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

[Jared Hanson <[e-mail]>]

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