I'm confused - it seems like you're mixing web clients and native clients in this most recent explanation. It's perfectly reasonable that the authorization code will always be returned by a provider in a secure TLS channel to the web browser or native client which started the authorization request. What's not reasonable is, in the case of the code returned to a web browser (acting on behalf of a web client), for the browser to then pass the code on to the web client over TLS.
Maybe you can elaborate the attack you are considering by listing each network request/response between the mobile client and any servers? I'll repeat again that the attack I've seen described thus far doesn't apply to mobile apps with( or without) many copies because there is no local redirect involved. (The redirect URI is merely an identifier that says "here's the code!" - it need not be a network location, and if it is, it's just a local location on the same device - eg, another app running on the same device). skylar On Apr 4, 2011, at 3:38 PM, Phil Hunt wrote: > If you run a scanner, you will see that many of the current draft > implementations pass the authorization code by redirect without SSL. I've > seen several implementations where the authorization code is easy to scan. > > I suspect this occurs because the HTTP response isn't directly in response to > the original outgoing authorization. When I run the scanner, the resource > provider is performing a workflow with the user that accomplishes form based > authentication and authorization with the user, some of which is not on SSL. > What happens is the redirect is then not sent by SSL. It seems like only a > natural consequence of typical authentication/authorization workflows. Or at > best, it is difficult the guarantee that the authorization code will always > be returned in a secure TLS channel. > > Several people stated that the redirect end-point cannot implement > server-side security (called local redirect) and I think their request is > reasonable as it would require each client to have its own server > certificate. That *might* be acceptable to most web apps, but likely won't > work for apps with many many copies like mobile apps. > > So, I'm making the assumption that if we can minimally count on outbound TLS > security, the transaction id would suffice to allow the token service to > connect the originating authorization client with the client requesting an > access token. > > Phil > phil.h...@oracle.com > > > > > On 2011-04-04, at 12:28 PM, Skylar Woodward wrote: > >> But mobile clients aren't vulnerable to this type of attack because all of >> their code is contained on the device and they make all outgoing requests to >> the provider via SSL. There are no redirects to insecure remote endpoints. >> A mobile device incapable of making outgoing SSL requests would not be able >> to run an OAuth-compliant client as the spec is currently written. >> >> Where in this example is the un-encrypted exchange you are trying to protect? >> >> >> On Apr 4, 2011, at 3:12 PM, Phil Hunt wrote: >> >>> 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 >>> phil.h...@oracle.com >>> >>> >>> >>> >>> 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 <sky...@kiva.org> 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 >>>>>>> phil.h...@oracle.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 <phil.h...@oracle.com> >>>>>>>> To: Prateek Mishra <prateek.mis...@oracle.com> >>>>>>>> Cc: OAuth WG <oauth@ietf.org> >>>>>>>> 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 >>>>>>>> phil.h...@oracle.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
