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

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 10 Jan 2020 00:25:08 +0000

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=[email-masked]>
Date: Thursday, January 9, 2020 at 11:34 AM
To: "Richard Backman, Annabelle" <[email-masked]>, oauth <[email-masked]>
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 <[email-masked]> On Behalf Of Richard Backman, Annabelle
Sent: Wednesday, January 8, 2020 3:47 PM
To: oauth <[email-masked]>
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

---

From: Dick Hardt <[email-masked]>
Date: Thu, 9 Jan 2020 17:25:47 -0800

+1 to Annabelle's point

Different crypto operations should be able to use separate key pairs to
allow a separation of duties.
ᐧ

On Thu, Jan 9, 2020 at 4:25 PM Richard Backman, Annabelle <richanna=
[email-masked]> 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.
>
>
>
> –
>
> *From: *Mike Jones <Michael.Jones=[email-masked]>
> *Date: *Thursday, January 9, 2020 at 11:34 AM
> *To: *"Richard Backman, Annabelle" <[email-masked]>, oauth <
> [email-masked]>
> *Subject: *[UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits
> of jwks_uri
>
>
>
> 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.
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Richard Backman,
> Annabelle
> *Sent:* Wednesday, January 8, 2020 3:47 PM
> *To:* oauth <[email-masked]>
> *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?
>
>
>
> –
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Neil Madden <[email-masked]>
Date: Fri, 10 Jan 2020 15:50:48 +0000

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=[email-masked]> wrote:
> 
> 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.
>  
> – 
> From: Mike Jones <Michael.Jones=[email-masked] <mailto:Michael.Jones=[email-masked]>>
> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, oauth <[email-masked] <mailto:[email-masked]>>
> From: OAuth <[email-masked] <mailto:[email-masked]>> On Behalf Of Richard Backman, Annabelle
> To: oauth <[email-masked] <mailto:[email-masked]>>
> 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.
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Jan 2020 12:00:57 -0500

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 <[email-masked]> wrote:
> 
>> On 10 Jan 2020, at 00:25, Richard Backman, Annabelle <richanna=[email-masked] <mailto:richanna=[email-masked]>> wrote:
>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jan 2020 09:22:39 -0800

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 <[email-masked]> 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
>
> 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=[email-masked]> wrote:
>
> of content gets encrypted and sent to the AS in different contexts. However,
>  I gave one example on the PAR thread
> <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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 10 Jan 2020 18:58:51 +0100

> Am 10.01.2020 um 18:23 schrieb Dick Hardt <[email-masked]>:
> 
> 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.

How do you envision this to work? As you said, OAuth 2.0 is built on the assumption the AS is (at least logically) a monolith. All extension were built on that underlying assumption. I don’t see how an arbitrary extension can relax that assumption and still be compatible with the rest (just revisit the discussion re PAR and keys).

I think we should accept this design assumption, in the same way we should accept form encoding as request format instead of JSON, for OAuth 2.0 extensions. 

OAuth 3.0 could explicitely be developed with different architectures in mind.

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jan 2020 10:09:03 -0800

Perhaps I am misunderstanding what Annabelle was getting at, but having
more than one key in the metadata document would solve the the issue. IE,
extensions would define their own key instead of using the same one.

The metadata document itself was an extension.

On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <[email-masked]>
wrote:

> How do you envision this to work? As you said, OAuth 2.0 is built on the
> assumption the AS is (at least logically) a monolith. All extension were
> built on that underlying assumption. I don’t see how an arbitrary extension
> can relax that assumption and still be compatible with the rest (just
> revisit the discussion re PAR and keys).
>
> I think we should accept this design assumption, in the same way we should
> accept form encoding as request format instead of JSON, for OAuth 2.0
> extensions.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 10 Jan 2020 19:14:39 +0100

You mean additional JWKS URIs, for example?

> Am 10.01.2020 um 19:09 schrieb Dick Hardt <[email-masked]>:
> 
> 
> Perhaps I am misunderstanding what Annabelle was getting at, but having more than one key in the metadata document would solve the the issue. IE, extensions would define their own key instead of using the same one.
> 
>> On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <[email-masked]> wrote:
>> 
>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jan 2020 10:15:26 -0800

Yes. Thanks for clarifying.
ᐧ

On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <
[email-masked]> wrote:

>> > 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.
>>
>> I think we should accept this design assumption, in the same way we
>> should accept form encoding as request format instead of JSON, for OAuth
>> 2.0 extensions.
>>

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 10 Jan 2020 12:19:01 -0600

Can the keys in the document at the jwks_uri indicate what they are for?
Either by adding other top-level properties next to "keys" or by specifying
a property on a key itself? At least that way implementations that expect
just one value of jwks_uri wouldn't have to change.

Aaron

On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt <[email-masked]> wrote:

>> Am 10.01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail..com
>> <[email-masked]>>:
>>
>> 
-- 
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: Neil Madden <[email-masked]>
Date: Fri, 10 Jan 2020 18:26:58 +0000

The problem with specifying a property on the key itself is that a microservice might lie about what it’s keys are for. I think you either need separate documents or some separate metadata mapping uses to key ids. 

— Neil

> On 10 Jan 2020, at 18:19, Aaron Parecki <[email-masked]> wrote:
> 
> !
> Can the keys in the document at the jwks_uri indicate what they are for? Either by adding other top-level properties next to "keys" or by specifying a property on a key itself? At least that way implementations that expect just one value of jwks_uri wouldn't have to change.
> 
> Aaron
> 
> 
> 
>>> On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <[email-masked]> wrote:
>>>>> Am 10.01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail..com>:
>>>>> 
>>>> 
> @aaronpk

---

From: Neil Madden <[email-masked]>
Date: Fri, 10 Jan 2020 18:30:04 +0000

> On 10 Jan 2020, at 17:22, Dick Hardt <[email-masked]> wrote:
[...]
> 
> 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. 

Well you can run more than one instance - it’s a completely stateless service. You can also run a separate instance (or set of instances) per key if you like. 

Neil

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jan 2020 10:50:31 -0800

There are many other factors to resiliency than multiple instances.

On Fri, Jan 10, 2020 at 10:30 AM Neil Madden <[email-masked]>
wrote:

> > As to the suggestion of using a JWT-decryption-microservice, another
> goal would be increased resiliency of the components. If the
> Well you can run more than one instance - it’s a completely stateless
> service. You can also run a separate instance (or set of instances) per key
> if you like.
>
> Neil

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jan 2020 10:52:52 -0800

The metadata document is declarative, and can easily be yet another
separate role in the AS.

In large organizations, different people are empowered different roles, so
the team owning the metadata document could be different from the team
generating ID tokens, and different from the team generating JWTs.

On Fri, Jan 10, 2020 at 10:27 AM Neil Madden <[email-masked]>
wrote:

> The problem with specifying a property on the key itself is that a
> microservice might lie about what it’s keys are for. I think you either
> need separate documents or some separate metadata mapping uses to key ids.
>
> — Neil
>
>>>> How do you envision this to work? As you said, OAuth 2.0 is built on
>>>> the assumption the AS is (at least logically) a monolith. All extension
>>>> were built on that underlying assumption. I don’t see how an arbitrary
>>>> extension can relax that assumption and still be compatible with the rest
>>>> (just revisit the discussion re PAR and keys).
>>>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jan 2020 10:59:11 -0800

To restate my previous point, we may not be able to change what is
currently specified and deployed, but we can for future extensions such as
RAR and PAR.

To paraphrase Annabelle, this ship may have already sailed.

---

From: Neil Madden <[email-masked]>
Date: Fri, 10 Jan 2020 19:31:39 +0000

Sure, but we know how to run resilient services. My point is that there’s nothing particularly special about cryptographic keys: if you want to control how they are used there is a whole range of normal access control methods you can apply to them without needing to change anything in OAuth. 

Neil

> On 10 Jan 2020, at 18:50, Dick Hardt <[email-masked]> wrote:
> 
> 
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden <[email-masked]> wrote:
>> 
>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 10 Jan 2020 21:22:10 +0000

Having different JWKS URIs in the metadata document for different purposes would address the issue, but I’m not sure off-hand if we can clearly delineate purposes in a robust way without making it too complicated. So it may be correct for the working group to accept the situation for what it is.

However, if we do that then we need to stop pretending that “use different keys” is a viable option. That tool needs to be tossed out of the toolbox, because our specifications do not allow implementers to do that in a meaningful way. The fact that we’ve used that argument despite this limitation demonstrates that this is a non-obvious result of the trust model we’ve adopted. If we stick with that model, we need to be more conscious of this issue in our future work. Some documents will need Security Considerations that draw attention to it, others may need more attention. We also need to recognize that we will be ruling out certain types of deployments, and certain use cases.

–

From: Dick Hardt <[email-masked]>
Date: Friday, January 10, 2020 at 11:00 AM
To: Neil Madden <[email-masked]>
Cc: Aaron Parecki <[email-masked]>, oauth <[email-masked]>, Mike Jones <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

To restate my previous point, we may not be able to change what is currently specified and deployed, but we can for future extensions such as RAR and PAR.

On Fri, Jan 10, 2020 at 10:52 AM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
The metadata document is declarative, and can easily be yet another separate role in the AS.

In large organizations, different people are empowered different roles, so the team owning the metadata document could be different from the team generating ID tokens, and different from the team generating JWTs.

On Fri, Jan 10, 2020 at 10:27 AM Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:
The problem with specifying a property on the key itself is that a microservice might lie about what it’s keys are for. I think you either need separate documents or some separate metadata mapping uses to key ids.

— Neil

On 10 Jan 2020, at 18:19, Aaron Parecki <[email-masked]<mailto:[email-masked]>> wrote:
!
Can the keys in the document at the jwks_uri indicate what they are for? Either by adding other top-level properties next to "keys" or by specifying a property on a key itself? At least that way implementations that expect just one value of jwks_uri wouldn't have to change.

Aaron

On Fri, Jan 10, 2020 at 12:16 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Yes. Thanks for clarifying.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=373436a5-294f-48b6-a06d-73c59fdafe0d]ᐧ

