Prerequisites:

IPsec VPN: Understanding the IKE Phase 1 Main Mode

IKE Phase 2 | Quick mode

• IKE phase 2 tunnel is also referred to as IPsec tunnel.

• This tunnel will be used to protect user data and there is only 1 mode to build this tunnel and i.e. Quick mode.

• Negotiation for the Phase 2 tunnel happens within the protection of our IKE Phase 1 tunnel so everything is encrypted and only the hash of the message contents (payloads & message ID) can be seen.

• Only 3 messages are sent for Phase 2 tunnel negotiation.

• It is unidirectional.

---

IKE Phase 2 parameters & payloads

The VPN peers will negotiate several parameters as follows:

Where:

1. HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )

2. HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr )

3. HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

HASH(1) is the prf over the following parameters:

1. M-ID = message-id from the ISAKMP header but excluding any padding added for encryption

   

2. SA = security associations sent as a proposal.

3. Ni = Nonce of Initiator which is just a random number used once.

4. KE = Key exchange payload

5. IDci = client ID of the initiator

6. IDcr = client ID of responder

HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni is added after M-ID but before the complete message. The addition of the nonce to HASH(2) is for liveliness proof.

HASH(3) is the prf over the following parameters:

1. value zero represented as a single octet,

2. M-ID = message id

3. Ni_b = Nonce of Initiator

4. Nr_b = Nonce of responder

Pseudo-Random Function | PRF

PRF uses an algorithm to generate pseudo-random content utilizing certain parameters/arguments for the creation of keying material and can be calculated:

1. Periodically - after a negotiated interval of time i.e. the lifetime value negotiated in Quick mode messages 1 and 2.

2. Triggered - required re-keying event or for integrity check function.

---

Perfect Forward Secrecy | PFS

In IKE Phase 1, DH key values are exchanged to derive a DH shared secret. Further, this shared secret along with the SKEYID is used to generate session keys to encrypt 5th and 6th Main mode messages and also the IKE Phase 2 messages.

When using pre-shared keys:

SKEYID = prf(pre-shared-key, Ni_b | Nr_b)

The SKEYID value along with the DH Shared Secret (and a few other values) are used to create three session keys:

The above keys are derived as follows:

SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)

SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)

SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

Without PFS

If PFS is disabled then additional DH Key Exchange payloads are not exchanged during Phase 2 or Quick mode message exchange and the keying material is defined as:

KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).

With PFS

If PFS is enabled then additional DH Key Exchange payloads are exchanged and the keying material is defined as:

KEYMAT = prf(SKEYID_d, g^xy | protocol | SPI | Ni_b | Nr_b)

where g^xy is the DH shared secret from the temporary or short-lived DH key exchange of this Quick Mode.

So when PFS is enabled, the keying material is defined using both:

1. SKEYID_d = Derived session key from Phase 1

2. g^xy = DH shared secret made using forced key exchange in Phase 2 / Quick mode.

NOTE: In either case, "protocol" and "SPI" are from the ISAKMP Proposal Payload that contained the negotiated Transform set.

Packet capture analysis

Spoiler: Nothing much to see here as these messages are encrypted.

Quick mode message 1:

Quick mode message 2:

Quick mode message 3:

References:

1. RFC- https://www.rfc-editor.org/rfc/rfc2409

2. PCAP file - https://www.cloudshark.org/captures/ff740838f1c2