7.1.1.1. AH extension

The presence of the AH extension is indicated by the Next Header (in IPv6) or Protocol (in IPv4) field of the previous header, with a value of 51.

The AH extension contains the following fields (Figure 7.1).

Next Header: this field, coded on one byte, indicates the type of header following the ESP extension.

Payload Length: this field, coded on 1 byte, provides the extension size in multiples of four bytes, not including the first eight bytes. The size of the extension in IPv6 must remain a multiple of eight bytes.

Security parameters index (SPI): this field, coded on four bytes, contains a value pertaining to the previously negotiated security association.

Sequence Number: this field, coded on four bytes, contains a value increased by one unit for each IPv4 or IPv6 packet transmitted. This field enables protection against replay. This field has a value of 1 for the first packet transmitted. When the counter reaches the maximum value, a new security association must be negotiated in order to avoid the start of a new cycle.

An extended sequence number (ESN), coded on eight bytes, constitutes an option, making it possible for the lifetime of the security association to be prolonged. In order to preserve the structure of the extension, the 32 least significant bits are transmitted in the sequence number field. However, the seal is calculated on all 64 bits.

Integrity check value (ICV): this field is coded on a multiple of four bytes and contains the seal of the data, ensuring authentication and integrity checking.

7.1.1.2. ESP extension

The presence of the ESP extension (Figure 7.2) is indicated by the Next Header (in IPv6) or Protocol (in IPv4) field of the previous header, with a value of 50.

The ESP extension contains the same fields as the AH extension. It starts with the SPI and Sequence Number fields. After these fields come the encapsulated data, which may contain synchronization data (initialization vector) of the encryptor. Following the encapsulated data, the extension ends with the following fields: Padding, Pad, Length, Next Header and optionally ICV (authentication, data).

The Padding field is necessary when block encryption is used, and the block must be of a certain size, to align the packet size with a multiple of four bytes.

7.1.1.3. Transport and tunnel modes

For transport mode, the AH or ESP header is inserted between the IP header and the source IP packet payload. In the IPv6 environment, the AH or ESP header appears after the Hop-by-Hop, Destination, Routing and Fragment extensions.

For tunnel mode, the AH or ESP header encapsulates the source IP packet, and the whole is encapsulated in its turn by a new IP header. The tunnel corresponds to a data structure, in which an IP packet contains another IP packet.

When the AH header is used, authentication is applied to the whole packet except for the variable fields of the IP header (Figure 7.3).

The variable fields of the IPv4 header are set at ZERO to calculate the authentication digest:

• – DSCP (DiffServ Code Point): the value of this field can be modified by an intermediary router when it checks traffic characteristics;
• – ECN (Explicit Congestion Notification): the value of this field can be modified by an intermediary router to alert the destination that congestion is developing;
• – DF (Don’t Fragment): this bit can be set at ONE by an intermediary router;
• – Fragment Offset: insertion of the AH header occurs on non-fragmented IP packets, and, therefore, this field has a value of zero;
• – TTL (Time To Live): the value of this field is decreased by one unit for each router crossed;
• – Checksum: the value of this field is recalculated as soon as a field in the IP header changes value.

The set of IPv4 header options is considered as a single entity. Some options can be modified by an intermediary router. If a single modifiable option appears, then the set of options is set at ZERO for the authentication digest calculation.

The variable fields of the IPv6 header are set at ZERO for the authentication digest calculation. These are identical fields to the ones in the IPv4 header (DSCP, ECN and Hop Limit), as well as the Flow Label field.

The Hop-by-Hop and Destination extensions of the IPv6 header have a bit that indicates whether the option can be modified by an intermediary router or not. If this bit is set at ONE, then the extension is set at ZERO for the authentication digest calculation.

When the ESP header is used in transport mode, the confidentiality service is applied to the encapsulated data and ESP tail. Authentication and integrity services cover the ESP header, encapsulated data and ESP tail (Figure 7.4).

When the ESP header is used in tunnel mode, the confidentiality service is applied to the source IP packet and ESP tail. Authentication and integrity services cover the ESP header, source IP packet and ESP tail (Figure 7.4).

Note that in transport mode, the Destination extension can appear before, after or simultaneously before and after the AH or ESP extension.

7.1.2.1. Message header

The header of the IKE message contains the following fields (Figure 7.5):

Initiator’s SPI: this field, coded on eight bytes, incorporates a value chosen by the initiator. It initializes identification of the IKE security association.

Responder’s SPI: this field, coded on eight bytes, incorporates a value chosen by the responder. It completes the identification of the IKE security association.

Next Payload: this field, coded on one byte, incorporates the indication of the type of block following the header (Table 7.1).

Major Version: this field, coded on four bits, indicates the maximum value of the IKE protocol version that can be used. This value is equal to 2 for the implementation of the IKEv2 protocol.

Minor Version: this field, coded on four bits, indicates the minimum value of the IKE protocol version. This value is equal to 0 for the implementation of the IKEv2 protocol.

Exchange Type: this field, coded on one byte, indicates the type of exchange to which the message belongs:

• – IKE_SA_INIT: this exchange concerns the first phase of the establishment of the IKE security association;
• – IKE_AUTH: this exchange concerns the second phase of the establishment of the security association;
• – CREATE_CHILD_SA: this exchange concerns the establishment of the ESP/AH security association;
• – INFORMATIONAL: this exchange concerns event notification.

Each type of exchange imposes a certain number of required blocks composing the message and defines optional blocks.

Flags: this field includes the following three flags:

• – R (Response): this flag, positioned at ONE, indicates that this message is a response. An IKE termination must not respond to a response except when authentication has failed;
• – V (Version): this flag, positioned at ONE, indicates that the IKE termination is able to process a version higher than the one shown in the Major Version field;
• – I (initiator): this flag, positioned at ONE, indicates that the message is generated by the initiator of the IKE security association.

Message ID: this field, coded on four bytes, is an identifier used to control the retransmission of lost messages and to correlate the request and response. It also protects against replay attacks.

Length: this field, coded on four bytes, includes the IKE message size.

7.1.2.2. Blocks

Each block starts with a generic header containing the Next Payload field, the C (Critical) bit and the Payload Length field (Figure 7.6).

The Next Payload field indicates the type of block that comes next, thus enabling chaining.

The C bit determines the process to be executed when the receiver does not recognize the block:

• – if the C bit is positioned at ONE, the receiver rejects the message;
• – if the C bit is positioned at ZERO, the receiver ignores the block and processes the next block.

7.1.3.1. IKE_SA_INIT exchange

The first exchange, IKE_SA_INIT, negotiates cryptographic algorithms and random numbers and executes a Diffie–Hellman exchange in order to create an IKE security association.

The initiator generates an IKE message containing the header (HDR) and the SAi1, KEi and Ni blocks. The header contains the initiator’s SPI, version numbers and flags. The SAi1 block contains the cryptographic algorithms proposed by the initiator for the IKE security association. The KEi block includes the Diffie–Hellman group and public value. The Ni block displays the initiator’s random number (Figure 7.7).

The responder chooses a cryptograph series from the initiator’s proposals and includes it in the SAr1 block. It completes the exchange of Diffie–Hellman keys with the KEr block. It sends its random number in the Nr block (Figure 7.7). It can possibly communicate a list of certificate authorities in the CERTREQ block.

At this stage of the negotiation, each end point can generate the SKEYSEED key. The keys used for encryption and integrity of IKE messages are produced by the SKEYSEED key and are known as SK_e (encryption) and SK_a (integrity). Message protection involves only the blocks; the header is not included.

The two different directions of traffic use different keys. The keys used to protect messages from the initiator are SK_ai and SK_ei. The keys used to protect messages in the other direction are SK_ar and SK_er.

Other keys are also derived from the SKEYSEED key. The SK_d key is used to derive the keys used in the ESP/AH security association.

