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
