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

[Andrii Deinega <[e-mail]>]

The Cache-Control header, even with its strongest directive "no-store", is
pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext
Transfer Protocol: Caching).

This directive is NOT a reliable or sufficient mechanism for ensuring
> privacy.  In particular, malicious or compromised caches might not
> recognize or obey this directive, and communications networks might be
> vulnerable to eavesdropping.


Regarding TLS, I've mentioned that we don't always have the luxury to see
what is going on with the infrastructure. A bright example would be an AS
implemented as a serverless application and hosted by one of the cloud
providers.

As for,

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.


Following your logic, other RFCs such as 8555 (Automatic Certificate
Management Environment) went the wrong way with their mandatory anti-replay
built-in mechanism in quite similar circumstances.

https://tools.ietf.org/html/rfc8555#section-6.5

Regards,
Andrii


On Fri, Feb 12, 2021 at 12:09 AM Neil Madden <[e-mail]>
wrote:

>
> On 11 Feb 2021, at 21:43, Andrii Deinega <[e-mail]> 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
> <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).
>
>
> 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
>
>
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>