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 phil.h...@oracle.com 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 > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Eran Hammer-Lahav > Sent: Wednesday, August 24, 2011 7:54 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > I believe we have full consensus on this approach. > > EHL > > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Tuesday, August 23, 2011 11:06 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > 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. > > 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:tors...@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 > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
