The IKE_SA_INIT does create a key seed SKEYSEED from the Diffie-Hellman values and nonces. Since the exchange does sharing the secret between the communication partners, I do not understand why it is not enough for authentication.
Add a comment
|
1 Answer
The plain ephemeral (new key every connection) Diffie-Hellman is unauthenticated. You perform the DH operation using newly created keys on both sides and establish a shared secret value you can use to encrypt the communication. But you do not know who you're talking to. The other side can be anyone. You have no way to know, except if you trust the source IP address in the packets (you shouldn't).
TLS, SSH and IKE perform authentication after DH to establish that you are talking to the server/client you meant to talk to. This is called "authenticated Diffie-Hellman".
Usually the client ensures the server is not an impostor by requiring the server to produce a new asymmetric digital signature (and then verifying the signature), thus proving the server possesses the private key matching the public key the client already has (or which the client receives in a certificate and checks the certificate is signed by someone the client already trusts, etc.).
The server may require the same from the client, or some other form of authentication (or no client authentication at all as is common for TLS but not common for SSH and IKE).
Static DH (long term keys) can be used for authentication. For example, the client may know the public key share of the server, and the server may know the public key share of the client, and they can send messages to each other by performing DH using the private part of their own key and the public part of the other side's key, establish the same shared secret every time and use it for encryption. The problem with this scheme is that all messages are encrypted with the same key. When the the private part of either side's DH key leaks, the adversary can decrypt all previously recorded communication. To avoid this problem, we use ephemeral DH, with new keys every time and destroy the private part of the key in memory immediately after it has been used.
It is possible to combine ephemeral DH (new key every connection) and static DH (long term key), to use a long term DH key only for authentication while encrypting using newly established keys thus providing forward secrecy as in authenticated DH. If so, the handshake will be two DH operations instead of one DH operation and one digital signature operation. But AFAIK, this variant does not exist in the spec for IKE (or TLS or SSH). You can read about this in Noise protocol framework, if you're interested.
