Re: [OAUTH-WG] problem statement

Michael Thomas <mike@mtcc.com> Tue, 06 September 2011 19:48 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 9BD6D21F8E14 for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 12:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 XTIvS+-GqpMM for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 12:47:59 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id D183A21F8E07 for <oauth@ietf.org>; Tue, 6 Sep 2011 12:47:59 -0700 (PDT)
Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86JnhM4030560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 12:49:44 -0700
Message-ID: <4E667953.9020906@mtcc.com>
Date: Tue, 06 Sep 2011 12:49:39 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Justin Richer <jricher@mitre.org>
References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.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>
In-Reply-To: <1315337809.3136.38.camel@ground>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3295; t=1315338585; x=1316202585; 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:=20Justin=20Richer=20<jricher@mitre.org> |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ms9WbjGyWGpKDZza/gAM0W1kVIC3HWS5kQmoWhGbr2Y=; b=QLlvOW/J/+TY0NkVKc1iOilhnxcErkS8JeF5E4KiwE5X7Vg2LVd2QJ2S1P Kz+lm2FxtKVtEh2MQReBT7mNzyg2v7LyDuQQ4z8VG1VJKXxwVV3poO/JDBzr XJ4Kiem0/wSi7j7iuBCfEOQpM56ug0njhDhfiRLPDa3xA9jojY/OI=;
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@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: Tue, 06 Sep 2011 19:48:00 -0000

Justin Richer wrote:
> Mike,
> 
> I think this is a red herring. as this vector has nothing to do with
> mobile apps. The attack that you've suggested is also possible with a
> compromised browser on a desktop using the web flow. In this case, the
> browser (UA) can steal the user's credentials and hand them to whoever
> they want to when the user gets redirected. It doesn't have to be the
> OAuth client that's phishing the credentials, after all. 

Absolutely. I only brought it up because that is what I was working on.

> OAuth *does* work with phone apps, and it's a misnomer to say that it's
> not a good idea in such environments. In all cases, you have to trust
> the user agent and all of the mechanisms that let the user log into the
> host site. But you have to do that in order to let the user log into the
> host site at all. Fixing that is a larger problem for the web as a whole
> and ultimately outside of OAuth.

Except in the desktop web world, I choose from a *tiny* set of browsers:
chrome, firefox, opera, and, uh, ie. To a lesser or greater extent, I don't
expect that the browsers themselves are malicious. Which is a pretty ok
assumption.

With embedded web views, that assumption goes out the window. There are
100's of thousands of apps, all of which can use webviews. I have no way
to know if a given app is evil or not, and *lots* of apps provide facebook
and twitter integration. Not because they're evil, but because that's what's
expected by users. So the use model of oauth in this case is *very* different
than the desktop use case.

But I'm being told that use cases aren't the problem of oauth. I'd say that
there has all along been a hidden assumption that the browser was
a trusted entity. Since it isn't always, it should be very explicit in the
protocol, threats, and security considerations of what could happen if it's
not.

Mike, frankly this is why apps do suck but i'm not king of the world

> 
>  -- Justin
> 
> On Tue, 2011-09-06 at 15:28 -0400, Michael Thomas wrote:
>> Melinda Shore wrote:
>>> On 09/06/2011 11:11 AM, Jill Burrows wrote:
>>>> I repeat, it is not an OAuth problem.
>>> If I'm reading Mike correctly (and if I'm not it won't be the
>>> first time I've misunderstood him), he's not really asking for
>>> OAUTH to solve this particular problem but to clarify the
>>> documents and beef up discussions of what is and is not in
>>> scope.  He read the document and couldn't figure out whether
>>> or not this particular problem is the business of the working
>>> group.
>> I'm fairly certain that if somebody were deploying oauth for their servers
>> that unless the document told me that oauth doesn't provide protection
>> against third party snooping if it's embedded in any app, most people wouldn't
>> have a clue that that was a dangerous assumption.
>>
>> What this says is that oauth only works in one use case, and that only the
>> user can tell the difference. Given the proliferation of phone apps and
>> embedded webviews, it seems that the original assumptions of oauth are
>> no longer up to date.
>>
>> Mike
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>