Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

I'd like to ask the chairs to open an issue for this.

I didn't realize how hyper sensitive this working group has become that every proposal being questioned needs a ticket to prove to people that they are not being dismissed. But since this is clearly the case, let's be pedantic and open an issue.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, August 17, 2011 10:58 PM
> To: Torsten Lodderstedt; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> Impersonation)
> 
> I've read the thread leading to this, and the proposed text and I do not
> understand the attack. Can you provide a step-by-step scenario of how an
> attacker gains access?
> 
> Also, it is unlikely that any major provider is going to require CAPCHA as part
> of the authorization flow. This is especially true in the case of using OAuth for
> login which has to be practically transparent (one click). I would hate to
> recommend a solution that no one is going to take seriously.
> 
> I'm keeping this proposed text out until we resolve this questions.
> 
> EHL
> 
> 
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> > Of Torsten Lodderstedt
> > Sent: Friday, August 12, 2011 7:56 AM
> > To: oauth@ietf.org
> > Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner
> > Impersonation)
> >
> > Hi all,
> >
> > I think the impersonation issue as raised by Niv on the list should be
> > covered by the core spec. It directly aims at the trustworthiness of
> > the user consent, which in my opinion is one of the core principles of
> > OAuth. I therefore suggest to add a description to section 10.
> >
> > Please find below the text Niv and I prepared. In comparison to  Niv's
> > original proposal, it covers resource owner impersonation for all client
> categories.
> >
> > regards,
> > Torsten.
> >
> > proposed text:
> >
> > 10.<to be determined> Resource Owner Impersonation
> >
> > When a client requests access to protected resources, the
> > authorization flow normally involves the resource owner's explicit
> > response to the access request, either granting or denying access to the
> protected resources.
> >
> > A malicious client can exploit knowledge of the structure of this flow
> > in order to gain authorization without the resource owner's consent,
> > by transmitting the necessary requests programmatically, and
> > simulating the flow against the authorization server. An suthorization
> > server will be vulnerable to this threat, if it uses non-interactive
> > authentication mechanisms or split the authorization flow across multiple
> pages.
> >
> > It is RECOMMENDED that the authorization server takes measures to
> > ensure that the authorization flow cannot be simulated.
> > Attacks performed by scripts running within a trusted user-agent can
> > be detected by verifying the source of the request using HTTP referrer
> headers.
> > In order to prevent such an attack, the authorization server may force
> > a user interaction based on non-predictable input values as part of
> > the user consent approval.
> >
> > The authorization server could combine password authentication and
> > user consent in a single form, make use of CAPTCHAs or one-time secrets.
> >
> > Alternatively, the authorization server could notify the resource
> > owner of any approval by appropriate means, e.g. text message or e-Mail.
> >
> > _______________________________________________
> > 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