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

Michael Thomas <> Tue, 03 January 2012 23:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C794011E8089; Tue, 3 Jan 2012 15:39:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GhP+Vmvj1y0y; Tue, 3 Jan 2012 15:39:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4787E11E8086; Tue, 3 Jan 2012 15:39:24 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q03NIHvP022271 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 3 Jan 2012 15:18:18 -0800
Message-ID: <>
Date: Tue, 03 Jan 2012 15:18:17 -0800
From: Michael Thomas <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20090605 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Mark Mcgloin <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7226; t=1325632762; x=1326496762; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20Michael=20Thomas=20<> |Subject:=20Re=3A=20[OAUTH-WG]=20WGLC=20on=20draft-ietf-oau th-v2-threatmodel-01,=20ends=209=0A=20Dec=202011 |Sender:=20 |To:=20Mark=20Mcgloin=20<> |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=7QGObA2xW4o5EK3HSmybED7CRcpl3ogcxIbEsHw818A=; b=nEEuI1+JeVV5gbi0w096sJ8Grxdxbn5S7qdsRwe6H8mQmx+UuWlRs0oWfu M6jX06odb1tZPmtjjEttwuvLafly9ovs3jUYdKJbFplrf6/RCc6Eu5HVv3qE XChbV/DtiBJSujlkBx1Z/Wehjh+c80Ru/dqHjuqVFbfrCyHTm/F6c=;
Authentication-Results: ; v=0.1; dkim=pass ( sig from verified; ); dkim-asp=pass
Cc: Barry Leiba <>, oauth WG <>,
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jan 2012 23:39:49 -0000

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.


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
>> wrote on 15/12/2011 18:15:45:
>>> From:
>>> Michael Thomas<>
>>> To:
>>> Phil Hunt<>
>>> Cc:
>>> Barry Leiba<>, oauth WG<>
>>> Date:
>>> 15/12/2011 18:16
>>> Subject:
>>> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
>> 2011
>>> Sent by:
>>> 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
>>>> [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 mailing list