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

[Michael Thomas <[e-mail]>]

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