Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01

Michael Thomas <> Tue, 24 January 2012 19:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F8C321F8550 for <>; Tue, 24 Jan 2012 11:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nVB1--4XTNZe for <>; Tue, 24 Jan 2012 11:06:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 342BA21F855F for <>; Tue, 24 Jan 2012 11:06:01 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q0OJ5vpJ019969 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Jan 2012 11:05:58 -0800
Message-ID: <>
Date: Tue, 24 Jan 2012 11:05:57 -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: Justin Richer <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2978; t=1327431958; x=1328295958; 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]=20[apps-discuss]=20Apps=20Ar ea=20review=20of=20draft-ietf-oauth-v2-threatmodel-01 |Sender:=20 |To:=20Justin=20Richer=20<> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=cvbRGHNWa4QIKEJShvzp5f/4ejraWmDprivx4Pf8m9w=; b=M3w5XLxfSfMJDx6p/Y5TNBQElNSr2XDabAp8lZcWRONV1T0TEbosvZ3/ii eWU9WXA056c9Zgw1dNtSX+fagAFmrINWBjn6R+MJB5K8+YbWMhBAYXFZ1ZnY fIClyrV9ErNAahm2KxXDvy8L4pdE/p+DExWa8gO322YueCP26+tec=;
Authentication-Results: ; v=0.1; dkim=pass ( sig from verified; ); dkim-asp=pass
Subject: Re: [OAUTH-WG] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01
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, 24 Jan 2012 19:06:02 -0000

On 01/24/2012 05:57 AM, Justin Richer wrote:
> Keep in mind that a major purpose of this document is to encourage best practices by well-meaning developers. We want to make it clear for people who want to do the right thing what the right thing to do is. No document in the world will make ill-meaning developers do the right thing.

That what BCP's are for. A threat document is supposed to outline threats
and what good guys can do to mitigate them. Telling bad guys to be good
is completely useless.


>  -- Justin
> On 01/23/2012 07:17 PM, Michael Thomas wrote:
>> On 01/23/2012 01:47 PM, S Moonesamy wrote:
>>> Minor Issues:
>>> 2nd bullet.  The explanation of why this wouldn't work for
>>> native clients wasn't comprehensible to me.  I'm suspicious of any
>>> such claims because I can emulate most things a browser can do in a
>>> mobile client.  Perhaps this would be obvious to someone who is an
>>> OAuth2 implementor.
>> Actually I'd say that it is *not* obvious because I joined the working
>> group mailing list as an oauth deployer who had precisely questions
>> along these lines expecting that I was *wrong* in worrying about this
>> attack.
>> I'd also say in this section and others like it dealing with native apps
>> that saying:
>>    " Assumption: It is not the task of the authorization server to protect the end-user's
>>     device from  malicious software"
>> Is wrong headed. It's not the authorization server's task to protect the end user,
>> but the authorization server *surely* has an interest in protecting *itself* from
>> rogue clients. An attack by a malicious client is an attack against the end user
>> *and* the authorization server.
>>> I think where it says "iFrame" it might mean "WebView", i.e. a
>>> Web Browser control embedded in the native app.  If that's not what it
>>> means, I don't understand what it's saying.  If this is true, then the
>>> second bullet point is probably wrong.
>> I agree, and don't think the first bullet makes any sense either:
>>    "Native applications SHOULD use external browsers instead of
>>     embedding browsers in an iFrame when requesting end-user authorization"
>> Who exactly is the attacker here? If it's the native app itself, then
>> this isn't a countermeasure at all because the rogue client will ignore
>> this SHOULD. If it's not the native app, then what is the an external
>> browser doing that an embedded browser cannot?
>> I don't understand the third bullet in this one either, but if only works
>> in older browsers it's probably not worth mentioning.
>> Mike
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list