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

From: Mike Jones <[email-masked]>
Date: Thu, 21 Jan 2016 06:28:05 +0000

John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up Mitigation draft.  Changes were:

*       Simplified by no longer specifying the signed JWT method for returning the mitigation information.

*       Simplified by no longer depending upon publication of a discovery metadata document.

*       Added the "state" token request parameter.

*       Added examples.

*       Added John Bradley as an editor.

The specification is available at:

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

An HTML-formatted version is also available at:

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

                                                          -- Mike

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

---

From: John Bradley <[email-masked]>
Date: Thu, 21 Jan 2016 11:41:31 -0300

We merged the state verification in with this rather than forcing people to also look at the JWT encoded State draft.  https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state.  

While JWT encoded state is how I would do state in a client and at-least one client I know of uses it, it is not the only way to manage state, and I am hesitant that developers might be scared away by thinking they need to encode state as a JWT.

I decided that cross referencing them is better.   This made sending much simpler to describe.   

I also removed the hashing from state.   That cut the text by about 2/3 by not having to describe character set normalization so that both the client and the AS could calculate the same hash.
That also achieved the goal of not requiring a simple OAuth client doing the code flow to add a crypto library to support SHA256.

Once we make a algorithm mandatory, we need to defend why we don’t have crypto agility eg support for SHA3 etc.  We would be forced by the IESG to add another parameter to the request to specify the hash alg if we went that direction.

Given that we assume state to be public info in the request that an attacker can see, hashing state provides not much value for a lot of complexity that people may get wrong or not implement.

I appreciate why from a theory point of view hashing it would have been better.

If people really want it I can add it back.

John B.

> On Jan 21, 2016, at 3:28 AM, Mike Jones <[email-masked]> wrote:
> 
> ·       Simplified by no longer specifying the signed JWT method for returning the mitigation information.
> ·       Simplified by no longer depending upon publication of a discovery metadata document.
> ·       Added the “state” token request parameter.
> ·       Added examples.
> ·       Added John Bradley as an editor.
>  
> ·       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01>
>  
> ·       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html <http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html>
>  
>                                                           -- Mike
>  
> P.S.  This note was also posted at http://self-issued.info/?p=1526 <http://self-issued.info/?p=1526> and as @selfissued <https://twitter.com/selfissued>.
>  
> _______________________________________________
> OAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Justin Richer <[email-masked]>
Date: Thu, 21 Jan 2016 13:58:49 -0500

Thank you for removing state hashing and please don’t add it back. It’s security theater, and that’s giving it the benefit of the doubt. Remember, this is being sent in a  request where other parameters (code, client_id, client_secret, redirect_uri) are all sent plain over TLS as well. Either come up with a general mechanism to hash everything or don’t hash anything. The latter is more likely to win, and it’s the only thing that makes sense currently.

Also, keep in mind that if the client hashes the state on the second request, then the server can’t store the state parameter using its own hash methods (for data-at-rest protection) and still be able to do the comparison. Having the client send it over plain is really better all around in terms of simplicity and adoptability.

Now if we really wanted to have message-level protection of HTTP requests, I can think of a good way to do that…

 — Justin

> On Jan 21, 2016, at 9:41 AM, John Bradley <[email-masked]> wrote:
> 
> We merged the state verification in with this rather than forcing people to also look at the JWT encoded State draft.  https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state <https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state>.
> 
>> On Jan 21, 2016, at 3:28 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 21 Jan 2016 16:15:34 -0300

The server could hash the state using the same algorithm the client uses if the client passed that as well.

I see lots of things being fragile about that.

The draft allows the server to use whatever hash it wants to internally to compare them.  Given that we are detecting tamping and don’t need to worry about collisions as the state should have it’s own integrity protection you could probably get away with MD5 on the server.  Though I don’t think saying that in a spec would be a good idea:)

I am being sensitive, because I am changing a decision that was agreed to by the group in Germany.   I want people to know it was changed, so they can provide feedback if they feel strongly.

John B.

> On Jan 21, 2016, at 3:58 PM, Justin Richer <[email-masked]> wrote:
> 
>> On Jan 21, 2016, at 9:41 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 21 Jan 2016 14:18:47 -0500

Just because there’s a potential workaround doesn’t mean this is a good idea, especially when you can easily avoid the need for workarounds in the first place. :)

 — Justin

