Thanks, Oleg, for the note. I agree that key distribution has been a difficult problem. Since the OAuth draft 10 section 2.1 provides a mechanism for the client to authenticate to the Authz Server using some shared symmetric secret, I think the MAC scheme can be built on the presumably available shared secret. It appears that the DDoS vulnerability stated below could be addressed if we require the authorization code to be accompanied by a MAC (using a key derived from some secret shared between the Authz Server and the client), and the client validates the MAC and the freshness of the authorization code before sending it to the Authz Server.
> I think there is some kind of automatic client registration protocol > under way. It will handle new clients registration and initial key > distribution, but AFAIK it's not governed by IETF's OAuth group. Do you have a link to the current draft of the registration protocol? I would be very interested to read it as this is a non-trivial problem. As an aside, I have received some very good critique in private from a few other people. I will summarize the discussion in a separate posting, later. Best, Eric On Thu, Nov 18, 2010 at 1:32 AM, Oleg Gryb <oleg_g...@yahoo.com> wrote: The concern is valid, but proposed solution would be hard to implement: everybody who has implemented at least one crypto system where symmetric keys need to be distributed between external parties would tell you that, let alone OAuth use cases where you can have many web server clients dynamically added to existing service providers. If you add a requirement of periodic key rotation that is very common nowadays then implementation will become even more difficult. PKI would be a better approach in my view: Authz Server would need to sign using a a private key and web client will use a public key to verify the signature, but again in case of key rotation, an automatic key exchange mechanism would need to be involved. I think there is some kind of automatic client registration protocol under way. It will handle new clients registration and initial key distribution, but AFAIK it's not governed by IETF's OAuth group. ----- Original Message ---- > From: "pf...@cs.stanford.edu" <pf...@cs.stanford.edu> > To: oauth@ietf.org > Cc: Dawn Song <dawns...@cs.berkeley.edu>; John Mitchell ><mitch...@cs.stanford.edu>; Peifung Eric Lam <pf...@cs.stanford.edu>; Devdatta >Akhawe <devda...@eecs.berkeley.edu>; Adam Barth <aba...@gmail.com> > Sent: Fri, November 12, 2010 5:47:35 PM > Subject: Re: [OAUTH-WG] vulnerability in OAuth 2.0/ 1.0/ WRAP leading to DDOS >attacks > Hi, > We are a group of university researchers and have been applying a formal > approach to analyze web security protocols. Devdatta gave a talk at IIW at > Mountain View last week about our work, and a summary of our earlier results can be found at > http://theory.stanford.edu/~jcm/papers/browsermodel-csf-2010.pdf . While analyzing OAuth specifications (2.0/1.0/WRAP), we found that a vulnerability exists that can be exploited to carry out DDOS > attacks. Under the current specifications, such attacks are difficult to > differentiate from legitimate and non-malicious connections, so rate-limiting based on user identities or machine fingerprinting are likely to be ineffective. A tentative solution is proposed at the end of > this email. Any feedback is welcome! > Best, > Peifung Eric Lam > ===== > In the OAuth 2.0 and the OAuth WRAP specifications, we found that in the > Web Server/Web App profile, an attacker can send an HTTP request to the redirect URI of a client web application (with an arbitrary authorization > code), causing the client to issue an HTTPS request to the OAuth Authorization Server. The revelant sections in OAuth 2.0 Draft 10 are 1.4.1(C), and sections 3 and 4. A slightly modified attack can be mounted > against OAuth 1.0 as specified in RFC 5849. > From our initial analysis, this feature of OAuth can be exploited by attackers to launder requests through trusted OAuth clients and launch a > DDOS attack on the Authorization Server. Under the current specifications > such attacks are difficult to differentiate from legitimate and non-malicious connections, so rate-limiting based on user identities or machine fingerprinting are likely to be ineffective. > Specifically, an attacker can bombard the redirect URIs of the web application clients, causing a flood of HTTPS connections to the OAuth Authz Server. This can lead to depletion of resources on the Authz Server > and prevent HTTPS connections carrying legitimate payload from reaching the Authz Server. During such an attack, all that the Authz Server learns > (based on the 1.0, 2.0, and WRAP specs), is that a) each request comes from a registered web site which may have legitimate business making such > a request, and b) the tokens conveyed in each request. However, as the attacker can issue authorization codes that are just (pseudo-) random bit > strings not tied to any end-user identity, the Authz Server has learned little information regarding the attacker or its machines causing such frivolous connections. > A large number of web application clients integrated with the Authz Server > can help the attacker obfuscate its sources of attack and make information > collection for DDOS defense more difficult. From statistics released by popular websites (such as Facebook), we expect the number of clients can > be as high as a million. > It seems that if we require the authorization code to be signed by the Authz Server (or HMAC'ed using a shared key between the Authz Server and > the Client), and the client verifies the signature or HMAC code first before connecting to the Authz Server, then the above DDOS attack can be > largely foiled. > Please let us know if you would like to discuss this issue further so that > we can devise a clean solution to this problem. > Eran Hammer-Lahav <e...@hueniverse.com> wrote: > > > > The right place to bring this up for discussion is the IETF OAuth > mailing list: oa...@ietf.org. > > > > Thanks! > > > > EHL > _______________________________________________ > 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
