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
