Re: [OAUTH-WG] Authorization code security issue (reframed)

[Phil Hunt <[e-mail]>]

I was referring to a mobile client that passes the request via an external browser. That browser is capable of running SSL with server authentication only.

Phil
[e-mail]




On 2011-04-04, at 12:08 PM, Skylar Woodward wrote:

> Maybe you can explain your example in more detail then? I'm assuming your "client app" is a web application hosted on web server supporting only HTTP.
> 
> How does the nonce or request_id get to the provider as part of the authorization request in your example?  (step 1)
> 
> 
> On Apr 4, 2011, at 3:03 PM, Phillip Hunt wrote:
> 
>> It doesn't require client side ssl. 
>> 
>> Phil
>> 
>> Sent from my phone. 
>> 
>> On 2011-04-04, at 11:47, Skylar Woodward <[e-mail]> wrote:
>> 
>>> How does the client app transmit the nonce (random number) to the web browser for redirect to the provider? If the client app does not support HTTPS, it can't set up a secure session on its own to give the browser/user something to pass on during the provider authorization.
>>> 
>>> To me, this is nothing different that a unique value of "state" which robust clients will already use to differentiate request flows. Such a state variable would be exposed both on its way and back of the provider's redirect.
>>> 
>>> 
>>> In any case, I see HTTPS as the simple solution here. I question if it is in the scope of OAuth to provide a mechanism to the community to protect against such MITM attacks between a hosted web application and the web browser.  If the nature of the data requires such protection, the app developer (or the provider) can work to provide such security outside of HTTPS.  In the right context, tunneling customer traffic through a provider-provided VPN could be considered a reasonable protection for the cases folks have outlined.  It just doesn't seem like a popular need at this point, and there seem to be no easy wins for hosted clients unable to register with a certificate authority.
>>> 
>>> 
>>> 
>>> On Apr 4, 2011, at 2:23 PM, Phil Hunt wrote:
>>> 
>>>> I have been wondering if we can combine a couple of things such as a client generated transaction secret and use limited TLS to achieve a fix.  Note: this would address a hacker sniffing a returned authorization code, but it probably does little for the MITM scenario that was also outlined.
>>>> 
>>>> 1. The client app generate a random number or sequence of characters, lets call it "request_id", then that value would be included and securely (using TLS) transmitted in the authorization request.
>>>> 2. The authorization server does its usual thing and returns, preferably securely but not necessarily, the authorization code to the client app.
>>>> 3. Upon requesting an access_token, the client app also includes the same request_id in its secure request to the token endpoint.
>>>> 4. The token server verifies that the "request_id" matches the request_id supplied in the authorize request (in addition to all the other processing).
>>>> 
>>>> Since both requests are sent securely a sniffing client cannot obtain the client request_id even though it might be able to obtain the authorization code being returned.
>>>> 
>>>> What this might allow is that the client can transmit a secret protected by TLS in its outbound request, but can accept non-secure delivery of the authorization code.  The token server then has a means to verify that the client exchanging the authorization code is the same one that made the initial request.
>>>> 
>>>> This is off the top of my head, I am sure the proposal is likely not yet a complete solution, but maybe someone can build on that.
>>>> 
>>>> Phil
>>>> [e-mail]
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 2011-04-04, at 10:52 AM, Oleg Gryb wrote:
>>>> 
>>>>> After looking into exiting (and working) implementations of OAuth 1.0 in mobile world I have strong doubts about possibility of implementing what was suggested in option #3. 
>>>>> 
>>>>> In my view, two conditions are needed to achieve that:
>>>>> 
>>>>> 1. Something unique stored on a mobile client.
>>>>> 2. That something should be a secret, so other (malicious) clients could not reuse it.
>>>>> 
>>>>> Distribution of that "unique secrets" should be automated in the mobile world and is usually included to mobile application 
>>>>> activation process, but that activation process can't make conditions 1 & 2 above met in full, becuase:
>>>>> 
>>>>> 1. As soon as secrets are distributed to a mobile device they are not quite secret any more
>>>>> 2. As soon as the secret becomes known, a simulator or other mobile device can be used to spoof the traffic
>>>>> 
>>>>> I would consider option #3 as an illusion until somebody comes up with a solution that would address the described issues.
>>>>> 
>>>>> BTW, the draft of "OAuth Dynamic Client Registration Protocol" (http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-00) has expired on Feb. 12 and I didn't see any attempts to re-vitalise it. I think it would be better and more beneficial for the community to return to this protocol rather than inventing a new method of "mutual authentication". 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> From: Phil Hunt <[e-mail]>
>>>>> To: Prateek Mishra <[e-mail]>
>>>>> Cc: OAuth WG <[e-mail]>
>>>>> Sent: Mon, April 4, 2011 9:52:17 AM
>>>>> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed)
>>>>> 
>>>>> Apologies for the long message (again). I have attempted to sum things up and bring out the issue without using any existing service or party as an example of problems. It seems some have taken offence to my previous message pushing for a solution. As a result it was not productive. I apologize.  Hopefully this message sticks to the issue of developing an appropriate counter measure to threats as that is my only intent.
>>>>> 
>>>>> As Prateek clarified in the previous message to Francisco, SAML also uses SHOULD, but artifact security is achieved by an additional counter-measure...
>>>>>> The identity provider MUST ensure that only the service provider to whom the <Response> message has
>>>>>> been issued is given the message as the result of an <ArtifactResolve> request.
>>>>> 
>>>>> Yet, in OAuth the client app is not unique for a particular set of client credentials we currently have no way to verify that the correct client got the code. This has been the mechanism that the community has been assuming solves the problem. Client credentials do not always work to protect the authorization code because in OAuth you can have many many clients with the same credential. For example everyone with the same mobile app likely has the same client credential. Thus a copy of a valid client app which is easy to obtain becomes the hacker's attack vector. So, the client credential is not an effective counter in this case.
>>>>> 
>>>>> Several have commented that there are other supplementary techniques for protection, but in my view, most of them work indirectly and/or depend on correct collective configuration of several components. Some of these are: tokens may be used one time; tokens are invalidated if used a second time, tokens are sufficiently unique, etc.  All of these will help. But none are designed to directly counter the attack. In fact the best one - token invalidation carries the additional problem of unreliable service for the legitimate client. The hacker can deny service to anyone in the room simply by re-using any tokens seen.
>>>>> 
>>>>> From my perspective, the "easy" solution was to increase the requirements on TLS from SHOULD to MUST to prevent eavesdropping of the code. This was echoed by several others. I agree this will not work for everyone. Many have made strong arguments for why they can't use it. But without a MUST we are still missing a direct counter to the threat.
>>>>> 
>>>>> I don't want to change things at this late date, but maybe this means introducing some form of mutual authentication -- some way for the requesting client "instance" to prove that they are the copy eligible to use an authorization code. 
>>>>> 
>>>>> To end this discussion, I propose we vote on the proposal from Eran plus one new option...
>>>>> 1. Include a normative MUST use TLS for the client redirection URI endpoint.
>>>>> 2. Include a normative SHOULD use TLS for the client redirection URI endpoint with strong language explaining the various attacks possible if the endpoint is not made secure.
>>>>> 3. Keep current language of SHOULD, but develop a direct counter-measure to token theft such as specific client instance identification or mutual authentication.
>>>>> 
>>>>> Phil
>>>>> [e-mail]
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2011-04-04, at 8:57 AM, Prateek Mishra wrote:
>>>>> 
>>>>>> Francisco,
>>>>>> 
>>>>>> You are right, I was in error to suggest that it was a MUST.
>>>>>> 
>>>>>> I think my main concern was that security considerations should not be based on polling developers/deployers of an existing or legacy protocol.
>>>>>> 
>>>>>> SAML does include some additional countermeasures though - for example (lines 595-596, profiles document) - that specifically deal with the
>>>>>> artifact being leaked - 
>>>>>> 
>>>>>> [quote]
>>>>>> The identity provider MUST ensure that only the service provider to whom the <Response> message has
>>>>>> been issued is given the message as the result of an <ArtifactResolve> request.
>>>>>> [\quote]
>>>>>> 
>>>>>> - prateek
>>>>>>> Hi Prateek,
>>>>>>> 
>>>>>>>> I would like to strongly disagree with this proposal.
>>>>>>>> 
>>>>>>>> It amounts to explicitly making OAuth 2.0 insecure so as to
>>>>>>>> satisfy some mysterious and unspecified set of legacy OAuth
>>>>>>>> 1.0 deployments.
>>>>>>>> 
>>>>>>>> The SAML web SSO (artifact) profile - which shares many
>>>>>>>> characteristics with the initial steps in OAuth - requires
>>>>>>>> precisely such a counter-measure and is widely implemented
>>>>>>>> in 1000s of deployments.
>>>>>>> 
>>>>>>> What counter-measure is this?  Can you provide a reference?
>>>>>>> Section 4.1.3.5 of 
>>>>>>> http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
>>>>>>> recommends TLS but does not require it.
>>>>>>> 
>>>>>>> Francisco
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth