Re: [OAUTH-WG] draft-ietf-oauth-v2-threatmodel

Phil Hunt <> Wed, 02 May 2012 17:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB4EE21F8548 for <>; Wed, 2 May 2012 10:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H0dPlM7XesDP for <>; Wed, 2 May 2012 10:35:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 739B721F8543 for <>; Wed, 2 May 2012 10:35:04 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q42HYrss027230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 May 2012 17:34:53 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id q42HYqYD023117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 17:34:52 GMT
Received: from ( []) by ( with ESMTP id q42HYq3v011988; Wed, 2 May 2012 12:34:52 -0500
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 May 2012 10:34:51 -0700
References: <>
In-Reply-To: <>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <>
X-Mailer: iPhone Mail (9B179)
From: Phil Hunt <>
Date: Wed, 2 May 2012 10:36:16 -0700
To: Hannes Tschofenig <>
X-Source-IP: []
Cc: " WG" <>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-threatmodel
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: Wed, 02 May 2012 17:35:05 -0000

I think you hit the nail on the head. 

My feeling is that threats not directly related to OAuth obfuscate the key issues we are trying to alert implementers and deployers to. 

I think Barry made a good proposal but Michael still feels Barry's text has not addressed the issue. 

I think you are right to escalate the issue for guidance. 


On 2012-05-02, at 9:02, Hannes Tschofenig <> wrote:

> Hi all, 
> I looked at the feedback for the draft-ietf-oauth-v2-threatmodel and I want to share my thoughts with you (as a WG co-chair).
> I believe there are three questions that need to be answered:
> 1) Is malicious code a problem? 
> I believe most people would agree that malicious code is indeed a problem for Internet security. 
> 2) Are IETF working groups required to address this extended Internet threat model? 
> RFC 3552 provides guidance for protocol developers writing security considerations. It also defines terminology and a threat model. 
> The model, however, does not consider malicious code as a threat. 
> Malicious code is a problem for any IETF protocol, not just for OAuth. This requires a broader IETF discussion.  
> If there is the believe that IETF groups should (a) describe threats that result from malicious code and (b) develop solutions to deal with it then the IAB  should facilitate such a discussion. I will discuss this topic within the IAB. 
> Despite the lack of available guidance in RFC 3552 draft-ietf-oauth-v2-threatmodel talks about this threat. 
> 3) What can we do to highlight the threat in our document? 
> Barry proposed additional text (see below) that highlights the challenges. 
> This issue as resolved. Let's move forward. 
> Ciao
> Hannes
> PS: Here is Barry's proposed tet
> -----------------------------------------------------------------
> 5.5.  A Word on User Interaction and User-Installed Apps
> OAuth, as a security protocol, is distinctive in that its flow usually
> involves significant user interaction, making the end user a part of
> the security model.  This creates some important difficulties in
> defending against some of the threats discussed above.  Some of these
> points have already been made, but it's worth repeating and
> highlighting them here.
> * End users must understand what they are being asked to approve (see
> Section  Users often do not have the expertise to understand
> the ramifications of saying "yes" to an authorization request. and are
> likely not to be able to see subtle differences in wording of
> requests.  Malicious software can confuse the user, tricking the user
> into approving almost anything.
> * End-user devices are prone to software compromise.  This has been a
> long-standing problem, with frequent attacks on web browsers and other
> parts of the user's system.  But with increasing popularity of
> user-installed "apps", the threat posed by compromised or malicious
> end-user software is very strong, and is one that is very difficult to
> mitigate.
> * Be aware that users will demand to install and run such apps, and
> that compromised or malicious ones can steal credentials at many
> points in the data flow.  They can intercept the very user login
> credentials that OAuth is designed to protect.  They can request
> authorization far beyond what they have led the user to understand and
> approve.  They can automate a response on behalf of the user, hiding
> the whole process.  No solution is offered here, because none is
> known; this remains in the space between better security and better
> usability.
> * Addressing these issues by restricting the use of user-installed
> software may be practical in some limited environments, and can be
> used as a countermeasure in those cases.  Such restrictions are not
> practical in the general case, and mechanisms for after-the-fact
> recovery should be in place.
> -----------------------------------------------------------------
> _______________________________________________
> OAuth mailing list