Re: [OAUTH-WG] problem statement

Michael Thomas <mike@mtcc.com> Wed, 07 September 2011 14:52 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 4076421F8C48 for <oauth@ietfa.amsl.com>; Wed, 7 Sep 2011 07:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, SARE_ADULT2=1.42]
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 WKxYU1X+I6lm for <oauth@ietfa.amsl.com>; Wed, 7 Sep 2011 07:52:35 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id CC73021F8C40 for <oauth@ietf.org>; Wed, 7 Sep 2011 07:52:35 -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 p87EsNk2029683 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 07:54:23 -0700
Message-ID: <4E67859F.9050908@mtcc.com>
Date: Wed, 07 Sep 2011 07:54:23 -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: "Manger, James H" <James.H.Manger@team.telstra.com>
References: <4E665B25.6090709@mtcc.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> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> <4E66C521.5070804@mtcc.com> <1315358847.25169.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E66CF9A.8000905@mtcc.com> <255B9BB34FB7D647A506DC292726F6E1128DF46CA4@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128DF46CA4@WSMSG3153V.srv.dir.telstra.com>
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=2385; t=1315407265; x=1316271265; 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:=20=22Manger,=20James=20H=22=20<James.H.Manger@team.tel stra.com> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=FF5zyF/5GhwK7mKUPFvI4BhfOxK01EIUXgMt3yEDw8E=; b=Iwjm9/IyjB2MscpucJqckwnwyT9hX2Aw3wJTqEd164Qd2EtsigUNtaGwRZ ZKztdXXSZPvLI6cGOtmV8j1T319YRXw5KeruOE+aBoatUXhC7KclV8oqJlmR XaJykD8LpXWYj0FDd/riZ7B5YPjdyLFpmv2jsYJjm7yakD47smPOY=;
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: Wed, 07 Sep 2011 14:52:40 -0000

On 09/06/2011 08:52 PM, Manger, James H wrote:
> A strange aspects of this thread is that the current draft already talks about exactly this issue:
>
> draft-ietf-oauth-v2-21 section 9 "Native Applications"
>
>    "...Native applications can invoke an external user-agent or
>    embed a user-agent within the application
>    ...
>    Embedded user-agents pose a security challenge because resource
>    owners are authenticating in an unidentified window without access
>    to the visual protections found in most external user-agents.
>    Embedded user-agents educate end-user to trust unidentified
>    requests for authentication (making phishing attacks easier to
>    execute)."
>
> The webView that Michael Thomas talks about is an "embedded user-agent".
>    

First, thank you for finding this -- this is far more useful than
the snarls I've received.

Second, I'd say that this is a good first step, but the text there
should be explicit and not pussy-foot around the fact that it
means embedded UA's in phone apps and other examples. It
should also make clear that the "challenge" (ack, ptui) involves
untrusted apps stealing the user's credentials by simply snooping
on the UA itself. If there is reasonable mitigation, then by all means
add text about it. This is important because I do not think that
many people grok the seriousness of the issue, and most especially
people who would deploy oauth authentication services.

Third, I think that the introduction needs to have an applicability
statement of *when/where/what* oauth can be used. That is,
do not beat around the bush about the need for the UA to be
trustable because that is a basic the assumption that oauth makes.
As inconvenient as that may be, it would be far worse for people
in the industry to not fully understand the threat.

Fourth, it would be *really* nice to hear from folks at Facebook
and Twitter who have deployed oauth and oauth-like flows with
their experience here, and most especially if they understood the
threat ahead of their deployment, and what they do to mitigate
it if anything.

Mike
> --
> James Manger
>
>
> ----------
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Michael Thomas
>
> ...
> At this point, it would be just nice for the industry to know that the issue
> even *exists*.
>