Eric,
The state parameter helps simplify but is not necessary for state management. I
would note that the client has total control of what information the parameter
captures. So it could be devised to carry an index to the state table, a
sequence number (for replay protection), and a signature (for authentication).
The CSRF case is interesting. Let's consider the following scenario:
1. Rob (the resource owner) is tricked to send a service request to the client.
2. Upon receiving the request, the client redirects Rob to the authorization
server as well as changes its internal state to pending authorization by Bob.
(Note that the client may try to authenticate Rob first. Rob could become
suspicous of the authentication request. But let's assume that he plays along.)
3. Upon receiving the authorization request, the authorization server
authenticates Rob and asks for his approval of the client's request.
4. Upon seeing the approval dialogue box, Rob should become alarmed, because he
didn't take the action in step 1 knowingly. He rejects the request.
5. The authorization server redirects the rejection response back to the client.
6. The client sends an apology to Rob explaining why it can not carry out his
service request.
So Rob needs to be totally clueless for the CSRF attacks to work. What is the
likelihood for that to happen? Have I missed something?
Best regards,
Huilan
________________________________
From: pf...@cs.stanford.edu [mailto:pf...@cs.stanford.edu]
Sent: Thursday, March 03, 2011 4:52 AM
To: Lu, Hui-Lan (Huilan)
Cc: Torsten Lodderstedt; Eric; oauth@ietf.org
Subject: Re: [OAUTH-WG] validate authorization code in draft 12
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> <mailto:huilan...@alcatel-lucent.com> wrote:
I agree with Tosten. A healthy 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] On Behalf Of Torsten Lodderstedt
Sent: Monday, February 07, 2011 3:56 PM
To: Eric
Cc: 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 who owns 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 at
http://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 cert
ificate, 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] On Behalf
> Of internet-dra...@ietf.org
> Sent: Thursday, January 20, 2011 4:45
PM
> To: i-d-annou...@ietf.org
> Cc: 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
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
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