> On Jan 21, 2016, at 2:15 PM, John Bradley <[email-masked]> wrote:
> 
>> On Jan 21, 2016, at 3:58 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Hans Zandbelt <[email-masked]>
Date: Thu, 21 Jan 2016 20:24:56 +0100

Note that the argument was not about message-level protection: it was 
about not disclosing the state value verbatim over the token endpoint.

I don't feel strongly about it either; it was just what was agreed at 
first. Since no-one actually came up with even a hypothetical attack I 
guess it makes sense to revert that decision.

Hans.

On 1/21/16 7:58 PM, Justin Richer wrote:
> Thank you for removing state hashing and please don’t add it back. It’s
> security theater, and that’s giving it the benefit of the doubt.
> Remember, this is being sent in a  request where other parameters (code,
> client_id, client_secret, redirect_uri) are all sent plain over TLS as
> well. Either come up with a general mechanism to hash everything or
> don’t hash anything. The latter is more likely to win, and it’s the only
> thing that makes sense currently.
>
> Also, keep in mind that if the client hashes the state on the second
> request, then the server can’t store the state parameter using its own
> hash methods (for data-at-rest protection) and still be able to do the
> comparison. Having the client send it over plain is really better all
> around in terms of simplicity and adoptability.
>
> Now if we really wanted to have message-level protection of HTTP
> requests, I can think of a good way to do that…
>
>   — Justin
>
>
>> We merged the state verification in with this rather than forcing
>> people to also look at the JWT encoded State draft.
>> https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state.
>>
>> While JWT encoded state is how I would do state in a client and
>> at-least one client I know of uses it, it is not the only way to
>> manage state, and I am hesitant that developers might be scared away
>> by thinking they need to encode state as a JWT.
>>
>> I also removed the hashing from state.   That cut the text by about
>> 2/3 by not having to describe character set normalization so that both
>> the client and the AS could calculate the same hash.
>> That also achieved the goal of not requiring a simple OAuth client
>> doing the code flow to add a crypto library to support SHA256.
>>
>> Once we make a algorithm mandatory, we need to defend why we don’t
>> have crypto agility eg support for SHA3 etc.  We would be forced by
>> the IESG to add another parameter to the request to specify the hash
>> alg if we went that direction.
>>
>> Given that we assume state to be public info in the request that an
>> attacker can see, hashing state provides not much value for a lot of
>> complexity that people may get wrong or not implement.
>>
>>> On Jan 21, 2016, at 3:28 AM, Mike Jones <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>> ·Simplified by no longer specifying the signed JWT method for
>>> returning the mitigation information.
>>> ·Simplified by no longer depending upon publication of a discovery
>>> metadata document.
>>> ·Added the “state” token request parameter.
>>> ·Added examples.
>>> ·Added John Bradley as an editor.
>>> ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>>> ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html
>>>                                                           -- Mike
>>> P.S.  This note was also posted
>>> athttp://self-issued.info/?p=1526andas@selfissued
>>> <https://twitter.com/selfissued>.

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

---

From: Justin Richer <[email-masked]>
Date: Thu, 21 Jan 2016 14:42:01 -0500

Hans,

Thanks; while I see the argument, my counter argument was to ask for a situation where you’d want to protect the state value but not code, client_secret, redirect_uri, and everything else in the request. If you actually want to protect all of that, it’s better to have a message-level protection mechanism instead of a piecemeal solution.

 — Justin

> On Jan 21, 2016, at 2:24 PM, Hans Zandbelt <[email-masked]> wrote:
> 
> Note that the argument was not about message-level protection: it was about not disclosing the state value verbatim over the token endpoint.
> 
> I don't feel strongly about it either; it was just what was agreed at first. Since no-one actually came up with even a hypothetical attack I guess it makes sense to revert that decision.
> 
> Hans.
>

---

From: David Waite <[email-masked]>
Date: Thu, 21 Jan 2016 12:48:47 -0700

Question: 

I understand how “iss" helps mitigate this attack (client knows response was from the appropriate issuer and not an attack where the request was answered by another issuer). 

However, how does passing “state” on the authorization_code grant token request help once you have the above in place? Is this against some alternate flow of this attack I don’t see, or is it meant to mitigate some entirely separate attack?

If one is attempting to work statelessly (e.g. your “state” parameter is actual state and not just a randomly generated value), a client would have always needed some way to differentiate which issuer the authorization_code grant token request would be sent to.

