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
