The requirement on 128-bit entropy is a MUST in RFC 6749. There is a SHOULD for the stronger 160-bit level. How does authentication address the problem?
Neil > On 2 Jan 2018, at 15:06, John Bradley <ve7...@ve7jtb.com> wrote: > > In reality people developers may not always be putting that much entropy into > a token. It is only a SHOULD and hard to enforce. I may have come up with > the min entropy number. > > There may also be side channel attacks if you allow introspection of > encrypted or signed tokens. > > There is also a potential privacy issue if you return a bunch of PII in the > token response. If the token leaked it perhaps can’t be used if it isa POP > token but you may still leak PII via introspection. > > In general I am not a big fan of introspection. We didn’t include it in > Connect. However the pattern is used in a number of commercial products to > have the RS introspect tokens at the AS. > It was decided by the WG that having a standard would reduce the number of > things people need to support when you have things like a DataPower talking > to Ping Fed or something like that. > > Given that this is mostly used by RS I think the decision was made to err on > the side of caution, as authentication is not a huge burden. > I recall it being discussed and some people didn’t want to do authentication. > > It is not cut and perhaps in some cases it might not be required, however > that would introduce a option that people may get wrong in implementations. > > Happy New Year > John B. > >> On Jan 2, 2018, at 9:42 AM, Neil Madden <neil.mad...@forgerock.com> wrote: >> >> 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 >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
