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
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