The SKEYSEED key is calculated using the Diffie–Hellman secret (D-H key) and the random numbers Ni and Nr:

• SKEYSEED = PRF (D-H key, Ni | Nr)

The keys SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi and SK_pr are generated as follows:

• SK_d = PRF (SKEYSEED, Ni | Nr | SPIi | SPIr | 0x01);
• SK_ai = PRF (SKEYSEED, SK_d | Ni | Nr | SPIi | SPIr | 0x02);
• SK_ar = PRF (SKEYSEED, SK_ai | Ni | Nr | SPIi | SPIr | 0x03);
• SK_ei = PRF (SKEYSEED, SK_ar | Ni | Nr | SPIi | SPIr | 0x04);
• SK_er = PRF (SKEYSEED, SK_ei | Ni | Nr | SPIi | SPIr | 0x05).

7.1.3.2. IKE_AUTH exchange

The second exchange, IKE_AUTH, is used to authenticate previous IKE messages and communicate identities and possibly exchange certificates, as well as to establish the first AH/ESP security association. These messages are completely encrypted and protected by the keys established during the IKE_SA_INIT exchange.

The initiator indicates its identity with the IDi block. It authenticates its identity and protects the integrity of the first message in the IKE_SA_INIT exchange using the AUTH block.

It can possibly send its certificate in the CERT block and the certification authority’s identity in the CERTREQ block. In this case, the AUTH block contains the initiator’s signature (Figure 7.8).

The optional IDr block enables the initiator to specify which of the responder’s identities it wishes to communicate with (Figure 7.8).

The initiator starts the negotiation of the AH/ESP security association with the SAi2 block. The TSi block specifies the characteristics of the packets transferred by the initiator. The TSr block specifies the address for packets transferred to the responder (Figure 7.8).

The notation SK{ … } indicates that the blocks are completely encrypted and protected (Figure 7.8).

The responder communicates its identity in the IDr block. It may send a certificate. It authenticates its identity and protects the integrity of the second message of the IKE_SA_INIT exchange. It completes the negotiation of the ESP/AH security association with the SAr2 block (Figure 7.8).

7.1.3.3. CREATE_CHILD_SA exchange

The CREATE_CHILD_SA exchange is used to create the ESP/AH security association and to renew the keys of the IKE and ESP/AH security association.

For the exchange involving the creation of the ESP/AH security association, the initiator finalizes it in the SA block and the traffic selectors proposed for the SA in the TSi and TSr blocks. It transmits a random number in the Ni block and optionally a Diffie–Hellman value in the KEi block (Figure 7.9).

The responder confirms the offer in the SA block. It transmits a Diffie–Hellman value in the KEr block, if the KEi block has been included in the request (Figure 7.9).

The KEYMAT key, used for the ESP/AH security association, is derived from the SK_d key and the random numbers Ni and Nr. If the exchange contains Diffie–Hellman values, then the secret D-H key obtained also participates in the creation of the KEYMAT key:

• KEYMAT = PRF (SK_d, Ni | Nr)
• KEYMAT = PRF (SK_d, D-H key | Ni | Nr)

To renew the IKE SA key, the initiator sends the parameters in the SA block, a random number in the Ni block and a Diffie–Hellman value in the KEi block. The initiator’s new SPI is provided in the SA block (Figure 7.10).

The responder confirms the offer in the SA block. It transmits a Diffie–Hellman value in the KEr block. The responder’s new SPI is provided in the SA block (Figure 7.10).

The new SKEYSEED key is computed from the old key SK_d, the secret key D-H and the random numbers Ni and Nr.

• SKEYSEED = PRF (old SK_d, D-H key | Ni | Nr)

To renew the ESP/AH SA key, the messages transmitted by the initiator and the responder are similar to the ones used in the creation of the security association. The initiator’s request contains an N block (REKEY_SA) containing the SPI value of the new security association (Figure 7.11).