On Fri, Jan 10, 2020 at 10:14 AM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
You mean additional JWKS URIs, for example?

Am 10.01.2020 um 19:09 schrieb Dick Hardt <dick.hardt@gmail..com<mailto:[email-masked]>>:
Perhaps I am misunderstanding what Annabelle was getting at, but having more than one key in the metadata document would solve the the issue. IE, extensions would define their own key instead of using the same one.

On Fri, Jan 10, 2020 at 9:58 AM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

> Am 10.01.2020 um 18:23 schrieb Dick Hardt <[email-masked]<mailto:[email-masked]>>:
>

OAuth 3.0 could explicitely be developed with different architectures in mind.
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com>
@aaronpk<http://twitter.com/aaronpk>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jan 2020 18:34:17 -0800

I was not saying that there was anything special about keys, nor that we
needed to change OAuth.

While using one key and controlling where it us used via access control
works, it is not ideal.

OAuth could have had just one endpoint, and done access control for
different roles -- but it did not. We enabled flexibility by separating the
authorization endpoint and the token endpoint. The dynamic client
registration extension defined a new endpoint, the registration endpoint.

I don't think we can change what has been deployed today -- but NEW
extensions that use keys for new purposes SHOULD define their own URI.
ᐧ

On Fri, Jan 10, 2020 at 11:31 AM Neil Madden <[email-masked]>
wrote:

