Re: [OAUTH-WG] problem statement

Michael Thomas <mike@mtcc.com> Wed, 07 September 2011 18:00 UTC

Return-Path: <mike@mtcc.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 AC5CC21F8C9C for <oauth@ietfa.amsl.com>; Wed, 7 Sep 2011 11:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.187
X-Spam-Level:
X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_53=0.6]
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 ExB2KsSK9nxP for <oauth@ietfa.amsl.com>; Wed, 7 Sep 2011 11:00:54 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 13C3C21F8C95 for <oauth@ietf.org>; Wed, 7 Sep 2011 11:00:54 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87I2hpg003800 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 11:02:43 -0700
Message-ID: <4E67B1C3.60306@mtcc.com>
Date: Wed, 07 Sep 2011 11:02:43 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: John Kemp <john@jkemp.net>
References: <4E665B25.6090709@mtcc.com> <CD0B1909-8298-4CC3-B273-7B26E71EAB31@hueniverse.com> <4E666512.7010701@mtcc.com> <F4839FCD-CA73-4450-AD12-E07D46BB7746@hueniverse.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.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> <D3A6B9B9-AC0A-4D0E-ACA8-AEB1BF8D5ECF@jkemp.net>
In-Reply-To: <D3A6B9B9-AC0A-4D0E-ACA8-AEB1BF8D5ECF@jkemp.net>
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=2051; t=1315418564; x=1316282564; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20John=20Kemp=20<john@jkemp.net> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=LFDmKpjLLETkiBUHWfm/yfj43OOu0KAvYeR8++bYdIM=; b=V3Ti6VsDX8GefIl1hsiHB5fe5ApQBSrkKOszIqOPTRLZVdin9lDU8ZpZGT Mr+66pIZAr/u3YTu1jfXwE33l1ghvJoFMYYhwChXVt75I+YLuy3b17+v2xx9 GXfbt9PWLbBZM/ptN/QMzhzG5F5DxcFLGYRXd3bTO8ZIrvbNPQAi0=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com
Cc: OAuth WG <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: Wed, 07 Sep 2011 18:00:54 -0000

On 09/07/2011 10:49 AM, John Kemp wrote:
> Mike,
>
> On Sep 7, 2011, at 1:26 PM, Michael Thomas wrote:
>
>    
>> On 09/07/2011 10:17 AM, Igor Faynberg wrote:
>>      
>>> +300 (if I can do that) to indicate my strong agreement.  But if somehow it is decided to add a few sentences on saying that OAuth cannot deal with key-logging, I will insist on adding two sentences each on OAuth being unable to deal with 1) earthquakes, 2) certain contageous diseases, etc., [...]
>>>        
>> Please, enough of the hyperbole. It is not clear or obvious whether this is
>> a protocol issue or not. It brings into question whether the protocol is worth
>> deploying at all, and that is surely an issue. As far as I can tell, there is very
>> little upside to deploying OAuth in the general case over, say, Basic+TLS. In
>> fact, you guys have convinced me that OAuth gives inferior protection at
>> considerable expense for all concerned.
>>      
> I'm sorry that you haven't received an easy introduction to the OAuth WG. But that's no reason to spout nonsense. OAuth seeks to replace something that was once rather common - the need for a user to type (and/or store) his password for site A at site B, to let site B get their content from site A. Now, site B gets a token in the common case, rather than the user's password for site A. This doesn't remove the need for a user to exercise common sense in deciding where to type her password. But it does, in the common case, mitigate the password being shared among websites, or across networks multiple times.
>
> You are right that OAuth doesn't mitigate key logging or other similar attacks on the client OS/platform itself. But that doesn't make it inferior to other methods of web authorization.
>
>    

It's not nonsense:

1) App prompts me for my credentials to Facebook -- I wonder whether
     I trust the app.
2) App puts me in a Facebook login window -- I figure that it's secure and
     don't wonder whether I trust the app.

#2 sure looks worse than #1.

Mike