After much reflection and review of the big picture (OAuth 1.0 deployment included), I have come to the conclusion that this is a valid security concern which should be explained in the security consideration section, but which does not merit a requirement to use TLS on the client side.
I am now opposed to specifying a MUST use TLS with the callback URI deployed by the client. We should change section 2.1 as follows: Since requests to the authorization endpoint result in user authentication and the transmission of clear-text credentials (in the HTTP response), the authorization server MUST require the use of a transport-layer security mechanism when sending requests to the token endpoints. The authorization server MUST support TLS 1.2 as defined in [RFC5246<http://tools.ietf.org/html/rfc5246>], and MAY support additional transport-layer mechanisms meeting its security requirements. This is the only normative change we should make. My reason for rejecting the requirement to use TLS on the client side is that it is a misleading and narrowly focused guideline. If the client deploys an HTTPS redirection URI endpoint, only to then set an insecure cookie for session management, the same attack is still possible. IOW, if the client allows *any* kind of insecure authentication, OAuth or not, this exploit can put protected resources at risk. The only meaningful - but completely out of scope – requirement to make is that any client using OAuth MUST only support secure authentication of any kind using any protocol (OAuth, cookies, Basic). This translates into full HTTPS deployment for client applications, something that is a growing trend but far from industry standard. So while this is a valid concern, forcing the client to deploy TLS for the OAuth endpoint is an over-reaction and insufficient at that. EHL From: George Fletcher [mailto:gffle...@aol.com] Sent: Wednesday, March 30, 2011 10:33 AM To: Eran Hammer-Lahav Cc: Chuck Mortimore; Phillip Hunt; Karen P. Lewison; OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt From a deployment perspective... I'm considering allowing HTTP redirect_uri (for development only) but making the UI very obnoxious (e.g. bright red background, warnings etc) such that no real user would click through, but a developer will ignore. It also forces them to switch to TLS for production. Thoughts? Also, as long as the authorization code is one-time-use, the passive attack doesn't work. It has to be MITM. Is there any reason authorization codes shouldn't be short-lived and one-time-use? Thanks, George On 3/30/11 2:34 AM, Eran Hammer-Lahav wrote: I’ve been doing this longer. Requiring TLS on the redirection endpoint is a big change for OAuth deployments. This would have been unthinkable for OAuth 1.0(a). One of the main goals of 2.0 was to make it much easier for client developers. I don’t think deploying HTTPS as a prerequisite for playing with an OAuth endpoint is trivial for most client developers. When we had the same debate over bearer token and TLS, many people argued to keep it SHOULD, but no one said they will actually deploy it without TLS. That was a very useful data point. We should take a moment to find out what existing OAuth providers have to say about this. To clarify – I am not objecting to making this a MUST. But I am objecting and will delay this change until we gather more information from actual deployments. Since this applies to OAuth 1.0, it would be very relevant to ask existing providers if they will try and enforce such a restriction for 1.0 as well. Specifications written in a bubble usually fail outright or fail to reflect reality. Also, the attacks are different for the authorization code and implicit grant types. Each can benefit from using TLS for the redirection endpoint in different ways (one transmission of code from user-agent to client, the other manipulation of scripts from client to user-agent). Just want to make sure we don’t just focus on one vector. EHL From: Chuck Mortimore [mailto:cmortim...@salesforce.com] Sent: Tuesday, March 29, 2011 11:19 PM To: Phillip Hunt Cc: Eran Hammer-Lahav; Karen P. Lewison; OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt +1 I disagree that to use TLS is a big change. Rather I'd categorize using TLS as a big inconvenience. We should define a secure profile. If individual deployments choose to relax the spec and determine HTTP acceptable for local host or other convenience thats fine, but it shouldn't be compliant. - cmort On Mar 29, 2011, at 10:55 PM, "Phillip Hunt" <phil.h...@oracle.com<mailto:phil.h...@oracle.com>> 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<mailto: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<mailto: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<mailto:e...@hueniverse.com>> wrote: From: Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> Subject: RE: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt To: "fcore...@pomcor.com<mailto:fcore...@pomcor.com>" <fcore...@pomcor.com<mailto:fcore...@pomcor.com>>, "Phil Hunt" <phil.h...@oracle.com<mailto:phil.h...@oracle.com>>, "Justin Richer" <jric...@mitre.org<mailto:jric...@mitre.org>> Cc: "OAuth WG" <oauth@ietf.org<mailto:oauth@ietf.org>>, "Karen P. Lewison" <kplewi...@pomcor.com<mailto:kplewi...@pomcor.com>>, "Paul Tarjan (p...@fb.com<mailto:p...@fb.com>)" <p...@fb.com<mailto: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<mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