However, if an AS was treating “code” as a token (for instance, encoding: client, user, consent time and approved scopes), the AS now has to include the client’s state as well. This would effectively double (likely more with encoding) the state sent in the authorization response back to the client redirect URL, adding more pressure against maximum URL sizes.

-DW

> On Jan 20, 2016, at 11:28 PM, Mike Jones <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Thu, 21 Jan 2016 18:50:27 -0300

Yes if the AS is encoding state + redirect_uri and grants in the code then it could get big.  
In that case you probably would put a hash of the state in the code to manage size.  The alg would be up to the AS, as long as it used the same hash both places it would work.

Sending the state to the token endpoint is like having nonce and c_hash in the id_token, it binds the issued code to the browser instance.

This protects against codes that leak via redirect uri pattern matching. failures etc.  It prevents an attacker from being able to replay a code from a different browser.

If the client implements the other mitigations on the authorization endpoint, then it wouldn't be leaking the code via the token endpoint. 

The two mitigations are for different attacks, however some of the attacks combined both vulnerabilities.

Sending the iss and client_id is enough to stop the confused client attacks, but sending state on its own would not have stopped all of them.

We discussed having them in separate drafts, and may still do that.   However for discussion having them in one document is I think better in the short run.

John B.

> On Jan 21, 2016, at 4:48 PM, David Waite <[email-masked]> wrote:
> 
> Question: 
> 
>> On Jan 20, 2016, at 11:28 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: David Waite <[email-masked]>
Date: Thu, 21 Jan 2016 21:22:39 -0700

> On Jan 21, 2016, at 2:50 PM, John Bradley <[email-masked]> wrote:
> 
Yes, true. 
> Sending the state to the token endpoint is like having nonce and c_hash in the id_token, it binds the issued code to the browser instance.
I think I understand what you are saying. Someone won’t be able to frankenstein up a state and a token from two different responses from an AS, and have a client successfully fetch an access token based on the amalgamation.
 
> This protects against codes that leak via redirect uri pattern matching. failures etc.  It prevents an attacker from being able to replay a code from a different browser.
Yes, if a party intercepts the redirect_url, or the AS fails to enforce one time use (which even for a compliant implementation could just mean the attacker was faster than the state propagated within the AS)

Makes sense. Thanks John.

-DW

>> On Jan 21, 2016, at 4:48 PM, David Waite <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Question: 
>>

---

From: John Bradley <[email-masked]>
Date: Fri, 22 Jan 2016 09:45:20 -0300

Perhaps Frankenstein response is a better name than cut and paste attack.

John B.
On Jan 22, 2016 1:22 AM, "David Waite" <[email-masked]> wrote:

> In that case you probably would put a hash of the state in the code to
> manage size.  The alg would be up to the AS, as long as it used the same
> hash both places it would work.
>
> Yes, true.
>
>
> Sending the state to the token endpoint is like having nonce and c_hash in
> the id_token, it binds the issued code to the browser instance.
>
> I think I understand what you are saying. Someone won’t be able to
> frankenstein up a state and a token from two different responses from an
> AS, and have a client successfully fetch an access token based on the
> amalgamation.
>
>
> This protects against codes that leak via redirect uri pattern matching.
> failures etc.  It prevents an attacker from being able to replay a code
> from a different browser.
>
> Yes, if a party intercepts the redirect_url, or the AS fails to enforce
> one time use (which even for a compliant implementation could just mean the
> attacker was faster than the state propagated within the AS)
>
> If the client implements the other mitigations on the authorization
> endpoint, then it wouldn't be leaking the code via the token endpoint.
>
> Sending the iss and client_id is enough to stop the confused client
> attacks, but sending state on its own would not have stopped all of them.
>
> We discussed having them in separate drafts, and may still do that.
> However for discussion having them in one document is I think better in the
> short run.
>
> John B.
>
> I understand how “iss" helps mitigate this attack (client knows response
> was from the appropriate issuer and not an attack where the request was
> answered by another issuer).
>
> However, how does passing “state” on the authorization_code grant token
> request help once you have the above in place? Is this against some
> alternate flow of this attack I don’t see, or is it meant to mitigate some
> entirely separate attack?
>
> If one is attempting to work statelessly (e.g. your “state” parameter is
> actual state and not just a randomly generated value), a client would have
> always needed some way to differentiate which issuer the authorization_code
> grant token request would be sent to.
>
> However, if an AS was treating “code” as a token (for instance, encoding:
> client, user, consent time and approved scopes), the AS now has to include
> the client’s state as well. This would effectively double (likely more with
> encoding) the state sent in the authorization response back to the client
> redirect URL, adding more pressure against maximum URL sizes.
>
> -DW
>
>

---

From: William Denniss <[email-masked]>
Date: Fri, 22 Jan 2016 13:11:24 +0000

+1 ;)
On Fri, Jan 22, 2016 at 8:45 PM John Bradley <[email-masked]> wrote:

>> Sending the state to the token endpoint is like having nonce and c_hash
>> in the id_token, it binds the issued code to the browser instance.
>>

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 22 Jan 2016 16:32:43 +0000

Hi John,

Le jeu. 21 janv. 2016 15:42, John Bradley <[email-masked]> a écrit :

> We merged the state verification in with this rather than forcing people
> to also look at the JWT encoded State draft.
> While JWT encoded state is how I would do state in a client and at-least
> one client I know of uses it, it is not the only way to manage state,
>

And not how I'd do it (unless you convince me that jwt is really better and
the advantages outweigh the network bloat)

and I am hesitant that developers might be scared away by thinking they
> need to encode state as a JWT.
>

Wouldn't linking to RFC 6819 be enough?

I also removed the hashing from state.   That cut the text by about 2/3 by
> not having to describe character set normalization so that both the client
> and the AS could calculate the same hash.
> That also achieved the goal of not requiring a simple OAuth client doing
> the code flow to add a crypto library to support SHA256.
>
> Once we make a algorithm mandatory, we need to defend why we don’t have
> crypto agility eg support for SHA3 etc.  We would be forced by the IESG to
> add another parameter to the request to specify the hash alg if we went
> that direction.
>
> ·       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>
> ·
> http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html
>
>                                                           -- Mike
>
> P.S.  This note was also posted at http://self-issued.info/?p=1526 and as
> @selfissued <https://twitter.com/selfissued>.
>

---

From: John Bradley <[email-masked]>
Date: Fri, 22 Jan 2016 13:58:04 -0300

I agree that using a JWT is not the only way to do it, however many clients were not sending state at all or doing something insecure.

Particularly some people were having trouble with AS like Google who do exact redirect_uri matching and not being able to see how to pass multiple parameters in state rather then tacking extra query parameters on to the redirect_uri.

Documenting how to do it with a JWT and some of the security considerations specific to crating a useful state value has been useful to some people.

RFC 6819 has only a short section on state.

3.6 <https://tools.ietf.org/html/rfc6819#section-3.6>.  "state" Parameter

   The "state" parameter is used to link requests and callbacks to
   prevent cross-site request forgery attacks (see Section 4.4.1.8 <https://tools.ietf.org/html/rfc6819#section-4.4.1.8>)
   where an attacker authorizes access to his own resources and then
   tricks a user into following a redirect with the attacker's token.
   This parameter should bind to the authenticated state in a user agent
   and, as per the core OAuth spec, the user agent must be capable of
   keeping it in a location accessible only by the client and user
   agent, i.e., protected by same-origin policy.

That is a bit hand wavy for some developers who wanted examples.

In any event I think we agree that dragging the whole JWT signed state draft into the checking state mitigation.

The mitigation makes checking the integrity of state by the client signing less important, as tampering with the value would be detected by the server in the code flow.

Perhaps as we develop the mitigation spec we could move some of the more critical advice on how to bind the browser instance to the state over to the mitigation draft.

John B.

> On Jan 22, 2016, at 1:32 PM, Thomas Broyer <[email-masked]> wrote:
> 
> 
> Hi John,
> 
> 
> Le jeu. 21 janv. 2016 15:42, John Bradley <[email-masked] <mailto:[email-masked]>> a écrit :
> While JWT encoded state is how I would do state in a client and at-least one client I know of uses it, it is not the only way to manage state,
> 
> And not how I'd do it (unless you convince me that jwt is really better and the advantages outweigh the network bloat)
> 
> and I am hesitant that developers might be scared away by thinking they need to encode state as a JWT.
>

---

From: George Fletcher <[email-masked]>
Date: Fri, 22 Jan 2016 12:02:46 -0500

"Frankensteinian Amalgamation" -- David Waite

I like it! :)

