Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

[Phillip Hunt <[e-mail]>]

-1. I think you should be suggesting alternative text at this stage. We all have same responsibilities here. 

Phil

On 2012-01-03, at 15:18, Michael Thomas <[e-mail]> wrote:

> Barry -- It's now been two weeks and I haven't heard anything to
> the objections I raised. It is not my responsibility to come up with
> mitigation that works, it's the working group's. If there is no reasonable
> mitigation it should just say that.
> 
> Mike
> 
> On 12/16/2011 06:55 AM, Michael Thomas wrote:
>> On 12/16/2011 03:02 AM, Mark Mcgloin wrote:
>>> Michael,
>>> 
>>> I will review the comments from Phil where he suggests some changes in
>>> section 4.1.4 of the threat model
>>> 
>>> I am unclear exactly what you are proposing. If you want to propose a
>>> clearly worded revamp of that section in the next couple of days, I am
>>> willing to review and accept legitimate changes. Clearly worded means
>>> concise, technically accurate and devoid of alarmist phrases and words used
>>> out of context, such as existential. Can I suggest you review with a
>>> colleague before posting here.
>> 
>> Barry -- I have gone through this section and made comments
>> and was blown off seemingly without reading them at all, and
>> now I'm being told to come up with text for which I can be blown
>> off again: "Can I suggest you review..."
>> 
>> The fact of the matter is that my comments say that the
>> threats are understated and mitigations that are proposed do not
>> work. It's not my job alone to fix this. It's the working group's.
>> In fact if I were to propose text, it would be along the lines of
>> "can't be mitigated" because I do not know how to fix them. If
>> nobody else can come up with a better mitigation, then that
>> *is* what should be there, not some hand waving nonsense that
>> doesn't work.
>> 
>> Mike, "instruct users..." feh
>> 
>>> Regards
>>> Mark
>>> 
>>> [e-mail] wrote on 15/12/2011 18:15:45:
>>> 
>>>> From:
>>>> 
>>>> Michael Thomas<[e-mail]>
>>>> 
>>>> To:
>>>> 
>>>> Phil Hunt<[e-mail]>
>>>> 
>>>> Cc:
>>>> 
>>>> Barry Leiba<[e-mail]>, oauth WG<[e-mail]>
>>>> 
>>>> Date:
>>>> 
>>>> 15/12/2011 18:16
>>>> 
>>>> Subject:
>>>> 
>>>> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
>>> 2011
>>>> Sent by:
>>>> 
>>>> [e-mail]
>>>> 
>>>> On 12/15/2011 09:54 AM, Phil Hunt wrote:
>>>>> Note: one change recommended below...
>>>>> 
>>>>> With regards to 4.1.4…
>>>>> 4.1.4.  Threat: End-user credentials phished using compromised or
>>>>>          embedded browser
>>>>> 
>>>>>     A malicious application could attempt to phish end-user passwords
>>> by
>>>>>     misusing an embedded browser in the end-user authorization process,
>>>>>     or by presenting its own user-interface instead of allowing trusted
>>>>>     system browser to render the authorization user interface.  By
>>> doing
>>>>>     so, the usual visual trust mechanisms may be bypassed (e.g.  TLS
>>>>>     confirmation, web site mechanisms).  By using an embedded or
>>> internal
>>>>>     client application user interface, the client application has
>>> access
>>>>>     to additional information it should not have access to (e.g. uid/
>>>>>     password).
>>>>> 
>>>>> 
>>>>> [mat] I think it's also worth mentioning either here, or in another
>>>>> threat that there is a further social engineering misuse/attack where
>>> an
>>>>> app offers/demands to keep your credentials so that you don't have to
>>> go
>>>>> through the authorization rigmarole. Users are already conditioned to
>>>>> give their credentials up to do things -- just this morning I
>>>> noticed facebook
>>>>> asking for my email password which they promise with sugar on top to
>>> not
>>>>> store. It might be worth mentioning that things like CAPTCHA could be
>>>>> deployed to defend against that sort of attack/misuse.
>>>>> 
>>>>> [Phil] I don't think we need to really add much here. We could
>>>> write whole essays on this topic and likely will.
>>>>> I think the point is simply to educate the client developer that
>>>> there is no need for a client application to ever have access to a
>>>> raw uid/password (or any other user credential).
>>>>> [/Phi]
>>>>> 
>>>> Remember: I came here not understanding whether this threat was real or
>>> not.
>>>> A threat document that can't be bothered to elaborate on one of the
>>> biggest
>>>> existential  threats to the protocol is worthless. The way it is worded
>>>> now does
>>>> not make it crystal clear that, yes, this means UIWebView's in iPhone
>>>> apps, etc too.
>>>> It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH
>>>> SERVER.
>>>> 
>>>> 
>>>>> [snip]
>>>>> 
>>>>>     Countermeasures:
>>>>> 
>>>>>     o  Client developers and end-user can be educated to trust an
>>>>>        external System-Browser only.
>>>>> 
>>>>> 
>>>>> [mat] I assume that this is in here just for the amusement factor
>>> because
>>>>> it is not a credible countermeasure.
>>>>> 
>>>>> [Phil] I agree, Firefox recently demonstrated how poorly users
>>>> recognize the security signals in the browser by dropping the "lock"
>>>> icon without announcement. When I found out, I had already been
>>>> using it for some time and hadn't noticed.  This counter measure
>>>> should be changed to:
>>>>> o The OAuth flow is designed so that client applications never
>>>> need to know user passwords. Where possible Client applications
>>>> SHOULD avoid directly asking for user credentials during an
>>>> authorization flow.
>>>>> [/Phil]
>>>>> 
>>>> The basic problem here is that the client app is not trusted. So if it's
>>>> a bad
>>>> actor this admonition will be ignored. If it's a good actor, there
>>>> wasn't a threat
>>>> in first place. So the mitigation completely misses the mark.
>>>> 
>>>>>     o  Client applications could be validated prior publication in a
>>>>>        application market.
>>>>> 
>>>>> [mat] How would this be done in practice?
>>>>> [Phil] I think this needs to change to:
>>>>> 
>>>>> o Client applications could be validated for acceptable practices
>>>> by the Resource Site provider prior to issuing production Client
>>> Credentials.
>>>> When, exactly, can we expect to see this in the field? Neither Twitter
>>>> or Facebook
>>>> do this. And even if they were so inclined, the draft provides exactly
>>>> zero guidance
>>>> as to what exactly that "validated" might mean in practice. The way I
>>>> read this is:
>>>> "we don't know how to mitigate this".
>>>>> [/Phil]
>>>>>     o  Client developers should not collect authentication information
>>>>>        directly from users and should instead use redirects to and back
>>>>>        from a trusted external system-browser.
>>>>> 
>>>>> 
>>>>> [mat] How would the resource/authentication server enforce such a
>>> thing?
>>>>> [Phil] This is a best practice for the client developer. [Phil]
>>>>> 
>>>>> 
>>>> I don't even know what that means in the context of embedded apps.
>>>> Has anybody even tried this? At the very least, an example flow might
>>>> be useful for the uninitiated client developer.
>>>> 
>>>> 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
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth