Re: [OAUTH-WG] Issue: 'username' parameter proposal

Eran Hammer-Lahav <eran@hueniverse.com> Tue, 20 April 2010 15:08 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A66828C18B for <oauth@core3.amsl.com>; Tue, 20 Apr 2010 08:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level:
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqy2OZkhpso8 for <oauth@core3.amsl.com>; Tue, 20 Apr 2010 08:08:52 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DD66F3A6AFD for <oauth@ietf.org>; Tue, 20 Apr 2010 08:08:31 -0700 (PDT)
Received: (qmail 31356 invoked from network); 20 Apr 2010 15:08:23 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Apr 2010 15:08:22 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 20 Apr 2010 08:08:22 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Evan Gilbert <uidude@google.com>
Date: Tue, 20 Apr 2010 08:08:29 -0700
Thread-Topic: [OAUTH-WG] Issue: 'username' parameter proposal
Thread-Index: AcrgHtAsMYbs6eHOQGKTjgk0AbXNoQAfC3uQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438E5C7F45A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <r2pc8689b661004190833tf46085bayb92b840acf080bb4@mail.gmail.com> <C7F1C6AC.327EE%eran@hueniverse.com> <u2jc8689b661004191006hc3c7fb3eid09feafd57d2fd8a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F163@P3PW5EX1MB01.EX1.SECURESERVER.NET> <o2wc8689b661004191716o69966d5di900c07737d3be568@mail.gmail.com>
In-Reply-To: <o2wc8689b661004191716o69966d5di900c07737d3be568@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723438E5C7F45AP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 20 Apr 2010 15:08:54 -0000

This attack is why the flow requires the client to present the callback it used again when getting the token.

EHL


From: Evan Gilbert [mailto:uidude@google.com]
Sent: Monday, April 19, 2010 5:17 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal


On Mon, Apr 19, 2010 at 10:58 AM, Eran Hammer-Lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>> wrote:
Thanks. That makes sense.

My concern is that the client will ask for a specific username but an attacker will change that request before it hits the server. The server then asks the (wrong) user to authenticate and returns a token. The client has no way of knowing it got an access token for the wrong user. Does requiring that the server returns the token with the username solves this? Is this a real issue?

This particular attack wasn't of concern to me, for a few of reasons:
- The request is HTTPS, hard to modify the request before it hits the server
- There are probably other, more dangerous attacks if you can modify request parameters (for example, you can modify the client_id and get the user to authorize the wrong app)

I'm willing to be convinced otherwise

I have no objections to this proposal but wanted to see some discussion and support from others before adding it to the spec.

EHL

From: Evan Gilbert [mailto:uidude@google.com<mailto:uidude@google.com>]
Sent: Monday, April 19, 2010 10:06 AM
To: Eran Hammer-Lahav
Cc: OAuth WG

Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal

User 1 is logged into Client site
User 2 is logged into IDP site

This can happen quite frequently, as client sites often have long-lived cookies and may only be visited by one user on a shared computer.

Right now client site has no way to ask for a token for User 1, and end result will be that User 1 starts seeing User 2's data.

On Mon, Apr 19, 2010 at 8:37 AM, Eran Hammer-Lahav <eran@hueniverse.com<mailto:eran@hueniverse.com>> wrote:
How can they both be logged in? I have never seen a case where two users can be both logged into to the same service at the same time...

EHL



On 4/19/10 8:33 AM, "Evan Gilbert" <uidude@google.com<http://uidude@google.com>> wrote:
More details on this enhancement.

Goal: Make sure you get an access token for the right user in immediate mode.

Use case where we have problems if we don't have username parameter:

 1.  Bob is logged into a web site as bob@IDP.com<http://bob@IDP.com>.
 2.  Mary (his wife) is logged into IDP on the same computer as mary@IDP.com<http://mary@IDP.com>
 3.  A request is made to get an access token via the User-Agent flow in immediate mode (or with any redirect without prompting the user)
 4.  -ob now has an access token for Mary and (posts activities, schedules events, gets contacts) as Mary
 5.  Hilarity ensues

Secondary goal: Provide a hint for non-immediate mode

On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav <eran@hueniverse.com<http://eran@hueniverse.com>> wrote:
Evan Gilbert proposed a 'username' request parameter to allow the client to
limit the end user to authenticate using the provided authorization server
identifier. The proposal has not been discussed or supported by others, and
has not received a security review.

Proposal: Obtain further discussion and support from others, as well as a
security review of the proposal. Otherwise, do nothing.

EHL

_______________________________________________
OAuth mailing list
OAuth@ietf.org<http://OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth