The WANFast Key Exchange and Authentication Protocol

The WANFast Key Exchange and Authentication Protocol uses RSA key pairs and 256-bit AES encryption to secure a standard Diffie-Hellman key exchange and provide the following features:

  • forward secrecy.  Each WANFast session uses a new Diffie-Hellman key exchange so that breaking the protection on one connection does not open subsequent connections.
  • mutual authentication.  Both the end-user and the server are authenticated using RSA key pairs.
  • enhanced security.  It has been hypothesized that a sufficiently well-funded organization can assemble enough computer power to break a 1024-bit Diffie-Hellman exchange (see Diffie-Hellman).  The WANFast KEAP prevents this by a) using a 2048-bit exchange that can optionally be set higher; b) and by AES encrypting the exchange using ephemeral keys exchanged via RSA encryption.  Thus breaking a WANFast session would require first breaking two 2048-bit RSA keys before breaking a 2048-bit Diffie-Hellman exchange.

 

Detailed Protocol Description


SYMBOLS
-------
ID = Client ID used to index client's public key on server
g = Diffie-Hellman prime base
p = Diffie-Hellman prime modulus (2048 bit)
a = client's random nonce
A = g^a mod p
b = server's random nonce
B = g^b mod p
s = DH shared secret, On client: B^a mod p; on server: A^b mod p
S = Shared session key derived from s
CPrK = Client private key (2048-bit RSA)
CPuK = Client public key
SPrK = Server private key (2048-bit RSA)
SpuK = Server public key
S3D = The server's randomly generated temporary AES key.
C3D = The client's randomly generated temporary AES key.
[X]K = X encrypted using the key K
{X}S = Keyed hash of X using the key S
M = Session negotiation message
R = Session negotiation response

Phase 1: Client --> Server
--------------------------
    ID

The CLIENT sends its ID in a Phase 1message to the server.

The SERVER receives the Phase 1 message and looks the client ID up in its authorized_keys file to recover the client's public key.  If the ID is not found, the session is rejected.

Phase 2: Server --> Client
    [S3D]CPuK, [B]S3D, SpuK

The SERVER prepares a Phase 2 message that includes the server's public key (in case the client does not have it), an AES key that has been encrypted with the client's public  key, and the initial portion of a Diffie-Hellman key exchange, which has been encrypted with the AES key.

The WANFast KEAP provides authentication of the client, through the encryption of the DH public values.  Only the client can decrypt B to complete the DH exchange. Likewise the client returns its DH public value encrypted with a short-term AES key that can only be recovered using the server's public key.  If the two parties wind up with the same shared session key, then we are sure that the server has the server's private key and the client has the client's private key.

The WANFast KEAP also helps protect the DH exchange against an attack from the NSA or other very-well funded organizations that has been hypothesized in some of the literature.  In ssh, an attacker need only break the DH exchange in order to gain access to the subsequent encrypted data.  With KEAP, an attacker would need to steal (or break) both the server and client private keys in addition to breaking the DH exchange.

The KEAP protocol also preserves perfect forward secrecy in that the compromise of the server's private key does not expose past communications.  The attacker would still need to break the client's private key and the DH exchange.

The CLIENT receives the Phase 2 message and verifies that the server public key is in its known_hosts file.  If not, it asks the user's permission to add it to the file.  If not in the file and permission not granted, the session is rejected.  The client then decrypts the server's AES key using the client's private key.  It then uses the AES key to decrypt the server's public DH value.  The client then creates its own DH public value A, and completes the DH exchange to get the shared secret value s, from which it derives the shared session key, S.

Phase 3: Client --> Server
--------------------------
    [C3D]SPuK, {M}S, [A, M]C3D

The CLIENT prepares the Phase 3 message, which will include the actual session negotiation message, M, and an authenticator -- a keyed hash of M using S as the key.  The client then creates its own random AES key.  It encrypts the AES key with the server's public key.  It encrypts the DH public value and the message, M, with the AES key.

The SERVER receives the Phase 3 message and decrypts the client's AES key using the server's private key.  It then decrypts the client's public DH value, session negotiation message, and authenticator using the AES key.  It completes the DH exchange using A and b to get s, from which it derives the shared session key, S.  It then uses S to verifiy the message authenticator.

Phase 4: Server --> Client
--------------------------
    {R}S, [R]S3D

The SERVER prepares a Phase 4 message, which includes a session negotiation response, R, which it encrypts with the AES key that it created for Phase 2.  The message also includes an authenticator of R -- a keyed hash using S as the key.

The CLIENT receives the Phase 4 message and decrypts the response using the server's AES key from Phase 2.  It then validates the authenticator using S.  If valid, it processes the session negotiation response.