Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8906E21F8B19 for ; Sun, 21 Aug 2011 12:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxg3LW3MIl9U for ; Sun, 21 Aug 2011 12:04:35 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 3180221F8B18 for ; Sun, 21 Aug 2011 12:04:34 -0700 (PDT) Received: (qmail 30245 invoked from network); 21 Aug 2011 19:05:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Aug 2011 19:05:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 21 Aug 2011 12:04:04 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Sun, 21 Aug 2011 12:02:41 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxgLMN0Y2Y+vxPHR3aUSIUK/Z5JuAACAwIQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> In-Reply-To: <4E5148A8.8070903@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234518A292F49P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 19:04:39 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234518A292F49P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I light to the recent discussion, do you still feel that changing 'state' f= rom optional to required is the best approach? EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, August 21, 2011 11:04 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) 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. 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 be= lieve we have a tie (4:4) and therefore no consensus for making it (as of t= his 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: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, he= re 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 has= h of the session cookie, with or without salt which isn't sufficient. We us= e "cannot be generated, modified, or guessed to produce valid values" elsew= here in the document, but this is much easier to get right for access token= s and refresh tokens than CSRF tokens which are often just some algorithm o= n 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 th= e same user session once the leak is no longer viable. In addition, this is not what "state" was originally intended for. If the w= orking group decides to mandate a CSRF parameter, it should probably be a n= ew parameter with a more appropriate name (e.g. 'csrf'). By forcing clients= to use "state" for this purpose, developers will need to use dynamic queri= es for other state information which further reduces the security of the pr= otocol (as the draft recommends not using dynamic callback query components= ). Encoding both CSRF tokens and other state information can be non-intuiti= ve or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to bette= r documenting it (though I feel the current text is already sufficient), bu= t we can't realistically expect to identify and close every possible browse= r-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF att= acks are not likely to implement it correctly with this information. Those = who understand it do not need the extra verbiage which is more confusing th= an helpful. As for the new requirements, they are insufficient to actually accomplish w= hat the authors propose without additional requirements on state local stor= age and verification to complete the flow. Also, the proposed text needs cl= arifications as noted below. From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack 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 red= irecting 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 red= irecting the user-agent back to the client. The encoded value SHOULD enable= the client application to determine the user-context that was active at th= e 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. "valu= e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi= dential" mean? Confidential from what? Why specify an "encoded value"? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the resource owner resulting in a comprom= ise of either the resource server or of the client application itself. In t= he OAuth context, such attacks allow an attacker to inject their own author= ization 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 th= e victim's. Depending on the nature of the client and the protected resourc= es, 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" paramet= er to authorization and access token requests to the authorization server. = The client MUST keep the state value in a location accessible only by the c= lient or the user-agent (i.e., protected by same-origin policy), for exampl= e, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirect, th= e client application MUST confirm that returned value of "state" correspond= s to the state value of the user-agent's user session. If the end-user sess= ion represents an authenticated user-identity, the client MUST ensure that = the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term i= s defined. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E7234518A292F49P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I light to the recent discussion, do you stil= l feel that changing ‘state’ from optional to required is the b= est approach?

 

EHL

 

From: Torsten Lodderstedt [mai= lto:torsten@lodderstedt.net]
Sent: Sunday, August 21, 2011 11:04= AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)=
Subject: Re: [OAUTH-WG] Auth Code Swap Attack<= /p>

 

My intention is to require clients to implement CSRF prevention. I thoug= ht 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 th= eir 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 raise= d below.

 

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

 

To clarify &#= 8211; I am not proposing we close this issue just yet.

 

EHL

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To:<= /b> OAuth WG (oauth@ietf.org)
S= ubject: Re: [OAUTH-WG] Auth Code Swap Attack

 

To demonstrate why making state required as propos= ed isn’t very helpful, here is an incomplete list of other requiremen= ts needed to make an effective CSRF:

 

* State value must not be empty (a co= mmon 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 su= fficient. We use “cannot be generated, modified, or guessed to produc= e 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 sessio= n once the leak is no longer viable.

 

In addition, this is not what “= state” was originally intended for. If the working group decides to m= andate a CSRF parameter, it should probably be a new parameter with a more = appropriate name (e.g. ‘csrf’). By forcing clients to use ̶= 0;state” for this purpose, developers will need to use dynamic querie= s for other state information which further reduces the security of the pro= tocol (as the draft recommends not using dynamic callback query components)= . Encoding both CSRF tokens and other state information can be non-intuitiv= e or complicated for some developers/platforms.

 

EHL

<= p class=3DMsoNormal> <= /p>

 

 

 =

From: Eran Hammer-La= hav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony = Nadalin; OAuth WG (oauth@ietf.org)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 c= urrent text is already sufficient), but we can't realistically expect to id= entify 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 impl= ement it correctly with this information. Those who understand it do not ne= ed the extra verbiage which is more confusing than helpful.

&nbs= p;

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

=

 

&nb= sp;

From: A= nthony Nadalin <tonynad@microso= ft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)&quo= t; <oauth@ietf.org>
Subje= ct: [OAUTH-WG] Auth Code Swap Attack

 

<= /div>

 

 

Recommended Changes to d= raft-ietf-oauth-v2

 

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

 

state

OPTIONAL. An opa= que value used by the client to maintain state between the request and call= back. The authorization server includes this value when redirecting the use= r-agent back to the client.

 

=

to:<= /p>

 

state

= REQUIRED. An opaque val= ue used by the client to maintain state between the request and callback. T= he 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  req= uest (see section 10.12). The value MUST NOT be guessable or predictable, a= nd MUST be kept confidential.

 

 

Making the parameter required without making i= ts usage required (I.e. "value SHOULD enable") accomplishes nothi= ng. Also, what does "MUST be kept confidential" mean? Confidentia= l from what? Why specify an "encoded value"?

 

 

Section 10.12 Cross-Site Request Forgery

=

&n= bsp;

Cha= nge to:

 

Cross-site requ= est forgery (CSRF) is a web-based attack whereby HTTP requests are transmit= ted from the user-agent of an end-user the server trusts or has authen= ticated. CSRF attacks enable the attacker to intermix the attacker's securi= ty context with that of the resource owner resulting in a compromise o= f either the resource server or of the client application itself. In the OA= uth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather th= an the victim's. Depending on the nature of the client and the protected&nb= sp;resources, this can have undesirable and damaging effects.

In ord= er to prevent such attacks, the client application MUST encode a non-guessa= ble, 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 polic= y), for example, using a DOM variable, HTTP cookie, or HTML5 client-si= de 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 re= turned value of "state" corresponds to the state value of the use= r-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.

 

 

The above text uses 'user-context' and this 'user-i= dentity'. Neither term is defined.

 

<= /div>

EHL<= o:p>




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
o:p>
= --_000_90C41DD21FB7C64BB94121FBBC2E7234518A292F49P3PW5EX1MB01E_--