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

From: Phil Hunt <[email-masked]>
Date: Mon, 25 Jan 2016 15:22:48 -0800

Sorry, meant to reply-all.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> Begin forwarded message:
> 
> From: Phil Hunt <[email-masked]>
> 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 <[email-masked]>
> 
> 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/>[email-masked] <mailto:[email-masked]>
> 
> 
> 
> 
> 
>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> 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) <[email-masked] <mailto:[email-masked]>>:
>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> > would
>> 
>> _______________________________________________
>> OAuth mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: nov matake <[email-masked]>
Date: Tue, 26 Jan 2016 09:52:30 +0900

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 <[email-masked]> wrote:
> 
>> From: Phil Hunt <[email-masked] <mailto:[email-masked]>>
>> To: Nat Sakimura <[email-masked] <mailto:[email-masked]>>
>> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Mon, 25 Jan 2016 17:45:36 -0800

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

> On Jan 25, 2016, at 4:52 PM, nov matake <[email-masked]> wrote:
> 
>> On Jan 26, 2016, at 08:22, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Nov Matake <[email-masked]>
Date: Tue, 26 Jan 2016 10:53:32 +0900

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 <[email-masked]> wrote:
> 
>    as described in Section 1.6 when sending requests to the
>    authorization endpoint.
> 
> Sec 3.1.2.1 
>    in Section 1.6 when the requested response type is "code" or "token",
> www.independentid.com
> [email-masked]
>> The first assumption is coming from the original security report at http://arxiv.org/abs/1601.01229.
>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
>> 
>> nov
>> 
>>> www.independentid.com
>>> [email-masked]
>>>> www.independentid.com
>>>> [email-masked]
>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura <[email-masked]> 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) <[email-masked]>:
>>>>>> > On Jan 25, 2016, at 10:39, George Fletcher <[email-masked]> wrote:
>>>>>> >
>>>>>> > would
>>>>>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 25 Jan 2016 19:29:40 -0800

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 <[email-masked]> wrote:
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 25 Jan 2016 19:37:30 -0800

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) <[email-masked]> wrote:
>

---

From: nov matake <[email-masked]>
Date: Tue, 26 Jan 2016 12:57:22 +0900

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) <[email-masked]> wrote:
> 
> On Jan 25, 2016, at 19:29, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Jan 25, 2016, at 17:53, Nov Matake <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Jan 26, 2016, at 10:45, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> On Jan 25, 2016, at 4:52 PM, nov matake <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 25 Jan 2016 20:14:44 -0800

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 <[email-masked]> wrote:
>

---

From: George Fletcher <[email-masked]>
Date: Tue, 26 Jan 2016 07:37:47 -0500

While I agree it may not be "proper" OAuth the fact is that the attack 
is still possible and that means that some acknowledgement (security or 
spec considerations) is required. Being able to MITM the UA or get the 
user to click a link that takes them to a malicious "client" that is 
really a MITM agent is easily doable.

While it's possible to confuse a client that just uses a single AS, that 
attack is more of a "endpoint phishing" style attack than a protocol 
attack. So far, baring no additional use cases, I'm still OK with 
declaring the existing spec viable for clients that pre-configure a 
single AS. Though I do think a "security consideration" should be 
written discussing this "endpoint phishing" attack that Nat describes.

That said, to really protect these flows, I've come to the conclusion 
that discovery and cryptographic binding are required for clients.

Thanks,
George

