The IKEv2 Header and the Security Association Payload

As discussed in my previous blogpost, during IKEv2 Establishment the first two exchanges are the "IKE SA Init" and the "IKE Auth". The first one is the only exchange that is unauthenticated and unencrypted, and therefore is of a special interest.     

The "IKE SA Init" exchange includes by default the IKEv2 header, the Security Association payload, the Key Exchange payload and the Nonce payload. Except of the IKEv2 header, of a special interest is the Security Association payload, for two main reasons: First, it is the one used for the various negotiations that need to take place in order to establish the Security Association, and secondly, ti will give us some room for testing IKEv2 implementations. Therefore, in this second part of the IKEv2 blogpost these two structures, the IKEv2 header and the Security Association payload, as well as their usage, are examined. 

The IKE header is depicted in the next figure:

The IKE Header Format (figure obtained from ref. [2]).

 In the above figure:

• SPIs (Security Parameter Indexes) are connection unique identifiers chosen by the endpoint (initiator and responder) themselves. Incoming IKE packets are mapped to an IKE SA only using the packet's SPI. Multiple sessions per peer are possible. In the first message of an initial IKE exchange, the initiator will set the responder's SPI value to zero.

• Next Payload indicates the type of payload that immediately follows the header.

• Exchange Type indicates the type of exchange being used. The reader should refer to https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml for the possible values. The most typical values are the following:

34	IKE_SA_INIT
35	IKE_AUTH
36	CREATE_CHILD_SA
37	INFORMATIONAL
38	IKE_SESSION_RESUME (defined in [4])

• Flags indicate specific options that are set for the message. The bits are as follows:

| X | X | R | V | I | X | X | X |

• R (Response) indicates that this message is a response to a message containing the same Message ID. This bit MUST be cleared in all request messages and MUST be set in all responses.

• V (Version) - Implementations of IKEv2 MUST clear this bit when sending and MUST ignore it in incoming messages.

• I (Initiator) MUST be set in messages sent by the original initiator of the IKE SA and MUST be cleared in messages sent by the original responder. It is used by the recipient to determine which eight octets of the SPI were generated by the recipient. This bit changes to reflect who initiated the last rekey of the IKE SA.

• 'X' bits MUST be set to zero (0) when sending and MUST be ignored on receipt.

• Message ID is used to control retransmission of lost packets and matching of requests and responses, as well as to prevent message replay attacks.

• Length indicates the length of the total message (including the header and all the payloads).

 A wireshark capture of IKEv2 header is presented below:

An IKEv2 header (as captured by Wireshark)

(screenshot obtained thanks to the pcap files published by by Johannes Weber at https://blog.webernetz.net/ikev1-ikev2-capture/)

In the above figure we can see: a) the initiator’s and responder’s SPIs (the responder’s one is set to 0 since this is the very first message of the initial exchange), b) the Next Payload (which, in this case, points to a Security Association payload, the IKE Version 2.0), c) the flags (which depict that this is a message sent by the Initiator of the exchange, and that it is a Request, and d) the Message ID and the length of the header plus the payloads.

For more information the fields of the IKE header, the reader can refer to section 3.1 of [2].

Each IKE payload begins with a generic payload header, shown in the next figure. This is the first part of all IKE payloads, and hence, it is described in this subsection to avoid repeating information.

Generic Payload Header (figure obtained from ref. [2]).

• Next Payload is an identifier for the type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. An Encrypted payload, which must always be the last payload of a message, is an exception. The currently defined payloads are the following:

  33	Security Association	SA
  34	Key Exchange	KE
  35	Identification - Initiator	IDi
  36	Identification - Responder	IDr
  37	Certificate	CERT
  38	Certificate Request	CERTREQ
  39	Authentication	AUTHGeneric
  40	Nonce	Ni, Nr
  41	Notify	N
  42	Delete	D
  43	Vendor ID	V
  44	Traffic Selector - Initiator	TSi
  45	Traffic Selector - Responder	TSr
  46	Encrypted and Authenticated	SK
  47	Configuration	CP
  48	Extensible Authentication	EAP
  49	Generic Secure Password Method	GSPM [RFC6467]
  53	Encrypted and Authenticated Fragment	SKF     [RFC7383]
  54	Puzzle Solution	PS       [RFC8019]

  The reader should refer to https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml for the latest update.

