Improving OpenIDs use of cryptography 1 - using a MAC

[Paul Crowley]

The main reason Brad asked me to look at OpenID was because as a 
cryptographer, I was always ragging on him to get the cryptography in 
these things right before setting them in stone.  OpenIDs use of 
cryptography doesn't lead to an immediate break, but it can definitely 
be brought much closer to best practice.  As I mentioned before, I'll 
break this into several emails.

The first change I'd propose is good news for implementors and for 
server CPUs.  OpenID doesn't need public-key cryptography at all and 
would be better off without it.  Instead of DSA signing the tokens 
passed between identity server and identity consumer via the user agent, 
we can authenticate them using a secret-key MAC such as HMAC-SHA1.  This 
will be vastly faster and much easier to implement.  Instead of 
connecting to the ID server to fetch the DSA public key, each ID 
consumer will agree their own MAC secret with the ID server.  Each MAC 
secret will have a unique name stored by the identity consumer and 
passed on as part of the authentication request.  The server doesn't 
really have to store a secret per consumer - it can use a strategy like 
LJ::get_secret to map MAC IDs onto MAC secrets using a secret function. 
  Generating or validating HMAC-SHA1 is over a thousand times faster 
than generating or validating DSA - and it sounds like DSA would be an 
implementation nightmare on lots of platforms too, while nearly 
everything provides a SHA-1 implementation.

At the moment OpenID looks like a PKI solution with a severely broken 
PKI.  Removing the only actual PK component would fix that.  If you 
later decide you want the assurance of SSL's PKI, just buy a certificate 
for your ID server and provide an https: URL for it - the PK of the SSL 
and the OpenID cryptography will complement each other perfectly.

Whether or not this suggestion is implemented, the way that ID consumers 
get authentication keys from ID servers needs to be part of the 
specification.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/