Subject: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05

From: "Schaar, R.M. (Remco) - Logius" <[email-masked]>
Date: Tue, 6 Aug 2019 14:01:59 +0000

Hello,

I would like to request the OAuth2 working group on a clarification for introspection, in particular regarding the semantics of the 'jti' and 'aud' claims. The draft 'JWT Response for OAuth Token Introspection' seems ambiguous in relation to RFC7662 and RFC7519. In particular sections 3 and 6.1 cause this ambiguity.

RFC7662 specifies the 'aud' and 'jti' parameters in relation to "for the token". Note that the wording in RFC7662 is somewhat implicit, we assume "the token" is the (access) token being introspected.
RFC7519 specifies the 'aud' and 'jti' parameters in relation to the JWT itself. The token in the context of RFC7519 is the JWT containing the parameters.

The draft (draft-ietf-oauth-jwt-introspection-response-05) now formulates the response to an introspection as a JWT. The content of the JWT "MAY furthermore contain all claims defined in RFC7662". Now this raises the question to the meaning of the 'aud' and 'jti' parameters.

In line with RFC7519 the parameters would define a value for the introspection response. On the other hand following RFC7662 for the definition would define the value of the parameters as those of the introspected token.

Now for the 'aud' parameter this will typically only be an issue with multiple values for the audience. In the case of a single intended audience the audience of the introspected (access) token will normally be the same principal as the audience of the introspection response JWT. Only for some use cases the value of 'aud' may end up ambiguous.
The 'jti' parameter however will always be ambiguous. As it is an identifier, it should differ for the introspected token and the introspection response by definition. Hence the semantics of 'jti' in a JWT introspection response is unclear. The same can apply to the 'iat', 'nbf' and 'exp' claims in a JWT introspection response.

Can someone clarify the semantics of claims in an introspection response JWT that are defined in both RFC7662 and RFC7519?

Furthermore, the introspection response should use the 'iss' and 'aud' claims to avoid cross-JWT confusion (section 6.1). The 'iss' and 'aud' of an introspected token will typically be the same as those of the introspection response. Hence a JWT access token cannot be distinguished from an introspection response using 'iss' and 'aud' as suggested in the draft.

Introspection refers to JWT best-current-practice. The draft BCP recommends using explicit typing of JWTs, however the draft JWT response for introspection does not apply this recommendation and uses the generic 'application/jwt' instead... The BCP has other recommendations in section 3.12, but these may be insufficient to distinguish a JWT access token from a JWT introspection response.

How would people suggest to best distinguish a JWT (access) token from a JWT introspection response?

Thank you in advance for your response.

Kind regards,
Remco Schaar
Logius
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Aug 2019 13:59:48 +0200

Hi Remco,

> On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius <[email-masked]> wrote:
> 
> Hello,
>  
> I would like to request the OAuth2 working group on a clarification for introspection, in particular regarding the semantics of the ‘jti’ and ‘aud’ claims. The draft ‘JWT Response for OAuth Token Introspection’ seems ambiguous in relation to RFC7662 and RFC7519. In particular sections 3 and 6.1 cause this ambiguity.
>  
> RFC7662 specifies the ‘aud’ and ‘jti’ parameters in relation to “for the token”. Note that the wording in RFC7662 is somewhat implicit, we assume “the token” is the (access) token being introspected.
> RFC7519 specifies the ‘aud’ and ‘jti’ parameters in relation to the JWT itself. The token in the context of RFC7519 is the JWT containing the parameters.
>  
> The draft (draft-ietf-oauth-jwt-introspection-response-05) now formulates the response to an introspection as a JWT. The content of the JWT “MAY furthermore contain all claims defined in RFC7662”. Now this raises the question to the meaning of the ‘aud’ and ‘jti’ parameters.
>  

RFC 7519 and RFC 7662 “just” define different representations for token data. In RFC 7519 the data is carried in the token itself (which also means the format of the token is well-defined and know to the RS) whereas RFC 7662 defines a way to inspect tokens via an API provided by the AS. The latter is typically used in conjunction with opaque tokens, i.e. the RS does not have a clue how to parse and interpret the token. The token might just be a handle to a database entry at the AS in this case. 

