Subject: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

From: Mike Jones <[email-masked]>
Date: Mon, 11 Jan 2016 09:27:21 +0000

Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up<https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>.  This note announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks covered in the advisory.  The abstract of the specification is:

This specification defines an extension to The OAuth 2.0 Authorization Framework that enables an authorization server to provide a client using it with a consistent set of metadata about itself. This information is returned in the authorization response. It can be used by the client to prevent classes of attacks in which the client might otherwise be tricked into using inconsistent sets of metadata from multiple authorization servers, including potentially using a token endpoint that does not belong to the same authorization server as the authorization endpoint used. Recent research publications refer to these as "IdP Mix-Up" and "Malicious Endpoint" attacks.

The gist of the mitigation is having the authorization server return the client ID and its issuer identifier (a value defined in the OAuth Discovery specification<http://self-issued.info/?p=1496>) so that the client can verify that it is using a consistent set of authorization server configuration information, that the client ID is for that authorization server, and in particular, that the client is not being confused into sending information intended for one authorization server to a different one.  Note that these attacks can only be made against clients that are configured to use more than one authorization server.

Please give the draft a quick read and provide feedback to the OAuth working group.  This draft is very much a starting point intended to describe both the mitigations and the decisions and analysis remaining before we can be confident in standardizing a solution.  Please definitely read the Security Considerations and Open Issues sections, as they contain important information about the choices made and the decisions remaining.

Special thanks go to Daniel Fett (University of Trier), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Guido Schmitz (University of Trier) for notifying us of the attacks and working with us both on understanding the attacks and on developing mitigations.  Thanks too to Hannes Tschofenig for organizing a meeting on this topic last month and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting.

The specification is available at:

*       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00

An HTML-formatted version is also available at:

*       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html

                                                          -- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1524 and as @selfissued<https://twitter.com/selfissued>.

---

From: George Fletcher <[email-masked]>
Date: Mon, 11 Jan 2016 13:20:38 -0500

Thanks Mike. One question after reading about the different attack 
vectors and this spec...

How are the 'iss' and 'aud' values returned with the 'code' and 'state' 
parameters. It seems the client needs to verify the endpoints before 
making the request to exchange the code for a token. If the client is 
using the default OAuth2 client_id and client_secret these values will 
be sent to the malicious endpoint if the client can't verify the 
endpoints before hand.

Also, it would be nice to add some non-normative examples to the spec.

Thanks,
George

On 1/11/16 4:27 AM, Mike Jones wrote:
>
> Yesterday Hannes Tschofenig announced an OAuth Security Advisory on 
> Authorization Server Mix-Up 
> <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>.  
> This note announces the publication of the strawman OAuth 2.0 Mix-Up 
> Mitigation draft he mentioned that mitigates the attacks covered in 
> the advisory.  The abstract of the specification is:
>
> This specification defines an extension to The OAuth 2.0 Authorization 
> Framework that enables an authorization server to provide a client 
> using it with a consistent set of metadata about itself. This 
> information is returned in the authorization response. It can be used 
> by the client to prevent classes of attacks in which the client might 
> otherwise be tricked into using inconsistent sets of metadata from 
> multiple authorization servers, including potentially using a token 
> endpoint that does not belong to the same authorization server as the 
> authorization endpoint used. Recent research publications refer to 
> these as "IdP Mix-Up" and "Malicious Endpoint" attacks.
>
> The gist of the mitigation is having the authorization server return 
> the client ID and its issuer identifier (a value defined in the OAuth 
> Discovery specification <http://self-issued.info/?p=1496>) so that the 
> client can verify that it is using a consistent set of authorization 
> server configuration information, that the client ID is for that 
> authorization server, and in particular, that the client is not being 
> confused into sending information intended for one authorization 
> server to a different one.  Note that these attacks can only be made 
> against clients that are configured to use more than one authorization 
> server.
>
> Please give the draft a quick read and provide feedback to the OAuth 
> working group.  This draft is very much a starting point intended to 
> describe both the mitigations and the decisions and analysis remaining 
> before we can be confident in standardizing a solution.  Please 
> definitely read the Security Considerations and Open Issues sections, 
> as they contain important information about the choices made and the 
> decisions remaining.
>
> Special thanks go to Daniel Fett (University of Trier), Christian 
> Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University 
> Bochum), and Guido Schmitz (University of Trier) for notifying us of 
> the attacks and working with us both on understanding the attacks and 
> on developing mitigations.  Thanks too to Hannes Tschofenig for 
> organizing a meeting on this topic last month and to Torsten 
> Lodderstedt and Deutsche Telekom for hosting the meeting.
>
> ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>
> ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html
>
> -- Mike
>
> P.S.  This note was also posted at http://self-issued.info/?p=1524 and 
> as @selfissued <https://twitter.com/selfissued>.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
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: Mike Jones <[email-masked]>
Date: Mon, 11 Jan 2016 19:59:21 +0000

The alternatives for the code flow are to return them either in a new JWT added to the reply containing them in the "iss" and "aud" claims or to return them in new individual "client_id" and "iss" authorization response parameters.  Both alternatives are described in the draft.  I'm sure that we'll now be having a good engineering discussion on the tradeoffs between the alternatives.,

In a separate draft, John Bradley will shortly also be describing the possibility of securing the "state" value using a "state_hash" value that works in a way that's similar to how "at_hash" and "c_hash" secure the "access_token" and "code" values in Connect.  This would be an alternative means of binding the authorization request and response to the session - accomplishing the same thing that the Connect "nonce" does.

While I fully get that some OAuth implementations want to avoid having to have crypto, it seems like at least support for cryptographic hashing (SHA-256, etc.) may be necessary to mitigate some of these attacks (at least for clients that use more than one authorization server).

The other important engineering discussion I know we're going to have is whether, when an OAuth profile already returns the information needed for the mitigation, whether we want to specify that the client obtain it from the existing location, or whether to also return it in a duplicate location.  I'll note that OpenID Connect already returns the client ID and issuer for the flows that return an ID Token in the authorization response, so this isn't a hypothetical question.

Finally, I know that we'll need to discuss the impact of cut-and-paste attacks when the issuer and client ID are returned as individual authorization response parameters that are not cryptographically bound to the rest of the response.  The cut-and-paste attack that returning the issuer and client_id values as separate parameters enables, even when state_hash or nonce is used, is for the attacker to capture the legitimate response containing "iss" and "client_id" results and substitute different values for these fields, then post that altered response to the legitimate client.  The state and/or nonce values are protected against substitution but "iss" and "client_id" are not.

And yes, I absolutely agree that good examples are essential.  That's high on my list for the -01 version.

                                                          Thanks a bunch,
                                                          -- Mike

From: George Fletcher [mailto:[email-masked]]
Sent: Monday, January 11, 2016 10:21 AM
To: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Thanks Mike. One question after reading about the different attack vectors and this spec...

How are the 'iss' and 'aud' values returned with the 'code' and 'state' parameters. It seems the client needs to verify the endpoints before making the request to exchange the code for a token. If the client is using the default OAuth2 client_id and client_secret these values will be sent to the malicious endpoint if the client can't verify the endpoints before hand.

Thanks,
George

                                                          -- Mike

OAuth mailing list

[email-masked]<mailto:[email-masked]>

--

Chief Architect

Identity Services Engineering     Work: [email-masked]<mailto:[email-masked]>

AOL Inc.                          AIM:  gffletch

---

From: George Fletcher <[email-masked]>
Date: Mon, 11 Jan 2016 15:13:12 -0500

So just to make sure I understand...

This specification requires the response from the Authorization Server 
to an successful /authorize call to pass back code=, state= and jwt= (?) 
or individually iss= and aud= as URL parameters on the 302 to the 
redirect_url. This way, before the client issues a call to the /token 
endpoint (with the code), it can verify that the token endpoint is correct.

If the client doesn't validate the endpoints at this step, then it could 
disclose it's secret to a malicious endpoint. Correct?

Thanks,
George

On 1/11/16 2:59 PM, Mike Jones wrote:
>
> The alternatives for the code flow are to return them either in a new 
> JWT added to the reply containing them in the “iss” and “aud” claims 
> or to return them in new individual “client_id” and “iss” 
> authorization response parameters. Both alternatives are described in 
> the draft.  I’m sure that we’ll now be having a good engineering 
> discussion on the tradeoffs between the alternatives.,
>
> In a separate draft, John Bradley will shortly also be describing the 
> possibility of securing the “state” value using a “state_hash” value 
> that works in a way that’s similar to how “at_hash” and “c_hash” 
> secure the “access_token” and “code” values in Connect.  This would be 
> an alternative means of binding the authorization request and response 
> to the session – accomplishing the same thing that the Connect “nonce” 
> does.
>
> While I fully get that some OAuth implementations want to avoid having 
> to have crypto, it seems like at least support for cryptographic 
> hashing (SHA-256, etc.) may be necessary to mitigate some of these 
> attacks (at least for clients that use more than one authorization 
> server).
>
> The other important engineering discussion I know we’re going to have 
> is whether, when an OAuth profile already returns the information 
> needed for the mitigation, whether we want to specify that the client 
> obtain it from the existing location, or whether to also return it in 
> a duplicate location.  I’ll note that OpenID Connect already returns 
> the client ID and issuer for the flows that return an ID Token in the 
> authorization response, so this isn’t a hypothetical question.
>
> Finally, I know that we’ll need to discuss the impact of cut-and-paste 
> attacks when the issuer and client ID are returned as individual 
> authorization response parameters that are not cryptographically bound 
> to the rest of the response. The cut-and-paste attack that returning 
> the issuer and client_id values as separate parameters enables, even 
> when state_hash or nonce is used, is for the attacker to capture the 
> legitimate response containing “iss” and “client_id” results and 
> substitute different values for these fields, then post that altered 
> response to the legitimate client.  The state and/or nonce values are 
> protected against substitution but “iss” and “client_id” are not.
>
> And yes, I absolutely agree that good examples are essential.  That’s 
> high on my list for the -01 version.
>
> Thanks a bunch,
>
> -- Mike
>
> *From:*George Fletcher [mailto:[email-masked]]
> *Sent:* Monday, January 11, 2016 10:21 AM
> *To:* Mike Jones <[email-masked]>; [email-masked]
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
>
> How are the 'iss' and 'aud' values returned with the 'code' and 
> 'state' parameters. It seems the client needs to verify the endpoints 
> before making the request to exchange the code for a token. If the 
> client is using the default OAuth2 client_id and client_secret these 
> values will be sent to the malicious endpoint if the client can't 
> verify the endpoints before hand.
>
>     Yesterday Hannes Tschofenig announced an OAuth Security Advisory
>     on Authorization Server Mix-Up
>     This note announces the publication of the strawman OAuth 2.0
>     Mix-Up Mitigation draft he mentioned that mitigates the attacks
>     covered in the advisory.  The abstract of the specification is:
>
>     This specification defines an extension to The OAuth 2.0
>     Authorization Framework that enables an authorization server to
>     provide a client using it with a consistent set of metadata about
>     itself. This information is returned in the authorization
>     response. It can be used by the client to prevent classes of
>     attacks in which the client might otherwise be tricked into using
>     inconsistent sets of metadata from multiple authorization servers,
>     including potentially using a token endpoint that does not belong
>     to the same authorization server as the authorization endpoint
>     used. Recent research publications refer to these as "IdP Mix-Up"
>     and "Malicious Endpoint" attacks.
>
>     The gist of the mitigation is having the authorization server
>     return the client ID and its issuer identifier (a value defined in
>     the OAuth Discovery specification
>     <http://self-issued.info/?p=1496>) so that the client can verify
>     that it is using a consistent set of authorization server
>     configuration information, that the client ID is for that
>     authorization server, and in particular, that the client is not
>     being confused into sending information intended for one
>     authorization server to a different one.  Note that these attacks
>     can only be made against clients that are configured to use more
>     than one authorization server.
>
>     Please give the draft a quick read and provide feedback to the
>     OAuth working group.  This draft is very much a starting point
>     intended to describe both the mitigations and the decisions and
>     analysis remaining before we can be confident in standardizing a
>     solution.  Please definitely read the Security Considerations and
>     Open Issues sections, as they contain important information about
>     the choices made and the decisions remaining.
>
>     Mainka (Ruhr-University Bochum), Vladislav Mladenov
>     (Ruhr-University Bochum), and Guido Schmitz (University of Trier)
>     for notifying us of the attacks and working with us both on
>     understanding the attacks and on developing mitigations.  Thanks
>     too to Hannes Tschofenig for organizing a meeting on this topic
>     last month and to Torsten Lodderstedt and Deutsche Telekom for
>     hosting the meeting.
>
>     P.S.  This note was also posted at http://self-issued.info/?p=1524
>     and as @selfissued <https://twitter.com/selfissued>.
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>
> Identity Services Engineering     Work:[email-masked] <mailto:[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: Mike Jones <[email-masked]>
Date: Mon, 11 Jan 2016 20:14:25 +0000

Correct

From: George Fletcher [mailto:[email-masked]]
Sent: Monday, January 11, 2016 12:13 PM
To: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

This specification requires the response from the Authorization Server to an successful /authorize call to pass back code=, state= and jwt= (?) or individually iss= and aud= as URL parameters on the 302 to the redirect_url. This way, before the client issues a call to the /token endpoint (with the code), it can verify that the token endpoint is correct.

If the client doesn't validate the endpoints at this step, then it could disclose it's secret to a malicious endpoint. Correct?

Thanks,
George

                                                          Thanks a bunch,
                                                          -- Mike

From: George Fletcher [mailto:[email-masked]]
Sent: Monday, January 11, 2016 10:21 AM
To: Mike Jones <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Thanks,
George

                                                          -- Mike

OAuth mailing list

--

Chief Architect

AOL Inc.                          AIM:  gffletch

--

Chief Architect

AOL Inc.                          AIM:  gffletch

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 11 Jan 2016 13:34:07 -0700

I disagree that validating endpoints "at this step" (which refers to 
right before making the token request) should be the default way of 
handling this. The vast majority of OAuth client deployments connecting 
to more than one AS will have a static configuration of the ASes 
issuer/endpoint information anyhow and they just need to confirm that 
the issuer value received in the authorization response is the same 
issuer as that the request was sent to.

Hans.

On 1/11/16 1:14 PM, Mike Jones wrote:
> *Sent:* Monday, January 11, 2016 12:13 PM
>     The alternatives for the code flow are to return them either in a
>     new JWT added to the reply containing them in the “iss” and “aud”
>     claims or to return them in new individual “client_id” and “iss”
>     authorization response parameters.  Both alternatives are described
>     in the draft.  I’m sure that we’ll now be having a good engineering
>     In a separate draft, John Bradley will shortly also be describing
>     the possibility of securing the “state” value using a “state_hash”
>     value that works in a way that’s similar to how “at_hash” and
>     “c_hash” secure the “access_token” and “code” values in Connect.
>     This would be an alternative means of binding the authorization
>     request and response to the session – accomplishing the same thing
>     that the Connect “nonce” does.
>
>     While I fully get that some OAuth implementations want to avoid
>     having to have crypto, it seems like at least support for
>     cryptographic hashing (SHA-256, etc.) may be necessary to mitigate
>     some of these attacks (at least for clients that use more than one
>     authorization server).
>
>     The other important engineering discussion I know we’re going to
>     have is whether, when an OAuth profile already returns the
>     information needed for the mitigation, whether we want to specify
>     that the client obtain it from the existing location, or whether to
>     also return it in a duplicate location.  I’ll note that OpenID
>     Connect already returns the client ID and issuer for the flows that
>     return an ID Token in the authorization response, so this isn’t a
>     hypothetical question.
>
>     Finally, I know that we’ll need to discuss the impact of
>     cut-and-paste attacks when the issuer and client ID are returned as
>     individual authorization response parameters that are not
>     cryptographically bound to the rest of the response.  The
>     cut-and-paste attack that returning the issuer and client_id values
>     as separate parameters enables, even when state_hash or nonce is
>     used, is for the attacker to capture the legitimate response
>     containing “iss” and “client_id” results and substitute different
>     values for these fields, then post that altered response to the
>     legitimate client.  The state and/or nonce values are protected
>     against substitution but “iss” and “client_id” are not.
>
>     And yes, I absolutely agree that good examples are essential.
>     That’s high on my list for the -01 version.
>
>                                                                Thanks a
>     bunch,
>
>                                                                -- Mike
>
>     *To:* Mike Jones <[email-masked]>
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     'state' parameters. It seems the client needs to verify the
>     endpoints before making the request to exchange the code for a
>     token. If the client is using the default OAuth2 client_id and
>     client_secret these values will be sent to the malicious endpoint if
>     the client can't verify the endpoints before hand.
>
>         provide a client using it with a consistent set of metadata
>         about itself. This information is returned in the authorization
>         attacks in which the client might otherwise be tricked into
>         using inconsistent sets of metadata from multiple authorization
>         servers, including potentially using a token endpoint that does
>         not belong to the same authorization server as the authorization
>         endpoint used. Recent research publications refer to these as
>         "IdP Mix-Up" and "Malicious Endpoint" attacks.
>
>         return the client ID and its issuer identifier (a value defined
>         in the OAuth Discovery specification
>         authorization server to a different one.  Note that these
>         attacks can only be made against clients that are configured to
>         use more than one authorization server.
>
>         solution.  Please definitely read the Security Considerations
>         and Open Issues sections, as they contain important information
>         about the choices made and the decisions remaining.
>
>         Special thanks go to Daniel Fett (University of Trier),
>         Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov
>         (Ruhr-University Bochum), and Guido Schmitz (University of
>         Trier) for notifying us of the attacks and working with us both
>         on understanding the attacks and on developing mitigations.
>         Thanks too to Hannes Tschofenig for organizing a meeting on this
>         topic last month and to Torsten Lodderstedt and Deutsche Telekom
>         for hosting the meeting.
>
>         P.S.  This note was also posted at
>         http://self-issued.info/?p=1524 and as @selfissued
>         <https://twitter.com/selfissued>.
>
>
>
>
>

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

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 Jan 2016 20:40:53 +0000

The specification describes this validation method (comparison of the issuer received to the issuer recorded at registration time) in step 2 of Section 4 (Validating the Response).  In fact, I added this in response to your feedback on an earlier draft, Hans.

-----Original Message-----
From: Hans Zandbelt [mailto:[email-masked]] 
Sent: Monday, January 11, 2016 12:34 PM
To: Mike Jones <[email-masked]>; George Fletcher <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

I disagree that validating endpoints "at this step" (which refers to right before making the token request) should be the default way of handling this. The vast majority of OAuth client deployments connecting to more than one AS will have a static configuration of the ASes issuer/endpoint information anyhow and they just need to confirm that the issuer value received in the authorization response is the same issuer as that the request was sent to.

Hans.

On 1/11/16 1:14 PM, Mike Jones wrote:
>     new JWT added to the reply containing them in the "iss" and "aud"
>     claims or to return them in new individual "client_id" and "iss"
>     in the draft.  I'm sure that we'll now be having a good engineering
>     the possibility of securing the "state" value using a "state_hash"
>     value that works in a way that's similar to how "at_hash" and
>     "c_hash" secure the "access_token" and "code" values in Connect.
>     request and response to the session - accomplishing the same thing
>     that the Connect "nonce" does.
>
>     The other important engineering discussion I know we're going to
>     also return it in a duplicate location.  I'll note that OpenID
>     return an ID Token in the authorization response, so this isn't a
>     hypothetical question.
>
>     Finally, I know that we'll need to discuss the impact of
>     containing "iss" and "client_id" results and substitute different
>     against substitution but "iss" and "client_id" are not.
>
>     That's high on my list for the -01 version.
>
>                                                                Thanks a
>     bunch,
>
>                                                                -- Mike
>
>         *http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>
>         *http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html
>
>                                                                    -- Mike
>

---

From: nov matake <[email-masked]>
Date: Tue, 12 Jan 2016 15:44:50 +0900

Hi Mike,

Isn’t Nat’s "OAuth Response Metadata” spec enough to solve those issues?
https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt <https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt>

> On Jan 12, 2016, at 05:40, Mike Jones <[email-masked]> wrote:
> 
> From: Hans Zandbelt [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>; George Fletcher <[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]>>
>>        <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>>.
>>        <http://self-issued.info/?p=1496 <http://self-issued.info/?p=1496>>) so that the client can verify
>>        *http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00>
>> 
>>        *http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html <http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html>
>> 
>>                                                                   -- Mike
>> 
>>        http://self-issued.info/?p=1524 <http://self-issued.info/?p=1524> and as @selfissued
>>        <https://twitter.com/selfissued <https://twitter.com/selfissued>>.
>> 
>> 
>> 
>> 
>> 
>>        [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>> 
>>        https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> 
>> 
>>    --
>> 
>>    Chief Architect
>> 
>>    Identity Services Engineering     Work:[email-masked] <mailto:[email-masked]> <mailto:[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/>
>> 
>> 
>> 
>> --
>> 
>> Chief Architect
>> 
>> Identity Services Engineering     Work:[email-masked] <mailto:[email-masked]> <mailto:[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/>
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
> 
> -- 
> [email-masked] <mailto:[email-masked]> | Ping Identity
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: George Fletcher <[email-masked]>
Date: Tue, 12 Jan 2016 11:09:15 -0500

If the endpoints are statically configured, does that in and of itself 
protect against most of the malicious endpoint attacks? There are other 
ways a client could protect against this malicious endpoint injection. 
However, I thought the point of the spec was to protect a client that 
truly supports any OP that is selected by a user of the app. In this 
case, the client doesn't have any pre-configured static endpoint values.

I suppose that if the client knows which issuer (i.e. AS) it's using to 
try and authenticate the client, then an issuer compare is sufficient to 
protect the client and the user. So to avoid having to do an endpoint 
check at this point, the client must maintain which "issuer" (from 
discovery) it's using for the authentication.

What was unclear to me from the spec is that the AS is required to add 
additional response parameters in the 302 response from the /authorize 
call. That will get clearer when the non-normative examples are added.

I am curious as to how many Authorization Servers out there have 
endpoints that don't match the issuer domain. Checking this at discovery 
time seems simpler if possible.

Thanks,
George

On 1/11/16 3:34 PM, Hans Zandbelt wrote:
> handling this. The vast majority of OAuth client deployments 
> connecting to more than one AS will have a static configuration of the 
> ASes issuer/endpoint information anyhow and they just need to confirm 
> that the issuer value received in the authorization response is the 
> same issuer as that the request was sent to.
>
> Hans.
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 21 Jan 2016 08:03:59 +0000

Sorry to be slow responding, Nov.  I wanted to wait to respond until a draft with the “state” token request parameter was published, which just happened.

I think the oauth-meta spec solves some of them but not others.  There were a bunch of different attacks discussed by the security researchers in Darmstadt (see the notes at https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit#heading=h.od92ummd22zs), some with interdependencies between them.  There are reasons, for instance, for sending the “state” value to the token endpoint so that the authorization server can check it.  The mitigations involve validations by both the client and the server – not all of which the oauth-meta draft includes.

Also, see the current discussion in the thread “[OAUTH-WG] Call for Adoption”.  In short, I think there should be one solution approach that we work on for this, not two.

                                                Best wishes,
                                                -- Mike

From: nov matake [mailto:[email-masked]]
Sent: Monday, January 11, 2016 10:45 PM
To: Mike Jones <[email-masked]>
Cc: Hans Zandbelt <[email-masked]>; George Fletcher <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Hi Mike,

Isn’t Nat’s "OAuth Response Metadata” spec enough to solve those issues?
https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt

On Jan 12, 2016, at 05:40, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Hans Zandbelt [mailto:[email-masked]]
Sent: Monday, January 11, 2016 12:34 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; George Fletcher <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Hans.

Correct

*From:*George Fletcher [mailto:[email-masked]]
*Sent:* Monday, January 11, 2016 12:13 PM
*To:* Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
*Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Thanks,
George

                                                              Thanks a
   bunch,

                                                              -- Mike

   *From:*George Fletcher [mailto:[email-masked]]
   *Sent:* Monday, January 11, 2016 10:21 AM
   *To:* Mike Jones <[email-masked]<mailto:[email-masked]>>
   <mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>
   *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

   Thanks,
   George

                                                                  -- Mike

       OAuth mailing list

       [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

   --

   Chief Architect

   Identity Services Engineering     Work:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

   AOL Inc.                          AIM:  gffletch

   Office: +1-703-265-2544           Photos:http://georgefletcher.photography<http://georgefletcher.photography/>

--

Chief Architect

Identity Services Engineering     Work:[email-masked]<mailto:[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]<mailto:[email-masked]> | Ping Identity

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 21 Jan 2016 11:47:27 +0000

Hi

On 11/01/16 19:59, Mike Jones wrote:
> JWT added to the reply containing them in the “iss” and “aud” claims or
> to return them in new individual “client_id” and “iss” authorization
> response parameters.  Both alternatives are described in the draft.  I’m
> sure that we’ll now be having a good engineering discussion on the
> tradeoffs between the alternatives.,
>
> that works in a way that’s similar to how “at_hash” and “c_hash” secure
> the “access_token” and “code” values in Connect.  This would be an
> alternative means of binding the authorization request and response to
> the session – accomplishing the same thing that the Connect “nonce” does.
>
> to have crypto, it seems like at least support for cryptographic hashing
> (SHA-256, etc.) may be necessary to mitigate some of these attacks (at
> least for clients that use more than one authorization server).
>

I'm not sure if it is relevant or misses the point, if so then my 
apologies, but I guess it is +1 to the *optional* hashing of the *whole* 
response as opposed to of some individual response properties. Awhile 
back I posted some proposal to use a JWK thumbprint idea to calculate a 
thumbprint of the response and sign in and include the result of it as 
an extra response property.

Cheers, Sergey

> The other important engineering discussion I know we’re going to have is
> whether, when an OAuth profile already returns the information needed
> for the mitigation, whether we want to specify that the client obtain it
> from the existing location, or whether to also return it in a duplicate
> location.  I’ll note that OpenID Connect already returns the client ID
> and issuer for the flows that return an ID Token in the authorization
> response, so this isn’t a hypothetical question.
>
> to the rest of the response. The cut-and-paste attack that returning the
> issuer and client_id values as separate parameters enables, even when
> state_hash or nonce is used, is for the attacker to capture the
>     itself. This information is returned in the authorization response.
>     It can be used by the client to prevent classes of attacks in which
>     the client might otherwise be tricked into using inconsistent sets
>     of metadata from multiple authorization servers, including
>     potentially using a token endpoint that does not belong to the same
>     authorization server as the authorization endpoint used. Recent
>     research publications refer to these as "IdP Mix-Up" and "Malicious
>     Endpoint" attacks.
>
>     the client ID and its issuer identifier (a value defined in the
>     OAuth Discovery specification <http://self-issued.info/?p=1496>) so
>     that the client can verify that it is using a consistent set of
>     authorization server configuration information, that the client ID
>     is for that authorization server, and in particular, that the client
>     is not being confused into sending information intended for one
>     describe both the mitigations and the decisions and analysis
>     remaining before we can be confident in standardizing a solution.
>     Please definitely read the Security Considerations and Open Issues
>     sections, as they contain important information about the choices
>     made and the decisions remaining.
>
>     the attacks and working with us both on understanding the attacks
>     and on developing mitigations.  Thanks too to Hannes Tschofenig for

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: Nov Matake <[email-masked]>
Date: Fri, 22 Jan 2016 11:29:15 +0900

I agree the state token param solves code/token replace attack.

However, I still don't think it’s a good idea to introduce "iss" to OAuth servers which aren't going to support discovery at this point.

For Mix-up mitigation, RP just need to know Token endpoint they should use (rel=next), or AuthZ endpoint they used (rel=self).

So adding “turi” (Token endpoint, rel=next) and/or “auri” (AuthZ endpoint, rel=selft) in the AuthZ response and let clients do exact matching with what RP already know seems much simpler.
(“auri" will be defined in the next Nat’s draft)

nov

On Jan 21, 2016, at 17:03, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:

> I think the oauth-meta spec solves some of them but not others.  There were a bunch of different attacks discussed by the security researchers in Darmstadt (see the notes at https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit#heading=h.od92ummd22zs <https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit#heading=h.od92ummd22zs>), some with interdependencies between them.  There are reasons, for instance, for sending the “state” value to the token endpoint so that the authorization server can check it.  The mitigations involve validations by both the client and the server – not all of which the oauth-meta draft includes.
>  
>   <>
> From: nov matake [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Hans Zandbelt <[email-masked] <mailto:[email-masked]>>; George Fletcher <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Jan 12, 2016, at 05:40, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>  
> *From:*George Fletcher [mailto:[email-masked] <mailto:[email-masked]>]
> *To:* Mike Jones <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>    *From:*George Fletcher [mailto:[email-masked] <mailto:[email-masked]>]
>    *To:* Mike Jones <[email-masked] <mailto:[email-masked]>>