Hi Huilan,
If you are referring to the 'state' parameter (or some other way such as
a session cookie that the client uses to track the state of the
request), there are a few limitations:
a) it is an optional feature as far as the spec is concerned,
b) it is not sufficient to prevent a DDoS attack. See the discussion
below regarding "3. CSRF defense/the 'state' parameter don't completely
address this problem."
Regards,
Eric
On Wed, Mar 2, 2011 at 3:23 PM, Lu, Hui-Lan
(Huilan)<huilan...@alcatel-lucent.com>wrote:
I agree with Tosten. Ahealthy client is not expected to issue an
access token request unconditionally when receiving an authorization
code at its redirect_uri. The client should do so only if it is in
the right state with a correlatable authorization request pending.
Best regards,
Huilan LU
CONFIDENTIALITY NOTICE: This e-mail and any files attached may
contain confidential and proprietary information of Alcatel-Lucent
and/or its affiliated entities. Access by the intended recipient
only is authorized. Any liability arising from any party acting, or
refraining from acting, on any information contained in this e-mail
is hereby excluded. If you are not the intended recipient, please
notify the sender immediately, destroy the original transmission and
its attachments and do not disclose the contents to any other
person, use it for any purpose, or store or copy the information in
any medium. Copyright in this e-mail and any attachments belongs to
Alcatel-Lucent and/or its affiliated entities.
------------------------------------------------------------------------
*From:*oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>[mailto:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>]*On Behalf Of*Torsten Lodderstedt
*Sent:*Monday, February 07, 2011 3:56 PM
*To:*Eric
*Cc:*oauth@ietf.org <mailto:oauth@ietf.org>
*Subject:*Re: [OAUTH-WG] validate authorization code in draft 12
Hi Eric,
I'm trying to understand the attack you described. I would
expect any client to mark its web sessions if it triggers an
authorization process. If so, the attacker would need to forge a
valid client session in the right state (authz process in
progress) in order to place a sucessful attack. For a typical
web application this would require the attacker to login to this
app and kick off the authorization process. This requires more
than one additional http call.
What do you think?
regards,
Torsten.
Am 21.01.2011 09:30, schrieb Eric:
Eran, and others,
A few of us had some discussions on the authorization code
flow, as depicted in Fig. 3 of the current (12th) draft. We
think that it is probably worthwhile to suggest in the
specification that an OAuth implementation SHOULD provide a
way for the client to validate the authorization code before
sending it to the Authorization Server (AS). From what we
have heard, this has been done in some of the current OAuth
deployments. There are other people who do not think this is
such a big security risk, although so far no one has objected
that there is some risk here.
The issue is that according to the current draft, someone
whoowns a botnet can locate the redirect URIs of clients that
listen on HTTP, and access them with random authorization
codes, and cause HTTPS connections to be made on the
Authorization Server (AS). There are a few things that the
attacker can achieve with this OAuth flow that he cannot
easily achieve otherwise :
1. Cost magnification: the attacker incurs the cost of an HTTP
connection and causes an HTTPS connection to be made on the
AS; and he can co-ordinate the timing of such HTTPS
connections across multiple clients relatively easily, if
these clients blindly connect to the AS without first
validating the authorization codes received.
Although the attacker could achieve something similar, say by
including an iframe pointing to the HTTPS URL of the AS in an
HTTP web page and lure web users to visit that page, timing
attacks using such a scheme is (say for the purpose of DDoS)
more difficult .
2. Connection laundering: if the AS realizes it is flooded by
HTTPS connections with illegitimate codes, it collects no
useful information about the attacker, since the clients act
as relays.
3. CSRF defense/the 'state' parameter don't completely address
this problem. With such a defense, the attacker might need to
incur an additional HTTP request to obtain a valid CSRF code/
state parameter. This does cut down the effectiveness of the
attack by a factor of 2, which is good. However, if the
HTTPS/HTTP cost ratio is higher than 2 (the cost factor is
estimated to be around 3.5x
athttp://www.semicomplete.com/blog/geekery/ssl-latency.html
<http://www.semicomplete.com/blog/geekery/ssl-latency.html>),
the attacker still achieves a cost magnification.
Our proposal is that the OAuth specification suggests that an
OAuth (Authorization Server) implementation SHOULD provide a
way for the client to validate the authorization code before
sending it to the Authorization Server (AS). The specifics of
how to validate the authorization code may not need to be part
of the core specification. We sketch a design below for
consideration for future implementation. It might be
reasonable to assume that OAuth implementations provide some
API for the client to call to validate and send the
authorization code to the AS. There are two possible schemes
for implementation: a) if the client and the AS already share
a symmetric secret, an HMAC key can be created from the shared
secret, and the authorization code will be HMAC'ed and
standard techniques can be employed in the client-side API
implementation to detect replay and forgery attempts on the
code; b) an alternative is for the AS to sign the code using
the private key from its SSL certificate, and for the client
API to validate the signature using the public key.
On Thu, Jan 20, 2011 at 4:56 PM, Eran
Hammer-Lahav<e...@hueniverse.com>
<mailto:e...@hueniverse.com>wrote:
Draft -12 is finally out.
This is almost a complete rewrite of the entire document,
with the primary goal of moving it back to a similar
structure used in -05. I have been thinking about this for
a few months and finally came up with a structure that
combines the two approaches.
The draft includes some major cleanups, significantly
simpler language, reduces repeated prose, and tried to
keep prose to the introduction and normative language in
the rest of the specification. I took out sections that
broke the flow, and did my best to give this a linear
narrative that is easy to follow.
The draft includes the following normative changes:
o Clarified 'token_type' as case insensitive.
o Authorization endpoint requires TLS when an access
token is issued.
o Removed client assertion credentials, mandatory HTTP
Basic authentication support for client credentials,
WWW-Authenticate header, and the OAuth2 authentication scheme.
o Changed implicit grant (aka user-agent flow) error
response from query to fragment.
o Removed the 'redirect_uri_mismatch' error code since
in such a case, the authorization server must not send the
error back to the client.
o Defined access token type registry.
I would like to spend the coming week receiving and
applying feedback before requesting a WGLC for everything
but the security considerations section (missing) 2/1.
EHL
> -----Original Message-----
> From:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>[mailto:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>] On Behalf
> ofinternet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
> Sent: Thursday, January 20, 2011 4:45 PM
> To:i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
> Cc:oauth@ietf.org <mailto:oauth@ietf.org>
> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
>
> A New Internet-Draft is available from the on-line
Internet-Drafts directories.
> This draft is a work item of the Open Authentication
Protocol Working Group
> of the IETF.
>
>
> Title : The OAuth 2.0 Authorization Protocol
> Author(s) : E. Hammer-Lahav, et al.
> Filename : draft-ietf-oauth-v2-12.txt
> Pages : 46
> Date : 2011-01-20
>
> This specification describes the OAuth 2.0 authorization
protocol.
>
> A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt
<http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt>
>
> Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
<ftp://ftp.ietf.org/internet-drafts/>
>
> Below is the data which will enable a MIME compliant mail
reader
> implementation to automatically retrieve the ASCII
version of the Internet-
> Draft.
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
