Subject: Re: [OAUTH-WG] Correct use of jku claims in JWT/JWS bearer assertions

From: Brian Campbell <[email-masked]>
Date: Tue, 4 Mar 2014 15:40:44 +0000

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 <[email-masked]> 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#ProviderConfig
>
> --
> Jared Hanson <http://jaredhanson.net/>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 4 Mar 2014 16:22:34 +0000

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:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, March 04, 2014 7:41 AM
To: Jared Hanson; [email-masked]
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.

       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:

   of the JWT."

On Wed, Feb 12, 2014 at 6:26 PM, Jared Hanson <[email-masked]<mailto:[email-masked]>> wrote:

> I'm wondering if there is any guidance on including "jku", "jwk",

> "x5u", and "x5c"

> 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/"

> 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]).

> 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.

> 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

> [email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>