On 1/25/16 11:14 PM, Phil Hunt (IDM) 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.
>
> On Jan 25, 2016, at 19:57, nov matake <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> However, RP’s redirect response which causes following AuthZ request 
>> is still not TLS-protected, and modified on the attacker’s proxy.
>>
>>> On Jan 26, 2016, at 12:37, Phil Hunt (IDM) <[email-masked] 
>>> <mailto:[email-masked]>> 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
>>>
>>>>>>     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
>>>>>>     inSection 1.6 <https://tools.ietf.org/html/rfc6749#section-1.6>  when the requested response type is "code" or "token",
>>>>>> www.independentid.com <http://www.independentid.com/>
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> www.independentid.com <http://www.independentid.com/>
>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Begin forwarded message:
>>>>>>>>>
>>>>>>>>> *From: *Phil Hunt <[email-masked] 
>>>>>>>>> <mailto:[email-masked]>>
>>>>>>>>> *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 <[email-masked] 
>>>>>>>>> <mailto:[email-masked]>>
>>>>>>>>>
>>>>>>>>> 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/>
>>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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) <[email-masked] 
>>>>>>>>>> <mailto:[email-masked]>>:
>>>>>>>>>>
>>>>>>>>>>     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 that are deployed in large volume and may
>>>>>>>>>>     update frequently (more discussion of "public" cases)
>>>>>>>>>>     > On Jan 25, 2016, at 10:39, George Fletcher
>>>>>>>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>>     >
>>>>>>>>>>     > would
>>>>>>>>>>

-- 
Chief Architect
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

---

From: John Bradley <[email-masked]>
Date: Tue, 26 Jan 2016 14:18:13 -0300

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) <[email-masked]> wrote:
> 
> On Jan 25, 2016, at 19:57, nov matake <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 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>
>> 
>> http://arxiv.org/pdf/1601.01229v2.pdf <http://arxiv.org/pdf/1601.01229v2.pdf>
>> 
>>> On Jan 26, 2016, at 12:37, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 27 Jan 2016 01:58:08 +0000

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 <[email-masked]>:

> 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)
>
> 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.
> 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.
>
> redirct to the ua and not call the authz direct), the IDP should either
> return an error or redirect the RP to TLS.
>
> However, RP’s redirect response which causes following AuthZ request is
> still not TLS-protected, and modified on the attacker’s proxy.
>
> 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
>
> *From: *Phil Hunt <[email-masked]>
> *Subject: **Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation*
> *To: *Nat Sakimura <[email-masked]>
>
> 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
> [email-masked]
>
>
>
>
>
> Since I was not in Darmstadt, I really do not know what was discussed
> there, but with the compromised developer documentation described in
> all RFC6749 clients with a naive implementer will be affected. The client
> does not need to be talking to multiple IdPs.
>
> Nat
>
>> 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:

---

From: George Fletcher <[email-masked]>
Date: Wed, 27 Jan 2016 07:43:40 -0500

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:
> 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.
>
> 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 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 <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Nov,
>
>     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)
>
>     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.
>     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)
>>     <[email-masked] <mailto:[email-masked]>> 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.
>>
>>>     However, RP’s redirect response which causes following AuthZ
>>>     request is still not TLS-protected, and modified on the
>>>     attacker’s proxy.
>>>
>>>>     On Jan 26, 2016, at 12:37, Phil Hunt (IDM)
>>>>     <[email-masked] <mailto:[email-masked]>> 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)
>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>>>     It is still a reasonable assumption that RP puts a "login
>>>>>>     with FB" button on a non TLS-protected page.
>>>>>>
>>>>>>     nov
>>>>>>
>>>>>>>>     The first assumption is coming from the original security
>>>>>>>>     report at http://arxiv.org/abs/1601.01229.
>>>>>>>>>>     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
>>>>>>>>>>>     On Jan 25, 2016, at 2:58 PM, Nat Sakimura
>>>>>>>>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>     Hi Phil,
>>>>>>>>>>>
>>>>>>>>>>>     Since I was not in Darmstadt, I really do not know what
>>>>>>>>>>>     was discussed there, but with the compromised developer
>>>>>>>>>>>     affected. The client does not need to be talking to
>>>>>>>>>>>     multiple IdPs.
>>>>>>>>>>>
>>>>>>>>>>>     Nat
>>>>>>>>>>>
>>>>>>>>>>>     2016 年1月26日(火) 3:58 Phil Hunt (IDM)
>>>>>>>>>>>     <[email-masked] <mailto:[email-masked]>>:
>>>>>>>>>>>
>>>>>>>>>>>         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)

