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

From: Andrii Deinega <[email-masked]>
Date: Wed, 17 Mar 2021 22:33:35 -0700

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

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

---

From: Neil Madden <[email-masked]>
Date: Thu, 18 Mar 2021 07:44:48 +0000

> On 18 Mar 2021, at 05:33, Andrii Deinega <[email-masked]> wrote:
> 
> 
> 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.

This quote is about privacy. Your concerns so far have been about replay protection. TLS protects both. 

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

Right, but (as I’ve said before) the same reasoning applies to a JWT too. The infrastructure could just as easily “terminate JWS” as it currently terminates TLS. As I keep saying, it’s much better to spend your time ensuring end-to-end TLS than end-to-end JWT. We should try to avoid writing specs just to work around badly configured infrastructure. 

(The counterexample to this is IoT applications, where messages often have to traverse protocol-translating proxies. But that’s not the case here).

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

The only justification of the replay nonce given in RFC8555 is for protection of 0RTT early-data (which does not benefit from TLS’s normal replay protections). As to why a protocol that can typically tolerate latencies of several weeks (for cert renewal) needs 0RTT, you’ll have to ask the authors of that RFC. It makes little sense to me. 

— Neil

--

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 18 Mar 2021 07:33:27 -0400

On Thu, Mar 18, 2021 at 3:45 AM Neil Madden <[email-masked]>
wrote:

> Right, but (as I’ve said before) the same reasoning applies to a JWT too.
> The infrastructure could just as easily “terminate JWS” as it currently
> terminates TLS. As I keep saying, it’s much better to spend your time
> ensuring end-to-end TLS than end-to-end JWT.
>

That's not always possible. In some enterprises, they will have an
inspection middlebox that breaks the end-to-end TLS, e.g., ZScaler.

Regards,
 Rifaat

> We should try to avoid writing specs just to work around badly configured
> infrastructure.
>
> (The counterexample to this is IoT applications, where messages often have
> to traverse protocol-translating proxies. But that’s not the case here).
>
>
> As for,
>
> The only justification of the replay nonce given in RFC8555 is for
> protection of 0RTT early-data (which does not benefit from TLS’s normal
> replay protections). As to why a protocol that can typically tolerate
> latencies of several weeks (for cert renewal) needs 0RTT, you’ll have to
> ask the authors of that RFC. It makes little sense to me.
>
> — Neil
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Neil Madden <[email-masked]>
Date: Thu, 18 Mar 2021 12:07:11 +0000

> On 18 Mar 2021, at 11:33, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> On Thu, Mar 18, 2021 at 3:45 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 18 Mar 2021, at 05:33, Andrii Deinega <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
> Right, but (as I’ve said before) the same reasoning applies to a JWT too. The infrastructure could just as easily “terminate JWS” as it currently terminates TLS. As I keep saying, it’s much better to spend your time ensuring end-to-end TLS than end-to-end JWT. 
> 
> That's not always possible. In some enterprises, they will have an inspection middlebox that breaks the end-to-end TLS, e.g., ZScaler.

And if you use encrypted JWTs to work around that you’ll soon have inspection middleboxes that break end-to-end JWT. This isn’t a game we can win by adding more layers of the same solution.

— Neil

---

From: Warren Parad <[email-masked]>
Date: Thu, 18 Mar 2021 13:25:00 +0100

💯

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.

On Thu, Mar 18, 2021 at 1:07 PM Neil Madden <[email-masked]>
wrote:

>> The Cache-Control header, even with its strongest directive "no-store",
>> is pretty naive protection... Below is an excerpt from RFC 7234 (Hypertext
> And if you use encrypted JWTs to work around that you’ll soon have
> inspection middleboxes that break end-to-end JWT. This isn’t a game we can
> win by adding more layers of the same solution.
>
> — Neil
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 18 Mar 2021 08:28:39 -0400

> win by adding more layers of the same solution.

I do not know the right solution in this case. All I was trying to say is
that you cannot always assume that you are guaranteed end-to-end TLS.

Regards,
 Rifaat