Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01

[Michael Thomas <[e-mail]>]

On 01/24/2012 05:57 AM, Justin Richer wrote:
> Keep in mind that a major purpose of this document is to encourage best practices by well-meaning developers. We want to make it clear for people who want to do the right thing what the right thing to do is. No document in the world will make ill-meaning developers do the right thing.


That what BCP's are for. A threat document is supposed to outline threats
and what good guys can do to mitigate them. Telling bad guys to be good
is completely useless.

Mike

>
>  -- Justin
>
> On 01/23/2012 07:17 PM, Michael Thomas wrote:
>> On 01/23/2012 01:47 PM, S Moonesamy wrote:
>>>
>>> Minor Issues:
>>>
>>> 4.4.1.4 2nd bullet.  The explanation of why this wouldn't work for
>>> native clients wasn't comprehensible to me.  I'm suspicious of any
>>> such claims because I can emulate most things a browser can do in a
>>> mobile client.  Perhaps this would be obvious to someone who is an
>>> OAuth2 implementor.
>>
>> Actually I'd say that it is *not* obvious because I joined the working
>> group mailing list as an oauth deployer who had precisely questions
>> along these lines expecting that I was *wrong* in worrying about this
>> attack.
>>
>> I'd also say in this section and others like it dealing with native apps
>> that saying:
>>
>>    " Assumption: It is not the task of the authorization server to protect the end-user's
>>     device from  malicious software"
>>
>> Is wrong headed. It's not the authorization server's task to protect the end user,
>> but the authorization server *surely* has an interest in protecting *itself* from
>> rogue clients. An attack by a malicious client is an attack against the end user
>> *and* the authorization server.
>>
>>>
>>> 4.4.1.9 I think where it says "iFrame" it might mean "WebView", i.e. a
>>> Web Browser control embedded in the native app.  If that's not what it
>>> means, I don't understand what it's saying.  If this is true, then the
>>> second bullet point is probably wrong.
>>
>> I agree, and don't think the first bullet makes any sense either:
>>
>>    "Native applications SHOULD use external browsers instead of
>>     embedding browsers in an iFrame when requesting end-user authorization"
>>
>> Who exactly is the attacker here? If it's the native app itself, then
>> this isn't a countermeasure at all because the rogue client will ignore
>> this SHOULD. If it's not the native app, then what is the an external
>> browser doing that an embedded browser cannot?
>>
>> I don't understand the third bullet in this one either, but if only works
>> in older browsers it's probably not worth mentioning.
>>
>>
>> Mike
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth