Re: [OAUTH-WG] problem statement

Thomas Hardjono <hardjono@MIT.EDU> Mon, 12 September 2011 17:56 UTC

Return-Path: <hardjono@mit.edu>
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 3E24F21F8C22 for <oauth@ietfa.amsl.com>; Mon, 12 Sep 2011 10:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 p4m2viQZmacr for <oauth@ietfa.amsl.com>; Mon, 12 Sep 2011 10:56:51 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3A621F85F2 for <oauth@ietf.org>; Mon, 12 Sep 2011 10:56:50 -0700 (PDT)
X-AuditID: 1209190f-b7b44ae000000a24-90-4e6e47c2d503
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 4A.6D.02596.2C74E6E4; Mon, 12 Sep 2011 13:56:18 -0400 (EDT)
Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p8CHwrOF025521; Mon, 12 Sep 2011 13:58:53 -0400
Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p8CHwq4N019343; Mon, 12 Sep 2011 13:58:53 -0400
Received: from w92exhub5.exchange.mit.edu (18.7.73.11) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 12 Sep 2011 10:57:57 -0700
Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub5.exchange.mit.edu ([18.7.73.11]) with mapi; Mon, 12 Sep 2011 13:58:51 -0400
From: Thomas Hardjono <hardjono@MIT.EDU>
To: David Recordon <recordond@gmail.com>, Michael Thomas <mike@mtcc.com>
Date: Mon, 12 Sep 2011 13:58:51 -0400
Thread-Topic: [OAUTH-WG] problem statement
Thread-Index: Acxv3ygPlMWlltrhTq2d5KspgKxVsQBleFog
Message-ID: <DADD7EAD88AB484D8CCC328D40214CCD0E760C0D88@EXPO10.exchange.mit.edu>
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-XJmKUPkU11BWwb2wbnmZNmsw2y3EnJSPeBA@mail.gmail.com>
In-Reply-To: <CAB_mRgPDiZU9uN-XJmKUPkU11BWwb2wbnmZNmsw2y3EnJSPeBA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTcRTnv3u33a3dvJva/r4CJ5ZZ8/1BImQU1igYGgXVF726q1tt0+6d MkeY9UWwAjX90Ex8MCMfOWeQ9lQXBoqaIoFoJcpKWaYJYUkg3bvrdN9+h9/jnMM5GKL4JYzE jBYrRVtIk0okRRWS8Di155xFl/J3JTGzs84pyhz76RNl3l/7jmoQ7UvHF7HW6dwWaLt7P4pz kGvSU3rKZCyn6OSsfKlhfjK7tO+wzd37QFgFemENkGCQyIATs9sojw/B6a8uUQ2QYgriHYAP 3y+jfDHMFi0dAr74AGDXyMau7AWAQ+sbYr6oBdB5bw3hwkREApz691bM4TBCC92rXj9GiHjo 6p4RcBhlcUffUz8OJY7BRccMq8FYfSJs3DnLW9NgzeNVvwQncuD6XPPuFLUYXOz3+geXELlw Z/aZHwN2iT/jPQK+lxLOe1sE/HJy2N70BgksuvNqScTrw+Hnahfg9UlwrrFBxOPj8EnbD4Rv LIdjj7xoLYhwBMU6giyOIIsjyNIK0C4Qozfb1WbSaGKoQjVTSFosFK3OSDIbrUmUvqwf+A8b ETIItkZUHkBgQCXDbfEWnUJIljMVZg+IwASqcLyTvbviYEGJvsJAMoY8usxEMR4AMUQVhl/O ZjlcT1bYKbokQEVhqEqJ3xnU6BREMWmlblBUKUUH2GgMU0F8gAuV01QxZSsymqz7tACTcOEy NjyF0+BMKWlmjMU8Pw5iI5X4E44gOMJQZtnzBh7VB5TsKqH4MKeSsW+85/axwQI2+EqHmQu2 kvtUZBVIpUbrsNah0y0Xc/p7qis/RYmvL5zMGnI3P78wPaDIurt5a+qmoW0yJDo3f6sjdTZ/ dN5lr6o8sSlJMJK0jZlrdxetVGqQkAOLQvem7szt37Hnl+N839bTZQ3ygrZLPqtGGnNU13Sk Eegsaxqcrk8m0qLSqbyrr+sXlieW7CqUMZCpiQjNkP8Bn8m734MDAAA=
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 17:56:52 -0000

> > 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