This a good thing to think about. Thanks for bringing this up, Annabelle.
One thing that partially mitigates this is that the “use” and/or “key_ops”
attributes can be provided. This can allow signing keys to be differentiated
from encryption keys, for instance.
I’m not as worried about encryption keys as signing keys. If multiple kinds of
applications encrypt content to a party using the same public per-party key,
and the encryption is being used only to ensure confidentiality of the
messages, the confidentiality is still achieved.
One mitigation for signing keys is use of the “typ” field, as described in the
JWT BCP. Even if the same key was used and you receive an unexpected JWT type,
you will still reject it.
I believe there’s also cases where it’s fine to use the same signing key for
related operations. For instance, signing a Pushed Authorization Request and a
Request Object with the same key seems both logical and safe to me. (If others
can think of an attack that this enables, however, please do point it out.)
Which I believe leaves us with this case to worry about – shared signing keys
by unrelated applications when “typ” is not used. One way to mitigate this
would be to use per-application key sets. For instance, using values other
than “jwks_uri” to reference key sets for particular applications.
Anyway, for PAR, I believe that it’s fine to use the same keys as used for
Request Objects, so no new fields are needed for it.
I look forward to further discussion on the topic.
-- Mike
From: OAuth <[email protected]> On Behalf Of Richard Backman, Annabelle
Sent: Wednesday, January 8, 2020 3:47 PM
To: oauth <[email protected]>
Subject: [OAUTH-WG] Cryptographic hygiene and the limits of jwks_uri
I originally brought up this issue in the context of the PAR draft, but since
it broadly applies to the OAuth space I’m starting a new thread…
Section 3.12 of the JWT
BCP<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwt-bcp-07%23section-3.12&data=02%7C01%7CMichael.Jones%40microsoft.com%7C73d547c7681f4ea59a4808d7949529e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637141240697295445&sdata=AeQLxCao2ZT661ZK2fE4a6QKyh8IzO%2Bq%2Fqzbt7Vld0s%3D&reserved=0>
says: “Use different keys for different kinds of JWTs.” Section 4 of the JWT
Profile for OAuth 2.0 Access
Tokens<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-access-token-jwt-03%23section-4&data=02%7C01%7CMichael.Jones%40microsoft.com%7C73d547c7681f4ea59a4808d7949529e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637141240697305402&sdata=ISszTxlHTbALInjK%2FKggH9seZdW8kGXTDHZEWCyfAzc%3D&reserved=0>
says: “An authorization server MAY elect to use different keys to sign
id_tokens and JWT access tokens.” These statements are consistent with good
cryptographic hygiene. And we’ve made it difficult to impossible for an AS to
follow them.
The AS has a single metadata document containing a single URI referencing a
single JWK Set. But the AS has no way of indicating to clients which keys to
use for which purposes. For example, an AS cannot say that *only these* keys
are to be used to encrypt id_token_hint JWTs, and *only these* keys are to be
used to encrypt JAR request object JWTs. For encryption, the AS could enforce
that logic internally, but there is no way for the client to discover this. And
while the AS may be built to only use certain keys for signing ID Tokens and
other keys for signing JWT access tokens, it has no way to indicate this to the
client. So even if ID Token generation and access token generation are isolated
in different microservices within the AS, each microservice is capable of
forging the other’s tokens, because consumers can’t be told to distinguish
between different keys for the AS.
This seems like a ticking time bomb to me, as it’s a non-obvious side effect of
combining various OAuth 2.0 extensions, and it can undermine a lot of
sophisticated effort to follow security best practices. I can see a couple of
ways to address this (e.g., more sophisticated AS key metadata, tagging or
similar use case indication on JWKs), but before trying to propose something
I’d like to get people’s opinions on the problem. Is this already mitigated in
other ways? Has the ship sailed on this for OAuth, and now we have to live with
it? Should this be left to the deployments that care to solve with
non-interoperable solutions? Are there other clever ways we could approach
this? Are there other angles that we need to consider?
–
Annabelle Richard Backman
AWS Identity
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