• Critical MUST be set to zero if the sender wants the recipient to skip this payload if it does not understand the payload type code in the Next Payload field of the previous payload. It MUST be set to one if the sender wants the recipient to reject this entire message if it does not understand the payload type. It MUST be ignored by the recipient if the recipient understands the payload type code. Note that the critical bit applies to the current payload rather than the "next" payload whose type code appears in the first octet.

• Payload Length is the length in octets of the current payload, including the generic payload header.

The Security Association payload is probably the most complicated IKEv2 one.

In a nutshell, eech Security Association (SA) payload MAY contain one or more Proposals, each one of which MAY contain one or more Transforms, each one of which MAY contain one or more Attribute information. Proposals, Transforms, and Attributes each have their own variable-length encodings. They are nested such that the Payload Length of an SA payload includes the combined contents of the SA, Proposal, Transform, and Attribute information.

An example of a Security Association payload with one Proposal and several nested Transforms is depicted below:

As said, the length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains.

The Security Association payload format is depicted in the figure below:

Security Association Payload (figure obtained from ref. [2]).

The first 32 bits are the ones of the Generic Payload header described in the previous subsection.

As already mentioned, a Security Association Payload may contain one or more payload. A Proposal contains a Proposal Num and an IPsec Protocol ID. The Proposals substructure is depicted in the next figure:

 Proposal Substructure (figure obtained from ref. [2]).

• Last Substruc specifies whether or not this is the last Proposal Substructure in the SA. This field has a value of 0 if this was the last Proposal Substructure, and a value of 2 if there are more Proposal Substructures.

• Proposal Length is the length of this proposal, including all transforms and attributes that follow.

• Proposal Num. When a proposal is made, the first proposal in an SA payload MUST be 1, and subsequent proposals MUST be one more than the previous proposal (indicating an OR of the two proposals). When a proposal is accepted, the proposal number in the SA payload MUST match the number on the proposal sent that was accepted.

• Protocol ID specifies the IPsec protocol identifier for the current negotiation. The most common defined values are the following (more can be found in https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-18):

Protocol Protocol ID

IKE          1

AH           2

ESP         3

• SPI Size. For an initial IKE SA negotiation, this field MUST be zero; the SPI is obtained from the outer header. During subsequent negotiations, it is equal to the size, in octets, of the SPI of the corresponding protocol (8 for IKE, 4 for ESP and AH).

• Num Transforms specifies the number of transforms in this proposal.

• SPI (variable) - The sending entity's SPI. Even if the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload. When the SPI Size field is zero, this field is not present in the Security Association payload.

If there is more than one Proposal, they MUST be ordered from most preferred to least preferred. Each Proposal contains a single IPsec protocol, each protocol MAY contain multiple transforms, and each transform MAY contain multiple attributes.

Each Proposal structure is followed by one or more transform structures. The number of different Transforms is generally determined by the Protocol, as follows:

• AH generally has two transforms: Extended Sequence Numbers (ESNs) and an integrity check algorithm.

• ESP generally has three transforms: ESN, an encryption algorithm, and an integrity check algorithm.

• IKE generally has four transforms: a Diffie-Hellman group, an integrity check algorithm, a PRF (Pseudo-Random Function) algorithm, and an encryption algorithm.

The Transforms substructure is depicted in the next figure:

Transform Substructure (figure obtained from ref. [2]).

• Last Substruc specifies whether or not this is the last Transform Substructure in the Proposal. This field has a value of 0 if this was the last Transform Substructure, and a value of 3 if there are more Transform Substructures.

• Transform Length gives the length (in octets) of the Transform Substructure including Header and Attributes.

• Transform Type. Different protocols support different Transform Types. For some protocols, some of the transforms may be optional. If a transform is optional and the initiator wishes to propose that the transform be omitted, no transform of the given type is included in the proposal. If the initiator wishes to make use of the transform optional to the responder, it includes a transform substructure with Transform ID = 0 as one of the options. The Transform Type values are listed below (the reader should refer to https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-3 for the latest update).

   Description                     Trans.  Used In
                                   Type
   ------------------------------------------------------------------
   Encryption Algorithm (ENCR)     1       IKE and ESP
   Pseudorandom Function (PRF)     2       IKE
   Integrity Algorithm (INTEG)     3       IKE, AH, optional in ESP
   Diffie-Hellman Group (D-H)      4       IKE, optional in AH & ESP
   Extended Sequence Numbers (ESN) 5       AH and ESP

