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 www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com <mailto:phil.h...@oracle.com> > On Jan 25, 2016, at 4:52 PM, nov matake <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>. > 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 >> <mailto: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 <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
