The first assumption is coming from the original security report at 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/> nov > On Jan 26, 2016, at 08:22, Phil Hunt <phil.h...@oracle.com> wrote: > > Sorry, meant to reply-all. > > Phil > > @independentid > www.independentid.com <http://www.independentid.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 >> www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com >> <mailto:phil.h...@oracle.com> >> >> >> >> >> >>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura <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/>, >>> 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) <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 <gffle...@aol.com >>> > <mailto:gffle...@aol.com>> wrote: >>> > >>> > would >>> >>> _______________________________________________ >>> 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 > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
