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 phil.h...@oracle.com 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 > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@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, 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 (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 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 <tony...@microsoft.com> > Date: Fri, 12 Aug 2011 12:06:36 -0700 > To: "OAuth WG (oauth@ietf.org)" <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 > 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"? > > > 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. > > > The above text uses 'user-context' and this 'user-identity'. Neither term is > defined. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
