Thanks for the extra details! I published an updated draft.
Comments:
* The reason for the restructuring is the following: [..]counter-measures
are applicable to end users and clients looking at the tokens [..] The first
sentence talks about clients and end users and not just about clients.
Makes perfect sense! I applied your suggestion in the new draft.
* I am not as passionate about this paragraph as others in the group
because I have a pragmatic approach: it will not make a difference whether the
MUST NOT is capitalized or not.
On the basis of this, I would like to try keeping the uppercase thru the next
iteration. I’d rather make the intent extra clear, especially if it doesn’t
make a difference in terms of testable behavior.
On the leaking keys, that warrants more discussion. The current language is the
result of the discussion in
https://mailarchive.ietf.org/arch/msg/oauth/OfHpPeCQ0Pt8r9_qOF5sVC9GdWo/. You
can find the details in there, but the TL;DR is that we don’t want anyone to
have the impression that having one key dedicated to id_tokens and another for
access tokens only gives any extra guarantee in case one of those two keys is
leaked: meaning, if both keys are advertised in the metadata, they can be used
interchangeably hence an attacker obtaining the key dedicated to signing
id_tokens will be able to manufacture valid access tokens too without the RS
being able to tell the difference. It took me a bit to understand this during
the discussion, it is a tricky point. But all the more reasons to address it
explicitly.
In details:
* For the symmetric key case
The main challenge we are dealing with is the lack of specialized metadata
attributes to advertise intended key function.
That excludes the symmetric case given that there’s no discovery involved,
hence out of band anything can happen (eg the two parties might agree on
specific key uses).
* are even talking about the use of keys for different recipients. ID
Tokens are created by the AS for use by the OAuth Client while access tokens
are consumed by the resource server.
From the security PoV, the fact that the intended recipients are distinct
doesn’t improve outcomes if compromising a key meant for one recipient grants
an attacker access to the other recipient too.
Also. From the developer PoV it is pretty common to have one web application
that handles both browser requests for pages (hence being an ID_token
recipient) and API requests (hence expacting access tokens) from mobile
clients, S2S and other clients. Many developer platforms automatically
provision both a client_id and a resource ID for an application. This doesn’t
mean that _every_ application will have this dual nature, but it means that it
is a prominent enough scenario to require consideration, even if the dual
audience compromise wouldn’t be a problem in itself.
* Are you concerned that the private key is compromised on the AS?
Definitely the concern considered here. We advertise the public keys in the
metadata hence they are “leaked” by design 😊
* “The "kid" (key ID) Header Parameter is a hint indicating which key was
used to secure the JWS.”
At that point that is far too late 😊 If as RS I receive a JWT AT whose kid
declares it has been signed by A, and the AS metadata declares that possible
signing keys correspond to A and B, I have to accept the signature- right? But
as RS I cannot know whether A is the key the AS intended to use for signing ATs
or ID_tokens, all I know is that it is one of the keys the AS declares it will
use. If I am expecting an ID_token, I am in the exact same situation. That
means that an attacker compromising A can manufacture both ID_tokens and JWT
ATs that will look valid, regardless of what use (AT or ID_token) the AS
assigned to A or B. The key is that the AS intent remains an internal detail,
and all the RS can do is verify that A is one of the keys AS advertises. The
kid in the header doesn’t help to solve this.
* Why is this statement true “they have to accept signatures performed with
any of the keys published in AS metadata or OpenID Connect discovery"
See the last point
* Using different keys for different purposes with different recipients is
a common practice.
That’s true, but unfortunately in this particular case the lack of
differentiation in the AS metadata means that assigning different keys to
different audiences will not make a difference if those keys are all published
in an indifferentiated list.
From: Hannes Tschofenig <[email protected]>
Date: Thursday, September 17, 2020 at 03:23
To: Vittorio Bertocci <[email protected]>, "[email protected]"
<[email protected]>
Subject: RE: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
Hi Vittorio,
Thanks for the draft update.
Responses to your questions are below:
From: Vittorio Bertocci <[email protected]>
Sent: Tuesday, September 15, 2020 8:59 AM
To: Hannes Tschofenig <[email protected]>; [email protected]
Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
Thank you Hannes for the thorough review, and thanks in advance for the writeup!
I applied most of the changes you suggested, and submitted a new draft.
Comments on questions and suggestions I didn’t understand below:
1. Question: If you refer to RFC 6750 and then list the steps are you just
repeating the steps from RFC 6750 or are you augmenting them?
6750 doesn’t offer an explicit list of validation steps, given the format
agnostic approach followed by Core, tho some can be inferred here and there.
The validation steps defined here are closer to the ones OIDC core lists for
id_token validation, but aren’t exactly the same- besides the typ header step
and aud value considerations, which are unique to this spec, the discussion led
to some other important differences from the OIDC list (no ordering in the
steps, no auth_time, acr, azp considerations etc) that warrant listing the
validation steps explicitly.
[Hannes] Thanks. This answers my question. No further action needed on this
issue.
1. The phrase "leaking keys" is probably not the best term to describe what
follows afterwards in the text.
Can you expand on what aspect makes the term misaligned with the following
text? The main difference seems to be that later on the verb used is
“compromise”, but that’s more due to the fact that there’s an active agent in
the sentence (the attacker) while the preceding phrase lacks one. If I were to
use “compromise” instead of leak I’d need to make it passive, which seems a bit
weird. I am happy to change it, but I wanted to understand the point better
first.
Here is the entire paragraph:
“
Authorization servers should not rely on the use of different keys
for signing OpenID Connect ID Tokens and JWT tokens as a method to
safeguard against the consequences of leaking specific keys. Given
that resource servers have no way of knowing what key should be used
to validate JWT access tokens in particular, they have to accept
signatures performed with any of the keys published in AS metadata or
OpenID Connect discovery: consequently, an attacker just needs to
compromise any key among the ones published to be able to generate
and sign JWTs that will be accepted as valid by the resource server.
“
Let us consider two cases here, namely the symmetric key case and the
asymmetric key case.
In both cases it is common practice to use different keys for different
purposes. In this case we are even talking about the use of keys for different
recipients. ID Tokens are created by the AS for use by the OAuth Client while
access tokens are consumed by the resource server.
For the symmetric key case, one of the two parties can leak the key. Who do you
assume leaks the key here?
For the asymmetric key case, leaking the public key does not have a security
impact. Are you concerned that the private key is compromised on the AS? There
is, however, additionally the question about the compromise of the trust anchor.
You are saying that resource servers have no way of knowing what key to use to
validate the access token. This is not correct because there is a dedicated
field for that purpose: From RFC 7515:
“The "kid" (key ID) Header Parameter is a hint indicating which key was used to
secure the JWS.”
Why is this statement true “they have to accept signatures performed with any
of the keys published in AS metadata or OpenID Connect discovery"
In general, it is bad if the private key got compromised. This will allow an
adversary to create access tokens. The question is therefore: if this happens,
how can you revoke the keys.
Using different keys for different purposes with different recipients is a
common practice.
1. This RFC 2119 language is not really enforceable in terms of
interoperability.
I’d like to understand this better. The thing I am trying to express here is an
absolute prohibition, as stated by 2119. The fact that it is unenforceable and
potentially inconsequential doesn’t make it acceptable, hence the language
seems to be appropriate.
I didn’t take out the MUST NOT yet as we clarify the point further. I
did however apply all your edits to that section, as they do make things
clearer. Thanks!
Here is the sentence again:
"
The client MUST NOT inspect the content of
the access token
"
I fully understand that you are trying to prohibit the OAuth client to look at
the access token.
Normally, RFC 2119 language is used to inform how implementations should
behave. This behavior can then be tested. How do you want to test whether a
client did or did not look at the token as an outside observer?
I am not as passionate about this paragraph as others in the group because I
have a pragmatic approach: it will not make a difference whether the MUST NOT
is capitalized or not.
1. The first sentence is a repetition of the previous paragraph. I would
suggest to delete the first sentence in this paragraph and to move the second
sentence to the previous paragraph
The second sentence isn’t really a repetition IMO- rather, it is a
specialization. Whereas the first paragraph talks about the client, the
sentence you singled out talks about the end user. Those are closely
correlated, but not the same. There are scenarios where the end user doesn’t
have access to the tokens, but the client app does.
You are right. I would restructure the paragraphs as follows:
As JWT access tokens carry information by value, it now becomes
possible for requestors and receivers clients and potentially
even end users to directly peek inside the
token claims collection.
The client MUST NOT inspect the content of
the access token: the authorization server and the resource server
might decide to change token format at any time (for example by
switching from this profile to opaque tokens) hence any logic in the
client relying on the ability to read the access token content would
break without recourse. The OAuth 2.0 framework assumes that access
tokens are treated as opaque by clients. Administrators of
authorization servers should also take into account that the content
of an access token is visible to the client. Whenever client access
to the access token content presents privacy issues for a given
scenario, the authorization server should take explicit steps to
prevent it.
In scenarios in which JWT access tokens are accessible to the end
user, it should be evaluated whether the information can be accessed
without privacy violations (for example, if an end user would simply
access his or her own personal information) or if steps must be taken
to enforce confidentiality.
Possible measures to prevent leakage of information to clients and end
Users include: encrypting the access token, encrypting the sensitive
claims, omitting the sensitive claims or not using this profile, falling
back on opaque access tokens.
The reason for the restructuring is the following:
1. The counter-measures are applicable to end users and clients looking at
the tokens – not just end users.
2. The first sentence talks about clients and end users and not just about
clients.
I hope this makes sense.
Ciao
Hannes
From: OAuth <[email protected]<mailto:[email protected]>> on behalf
of Hannes Tschofenig
<[email protected]<mailto:[email protected]>>
Date: Monday, September 7, 2020 at 23:29
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
Hi Victorio, Hi all,
I am doing my shepherd write-up for draft-ietf-oauth-access-token-jwt-07.
Reading through the draft I have a few minor suggestions:
Section 2:
I would delete this sentence "JWT access tokens are regular JWTs complying with
the requirements described in this section."
Reason: You pretty much make the same statement on the previous page (see
terminology section).
Section 2.1
s/asymmetric algorithms/asymmetric cryptography
(same replacement in Section 4)
s/ This specification registers the "application/at+jwt" media type,
which can be used to indicate that the content is an access token./This
specification registers the "application/at+jwt" media type,
which can be used to indicate that the content is a JWT access token.
Use capitalized "Section" when a section number is indicated, such as in
Section 2.2.
Section 2.2
s/""aud"/"aud"
2.2.1
s/ auth_time OPTIONAL - as defined in section 2 of [OpenID.Core]./
auth_time OPTIONAL - as defined in Section 2 of [OpenID.Core].
s/ acr, amr OPTIONAL - as defined in section 2 of [OpenID.Core]./ acr, amr
OPTIONAL - as defined in Section 2 of [OpenID.Core].
s/Please see/See
s/For example:/For example,
Section 4
You write:
"Authorization servers SHOULD implement OAuth 2.0 Authorization Server Metadata
[RFC8414] ... "
Are you sure you mean "implement" and not "use"? The paragraph gives me the
impression that you talk about "ASs using RFC 8414"
s/Please see section Section 5 for further guidance on security
implications./Please see Section 5 for further guidance on security
implications.
This sentence sounds strange to me:
"
When invoked as described in OAuth 2.0 Bearer Token Usage [RFC6750],
resource servers receiving a JWT access token MUST validate it in the
following manner.
"
How about:
"
Resource servers receiving a JWT access token MUST validate it in the
following manner.
"
Question: If you refer to RFC 6750 and then list the steps are you just
repeating the steps from RFC 6750 or are you augmenting them?
You write:
"
If the JWT access token includes authorization claims as described in
the authorization claims section, the resource server SHOULD use them
in combination with any other contextual information available to
determine whether the current call should be authorized or rejected.
"
Include a reference to the authorization claims section
s/ For more
details on cross-JWT confusion please refer to 2.8 of [RFC8725]./ For more
details on cross-JWT confusion please refer to Section 2.8 of [RFC8725].
You write:
"
Authorization servers should not rely on the use of different keys
for signing OpenID Connect ID Tokens and JWT tokens as a method to
safeguard against the consequences of leaking specific keys.
"
The phrase "leaking keys" is probably not the best term to describe what
follows afterwards in the text.
You write:
"
The client MUST NOT inspect the content of
the access token
"
This RFC 2119 language is not really enforceable in terms of interoperability.
Maybe you could rephrase a bit. Something like the following would work:
"
Authorization server and the resource server
might decide to change token format at any time (for example by
switching from this profile to opaque tokens). Hence, any logic in the
client relying on the ability to read the access token content would
break without recourse. The OAuth 2.0 framework assumes that access tokens
are treated opaque by clients.
Administrators of authorization servers should also take into account that
the content of an access token is visible to the client. Whenever client
access to the access token content presents privacy issues for a
given scenario, the authorization server should take explicit steps
to prevent it.
"
You wrote:
"
In scenarios in which JWT access tokens are accessible to the end
user, it should be evaluated whether the information can be accessed
without privacy violations (for example, if an end user would simply
access his or her own personal information) or if steps must be taken
to enforce confidentiality. Possible measures include: encrypting
the access token, encrypting the sensitive claims, omitting the
sensitive claims or not using this profile, falling back on opaque
access tokens.
"
The first sentence is a repetition of the previous paragraph. I would suggest
to delete
the first sentence in this paragraph and to move the second sentence to the
previous paragraph.
You wrote:
"
This profile mandates the presence of the "sub" claim in every JWT
access token, making it possible for resource servers to rely on that
information for performing tasks such as correlating incoming
requests with data stored locally for the authenticated principal.
Although the ability to correlate requests might be required by
design in many scenarios, there are scenarios where the authorization
server might want to prevent correlation to preserve the desired
level of privacy. Authorization servers should choose how to assign
"sub" values according to the level of privacy required by each
situation. For instance: if a solution requires preventing tracking
principal activities across multiple resource servers, the
authorization server should ensure that JWT access tokens meant for
different resource servers have distinct "sub" values tht cannot be
correlated in the event of resource servers collusion. Similarly: if
a solution requires preventing a resource server from correlating the
principal's activity within the resource itself, the authorization
server should assign different "sub" values for every JWT access
token issued. In turn, the client should obtain a new JWT access
token for every call to the resource server, to ensure that the
resource server receives different "sub" and "jti" values at every
call, thus preventing correlation between distinct requests.
"
The above paragraph suggests that there are different levels of privacy. What
you are
talking about in the text is unlinkability and identification. Ways to deal
with such
privacy threats are described in Section 6 of RFC 6973.
Hence, I would suggest to slightly rephrase the paragraph to something like:
"
This profile mandates the presence of the "sub" claim in every JWT
access token, making it possible for resource servers to rely on that
information for correlating incoming
requests with data stored locally for the authenticated principal.
Although the ability to correlate requests might be required by
design in many scenarios, there are scenarios where the authorization
server might want to prevent correlation. The "sub" claim should be
populated by the authorization servers according to a privacy impact
assessment. For instance, if a solution requires preventing tracking
principal activities across multiple resource servers, the
authorization server should ensure that JWT access tokens meant for
different resource servers have distinct "sub" values that cannot be
correlated in the event of resource servers collusion. Similarly, if
a solution requires preventing a resource server from correlating the
principal's activity within the resource itself, the authorization
server should assign different "sub" values for every JWT access
token issued. In turn, the client should obtain a new JWT access
token for every call to the resource server, to ensure that the
resource server receives different "sub" and "jti" values at every
call, thus preventing correlation between distinct requests.
"
Section 7.2
s/ Section Section 2.2.3.1 of this specification refers to the
attributes "roles", "groups", "entitlements" defined in [RFC7643] to
express authorization information in JWT access tokens.
/ Section 2.2.3.1 of this specification refers to the
attributes "roles", "groups", "entitlements" defined in [RFC7643] to
express authorization information in JWT access tokens.
References
RFC 7519 has to be a normative reference:
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
RFC 7644 is an unused reference:
[RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E.,
and C. Mortimore, "System for Cross-domain Identity
Management: Protocol", RFC 7644, DOI 10.17487/RFC7644,
September 2015, <https://www.rfc-editor.org/info/rfc7644>.
The same is true for RFC 3986:
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
