Improving OpenIDs use of cryptography 1 - using a MAC

[Brad Fitzpatrick]

On Fri, 3 Jun 2005, Paul Crowley wrote:

> Ben Hyde wrote:
> > One thing I sort of like about the design as it stands is the lack of
> > any state/account/relationship between the client and id servers.
>
> > I'd prefer not to introduce real accounts between the client-server <->
> > id-server.
>
> This proposal preserves those attributes.  While you can cache the
> HMAC-SHA1 secret just as you can cache the DSA key, you don't have to.
> You only have to keep it for the lifespan of this one authentication
> attempt, and you have to have some state for that long anyway for
> security.  You can even use cunning tricks to encrypt it into the return
> URL if you don't want to store it.

Ben was talking about the identity server's relationship with the
consumer, whereas you're addressing the consumer's relationship with the
identity server.

I think Ben's concerned that the identity server will have to remember
each secret that it gives out to each consumer in an HMAC scheme, since
we've been talking about LJ::get_secret() without anybody else knowing how
it works.

Ben:  LJ::get_secret() in a nutshell generates a self-signed secrets from
a slowly self-generating pool of actual server-side secrets.  LiveJournal
will make a new large, random string every day, and use it to give out
secrets later.  So rather than keeping track of what secrets have been
made, we just check that it's valid when we get it later.

This is similar in requirements to rotating a public key every so often
and keeping their names/dates mapped to their contents, which Paul was
saying is a requirement for DSA done right.

- Brad