Subject: [OAUTH-WG] Auth Code Swap Attack

From: Anthony Nadalin <[email-masked]>
Date: Fri, 12 Aug 2011 19:06:36 +0000

Here is an attack that Yaron, Torsten, Phil and I have documented which shows that there is a protocol flaw that needs to be corrected; the proposed text changes are also included.

Auth Code Swap Attack
This attack describes a phishing attempt where an attacker "gives" away access to a resource controlled by the attacker in order to compromise a client application.

Dramatis personae
Plaxo - An OAuth client. It asks its users to use OAuth to give Plaxo permission to access their address books in various services like Live. It uses the permissions to synch address books in remote services like Live's with the central address book kept in Plaxo.

Live - A resource server. It accepts authorization requests from clients to allow them access to protected resources. Those protected resources are address books owned by Live's users.

Gene - Gene is a user of both Plaxo and Live. Gene wants to use Plaxo to keep his address book at Live up to date.

Basil - Basil is an evil doer. His desire is to steal the contents of Live user's address books for marketing and other purposes.

Attack setup
Basil creates an account at Live.
Basil creates a website called 'Silly Fun Times'

The actual attack
1.            Basil sends spam to various victims trying to get them to come to his 'Silly Fun Times' website.
2.            Gene opens the spam mail and clicks on the link.
3.            The server running Basil's website initiates an authorization request to Live. The request uses Plaxo's redirection URI. The code running on Basil's server uses Basil's Live credentials to login to Live and to grant the authorization request. Live responds with a redirect containing an authorization code. Basil's server swallows the redirect and creates a web page containing the authorization code and sends the web page down to Gene's browser. [Note: Normally the actions in step 3 would be performed by a human at a browser but in the attack Basil has automated the process so his attack server can do everything automatically.]
4.            The web page, from 'Silly Fun Times', running on Gene's browser now completes the redirect sending Gene, using the authorization code that Live issues in response to Basil's request, to Plaxo.
5.            Gene is already logged into Plaxo so he isn't even asked anything before Plaxo accepts the redirect with the authorization code.
6.            Plaxo's server then uses the authorization code to get an access token and refresh token.
7.            Plaxo uses the access token to synchronize the address book on Basil's Live account with Gene's Plaxo server.

The outcome of step 7 is two separate attacks. One attack is that Plaxo will now push all of Gene's address book information into Basil's Live account. So Basil has now successfully stolen all of Gene's address book data. The other attack is that if Plaxo is doing bi-directional synch then Basil could put false contacts (perhaps with bad URLs to launch various types of attacks) and related information into Gene's central address book at Plaxo.

Variations:
1a. Basil could buy ads on search services like Bing and Google and use those as a way to lure people to the 'Silly Fun Times' website.
5a. Gene might not be logged into Plaxo but if 'Silly Fun Times' sets things up right it could fool Gene into thinking he is supposed to see Plaxo and so will handle the login.

There is an obvious variation of this attack for auth tokens rather than auth codes.

Pretty picture
The numbers in the picture are keyed to the steps in the use case above.

[Description: Description: Description: cid:[email-masked]]
Recommended Changes to draft-ietf-oauth-v2

In section 4, request options (e.g. 4.1.1) featuring "state" should change from:

state
OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.

to:

state
REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the  request (see section 10.12). The value MUST NOT be guessable or predictable, and MUST be kept confidential.

Section 10.12 Cross-Site Request Forgery

Change to:

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to inject their own authorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the "state" parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parameter when redirecting the user-agent back to the client. Upon receiving a redirect, the client application MUST confirm that returned value of "state" corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has NOT changed.

Yaron, Torsten, Phil and Tony

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 12 Aug 2011 14:52:45 -0700

This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week.

The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful.

As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below.

From: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] Auth Code Swap Attack

state

to:

state

Making the parameter required without making its usage required (I.e. "value SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confidential" mean? Confidential from what? Why specify an "encoded value"?

Change to:

The above text uses 'user-context' and this 'user-identity'. Neither term is defined.

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 13 Aug 2011 08:58:02 +0200

Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav:
> This is really just a flavor of CSRF attacks. I have no objections to 
> better documenting it (though I feel the current text is already 
> sufficient), but we can't realistically expect to identify and close 
> every possible browser-based attack. A new one is invented every other 
> week.
>
> The problem with this text is that developers who do no understand 
> CSRF attacks are not likely to implement it correctly with this 
> information. Those who understand it do not need the extra verbiage 
> which is more confusing than helpful.

We are constantly facing the fact that a comprehensive description of 
security threats needs more space than we have in the core draft. That's 
the reason why the security document has 63 pages and that's also the 
reason why we decided to let the core spec refer to this document for 
in-depth explanations. This holds true for this threat as well.

regards,
Torsten.

>
> As for the new requirements, they are insufficient to actually 
> accomplish what the authors propose without additional requirements on 
> state local storage and verification to complete the flow. Also, the 
> proposed text needs clarifications as noted below.
>
>
> To: "OAuth WG ([email-masked] <mailto:[email-masked]>)" 
> <[email-masked] <mailto:[email-masked]>>
>     *Recommended Changes to draft-ietf-oauth-v2*
>
>     OPTIONAL. An opaque value used by the client to maintain state
>     between the request and callback. The authorization server
>     includes this value when redirecting the user-agent back to the
>     client.
>
>     to:
>
>     state
>
>     REQUIRED. An opaque value used by the client to maintain state
>     between the request and callback. The authorization server
>     includes this value when redirecting the user-agent back to the
>     client. The encoded value SHOULD enable the client application to
>     determine the user-context that was active at the time of the
>      request (see section 10.12). The value MUST NOT be guessable or
>     predictable, and MUST be kept confidential.
>
>
> Making the parameter required without making its usage required (I.e. 
> "value SHOULD enable") accomplishes nothing. Also, what does "MUST be 
> kept confidential" mean? Confidential from what? Why specify an 
> "encoded value"?
>
>
>     Cross-site request forgery (CSRF) is a web-based attack whereby
>     HTTP requests are transmitted from the user-agent of an
>     end-user the server trusts or has authenticated. CSRF attacks
>     enable the attacker to intermix the attacker's security context
>     with that of the resource owner resulting in a compromise of
>     either the resource server or of the client application itself. In
>     the OAuth context, such attacks allow an attacker to inject their
>     own authorization code or access token into a client, which can
>     result in the client using an access token associated with the
>     attacker's account rather than the victim's. Depending on the
>     nature of the client and the protected resources, this can have
>     undesirable and damaging effects.
>
>     In order to prevent such attacks, the client application MUST
>     encode a non-guessable, confidential end-user artifact and submit
>     as the "state" parameter to authorization and access token
>     requests to the authorization server. The client MUST keep the
>     state value in a location accessible only by the client or the
>     user-agent (i.e., protected by same-origin policy), for example,
>     using a DOM variable, HTTP cookie, or HTML5 client-side storage.
>
>     The authorization server includes the value of the "state"
>     parameter when redirecting the user-agent back to the client.
>     Upon receiving a redirect, the client application MUST confirm
>     that returned value of "state" corresponds to the state value of
>     the user-agent's user session. If the end-user session represents
>     an authenticated user-identity, the client MUST ensure that the
>     user-identity has NOT changed.
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Sat, 13 Aug 2011 00:21:50 -0700

+1 (to putting more detail in the Threat Model document)

Yes, this is another CSRF attack (hence the change to 10.2). 

What is *new* is this is an attack on the client application rather than the resource server. As such, I agree this new attack vector is well deserving of wider review and discussion before finalizing the draft.

Phil

@independentid
www.independentid.com
[email-masked]

On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote:

> We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well.
> 
> regards,
> Torsten. 
> 
>> 
>> From: Anthony Nadalin <[email-masked]>
>> To: "OAuth WG ([email-masked])" <[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 13 Aug 2011 07:30:19 -0700

All OAuth CSRF attacks are on the client.

EHL

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Sat, 13 Aug 2011 00:21:50 -0700
To: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
Cc: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>, "OAuth WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Phil

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

regards,
Torsten.

state

to:

state

Change to:

EHL

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 13 Aug 2011 08:14:22 -0700

Again, the idea that you can produce a comprehensive description of
security threat is impractical if you are going to include every
browser-based attack and its remedies. OAuth use of browser redirection
imports almost every possible attack vector on the web. That's my point.
People constantly bring up these attack vectors, and in multiple flavors
and variations, as if *anyone* can produce a complete list of these issues.

Now, this doesn't mean we should not try to be comprehensive but this can
go on forever.

The changes to 10.12 seem reasonable with the exception of the new MUSTs.
I disagree that we should mandate clients to use the state parameter as
the only CSRF protection vector, especially in an evolving web
environment. We can still include a MUST for verifying that the user
redirected to the authorization server is the same user coming back, and
highlight the state parameter as one way to accomplish that.

How about:

state: OPTIONAL. An opaque value used by the client to maintain state
between the request and redirection. The authorization server includes
this value when redirecting the user-agent back to the client. Use of the
"state" parameter is RECOMMENDED for preventing cross-site request forgery
as described in Section 10.12.

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from the user-agent of an end-user the server
trusts or has authenticated. CSRF attacks enable the attacker to intermix
the attacker's security context with that of the resource owner resulting
in a compromise of either the resource server or of the client application
itself.

In the OAuth context, such attacks allow an attacker to inject their own
authorization code or access token into the client, which can result in
the client associating the attacker's protected resources to the victim's
account on the client. Depending on the nature of the client and the
protected resources, this can have undesirable and damaging effects. In
order to prevent such attacks, the client MUST employ CSRF protection.

It is strongly RECOMMENDED for the client to utilize the "state" request
parameter with authorization requests to the authorization server. When
used for CSRF prevention, the "state" request parameter MUST contain a
non-guessable value, which the client MUST also store with the resource
owner's user-agent in a location accessible only to the client or the
resource owner's user-agent (i.e., protected by same-origin policy). For
example, the client can using a DOM variable, HTTP cookie, or HTML5
client-side storage.

When redirecting the resource owner's user-agent back to the client, the
authorization server includes the value of the "state" parameter. Upon
receiving the redirection request, the client MUST confirm that returned
value of the "state" parameter matches the value stored with the resource
owner's user-agent.

EHL

From:  Torsten Lodderstedt <[email-masked]>
Date:  Fri, 12 Aug 2011 23:58:02 -0700
To:  Eran Hammer-lahav <[email-masked]>
Cc:  Anthony Nadalin <[email-masked]>, "OAuth WG ([email-masked])"
<[email-masked]>
Subject:  Re: [OAUTH-WG] Auth Code Swap Attack

>      This is really just a flavor of CSRF attacks. I have no
>        objections to better documenting it (though I feel the current
>        text is already sufficient), but we can't realistically expect
>        to identify and close every possible browser-based attack. A new
>        one is invented every other week.
>      
>      
>      The problem with this text is that developers who do no
>        understand CSRF attacks are not likely to implement it correctly
>        with this information. Those who understand it do not need the
>        extra verbiage which is more confusing than helpful.
>    
>
>    
>    We are constantly facing the fact that a comprehensive description
>    of security threats needs more space than we have in the core draft.
>    That's the reason why the security document has 63 pages and that's
>    also the reason why we decided to let the core spec refer to this
>    document for in-depth explanations. This holds true for this threat
>    as well.
>    
>    regards,
>    Torsten. 
>    
>    
>      
>      
>      As for the new requirements, they are insufficient to
>        actually accomplish what the authors propose without additional
>        requirements on state local storage and verification to complete
>        the flow. Also, the proposed text needs clarifications as noted
>        below.
>      
>      
>      
>      
>      
>>                In section 4, request options (e.g.
>>                      4.1.1) featuring "state" should change from:
>>                 
>>                state
>>                OPTIONAL.
>>                    An opaque value used by the client to maintain state
>>                    between the request and callback. The authorization
>>                    server includes this value when redirecting the
>>                    user-agent back to the client.
>>                 
>>                to:
>>                 
>>                state
>>                REQUIRED.
>>                    An opaque value used by the client to maintain state
>>                    between the request and callback. The authorization
>>                    server includes this value when redirecting the
>>                    user-agent back to the client. The encoded value
>>                    SHOULD enable the client application to determine
>>                    the user-context that was active at the time of the
>>                     request (see section 10.12). The value MUST NOT be
>>                    guessable or predictable, and MUST be kept
>>                    confidential.
>>                 
>>              
>>            
>>          
>>        
>      
>      
>      
>      Making the parameter required without making its usage
>        required (I.e. "value SHOULD enable") accomplishes nothing.
>        Also, what does "MUST be kept confidential" mean? Confidential
>        from what? Why specify an "encoded value"?
>      
>      
>      
>      
>      
>        >
>>          
>>            
>>              
>>                Cross-site
>>                    request forgery (CSRF) is a web-based attack whereby
>>                    HTTP requests are transmitted from the user-agent of
>>                    an end-user the server trusts or has authenticated.
>>                    CSRF attacks enable the attacker to intermix the
>>                    attacker's security context with that of
>>                    the resource owner resulting in a compromise of
>>                    either the resource server or of the client
>>                    application itself. In the OAuth context,
>>                    such attacks allow an attacker to inject their own
>>                    authorization code or access token into a client,
>>                    which can result in the client using an access token
>>                    associated with the attacker's account rather than
>>                    the victim's. Depending on the nature of the client
>>                    and the protected resources, this can have
>>                    In order to prevent such attacks, the client
>>                    application MUST encode a non-guessable,
>>                    confidential end-user artifact and submit as the
>>                    "state" parameter to authorization and access token
>>                    requests to the authorization server. The client
>>                    MUST keep the state value in a location accessible
>>                    only by the client or the user-agent (i.e.,
>>                    protected by same-origin policy), for example, using
>>                    a DOM variable, HTTP cookie, or HTML5 client-side
>>                    storage.
>>                 
>>                    The authorization server includes the value of the
>>                    "state" parameter when redirecting the user-agent
>>                    back to the client. Upon receiving a redirect, the
>>                    client application MUST confirm that returned value
>>                    of "state" corresponds to the state value of the
>>                    user-agent's user session. If the end-user session
>>                    represents an authenticated user-identity, the
>>                    client MUST ensure that the user-identity has NOT
>>                    changed.
>>                 
>>              
>>            
>>          
>>        
>      
>      
>      
>[email-masked]://www.ietf.org/mailman/listinfo/oauth
>    
>
>

---

From: "William J. Mills" <[email-masked]>
Date: Sat, 13 Aug 2011 09:22:07 -0700 (PDT)

All CSRF attacks are a against the client (confused deputy) yes.  The defense is always in the server side.  I agree that it's really worth covering.  There are already good discussions of CSRF out there which I think we shoudl lean on rather than re-writing our own, i.e. http://www.rfc-editor.org/rfc/rfc6265.txt

-bill

________________________________
From: Eran Hammer-Lahav <[email-masked]>
To: Phil Hunt <[email-masked]>; Torsten Lodderstedt <[email-masked]>
Cc: "OAuth WG ([email-masked])" <[email-masked]>
Sent: Saturday, August 13, 2011 7:30 AM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

EHL
From:  Phil Hunt <[email-masked]>
Date:  Sat, 13 Aug 2011 00:21:50 -0700
To:  Torsten Lodderstedt <[email-masked]>
Cc:  Eran Hammer-lahav <[email-masked]>, "OAuth WG ([email-masked])" <[email-masked]>
Subject:  Re: [OAUTH-WG] Auth Code Swap Attack

>[email-masked]
>
>
>
>
>
>
                    MUST keep the state value in a location accessible                    only by the client or the user-agent (i.e.,
                    back to the client. Upon receiving a redirect, the                    client application MUST confirm that returned value
>>>The above text uses 'user-context' and this 'user-identity'. Neither term is defined.
OAuth mailing list [email-masked]://www.ietf.org/mailman/listinfo/oauth
_______________________________________________

---

From: Phil Hunt <[email-masked]>
Date: Sat, 13 Aug 2011 16:41:07 -0700

There are two CSRF variations scenarios that I see.

I can attack you and give my client access to your resources (original attack on the "resource").

I can attack you and give your client access to my resource (new attack on the "client").

Attack on the client vs. attack on the resource may be misleading here.  Draft 20 only referred to attacks on the "resource" in its original CSRF description.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: "William J. Mills" <[email-masked]>
Date: Sat, 13 Aug 2011 21:16:23 -0700 (PDT)

The defense is the same though, correct?

________________________________
From: Phil Hunt <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>
Cc: "OAuth WG ([email-masked])" <[email-masked]>
Sent: Saturday, August 13, 2011 4:41 PM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Phil

@independentid

---

From: Phillip Hunt <[email-masked]>
Date: Sat, 13 Aug 2011 22:55:18 -0700

No. I don't think so. In the new variant the client has to check the returned state to confirm it has not changed or associated with a different user.  

Previously the authz server had to do the checks. 

Phil

---

From: John Kemp <[email-masked]>
Date: Sun, 14 Aug 2011 09:06:17 -0400

Hi Tony (et al),

On Aug 12, 2011, at 3:06 PM, Anthony Nadalin wrote:

[…]

> 3.            The server running Basil's website initiates an authorization request to Live. The request uses Plaxo's redirection URI.

And why does Live believe that this is a valid authorization request? Has Basil forged a request to Live as if it came from Plaxo (Basil has at least the client_id for Plaxo's client)? Shouldn't Live protect its authorization endpoint by requiring some authentication of the requester?

> The code running on Basil's server uses Basil's Live credentials to login to Live and to grant the authorization request. Live responds with a redirect containing an authorization code. Basil's server swallows the redirect and creates a web page containing the authorization code and sends the web page down to Gene's browser. [Note: Normally the actions in step 3 would be performed by a human at a browser but in the attack Basil has automated the process so his attack server can do everything automatically.]

Although Plaxo never had a request initiated from anyone (Gene, or Basil) to sync Gene's contacts with Live? And shouldn't Plaxo ask Gene for explicit authorization before syncing his contacts to Live, regardless of whether he is already authenticated? 

Regards,

- John

---

From: John Kemp <[email-masked]>
Date: Sun, 14 Aug 2011 09:19:39 -0400

> Previously the authz server had to do the checks. 

In a CSRF attack, either of the two web servers (one is the OAuth "client" in this case) may be attacked with a CSRF. The defense against a CSRF is always for the recipient of the request to authenticate the requester in one way or another. One way to do that is with a CSRF token (see https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet). 

In OAuth, I think it's fair to say that an "OAuth CSRF attack" might be a special-case of a CSRF attack, but the typical defenses apply to both the OAuth "client" and the OAuth "resource server".

- John

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 14 Aug 2011 06:30:40 -0700

Not true. It is the same.

EHL

On Aug 14, 2011, at 1:55, "Phillip Hunt" <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On 2011-08-13, at 21:16, "William J. Mills" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: Phil Hunt <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
To: Eran Hammer-Lahav <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG (<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Sent: Saturday, August 13, 2011 4:41 PM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Phil

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

EHL

From: Phil Hunt <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Date: Sat, 13 Aug 2011 00:21:50 -0700
To: Torsten Lodderstedt <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Cc: Eran Hammer-lahav <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>, "OAuth WG (<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)" <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Phil

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

regards,
Torsten.

From: Anthony Nadalin <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)" <<mailto:[email-masked]><mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Subject: [OAUTH-WG] Auth Code Swap Attack

state

to:

state

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 14 Aug 2011 23:31:53 -0700

I'm using my proposed text in -21.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Saturday, August 13, 2011 8:14 AM
> To: Torsten Lodderstedt
> Cc: OAuth WG ([email-masked])
> Again, the idea that you can produce a comprehensive description of security
> threat is impractical if you are going to include every browser-based attack
> and its remedies. OAuth use of browser redirection imports almost every
> possible attack vector on the web. That's my point.
> People constantly bring up these attack vectors, and in multiple flavors and
> variations, as if *anyone* can produce a complete list of these issues.
> 
> I disagree that we should mandate clients to use the state parameter as the
> only CSRF protection vector, especially in an evolving web environment. We
> can still include a MUST for verifying that the user redirected to the
> authorization server is the same user coming back, and highlight the state
> parameter as one way to accomplish that.
> 
> How about:
> 
> 
> between the request and redirection. The authorization server includes this
> value when redirecting the user-agent back to the client. Use of the "state"
> parameter is RECOMMENDED for preventing cross-site request forgery as
> described in Section 10.12.
> 
> 
> 
> 
> trusts or has authenticated. CSRF attacks enable the attacker to intermix the
> attacker's security context with that of the resource owner resulting in a
> compromise of either the resource server or of the client application itself.
> 
> authorization code or access token into the client, which can result in the
> client associating the attacker's protected resources to the victim's account
> on the client. Depending on the nature of the client and the protected
> resources, this can have undesirable and damaging effects. In order to
> prevent such attacks, the client MUST employ CSRF protection.
> 
> owner's user-agent in a location accessible only to the client or the resource
> owner's user-agent (i.e., protected by same-origin policy). For example, the
> client can using a DOM variable, HTTP cookie, or HTML5 client-side storage.
> 
>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 15 Aug 2011 14:51:21 +0000

That's nice, four people come up with text and you decide to use your text. Making state optional does nothing to fix the protocol issue, people will get this wrong and have. Our developers have been through this and agreed upon the text that was generated. They find the text in the current draft unacceptable and confusing and think that new text is acceptable. 

So -1 on your text

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Sunday, August 14, 2011 11:32 PM
To: [email-masked]; Torsten Lodderstedt
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

EHL

> browser-based attack and its remedies. OAuth use of browser 
> redirection imports almost every possible attack vector on the web. That's my point.
> People constantly bring up these attack vectors, and in multiple 
> flavors and variations, as if *anyone* can produce a complete list of these issues.
> 
> Now, this doesn't mean we should not try to be comprehensive but this 
> can go on forever.
> 
> I disagree that we should mandate clients to use the state parameter 
> as the only CSRF protection vector, especially in an evolving web 
> redirected to the authorization server is the same user coming back, 
> and highlight the state parameter as one way to accomplish that.
> 
> How about:
> 
> 
> this value when redirecting the user-agent back to the client. Use of the "state"
> trusts or has authenticated. CSRF attacks enable the attacker to 
> intermix the attacker's security context with that of the resource 
> owner resulting in a compromise of either the resource server or of the client application itself.
> 
> In the OAuth context, such attacks allow an attacker to inject their 
> own authorization code or access token into the client, which can 
> result in the client associating the attacker's protected resources to 
> the victim's account on the client. Depending on the nature of the 
> client and the protected resources, this can have undesirable and 
> damaging effects. In order to prevent such attacks, the client MUST employ CSRF protection.
> 
> It is strongly RECOMMENDED for the client to utilize the "state" 
> request parameter with authorization requests to the authorization 
> server. When used for CSRF prevention, the "state" request parameter 
> MUST contain a non-guessable value, which the client MUST also store 
> with the resource owner's user-agent in a location accessible only to 
> the client or the resource owner's user-agent (i.e., protected by 
> same-origin policy). For example, the client can using a DOM variable, HTTP cookie, or HTML5 client-side storage.
> 
> 
> When redirecting the resource owner's user-agent back to the client, 
> the authorization server includes the value of the "state" parameter. 
> Upon receiving the redirection request, the client MUST confirm that 
> returned value of the "state" parameter matches the value stored with 
> the resource owner's user-agent.
> 
> 
> EHL
> 
> 
> 
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 15 Aug 2011 11:06:44 -0400

On Mon, Aug 15, 2011 at 10:51 AM, Anthony Nadalin <[email-masked]> wrote:
> That's nice, four people come up with text and you decide to use your text.
> Making state optional does nothing to fix the protocol issue, people will get
> this wrong and have. Our developers have been through this and agreed
> upon the text that was generated. They find the text in the current draft
> unacceptable and confusing and think that new text is acceptable.

I have to agree with what Tony says above.  The text proposed in his
message was agreed upon by several WG participants, and unless there's
some significant objection to it I think we should use it in the -21
version, subject to final WG review.

Barry, as chair

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 15 Aug 2011 08:07:08 -0700

(please don't use my sled.com work email address)

I'll ask the chairs to open an issue for this.

My proposed requires CSRF protected without adding additional requirements, and therefore, is within the scope of my editorial discretion. IOW, my text is already well-within working group consensus. Your text has not established consensus, and I have listed actual issues with the proposed text which none of the authors have addressed so far.

I'm opposed to making the state parameter required because it is meaningless without addition specification of exactly how to use it (i.e. achieve interoperable implementation), which is clearly outside the scope of this document.

The "new" attack described is in no way more severe than the existing CSRF attack described in -20. You have provided no justification for making this significant normative change other than this "new" CSRF attack, and the current text is based on actual working group consensus.

EHL

> From: Anthony Nadalin [mailto:[email-masked]]
> Sent: Monday, August 15, 2011 7:51 AM
> To: Eran Hammer-Lahav; [email-masked]; Torsten Lodderstedt
> Subject: RE: [OAUTH-WG] Auth Code Swap Attack
> 
> "state"

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 15 Aug 2011 08:10:11 -0700

Please go back to the beginning of the thread where I expressed (not as editor) my "significant objection" and listed actual problems with the proposed text, as well as the entire justification for making it.

In addition, my text is well within my discretion for making non-normative editorial changes.

EHL

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Monday, August 15, 2011 8:07 AM
> To: Anthony Nadalin
> Cc: Eran Hammer-Lahav; [email-masked]; Torsten Lodderstedt; OAuth WG
> ([email-masked])
> > Making state optional does nothing to fix the protocol issue, people
> > will get this wrong and have. Our developers have been through this
> > and agreed upon the text that was generated. They find the text in the
> > current draft unacceptable and confusing and think that new text is
> acceptable.
> 
> some significant objection to it I think we should use it in the -21 version,
> subject to final WG review.
> 
> Barry, as chair

---

From: Barry Leiba <[email-masked]>
Date: Mon, 15 Aug 2011 11:25:22 -0400

> I'll ask the chairs to open an issue for this.

The chairs consider themselves asked, and have opened a ticket:
http://trac.tools.ietf.org/wg/oauth/trac/ticket/23

> My proposed requires CSRF protected without adding additional requirements,
> and therefore, is within the scope of my editorial discretion. IOW, my text is
> already well-within working group consensus. Your text has not established
> consensus, and I have listed actual issues with the proposed text which none
> of the authors have addressed so far.

This chair disagrees with the editorial prerogative at this point.  I
have not discussed this with my co-chairs, and perhaps they don't
agree with me.

I agree with Eran that the issue isn't settled -- that the
Tony/Yaron/Torsten/Phil text, and the normative change it proposes,
does not yet have WG consensus.  And I note Eran's objection and the
reasons for it, and I agree that it needs more discussion.

But I believe the T/Y/T/P proposal has enough backing that it's the
one that should be floated in the next version of the document right
now.  That by no means makes it final, and the chairs will track the
discussion and make a proper consensus judgment at the appropriate
time.

I also think it's perfectly acceptable for the editor to put both
versions of the text in, with a note that the WG must choose which way
to go.  Eran, is that a path you can tolerate?

Barry, as chair

---

From: John Kemp <[email-masked]>
Date: Mon, 15 Aug 2011 11:25:56 -0400

> I'm opposed to making the state parameter required because it is meaningless without addition specification of exactly how to use it (i.e. achieve interoperable implementation), which is clearly ou…

I agree - I am also opposed to making 'state' required.

> 
> The "new" attack described is in no way more severe than the existing CSRF attack described in -20.

I, too, do not see how this attack is different than other CSRF attacks, or why existing security measures (including but not limited to 'state') as described in the specification are not sufficient to prevent this attack.  

- John

> You have provided no justification for making this significant normative change other than this "new" CSRF attack, and the current text is based on actual working group consensus.
> 
> EHL
> 
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 15 Aug 2011 08:52:33 -0700

> Sent: Monday, August 15, 2011 8:25 AM
> To: Eran Hammer-Lahav
> Cc: Anthony Nadalin; OAuth WG ([email-masked])
> > My proposed requires CSRF protected without adding additional
> > requirements, and therefore, is within the scope of my editorial
> > discretion. IOW, my text is already well-within working group
> > consensus. Your text has not established consensus, and I have listed
> > actual issues with the proposed text which none of the authors have
> addressed so far.
> 
> This chair disagrees with the editorial prerogative at this point.  I have not
> discussed this with my co-chairs, and perhaps they don't agree with me.

What does "at this point" mean?

This is how this working group has operated for 20 revisions. Does "at this point" references the late stage of the specification and closing of WGLC? If so, then your support for making such a significant normative change is puzzling. Seems like *not* making this change first and discussing later is the appropriate action "at this point".

I would suggest you compare the two texts side by side to see that the only real difference is the use of MUST vs. RECOMMENDED. I didn't just make stuff up. "My" text is just an editorial cleanup with exclusion of the new MUST. And this new MUST is clearly against past established consensus since version -00 (!) of this document and even earlier in its wrap_client_state form in WRAP. It is even a noticeable departure from the authors' own original security consideration text submitted before.

> Tony/Yaron/Torsten/Phil text, and the normative change it proposes, does
> not yet have WG consensus.  And I note Eran's objection and the reasons for
> it, and I agree that it needs more discussion.
> 
> But I believe the T/Y/T/P proposal has enough backing that it's the one that
> should be floated in the next version of the document right now.  That by no
> means makes it final, and the chairs will track the discussion and make a
> proper consensus judgment at the appropriate time.
> 
> I also think it's perfectly acceptable for the editor to put both versions of the
> text in, with a note that the WG must choose which way to go.  Eran, is that a
> path you can tolerate?

I do not plan to publish another draft until this issue is closed and resolved. I plan to seek WG consensus to every change made to -21 prior to publication to reduce the need for another WG draft. This is why I am informing the list with every change I make on my local copy so that people can raise their concerns or objections.

Of course, like any WG document, -21 will be subject to review, but there is a difference between publishing a document known to include issues to one that can be safely considered stable.

Ignoring Mr. Nadalin unproductive tone, this is exactly what has happened here. Text was proposed, issues raised, an alternative was proposed, and I informed the list of my intention of using the edited text. Mr. Nadalin then raised his disagreement with the proposed edit. Fine. Now we wait for more participants to express their views.

EHL

---

From: Barry Leiba <[email-masked]>
Date: Mon, 15 Aug 2011 12:26:57 -0400

> I do not plan to publish another draft until this issue is closed and resolved.
> I plan to seek WG consensus to every change made to -21 prior to publication
> to reduce the need for another WG draft.
...
> and I informed the list of my intention of using the edited text. Mr. Nadalin then
> raised his disagreement with the proposed edit. Fine. Now we wait for more
> participants to express their views.

OK, this is where the disconnect came from, and why I had a problem
with what I heard.  My guess is that that's the same problem Tony had:
My interpretation of your one-line message that said, "I'm using my
proposed text in -21," was that you were deciding the issue, and were
about to publish a new draft now-ish that reflects your decision.
What you say here makes it clear that that's not the case, and that
what you meant was, "I believe my proposed text addresses this issue
while maintaining established consensus about the protocol details,
and when I post -21 (soon, but not now), which I hope will be the
final version, I intend to use that version of the text, unless
further discussion shows that WG consensus on the 'state' option has
now changed."

That's rather more long-winded, of course, but I have, as chair, no
problem at all with that plan.  I also suspect that Tony will consider
the longer-winded explanation to be less dismissive of the T/Y/T/P
proposal than the one-sentence version may have come across.

And, so, carry on.

Barry, still chair-like

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 15 Aug 2011 09:35:13 -0700

To demonstrate why making state required as proposed isn't very helpful, here is an incomplete list of other requirements needed to make an effective CSRF:

* State value must not be empty (a common bug in many implementations using simple value comparison).

* 'Non-guessable' isn't sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn't sufficient. We use "cannot be generated, modified, or guessed to produce valid values" elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie.

* State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable.

In addition, this is not what "state" was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. 'csrf'). By forcing clients to use "state" for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms.

EHL

From: Eran Hammer-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

state

to:

state

Change to:

EHL

---

From: Blaine Cook <[email-masked]>
Date: Mon, 15 Aug 2011 17:44:49 +0100

>From my chair-seat, Barry's interpretation matches mine. Having
carefully reviewed Eran's revised text vis-a-vis the proposal from
Anthony et al., it seems like the concerns are addressed without
forcing the use of any specific mechanism to maintain state, which is
commensurate with the approach to the problem in the HTTP world.

Reviewing the history of the state parameter, and thinking about how
it will be used within a functioning system, I'm inclined to agree
with Eran's most recent comments. Thus, the challenge for me is
whether or not there is a way to introduce a required CSRF parameter
that meets the security requirements, can be implemented seamlessly in
libraries, and is reasonably scalable in its default (library-driven)
form (my intuition says there isn't).

b.

On 15 August 2011 17:35, Eran Hammer-Lahav <[email-masked]> wrote:
> To demonstrate why making state required as proposed isn’t very helpful,
> here is an incomplete list of other requirements needed to make an effective
> CSRF:
>
>
>
> * ‘Non-guessable’ isn’t sufficient as most developers will simply use a hash
> of the session cookie, with or without salt which isn’t sufficient. We use
> “cannot be generated, modified, or guessed to produce valid values”
> elsewhere in the document, but this is much easier to get right for access
> tokens and refresh tokens than CSRF tokens which are often just some
> algorithm on top of the session cookie.
>
>
>
> * State CSRF value should be short-lived or based on a short-lived session
> cookie to prevent the use of a leaked state value in multiple attacks on the
> same user session once the leak is no longer viable.
>
>
>
> In addition, this is not what “state” was originally intended for. If the
> working group decides to mandate a CSRF parameter, it should probably be a
> new parameter with a more appropriate name (e.g. ‘csrf’). By forcing clients
> to use “state” for this purpose, developers will need to use dynamic queries
> for other state information which further reduces the security of the
> protocol (as the draft recommends not using dynamic callback query
> components). Encoding both CSRF tokens and other state information can be
> non-intuitive or complicated for some developers/platforms.
>
>
>
> EHL
>
>
>
>
>
>
>
>
>
> From: Eran Hammer-Lahav
> This is really just a flavor of CSRF attacks. I have no objections to better
> documenting it (though I feel the current text is already sufficient), but
> we can't realistically expect to identify and close every possible
> browser-based attack. A new one is invented every other week.
>
>
>
> The problem with this text is that developers who do no understand CSRF
> attacks are not likely to implement it correctly with this information.
> Those who understand it do not need the extra verbiage which is more
> confusing than helpful.
>
>
>
> As for the new requirements, they are insufficient to actually accomplish
> what the authors propose without additional requirements on state local
> storage and verification to complete the flow. Also, the proposed text needs
> clarifications as noted below.
>
>
>
>
>
> OPTIONAL. An opaque value used by the client to maintain state between the
> request and callback. The authorization server includes this value when
> redirecting the user-agent back to the client.
>
>
>
> to:
>
>
>
> state
>
> REQUIRED. An opaque value used by the client to maintain state between the
> request and callback. The authorization server includes this value when
> redirecting the user-agent back to the client. The encoded value SHOULD
> enable the client application to determine the user-context that was active
> at the time of the  request (see section 10.12). The value MUST NOT be
> guessable or predictable, and MUST be kept confidential.
>
>
>
>
>
> Making the parameter required without making its usage required (I.e. "value
> SHOULD enable") accomplishes nothing. Also, what does "MUST be kept
> confidential" mean? Confidential from what? Why specify an "encoded value"?
>
>
>
>
>
> the attacker's security context with that of the resource owner resulting in
> a compromise of either the resource server or of the client application
> itself. In the OAuth context, such attacks allow an attacker to inject their
> own authorization code or access token into a client, which can result in
> the client using an access token associated with the attacker's account
> rather than the victim's. Depending on the nature of the client and the
> protected resources, this can have undesirable and damaging effects.
>
> In order to prevent such attacks, the client application MUST encode a
> non-guessable, confidential end-user artifact and submit as the "state"
> parameter to authorization and access token requests to the authorization
> server. The client MUST keep the state value in a location accessible only
> by the client or the user-agent (i.e., protected by same-origin policy), for
> example, using a DOM variable, HTTP cookie, or HTML5 client-side storage.
>
> The authorization server includes the value of the "state" parameter when
> redirecting the user-agent back to the client. Upon receiving a redirect,
> the client application MUST confirm that returned value of "state"
> corresponds to the state value of the user-agent's user session. If the
> end-user session represents an authenticated user-identity, the client MUST
> ensure that the user-identity has NOT changed.
>
>
>
>
>

---

From: "William J. Mills" <[email-masked]>
Date: Mon, 15 Aug 2011 10:07:29 -0700 (PDT)

I'm a -1 on both of these until I re-read the attack description and really parse this again.  Perhaps I'm being confused by the usage of "client" here.  My initial reaction is that any time we are relying on the client to protect itself from CSRF it is a mistake.

I do think that CSRF protection is REQUIRED, the remaining question is whether it's reasonable to force folks to use the state parameter.  My gut says it's not unreasonable to force this simple model.

I also don't particularly like either CSRF description used.  As I've said before I think there are better discussions of it out there.

More later when I have more time to think on this.

-bill

________________________________
From: Barry Leiba <[email-masked]>
To: Anthony Nadalin <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "OAuth WG ([email-masked])" <[email-masked]>
Sent: Monday, August 15, 2011 8:06 AM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Barry, as chair

---

From: "William J. Mills" <[email-masked]>
Date: Mon, 15 Aug 2011 18:41:07 -0700 (PDT)

After thinking about this and getting on the phone with Eran, I think making "state" required isn't right (because we're dictating one solution/format to no real point), but CSRF protection *is* REQUIRED.  I also think that we're probably not sufficiently clear about which state parameter we're talking about, since we have 2, but that's a different question). The core of the problem described 
in the first message of this topic is a plain CSRF vulnerability of the 
redirect URI.  Alice's (our victim) browser visits the malicious 
redirect URI, presents her credential, and the bad thing happens.

I'm proposing a 3rd variant.  The original -20 text is included below, it's closer to where I think we should be.  This leans on a rather fuzzy-term "non-guessable" but I'm OK with it if no on else objects.

10.12.  Cross-Site Request Forgery

Cross-site request forgery (CSRF) 
is an attack whereby malicious URLs are sent to the user-agent of an end user (generally as hidden links or images) and transmitted from the 
user-agent the server trusts or has authenticated. The most commonly exploited mechanism for this is credentials held in cookies automatically presented by a web browser.  CSRF attacks against the client's redirection URI allow 
an attacker to inject their own authorization code or access token, 
which can result in the client using an access token associated with the attacker's account rather than the victim's.  CSRF 
attacks are also possible against an authorization endpoint.  

Client applications MUST implement CSRF protection for the redirection URI.  CSRF protection for a request is data included in the request that ties that request to the user's authenticated state, i.e. a cryptographic signature of the user credential and the redirection URI path.  Upon receipt of a request the client application computes the CSRF data based on the presented credential and compares that to the CSRF protection data presented in the request.  CSRF protection data MUST contain a non-guessable value, and the client MUST keep it in a 
location accessible only by the client or the user-agent (i.e., 
protected by same-origin policy). The "state" redirection URI parameter is provided as one method of carrying CSRF protection data, and is RECOMMENDEDto provide the greatest compatibility with systems implementing strong redirection URI validation.  

It is strongly RECOMMENDED that 
the client includes the "state" request parameter with authorization 
requests to the authorization server.  The "state" request parameter 
MUST contain a non-guessable value, and the client MUST keep it in a 
location accessible only by the client or the user-agent (i.e., 
protected by same-origin policy). 

For example, using a DOM variable, HTTP cookie, or HTML5 client-side 
storage.  The authorization server includes the value of the "state" 
parameter when redirecting the user-agent back to the client which MUST 
then ensure the received value matches the stored value. 

Original -20 text:

10.12.  Cross-Site Request Forgery

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated.  CSRF attacks on the authorization endpoint can allow an attacker to obtain authorization without the consent of the resource owner. 

The "state" request parameter SHOULD be used to mitigate against CSRF attacks, particularly for login CSRF attacks.  CSRF attacks against the client's redirection URI allow an attacker to inject their own authorization code or access token, which can result in the client using an access token associated with the attacker's account rather than the victim's.  Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. 

It is strongly RECOMMENDED that the client includes the "state" request parameter with authorization requests to the authorization server.  The "state" request parameter MUST contain a non-guessable value, and the client MUST keep it in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy). 

For example, using a DOM variable, HTTP cookie, or HTML5 client-side storage.  The authorization server includes the value of the "state" parameter when redirecting the user-agent back to the client which MUST then ensure the received value matches the stored value. 

________________________________
From: William J. Mills <[email-masked]>
To: Barry Leiba <[email-masked]>; Anthony Nadalin <[email-masked]>
Cc: "OAuth WG ([email-masked])" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Monday, August 15, 2011 10:07 AM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

-bill

Barry, as chair

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 17 Aug 2011 23:04:56 -0700

I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of 'state' from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below.

Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section's language and clarity which we should address either way.

To clarify - I am not proposing we close this issue just yet.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

EHL

From: Eran Hammer-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

state

to:

state

Change to:

EHL

---

From: Phil Hunt <[email-masked]>
Date: Wed, 17 Aug 2011 23:41:06 -0700

I felt the argument provided was persuasive and that the current spec leaves implementers open to attack. I get concerned when the core spec says "OPTIONAL" for state and then Security Considerations says REQUIRED. The inconsistency seemed to be a flaw in draft 20.

As to your comment about a tie vote, all that shows is a lack of consensus. Clearly we need to keep working on some more proposals.

I think it is reasonable to determine whether MUST is appropriate in all cases. I agree with what you said earlier, we should have more specific language other then "of sufficient complexity" to describe the value of the state parameter. 

I saw a proposal by William Mills that I would like to see more discussion on.

Phil

@independentid
www.independentid.com
[email-masked]

On 2011-08-17, at 11:04 PM, Eran Hammer-Lahav wrote:

> I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of ‘state’ from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below.
>  
> Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section’s language and clarity which we should address either way.
>  
> To clarify – I am not proposing we close this issue just yet.
>  
> EHL
>  
> To demonstrate why making state required as proposed isn’t very helpful, here is an incomplete list of other requirements needed to make an effective CSRF:
>  
> * ‘Non-guessable’ isn’t sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn’t sufficient. We use “cannot be generated, modified, or guessed to produce valid values” elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie.
>  
> In addition, this is not what “state” was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. ‘csrf’). By forcing clients to use “state” for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms.
>  
> EHL
>  
>  
>  
>  
> From: Eran Hammer-Lahav

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 18 Aug 2011 00:15:15 -0700

There was no argument made. You described a CSRF attack scenario which carries the exact same risk and uses the exact same solution as the CSRF attack already present in the specification. Then jumped from there to a new normative requirement. I have not seen any argument to justify the new MUST requirement - if I have missed it, please point me in the right direction.

Also, -20 has no such inconsistencies. It is OPTIONAL in one place and RECOMMENDED in the other.

However, -20 does not *require* CSRF protection which put it at odds with how we address every other attack vector, so we are in full agreement that CSRF prevention is a MUST. My text fixes that in a manner consistent with how you and the other security consideration section drafters approached many of the other sections (by requiring a solution but not limiting developers to a particular one).

There are two open issues:

- the quality of the prose (I agree that Bill's text is a good new starting point), and

- whether we should dictate to developers the parameter name (and location) of the CSRF artifact.

If we decide that we should mandate such a parameter, we then need to decide if 'state' is the right place and if it is, find a new way to describe it because using it for CSRF is a relative new use case for the parameter (which still have all the previous use cases).

EHL

From: Phil Hunt [mailto:[email-masked]]
Sent: Wednesday, August 17, 2011 11:41 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Phil

@independentid

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

EHL

From: Eran Hammer-Lahav

state

to:

state

Change to:

EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 21 Aug 2011 20:04:24 +0200

My intention is to require clients to implement CSRF prevention. I 
thought making the state parameter mandatory would be the 
straightforward way.

regards,
Torsten.

Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav:
>
> I would like to hear from the other 3 authors of the proposed change 
> about their reasons for changing the use of 'state' from recommended 
> to required for CSRF prevention. It would also help moving this issue 
> forward if the 4 authors can provide answers or clarifications on the 
> issues raised below.
>
> Assuming we can count all 4 authors are in favor of making the change, 
> I believe we have a tie (4:4) and therefore no consensus for making it 
> (as of this point). However, we did identify issues with the section's 
> language and clarity which we should address either way.
>
> To clarify -- I am not proposing we close this issue just yet.
>
> EHL
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Eran Hammer-Lahav
> *Sent:* Monday, August 15, 2011 9:35 AM
> *To:* OAuth WG ([email-masked])
> *Subject:* Re: [OAUTH-WG] Auth Code Swap Attack
>
> To demonstrate why making state required as proposed isn't very 
> helpful, here is an incomplete list of other requirements needed to 
> make an effective CSRF:
>
> * 'Non-guessable' isn't sufficient as most developers will simply use 
> a hash of the session cookie, with or without salt which isn't 
> sufficient. We use "cannot be generated, modified, or guessed to 
> produce valid values" elsewhere in the document, but this is much 
> easier to get right for access tokens and refresh tokens than CSRF 
> tokens which are often just some algorithm on top of the session cookie.
>
> * State CSRF value should be short-lived or based on a short-lived 
> session cookie to prevent the use of a leaked state value in multiple 
> attacks on the same user session once the leak is no longer viable.
>
> In addition, this is not what "state" was originally intended for. If 
> the working group decides to mandate a CSRF parameter, it should 
> probably be a new parameter with a more appropriate name (e.g. 
> 'csrf'). By forcing clients to use "state" for this purpose, 
> developers will need to use dynamic queries for other state 
> information which further reduces the security of the protocol (as the 
> draft recommends not using dynamic callback query components). 
> Encoding both CSRF tokens and other state information can be 
> *From:*Eran Hammer-Lahav
> *Sent:* Friday, August 12, 2011 2:53 PM
> *To:* Anthony Nadalin; OAuth WG ([email-masked] <mailto:[email-masked]>)
> *Subject:* Re: [OAUTH-WG] Auth Code Swap Attack
>
> *From: *Anthony Nadalin <[email-masked] 
> <mailto:[email-masked]>>
> *Date: *Fri, 12 Aug 2011 12:06:36 -0700
> *To: *"OAuth WG ([email-masked] <mailto:[email-masked]>)" 
> *Subject: *[OAUTH-WG] Auth Code Swap Attack
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 21 Aug 2011 12:02:41 -0700

I light to the recent discussion, do you still feel that changing 'state' from optional to required is the best approach?

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Sunday, August 21, 2011 11:04 AM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

My intention is to require clients to implement CSRF prevention. I thought making the state parameter mandatory would be the straightforward way.

regards,
Torsten.

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

EHL

From: Eran Hammer-Lahav

state

to:

state

Change to:

EHL

OAuth mailing list

---

From: David Recordon <[email-masked]>
Date: Sun, 21 Aug 2011 18:10:35 -0700

So far Facebook has used `state` in examples within our documentation
and strongly recommend it but have not gone so far as to mandate it.

Quoting https://developers.facebook.com/docs/authentication/:
> Cross site request forgery is an attack in which an trusted (authenticated
> and authorized) user unknowingly performs an action on website. To prevent
> this attack, you should pass an identifier in the state parameter, and then
> validate the state parameter matches on the response. We strongly recommend
> that any app implementing Facebook user login implement CSRF protection using
> this mechanism.

I'd rather clearly document this in the spec, strongly recommend a
solution but not mandate this specific parameter.

--David

On Sun, Aug 21, 2011 at 12:02 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> I light to the recent discussion, do you still feel that changing ‘state’
> from optional to required is the best approach?
>
>
>
> EHL
>
>
>
> My intention is to require clients to implement CSRF prevention. I thought
> making the state parameter mandatory would be the straightforward way.
>
> regards,
> Torsten.
>
> I would like to hear from the other 3 authors of the proposed change about
> their reasons for changing the use of ‘state’ from recommended to required
> for CSRF prevention. It would also help moving this issue forward if the 4
> authors can provide answers or clarifications on the issues raised below.
>
>
>
> Assuming we can count all 4 authors are in favor of making the change, I
> believe we have a tie (4:4) and therefore no consensus for making it (as of
> this point). However, we did identify issues with the section’s language and
> clarity which we should address either way.
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Sun, 21 Aug 2011 22:38:32 -0700

I think the complication here is that CSRF issues are multi-site issues where the attacker cross connecting his client with a victims resource, or a victims client with the attackers resource.

So while an individual site (e.g. Facebook) may presume little or no risk - there is a network effect here. A CSRF attacker could be using facebook to attack another site. See Yaron's original text about Plaxo/Live at the start of this thread.

Would it be reasonable to assess whether a resource site could make it mandatory based on a pre-registered client?  IOW, would Facebook want to make state mandatory for Confidential clients, but not public clients?

Would it be acceptable to change status from OPTIONAL to RECOMMENDED?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 21 Aug 2011 22:53:54 -0700

> Sent: Sunday, August 21, 2011 10:39 PM
> To: David Recordon
> Cc: Eran Hammer-Lahav; OAuth WG ([email-masked])
> I think the complication here is that CSRF issues are multi-site issues where
> the attacker cross connecting his client with a victims resource, or a victims
> client with the attackers resource.
> 
> So while an individual site (e.g. Facebook) may presume little or no risk -
> there is a network effect here. A CSRF attacker could be using facebook to
> attack another site. See Yaron's original text about Plaxo/Live at the start of
> this thread.

It's still just a CSRF attack.
 
> Would it be reasonable to assess whether a resource site could make it
> mandatory based on a pre-registered client?  IOW, would Facebook want to
> make state mandatory for Confidential clients, but not public clients?

That's irrelevant. The authorization server has absolutely no way of verifying if the client is implementing a CSRF protection properly. Making 'state' required does not accomplish such an enforcement. A client can pass the proposed text requirement with "state=ni".

> Would it be acceptable to change status from OPTIONAL to RECOMMENDED?

Parameters are either required or optional. We can makes it optional and recommended for a particular purpose which is consistent with the existing text.

It should be mandatory to implement CSRF protection. We agree on that and should add it to the text. We also agree that 'state' is a great way of implementing it and should recommend it. We already do that in the security consideration section and can enhance that when defining the 'state' parameter.

EHL

---

From: Phil Hunt <[email-masked]>
Date: Mon, 22 Aug 2011 08:57:54 -0700

Eran, to summarize,

1. The server cannot tell if the client did its job - so the server can't "require" the client to implement state
2. There are many ways to enforce CSRF

There is an important "network" effect  here (and in general with OAuth) - that client decisions affect the security of the resource server and vice-versa. One could argue, that many implementers will want a solution for #1 above -- some form of mutual state validation.  This may not be of interest to today's implementers, but I know this is critical for government and financial services where fraud (and phishing) become a much larger issue.

I am beginning to believe we can't fix this now. This will likely have to be an optional RFC for higher strength anti-CSRF which specifies a standard methodology that can be verified by the server (so it can enforce that it was done).  My belief is that a standard methodology would make things easier for developers since they would have clear instructions on how to do it. Hopefully this would address folks like Facebook who are concerned developers have a hard time getting this right.

Because of this, I re-checked RFC2119 regarding making state "RECOMMENDED".  Whereas "REQUIRED" is equivalent to "MUST", "RECOMMENDED" is equivalent to SHOULD and could be used as a parameter qualifier. Though I agree, traditionally this isn't done.  However, my feeling is that the developer needs to be alerted to the importance of "state". Deciding not to use it means they should have some other technique to counter CSRF.  This is what SHOULD is meant for.  Changing to RECOMMENDED makes the calls consistent with the security consideration requirement that anti-CSRF is a MUST.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 22 Aug 2011 12:16:03 -0700

Sounds like a good compromise. I will play with the text Bill proposed and follow up with new text on the list.

EHL

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Mon, 22 Aug 2011 08:57:54 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "OAuth WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Eran, to summarize,

Phil

@independentid
www.independentid.com

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 22 Aug 2011 21:58:53 +0000

Concern here is we have a protocol that is open to attacks, we need to document a way that developers can safely implement, leaving it up to the developer may not be the best way unless they know what they are doing, so more in favor of recommending the use of  state and if the developer can do something better the so be it

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 22, 2011 12:16 PM
To: Phil Hunt
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

EHL

Eran, to summarize,

Phil

@independentid

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 22 Aug 2011 15:15:37 -0700

That's what we are saying. Not sure what exactly are you arguing against now.

EHL

From: Anthony Nadalin [mailto:[email-masked]]
Sent: Monday, August 22, 2011 2:59 PM
To: Eran Hammer-Lahav; Phil Hunt
Cc: OAuth WG ([email-masked])
Subject: RE: [OAUTH-WG] Auth Code Swap Attack

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 22, 2011 12:16 PM
To: Phil Hunt
Cc: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

EHL

Eran, to summarize,

Phil

@independentid

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 24 Aug 2011 08:06:12 +0200

making CSRF prevention a MUST and recommending the state parameter as 
implementation pattern is ok with me.

regards,
Torsten.

Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav:
>
> I light to the recent discussion, do you still feel that changing 
> 'state' from optional to required is the best approach?
>
> EHL
>
> *From:*Torsten Lodderstedt [mailto:[email-masked]]
> *Sent:* Sunday, August 21, 2011 11:04 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG ([email-masked])
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Eran Hammer-Lahav
> *To:* OAuth WG ([email-masked] <mailto:[email-masked]>)
> [email-masked]  <mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 24 Aug 2011 07:54:10 -0700

I believe we have full consensus on this approach.

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Tuesday, August 23, 2011 11:06 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

making CSRF prevention a MUST and recommending the state parameter as implementation pattern is ok with me.

regards,
Torsten.

EHL

regards,
Torsten.

EHL

EHL

From: Eran Hammer-Lahav

state

to:

state

Change to:

EHL

OAuth mailing list

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Aug 2011 11:36:13 -0400

> I believe we have full consensus on this approach.

I agree, and I will close the issue.

Barry, happy chair

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 25 Aug 2011 15:11:01 +0000

I have not seen any updated text, so I don't believe we have consensus. Also we have a flawed protocol and we are not providing a fix, suggest that MUST be on the state also unless someone has a better fix

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, August 24, 2011 7:54 AM
To: Torsten Lodderstedt
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

EHL

From: Torsten Lodderstedt [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, August 23, 2011 11:06 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

regards,
Torsten.

EHL

regards,
Torsten.

EHL

EHL

From: Eran Hammer-Lahav

state

to:

state

Change to:

EHL

OAuth mailing list

---

From: Phil Hunt <[email-masked]>
Date: Thu, 25 Aug 2011 09:25:30 -0700

I agree. I think at least one implementation must be included in the spec.  However, I'd like to see it left that more methods could be implemented in the future.  

I can live with "SHOULD" given the definition in 2119.  Or phrased "MUST implement at least the following method..." for stronger language.

Tony is correct, I think it is a serious issue given the dependence on grants being passed by URLs through redirects.

Phil

@independentid
www.independentid.com
[email-masked]

On 2011-08-25, at 8:11 AM, Anthony Nadalin wrote:

> I have not seen any updated text, so I don’t believe we have consensus. Also we have a flawed protocol and we are not providing a fix, suggest that MUST be on the state also unless someone has a better fix
>  
> I light to the recent discussion, do you still feel that changing ‘state’ from optional to required is the best approach?
>  
> EHL
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Aug 2011 09:53:41 -0700

Everyone yourself included indicated that the combination of MUST prevent CSRF and SHOULD use 'state' is the way to go. Yes, we still need to agree on text but the normative language part is settled.

If you still insist on making 'state' required, I will defer to the chairs to decide how to move forward.

EHL

From: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Date: Thu, 25 Aug 2011 08:11:01 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
Cc: "OAuth WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OAUTH-WG] Auth Code Swap Attack

EHL

regards,
Torsten.

EHL

regards,
Torsten.

EHL

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG ([email-masked]<mailto:[email-masked]>)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

EHL

From: Eran Hammer-Lahav

state

to:

state

Change to:

EHL

OAuth mailing list

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 25 Aug 2011 17:00:13 +0000

No that is not what I said; you seemed to have interpreted it that way,

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Thursday, August 25, 2011 9:54 AM
To: Anthony Nadalin; Torsten Lodderstedt
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

EHL

EHL

regards,
Torsten.

EHL

regards,
Torsten.

EHL

EHL

From: Eran Hammer-Lahav

state

to:

state

Change to:

EHL

OAuth mailing list

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Aug 2011 10:02:15 -0700

We already have one recommended implementation with 'state'. It is clearly described in the security section which is the right place to define it. I will further emphasize it in the 'state' parameter definition as previously proposed.

BTW, as stated repeatedly before, making the parameter required does not provide *ANY* CSRF protection. It just forces it to be included. To guarantee CSRF protection, you need a LOT more normative language in how to bind the state value with some form of session information on the user-agent – which is clearly outside the scope of this working group. Requiring CSRF protection accomplishes that, and if a developer doesn't know how to do that, unfortunately, we will not be able to help within the scope of this document – which doesn't exclude it from being discussed in details in the thread model document as advised by the chairs.

CSRF is a serious attack vector, but our correct course is to highlight it, suggest a path, and leave it to developers to implement proper security like the other handful of possible attacks listed.

EHL

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Thu, 25 Aug 2011 09:25:30 -0700
To: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Cc: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>, "OAuth WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Phil

@independentid

EHL

regards,
Torsten.

EHL

regards,
Torsten.

EHL

EHL

From: Eran Hammer-Lahav

state

to:

state

Change to:

EHL

OAuth mailing list