1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

Why does resolver sign entity statement?

Issue #1432 resolved
Torsten Lodderstedt created an issue

PR #122 changed the evaluate endpoint to a resolve endpoint. While I like the idea of a resolver as agent/utility function (just like in DNS), I don’t understand why the resolver signs the response. That way the receiver cannot validate the authenticity of the entity statement (which should have been signed by the respective issuer).

I also don’t understand the purpose of the iss parameter. Why is this supposed to be “The entity identifier of the entity who is requesting the information.“ ?

Comments (27)

  1. Giuseppe De Marco

    I agree on iss having moved a similar doubt here
    https://bitbucket.org/openid/connect/issues/1368/federation_api-fetch-entity-statement

    then we get iss as optional in the fetch endpoint. Here in resolve endpoint, if I understand correctly, it’s something usefull for having something signed from a specific issuer. I dont' believe to use it and probably I won’t implement it.

    At the same time there’s who think that this `iss` could give some power when the resolve endpoint would be an interface of a shared federation API. Nothing of my interest if I can be honest.

    Regarding the response content I remember that the first proposal was for a json content, then we saw a signed jwt due to the motivation to have something signed from a trusted entity of which we have its entity configuration, a priori.

  2. Roland Hedberg

    All this was discussed at a AB/Connect conference call.

    The idea with the resolve endpoint is that the resolver does the evaluation/validating work, one could say on behalf of the requester.

    Having the resolver signed the response has two reasons. On his that the tamper resistance the other non-repudiation. Such that the receiver can see that the response actually came from the resolver and that the resolver puts it reputation on the line.

    This was John’s doing. He wanted to have, if possible, the requestor of the information being the receiver of the response in the “aud” parameter.

    Since the requestor doesn’t have to sign the request the only way that the resolver might get to know who is asking is if the requestor adds its id to the request. “iss” in the context therefor is the issuer of the request.

    ‌

  3. Torsten Lodderstedt reporter

    I have concerns.

    1. The whole openid federation trust model depends on the signature of the authoritative source of the entity statement and now we replace that by a signature of a more less arbitrary party? Such a signature might help to convict a bad guy, but that can only happen after the fact. If an attacker takes over a resolver, it could manipulate all federation metadata at will.
    2. Setting the “aud” to a value defined by the requestor without authenticating the requestor means this endpoint can be used by an attacker to mint responses.

    I think the OpenID Federation spec needs a resolver design/architecture. However, that needs to be thoroughly designed, discussed, and security analysed. A single WG call is not enough.

    ‌

  4. Roland Hedberg

    It doesn’t sign entity statements. It signs a JSON structure containing resolved metadata and verified trust marks.

    Agree that using “iss” in the request as something to trust is insecure.

    Which leads us to using signed request or …

  5. Roland Hedberg

    To be clear: I agree with Tom Jones in this. There resolve endpoint is not there to off load the work of an entity of doing trust chain collection and verification. It has some usage as a recommendation though.

    If as Tom pointed out someone does auditing on an entity and finds it hasn’t done its bit (collecting and verifying trust chains before starting to talk to an entity) then it is in deep …

  6. Torsten Lodderstedt reporter

    I know that the resolver does not sign entity statements. It builds and signs a response (hopefully) containing the result of the resolution.

    The caller must fully trust the resolver since there is no way to validate the response independently. The resolver must be well protected. Since an attacker that has taken over a legit resolver could produce false data thus sending user’s of to phishing web sites posing to be legit IDPs. …

    That’s why I pointed out the trust model completely changes and the cryptographic protection of the authoritative federation metadata is gone. At least the security considerations section should point that out.

  7. Roland Hedberg

    Right, so the caller must itself do collecting/verifying/resolving of trust chains before using the information. It should NOT (IMHO) start any communication with another entity based solely on what the resolver says. The spec should be explicit regarding this.

  8. Giuseppe De Marco

    Resolve endpoint is a very delicate topic.
    Yes it can be protected, for example, in a organization that uses it as an internal middleware to centralize all the federation trust operations. Each of its RPs or OPs would have a single point of trust and doesn’t need to implement federation and store trust chain by its own.

    Let’s assume that an organization can’t customize all the oidc service (and underlying libraries) to support oidc federation, so it needs a middleware to divide the oidc core operations from the oidc fed ones. This is a strategy. Its RPs or OPs just have to include a intercept middlware to fetch (and store in the preexisting storage) the resolved entity statement, then it can continue working with its oidc core libraries. In this way OIDC Fed can be implemented also like an API gateway

    In another way, the Resolve Endpoint can be served by a trust anchor, that periodically collects all the trust chains of its descendant (and also of the descendats of their descendants with the constraint of max_path_length) and give to the requestes the cached trust marks and metadata of a subject, if available (with iat and exp having said that it’s a signed JWT).

    regarding the iss parameter of this resolve endpoint, I ignore it in my implementation because I don’t support my service to proxy to other third party issuers, so the iss in my service is implicitly itself.

  9. Torsten Lodderstedt reporter

    I think a resolver is a very helpful mechanisms (like in DNS). I hope we can agree a resolver must be a trustworthy/trusted component since it has a different trust model than the underlying federation. I suggest to add a section to the spec discussing pros and cons of a resolver along with security advise. I have filed issue #1445.

  11. Torsten Lodderstedt reporter

    Please have a look at https://openid.bitbucket.io/connect/openid-connect-federation-1_0.html#rfc.section.7.2.2

    It states:

    The response is a signed JWT containing resolved metadata and verified trust marks. The keys used by the resolver should be the same keys as it would use when it construct a self-signed entity statement. This means that the issuer of the request can easily find and verify the resolvers signing keys by collecting and verifying the appropriate trust chain.

    The example underneath this paragraph also uses the iss value "https://resolver.example.it/spid".

    This means the signature of the original issuer of the entity statement is gone, which is the signature that is intended to establish trust in the entity statement. Can someone please explain the rationale?

  12. Giuseppe De Marco

    The resolve statement response is signed by its issuer that’s https://resolver.example.it/spid", because this latter builds the trust chains and get the final metadata. This result, the final metadata, is something produced and issued by https://resolver.example.it/spid that applies the metadata policy

    So the trust is placed on the resolver of the metadata and not to the subject of the statement. The trust Marks contained in the response are only the trust marks recognized and verified by https://resolver.example.it/spid

    When I read it construct a self-signed entity statement I mean that the resolve entity statement must be signed with a federation jwk (as it is for all the federation signature operations, as entity configurations and statements and trust marks issuance)

  13. Giuseppe De Marco

    @Torsten Lodderstedt @Roland Hedberg
    Do you think it might be useful to get the entire trust chain within the resolve entity statement, in a claim called for example “trust_chain”?

    An example of a serialized trust chain would be a list of entity statement (signed JWT)

    ‌

  14. Roland Hedberg

    Guiseppe is correct. The resolver is doing the work and should take responsibility for the result so it’s the resolver that signs the result.

  15. Michael Jones

    As discussed on the 21-Apr-22 call, each Entity Statement remains a JWT signed by its issuer. The signature by the resolver is in addition to those.

    Does the above discussion sufficiently satisfy your question such that we can close the issue, Torsten, or would you like to instead propose specific changes to the specification?

    Thanks all.

  16. Vladimir Dzhuvinov

    Do we have other GET requests in OIDC Federation with an iss query parameter?

    I found the naming of this parameter when asking for a resolved trust chain somewhat confusing. An aud seems a better choice to me, since that would become the aud of the signed resolve response.

  17. Giuseppe De Marco

    @Vladimir Dzhuvinov

    the iss parameter is required only in the fetch entity statement endpoint

    I agree about your doubts on having iss in the entity resolve endpoint, anyway it’s optional and would enable proxying feature (that I won’t implement anyway).
    aud sounds misleading to me, because this endpoint is not protected

  18. Vladimir Dzhuvinov

    Thanks Giuseppe for chiming in. It was the naming of the parameter that sets the aud in the resolver response that I found confusing, in the sense that query parameters in a GET request are typically meant to filter / shape the request. So I thought about aud or something more descriptive, like requester_iss.

    Is the resolve endpoint required or optional to implement? I looked for this piece of info in the spec.

    ‌

  19. Roland Hedberg

    Definitely optional. It’s absolutely possible to run a federation without having any of the entities in the federation implementing this endpoint.

  20. Giuseppe De Marco

    yes, resolve entity statement is completely optional, it’s more like a helper, a tool.

    @Vladimir Dzhuvinov I mean that it’s impossible to determine who is the requester, and also how to value the aud claim, having the resolve endpoint unprotected.

    We know a requester only if it makes a request to a protected endpoint (basic, private_key …).
    In the implementation I work on, my team is wondering about the need of protecting this endpoint, but for quite different purpose (here).

    anyway if the response is signed and the requester is known, the audience of the response is the requeter and the aud claim sounds pretty good to me

  21. Vladimir Dzhuvinov

    Thanks! I did find that section now 🙂

    4.6. Federation Entityfederation_resolve_endpoint
    OPTIONAL. The resolve endpoint described in Section 7.2. Any federation entity MAY publish a federation_resolve_endpoint.

    ‌

    How about updating the spec about the requester identifier to say that it MUST be ignored if the requester isn’t authenticated? What was the intended purpose for having it? Was it simply to make sure there is an aud in the signed response JWT? I second Guiseppe’s concern to essentially vouch for an aud in the signed response in cases when the caller isn’t known. This may end up opening an avenue for some unexpected misuse of the protocol.

  24. Michael Jones

    In discussions with @Roland Hedberg and @Giuseppe De Marco at TNC, we agreed that the iss request parameter should be removed and an aud should only be present in the response if the requesting client is authenticated.

  28. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
Federation
Milestone
–
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!