Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

[Dick Hardt <[e-mail]>]

OAuth 1.0 assumed the RS and AS were a monolith.

OAuth 2.0 separated the RS and the AS. It put them in separate boxes. It
also did not define the access token, allowing an implementation to keep
them as a monolith, or allow separation of duties. There was no impact on
the client, but it was a more agile specification for implementation.

As OAuth 2.0 has been extended, the AS is now also an OpenID Connect
Provider, and the access token is being defined. These extensions have
assumed all of this functionality is a monolith.

I'm not suggesting that we MUST make changes to existing extensions, but
design future extensions so that an implementation can separate duties if
desired.

As to the suggestion of using a JWT-decryption-microservice, another goal
would be increased resiliency of the components. If the
JWT-decryption-microservice is unavailable, the whole system is
unavailable. If there are separate keys, then a failure in one component
does not fail the entire system.

/Dick




ᐧ

On Fri, Jan 10, 2020 at 9:01 AM Justin Richer <[e-mail]> wrote:

> I would argue that the AS being monolithic, as seen by outside parties, is
> a core assumption in OAuth 2. While there are deployments that, for
> example, split the authorization and token endpoints into different domains
> and servers, the client still sees them as a single entity.
>
> I think it’s fair for any extension to OAuth 2 to rest on that assumption.
> Any effort to split the endpoints into parts should be seen as a deployment
> detail requiring some extra work on the deployer’s side. For example, take
> PKCE: you need to communicate the client’s challenge at the authorization
> endpoint back to the token endpoint in order to verify the verifier. Or
> even just the authorization code itself. OAuth doesn’t tell you how to do
> that at all because it assumes that’s your problem to solve and it’s
> internal to the box drawn by the protocol.
>
> We do have a chance with the next generation work that we’re trying to
> start over in TxAuth to change these assumptions, but I think it’s too late
> to impose that requirement on OAuth 2.
>
>  — Justin
>
> On Jan 10, 2020, at 10:50 AM, Neil Madden <[e-mail]>
> wrote:
>
> This is an interesting point.
>
> I think OAuth has historically assumed that the AS is a monolithic system,
> or at least can be treated like one by clients. I think we might have to
> revisit quite a lot if we drop this assumption and adopt a threat model in
> which the AS is itself composed of a collection of mutually distrusting
> entities. Especially as different ASes might decide to divide up the trust
> boundaries in different ways.
>
> At least partially this feels like an internal implementation detail of
> the AS that can also be solved internally to that AS. For example, rather
> than providing microservices direct access to private keys you could
> implement a JWT-decryption-microservice that other microservices call. It
> can then check if the calling microservice is allowed to decrypt that type
> of JWT before returning the response (e.g., by checking the "typ" header).
> The same can be done for signing JWTs. Of course, that's not a perfect
> solution, but it illustrates that we don't necessarily need to solve these
> problems in the WG.
>
> If we go down the path of separate keys, then it might be simpler to
> introduce new metadata elements to list the kids of valid key ids for a
> given purpose rather than having multiple JWK Set endpoints. e.g.
> "id_token_hint_encryption_kids": ["rsa-key-1", "ec-key-2"]. That avoids the
> client having to fetch multiple sets of keys.
>
> -- Neil
>
> On 10 Jan 2020, at 00:25, Richard Backman, Annabelle <
> richanna=[e-mail]> wrote:
>
> The “typ” field helps prevent misrepresentation of a legitimately issued
> JWT, but it doesn’t address the issue I am trying to draw attention to,
> which is that the current model forces broader distribution and reuse of
> keys than is necessary, resulting in a greater blast radius for compromised
> keys or systems.
>
> For many cases, this is not a significant concern, as the AS is a
> monolithic system with no internal trust boundaries. However, in cases
> where the AS is composed of multiple microservices performing different
> tasks, the need to share keys between different microservices undermines
> efforts to create trust boundaries between them. I gave one example of this
> in my original email, where ID Token generation and access token generation
> are relegated to independent systems, each with separate private keys for
> signing tokens. Suppose a malicious party compromised the ID Token
> generator, or gained access to its private key, and issued fraudulent
> access tokens signed using that key. Since verifiers of both token types
> will look to the same metadata file and thus the same JWK set, they have no
> way to recognize that these access tokens are fraudulent.
>
> Note that while “typ” would help a verifier distinguish between an ID
> Token and an access token, it does not help in this case because the
> malicious party is generating well-formed access token JWTs, signed with a
> key that is legitimate for the AS but not for this purpose.
>
> The case for this being a concern on the encryption side is fuzzier,
> primarily because we simply don’t have many use cases where different kinds
> of content gets encrypted and sent to the AS in different contexts. However,
>  I gave one example on the PAR thread
> <https://mailarchive.ietf.org/arch/msg/oauth/iVXk3EusmV4Bh9-r58bebgZ6888>,
> where a PAR endpoint that decrypts request object JWTs will also be able to
> decrypt id_token_hint JWTs.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *Mike Jones <Michael.Jones=[e-mail]>
> *Date: *Thursday, January 9, 2020 at 11:34 AM
> *To: *"Richard Backman, Annabelle" <[e-mail]>, oauth <
> [e-mail]>
> *Subject: *[UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits
> of jwks_uri
>
> 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 <[e-mail]> *On Behalf Of *Richard Backman,
> Annabelle
> *Sent:* Wednesday, January 8, 2020 3:47 PM
> *To:* oauth <[e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>