Subject: Re: [OAUTH-WG] validate authorization code in draft 12

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 07 Feb 2011 21:56:15 +0100

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), the 
> attacker still achieves a cost magnification.
>
> Our proposal is that the OAuth specification suggests that an OAuth 
> 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<[email-masked]>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:[email-masked]
>     <mailto:[email-masked]>[mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf
>     > [email-masked] <mailto:[email-masked]>
>     > Sent: Thursday, January 20, 2011 4:45 PM
>     > To:[email-masked] <mailto:[email-masked]>
>     > Cc:[email-masked] <mailto:[email-masked]>
>     > 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
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/oauth
>     <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: [email-masked]
Date: Mon, 07 Feb 2011 20:52:34 -0800

Hi Torsten,

Thanks for getting back to me and raising this interesting point.

Are you hinting that while a web application allows anonymous access, it 
shouldn't participate in OAuth? If so, this assumption has not been 
spelled out in the core specification. From what I read, the current 
specification seems to put user authentication with the client as an 
orthogonal issue, and I can't seem to find any hinting of such a 
dependency of OAuth in this specification.

I do not represent an industry vendor, so the example I use below might 
not be appropriate, and I welcome feedback from the members of this 
audience. Currently there are quite a few websites that allow free, 
anonymous access to their service. Suppose a website similar to YouTube 
intends to allow the users to play not only media files hosted on its 
site, but also files hosted somewhere else as long as the user can 
provide the proper authorization to access them (using OAuth). I don't 
see an inherent reason why the site needs to authenticate the user 
locally before retrieving such remote resources.

What do you think?

Best,
Eric

---------- Forwarded message ----------
From:*Torsten Lodderstedt*<[email-masked]>
Date: Mon, Feb 7, 2011 at 12:56 PM
Subject: Re: [OAUTH-WG] validate authorization code in draft 12
To: Eric <[email-masked]>
Cc: Eran Hammer-Lahav <[email-masked]>, "[email-masked]" 
<[email-masked]>

Hi Eric,

more than one additional httpcall.

What do you think?

regards,
Torsten.

Am 21.01.2011 09:30, schrieb Eric:
> (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 
> Hammer-Lahav<[email-masked]> <mailto:[email-masked]>wrote:
>
> https://www.ietf.org/mailman/listinfo/oauth  <https://www.ietf.org/mailman/listinfo/oauth>