I agree that there should be mitigation controls in place on web server clients: it would alleviate Authz Server task of blocking fraudulent traffic and make the whole solution more scalable. Using signatures looks like a good idea, but key distribution needs to be automated in this case.
Here is a link to the protocol that I've mentioned before: https://github.com/mrtopf/UMA-Specifications/blob/master/draft-oauth-client-registration.txt It looks like the ownership has moved from UMA to IETF. The main purpose is to dynamically register Authz Server clients (both resource servers and "enhanced" OAuth clients). I'm not sure if "enhanced" clients include web server clients that we've discussed here. It would be great if somebody can clarify. It would be great also if somebody can comment on key distribution and key rotation: will it be covered by the protocol? Is the secret that initially given to an enhanced OAuth client a key? What kind of key? I didn't see too many details in the current draft. Probably it was made this way on purpose to keep all options open. ----- Original Message ---- > From: "pf...@cs.stanford.edu" <pf...@cs.stanford.edu> > To: Oleg Gryb <o...@gryb.info> > Cc: Dawn Song <dawns...@cs.berkeley.edu>; John Mitchell ><mitch...@cs.stanford.edu>; pf...@cs.stanford.edu; Devdatta Akhawe ><devda...@eecs.berkeley.edu>; oauth@ietf.org; Adam Barth <aba...@gmail.com> > Sent: Fri, November 19, 2010 4:27:37 AM > Subject: Re: [OAUTH-WG] vulnerability in OAuth 2.0/ 1.0/ WRAP leading to DDOS >attacks > > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
