shared secret alternative to DSA

[Brad Fitzpatrick]

On Sat, 4 Jun 2005, Paul Crowley wrote:

> Brad Fitzpatrick wrote:
> > As requested, I'm appointing you security dictator over the OpenID spec.
>
> Wow, thanks!
.... [snip]

Thank you!

> > DEFINITIONS:
>
> I want to modify these somewhat.  All the modifications make life easier
> for server implementors and make no difference to consumers
>
> The only rule in the specification is that (1) you must get a fresh (ie
> never-before-issued by this server) secret ID every time you ask for
> one, and (2) the map between the set of secret IDs ever issued and the
> secrets they map to must be indistinguishable from random.  The rest is
> just an implementation recommendation.

Of course.  Totally agree on (1) and (2) as core spec requirements.  I was
mapping out what I'd make my Perl modules do.

> I'd recommend something more like this:
[snip]

Gotcha.

> I've replaced <public-random> with <public-nonce>,  ....

Agreed.

> Finally, HMAC-SHA1 takes two values, a key and a string, so I've
> modified it to show that.

Whoops, my bad.

> >           (perhaps also the consumer site's trust_root, so the returned secret handle/value
> >            are tied to one trust_root in case the value is intercepted)
>
> No need.  You can't use this secret to try and spoof other consumers,
> because those other consumers don't know this secret.

I was thinking so.  It was late and it was a last minute thought I didn't
fully think out.

> I'd rather handle the expiry stuff slightly differently, but that's
> nothing to do with the shared secret so I'll save it for another post.

Looking forward to it.

> Again this is nothing to do with shared secret, but I wonder what the
> pros and cons are of making the server explicitly include information
> like secret_handle and openid.assert_identity in the reply, over making
> the client encode it in the return_to URL however they like?

I'd say if it's something every consumer must have, let's make it
explicit.  If it's optional or can be handled in multiple ways, then let
it be part of the return_to.

> >  CON:  consumers /must/ cache the secret_handle -> secret_value, at least
> >        for 30 seconds or so.  at least with DSA mode, a completely stateless
> >        design was possible and caching just helped:  it wasn't required.
>
> A completely stateless design is still possible, but you need to be
> cunning about it.  You have to have a consumer secret, then encrypt/MAC
> the HMAC-SHA1 secret with the consumer secret, and include that in the
> return_to URL.

Encrypting sounds like we just lost the ease of implementation we were
seeking if ditching DSA.

> However, if this turns out to be a big pain, it would be possible for
> identity servers to do more to support consumers that really can't store
> any state at all; a simple variant on this protocol would allow for
> something more like your original idea of a callback from consumer to
> server on each identification, which is what the stateless consumers
> have to do anyway.

I'm for putting that "check mode" in the protocol spec as a MUST for
servers, to support dumb consumers.   It won't unduly load identity
servers because a) it's a cheap check, and b) any popular consumer would
have it in their best interest to cache secrets and avoid that extra HTTP
round-trip, so the only dumb consumers doing the unnecessary round trip
are ones that are either unable to cache (mobile devices?) or just playing
around, not serious, and didn't specify a Cache object to their library.

>  > What pros/cons and counter arguments am I missing?
>
> The big PRO argument that doesn't get a mention here is performance.

Okay.  Just not a big win from my point of view.  Compared to performance
problems I deal with regularly, I'm not concerned about performance
here... just correctness.

> >  CON:  secret value goes from idserver to consumer in the clear.
>
> This seems to be everyone's main stopping point.
>
> In one post you mentioned that sending secrets in the clear "looks bad".
>     But to my eyes, sending public keys unauthenticated looks worse.
> Either can make it look as if the security of the protocol isn't very
> well considered, if we don't justify them explicitly.  Both are
> justified only by our assumption that actually, doing bad things to core
> internet connections is quite difficult.  Both are solved if SSL is used.

If we document it as a recognized weakness that we're not worried about,
and that SSL is the answer for those that care, then I'm happy leaving it
"in the clear" for those that don't care.  TypeKey's identity server will
run on SSL, and LiveJournal's codebase will make it optional.

> >        -- Diffie-Hellman /could/ be used for secret exchange, maybe.
>
> If I really can't convince people here that it's no worse to send the
> MAC secret in the clear, then let's move to an HMAC-SHA1 + DH protocol.
>   That will address people's concerns, while still preserving the
> performance advantages, and avoiding the implementation complexity of
> DSA.   But to be honest I'm still far from convinced.  If you think
> there's a real risk your consumer connection to the ID server will be
> snooped, you should be just as worried about the risk it'll be tampered
> with, and in that case the only thing that will save you is SSL.

I'm leaning towards SSL instead of DH too.  So the requirements would be:

Consumer:
   - must have http library w/ SSL support.

Server:
   - optional: SSL

Both:
   - no DH, so no bigint work
   - sha1 library (hmac is trivial atop sha1)

?


- Brad