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
