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 <neil.mad...@forgerock.com> wrote: > > On 11 Feb 2021, at 21:43, Andrii Deinega <andrii.dein...@gmail.com> 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>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