---

From: George Fletcher <[email-masked]>
Date: Wed, 27 Jan 2016 07:49:07 -0500

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:
> different? It seems like a simple check that would address the 
> endpoint mix-up cases.
>
> Thanks,
> George
>
>> 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.
>>
>> 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.
>> disallow the ASs that has different authority section for the Auhtz 
>> EP and Token EP would be adequate.
>>
>> Nat
>>
>>     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
>>>     <[email-masked]> wrote:
>>>
>>>>>     <[email-masked]> wrote:
>>>>>
>>>>>     <[email-masked]> wrote:
>>>>>
>>>>>>>>>>>>     <[email-masked]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>     Hi Phil,
>>>>>>>>>>>>
>>>>>>>>>>>>     <[email-masked]>:
>>>>>>>>>>>>         <[email-masked]> wrote:
>>>>>>>>>>>>         >
>>>>>>>>>>>>         > would
>>>>>>>>>>>>
> Identity Services Engineering     Work:[email-masked]
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch
> Office: +1-703-265-2544           Photos:http://georgefletcher.photography
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 27 Jan 2016 13:07:21 +0000

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 <[email-masked]>:

> 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.
>
>
> 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
>
>> 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)
>>
>> 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.
>>
>> 2016 年1月26日(火) 3:58 Phil Hunt (IDM) <[email-masked]>:
>>
>>> I recall proposing a new security document that covers oauth security
>>> for dynamic scenarios. "Dynamic" being broadly defined to mean:
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Chief Architect
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Chief Architect

---

From: Justin Richer <[email-masked]>
Date: Wed, 27 Jan 2016 15:48:46 -0500

I propose we rename this the “Random ASs Attack”.

 — Justin (only half joking)

> On Jan 27, 2016, at 8:07 AM, Nat Sakimura <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>>:
> 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.
> 
> 
>> 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
>> 
>>> 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. 
>>> 
>>> 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:[email-masked]>[email-masked] <mailto:[email-masked]>>:
>>> Nov,
>>> 
>>>> On Jan 26, 2016, at 1:14 AM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> On Jan 25, 2016, at 19:57, nov matake < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>>> On Jan 26, 2016, at 12:37, Phil Hunt (IDM) < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> On Jan 25, 2016, at 19:29, Phil Hunt (IDM) < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>>> On Jan 25, 2016, at 17:53, Nov Matake < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>> 
>>>>>>>> On Jan 26, 2016, at 10:45, Phil Hunt < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>> 
>>>>>>>>>  <http://www.independentid.com/>www.independentid.com <http://www.independentid.com/> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Jan 25, 2016, at 4:52 PM, nov matake < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> 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>.
>>>>>>>>>>  <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:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>  <http://www.independentid.com/>www.independentid.com <http://www.independentid.com/> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>> 
>>>>>>>>>>>>  <http://www.independentid.com/>www.independentid.com <http://www.independentid.com/> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> 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:[email-masked]>[email-masked] <mailto:[email-masked]>>:
>>>>>>>>>>>>> > On Jan 25, 2016, at 10:39, George Fletcher < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > would
>>>>>>>>>>>>> 
>>>>>>>>>>>>>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>>>>>>>>>  <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>>>>>>>  <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>>>  <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>> 
>> Identity Services Engineering     Work: [email-masked] <mailto:[email-masked]>
>> 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/>
>> 
>> 
> Identity Services Engineering     Work: [email-masked] <mailto:[email-masked]>
> 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/>

---

From: Hans Zandbelt <[email-masked]>
Date: Wed, 27 Jan 2016 20:56:40 +0000

a perfectly valid - at first - AS may get compromised later and used to 
attack other ASes; that attacj does not require code changes or control 
over the authorization endpoint: a rogue employee that happens to have 
access to log files (granted those include GET & POST data) on the AS 
can mount the attack if only he can phish the user