This also means a JWT (RFC 7662) and the Introspection Response are conceptually the same from a RSs perspective.

>  
> Now for the ‘aud’ parameter this will typically only be an issue with multiple values for the audience. In the case of a single intended audience the audience of the introspected (access) token will normally be the same principal as the audience of the introspection response JWT. Only for some use cases the value of ’aud’ may end up ambiguous.

It should not. At most the RS must turn up in the list of the legit recipient. At best the aud value is always the RS only (see https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-3.8.1.3) . 

> The ‘jti’ parameter however will always be ambiguous. As it is an identifier, it should differ for the introspected token and the introspection response by definition. Hence the semantics of ‘jti’ in a JWT introspection response is unclear. The same can apply to the ‘iat’, ‘nbf’ and ‘exp’ claims in a JWT introspection response.

I don’t understand the difference you are making. All before mentioned claims are related to the (abstract) access token. You may think of the Introspection Response as _the_ JWT representation of the access token produced by the AS for the RS.

> Furthermore, the introspection response should use the ‘iss’ and ‘aud’ claims to avoid cross-JWT confusion (section 6.1). The ‘iss’ and ‘aud’ of an introspected token will typically be the same as those of the introspection response. Hence a JWT access token cannot be distinguished from an introspection response using ‘iss’ and ‘aud’ as suggested in the draft..
>  
> Introspection refers to JWT best-current-practice. The draft BCP recommends using explicit typing of JWTs, however the draft JWT response for introspection does not apply this recommendation and uses the generic ‘application/jwt’ instead... The BCP has other recommendations in section 3.12, but these may be insufficient to distinguish a JWT access token from a JWT introspection response.

Good point. The reason why the BCP recommends explicit typing is to prevent replay in other contexts. In the end typing is a compelling concept unfortunately not broadly used in the wild.

So the JWT Introspection Response draft copes with that attack angle by making iss and aud mandatory. 

> How would people suggest to best distinguish a JWT (access) token from a JWT introspection response?

Why should you? One reason why we extended the Introspection Response was to eliminate the difference between JWTs directly used as access tokens and Introspection Responses.

best regards,
Torsten. 

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

---

From: "Schaar, R.M. (Remco) - Logius" <[email-masked]>
Date: Mon, 26 Aug 2019 07:42:51 +0000

Hello Thorsten,

Thank you for your response. I have a few more questions/comments as
follow-up...

You state that RFC7519 and RFC7662 "just" define different representations
for token data. If the draft RFC would refer to RFC 7515 (JWS), I would
agree. However, RFC7519 (JWT) explicitly adds semantics to some specific
parameters (e.g. aud, jti and iat). RFC7662 has different semantics for
the several of the same parameters.
For instance the 'iat', is the moment of issuance of the JWT in RFC7519. In
RFC7662 that is the "when this token was originally issued". This time will
vary in use cases without immediate introspection of an access token.

For the use case of the resource server relying on verifiable data, as
described in the introduction of the draft RFC, the time of the introspection
is critical. In particular when combined with revocation, the time of
introspection and the 'active' status can differ between two subsequent calls
for introspection.

If the draft RFC just produces a JWT representation of the access token,
including 'active' would not make sense as the JWT will expire without
updating it to false. Leaving 'active' out would make it incompatible with
RFC7662 introspection responses.
Similar, not including a unique 'jti' per introspection response would make
the resource server vulnerable to replay attacks. Or the resource server
would mistakenly refer to non-unique tokens, making the responses unsuitable
for accountability and audit purposes.

As to why someone would want to distinguish a JWT access token from an
introspection response: several use cases come to mind.

First of all, even if one is using standalone interpretable JWT access tokens,
one may want to combine that with revocation checking using introspection. The
interpretation and meaning of the JWT and the introspection response than do
differ and matter.

