[OpenID] D-H vs SSL

[Peter Williams]

Now im liking it.

By default, openid can have null protection on its master secret (proposed by OP, it looks like, RSA like), when there is a bearer known as SSL.

Session type X agreed between RP#1 and OP#1 can perhaps be leveraging the internals of an SSL ciphersuite, to perhaps have a KDF applied to the master secret for the new record layer protocol. Others have done this (in connectionless SSL over UDP, for discovery of routers/firewall management ports).

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Andrew Arnott
Sent: Thursday, March 19, 2009 11:39 AM
To: Allen Tom
Cc: Martin Atkins; OpenID List
Subject: Re: [OpenID] D-H vs SSL

Well, the spec allows for session types to be implemented that are not defined in the spec.  If DH is ever removed from the OpenID spec, I hope the spec can reference another DH spec that keeps it alive as a spec that people can optionally implement.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

2009/3/19 Allen Tom <atom at yahoo-inc.com<mailto:atom at yahoo-inc.com>>
If we consider OAuth's secret exchange mechanism for HMAC-SHA1 sigs,

 *   OAuth Service Providers usually issue a Consumer Secret to the developer, without any input from the developer. (hopefully via HTTPS)
 *   OAuth Request Token and Access Token secrets are issued by the Service Provider to the Consumer (also, hopefully via HTTPS), without any input from the Consumer
Returning cleartext secrets via HTTPS would be consistent with OAuth.

Although DH on top of SSL is safer than cleartext and SSL, is the overhead of having the spec discuss DH worth it? If the OP is unable to generate a strong secret on its own, or if the transport layer between the RP and OP cannot be secured using HTTPS, then arguably the entire system has issues.

I only mention DH, not because I have an issue with DH, but because one of OpenID's most desirable traits is its relative simplicity. The spec is pretty straightforward, and it's not all that hard to implement. Sites that want a richer (and more complicated) SSO protocol standard have alternatives that are already in production and are widely used.

Allen


Ben Laurie wrote:


Ah. I see.



So, I am going to be lazy, because I have not checked the spec, but

its considered good practice when establishing a shared secret for

both sides to contribute to that secret. Is that true for the

cleartext secret?





_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090319/2fec132f/attachment-0002.htm>