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

[Mark Mcgloin <[e-mail]>]

Hi Michael

Can you clearly word the threat for which this countermeasure (or lack of)
applies


thanks
Mark

Michael Thomas <[e-mail]> wrote on 03/01/2012 23:52:54:

> From:
>
> Michael Thomas <[e-mail]>
>
> To:
>
> Phillip Hunt <[e-mail]>
>
> Cc:
>
> Mark Mcgloin/Ireland/IBM@IBMIE, Barry Leiba
> <[e-mail]>, oauth WG <[e-mail]>, "oauth-
> [e-mail]" <[e-mail]>
>
> Date:
>
> 03/01/2012 23:53
>
> Subject:
>
> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
2011
>
> On 01/03/2012 03:46 PM, Phillip Hunt wrote:
> > -1. I think you should be suggesting alternative text at this
> stage. We all have same responsibilities here.
>
> My "responsibility", such as it is, is to bring up that the document's
> threat mitigations suggested don't work. I am only a recent and
> reluctant participant, versus the principals of this working group
> who have been around for many years.
>
> But if you insist, here's my concise suggestion to that points that I
> raised objections to:
>
> "No known mitigation exists."
>
> Mike
>
> >
> > 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
>