-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 <m...@mtcc.com> 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 >>> >>> oauth-boun...@ietf.org wrote on 15/12/2011 18:15:45: >>> >>>> From: >>>> >>>> Michael Thomas<m...@mtcc.com> >>>> >>>> To: >>>> >>>> Phil Hunt<phil.h...@oracle.com> >>>> >>>> Cc: >>>> >>>> Barry Leiba<barryle...@computer.org>, oauth WG<oauth@ietf.org> >>>> >>>> Date: >>>> >>>> 15/12/2011 18:16 >>>> >>>> Subject: >>>> >>>> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec >>> 2011 >>>> Sent by: >>>> >>>> oauth-boun...@ietf.org >>>> >>>> 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 >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> > >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
