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

[Phil Idm Hunt <[e-mail]>]

+1 

This feels like it has similar requirements and concerns as for SET and may be should leverage it to avoid confusion and inconsistencies down the road. 

Phil

> On Sep 4, 2019, at 12:49 PM, Justin Richer <[e-mail]> wrote:
> 
> As I’ve said in the past, I think there is and should be a clear difference between a JWT access token and a JWT-formatted response from any endpoint. It gets extra fuzzy here because the response from the endpoint represents the token being introspected. 
> 
> However, I think they are still two very different things because the introspection response by definition represents what the token was at the time of introspection. That’s why the “active” claim is important here, along with the timestamp information in the JWT container — you can say that the token *was* active at the time of introspection, but you can’t say it’s still active without introspecting the token again to check. This leads to exactly the kind of collision that’s being discussed here. It’s confusing for developers of both the AS and the RS, and I fear it’s going to lead to an AS choosing one interpretation and an RS choosing another, and therefore leaving open a door to security issues down the road.
> 
> Also, remember one of the main reasons that we require some form of RS authentication to the token endpoint is that different RS’s can get different answers for the same token. The AS can tailor its response based on what scopes the RS is supposed to know about, or which RS’s can know a user’s identifier (or even use pairwise identifiers), or even which RS is supposed to know about a given token at all. In each of these cases, using this draft, you’ll get a different JWT out for the same token on the way in. You’re not simply translating an access token to another access token here — if you want to do that, use token exchange and do it properly with an OAuth grant. Instead, you’re getting information about the token itself at the time of the request and from the perspective of the requestor, and you happen to be wrapping the response in a container that is also widely used to format access tokens. 
> 
> The separation that Torsten points out below brings up one of the biggest problems with JWTs as a data container format — all the information about the JWT itself is mixed in with the thing it’s carrying information about. We see this issue with JAR, where the “aud” parameter can mean the audience of the authorization request and the audience of the JWT used to carry the authorization request. We also see this a little bit in dynamic client registration’s software statement. Root-level JWT claims are a poor mechanism for this.
> 
> In retrospect, what I wish we’d done with all of them using a named payload like with SET’s “event” claim. Even there, we had a lot of argument about a “sub” claim inside the “event” object vs. one at the root of the JWT container, but at least in these cases  we now had an opportunity to write clear language about what each meant in each circumstance. I realize this draft is already well along in its process, and I haven’t put in the review time or comments to date myself, but I think it’s unfortunate that the draft doesn’t define a sub-claim like “access_token” or “token_information” to carry inside the JWT payload. This would solve the problem of differentiating the “iat” for the token itself vs. the JWT container of the response.
> 
> The group may also recall that I originally said that this draft should not be done in light of only introspection, and instead should be a generic mechanism across OAuth’s various endpoints. Weird combinations like the “iat” claim here are a driver for having a solid generic mechanism instead of a handful of slightly different definitions. 
> 
> So what should we do here? If we are to keep the current practice of putting everything in the root of the JWT, we should have different claim names to differentiate the envelope and the token. The problem here is that “iat” is already defined in RFC7662 as referring to the token and in RFC7519 as referring to the JWT (which is not a token, but the container for the token information). I’m not sure which is worse, defining an “iat” for the introspection response or one for the JWT but only in this instance. Both feel really messy, and in cases like Torsten’s they collapse to the same value.
> 
> If however we put the introspection response in its own sub-section of the JWT payload, then we could avoid the namespace collision entirely. We would need normative rules like in SET to define how these fields relate to each other, but I see that as a tractable problem with a reasonable (if imperfect) precedent. 
> 
> Either path means redoing WGLC and the associated reviews, I’m afraid. Leaving it as-is works for the driving use case where the information is all the same, but I don’t find it to be a particularly clean representation of the information in question.
> 
> — Justin
> 
>> On Sep 4, 2019, at 5:21 AM, Torsten Lodderstedt <[e-mail]> wrote:
>> 
>> Hi Remco,
>> 
>>> On 31. Aug 2019, at 21:27, Schaar, R.M. (Remco) - Logius <[e-mail]> wrote:
>>> 
>>> Hello Torsten,
>>> 
>>> (my apologies for making a typo previously)
>> 
>> Thanks :-)
>> 
>>> 
>>> 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.
>> 
>> That’s a good point.  
>> 
>>> 
>>> 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”.
>> 
>> I'm meanwhile leaning towards "the response is returned in JWT format”.
>> 
>>> 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.
>> 
>> I’m not sure how an attacker could replay an introspection response given it is tighted to a certain endpoint via the iss claim. 
>> 
>> I agree the RS lacks a way to proof when it was provided with the access token data by the AS. 
>> 
>> The problem in my opinion is the overlay between the original access token data (e.g. when was it issued by the AS) and the data belonging to the representation in the introspection response (when was the response created). Conceptually, this means we require two separat “iat" (alike) claims to distinguish both aspects. 
>> 
>> I could image two ways to handle this:
>> - add another iat claim, e.g. “tir_iat", to the JWT
>> - add another “iat" claim to the JWS header containing the instant when the token introspection response was created
>> 
>> What do you think?
>> 
>> best regards,
>> Torsten. 
>> 
>>> 
>>> Kind regards,
>>> Remco schaar
>>> 
>>> -----Oorspronkelijk bericht-----
>>> Van: Torsten Lodderstedt <[e-mail]> 
>>> Verzonden: woensdag 28 augustus 2019 11:14
>>> Aan: Schaar, R.M. (Remco) - Logius <[e-mail]>
>>> CC: [e-mail]
>>> Onderwerp: Re: [OAUTH-WG] Question regarding draft-ietf-oauth-jwt-introspection-response-05
>>> 
>>> Hi Rhemco,
>>> 
>>>> On 26. Aug 2019, at 09:42, Schaar, R.M. (Remco) - Logius <[e-mail]> wrote:
>>>> 
>>>> 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.
>>> 
>>> 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”.
>>> 
>>>> 
>>>> 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.
>>> 
>>> Why is this time critical?
>>> 
>>>> In particular when combined with revocation, the time of
>>>> introspection and the 'active' status can differ between two subsequent calls
>>>> for introspection.
>>> 
>>> 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. 
>>> 
>>>> 
>>>> 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.
>>> 
>>> “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. 
>>> 
>>>> Similar, not including a unique 'jti' per introspection response would make
>>>> 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
>>>> 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.
>>> 
>>> As I described above, I don’t see any difference. 
>>> 
>>>> 
>>>> 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.
>>> 
>>> See above - I don’t see any issue. 
>>> 
>>>> 
>>>> 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.
>>> 
>>> That’s all possible within the current text. 
>>> 
>>> kind regards,
>>> Torsten 
>>> 
>>>> 
>>>> Kind regards,
>>>> Remco Schaar
>>>> 
>>>> -----Oorspronkelijk bericht-----
>>>> Van: Torsten Lodderstedt <[e-mail]> 
>>>> Verzonden: zaterdag 17 augustus 2019 14:00
>>>> Aan: Schaar, R.M. (Remco) - Logius <[e-mail]>
>>>> CC: [e-mail]
>>>> 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 <[e-mail]> wrote:
>>>>> 
>>>>> Hello,
>>>> 
>>>> [...]
>>>> 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.
>>>> 
>>>> [...]
>>>> 
>>>>> 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.
>>>> 
>>>>> 
>>>>> 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.
>>>> 
>>>> 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. 
>>>> 
>>>> 
>>>> 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.
>>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=0_FcucFstqzt0Hyr3ivbMX8i4a2La24tYRek5n-Xgvs&s=LTwDtpeHVz9jDIok9JOtN6dd1TS4i-3VoZLPdt6L2Ns&e=