2

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.

3

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.

| improve this answer | |
  • Great answer, thanks for also explaining why it is important to sign the IKE_SA_INIT! – sege Apr 24 '14 at 11:52

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.