Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

[Phil Hunt <[e-mail]>]

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/>[e-mail] <mailto:[e-mail]>





> On Jan 25, 2016, at 4:52 PM, nov matake <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Sorry, meant to reply-all.
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>
>> 
>> 
>> 
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: Phil Hunt <[e-mail] <mailto:[e-mail]>>
>>> 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 <[e-mail] <mailto:[e-mail]>>
>>> 
>>> 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/>[e-mail] <mailto:[e-mail]>
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura <[e-mail] <mailto:[e-mail]>> 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) <[e-mail] <mailto:[e-mail]>>:
>>>> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>>>> >
>>>> > would
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>