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

[Eran Hammer-Lahav <[e-mail]>]

Hey Torsten,

> -----Original Message-----
> From: Lodderstedt, Torsten [mailto:[e-mail]]
> Sent: Thursday, August 18, 2011 12:52 AM
> To: Eran Hammer-Lahav; Torsten Lodderstedt; [e-mail]
> Subject: AW: [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?
> 
> I'm honestly surprised you do not understand the attack. The client simply
> uses screen scraping on the authorization flow and programmatically
> "presses" the right buttons. This obviously only works if the client can predict
> the form structure and expected input values.

That's not an attack but a description of capabilities. The attack example provided by Niv is a *classic* CSRF attack on the authorization endpoint.

> >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.
> 
> This text has been proposed by 2 WG members (Niv and me), and reviewed
> by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of
> your strong assessment?

I don't understand the attack and how the proposed solution address it. I'm really happy for everyone else who got it, but I need more information to process it.

> The text proposes three classes of countermeasures (detect source, prevent
> using unpredictable input, inform resource owner and give her a chance to
> revoke). CAPTCHAs are one out of three examples given for unpredictable
> input. So I don't understand why your objection focuses on it.

True. But it was central in the list discussion and was promoted as strong defense to whatever this attack is. I think that CAPCHA is an impractical recommendation in general for the authorization endpoint. Can you point to any real world example of a large provider forcing CAPCHA on every login? That's what this amounts to.

> The selection
> of the appropriate countermeasure is the task of the service provider and it
> will most likely depend this on its capabilities, cost, user experience, and
> risk/impact associated with abuse. CAPTCHAs (and even one time
> passwords) might not be the choice for the average internet service. This will
> be completely different if OAuth is used to process payment transactions.

The text hints at a very dangerous attack vector of scripts doing 'really bad things'. But it doesn't show why this attack requires any kind of automation at all. If I am targeting just a small number of people, I can "automate" this by sending a message to a human who will break the CAPCHA and quickly return the link to approve access. The other measures either have the same properties, are just there to annoy the attacker, or provide some kind of after the fact notice (when it is clearly too late to prevent damage).

> >I'm keeping this proposed text out until we resolve this questions.
> 
> See above - I probably misunderstand the IETF process, but several people
> agreed with it and no one (except you) objected. Why do you hold it back?

"no one (except you)" is an interesting statement... :-)

This is not a process issue. New text has been proposed with the support of a few working group members. The working group has been largely silent about it (and the review you referenced above was done off list). I have read the new text and did not understand it, therefore, could not edit the text as I have done with every other proposed language.

No new draft will be published until we resolve all open issues, which is exactly what I have stated above. To make it clearer:

I am keeping this proposed text out of *my* working draft for -21 until the working group discusses the text further and addresses the issues I have raised about the text as a working group member (technical issues) and as an editor (clarity issues).

As for IETF process, all it takes is one objection to block text from being *automatically* added to the specification. I have not implied anywhere that I have made any decision (or have the authority to) with regard to this text, only that I'm holding it back until the issues are resolved. And IETF process does not require full agreement to solve issues which is the role of the chairs to resolve. In this case, we're nowhere near needing help from the chairs - just the assistance of the text authors to do their job and explain it.

EHL