Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and nonce

[Andrii Deinega <[e-mail]>]

I still don't see how your #1 and #3 points mitigate the replay attack when
an attacker somehow eavesdrops a successful response from an AS (yes, it's
signed by a public key) and then starts to replay it for other requests
from the same client.

The main problem here is that the client doesn't have a way to correlate
the introspection response with the initial introspection request.

Regarding #2, it's true that there are many proxies that do this and that.
In practice, you don't always have control over the infrastructure where
you may run your AS as I was saying before.

Regards,
Andrii


On Tue, Feb 9, 2021 at 1:30 PM Neil Madden <[e-mail]>
wrote:

> Three points:
>
> 1. In many cases the JWT will be verified using a public key fetched over
> the same TLS channel.
>
> 2. Many proxies can now also produce and consume JWTs for downstream
> services, so end-to-end JWT is no more guaranteed than end-to-end TLS.
>
> 3. The JWT response already contains an iat claim which is sufficient to
> judge freshness.
>
> It would be better to concentrate on ensuring end-to-end TLS rather than
> trying to reinvent the same mechanisms in JWT form on top.
>
> — Neil
>
> On 9 Feb 2021, at 20:38, Andrii Deinega <[e-mail]> wrote:
>
> 
> How can you guarantee that there are always direct TLS connections between
> a client and an AS hosted say some cloud provider where you have a little
> control on their infrastructure?
>
> Even without all those cloud providers, how can you guarantee the same
> when there are a bunch of different (software and hardware) components that
> legitimately perform SSL offloading / DPI in front of an AS...  or the
> client may just use the proxy server?
>
> Regards,
> Andrii
>
> On Tue, Feb 9, 2021 at 12:43 AM Neil Madden <[e-mail]>
> wrote:
>
>> On 9 Feb 2021, at 06:55, Andrii Deinega <[e-mail]> wrote:
>>
>>
>> 
>> Hi WG,
>>
>> I wonder if there are any particular reasons to not make nonce a
>> mandatory parameter for the current JWT Response for OAuth Token
>> Introspection draft. Or, at least, force an AS to include the nonce claim
>> in a JWT response when nonce is presented in the introspection request
>> similar to what happens with the similar scenario in the OpenID Connect ID
>> Token?
>>
>>
>> https://openid.net/specs/openid-connect-core-1_0.html#:~:text=If%20present%20in%20the%20Authentication%20Request%2C,value%20sent%20in%20the%20Authentication%20Request.
>>
>> This will allow to mitigate replay attacks because clients can correlate
>> the response with the initial request
>>
>>
>> ID tokens involve flows using an insecure channel (the browser). This is
>> not the case for introspection requests which happen over a direct TLS
>> connection and so are already protected against replay attacks.
>>
>> — Neil
>>
>> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
>
>
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>