• Transform ID (2 octets) - The specific instance of the Transform Type being proposed. The Transform IDs for each Transform Type are listed in https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml.

If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple transforms with different Transform Types, the proposal is an AND of the different groups.

Attributes are necessary when the transform can be used in more than one way, as when an encryption algorithm has a variable key size. The transform would specify the algorithm and the attribute would specify the key size.

Most transforms do not have Attributes though. A transform MUST NOT have multiple attributes of the same type.

The Attributes are type/value pairs. Attributes can have a value with a fixed two-octet length or a variable-length value. For the latter, the attribute is encoded as type/length/value.

The Attributes Substructure is depicted in the figure below:

Attributes Substructure (figure obtained from ref. [2]).

• Attribute Format (AF) indicates whether the data attribute follows the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is zero (0), then the attribute uses TLV format; if the AF bit is one (1), the TV format (with two-byte value) is used.

• Attribute Type is a Unique identifier for each type of attribute.

• Attribute Value (variable length) is the value of the attribute associated with the attribute type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets.

The only currently defined Attribute type (Key Length) is fixed length (the variable-length encoding specification is included only for future extensions). This is defined as follows:

  Attribute Type         Value         Attribute Format
       ------------------------------------------------------------
       Key Length (in bits)   14            TV

An example of a set of Transforms (as a part of a Proposal), with one of them incorporating an Attribute, is depicted on the following Wireshark output:

A Wireshark output of some Transforms and an Attribute as part of the Security Association Payload.

 In the above example, the Attribute of the first transform (which proposes the use of AES as an encryption algorithm) is the key length of the AES algorithm (256 bits).

The Key Exchange payload is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The Key Exchange payload consists of the IKE generic payload header followed by the Diffie-Hellman public value itself.

The Key Exchange Payload (figure obtained from ref. [2]).

A Key Exchange payload is constructed by copying one’s Diffie-Hellman public value into the "Key Exchange Data" portion of the payload. T

he Diffie-Hellman Group Num identifies the Diffie-Hellman group in which the Key Exchange Data was computed. This Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified in a proposal in the SA payload that is sent in the same message, and SHOULD match the Diffie-Hellman group in the first group in the first proposal, if such exists. If none of the proposals in that SA payload specifies a Diffie-Hellman group, the KE payload MUST NOT be present. If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD.

The Nonce payload, denoted as Ni and Nr in this document for the initiator’s and responder’s nonce, respectively, contains random data used to guarantee liveness during an exchange and protect against replay attacks.

The Nonce Payload (figure obtained from ref. [2]).

Nonce Data (which is of a variable length) contains the random data generated by the transmitting entity.

The payload type for the Nonce payload is forty (40).

The size of the Nonce Data MUST be between 16 and 256 octets,inclusive. Nonce values MUST NOT be reused.

A wireshark screenshot of the Key Exchange and of the Nonce payload is presented below:

A Wireshark screenshot of a Key Exhange and a Nonce Payload

In these first two blogposts we examine how an IKEv2 Security Association(SA) is established. We saw that in order to achieve this we need two pairs of exchanges, IKE_SA_Init and IKE_Auth exchanges. From them, only the first one is unencrypted. Therefore, during the SA establishment, IKE_SA_init is the only attack surface available to an unauthenticated attacker.

During IKE_SA_Init, at a minimum one header (the IKEv2 header) and three payloads are used: The Security Association payload, the Key Exchange payload and the Nonce payload 9in some cases some more are used, but this will be examined in another blog post).

From the aforementioned IKEv2 payloads used during the SA establishment, of a special interest seems to be the Security Association payload. That is because it can encapsulate several nested substructures, of a different levels (Proposals, Transformations, Attributes) and numbers of substructure per parent structure.

In the next blog post I shall explain how we can easily set up a virtual IKEv2 lab and we will start testing it.

Until then, Merry Christmas to all!

[1] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.

[3] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, V.IT-22 n. 6, June 1977.

[4] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, <https://www.rfc-editor.org/info/rfc5723>.