On 1/22/16 8:11 AM, William Denniss wrote:
> +1 ;)
> On Fri, Jan 22, 2016 at 8:45 PM John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Jan 22, 2016 1:22 AM, "David Waite"
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>         On Jan 21, 2016, at 2:50 PM, John Bradley <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>         In that case you probably would put a hash of the state in
>>         the code to manage size.  The alg would be up to the AS, as
>>         long as it used the same hash both places it would work.
>         Yes, true.
>>
>>         Sending the state to the token endpoint is like having nonce
>>         and c_hash in the id_token, it binds the issued code to the
>>         browser instance.
>         I think I understand what you are saying. Someone won’t be
>         able to frankenstein up a state and a token from two different
>         responses from an AS, and have a client successfully fetch an
>         access token based on the amalgamation.
>>         This protects against codes that leak via redirect uri
>>         pattern matching. failures etc.  It prevents an attacker from
>>         being able to replay a code from a different browser.
>         Yes, if a party intercepts the redirect_url, or the AS fails
>         to enforce one time use (which even for a compliant
>         implementation could just mean the attacker was faster than
>         the state propagated within the AS)
>
>>         If the client implements the other mitigations on the
>>         authorization endpoint, then it wouldn't be leaking the code
>>         via the token endpoint.
>>
>>         The two mitigations are for different attacks, however some
>>         of the attacks combined both vulnerabilities.
>>
>>         Sending the iss and client_id is enough to stop the confused
>>         client attacks, but sending state on its own would not have
>>         stopped all of them.
>>
>>         We discussed having them in separate drafts, and may still do
>>         that.   However for discussion having them in one document is
>>         I think better in the short run.
>>
>>         John B.
>>
>>>         On Jan 21, 2016, at 4:48 PM, David Waite
>>>         <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>
>>>         Question:
>>>
>>>         I understand how “iss" helps mitigate this attack (client
>>>         knows response was from the appropriate issuer and not an
>>>         attack where the request was answered by another issuer).
>>>
>>>         However, how does passing “state” on the authorization_code
>>>         grant token request help once you have the above in place?
>>>         Is this against some alternate flow of this attack I don’t
>>>         see, or is it meant to mitigate some entirely separate attack?
>>>
>>>         If one is attempting to work statelessly (e.g. your “state”
>>>         parameter is actual state and not just a randomly generated
>>>         value), a client would have always needed some way to
>>>         differentiate which issuer the authorization_code grant
>>>         token request would be sent to.
>>>
>>>         However, if an AS was treating “code” as a token (for
>>>         instance, encoding: client, user, consent time and approved
>>>         scopes), the AS now has to include the client’s state as
>>>         well. This would effectively double (likely more with
>>>         encoding) the state sent in the authorization response back
>>>         to the client redirect URL, adding more pressure against
>>>         maximum URL sizes.
>>>
>>>         -DW
>

-- 
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: David Waite <[email-masked]>
Date: Fri, 22 Jan 2016 10:54:07 -0700

It’s pronounced FronkenSTEEN-ian.

-DW

> On Jan 22, 2016, at 10:02 AM, George Fletcher <[email-masked]> wrote:
> 
>> On Fri, Jan 22, 2016 at 8:45 PM John Bradley < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>> On Jan 22, 2016 1:22 AM, "David Waite" <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Jan 21, 2016, at 2:50 PM, John Bradley < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> 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: John Bradley <[email-masked]>
Date: Fri, 22 Jan 2016 15:57:08 -0300

Now that we have a cool name all we need is a logo for the attack and per haps an anime character, and we are done with all the hard work:)

John B.
> On Jan 22, 2016, at 2:54 PM, David Waite <[email-masked]> wrote:
> 
>> On Jan 22, 2016, at 10:02 AM, George Fletcher <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Paul Madsen <[email-masked]>
Date: Fri, 22 Jan 2016 14:00:14 -0500

tshirt or it didnt happen

On 1/22/16 1:57 PM, John Bradley wrote:
> Now that we have a cool name all we need is a logo for the attack and 
> per haps an anime character, and we are done with all the hard work:)
>
> John B.
>> On Jan 22, 2016, at 2:54 PM, David Waite 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>
>>>>>         the code to manage size.  The alg would be up to the AS,
>>>>>         as long as it used the same hash both places it would work.
>>>>         Yes, true.
>>>>>
>>>>>         Sending the state to the token endpoint is like having
>>>>>         nonce and c_hash in the id_token, it binds the issued code
>>>>>         to the browser instance.
>>>>         able to frankenstein up a state and a token from two
>>>>         different responses from an AS, and have a client
>>>>         successfully fetch an access token based on the amalgamation.
>>>>>         pattern matching. failures etc.  It prevents an attacker
>>>>>         from being able to replay a code from a different browser.
>>>>         Yes, if a party intercepts the redirect_url, or the AS
>>>>         fails to enforce one time use (which even for a compliant
>>>>>         authorization endpoint, then it wouldn't be leaking the
>>>>>         code via the token endpoint.
>>>>>
>>>>>         The two mitigations are for different attacks, however
>>>>>         some of the attacks combined both vulnerabilities.
>>>>>
>>>>>         Sending the iss and client_id is enough to stop the
>>>>>         confused client attacks, but sending state on its own
>>>>>         would not have stopped all of them.
>>>>>
>>>>>         We discussed having them in separate drafts, and may still
>>>>>         do that.   However for discussion having them in one
>>>>>         document is I think better in the short run.
>>>>>
>>>>>         John B.
>>>>>
>>>>>>         However, how does passing “state” on the
>>>>>>         authorization_code grant token request help once you have
>>>>>>         the above in place? Is this against some alternate flow
>>>>>>         of this attack I don’t see, or is it meant to mitigate
>>>>>>         some entirely separate attack?
>>>>>>
>>>>>>         If one is attempting to work statelessly (e.g. your
>>>>>>         “state” parameter is actual state and not just a randomly
>>>>>>         generated value), a client would have always needed some
>>>>>>         way to differentiate which issuer the authorization_code
>>>>>>         instance, encoding: client, user, consent time and
>>>>>>         approved scopes), the AS now has to include the client’s
>>>>>>         state as well. This would effectively double (likely more
>>>>>>         with encoding) the state sent in the authorization
>>>>>>         response back to the client redirect URL, adding more
>>>>>>         pressure against maximum URL sizes.
>>>>>>
>>>>>>         -DW
>>>>
>>> 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: George Fletcher <[email-masked]>
Date: Fri, 22 Jan 2016 14:05:46 -0500

Isn't that your department Paul? I have high expectations!

On 1/22/16 2:00 PM, Paul Madsen wrote:
>>> <[email-masked]> wrote:
>>>
>>>>>     <[email-masked]> wrote:
>>>>>
>>>>>>         In that case you probably would put a hash of the state
>>>>>>         in the code to manage size.  The alg would be up to the
>>>>>>         AS, as long as it used the same hash both places it would
>>>>>>         work.
>>>>>         Yes, true.
>>>>>>
>>>>>>         nonce and c_hash in the id_token, it binds the issued
>>>>>>         code to the browser instance.
>>>>>         implementation could just mean the attacker was faster
>>>>>         than the state propagated within the AS)
>>>>>
>>>>>>         We discussed having them in separate drafts, and may
>>>>>>         still do that.   However for discussion having them in
>>>>>>         one document is I think better in the short run.
>>>>>>
>>>>>>         John B.
>>>>>>
>>>>>>>         <[email-masked]> wrote:
>>>>>>>
>>>>>>>         Question:
>>>>>>>
>>>>>>>         I understand how “iss" helps mitigate this attack
>>>>>>>         (client knows response was from the appropriate issuer
>>>>>>>         and not an attack where the request was answered by
>>>>>>>         another issuer).
>>>>>>>
>>>>>>>         authorization_code grant token request help once you
>>>>>>>         have the above in place? Is this against some alternate
>>>>>>>         flow of this attack I don’t see, or is it meant to
>>>>>>>         mitigate some entirely separate attack?
>>>>>>>
>>>>>>>         “state” parameter is actual state and not just a
>>>>>>>         randomly generated value), a client would have always
>>>>>>>         needed some way to differentiate which issuer the
>>>>>>>         authorization_code grant token request would be sent to.
>>>>>>>
>>>>>>>         state as well. This would effectively double (likely
>>>>>>>         more with encoding) the state sent in the authorization

---

From: Roland Hedberg <[email-masked]>
Date: Sat, 23 Jan 2016 15:26:54 +0000

+1  :-)

> 22 jan 2016 kl. 20:05 skrev George Fletcher <[email-masked]>:
>

---

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

Thanks for the write up John and Mike!

1. Editorial: I'd add something like the following to the last paragraph 
in section 2. "However, if the authorization server does not support 
OAuth Discovery, then it MUST publicly define it's AS issuer URI." The 
point being that the client has to have a way to obtain this value so 
that it can compare it later on in the protocol.

