Why does resolver sign entity statement?
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)
-
-
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.
-
reporter I have concerns.
- 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.
- 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.
-
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 …
-
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 …
-
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.
-
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.
-
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.
-
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. -
Good discussion. I agree that we should address this by working on issue #1445.
-
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?
-
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) -
@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)
-
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.
-
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.
-
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 theaud
of the signed resolve response. -
@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 -
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 aboutaud
or something more descriptive, likerequester_iss.
Is the resolve endpoint required or optional to implement? I looked for this piece of info in the spec.
-
Definitely optional. It’s absolutely possible to run a federation without having any of the entities in the federation implementing this endpoint.
-
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 -
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 anaud
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. -
- changed status to open
Need more discussion with Roland and Andreas
-
The aud claim in the non normative example of the resolve response has been removed here
https://bitbucket.org/openid/connect/pull-requests/171Having said that the resolve endpoint is a unprotected endpoint, it sounds useless to me having the aud claim in the response. We’ll have some more discussion on this
-
-
assigned issue to
In discussions with @Roland Hedberg and @Giuseppe De Marco at TNC, we agreed that the
iss
request parameter should be removed and anaud
should only be present in the response if the requesting client is authenticated. -
assigned issue to
-
Superb! Thanks :)
-
-
- changed status to resolved
- Log in to comment
I agree on
iss
having moved a similar doubt herehttps://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.