I propose we rename this the “Random ASs Attack”. — Justin (only half joking)
> On Jan 27, 2016, at 8:07 AM, Nat Sakimura <sakim...@gmail.com> wrote: > > Yup. > > For the RPs that would deal with valuable data, I also recommend it to become > HTTPS only. This will effectively close the hole for the AS Mix-Up. > Also, I would recommend to the clients to think twice before accepting random > ASs. > To prevent the code phishing, it is a good idea to require the same authority > restriction. Otherwise, use some variant of discovery to get the > authoritative token endpoints. > > > 2016年1月27日(水) 21:49 George Fletcher <gffle...@aol.com > <mailto:gffle...@aol.com>>: > Based on Hans' response to Nat I understand why this doesn't solve all the > use cases. It does still seem like a good idea from a client perspective that > would address the dynamic client registration cases where the Bad AS is > returning mixed endpoints. > > > On 1/27/16 7:43 AM, George Fletcher wrote: >> Following up on Nat's last paragraph... did the group in Darmstadt discuss >> this option? Namely, to require that the authority section of the AuthZ and >> Token endpoints be the same? Are there known implementations already >> deployed where the authority sections are different? It seems like a simple >> check that would address the endpoint mix-up cases. >> >> Thanks, >> George >> >> On 1/26/16 8:58 PM, Nat Sakimura wrote: >>> John, >>> >>> Nov is not talking about the redirection endpoint. I just noticed that >>> 3.1.2.1 of RFC 6749 is just asking TLS by "SHOULD" and I think it needs to >>> be changed to "MUST" but that is not what he is talking about. >>> >>> Instead, he is talking about before starting the RFC 6749 flow. >>> >>> In many cases, a non TLS protected sites have "Login with HIdP" button >>> linked to a URI that initiates the RFC 6749 flow. This portion is not >>> within RFC 6749 and this endpoint has no name or no requirement to be TLS >>> protected. Right, it is very stupid, but there are many sites like that. >>> As a result, the attacker can insert itself as a proxy, say by providing a >>> free wifi hotspot, and either re-write the button or the request so that >>> the RP receives "Login with AIdP" instead of "Login with HIdP". >>> >>> I have add a note explaining this to >>> <http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/>http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/ >>> <http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/> >>> >>> I also have added a bit of risk analysis on it and considered other risk >>> control measures as well. >>> >>> It does not seem to be worthwhile to introduce a new wire-protocol element >>> to deal with this particular attack. (I regard code cut-and-paste attack a >>> separate attack.) I am inclining to think that just to TLS protect the >>> pre-RFC6749 flow portion and add a check to disallow the ASs that has >>> different authority section for the Auhtz EP and Token EP would be >>> adequate. >>> >>> Nat >>> >>> 2016年1月27日(水) 2:18 John Bradley < >>> <mailto:ve7...@ve7jtb.com>ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>: >>> Nov, >>> >>> Are you referring to Sec 3.1.2.1 of RFC 6749. >>> >>> Stating that the the redirection endpoint SHOULD require TLS, and that the >>> AS should warn the user if the redirect URI is not over TLS (Something I >>> have never seen done in the real world) >>> >>> Not using TLS is reasonable when the redirect URI is using a custom scheme >>> for native apps. >>> >>> It might almost be reasonable for the token flow where the JS page itself >>> is not loaded over TLS so the callback to extract the fragment would not be >>> as well. >>> Note that the token itself is never passed over a non https connection in >>> tis case. >>> I would argue now that it is irresponsible to have a non TLS protected >>> site, but not everyone is going to go along with that. >>> >>> Using a http scheme URI for the redirect is allowed but is really stupid. >>> We did have a large debate about this when profiling OAuth for Connect. >>> We did tighten connect to say that if you are using the code flow then a >>> http scheme redirect URI is only allowed if the client is confidential. >>> >>> John B. >>>> On Jan 26, 2016, at 1:14 AM, Phil Hunt (IDM) <phil.h...@oracle.com >>>> <mailto:phil.h...@oracle.com>> wrote: >>>> >>>> Still don't see it. Though i think the diagram is wrong (the rp should >>>> redirct to the ua and not call the authz direct), the IDP should either >>>> return an error or redirect the RP to TLS. >>>> >>>> I don't see this as proper oauth protocol since the RP is MITM the UA >>>> rather than acting as a client. >>>> >>>> Phil >>>> >>>> On Jan 25, 2016, at 19:57, nov matake < >>>> <mailto:mat...@gmail.com>mat...@gmail.com <mailto:mat...@gmail.com>> wrote: >>>> >>>>> In this flow, AuthZ endpoint is forced to be TLS-protected. >>>>> http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png >>>>> <http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png> >>>>> >>>>> However, RP’s redirect response which causes following AuthZ request is >>>>> still not TLS-protected, and modified on the attacker’s proxy. >>>>> >>>>> Section 3.2 of this report also describes the same flow. >>>>> http://arxiv.org/pdf/1601.01229v2.pdf >>>>> <http://arxiv.org/pdf/1601.01229v2.pdf> >>>>> >>>>>> On Jan 26, 2016, at 12:37, Phil Hunt (IDM) < >>>>>> <mailto:phil.h...@oracle.com>phil.h...@oracle.com >>>>>> <mailto:phil.h...@oracle.com>> wrote: >>>>>> >>>>>> Also the authz endpoint is required to force tls. So if the client >>>>>> doesn't do it the authz should reject (eg by upgrading to tls). >>>>>> >>>>>> Phil >>>>>> >>>>>> On Jan 25, 2016, at 19:29, Phil Hunt (IDM) < >>>>>> <mailto:phil.h...@oracle.com>phil.h...@oracle.com >>>>>> <mailto:phil.h...@oracle.com>> wrote: >>>>>> >>>>>>> When the RP acting as the client issues a authorize redirect to the UA >>>>>>> it has to make it with TLS >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On Jan 25, 2016, at 17:53, Nov Matake < >>>>>>> <mailto:mat...@gmail.com>mat...@gmail.com <mailto:mat...@gmail.com>> >>>>>>> wrote: >>>>>>> >>>>>>>> It doen't say anything about the first request which initiate the >>>>>>>> login flow. >>>>>>>> It is still a reasonable assumption that RP puts a "login with FB" >>>>>>>> button on a non TLS-protected page. >>>>>>>> >>>>>>>> nov >>>>>>>> >>>>>>>> On Jan 26, 2016, at 10:45, Phil Hunt < >>>>>>>> <mailto:phil.h...@oracle.com>phil.h...@oracle.com >>>>>>>> <mailto:phil.h...@oracle.com>> wrote: >>>>>>>> >>>>>>>>> I would find it hard to believe that is true. >>>>>>>>> >>>>>>>>> From 6749 Sec 3.1 >>>>>>>>> Since requests to the authorization endpoint result in user >>>>>>>>> authentication and the transmission of clear-text credentials (in >>>>>>>>> the >>>>>>>>> HTTP response), the authorization server MUST require the use of >>>>>>>>> TLS >>>>>>>>> as described in Section 1.6 >>>>>>>>> <https://tools.ietf.org/html/rfc6749#section-1.6> when sending >>>>>>>>> requests to the >>>>>>>>> authorization endpoint. >>>>>>>>> >>>>>>>>> Sec 3.1.2.1 >>>>>>>>> The redirection endpoint SHOULD require the use of TLS as described >>>>>>>>> in Section 1.6 <https://tools.ietf.org/html/rfc6749#section-1.6> >>>>>>>>> when the requested response type is "code" or "token", >>>>>>>>> or when the redirection request will result in the transmission of >>>>>>>>> sensitive credentials over an open network. This specification >>>>>>>>> does >>>>>>>>> not mandate the use of TLS because at the time of this writing, >>>>>>>>> requiring clients to deploy TLS is a significant hurdle for many >>>>>>>>> client developers. If TLS is not available, the authorization >>>>>>>>> server >>>>>>>>> SHOULD warn the resource owner about the insecure endpoint prior to >>>>>>>>> redirection (e.g., display a message during the authorization >>>>>>>>> request). >>>>>>>>> >>>>>>>>> Lack of transport-layer security can have a severe impact on the >>>>>>>>> security of the client and the protected resources it is authorized >>>>>>>>> to access. The use of transport-layer security is particularly >>>>>>>>> critical when the authorization process is used as a form of >>>>>>>>> delegated end-user authentication by the client (e.g., third-party >>>>>>>>> sign-in service). >>>>>>>>> >>>>>>>>> Section 10.5 talks about transmission of authorization codes in >>>>>>>>> connection with redirects. >>>>>>>>> >>>>>>>>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of >>>>>>>>> authz codes. >>>>>>>>> >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> @independentid >>>>>>>>> <http://www.independentid.com/>www.independentid.com >>>>>>>>> <http://www.independentid.com/> >>>>>>>>> <mailto:phil.h...@oracle.com>phil.h...@oracle.com >>>>>>>>> <mailto:phil.h...@oracle.com> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jan 25, 2016, at 4:52 PM, nov matake < >>>>>>>>>> <mailto:mat...@gmail.com>mat...@gmail.com <mailto:mat...@gmail.com>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> The first assumption is coming from the original security report at >>>>>>>>>> <http://arxiv.org/abs/1601.01229>http://arxiv.org/abs/1601.01229 >>>>>>>>>> <http://arxiv.org/abs/1601.01229>. >>>>>>>>>> RFC 6749 requires TLS between RS and AS, and also between UA and AS, >>>>>>>>>> but not between UA and RS. >>>>>>>>>> >>>>>>>>>> The blog post is based on my Japanese post, and it describes >>>>>>>>>> multi-AS case. >>>>>>>>>> Nat's another post describes the case which can affect single-AS >>>>>>>>>> case too. >>>>>>>>>> >>>>>>>>>> <http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/>http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ >>>>>>>>>> >>>>>>>>>> <http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/> >>>>>>>>>> >>>>>>>>>> nov >>>>>>>>>> >>>>>>>>>>> On Jan 26, 2016, at 08:22, Phil Hunt < >>>>>>>>>>> <mailto:phil.h...@oracle.com>phil.h...@oracle.com >>>>>>>>>>> <mailto:phil.h...@oracle.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> Sorry, meant to reply-all. >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> @independentid >>>>>>>>>>> <http://www.independentid.com/>www.independentid.com >>>>>>>>>>> <http://www.independentid.com/> >>>>>>>>>>> <mailto:phil.h...@oracle.com>phil.h...@oracle.com >>>>>>>>>>> <mailto:phil.h...@oracle.com> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>> >>>>>>>>>>>> From: Phil Hunt <phil.h...@oracle.com >>>>>>>>>>>> <mailto:phil.h...@oracle.com>> >>>>>>>>>>>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up >>>>>>>>>>>> Mitigation >>>>>>>>>>>> Date: January 25, 2016 at 3:20:19 PM PST >>>>>>>>>>>> To: Nat Sakimura <sakim...@gmail.com <mailto:sakim...@gmail.com>> >>>>>>>>>>>> >>>>>>>>>>>> I am having trouble with the very first assumption. The user-agent >>>>>>>>>>>> sets up a non TLS protected connection to the RP? That’s a >>>>>>>>>>>> fundamental violation of 6749. >>>>>>>>>>>> >>>>>>>>>>>> Also, the second statement says the RP (assuming it acts as OAuth >>>>>>>>>>>> client) is talking to two IDPs. That’s still a multi-AS case is >>>>>>>>>>>> it not? >>>>>>>>>>>> >>>>>>>>>>>> Phil >>>>>>>>>>>> >>>>>>>>>>>> @independentid >>>>>>>>>>>> <http://www.independentid.com/>www.independentid.com >>>>>>>>>>>> <http://www.independentid.com/> >>>>>>>>>>>> <mailto:phil.h...@oracle.com>phil.h...@oracle.com >>>>>>>>>>>> <mailto:phil.h...@oracle.com> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura < >>>>>>>>>>>>> <mailto:sakim...@gmail.com>sakim...@gmail.com >>>>>>>>>>>>> <mailto:sakim...@gmail.com>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Phil, >>>>>>>>>>>>> >>>>>>>>>>>>> Since I was not in Darmstadt, I really do not know what was >>>>>>>>>>>>> discussed there, but with the compromised developer documentation >>>>>>>>>>>>> described in >>>>>>>>>>>>> <http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/>http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/ >>>>>>>>>>>>> >>>>>>>>>>>>> <http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/>, >>>>>>>>>>>>> all RFC6749 clients with a naive implementer will be affected. >>>>>>>>>>>>> The client does not need to be talking to multiple IdPs. >>>>>>>>>>>>> >>>>>>>>>>>>> Nat >>>>>>>>>>>>> >>>>>>>>>>>>> 2016 年1月26日(火) 3:58 Phil Hunt (IDM) < >>>>>>>>>>>>> <mailto:phil.h...@oracle.com>phil.h...@oracle.com >>>>>>>>>>>>> <mailto:phil.h...@oracle.com>>: >>>>>>>>>>>>> I recall making this point in Germany. 99% of existing use is >>>>>>>>>>>>> fine. OIDC is probably the largest community that *might* have an >>>>>>>>>>>>> issue. >>>>>>>>>>>>> >>>>>>>>>>>>> I recall proposing a new security document that covers oauth >>>>>>>>>>>>> security for dynamic scenarios. "Dynamic" being broadly defined >>>>>>>>>>>>> to mean: >>>>>>>>>>>>> * clients who have configured at runtime or install time >>>>>>>>>>>>> (including clients that do discovery) >>>>>>>>>>>>> * clients that communicate with more than one endpoint >>>>>>>>>>>>> * clients that are deployed in large volume and may update >>>>>>>>>>>>> frequently (more discussion of "public" cases) >>>>>>>>>>>>> * clients that are script based (loaded into browser on the fly) >>>>>>>>>>>>> * others? >>>>>>>>>>>>> >>>>>>>>>>>>> Phil >>>>>>>>>>>>> >>>>>>>>>>>>> > On Jan 25, 2016, at 10:39, George Fletcher < >>>>>>>>>>>>> > <mailto:gffle...@aol.com>gffle...@aol.com >>>>>>>>>>>>> > <mailto:gffle...@aol.com>> wrote: >>>>>>>>>>>>> > >>>>>>>>>>>>> > would >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> <mailto:OAuth@ietf.org>OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>> >>>>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> <mailto:OAuth@ietf.org>OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>> >>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>>>> >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> <mailto:OAuth@ietf.org>OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>> >>>>>>> <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth >>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> -- >> Chief Architect >> Identity Services Engineering Work: george.fletc...@teamaol.com >> <mailto:george.fletc...@teamaol.com> >> AOL Inc. AIM: gffletch >> Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch >> <http://twitter.com/gffletch> >> Office: +1-703-265-2544 Photos: http://georgefletcher.photography >> <http://georgefletcher.photography/> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > -- > Chief Architect > Identity Services Engineering Work: george.fletc...@teamaol.com > <mailto:george.fletc...@teamaol.com> > AOL Inc. AIM: gffletch > Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch > <http://twitter.com/gffletch> > Office: +1-703-265-2544 Photos: http://georgefletcher.photography > <http://georgefletcher.photography/> > _______________________________________________ > 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