2. Question: If OAuth2 discovery is not required, how does a simple 
issuer compare prevent the attack? It seems like the malicious AS could 
get the client to statically configure Good Issuer, Good AuthZ, Bad 
Token endpoint and assign the client a client_id that is valid at the 
Good AS. When the Good AS returns the response data it would include 
it's iss and the client_id which would match and the client would still 
send the code and client credentials to the Bad AS. I believe that 
supporting OAuth discovery is going to be required to fully mitigate 
this attack.

3. Question: In section 7.3 the phrase "unsigned cookie" is used but 
it's not clear exactly what that means. While the attacker can set 
cookies in the forged response, they shouldn't be able to set cookies on 
the specific domain of the AS. If the cookie identifying the AS session 
is HTTP Only and Secure, then the attacker should not be able to see or 
forge a value for this cookie. The attacker could bypass the browser 
completely and just forge a request to the client specifying whatever 
values they like. These could be taken from a valid session the attacker 
created and can see from their browser. It seems like the key protection 
in this case is binding the state value into the code so the code can't 
be substituted.

Thanks,
George

On 1/21/16 1:28 AM, Mike Jones wrote:
> P.S.  This note was also posted athttp://self-issued.info/?p=1526 and 
> as @selfissued <https://twitter.com/selfissued>.
>
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 26 Jan 2016 21:10:07 +0100

Hi Mike,

I really like the new revision since it is much simpler :-)

My comments:

I'm fine with describing all mitigations we talked about in Darmstadt in 
one/this spec. But the state check at the tokens endpoint is supposed to 
be a mitigation against code injection/cut and paste attack, which is 
not directly related to IDP/AS mix up. So I would suggest to change the 
name of the spec, probably "OAuth security extensions"?

I think the code injection/cut and paste attack should be described more 
extensively in the introduction. It's important for the reader to 
understand, why this mitigation is defined at all. Moreover, I think the 
description of the mitigation is still incomplete/spread over the 
document. In order to detect code injection, the RP not only needs to 
send the state to the tokens endpoint, it also needs to (directly or 
indirectly) _bind_ the state to the particular user agent (session). 
Otherwise, the attacker can inject the state along with the solen code 
easily. I would suggest to merge

          "To prevent replay of the state in another browser instance by 
an attacker, the state value MUST be tied to the browser instance in a 
way that cannot be forged by an attacker. Section 4 of 
[I‑D.bradley‑oauth‑jwt‑encoded‑state]
          provides several examples of how a client can accomplish this."

into section 5.

I thought we had discussed to also give implementors a guideline on 
using state to prevent CSRF as well? How will we take care of that topic?

kinds regards,
Torsten.

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 26 Jan 2016 14:00:41 -0800

Agreed. 

The security ext draft might fit well with the general grab bag of issues around all the "dynamic" cases. 

It would be stronger than a new threat model ext draft which would likely be informational. 

Phil

> On Jan 26, 2016, at 12:10, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Mike,
> 
> I'm fine with describing all mitigations we talked about in Darmstadt in one/this spec. But the state check at the tokens endpoint is supposed to be a mitigation against code injection/cut and paste attack, which is not directly related to IDP/AS mix up. So I would suggest to change the name of the spec, probably "OAuth security extensions"?
> 
> I think the code injection/cut and paste attack should be described     more extensively in the introduction. It's important for the reader to understand, why this mitigation is defined at all. Moreover, I think the description of the mitigation is still incomplete/spread over the document. In order to detect code injection, the RP not only needs to send the state to the tokens endpoint, it also needs to (directly or indirectly) _bind_ the state to the particular user agent (session). Otherwise, the attacker can inject the state along with the solen code easily. I would suggest to merge
> 
>          "To prevent replay of the state in another browser instance by an attacker, the state value MUST be tied to the browser instance in a way that cannot be forged by an attacker. Section 4 of [I‑D.bradley‑oauth‑jwt‑encoded‑state]    
> I thought we had discussed to also give implementors a guideline on using state to prevent CSRF as well? How will we take care of that topic? 
> 
> kinds regards,
> Torsten.
> 
> 
>> ·       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html
>>  
>>                                                           -- Mike
>>  
>> P.S.  This note was also posted at http://self-issued.info/?p=1526 and as @selfissued.
>>  
>> 
>>