Re: [OAUTH-WG] vulnerability in OAuth 2.0/ 1.0/ WRAP leading to DDOS attacks

[Oleg Gryb <[e-mail]>]

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: "[e-mail]" <[e-mail]>
> To: Oleg Gryb <[e-mail]>
> Cc: Dawn Song <[e-mail]>; John Mitchell 
><[e-mail]>; [e-mail]; Devdatta Akhawe 
><[e-mail]>; [e-mail]; Adam Barth <[e-mail]>
> 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 <[e-mail]> 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: "[e-mail]" <[e-mail]>
> > To: [e-mail]
> > Cc: Dawn Song <[e-mail]>; John  Mitchell
> ><[e-mail]>; Peifung  Eric Lam <[e-mail]>;
> Devdatta
> >Akhawe  <[e-mail]>;  Adam Barth <[e-mail]>
> > 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-mail]>   wrote:
> > >
> > > The right place to bring this up for discussion  is the  IETF OAuth
> > mailing list: [e-mail].
> > >
> > >   Thanks!
> > >
> > >  EHL
> >  _______________________________________________
> > OAuth mailing   list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> 
> 
> 
> _______________________________________________
> OAuth  mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>