I am looking for, but not finding, a published protocol that does something similar to TLS 1.3 mutual authentication, but simplified by using assumptions to reduce the chattiness of TLS.

If we assume that some set of clients are configured with key/cert pairs and the server's root cert, and the server has a key/cert pair and the client's root cert, and that the clients and server already know the cipher suite, can mutual authentication and key establishment be done with two messages?

I am thinking something like this:

C: ECDHE key material, client cert chain, signature (of something)

S: ECDHE key material, server cert chain, signature (also of something), Encrypted Data using AE

At this point, the two sides have apparently agreed on a ECDH key, and both sides have validated a signature and a cert chain. So...good to go?

Does this sound like anything already out there, or is it obviously deeply flawed? Is this just authenticated DH?

Edit: This appears to be similar to RFC 3830, so I guess that answers the question of something already existing.

  • Are you saying each client already has the server's authentication and encryption public keys? And that the server has each client's (at least authentication) public key? – Future Security Mar 21 at 1:56
  • More or less. Each client has the root cert for the server's certificate chain, and vice versa. So in the end, after receiving and validating a certificate chain, each side has the other's public key. The key in the cert is RSA, and can be (should be?) restricted to authentication. – Brad Mar 21 at 19:42

Triple Diffie-Hellman (3DH) is a simple authenticated key exchange with forward security and deniability.

Client and servers each generate a long term (identity) key pair. For each key exchange they generate an ephemeral key. It uses the same number of messages as ordinary DH.

  1. The client sends both its public keys (identity and ephemeral).
  2. The server verifies the client's identity public key. The server responds with its two keys.
  3. Both sides derive their symmetric keys using three Diffie-Hellman exchanges. (Something like the following.)
    • X1 = DHE(ClientEphemeral, ServerEphemeral)
    • X2 = DHE(ClientEphemeral, ServerIdentity)
    • X3 = DHE(ClientIdentity, ServerEphemeral)
    • SharedKeyn = KDF(X1 || X2 || X3, n)
    • The client and server destroy their ephemeral keys.

No dedicated signing algorithm is needed for authentication with 3DH.

Since you mentioned ECDH and because it doesn't sound like you have the specifics of some other key exchange key scheme worked out, I recommend using 3DH instead. (Use symmetric key encryption and symmetric key authentication, obviously.)

  • My original question was terribly worded, so thanks for this. It looks solid, but then again Needham-Shroeder seemed like a really good idea at the time. Do you know whether this one has had any formal methods analysis done to it? – Brad Mar 25 at 2:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.