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

[George Fletcher <[e-mail]>]

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/
>>
>> 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 <[e-mail]>:
>>
>>     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)
>>>     <[e-mail]> 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 <[e-mail]> 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
>>>>
>>>>     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
>>>>
>>>>>     On Jan 26, 2016, at 12:37, Phil Hunt (IDM)
>>>>>     <[e-mail]> 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)
>>>>>     <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>>>>>     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 inSection 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
>>>>>>>>         inSection 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
>>>>>>>>     [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.
>>>>>>>>>     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/
>>>>>>>>>
>>>>>>>>>     nov
>>>>>>>>>
>>>>>>>>>>     On Jan 26, 2016, at 08:22, Phil Hunt
>>>>>>>>>>     <[e-mail]> wrote:
>>>>>>>>>>
>>>>>>>>>>     Sorry, meant to reply-all.
>>>>>>>>>>
>>>>>>>>>>     Phil
>>>>>>>>>>
>>>>>>>>>>     @independentid
>>>>>>>>>>     www.independentid.com
>>>>>>>>>>     [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
>>>>>>>>>>>     [e-mail]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>     On Jan 25, 2016, at 2:58 PM, Nat Sakimura
>>>>>>>>>>>>     <[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/,
>>>>>>>>>>>>     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]>:
>>>>>>>>>>>>
>>>>>>>>>>>>         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]> wrote:
>>>>>>>>>>>>         >
>>>>>>>>>>>>         > would
>>>>>>>>>>>>
>>>>>>>>>>>>         _______________________________________________
>>>>>>>>>>>>         OAuth mailing list
>>>>>>>>>>>>         [e-mail]
>>>>>>>>>>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     _______________________________________________
>>>>>>>>>>     OAuth mailing list
>>>>>>>>>>     [e-mail]
>>>>>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>
>>>>>>     _______________________________________________
>>>>>>     OAuth mailing list
>>>>>>     [e-mail] <mailto:[e-mail]>
>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> -- 
> Chief Architect
> Identity Services Engineering     Work:[e-mail]
> AOL Inc.                          AIM:  gffletch
> Mobile: [phone]           Twitter:http://twitter.com/gffletch
> Office: [phone]           Photos:http://georgefletcher.photography
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: [e-mail]
AOL Inc.                          AIM:  gffletch
Mobile: [phone]           Twitter: http://twitter.com/gffletch
Office: [phone]           Photos: http://georgefletcher.photography