Re: [OAUTH-WG] problem statement
Phil Hunt <phil.hunt@oracle.com> Mon, 12 September 2011 18:20 UTC
Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF77E21F8B56 for <oauth@ietfa.amsl.com>; Mon, 12 Sep 2011 11:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.241
X-Spam-Level:
X-Spam-Status: No, score=-5.241 tagged_above=-999 required=5 tests=[AWL=1.358, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNuyMVOCiqFv for <oauth@ietfa.amsl.com>; Mon, 12 Sep 2011 11:20:29 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7421F21F8B55 for <oauth@ietf.org>; Mon, 12 Sep 2011 11:20:29 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8CIMUn5027092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 18:22:32 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8CIMUpN021131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 18:22:30 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8CIMORX010923; Mon, 12 Sep 2011 13:22:24 -0500
Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2011 11:22:24 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <DADD7EAD88AB484D8CCC328D40214CCD0E760C0D88@EXPO10.exchange.mit.edu>
Date: Mon, 12 Sep 2011 11:22:22 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E83227EA-F52A-4FE8-9E2A-F008FDDD9E88@oracle.com>
References: <4E665B25.6090709@mtcc.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <CAMrm-MJHKTxaj1iEm_Lr=X92sOiWZcYN4F6dNqb5w5gh4OPndQ@mail.gmail.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <E3DEC4C8-6BB0-44EE-821A-7589F5DC6462@jkemp.net> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> <4E67C893.5060505@mtcc.com> <4E67D149.8080200@mtcc.com> <D02EDDCE-4498-4B75-9C5F-340A439F0190@niven-jenkins.co.uk> <4E68147E.8000300@mtcc.com> <CAB_mRgPDiZU9uN-XJmKUPkU11BWwb2wbnmZNmsw2y3EnJSPeB! A@mail.gmail.com> <DADD7EAD88AB484D8CCC328D40214CCD0E760C0D88@EXPO10.exchange.mit.edu>
To: Thomas Hardjono <hardjono@MIT.EDU>
X-Mailer: Apple Mail (2.1084)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A02020A.4E6E4DE8.01E9:SCFMA922111,ss=1,re=-4.000,fgs=0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] problem statement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Sep 2011 18:20:31 -0000
Note that the security considerations doc was replaced with the Threat Models WG draft, http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 While that paragraph is not in the Threat Model document, there are numerous threats discussed regarding malicious clients and what the recommended counter measures are. I believe these threats go well beyond Michael's original concerns. I invite Michael to take a look at the Threat Model spec and suggest whether he would either prefer to describe a new threat (and propose text), or whether new introductory text is warranted such as the assumption from the security considerations draft below. Let us know if you have any specific comments on the Threat Model doc, in particular referencing sections/paragraphs which may need refinement to address the concerns. The easiest way to do this, as always, is to suggest edits and proposed replacement text to this mature document. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-09-12, at 10:58 AM, Thomas Hardjono wrote: >>> Basically, in the protocol document's introduction I think it should >>> be clearly explained that the UA functionality is expected to be >>> "trusted", ie not be under the control of a potential attacker. I >>> think that for the uninitiated that is anything but obvious. There has >>> been a sea-change since 2007 making this an important point. Had that >>> been in the introduction, we would not be having this conversation. >>> >>> Mike > > > Mike, > > I have found that the Security Considerations doc helps a lot in understanding the expected deployment conditions of OAUTH (see draft-lodderstedt-oauth-securityconsiderations-02.txt). > > For example, Section 2.2 (about Malicious Client) goes a long way towards answering your concerns: > > Assumption: It is not the task of the authorization server to protect > the end-user's device from malicious software. This is the > responsibility of the platform running on the particular device > probably in cooperation with other components of the respective > ecosystem (e.g. an application management infrastructure). The sole > responsibility of the authorization server is to control access to > the end-user's resources living in resource servers and to prevent > unauthorized access to them. Based on this assumption, the following > countermeasures are recommended. > > Hope this helps. > > /thomas/ > > __________________________________________ > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of David Recordon >> Sent: Saturday, September 10, 2011 1:29 PM >> To: Michael Thomas >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] problem statement >> >> Hey Mike, I think this has been said a few times by Eran and Peter but >> you really need to propose actual sentences that you want to see >> included in the specification at this point. Saying "I think it should >> be clearly explained" isn't actionable text. >> >> That said, I strongly don't believe this is an issue specific to OAuth. >> >> --David >> >> >> On Wed, Sep 7, 2011 at 6:03 PM, Michael Thomas <mike@mtcc.com> wrote: >>> On 09/07/2011 05:19 PM, Ben Niven-Jenkins wrote: >>>> >>>> Your original e-mail that started this thread was not targeted at a >>>> specific document and my interpretation is that some of the >> hostility >>>> you have experienced is due to a frustration that your request is >>>> seen as a potential obstacle to getting the protocol specification >>>> out the door because the issue you want to discuss is not directly >>>> related to how a developer might implement the protocol. >>>> >>> >>> I had no idea where in the ietf process the protocol document is. I'm >>> still not sure whether it's been through wg last call, ietf last >> call, etc. >>> >>>> If I may be so bold, could I suggest that you propose some text that >>>> articulates the issue that you would like to see documented and then >>>> the group can assess that text on its merits and try to reach >>>> consensus on which document, if any, it is best placed to reside >> within. >>>> >>> >>> Basically, in the protocol document's introduction I think it should >>> be clearly explained that the UA functionality is expected to be >>> "trusted", ie not be under the control of a potential attacker. I >>> think that for the uninitiated that is anything but obvious. There >> has >>> been a sea-change since 2007 making this an important point. Had that >>> been in the introduction, we would not be having this conversation. >>> >>> 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
- Re: [OAUTH-WG] problem statement Paul Madsen
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement John Kemp
- Re: [OAUTH-WG] problem statement Michael Thomas
- [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement William Mills
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement William Mills
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Justin Richer
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Jill Burrows
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Aiden Bell
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Aiden Bell
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Justin Richer
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement John Kemp
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement John Kemp
- Re: [OAUTH-WG] problem statement William Mills
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement John Kemp
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Aiden Bell
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Peter Saint-Andre
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Peter Saint-Andre
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Peter Saint-Andre
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement William Mills
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Manger, James H
- Re: [OAUTH-WG] problem statement Justin Richer
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement John Kemp
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Igor Faynberg
- Re: [OAUTH-WG] problem statement David Waite
- Re: [OAUTH-WG] problem statement Phil Hunt
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Peter Saint-Andre
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Aiden Bell
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Aiden Bell
- Re: [OAUTH-WG] problem statement Peter Saint-Andre
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Eran Hammer-Lahav
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement Melinda Shore
- Re: [OAUTH-WG] problem statement Ben Niven-Jenkins
- Re: [OAUTH-WG] problem statement Michael Thomas
- Re: [OAUTH-WG] problem statement David Recordon
- Re: [OAUTH-WG] problem statement Thomas Hardjono
- Re: [OAUTH-WG] problem statement Phil Hunt