Tacking this response to the end of the thread for lack of a better place to do
it: The name "username" seems not quite apt in the case of an autonomous client
that isn't representing an end-user. Would "identifier" be better? (Actually,
it sort of reminds me of SAML's "SessionIndex"...) Or would the parameter be
reserved for user-delegation flows?
Speaking of autonomous clients, Section 2.2 -- among possibly other places --
states that an autonomous client is also the resource owner, but that's not
always the case, is it? The client might be seeking access on behalf of itself.
(FWIW, I made roughly this same comment on David's first draft on March 21, and
he agreed with my suggested fix at the time.)
Eve
On 21 Apr 2010, at 2:30 PM, Torsten Lodderstedt wrote:
> Am 20.04.2010 20:59, schrieb Eran Hammer-Lahav:
>> Because the rest of the spec did receive extensive review from both early
>> adopters and from the previous drafts it borrowed from. Nothing so far is a
>> new concept. The concept of an identity is new in OAuth, and while offers
>> important benefits, should not be added to the spec when there are actual
>> security concerns around it.
>
> My impression is that the specification has undergone significant changes
> since its first version and cannot be compared to its predecessor in terms of
> security.
>
> Let me give you some examples.
>
> I wonder if anyone security reviewed the introduction of refresh tokens to
> the User Agent Flow? From my point of view, refresh tokens are dangerous in
> this flow.
>
> First of all, where should a JavaScript client store this token securely? If
> someone is able to steal the token, it can use it to obtain access tokens.
>
> Steps:
> 1) legitimate client is granted access by the end user
> 2) client stores refresh token in local storage (?)
> 3) malicious software reads refresh token from local storage
> 4) malicious software obtains access token from the authorization server (no
> client secret required)
> 5) malicious software uses token or sends it to a central storage for further
> abuse
>
> Second, the immediate mode has been introduced to the User Agent flow
> recently. I don't know exactly but my feeling is that a malicious software
> can steal tokens.
>
> Steps:
> 1) malicious software initiated authorization flow using immediate=true and a
> stolen client_id
> 2) Assuming this client has been granted access by the end user of the
> particular computer, the authorization server directly respondes with tokens
> w/o user interaction. The user does not realize what is happening.
> 3) malicious software uses token or sends it to a central storage for further
> abuse
>
> The only countermesure I see is the redirect URL verification, which seams to
> be optional: "If the client has previously registered a redirection URI with
> the
> authorization server".
>
>>
>> I raised a specific issue that was not addressed. Brian seems to have other
>> concerns.
>
> Other posts on the thread indicated a need for such an concept. We use such
> parameters, too.
>
> I think, from a security standpoint, the problem is much more the immediate
> parameter then the username parameter. If the username is modified by an
> attacker, the user should see the username in authentication or authorization
> dialogs. So he/her can react. That's not the case in immediate mode, so there
> are only technical ways to prevent username modifications, HTTPS or
> signatures.
>
>>
>> I don’t like the policy of add-first-discuss-later.
>
> I don't like it either. But sometimes it is more efficient to make progress
> and discuss such aspects in-depth when reaching milestones.
>
> regards,
> Torsten.
>
>>
>> EHL
>>
>> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
>> Sent: Tuesday, April 20, 2010 11:55 AM
>> To: Eran Hammer-Lahav
>> Cc: jsm...@stanfordalumni.org; OAuth WG
>> Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal
>>
>> In my experiences, such a review takes much longer than a few minutes.
>>
>> I think the whole specification should be subject to a comprehensive and
>> in-depth security analysis (threat modeling, counter measures and so on). So
>> why not adding this parameter and examine its implications in this context?
>>
>> regards,
>> Torsten.
>>
>> Am 20.04.2010 19:23, schrieb Eran Hammer-Lahav:
>> I’m not aware of anyone arguing against this feature. The only issue is a
>> full security review before we add it to the spec. If one of the security
>> experts here can spend a few minutes to review this, we can move forward and
>> add it to the draft.
>>
>> EHL
>>
>> From: Joseph Smarr [mailto:jsm...@gmail.com]
>> Sent: Tuesday, April 20, 2010 9:36 AM
>> To: Eran Hammer-Lahav
>> Cc: Evan Gilbert; OAuth WG
>> Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal
>>
>> Just to add some more context from experience, this "two users getting mixed
>> together" problem happens a lot in practice, esp. when you have a mix of
>> server-side and client-side auth. For instance, we saw this in our Facebook
>> Connect integration in Plaxo--normally the user connects and Plaxo stores
>> their session key in our databases, so when the user returns and logs in as
>> plaxo-user-123, we look it up and know that he's also facebook-user-456. But
>> some of Facebook Connect's UI widgets just look at the browser cookies on
>> facebook.com, where facebook-user-789 may be currently logged in (happens
>> all the time with shared computers at home). Thus we often had pages that
>> pulled some Facebook info server-side (as facebook-user-456) and some
>> client-side (as facebook-user-789) and it was very confusing and potentially
>> harmful (e.g. easy to accidentally post a story to the wrong account). The
>> solution would be for Plaxo to be able to pass facebook-user-456 down to the
>> JavaScript library, so it wouldn't just "silently auth" as a different
>> user--presumably, it would just treat it as if no one was logged into
>> facebook, if the passed-in user is not logged in. I think this is what Evan
>> is proposing we enable for OAuth, especially if we want it to work
>> client-side with immediate-mode (which I think we do).
>>
>> Another related example of this problem we saw was with our photo-uploader
>> plug-in inside Picasa Desktop for sharing photos on Plaxo. During the upload
>> flow, it embeds a web browser, which lets you log in as plaxo-user-123, but
>> when it's done uploading, it opens a default web browser, where you might be
>> logged in as plaxo-user-456, leading again to a confusing mix-up of
>> identities. We solved this by appending the session-info of the user from
>> the embedded web browser on the URL of the main browser that gets opened, so
>> it can clobber the session as needed and maintain continuity of session.
>>
>> Hope these experiences provide some useful and concrete context for
>> evaluating whether/how to support a username parameter in OAuth.
>>
>> Thanks, js
>>
>> On Tue, Apr 20, 2010 at 8:08 AM, Eran Hammer-Lahav <e...@hueniverse.com>
>> wrote:
>> 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:uid...@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 <e...@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:uid...@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 <e...@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" <uid...@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:
>> Bob is logged into a web site as b...@idp.com.
>> Mary (his wife) is logged into IDP on the same computer as m...@idp.com
>> 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)
>> -ob now has an access token for Mary and (posts activities, schedules
>> events, gets contacts) as Mary
>> Hilarity ensues
>>
>> Secondary goal: Provide a hint for non-immediate mode
>>
>> On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav <e...@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
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