> Sure, but we know how to run resilient services. My point is that there’s
> nothing particularly special about cryptographic keys: if you want to
> control how they are used there is a whole range of normal access control
> methods you can apply to them without needing to change anything in OAuth.
>
> Neil
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 10 Jan 2020 18:35:38 -0800

For new extensions, giving the key uri a new name would seem to work the
same as we have different names for different endpoints.

The cow is out of the barn for current work though.
ᐧ

On Fri, Jan 10, 2020 at 1:22 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> Having different JWKS URIs in the metadata document for different purposes
> would address the issue, but I’m not sure off-hand if we can clearly
> delineate purposes in a robust way without making it too complicated. So it
> may be correct for the working group to accept the situation for what it is.
>
>
>
> However, if we do that then we need to stop pretending that “use different
> keys” is a viable option. That tool needs to be tossed out of the toolbox,
> because our specifications do not allow implementers to do that in a
> meaningful way. The fact that we’ve used that argument despite this
> limitation demonstrates that this is a non-obvious result of the trust
> model we’ve adopted. If we stick with that model, we need to be more
> conscious of this issue in our future work. Some documents will need
> Security Considerations that draw attention to it, others may need more
> attention. We also need to recognize that we will be ruling out certain
> types of deployments, and certain use cases.
>
>
>
> –
>
> *From: *Dick Hardt <[email-masked]>
> *Date: *Friday, January 10, 2020 at 11:00 AM
> *To: *Neil Madden <[email-masked]>
> *Cc: *Aaron Parecki <[email-masked]>, oauth <[email-masked]>, Mike
> Jones <[email-masked]>, "Richard Backman, Annabelle" <
> [email-masked]>
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] [UNVERIFIED SENDER] RE:
> Cryptographic hygiene and the limits of jwks_uri
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 13 Jan 2020 21:25:52 -0500

I would rather see extensions define a key ID than a new key set URI. Otherwise what’s the point of having more than one key in the set, with unique identifiers?

It would’ve been nice if JWK could’ve agreed on a URL-based addressing format for individual keys within the set, but that ship’s sailed.

 — Justin

> On Jan 10, 2020, at 9:34 PM, Dick Hardt <[email-masked]> wrote:
> 
> I was not saying that there was anything special about keys, nor that we needed to change OAuth.
> 
> While using one key and controlling where it us used via access control works, it is not ideal.
> 
> OAuth could have had just one endpoint, and done access control for different roles -- but it did not. We enabled flexibility by separating the authorization endpoint and the token endpoint. The dynamic client registration extension defined a new endpoint, the registration endpoint.
> 
> I don't think we can change what has been deployed today -- but NEW extensions that use keys for new purposes SHOULD define their own URI.
> ᐧ
> 
> On Fri, Jan 10, 2020 at 11:31 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
>> On 10 Jan 2020, at 18:50, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> On Fri, Jan 10, 2020 at 10:30 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> > On 10 Jan 2020, at 17:22, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> [...]
>> >

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 13 Jan 2020 18:38:42 -0800

Right now, Okta publishes two keys at the jwks_uri in order to be able to
rotate keys periodically. During the token lifetime window during key
rotation, the RSs can still find both the old and new key IDs in the set.

RSs are looking for a specific key ID when they do this, so it would be
fine to include additional keys that are used for something other than
access tokens since the RSs would just ignore them.

So an extension could say "use this key identified by kid" and that'd be a
decent extension mechanism.

On Mon, Jan 13, 2020 at 6:26 PM Justin Richer <[email-masked]> wrote:

> I would rather see extensions define a key ID than a new key set URI.
> Otherwise what’s the point of having more than one key in the set, with
> unique identifiers?
>
> It would’ve been nice if JWK could’ve agreed on a URL-based addressing
> format for individual keys within the set, but that ship’s sailed.
>
>
>  — Justin
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 14 Jan 2020 21:17:47 +0000

The kid used by a service will change when it rotates keys (this is the main value of JWK Sets IMHO), so kid cannot be used as part of static metadata. You’d need to introduce a new field so you can assign a “logical key” identifier that remains the same across key rotations/versions.

There are several issues with trying to address this by augmenting JWK though:

  *   Existing deployments will ignore the logical key identifier, so there is no way to keep those keys from being used to sign fraudulent ID Tokens (for example).
  *   The JWK set becomes a shared resource that spans trust boundaries.

A solution based on separate jwks_uri metadata parameters solves both of these problems, and requires very little effort for ASes that don’t have this concern.

–

From: OAuth <[email-masked]> on behalf of Aaron Parecki <[email-masked]>
Date: Monday, January 13, 2020 at 6:39 PM
To: Justin Richer <[email-masked]>
Cc: "Richard Backman, Annabelle" <richanna=[email-masked]>, oauth <[email-masked]>, Mike Jones <Michael.Jones=[email-masked]>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] RE: Cryptographic hygiene and the limits of jwks_uri

Right now, Okta publishes two keys at the jwks_uri in order to be able to rotate keys periodically. During the token lifetime window during key rotation, the RSs can still find both the old and new key IDs in the set.

RSs are looking for a specific key ID when they do this, so it would be fine to include additional keys that are used for something other than access tokens since the RSs would just ignore them.

So an extension could say "use this key identified by kid" and that'd be a decent extension mechanism.

On Mon, Jan 13, 2020 at 6:26 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I would rather see extensions define a key ID than a new key set URI. Otherwise what’s the point of having more than one key in the set, with unique identifiers?

 — Justin

On Jan 10, 2020, at 9:34 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

I don't think we can change what has been deployed today -- but NEW extensions that use keys for new purposes SHOULD define their own URI.
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=40ee9f20-bfaf-4f2d-8905-6e0ad8b28481]ᐧ

On Fri, Jan 10, 2020 at 11:31 AM Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:
Sure, but we know how to run resilient services. My point is that there’s nothing particularly special about cryptographic keys: if you want to control how they are used there is a whole range of normal access control methods you can apply to them without needing to change anything in OAuth.

Neil

On 10 Jan 2020, at 18:50, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
There are many other factors to resiliency than multiple instances.

On Fri, Jan 10, 2020 at 10:30 AM Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:

> On 10 Jan 2020, at 17:22, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
[...]

Neil

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 15 Jan 2020 22:53:00 +0200

> format for individual keys within the set, but that ship’s sailed.

For querying / selecting JWKs from a set this would have been a useful
addition to the spec.

But I don't see how such an URL can help us to identify a single JWK in
a set, given the possibility to have multiple JWKs with the same "kid".

I.e. if we do "https://example.com/jwks.json?kid=xyz", there is no
guarantee for a single key. Even if we add additional query params, like
use, alg, etc, none of them guarantees a unique JWK identification.

I like the utility of that though.

Vladimir

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jan 2020 11:55:05 -0500

Well that’s what I’m saying — we could have had restrictions within JWK (and maybe even a different syntax) that would guarantee a unique key ID, as well as ways to talk about it from the outside. 

 — Justin

> On Jan 15, 2020, at 3:53 PM, Vladimir Dzhuvinov <[email-masked]> wrote:
>

---

From: "Manger, James" <[email-masked]>
Date: Wed, 29 Jan 2020 06:50:06 +0000

>> It would’ve been nice if JWK could’ve agreed on a URL-based 
>> addressing format for individual keys within the set, but that ship’s sailed.

Using the fragment on a JWKS URL to indicate the key id would be good.
Then a single URL by itself can identify a specific key.

https://example.com/keys.jwks#2011-04-29

This would have worked particularly well if a JWKS was a JSON object with key-ids as the member names, instead of an array. That is presumably too late to fix. But defining the fragment format for application/jwk-set+json to be a kid value should be possible.

