Re: [OAUTH-WG] problem statement

Justin Richer <jricher@mitre.org> Tue, 06 September 2011 19:36 UTC

Return-Path: <jricher@mitre.org>
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 9B64E21F8C98 for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 12:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.578
X-Spam-Level:
X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 bpZqQs+GzuYv for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 12:36:12 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D3FA121F84DB for <oauth@ietf.org>; Tue, 6 Sep 2011 12:36:11 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7814721B16B1; Tue, 6 Sep 2011 15:37:52 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7168F21B1565; Tue, 6 Sep 2011 15:37:52 -0400 (EDT)
Received: from [129.83.50.1] (129.83.31.55) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.270.1; Tue, 6 Sep 2011 15:37:51 -0400
From: Justin Richer <jricher@mitre.org>
To: Michael Thomas <mike@mtcc.com>
In-Reply-To: <4E667469.2040007@mtcc.com>
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>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 06 Sep 2011 15:36:49 -0400
Message-ID: <1315337809.3136.38.camel@ground>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.2
Content-Transfer-Encoding: 7bit
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:36:12 -0000

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. 

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.

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