On 09/07/2011 12:56 PM, Kristoph wrote:
Mike,

I am an implementer of this specification. I am struggling to understand what 
it is you are trying to communicate.

The only thing I can discern is that you believe there is a large cadre of 
software architects / developers who you think have the skill to read and 
understand this specification, design and implement an OAuth 2.0 server, and 
yet not understand that a rogue embedded UA would compromise the end users 
credentials. Is that basically your concern?

I think that the fine point of a rogue embedded UA will be lost on
people, yes. Especially those who are specing out the higher level
authentication service deployment. We have both Twitter and Facebook
out there in the wild who are subject to this attack right now. Are they
aware of  the attack? I really don't know.

Mike

]{

On Sep 7, 2011, at 12:40 PM, Michael Thomas wrote:

On 09/07/2011 12:32 PM, Peter Saint-Andre wrote:
On 9/7/11 1:24 PM, Michael Thomas wrote:

On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote:

[more browbeating elided]


In fact, you guys have convinced me that OAuth gives inferior
protection at

considerable expense for all concerned.


an irresponsible and serious offense - the kind of baseless FUD that
can cause real damage to important work.


I have written down at least 3 or 4 times why I think it's inferior.
Nobody attacking the messenger including yourself has answered
it. There's FUD here, but not from me.

Mike, did you propose text to address the concern? Per recent discussion
I think the threat-model document is the right place for it, so please
take a look at that spec to see where your proposed text can slot in.

Yes, I outlined what I think should be done at a minimum. I've
also been told by the editor that he won't consider it. Barry
has said that he won't consider it either. Unless the working
group is open to changes, I'm not going to waste my time crafting
the actual changes. So this is your call.

Here's what I wrote previously:

[...]

Second, I'd say that [section 9] is a good first step, but the text there
should be explicit and not pussy-foot around the fact that it
means embedded UA's in phone apps and other examples. It
should also make clear that the "challenge" (ack, ptui) involves
untrusted apps stealing the user's credentials by simply snooping
on the UA itself. If there is reasonable mitigation, then by all means
add text about it. This is important because I do not think that
many people grok the seriousness of the issue, and most especially
people who would deploy oauth authentication services.

Third, I think that the introduction needs to have an applicability
statement of *when/where/what* oauth can be used. That is,
do not beat around the bush about the need for the UA to be
trustable because that is a basic the assumption that oauth makes.
As inconvenient as that may be, it would be far worse for people
in the industry to not fully understand the threat.

Fourth, it would be *really* nice to hear from folks at Facebook
and Twitter who have deployed oauth and oauth-like flows with
their experience here, and most especially if they understood the
threat ahead of their deployment, and what they do to mitigate
it if anything.


Mike
_______________________________________________
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

Reply via email to