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