we can't expect that Clients are able to judge whether an AS will become 
compromised in the future; in fact that pushes the problems to the 
really good AS who now needs to decide if it accepts Clients that are 
able to make that judgement call about other ASes that it connects to

Hans.

On 1/27/16 8:48 PM, Justin Richer wrote:
>> On Jan 27, 2016, at 8:07 AM, Nat Sakimura <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Yup.
>>
>> authority restriction. Otherwise, use some variant of discovery to get
>> the authoritative token endpoints.
>>
>>
>>     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.
>>
>>
>>>     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
>>>
>>>>     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.
>>>>
>>>>     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.
>>>>     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".
>>>>
>>>>     <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/
>>>>
>>>>     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:[email-masked]>[email-masked]
>>>>         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)
>>>>
>>>>         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.
>>>>         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.
>>>>>         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:[email-masked]>[email-masked]
>>>>>>         However, RP’s redirect response which causes following
>>>>>>         AuthZ request is still not TLS-protected, and modified on
>>>>>>         the attacker’s proxy.
>>>>>>
>>>>>>>         <<mailto:[email-masked]>[email-masked]
>>>>>>>         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
>>>>>>>
>>>>>>>         <<mailto:[email-masked]>[email-masked]
>>>>>>>>         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:[email-masked]>[email-masked]
>>>>>>>>>         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:[email-masked]>[email-masked]
>>>>>>>>>>             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
>>>>>>>>>>             inSection 1.6
>>>>>>>>>>         <https://tools.ietf.org/html/rfc6749#section-1.6>  when the requested response type is "code" or "token",
>>>>>>>>>>         <http://www.independentid.com/>www.independentid.com
>>>>>>>>>>         <http://www.independentid.com/>
>>>>>>>>>>         <mailto:[email-masked]>[email-masked]
>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>         On Jan 25, 2016, at 4:52 PM, nov matake
>>>>>>>>>>>         <<mailto:[email-masked]>[email-masked]
>>>>>>>>>>>         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.
>>>>>>>>>>>
>>>>>>>>>>>         <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:[email-masked]>[email-masked]
>>>>>>>>>>>>         <http://www.independentid.com/>www.independentid.com
>>>>>>>>>>>>         <http://www.independentid.com/>
>>>>>>>>>>>>         <mailto:[email-masked]>[email-masked]
>>>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>         Begin forwarded message:
>>>>>>>>>>>>>
>>>>>>>>>>>>>         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:[email-masked]>[email-masked]
>>>>>>>>>>>>>         <mailto:[email-masked]>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>         <<mailto:[email-masked]>[email-masked]
>>>>>>>>>>>>>>         <mailto:[email-masked]>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         <<mailto:[email-masked]>[email-masked]
>>>>>>>>>>>>>>             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 are deployed in large volume
>>>>>>>>>>>>>>             and may update frequently (more discussion of
>>>>>>>>>>>>>>             "public" cases)
>>>>>>>>>>>>>>             <<mailto:[email-masked]>[email-masked]
>>>>>>>>>>>>>>             <mailto:[email-masked]>> wrote:
>>>>>>>>>>>>>>             >
>>>>>>>>>>>>>>             > would
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>         <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>         <https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>     Identity Services Engineering     Work:[email-masked] <mailto:[email-masked]>
>>>     AOL Inc.                          AIM:  gffletch
>>>     <http://georgefletcher.photography/>
>>>
>>>
>>     Identity Services Engineering     Work:[email-masked] <mailto:[email-masked]>
>>     AOL Inc.                          AIM:  gffletch
>>     Office: +1-703-265-2544           Photos:http://georgefletcher.photography <http://georgefletcher.photography/>
>>

-- 
Hans Zandbelt              | Sr. Technical Architect
[email-masked] | Ping Identity

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 28 Jan 2016 00:04:36 +0000

