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> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
