On Mon, Apr 27, 2009 at 10:50 AM, Eve Maler <eve.ma...@sun.com> wrote: > > Peter, thanks for putting the PIN idea in context for me. This is > perhaps a dumb question, but since testing equivalence of the *user* > (a bag of protoplasm) is sort of a last-mile problem anyway, and since > -- if I'm understanding the long Security Advisory discussion thread > correctly -- even PINs have social engineering risks, aren't we really > just looking for ever-better ways to do "weak" equivalence rather than > testing true equivalence?
Hi Eve- That's definitely something to think about, except that we can thus move the exploit completely into the social realm (where things like phishing live). I'd say from an authentication point of view, you are actually storing "state" on that bag or protoplasm :). OAuth leverages a bunch of existing standards/practices and giving user control of their identitiy is one of them. (I.e., lots of authentication schemes, even that used my my bank does the same). The specific social engineering risk mentioned in the Security Advisory thread centered on my original proposal that the user enter a PIN at A that they type again at B. The concern was that the attacker could convince the victim to type that in (since the attacker would have created it). My latest thinking entails the SP offering the PIN (I'm calling it a "valet key") after successful user authentication, which the user would be required to type in from the consumer side before getting the access token. (this is B-C interaction). That eliminates the possibility of the attacker coaxing the victim to enter it. --peter > > Eve > > On Apr 27, 2009, at 8:01 AM, Peter Keane wrote: > >> >> On Mon, Apr 27, 2009 at 9:42 AM, Eve Maler <eve.ma...@sun.com> wrote: >>> >>> Other than injecting identification into OAuth explicitly, *and* then >>> using a uniform identification system on both the consumer and >>> service >>> provider side (e.g. OpenID), strong equivalence -- test(B==C) -- is >>> impossible. And if identification in any one case is associated with >>> a sufficiently weak or phishable means of authentication, strong >>> equivalence may come into question again. >>> >>> There is great value in OAuth remaining agnostic on the >>> identification >>> question -- for example, it allows OAuth to be applied in >>> "brownfield" >>> situations where the consumer and service provider started out with >>> different systems, vs. creating a hard dependency on a disruptive >>> change to those systems. Many of my use cases depend on parties >>> applying OAuth dynamically without knowing yet if the same >>> identification system is in use. I hope there is interest in >>> developing a solution for the weaker form of equivalence -- min >>> Prob(B! >>> =C) -- perhaps in addition to the strong form. >>> >> >> Hi Eve- >> >> I completely agree on the need for OAuth to be agnostic re: >> identification. My various scenarios "verify" B==C entail a >> "temporary" agreement. Specifically, a PIN (or "valet key" as I >> called it in a previous proposal) that the user can remember just for >> completing the handshake. Essentially, identity in the "local" scope >> rather than identity in the "global" scope (e.g., OpenID). OAuth >> hooking into a global scope identity creates a dependency that makes >> OAuth much less attractive. >> >> I'm not convinced we need to settle for prob(B!=C), but if a local >> scope shared identity mechanism is not implemented (or seen to be too >> detrimental to UX), that may be the case. >> >> --peter >> >> >> >>> Eve >>> >>> On Apr 26, 2009, at 8:13 AM, Nat wrote: >>> >>>> >>>> >>>> >>>> =...@san Francisco via iPhone >>>> >>>> On 2009/04/26, at 5:38, John Kemp <j...@jkemp.net> wrote: >>>> >>>>> >>>>> On Apr 26, 2009, at 12:32 AM, Nat Sakimura wrote: >>>>> >>>>>> >>>>>> I agree that "2. test(B==C) , i.e., verify that the user at B is >>>>>> the >>>>>> same user at C" is >>>>>> not the same as "2b. min Prob(B!=C)". >>>>>> >>>>>> The former is clearly more desirable. >>>>> >>>>> +1 >>>>> >>>>>> >>>>>> If someone logs in to the both sites using something like OpenID, >>>>>> then it is trivially achieved without much user interaction >>>>>> impact, >>>>>> assuming OpenID AuthN is safe enough. For example, make >>>>>> verified_identifier a part of tokens. Then, user AuthN at the >>>>>> SP can be done automagically by browser redirect. >>>>> >>>>> Assuming that the "verified_identifier" is the same at both sites, >>>>> and >>>>> that the same user doesn't maintain two OpenIDs... >>>>> >>>> >>>> It is either the verified identifiers matches (among other things) >>>> thus the access is granted or does not match and the authorization >>>> fails. >>>> >>>>> - johnk >>>>> >>>>>> >>>>>> >>>>>> =nat >>>>>> >>>>>> On Sat, Apr 25, 2009 at 8:26 PM, pkeane <pjke...@gmail.com> wrote: >>>>>>> >>>>>>> Sorry: >>>>>>> >>>>>>> Almost all of the proposed solution attempt to minimize the >>>>>>> possibility that user at B is NOT the same as user at C. >>>>>>> >>>>>>> is what it should say... >>>>>>> >>>>>>> On Apr 25, 10:19 pm, pkeane <pjke...@gmail.com> wrote: >>>>>>>> Here is an attempt to help spell out the OAuth security in >>>>>>>> simple >>>>>>>> terms and thus provide a framework to judge various proposed >>>>>>>> fixes. I >>>>>>>> float this as either a useful shared assumption OR a strawman to >>>>>>>> knock >>>>>>>> down so the the issue can be addressed in some other way. >>>>>>>> >>>>>>>> Eran, in his explanation, outlined there steps that are not >>>>>>>> connected >>>>>>>> but *need* to be connected for the protocol to be secure. >>>>>>>> >>>>>>>> A. user initiates a consumer-to-provider handshake >>>>>>>> B. user logs in to provider (or verifies they are logged in) and >>>>>>>> authorizes this handshake from the provider side >>>>>>>> C. now back at the consumer, users does useful things based on >>>>>>>> the >>>>>>>> securely transacted handshake >>>>>>>> >>>>>>>> The OAuth spec MUST accomplish either of the following to close >>>>>>>> the >>>>>>>> security hole: >>>>>>>> >>>>>>>> 1. verify that the user at A is the same user at B >>>>>>>> 2. verify that the user at B is the same user at C >>>>>>>> >>>>>>>> Almost all of the proposed solution attempt to minimize the >>>>>>>> possibility that user at B is the same as user at C. Is that >>>>>>>> enough? >>>>>>>> It's true that actual "verification" will impact the user >>>>>>>> experience >>>>>>>> negatively (as actual authentication/verification inevitably >>>>>>>> does). >>>>>>>> >>>>>>>> It's probably worth thinking about what "verification" means and >>>>>>>> how >>>>>>>> that might be achieved. Otherwise, I think the community >>>>>>>> needs to >>>>>>>> decide if "minimizing possibility" is enough. >>>>>>>> >>>>>>>> --peter keane >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> http://www.sakimura.org/en/ >>>>>> >>>>>>> >>>>> >>>>> >>>>>> >>>> >>>>> >>> >>> >>> Eve Maler eve.maler @ >>> sun.com >>> Emerging Technologies Director cell +1 425 345 >>> 6756 >>> Sun Microsystems Identity Software www.xmlgrrl.com/ >>> blog >>> >>> >>>> >>> >> >> > > > > Eve Maler eve.maler @ sun.com > Emerging Technologies Director cell +1 425 345 6756 > Sun Microsystems Identity Software www.xmlgrrl.com/blog > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
