[OAUTH-WG] Token scanning attacks in RFC 7662
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
Re: [OAUTH-WG] Token scanning attacks in RFC 7662
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 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 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Interim Meetings Doodle Poll
Happy New Year! This is a reminder about our plan for an interim meeting during the Jan 15-19 week. Please, take a look and sign up if you are interested in these topics. Regards, Rifaat & Hannes On Wed, Dec 13, 2017 at 2:52 PM, Rifaat Shekh-Yusef wrote: > All, > > We are looking to schedule *two* Virtual Interim Meetings to discuss the > *Distributed > OAuth* and *"Mutual" OAuth* documents presented by Dick in Singapore. > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ > https://datatracker.ietf.org/doc/draft-hardt-oauth-mutual/ > > It is a real challenge to try to schedule such a meeting that takes into > considerations all the various time zones. > The following Doodle Poll has the time-slots that we thought would be > somewhat reasonable: > https://doodle.com/poll/erqrc75gtcmdgtru#table > > Please, take a look and let us know if you have any comments and choose > the best time-slot that works for you. > > Regards, > Rifaat & Hannes > > > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token scanning attacks in RFC 7662
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 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 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
Re: [OAUTH-WG] Token scanning attacks in RFC 7662
If you're interested in examples in the wild of token introspection without client authentication, Google offers one and specifically recommends that JS clients (which are public clients and thus can't use client authentication) use it to mitigate confused deputy attacks on access tokens. Documented here: https://developers.google.com/identity/protocols/OAuth2UserAgent#validate-access-token (section 5, select the "OAuth 2.0 Endpoints" tab). The endpoint doesn't follow the spec precisely, as it pre-dated it, but it's pretty close. Regarding that "MUST require authentication", it does seem like there are other mitigations, including ones that the text eludes to (e.g. throttling, high entropy, etc). I actually advocated for a watering down of the MUST at IETF 93, but by then the document was too advanced along the publishing process for chances to be considered. I gathered the intended use-case of the spec was more for resource server rather than client introspection (though I expressed a view that it could be expanded to cover both since it was so close). On Tue, Jan 2, 2018 at 9:01 AM, Neil Madden wrote: > 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 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 > 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 > c
Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
On Fri, Dec 15, 2017 at 11:12 PM, Vladimir Dzhuvinov < vladi...@connect2id.com> wrote: > On 15/12/17 00:43, William Denniss wrote: > > On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov < > vladi...@connect2id.com > >> wrote: > >> Hi, > >> > >> I just got a question on Twitter about the slow_down error: > >> > >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07#section-3.5 > >> > >> The question was why slow_down is communicated via HTTP status code 400 > >> and not 429 (Too Many Requests). > >> > > We could, it seems to match the intent of that error code. Main reason > it's > > not like that so far is that 400 is the default for OAuth, I fear people > > may not be checking for a 429. We don't strictly *need* the 429, since > > we're returning data in machine readable format one way or another (i.e. > > it's easy for the client to extract the "slow_down" response either way), > > which differs from HTML over HTTP which is intended for end-user > > consumption, making the specific status code more important. > Yes, on a 400 clients will need to check the error JSON object anyway, > so the "slow_down" cannot be missed. Whereas with 429 that becomes more > likely. > > +1 to return "slow_down" with status 400 as it is with the other OAuth > error codes. > Thanks for considering this Vladimir. To conclude this topic, it seems there are no compelling reasons to change to the 429, and a reasonable explanation of why it's a 400, so I think we should keep things as-is. Rifaat: The deadline has passed on the WGLC, and I believe all comments raised have been addressed. Can we now advance the draft? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
William, I will start working on the write-up soon. Regards, Rifaat On Tue, Jan 2, 2018 at 4:07 PM, William Denniss wrote: > > On Fri, Dec 15, 2017 at 11:12 PM, Vladimir Dzhuvinov < > vladi...@connect2id.com> wrote: > >> On 15/12/17 00:43, William Denniss wrote: >> > On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov < >> vladi...@connect2id.com >> >> wrote: >> >> Hi, >> >> >> >> I just got a question on Twitter about the slow_down error: >> >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07# >> section-3.5 >> >> >> >> The question was why slow_down is communicated via HTTP status code 400 >> >> and not 429 (Too Many Requests). >> >> >> > We could, it seems to match the intent of that error code. Main reason >> it's >> > not like that so far is that 400 is the default for OAuth, I fear people >> > may not be checking for a 429. We don't strictly *need* the 429, since >> > we're returning data in machine readable format one way or another (i.e. >> > it's easy for the client to extract the "slow_down" response either >> way), >> > which differs from HTML over HTTP which is intended for end-user >> > consumption, making the specific status code more important. >> Yes, on a 400 clients will need to check the error JSON object anyway, >> so the "slow_down" cannot be missed. Whereas with 429 that becomes more >> likely. >> >> +1 to return "slow_down" with status 400 as it is with the other OAuth >> error codes. >> > > Thanks for considering this Vladimir. To conclude this topic, it seems > there are no compelling reasons to change to the 429, and a reasonable > explanation of why it's a 400, so I think we should keep things as-is. > > Rifaat: The deadline has passed on the WGLC, and I believe all comments > raised have been addressed. Can we now advance the draft? > > ___ > 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
Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
On Jan 2, 2018, at 4:08 PM, William Denniss mailto:wdenn...@google.com>> wrote: On Fri, Dec 15, 2017 at 11:12 PM, Vladimir Dzhuvinov mailto:vladi...@connect2id.com>> wrote: On 15/12/17 00:43, William Denniss wrote: > On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov > mailto:vladi...@connect2id.com> >> wrote: >> Hi, >> >> I just got a question on Twitter about the slow_down error: >> >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07#section-3.5 >> >> The question was why slow_down is communicated via HTTP status code 400 >> and not 429 (Too Many Requests). >> > We could, it seems to match the intent of that error code. Main reason it's > not like that so far is that 400 is the default for OAuth, I fear people > may not be checking for a 429. We don't strictly *need* the 429, since > we're returning data in machine readable format one way or another (i.e. > it's easy for the client to extract the "slow_down" response either way), > which differs from HTML over HTTP which is intended for end-user > consumption, making the specific status code more important. Yes, on a 400 clients will need to check the error JSON object anyway, so the "slow_down" cannot be missed. Whereas with 429 that becomes more likely. +1 to return "slow_down" with status 400 as it is with the other OAuth error codes. Thanks for considering this Vladimir. To conclude this topic, it seems there are no compelling reasons to change to the 429, and a reasonable explanation of why it's a 400, so I think we should keep things as-is. Rifaat: The deadline has passed on the WGLC, and I believe all comments raised have been addressed. Can we now advance the draft? No one responded to the comment I shared on 27 November. Scott ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token scanning attacks in RFC 7662
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 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 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
