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

[Eric <[e-mail]>]

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<[e-mail]>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:[e-mail]
    <mailto:[e-mail]>[mailto:[e-mail]
    <mailto:[e-mail]>] On Behalf
    >  [e-mail] <mailto:[e-mail]>
    >  Sent: Thursday, January 20, 2011 4:45 PM
    >  To:[e-mail] <mailto:[e-mail]>
    >  Cc:[e-mail] <mailto:[e-mail]>
    >  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
    [e-mail] <mailto:[e-mail]>
    https://www.ietf.org/mailman/listinfo/oauth
    <https://www.ietf.org/mailman/listinfo/oauth>