A Glance at IKEv2 Security Association Establishment

Internet Key Exchange (IKE) is the protocol used to establish Security Associations in IPsec. IP Security (IPsec) is a family of network protocols providing confidentiality, data integrity, access control, and data source authentication to IP datagrams [1]. These services are provided by maintaining shared states between the source and the sink of an IP datagram called Security Associations (SAs).

IKE is a component of IPsec used for performing mutual authentication, establishing and maintaining the SAs dynamically and in an automated way. Its latest version is IKE version 2 (IKEv2), defined in [2].

Given that (a small part of) IKE is the only part of IPsec which is still unauthentiticated and unencrypted ,it introduces a special interest from a security perspective, because it constitutes one of the very few attack surfaces of IPsec. The objective of this series of blog post is to examine the latest version of IKE, IKEv2, in order to a) to help us understand i to full a extent, and b) to identify potential attacking vectors.

All IKE communications consist of pairs of messages: a request and a response, called exchange. An IKE message flow always consists of a request followed by a response. It is the responsibility of the requester to ensure reliability. If the response is not received within a time-out interval, the requester needs to retransmit the request (or abandon the connection).

IKE messages use UDP ports 500 and/or 4500, with one IKE message per UDP datagram. When sent on UDP port 500, IKE messages begin immediately following the UDP header. When sent on UDP port 4500, IKE messages have prepended four octets of zeros, which are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE.

Each IKE message begins with the IKE header (HDR); following the header, there are one or more IKE payloads.

The exchanges that take place during the IKA SA establishment are depicted in the next diagram.

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

The above screenshot depicts the IKEv2 Exchanges used to establish a Security Association, as presented in the diagram above. 

In exceptional cases there may be more than one of each of above exchanges.

In all cases, all IKE_SA_INIT exchanges MUST complete before any other exchange type, then all IKE_AUTH exchanges MUST complete before any further IKE exchanges (IKE_SA_INIT and IKE_AUTH exchanges are known as “Phase 1” in IKEv1.).

The exact content of each exchange of the IKE SA establishment is described per case in the next subsections.

IKE_SA_INIT exchange, depicted in the diagram above, negotiates security parameters (cryptographic algorithms) for the IKE SA, sends nonces, and do Diffie-Hellman [3] exchange. Specifically:

   - HDR is the IKE header and contains the Security Parameter Indexes (SPIs), version numbers, Exchange Type, Message ID, and flags of various sorts. The format and the basic fields of the IKE header will be described later.

   - SAi1 payload states the cryptographic algorithms the initiator supports for the IKE SA.

   - The KE payload sends the initiator's Diffie-Hellman value.

   - Ni is the initiator's nonce.

The responder chooses a cryptographic suite from the initiator’s offered choices and expresses that choice in the SAr1 payload, completes the Diffie-Hellman exchange with the KEr payload, and sends its nonce in the Nr payload [2]. The responder may also include an optional CERTREQ (Certificate Request) payload to request preferred certificates via IKEv2.

The format of IKE header and the most frequently used payloads will be discussed later.

Examples of the IKEv2 SA Init Initiator request and Responder response are given below:

IKEv2 SA Init - Initiator request

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

IKEv2 SA Init - Responder response

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

The above screenshots depict the IKEv2 header payload, as presented in the diagram in the Security Association Establishment.

All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange.That is, during the SA establishment, both the Initiator and Responder include a Security Association payload, a Key Exchange payload and a Nonce (more on their exact format, will follow).

It should be noted that from this point onwards, all messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange.

IKE_AUTH exchanges identities and certificates, proves knowledge of the secrets corresponding to the two identities, and sets up an SA for the first (and often only) Child SA (unless there is failure setting up the Child SA, in which case the IKE SA is still established without the Child SA).

Parts of these messages are encrypted and integrity protected with keys established through the IKE_SA_INIT exchange.

IKE_AUTH messsages carry, in addition to the IKEV2 header, the so called “Encrypted and Authenticated” payload, or simply the Encrypted payload (typically denoted as SK). The Encrypted payload, if present in a message, MUST be the last payload in this message (often, it is the only one).

Screenshots of typical IKE_AUTH exchange are depicted below:

IKEv2 AUTH Init - Initiator request

IKEv2 AUTH Init - Responder response

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

As we can observe in the above two screenshots, IKEv2 AUTH exchange is already authenticated and encrypted. Therefore, it seems that any potential non-cryptograpchic attacks should take place earlier, during the IKE_SA_Init phase, if possible.

In the next blog post we will start diving into the format of the IKEv2 payloads used during the SA Establishment, so as to identify any potential attack vectors. Stay tuned! 

[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.