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

From: [email-masked]
Date: Thu, 03 Mar 2011 22:22:47 -0800

Hi Huilan,

The vulnerability being mentioned here is not that an attacker 
impersonates Rob. Please refer to the original discussion below:
"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 : ..."

The point 3. about the state parameter/CSRF defense is that they can 
have the beneficial effect of making the above attack more difficult, 
but does not prevent it.

Best regards,
Eric

On Thu, Mar 3, 2011 at 8:08 PM, Lu, Hui-Lan 
(Huilan)<[email-masked]>wrote:

    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:[email-masked]
    <mailto:[email-masked]>[mailto:[email-masked]
    <mailto:[email-masked]>]
            Sent: Thursday, March 03, 2011 4:52 AM
            To: Lu, Hui-Lan (Huilan)
            Cc: Torsten Lodderstedt; Eric;[email-masked]
    <mailto:[email-masked]>
            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.lu <http://huilan.lu/>@alcatel-lucent.com
    <http://alcatel-lucent.com/>> <mailto:[email-masked]
    <mailto:[email-masked]>>  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:[email-masked]
    <mailto:[email-masked]>[mailto:[email-masked]
    <mailto:[email-masked]>] On Behalf Of Torsten Lodderstedt
                            Sent: Monday, February 07, 2011 3:56 PM
                            To: Eric
                            Cc:[email-masked] <mailto:[email-masked]>

                            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
    athttp://www.semicomplete.com/blog/geekery/ssl-latency.html
    <http://www.semicomplete.com/blog/geekery/ssl-latency.html><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 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] <mailto:[email-masked]>>
    <mailto:[email-masked] <mailto:[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><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/><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><https://www.ietf.org/mailman/listinfo/oauth
    <https://www.ietf.org/mailman/listinfo/oauth>>

      _______________________________________________
                                    OAuth mailing list
    [email-masked] <mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/oauth
    <https://www.ietf.org/mailman/listinfo/oauth><https://www.ietf.org/mailman/listinfo/oauth
    <https://www.ietf.org/mailman/listinfo/oauth>>

---

From: "Lu, Hui-Lan (Huilan)" <[email-masked]>
Date: Fri, 4 Mar 2011 12:36:01 -0600

Eric,
 
I'm confused. I didn't talk about an attacker impersonating Rob. At any rate, inasmuch as we are back to square one, I would maintain that receipt of an authorization code by the client alone is not sufficient for causing it to issue an access token request to the authorization server. The client has to have the right context and be in the right state for that to happen. I should say that it is valid to address DDoS attacks. At issue is only the plausibility of the chain reaction suggested.     

Best regards,
Huilan 

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Friday, March 04, 2011 1:23 AM
	To: Lu, Hui-Lan (Huilan)
	Cc: [email-masked]; Torsten Lodderstedt; [email-masked]
	Subject: Re: [OAUTH-WG] validate authorization code in draft 12

	Hi Huilan,
	
	The vulnerability being mentioned here is not that an attacker impersonates Rob. Please refer to the original discussion below:
	"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 : ..." 
	
	The point 3. about the state parameter/CSRF defense is that they can have the beneficial effect of making the above attack more difficult, but does not prevent it. 
	
	Best regards,
	Eric