On 02/01/18 19:01, Neil Madden wrote: > How does authentication address the problem? Authentication increases the effective entropy. An attacker fist has to be break the client secret, then successfully guess the token.
Vladimir > > 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 > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
