MUST with listed exceptions is much stronger than a SHOULD with implicit exceptions.
EHL On Mar 30, 2011, at 7:00, "Justin Richer" <jric...@mitre.org> wrote: > Isn't a "MUST with exceptions" basically the same weight as a "SHOULD"? > As per 2119: > > "SHOULD ... there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course." > > I've always put pretty heavy weight on "SHOULD" components in a spec, as > it really comes down to "ignore at your own peril." A "MUST" shouldn't > have exceptions like that if it's really a "MUST." > > -- Justin > > On Wed, 2011-03-30 at 01:55 -0400, Phillip Hunt wrote: >> Why can't TLS be a must except when the token cannot be exposed. Eg >> because the redirect is local? >> >> >> Phil >> >> >> Sent from my phone. >> >> On 2011-03-29, at 22:48, Eran Hammer-Lahav <e...@hueniverse.com> >> wrote: >> >> >> >>> Francisco – thanks for being persistent. >>> >>> >>> >>> Sounds like the same problem exists in OAuth 1.0. Basically, the >>> only way the client knows that the same user who granted >>> authorization is the one coming back, is via the authorization code. >>> Anyone who has that code is basically assumed to be the one granting >>> access. If the code is intercepted, whoever gets it can pretend to >>> be its legitimate holder. >>> >>> >>> >>> I agree this is an issue. >>> >>> >>> >>> Requiring callbacks to use TLS is a big change. >>> >>> >>> >>> There are some cases where it is not needed – namely, when the >>> client uses the access token obtained through this transaction to do >>> something on the backend without actually exposing anything to the >>> user who delivered the authorization code. For example, an >>> application scanning your Twitter account in the background, sending >>> you emails when someone is no longer following you. Such a client >>> does not need TLS because the authorization code represents a valid >>> grant, and the MITM doesn’t get any benefit from hijacking the >>> callback. No data is exposed. >>> >>> >>> >>> However, this is not the typical use case. >>> >>> >>> >>> As long as the security considerations are clearly stated, we can >>> move forward with either a MUST or a SHOULD. We can easily exempts >>> any internal callbacks from this requirement (localhost, application >>> scheme handler, etc.). >>> >>> I don’t want to write a specification that everyone knowingly >>> ignores. Once people ignore one security requirement, what’s to stop >>> them from ignoring others. So the most important input to this >>> discussion is what the vendors are going to do (regardless of what >>> the document says)? >>> >>> >>> >>> EHL >>> >>> >>> >>> >>> >>> From: Francisco Corella [mailto:fcore...@pomcor.com] >>> Sent: Tuesday, March 29, 2011 3:40 PM >>> To: Phil Hunt; Justin Richer; Eran Hammer-Lahav >>> Cc: OAuth WG; Karen P. Lewison; Paul Tarjan (p...@fb.com) >>> Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt >>> >>> >>> >>> >>>> Isn’t all this just different flavors of a session fixation >>> attacks? >>>> The client should use cookies and the state parameter to ensure >>> the >>>> same user-agent it redirected to the authorization server is the >>> one >>>> coming back. >>> >>> It's not a session fixation attack. It's just an interception of a >>> credential. The authorization code is a credential that provides >>> access to the protected resources. If the attacker can get it, the >>> attacker can get the protected resources (using the client as an >>> agent, so to speak). >>> >>> A cookie won't help, since it would be sent from the browser to the >>> client >>> along with the authorization code. If the attacker can observe or >>> intercept the authorization code, the attacker and observe or >>> intercept the cookie. >>> >>> Francisco >>> >>> --- On Tue, 3/29/11, Eran Hammer-Lahav <e...@hueniverse.com> wrote: >>> >>> >>> From: Eran Hammer-Lahav <e...@hueniverse.com> >>> Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt >>> To: "fcore...@pomcor.com" <fcore...@pomcor.com>, "Phil Hunt" >>> <phil.h...@oracle.com>, "Justin Richer" <jric...@mitre.org> >>> Cc: "OAuth WG" <oauth@ietf.org>, "Karen P. Lewison" >>> <kplewi...@pomcor.com>, "Paul Tarjan (p...@fb.com)" <p...@fb.com> >>> Date: Tuesday, March 29, 2011, 7:50 PM >>> >>> Isn’t all this just different flavors of a session fixation attacks? >>> The client should use cookies and the state parameter to ensure the >>> same user-agent it redirected to the authorization server is the one >>> coming back. >>> >>> >>> >>> EHL >>> >>> >>> >>> From: Francisco Corella [mailto:fcore...@pomcor.com] >>> Sent: Tuesday, March 29, 2011 11:46 AM >>> To: Phil Hunt; Justin Richer; Eran Hammer-Lahav >>> Cc: OAuth WG; Karen P. Lewison; Paul Tarjan (p...@fb.com) >>> Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt >>> >>> >>> >>> >>>> Can you explain how intercepting the authorization code >>>> without having access to the client credentials is a >>>> problem? For the sake of discussion, assume that the client >>>> has valid and secure credentials that an attacker cannot >>>> access. Also assume that the client has implemented some >>>> form of cross-site protection. >>> >>> One way: man-in-the-middle attack. The traffic between the >>> legitimate >>> user's browser and the client goes through the attacker's machine >>> (easy to set up with a rogue WiFi access point). The user's browser >>> sends an http request to the client, targeting the redirect URI. >>> The >>> attacker's machine doesn't let that request go through. The >>> attacker >>> then sends the same identical request from the attacker's own >>> browser. >>> When the client receives the request, it has no way to tell that it >>> is >>> coming from the attacker's browser rather than from the user's >>> browser. The client exchanges the authorization code for an access >>> token, uses the access token to obtain protected resources belonging >>> to the user, and delivers those resources to the attacker's browser. >>> (Or manipulates those resources as directed by the attacker's >>> browser.) In the Facebook use case, the client logs the user in >>> upon >>> verifying that the authorization code is valid by exchanging it >>> successfully for an access token. >>> >>> Another way (passive attack): The attacker observes the request from >>> the user's browser to the client. The attacker does not stop the >>> request. The client receives the request with the authorization >>> code >>> and exchanges the authorization code for the access token. Now the >>> attacker sends the same request from the attacker's own browser. >>> The >>> client receives the second request and exchanges the authorization >>> code for another access token. Upon receiving the second request >>> for >>> the same authorization code, the authorization server revokes the >>> first access token, as suggested in section 4.1.2 of the >>> specification: "If an authorization code is used more than once, the >>> auhorization server MAY revoke all tokens previously issued based on >>> that authorization code". The client then uses the second access >>> token to access protected resources for the benefit of the attacker. >>> In the Facebook use case, the attacker is logged in as the >>> legitimate >>> user. >>> >>>> I don‚Äôt know much about FB‚Äôs implementation but if they >>>> allow the authorization code to be used for anything other >>>> than exchanged for an access token using secure client >>>> credentials, then they are not implementing the protocol as >>>> specified. >>> >>> Facebook uses the protocol correctly, but the examples in the >>> Facebook >>> documentation use http rather than https for redirect URIs, so >>> implementations that follow the examples use http rather than https. >>> >>> Francisco >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