Interesting.
No code change even at the now compromised AS?

I can see that the phase two, the cut-and-paste attack portion works, but I
cannot see how the first portion works. Could you elaborate?
2016年1月28日(木) 5:56 Hans Zandbelt <[email-masked]>:

> >>>>     <
> http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/>
> >>>>>>>>>>         <https://tools.ietf.org/html/rfc6749#section-1.6>
> when the requested response type is "code" or "token",
> >>>>>>>>>>>         <
> >>>>>>>>>>>>>>         <
> http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/>
> >>>>>>>>>>>>>>             <https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>>>>>>>>         <https://www.ietf.org/mailman/listinfo/oauth>
> >>>>>>>>         <https://www.ietf.org/mailman/listinfo/oauth>
> <mailto:[email-masked]>
> >>>     AOL Inc.                          AIM:  gffletch
> <mailto:[email-masked]>
> >>     AOL Inc.                          AIM:  gffletch
> >>     Office: +1-703-265-2544           Photos:
> http://georgefletcher.photography <http://georgefletcher.photography/>
> >>

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 28 Jan 2016 01:38:18 +0100

indeed, if the attacker is able to phish the user, he can put up a 
script that first triggers the authorization request to the compromised 
AS (i.e. the AS at which he has access to the logs and gathers the state 
value from) through the Client, and subsequently trigger the redirect to 
the good AS using an auto-refresh of that same phishing page (with the 
stolen state value); no need to control the authorization endpoint of 
the compromised AS itself

Hans.

On 1/28/16 1:04 AM, Nat Sakimura wrote:
> I can see that the phase two, the cut-and-paste attack portion works,
> but I cannot see how the first portion works. Could you elaborate?
> 2016年1月28日(木) 5:56 Hans Zandbelt <[email-masked]
> <mailto:[email-masked]>>:
>
>     <mailto:[email-masked]>
>      >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>
>      >> Yup.
>      >>
>      >> 2016年1月27日(水) 21:49 George Fletcher <[email-masked]
>     <mailto:[email-masked]>
>      >> <mailto:[email-masked] <mailto:[email-masked]>>>:
>      >>
>      >>>>     <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>      >>>>     <mailto:[email-masked] <mailto:[email-masked]>>>:
>      >>>>
>      >>>>         Nov,
>      >>>>
>      >>>>         Not using TLS is reasonable when the redirect URI is
>     using a
>      >>>>         custom scheme for native apps.
>      >>>>
>      >>>>         Note that the token itself is never passed over a non
>     https
>      >>>>         connection in tis case.
>      >>>>>         <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >>>>>
>      >>>>>         <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>      >>>>>         <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>      >>>>>
>      >>>>>>>         <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked]
>      >>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>>>>>
>      >>>>>>>         <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked]
>      >>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>>>>>
>      >>>>>>>>         <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>      >>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>>>>>>
>      >>>>>>>>>         <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked]
>      >>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>>>>>>>
>       <https://tools.ietf.org/html/rfc6749#section-1.6>  when the
>     requested response type is "code" or "token",
>      >>>>>>>>>>         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>
>      >>>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked]
>      >>>>>>>>>>         <mailto:[email-masked]
>      >>>>>>>>>>>         <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>      >>>>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>>>>>>>>>
>      >>>>>>>>>>>>         <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked]
>      >>>>>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>>>>>>>>>>
>     <http://www.independentid.com>
>      >>>>>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked]
>      >>>>>>>>>>>>         <mailto:[email-masked]
>      >>>>>>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >>>>>>>>>>>>>         *Subject: **Re: [OAUTH-WG] Call for Adoption:
>     OAuth
>      >>>>>>>>>>>>>         2.0 Mix-Up Mitigation*
>     <mailto:[email-masked]>
>      >>>>>>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >>>>>>>>>>>>>
>     <http://www.independentid.com> <http://www.independentid.com/>
>      >>>>>>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked]
>      >>>>>>>>>>>>>         <mailto:[email-masked]
>      >>>>>>>>>>>>>>         <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked]
>     <mailto:[email-masked]>
>      >>>>>>>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>         Hi Phil,
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>         <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked]
>      >>>>>>>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>>:
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>             * clients that communicate with more
>     than one
>      >>>>>>>>>>>>>>             endpoint
>      >>>>>>>>>>>>>>             <<mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>      >>>>>>>>>>>>>>             <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>>>>>>>>>>>>>             >
>      >>>>>>>>>>>>>>             > would
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>>>             <mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>      >>>>>>>>>>>>>>             <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>>>>>>>>>>>>>
>      >>>>>>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>      >>>>>>>>>>>>         <mailto:[email-masked] <mailto:[email-masked]>>
>      >>>>>>>>>>>>
>      >>>>>>>>         <mailto:[email-masked]
>     <mailto:[email-masked]>>[email-masked] <mailto:[email-masked]>
>      >>>>>>>>         <mailto:[email-masked] <mailto:[email-masked]>>
>      >>>>>>>>
>      >>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>>     AOL Inc.                          AIM:  gffletch
>      >>>     Mobile: +1-703-462-3494
>      >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>     AOL Inc.                          AIM:  gffletch
>      >>     Mobile: +1-703-462-3494
>      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]> |
>     Ping Identity
>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 28 Jan 2016 01:42:07 +0000

