Re: [OAUTH-WG] problem statement

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Tue, 06 September 2011 18:08 UTC

Return-Path: <igor.faynberg@alcatel-lucent.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 8819B21F8C06 for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 11:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.605
X-Spam-Level:
X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 mxUc4l1W5e9E for <oauth@ietfa.amsl.com>; Tue, 6 Sep 2011 11:08:20 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D926021F8BCB for <oauth@ietf.org>; Tue, 6 Sep 2011 11:08:19 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p86IA5kG003453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Tue, 6 Sep 2011 13:10:05 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p86IA4sm010187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <oauth@ietf.org>; Tue, 6 Sep 2011 13:10:05 -0500
Received: from [135.244.40.187] (faynberg.lra.lucent.com [135.244.40.187]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p86IA3CV010681; Tue, 6 Sep 2011 13:10:04 -0500 (CDT)
Message-ID: <4E6661FA.7050804@alcatel-lucent.com>
Date: Tue, 06 Sep 2011 14:10:02 -0400
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: oauth@ietf.org
References: <4E665B25.6090709@mtcc.com>
In-Reply-To: <4E665B25.6090709@mtcc.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Subject: Re: [OAUTH-WG] problem statement
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
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 18:08:20 -0000

Mike,

You've got the problem statement right: allowing the user to authorize  
resource access to another party without divulging user's credentials is 
the objective of OAuth. You are also right in that the attack you have 
described defies the whole purpose of OAuth.  I do not think though that 
it is related to OAuth per se.

To this end, the security work led by Torsten has thoroughly analyzed 
the protocol and specified protection against multiple protocol 
attacks.  From what you described, it appears to me that the attack you 
mention is not related to the protocol but rather to the user's 
environment.  There is no possible protection from key loggers that a 
protocol can implement. I could be mistaken; in any case, it looks like 
the problem rests with the implementation of WebView.

If I am wrong, I would appreciate a detailed description of what happened.

Igor

On 9/6/2011 1:40 PM, Michael Thomas wrote:
> Hi all,
>
> Barry suggested that I might subscribe and explain what I sent him.
>
> My basic problem is that in neither the protocol nor the threats drafts,
> I can't seem to find what problem is actually trying to be solved with
> oauth, and what assumptions you're making about various elements.
>
> Here's what I did. I've written an app, and I wanted re-integrate the
> ability to send tweets after they deprecated Basic. So the app has a
> webView (android, iphone...) which it obviously completely controls.
> With oauth, the webview UA will ultimately redirect off to Twitter's
> site to collect the user's credentials and grant my app's backend an
> access token (sorry if I get terminology screwed up, i'm just coming
> up to speed).
>
> What occurs to me is that webview affords exactly zero protection from
> my client (ie, the app) from getting the user's twitter credentials. All
> I have to do is set up a keypress handler on that webview and in a few
> minutes of hacking I have a key logger. etc.
>
> So what I can't tell is whether this is a "problem" or not, because I
> don't know what problem you're trying to solve. If the object of oauth
> isn't to keep user/server credentials out of the hands of a third party,
> then what is it trying to solve? Is there an expectation that the
> UA is trusted by the user/server? What happens when that's not the case?
>
> Regardless of whether I'm misunderstanding, it would sure be nice to have
> both the problem and your assumptions laid out, hopefully with some 
> prominence
> so you don't get these sort of dumb questions.
>
> Mike
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth