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

From: Andrii Deinega <[email-masked]>
Date: Mon, 8 Feb 2021 22:55:27 -0800

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.

Regards,
Andrii

---

From: Neil Madden <[email-masked]>
Date: Tue, 9 Feb 2021 08:43:53 +0000

On 9 Feb 2021, at 06:55, Andrii Deinega <[email-masked]> 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?
> 
> 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>

---

From: Andrii Deinega <[email-masked]>
Date: Tue, 9 Feb 2021 12:38:12 -0800

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 <[email-masked]>
wrote:

> 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
>

---

From: Neil Madden <[email-masked]>
Date: Tue, 9 Feb 2021 21:29:59 +0000

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 <[email-masked]> 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 <[email-masked]> wrote:
>> ForgeRock values your Privacy

---

From: Andrii Deinega <[email-masked]>
Date: Tue, 9 Feb 2021 14:03:53 -0800

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 <[email-masked]>
wrote:

> 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.
>
> 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
>
> Even without all those cloud providers, how can you guarantee the same
> when there are a bunch of different (software and hardware) components that
>> 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?
>>
>>

---

From: Neil Madden <[email-masked]>
Date: Wed, 10 Feb 2021 08:15:49 +0000

> On 9 Feb 2021, at 22:04, Andrii Deinega <[email-masked]> wrote:
> 
> 
> 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 point of #1 is that an attacker that has compromised the communication channel between the AS and client can do much more than replay introspection responses. In particular they can replace the AS’s public key with their own and then sign their own introspection JWTs, with whatever nonce in them that they like (they can easily see the nonce in the request). 

They can also steal access tokens and almost certainly also steal user session cookies and manipulate authorization responses from users to change the scopes that are approved for different requests. 

It’s absolutely essential that ASs and clients ensure the TLS connection between them is secure. 

The stated purpose of JWT introspection responses is for non-repudiation. It’s not intended as a replacement for TLS. Within that context “iat” is sufficient proof of freshness. 

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

In a properly secured environment this guaranteed by TLS (and even TCP). 

> 
> 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.

Right - so trying to solve this issue by replacing TLS with another technology that is just as susceptible to the problem is not a real solution. 

— Neil

---

From: Andrii Deinega <[email-masked]>
Date: Thu, 11 Feb 2021 13:42:53 -0800

Thank you for the response! Unfortunately, I'm still not convinced that
there is no need for nonce.

Based on the draft, I don't know how it's possible to achieve a “stronger
assurance that the authorizationserver issued the token introspection
response for an access token, includingcases where the authorization server
assumes liability for the content of thetoken introspection response
<https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-10#legend:~:text=there%20are,server%20issued%20the%20token%20introspection%20response>”
if we can't guarantee that a client will always get the response to its
initial introspect request, or in other words, old communications can be
never reused (the iat claim isn't going to be sufficient for that).

Let's put aside those attackers for a moment and say we experience some
awfully wrong caching issues that can happen anywhere between an AS and a
client... where the client gets a cached response for its previous requests
which isn't expected. How can it be prevented?

Regards,

Andrii

On Wed, Feb 10, 2021 at 12:15 AM Neil Madden <[email-masked]>
wrote:

> 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 point of #1 is that an attacker that has compromised the communication
> channel between the AS and client can do much more than replay
> introspection responses. In particular they can replace the AS’s public key
> with their own and then sign their own introspection JWTs, with whatever
> nonce in them that they like (they can easily see the nonce in the
> request).
>
> They can also steal access tokens and almost certainly also steal user
> session cookies and manipulate authorization responses from users to change
> the scopes that are approved for different requests.
>
> The stated purpose of JWT introspection responses is for non-repudiation.
> It’s not intended as a replacement for TLS. Within that context “iat” is
> sufficient proof of freshness.
>
>
> Right - so trying to solve this issue by replacing TLS with another
> technology that is just as susceptible to the problem is not a real
> solution.
>
> — Neil
>
>

---

From: Neil Madden <[email-masked]>
Date: Fri, 12 Feb 2021 08:09:05 +0000

> On 11 Feb 2021, at 21:43, Andrii Deinega <[email-masked]> wrote:
> 
> 
> Thank you for the response! Unfortunately, I'm still not convinced that there is no need for nonce.
>  
> Based on the draft, I don't know how it's possible to achieve a “stronger assurance that the authorizationserver issued the token introspection response for an access token, includingcases where the authorization server assumes liability for the content of thetoken introspection response” if we can't guarantee that a client will always get the response to its initial introspect request, or in other words, old communications can be never reused (the iat claim isn't going to be sufficient for that).

The whole point about liability is being able to establish it after the fact. A nonce is only meaningful within the initial interaction and so is no help at all for establishing liability. 

>  
> Let's put aside those attackers for a moment and say we experience some awfully wrong caching issues that can happen anywhere between an AS and a client... where the client gets a cached response for its previous requests which isn't expected. How can it be prevented?

1. TLS. 2. Cache-Control. 

— Neil