Phil
Sent from my phone. On 2011-04-04, at 18:39, Skylar Woodward <sky...@kiva.org> wrote: > On Apr 4, 2011, at 4:06 PM, Phil Hunt wrote: > >> For the moment, I'm only talking about mobile clients. >> >> Very quickly here is the attack... >> 1) Paul starts dance at good Client & good AS, App requests authorization. >> Note: outbound call is secure, but returned redirect is not. > > I'm going to re-iterate Brian's point that this is not an interesting attack > because we have no problem with securing a response to the outbound call. > Just to be very clear that we're all speaking about the same thing here I'm > detailing what you are implying in step one (assuming pop-out to external > browser as you mentioned earlier in this thread): > > - Paul's mobile device (MD), running native client C, makes request to the > mobile browser (MB) on the same device for the OAuth authorization page for > provider P. > - The MB makes an outbound request over TLS to P's outh/authorization > endpoint. (HTTPS) > - P responds over the same socket with the approval (and or login pages). > (still HTTPS) Not guaranteed by spec nor in practice. > - Paul clicks the Approval button on the provider authorization page which > initiates MB to make a new HTTPS call confirming the approval. Again not in practice. > - MB responds on the same secure socket (HTTPS!) with the composed redirect > URI including auth code. Note here that the redirect URI uses a custom > protocol since the authorization is happening in an external browser (not > embedded in the client). This looks like something > x-application-myapp://oauth-callback?code=secret My scanner is showing this is not happening. Moreover the spec only says it is a SHOULD per the discussion. This is the point that is often trivial to eavesdrop and easy to pass into Brian's browser. The browser does the rest of the hack all by itself by following the link. > - MB handles the redirect URI by opening the native client C, passing it the > redirect URI from the previous step. This is a secure transfer of data > between two apps on MD. Agreed. > > This is the only flow on the table for a native mobile app using auth codes > and an external browser. All exchanges between clients (C and MB) and server > are over TLS. There is no MITM or sniffing exploit for this flow. > Only true if TLS is on. > For an embedded browser flow, the flow is similarly secure as Brian took care > to describe. The redirect URI might be an URN, a custom URI, or an HTTPS url. > > For an intercept to happen as you've outlined in step 2, MB or native client > C must make a **new** network connection to some yet-to-be- Remember the token request is a NEW endpoint. > identified server. To me, it seems beyond obvious that the redirect response > from the provider's authorization server would be secured over the same > socket that started the authorization. If the authorization server redirects > to itself using an HTTP url which then responds with the redirect URI, that > is a poorly implemented authorization server and would be non-complient > according to the spec. That's sloppy coding, not a sloppy spec. I think you are over complicating. Look at the Facebook implementation (No offense to Facebook) and watch with a scanner. > > So, this leaves us no identified security compromise for the native mobile > client, thus no need for further measures to secure this flow. > > Whew. Well the hack works just fine for me. I really wish you were correct. :) > > >> 2) Evil Brian intercepts the (HTTP) redirect containing Paul's authz code >> 3) Brian takes Paul's redirect #2 and enters it in his browser (e.g. by >> script) >> 4) Brian's browser processes redirect URI from #3 and passes to Brian's copy >> of client (e.g. downloaded from app store). >> 5) Brian's client exchanges substituted authz code for access token >> 6) Brian's client now accesses service using Paul's authorization >> >> As was explained earlier this attack is minimized by things like token >> invalidation when the second client comes along, but we still have a >> horserace and possibility of DoS for the user at minimum. >> >> The server cannot mitigate this unless it can either ensure the client is >> the only one that could have received the code, or can somehow uniquely >> identify the client so that a copy cannot masquerade as the original >> requestor. >> >> Phil >> phil.h...@oracle.com >> >> >> >> >> On 2011-04-04, at 12:52 PM, Skylar Woodward wrote: >> >>> 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
