Re: [OAUTH-WG] problem statement

[Michael Thomas <[e-mail]>]

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>