To this, I'll add that the OpenID Connect ID Token specification at http://openid.net/specs/openid-connect-core-1_0.html#IDToken adds this, prohibiting the use of header parameters to communicate the keys:
ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk header parameter fields. Instead, references to keys used are communicated in advance using Discovery and Registration parameters, per Section 10 (Signatures and Encryption)<http://openid.net/specs/openid-connect-core-1_0.html#SigEnc>. This is for exactly the reasons described in this thread. -- Mike -----Original Message----- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Tuesday, March 04, 2014 7:41 AM To: Jared Hanson; j...@ietf.org Cc: oauth Subject: Re: [OAUTH-WG] Correct use of jku claims in JWT/JWS bearer assertions I might be suffering from a touch of confirmation bias but I think this underscores what I was trying to say near the end of the JOSE session in Vancouver during the "key finding algorithm" discussion. Namely that finding a key is not the same as trusting a key and that I'm concerned that explaining how to find a key might lead to implementations that blindly trust whatever key is found. Looking again at the drafts, I found some guidance/precautionary text in JWS and JWT (there might be more I missed), which I've copied with references below. I think that's all there is and I don't know if it's really sufficient. Nor do I know if either WG could agree on saying much more specific. That's probably not exactly what you were looking for, Jared, but was what I could dig up. Maybe some more discussion will be catalyzed. The newish Notes on Key Selection appendix in JWS [0] has this cautionary text: 4. Make trust decisions about the keys. Signatures made with keys not meeting the application's trust criteria would not be accepted. Such criteria might include, but is not limited to the source of the key, whether the TLS certificate validates for keys retrieved from URLs, whether a key in an X.509 certificate is backed by a valid certificate chain, and other information known by the application. And the last paragraph of the Security Considerations in JWT [1], which I think was just recently added in -18, also has some words of caution: "The contents of a JWT cannot be relied upon in a trust decision unless its contents have been cryptographically secured and bound to the context necessary for the trust decision. In particular, the key(s) used to sign and/or encrypt the JWT will typically need to verifiably be under the control of the party identified as the issuer of the JWT." [0] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-23#appendix-D [1] http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18#section-11 On Wed, Feb 12, 2014 at 6:26 PM, Jared Hanson <jaredhan...@gmail.com<mailto:jaredhan...@gmail.com>> wrote: > I'm wondering if there is any guidance on including "jku", "jwk", > "x5u", and "x5c" > claims in a JWT/JWS used as a bearer assertion for authentication. > > Specifically, in the case of service-to-service authentication, where > the "iss" is set to the service acting as a client, say > "https://client.example.net/"; > making a > request to "https://api.example.com/";, and the assertion is signed > using client.example.net's private key. > > In this situation, api.example.com authenticates the assertion by > finding the corresponding public key (possibly in a JWK set, the > location of which can be obtained by something like OpenID Provider > Configuration [1]). > > It is clear that any claims in the assertion are self-asserted until > validated, including both the "iss" and any keys or URLs to keys. > Thus, when a service validates the assertion, it *must not* use the > values of "jku", etc to validate the signature. Instead it should use > some trusted channel to obtain the keys directly from the issuer. > > If this were not done, a malicious entity could freely generate > assertions claiming to be client.example.net, using any private key > and including a malicious reference to its own public key using a > "jku" set to "https://malicious.com/jwks.json"; > > This security consideration is not called out anywhere that I've > noticed, which I've seen leading to insecure implementations and/or > bad examples. For example, this example on Gluu's wiki: > http://ox.gluu.org/doku.php?id=oxauth:jwt is blindly using the value > of "jku" to fetch the key used to validate the signature, without any > way to validate that the URL itself belongs to the issuer. > > I'm raising this point hoping that guidance can be clarified and > included in the specification. > > Thanks, > Jared Hanson > > PS. I separately sent this same message to the JOSE list, and later > figured it was equally relevant to OAuth, if not more so. > > [1] > http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConf > ig > > -- > Jared Hanson <http://jaredhanson.net/> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
