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 <neil.mad...@forgerock.com> wrote: > > On 9 Feb 2021, at 22:04, Andrii Deinega <andrii.dein...@gmail.com> 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 > > > ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
