shared secret using diffie-hellman

[Paul Crowley]

Brad Fitzpatrick wrote:
> K = SHA-1(gx ^ y mod p), right?

Whoops, yes, sorry!  I usually think of g as an element of Z*_p, in 
which case the (mod p) is implicit, but we should be making it explicit 
here.

> CTR?  Where did AES come into play?  Why is any encryption necessary?

I thought we were going to use Diffie-Hellman key agreement to protect 
the secret MAC key from snoopers in transit?  Otherwise we're still 
having to do public-key-related stuff in the authentication 
transactions, which is what I was hoping to avoid

However, we can probably get away with using XOR instead of AES.  The 
reply could just send the secret key ID, expiry etc in the clear, and 
XOR the Diffie-Hellman key with the secret key.

> Single HTTP transaction to setup the shared secret, or for the identity
> check as well?

The flow is as before - consumer goes to server to get a secret; they 
get it in a single HTTP transaction and they can use it as often as they 
want.  They then use the secret to authenticate transactions that go via 
the user agent as before.

 > Because your openid.mode in your example above seems to
> suggest this round-trip was just for shared-secret setup, except you had a
> payload in the second half.

The payload is the shared secret.

> I'm confused about you saying consumers don't need to use more than one
> key and "x" must not be re-used.  Doesn't x influence the key?  Which key?

Consumers don't need more than one MAC key per server.  But every time 
they need a new MAC key for whatever reason, every time they need to do 
a new DH key agreement in order to fetch a MAC key, they must use a new 
value of x.
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/