Another use case would be a mixed ecosystem with resource servers relying on
introspection while others do parse JWT access tokens. A single, uniform
implementation for the AS would than mix both as well.

A last use case could be exchanging access tokens with a subset of the full
set of applicable parameters, to reduce the size of access tokens. Additional
information can be exchanged via introspection, resulting in mixed JWT access
tokens and introspection as well.

Kind regards,
Remco Schaar

-----Oorspronkelijk bericht-----
Van: Torsten Lodderstedt <[email-masked]> 
Verzonden: zaterdag 17 augustus 2019 14:00
Aan: Schaar, R.M. (Remco) - Logius <[email-masked]>
CC: [email-masked]
Onderwerp: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05

Hi Remco,

> On 6. Aug 2019, at 16:01, Schaar, R.M. (Remco) - Logius <[email-masked]> wrote:

[...]

[...]

best regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 28 Aug 2019 11:13:59 +0200

Hi Rhemco,

> On 26. Aug 2019, at 09:42, Schaar, R.M. (Remco) - Logius <[email-masked]> wrote:
> 
> Hello Thorsten,
> 

I read the text differently. In my interpretation “when the token was originally issued” stated from the perspective of the introspection endpoint refers exactly to the same instant as “the time at which the JWT was
   issued”.

> is critical.

Why is this time critical?

> In particular when combined with revocation, the time of

The status at token introspection request time is indeed critical. RFC 7662 gives a good indication how this value should be calculated.

“… a "true"
      value return for the "active" property will generally indicate
      that a given token has been issued by this authorization server,
      has not been revoked by the resource owner, and is within its
      given time window of validity (e.g., after its issuance time and
      before its expiration time)." 

So it represents the results of the issuer check, the revocation check and the validity check in one boolean value. 

> RFC7662 introspection responses.

“active” is not part of the JWT representation I referred to. The AS needs to determine the active value for every token introspection request. 

If the RS would consume JWTs, it would determine the “active” value itself by inspecting the iss claim and check against its AS whitelist, check the signature and the iat & exp values. Determining the revocation status would require an information exchange with the AS of some sort. 

> the resource server vulnerable to replay attacks.

To the contrary, including a different “jit" with every token introspection response would make the RS vulnerable to replay of one time access token since it remove the possibility for the RS to identity a certain access token. 

> Or the resource server

As I described above, I don’t see any difference. 

> implementation for the AS would than mix both as well.

See above - I don’t see any issue. 

> tokens and introspection as well.

That’s all possible within the current text. 

kind regards,
Torsten

---

From: "Schaar, R.M. (Remco) - Logius" <[email-masked]>
Date: Sat, 31 Aug 2019 19:27:35 +0000

Hello Torsten,

(my apologies for making a typo previously)

Time of introspection is critical if you want to use the signed introspection
response for later accountability or audit purposes. For example, a Client
obtains an access token A at time t. Now a resource server receives A at time
t+1, calls introspection and receives a response containing active=true. At
t+2 the acccess token is revoked. At time t+3 the resource server makes a new
introspection request, now receives a response containing active=false. The
only difference would be the value of the active parameter. Without the time
of introspection nor a unique id covered by the signature, one cannot make a
conclusive distinction between subsequent responses if revocation may be in
play.

The draft specifies 
       [...] to return responses as JWTs.
This could either mean "the response is returned in JWT format" or "the
response contains a JWT representation of the inspected token". Not having
clear, separate parameters to distinguish between the time and id of the
token and the time and id of the response results in double meaning. As a
consequence, it is either having the risk of replay of an access token or
replay of an introspection response instead of neither.

Kind regards,
Remco schaar

-----Oorspronkelijk bericht-----
Van: Torsten Lodderstedt <[email-masked]> 
Verzonden: woensdag 28 augustus 2019 11:14
Aan: Schaar, R.M. (Remco) - Logius <[email-masked]>
CC: [email-masked]
Onderwerp: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05

Hi Rhemco,

“… a "true"

kind regards,
Torsten