I think C can send the info that it is A who is requesting the data to S:V.
In the four legged case, the privacy leakage is not a problem, because the data acquirer must identify himself to the data provider anyways to obtain permission. In the tree legged case, it might pose a sort of correlation problem (privacy), but since S cannot learn too much activity of V at C, it probably would not be that bad. And, yes. This is not a technical approach, but legal and social approach, but is valid IMHO. =nat On Wed, Apr 29, 2009 at 11:01 AM, George Fletcher <[email protected]> wrote: > > Nat Sakimura wrote: >> On Tue, Apr 28, 2009 at 11:32 PM, Dossy Shiobara <[email protected]> wrote: >> >>> On 4/28/09 8:41 AM, Hubert Le Van Gong wrote: >>> >>>> I also saw 2 additional ideas that might help >>>> (and are not necessarily exclusive with the 2 proposals): >>>> >>>> (3) Make Request tokens one-time only >>>> (4) Request that the user logs in at the Consumer before the request >>>> token request >>>> >>> Requiring the user authenticate to the Consumer doesn't prevent the >>> attack, as the attacker is a legitimate user of Consumer in the attack >>> scenario. >>> >>> What I keep proposing is that the user must authenticate at the >>> _Provider_ before the request token request. This would completely >>> eliminate the attack in the scenario. >>> >> >> Right. I think I have seen something like this on this list recently, >> but the problem is in this wholesale grant model. >> >> Let S:=Service Provider, C:=Consumer, V:=Victim, A:=Attacker, >> S:V:= User V at S, S:V:Data := Data of user V at S, C:* := any user in C. >> >> Then, what OAuth does right now is: >> >> [1] Get Permission on (Grant access on S:V:data to C:*) >> >> by misguiding the user as (Grant access on S:V:data to C) >> >> This is not pretty. It is illegal in many countries (not in U.S. though.) >> >> And, what you are proposing is to deny the wild card in [1] above and >> make it explicit, so that it will be like: >> >> [2] Get Permission on (Grant access on S:V:data to C:A) >> >> which, I think, is a good idea. >> >> Under this scenario, in the last vulnerability that we encountered, >> the victim will be asked to grant permission to C:A, which, he >> probably would not. >> >> > But isn't the issue that there is no way for C to communicate A to S in > a way that V can determine their being "attacked"? One of the principles > of OAuth has been that it works without identity federation (i.e. that S > doesn't need to know about V's identity at C nor C know about V's > identity at S). > > It's possible for C to send the requesting user's "identifier" to S (in > the request_token request) for presentation to the user during > "authorization" at S, but then there is a leakage of identifiers that > could lead to privacy/correlation issues. This has been suggested by a > number of others as a good UX enhancement but not "solving" the > technical problem. Note that this also presumes that the user must first > be authenticated to C before starting the OAuth flow. > > Thanks, > George >> =nat >> >> >> >> >>> And yes, making request tokens one-time only is a MUST, IMHO. >>> >>> -- >>> Dossy Shiobara | [email protected] | http://dossy.org/ >>> Panoptic Computer Network | http://panoptic.com/ >>> "He realized the fastest way to change is to laugh at your own >>> folly -- then you can let go and quickly move on." (p. 70) >>> >>> >> >> >> >> > > > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
