IKEv2: Why is it important "that each side sign the other side's nonce"

Question

I am currently diging deep into the IKEv2 protocol. In the description of the Authentication (RFC5996, p. 48), the following statement is given:

"It is critical to the security of the exchange that each side sign the other side’s nonce"

Can anyone explain this issue to me? It is clear to me, that I need some kind of signature to prove the knowledge of a secret in order to authenticate. Also the fact that each side signs their first complete IKE_SA_INIT packet to provide integrity.

Answer 1

The sentence you quote is about replay attacks. If two systems A and B run the protocol and B proves its identity by signing some data element x, then that value x must change in some way every time the protocol is played. Otherwise, if x is reused, then an attacker C may impersonate B, by first observing the protocol once (to get a copy of B's signature on x), then by claiming to be B and showing that signature value again.

So x must change each time; and A must be sure that x is a new value, so it must not be chosen by B, but by A. A value chosen anew for each protocol run by a party and sent to the other is called a nonce.

The symmetrical situation arises when A signs and B verifies, so you need two nonces, and each system must sign the other side's nonce.

---

A simple nonce is not enough, though, because some industrious attacker could do the following:

• C connects to A and claims to be B.
• Simultaneously, C connects to B and claims to be A.
• A sends a nonce u to be signed by C (A will verify it with B's public key).
• B sends a nonce v to be signed by C (B will verify it with A's public key).
• C sends u to B as the nonce to be signed by B.
• C sends v to A as the nonce to be signed by A.
• B signs u, as is specified by the protocol.
• A signs v, as is specified by the protocol.
• C sends B's signature on u to A.
• C sends A's signature on v to B.

And voila! both A and B received a signature from, respectively, B and A, on the nonce values u and v that they sent. So now A and B are "sure" to be talking to each other, while in fact they are talking to the attacker C.

The trick here is that C "retargets" nonces and signatures: the attacker sends as "nonce to sign" the value that he received himself, and also sends back as "signature on nonce" a signature that he received. To prevent such attacks, the signature must not cover only the nonce, but also enough connection-specific data to prevent this retargeting. That is the point of including the whole IKE_SA_INIT in that block which is signed.

This kind of protocol issue is generic; you'll find the same kind of countermeasures in SSL/TLS, where both the signature from the client (CertificateVerify) and the final checksums (Finished messages) operate on hashes computed over all previous handshake messages.