Greetings, and Happy New Year! I was just re-reading the OAuth 2.0 token introspection RFC 7662, and I am a bit confused by the rationale for requiring client (RS) authentication when making calls to this endpoint. The stated rationale in Section 2.1 (https://tools.ietf.org/html/rfc7662#page-5) is:
“To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750].” This rationale is elaborated in the Security Considerations: "If left unprotected and un-throttled, the introspection endpoint could present a means for an attacker to poll a series of possible token values, fishing for a valid token. To prevent this, the authorization server MUST require authentication of protected resources that need to access the introspection endpoint and SHOULD require protected resources to be specifically authorized to call the introspection endpoint.” However, RFC 6749 already requires that access tokens be unguessable with a probability of successful guesses being at most 2^(-128) [https://tools.ietf.org/html/rfc6749#section-10.10]. Assuming that this means something like: if an attacker makes 2^n guesses then they have a maximum chance of guessing a particular access token of at most 2^(n-128), then I think the token scanning attacks are already taken care of aren’t they? It is not feasible for an attacker to make that many queries. Even if you consider that the attacker only needs to guess one out of the set of all valid access tokens, then I still don’t think this attack is feasible in any realistic time-frame, especially if you follow the “SHOULD" recommendation to require at most 2^(-160) probability. Is there some other threat model being considered here? Timing side-channels maybe? Also, I cannot find a justification in the RFC for how this threat is mitigated by requiring authentication. Is the assumption that this is a closed ecosystem where malicious parties cannot get valid credentials? Kind regards, Neil -- Neil Madden Security Director, ForgeRock Engineering. Email: neil.mad...@forgerock.com PGP: 90F8 43DF 4EDD AC5D Bugs/Reports: secur...@forgerock.com PGP: 6D19 AD77 1F43 ADAD _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
