Improving OpenIDs use of cryptography 1 - using a MAC

[Brad Fitzpatrick]

How is that secret exchanged without encryption?

LJ::secret works because LJ is the only party involved... twice.  It knows
its own secrets.  (right?)

I'd originally done without DSA and the identity server handed out a
"proof token" which the identity consumer could then check, by doing
another HTTP request to the identity server, but I disliked the extra HTTP
request which can be avoided by a consumer caching the public key.

School me.

- Brad


On Thu, 2 Jun 2005, Paul Crowley wrote:

> 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/
> _______________________________________________
> yadis mailing list
> yadis at lists.danga.com
> http://lists.danga.com/mailman/listinfo/yadis
>
>