shared secret using diffie-hellman
Brad Fitzpatrick
brad at danga.com
Sat Jun 4 18:34:03 PDT 2005
Here's how I'd see the shared secret setup as outlined before (and
corrected by Paul), but using diffie-hellman for finding the shared
secret, instead of passing it in the clear.
Props to Ben Trott for telling me about DH. Anybody correct me if I
understand it wrong.
Diffie-Hellman:
1) If consumer doesn't have shared secret handle:
consumer --> idserver (no UA involved, not that it'd matter)
openid.mode=get_dh_params
idserver -> consumer
p = prime
g = base
pub_key = ....
secret_handle = opaque string (probably "p/g/pub_key/last_privkey_gen_time/nonce/hmac-of-it-all")
expiry = 86400
consumer then maps that secret_handle to p, g,
pub_key_idserver, and its own priv_key it then generates. at
this point, the consumer knows the shared secret before the
identity server does, but the identity server did the harder
part of finding p and g. (design req: consumers dumber than servers)
2) Once it has that, it works mostly as before:
consumer --> UA -> idserver
openid.mode = checkid_immediate
openid.secret_handle = <that opaque string>
openid.pub_key = <consumer's public key for that secret_handle>
(now the idserver knows the shared secret, since it sees the
consumer's public key. after it parses/validates secret_handle is
valid too, of course, based on the hmac-of-it-all.)
idserver -> UA (redirect) -> consumer
openid.mode = id_res
openid.secret_handle = <that opaque string>
openid.hmac = HMACSHA1( shared_secret(secret_handle), plain )
It's no more HTTP requests than the plain-text exchange, it makes
people happy, and the only addition req on consumers is bigint
support (widely available). No primality testing, etc.
Thoughts?
- Brad
More information about the yadis
mailing list