[security] Gathering requirements for in-browser OpenID support

[john kemp]

Hello,

I think Ben's original point was that with a zero-knowledge proof
protocol (see http://en.wikipedia.org/wiki/Zero-knowledge_proof) used
for /authentication/ of the /user/ (rather than, say, standard
username/password) the user would not actually reveal her secret
information (password) to the rogue RP (IdP).

Ben's specific example was EKE (
http://en.wikipedia.org/wiki/Encrypted_key_exchange ).

As I think Ben already noted, a browser would need to support this
protocol, most likely either as a plug-in, or as part of the basic
browser software itself. But if that condition was met, even the user
may not know the piece of information used to actually authenticate
herself at some IdP, in which case, the user couldn't reveal it even if
she wanted to.

I believe that authentication of the user to the IdP is out of scope for
"OpenID Authentication".

It might be nice, however, to note in security considerations that an
identity provider may use "stronger" forms of authentication than
username/password, including EKE.

- John

Chris Drake wrote:
> Hi Joaquin,
> 
> Browsers cannot do asymmetric cryptography out of the context of the
> site you're visiting, so I think "us doubters" might have a valid
> point - unless you want to explain how a "stupid user" sitting in
> front of IE7 can use EKE?
> 
> If EKE *can* prevent phishers from stealing passwords, how do you
> explain that no site anyone has ever heard of is doing this today?
> 
> I maintain my position:  MitM is not a protocol problem - it's a
> "stupid user" problem.
> 
> Kind Regards,
> Chris Drake
> 
> 
> Wednesday, November 1, 2006, 2:14:33 AM, you wrote:
> 
> JM> It may help those doubters if we now briefly explain how EKEaccomplishes a) and b).
> 
>>> For the benefit of me andothers reading this thread, can you briefly
>>> explain how you would deploy EKE in a browser to defeat MitM?
> 
> JM> By ensuring that the man in the middle:
> 
> JM> a) Ends up not in the possession of any authenticationcredentials
> 
> JM> b) Can neither understand nor usefully modify the conversation they areproxying.
> 
> 
> JM> I'm sure everyone understands how an authenticated public
> JM> keyaccomplishes a) and b), so there is no need to read on.
> 
> JM> Cordially, Joaquin
> 
> 
> 
> 
> 
> 
> JM> a) The authentication credentials are encrypted with public
> JM> keys, so thatonly the intended recipient can decrypt* them.
> 
> JM> b) The conversation is encrypted with public keys, or with a
> JM> session keyexchanged using public keys, so that only the intended
> JM> recipient canunderstand* and only the sender can modify*.
> 
> 
> JM> * yeah, yeah: easily, soon enough to matter.
> 
> 
> 
> 
> 
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security