shared secret using diffie-hellman

[Jason Nelson]

The recent security insight to the protocols been very cool; I'm glad this
is occurring before the protocols widespread deployment.  

The DiffieHellman agreement algorithm's seems to provide a good balance
between security, performance, while being readily apart of the major
language libraries (or as a managed class for .NET). I've seen no major
concerns presented that will impediment a .NET implementation of the
protocol. 

+1

The conversations in this list have brought forward a lot of good insight
while the core concerns have been kept intact!  

Keep up the good work guys! I'm excited to see this specification near its
1.0 christening and widespread adoption their after. Go Internet 2.0. 

Rock n Roll, 

Jason Nelson
Software Architect / President
nterface, LLC

-----Original Message-----
From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
On Behalf Of Brad Fitzpatrick
Sent: 06/04/2005 6:34 PM
To: yadis at lists.danga.com
Subject: shared secret using diffie-hellman

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

_______________________________________________
yadis mailing list
yadis at lists.danga.com
http://lists.danga.com/mailman/listinfo/yadis