Establishing SAs Through IKEv1 Negotiation

IKEv1 goes through two phases to establish SAs. In phase 1, two peers negotiate and establish a secure tunnel, which is an IKE SA. In phase 2, the peers establish a pair of IPSec SAs for secure data transmission through the secure tunnel established in phase 1.

IKEv1 Phase 1

IKEv1 phase 1 needs to establish an IKE SA. After an IKE SA is established, all the ISAKMP messages transmitted between two IPSec peers are encrypted and authenticated. The secure tunnel established in phase 1 enables IPSec peers to communicate securely in phase 2.

IKEv1 phase 1 can use either main mode or aggressive mode.

The main mode requires three exchanges between the peers, totaling six ISAKMP messages, as shown in Figure 1. The three exchanges are described as follows:

Messages (1) and (2) are used for proposal exchange.

The initiator sends one or more IKE proposals to the responder. The responder then searches for IKE proposals and sends the first matched proposal to the initiator. IKE proposals of the initiator and responder match if they have the same encryption algorithm, authentication algorithm, authentication method, and DH group identifier.
Messages (3) and (4) are used for key information exchange.

The initiator and responder exchange the DH public value and nonce value to generate the IKE SA authentication key and encryption key.
Messages (5) and (6) are used for exchanging identity and authentication information. The initiator and responder use the generated keys to authenticate each other and the information exchanged in main mode.

Efficient VPN supports only the aggressive mode.
An IKE proposal is a set of algorithms used to secure IKE negotiation, including the encryption algorithm, authentication algorithm, DH group, and authentication method.
A nonce value is a random number that is used to check whether the IKE SA is alive and to protect against replay attacks.

The aggressive mode requires only two exchanges, totaling three messages. Messages (1) and (2) are used to negotiate an IKE proposal and exchange the DH public value, mandatory auxiliary information, and identity information. Message (2) also contains the identity information sent by the responder to the initiator for authentication. Message (3) is used by the responder to authenticate the initiator. Figure 1 shows IKEv1 phase 1.

Figure 1 IKEv1 phase 1

Compared with the main mode, the aggressive mode reduces the number of exchanged messages and speeds up the negotiation. However, the aggressive mode does not encrypt identity information.

IKEv1 Phase 2

IKEv1 phase 2 establishes IPSec SAs and generates keys for securely transmitting data. This phase uses the quick mode. This mode uses the keys generated in phase 1 to verify the integrity of ISAKMP messages and identities of the initiator and responder, and to encrypt ISAKMP messages, ensuring exchange security. Figure 2 shows IKEv1 phase 2.

Figure 2 IKEv1 phase 2

In IKEv1 phase 2, two IPSec SAs are established through three ISAKMP messages:

The initiator sends local security parameters and identity authentication information to the responder.

Security parameters include protected data flows and parameters to be negotiated, such as the IPSec proposal. Identity authentication information includes the keys generated in phase 1 and keying materials generated in phase 2, and can be used to authenticate the peer again.

An IPSec proposal is a set of protocols and algorithms used for negotiation, including the security protocol, encryption algorithm, and authentication algorithm.
The responder sends acknowledged security parameters and identity authentication information, and generates new keys.

The encryption key and authentication key used for secure data transmission over IPSec SAs are generated based on the keys generated in phase 1 and parameters such as the SPI and protocol. This ensures that each IPSec SA has unique encryption and authentication keys.

If PFS is enabled, the DH algorithm is used again to generate shared keys, based on which the encryption key and authentication key are calculated. Therefore, during parameter negotiation, a DH key group needs to be negotiated for PFS.
The initiator sends acknowledged information to communicate with the responder. IKEv1 negotiation then ends.