If you put multiple keys with the same key-id in a JWKS you are asking for trouble -- just call that a non-interoperable corner for people to avoid.

--
James Manger

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 29 Jan 2020 21:35:49 +0000

This could be nice, but it’s solving a different problem. The issue I’m drawing attention to is about how an AS indicates that a given key is valid. That’s what the jwks_uri AS metadata property is for, and it does a great job. The problem is that it does not allow enough granularity. Currently all an AS can do is say “here are the keys to use to verify stuff I signed.” It can’t say “here are the keys to use to verify ID Tokens, and here is a different set of keys to use to verify access tokens.”

—
Annabelle Backman
AWS Identity

> On Jan 28, 2020, at 10:51 PM, Manger, James <[email-masked]> wrote:
> 
> 
>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 30 Jan 2020 11:27:10 -0800

Rephrasing Annabelle's description to highlight the issue:

The AS says "here are the keys to use to verify all of the tokens that *we*
have signed"

Separating duties in a large system is good cryptographic hygiene, IE, one
component signs ID Tokens, another signs access tokens.

On Wed, Jan 29, 2020 at 1:36 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> This could be nice, but it’s solving a different problem. The issue I’m
> drawing attention to is about how an AS indicates that a given key is
> valid. That’s what the jwks_uri AS metadata property is for, and it does a
> great job. The problem is that it does not allow enough granularity.
> Currently all an AS can do is say “here are the keys to use to verify stuff
> I signed.” It can’t say “here are the keys to use to verify ID Tokens, and
> here is a different set of keys to use to verify access tokens.”
>
> —
> Annabelle Backman
> AWS Identity
>
> > This would have worked particularly well if a JWKS was a JSON object
> with key-ids as the member names, instead of an array. That is presumably
> too late to fix. But defining the fragment format for
> application/jwk-set+json to be a kid value should be possible.
> >
> > If you put multiple keys with the same key-id in a JWKS you are asking
> for trouble -- just call that a non-interoperable corner for people to
> avoid.
> >
> > --
> > James Manger

---

From: John Bradley <[email-masked]>
Date: Fri, 31 Jan 2020 11:39:36 -0300

I remember the fight to have diffrent keys defined for signing and
encryption.

I am glad times have changed.  

You can use difffent keys now with a JWKS URI that allows you to
separate the private keys.

The question is if you want the verifier to be able to differentiate the
purpose.

One way might be to encode some context into the keyID, but it is
probably better to have separate JWKS URI.

John B.

On 1/30/2020 4:27 PM, Dick Hardt wrote:
> The AS says "here are the keys to use to verify all of the tokens that
> *we* have signed"
>
> Separating duties in a large system is good cryptographic hygiene, IE,
> one component signs ID Tokens, another signs access tokens.
>
>
> On Wed, Jan 29, 2020 at 1:36 PM Richard Backman, Annabelle
> <richanna=[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     This could be nice, but it’s solving a different problem. The
>     issue I’m drawing attention to is about how an AS indicates that a
>     given key is valid. That’s what the jwks_uri AS metadata property
>     is for, and it does a great job. The problem is that it does not
>     allow enough granularity. Currently all an AS can do is say “here
>     are the keys to use to verify stuff I signed.” It can’t say “here
>     are the keys to use to verify ID Tokens, and here is a different
>     set of keys to use to verify access tokens.”
>
>     —
>     Annabelle Backman
>     AWS Identity
>
>     > On Jan 28, 2020, at 10:51 PM, Manger, James
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > 
>     >>
>     > This would have worked particularly well if a JWKS was a JSON
>     object with key-ids as the member names, instead of an array. That
>     is presumably too late to fix. But defining the fragment format
>     for application/jwk-set+json to be a kid value should be possible.
>     >
>     > If you put multiple keys with the same key-id in a JWKS you are
>     asking for trouble -- just call that a non-interoperable corner
>     for people to avoid.
>     >
>     > --
>     > James Manger