I see. That's like double cut-n-paste.

I tried to capture this case of used-to-be-good AS turning Compromised AS
(Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD

Given this, just relying on not using random AS is not good enough. You
would probably require AS w/ISMS with the policy of not logging un-masked
credentials and has strict access control on the log ;-)

Nat

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Jan 2016 14:53:46 -0300

Yes,  I note either mitigation in draft-jones-oauth-mix-up-mitigation-01 will stop this attack.

White listing AS seems tempting, but is just sweeping the problem partially under the rug.  
There are probably good policy reasons to whitelist AS but we shouldn’t let this AS mixup be one of them.

John B.

> On Jan 27, 2016, at 10:42 PM, Nat Sakimura <[email-masked]> wrote:
> 
> I tried to capture this case of used-to-be-good AS turning Compromised AS (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD <http://j.mp/1QtDeKD>
> 
> Given this, just relying on not using random AS is not good enough. You would probably require AS w/ISMS with the policy of not logging un-masked credentials and has strict access control on the log ;-) 
> 
> Nat
> 
> 2016年1月28日(木) 9:38 Hans Zandbelt <[email-masked] <mailto:[email-masked]>>:

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 29 Jan 2016 04:54:36 +0000

My preferred way of dealing with mix-up has been to use separate
redirection URI but your using issuer instead is for the backward
compatibility?

Nat

2016年1月29日(金) 2:53 John Bradley <[email-masked]>:

> There are probably good policy reasons to whitelist AS but
> we shouldn’t let this AS mixup be one of them.
>
> John B.
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 28 Jan 2016 21:14:50 -0800

We discussed that redirecr helps but we wanted the Token endpoint to also be able to detect assuming many client devs won't implement the check. 

Phil

> On Jan 28, 2016, at 20:54, Nat Sakimura <[email-masked]> wrote:
> 
> My preferred way of dealing with mix-up has been to use separate redirection URI but your using issuer instead is for the backward compatibility? 
> 
> Nat
> 
>>> I tried to capture this case of used-to-be-good AS turning Compromised AS (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD
>>>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 29 Jan 2016 06:11:33 +0000

But that's cut-n-paste protection using "state" token endpoint parameter,
is it not?

2016年1月29日(金) 14:14 Phil Hunt (IDM) <[email-masked]>:

> We discussed that redirecr helps but we wanted the Token endpoint to also
> be able to detect assuming many client devs won't implement the check.
>
>
> Phil
>