IKE stands for Internet Key Exchange. As you may guess from the terminology itself, it is a method that is used for Internet Security. Base framework of IKE is specified in RFC 2409 (IKE), RFC 4306 (IKEv2) and RFC 7296 (IKEv2).

This protocol is responsible for negotiating and exchanging the encryption keys that will be used to secure the communication between the two devices. IKE is used to establish the initial connection between two devices and to re-establish the connection if it is broken due to network disruptions or other issues.

IKE works by using a combination of several security protocols, including Authentication Header (AH), Encapsulating Security Payload (ESP), and Internet Security Association and Key Management Protocol (ISAKMP). These protocols work together to establish a secure channel between the two devices, authenticate the devices, negotiate the encryption algorithm and keys, and manage the keys during the communication.

• Two Phases of IKE
• Overall Sequece Flow - RFC 2409
• IKE : Phase 1 - Main Mode
• IKE : Phase 1 - Aggressive Mode
• Differences between Main Mode and Aggressive Mode
• Overall Sequence Flow - RFC 4306
• Comparision between IKEv1 and IKEv2
• IKE and ISAKMP
• Overall Sequence Flow - 3GPP 33.402
• Key Exchange Algorithm : IKE
• Step 1 :  SA Establish
• Step 1
• Step 2~6 :  Auth request/response for AAA
• Step 2
• Step 3
• Step 4
• Step 5
• Step 6
• Step 7~11 :  Auth request/response for RES/XRES Verification
• Step 7
• Step 8
• Step 9
• Step 10
• Step 11
• Step 12~15 :  Auth request/response for AUTH Verification
• Step 12
• Step 13
• Step 14
• Step 15
• IKEv2 Parameter Details
• Deleting SA
• DPD (Dead Peer Detection)
• Notation
• Appendix

Two Phases of IKE

IKE has two phases as follows : phase 1 of IKE establishes a secure channel for the exchange of IKE messages and negotiates the encryption algorithm and keys, while phase 2 establishes a secure channel for the exchange of data and negotiates the encryption algorithm and keys for protecting the data exchanged between the devices.

Phase 1:

In this phase, the devices establish a secure channel for the exchange of IKE messages. The main goal of this phase is to authenticate the devices and to negotiate the encryption algorithm and keys that will be used to secure the communication.

• Purpose: Establish a secure, authenticated communication channel between two peers to negotiate the IKE Security Association (SA).
• Process:
• Negotiation of IKE SA Parameters: Peers negotiate encryption, hashing, and Diffie-Hellman groups to establish a secure channel for further communication.
• Mutual Authentication: Peers authenticate each other using pre-shared keys, certificates, or public keys.
• Key Exchange: Each peer exchanges its Diffie-Hellman public key, which is used to generate a shared secret key.
• Creation of IKE SA: The shared key is used to create an IKE SA, which is used to protect subsequent exchanges.
• Outcome: A secure channel is created, and the IKE SA is established, allowing the peers to communicate securely for the next phase. This phase is also referred to as IKE_SA_INIT and IKE_AUTH exchanges in IKEv2.

The following steps occur in phase 1:

• a. The devices exchange a series of messages to establish a secure channel, called the IKE Security Association (SA). This channel will be used to exchange further messages during the negotiation process.
• b. The devices authenticate each other using a pre-shared key, a digital certificate, or another authentication method agreed upon during the negotiation.
• c. The devices negotiate the encryption algorithm and keys that will be used to secure the communication. They also negotiate the Diffie-Hellman key exchange algorithm, which is used to establish a shared secret between the devices.
• d. Once the negotiation is complete, the devices have established a secure IKE SA and are ready to proceed to phase 2.

Phase 2:

In this phase, the devices establish a secure channel for the exchange of data between the two devices. The main goal of this phase is to negotiate the encryption algorithm and keys that will be used to protect the data exchanged between the devices.

• Purpose: Negotiate the IPSec SAs, which define the encryption and integrity algorithms to be used for data transfer.
• Process:
• Negotiation of IPSec SA Parameters: Peers agree on the IPSec parameters, such as encryption and integrity algorithms, for protecting the data traffic.
• Establishment of Child SAs: The Child SAs (also called IPSec SAs) are established using the secure channel created in Phase 1. These SAs specify how the data packets will be protected during transfer.
• Key Exchange and Establishment of Traffic Keys: Additional keys are derived for protecting the actual data traffic.
• Outcome: The IPSec SAs are created, enabling secure data transfer between peers. This phase is responsible for the actual protection of IP traffic (data packets) using the negotiated parameters.

The following steps occur in phase 2:

• a. The devices negotiate the encryption algorithm and keys that will be used to protect the data exchanged between them. They also negotiate the protocol for data encryption and integrity, such as ESP (Encapsulating Security Payload) or AH (Authentication Header).
• b. Once the negotiation is complete, the devices have established a secure data channel and are ready to exchange data.
• c. The devices can now communicate securely over the network, using the encryption algorithm and keys that were negotiated during this phase.

Overall Sequence Flow - RFC 2409

The primary purpose of RFC 2409 defines the protocol and algorithms for IKE Phase 1. The protocol defined in this specification is called IKEv1.

IKE : Phase 1 - Main Mode

Main Mode provides a secure method for exchanging the authentication and encryption keys used in Phase 1, as well as for negotiating the parameters of the subsequent Phase 2 negotiation.

Acronyms used in the above procedures are as follows.

• SA stands for Security Association. It is a set of security parameters, such as encryption algorithms, integrity algorithms, and key lifetimes, that are negotiated between the two peers during IKE negotiation.
• N stands for the nonce value sent by the initiator in the IKE_SA_INIT message. The nonce is a random value used to ensure that each exchange of IKE messages is unique.
• KE stands for Key Exchange payload. It is used to transport the DH( Diffie-Hellman) public key between the two peers
• ID stands for Identity. It is a field in IKE messages that is used to identify the initiator or responder of the IKE negotiation. The identity may take different forms, depending on the authentication method being used. For example, the identity may be a username and password, a digital certificate, or a pre-shared key.
• "i" being used with each Acronym indicates "Initiator" and "r" being used with each Acronym indicates "Responder"

Followings are descriptions for each step.

• Step 1 : Initiator sends a proposal: The initiator sends a proposal message to the responder, which includes a set of encryption and authentication algorithms and parameters that the initiator is willing to use.
• Step 2 : Responder sends a proposal: The responder sends a proposal message to the initiator, which includes a set of encryption and authentication algorithms and parameters that the responder is willing to use.
• Step 3 : Initiator sends a Diffie-Hellman value: The initiator sends a Diffie-Hellman value to the responder, which is used to generate a shared secret key.
• Step 4 : Responder sends a Diffie-Hellman value and a certificate: The responder sends a Diffie-Hellman value to the initiator, along with a certificate that contains the responder's public key. The certificate is used to authenticate the responder to the initiator.
• Step 5 : Initiator verifies the certificate and generates a shared secret key: The initiator verifies the certificate sent by the responder and uses the Diffie-Hellman value to generate a shared secret key.
• Step 6 : Responder verifies the certificate and generates a shared secret key: The responder verifies the certificate sent by the initiator and uses the Diffie-Hellman value to generate a shared secret key.

IKE : Phase 1 - Aggressive Mode

Aggressive Mode provides a faster method for exchanging the authentication and encryption keys used in Phase 1, as well as for negotiating the parameters of the subsequent Phase 2 negotiation. Aggressive Mode is a three-message exchange that occurs between the two devices.

Acronyms used in the above procedures are as follows.

Followings are descriptions for each step.

• Step 1 : Initiator sends a proposal: The initiator sends a proposal message to the responder, which includes a set of encryption and authentication algorithms and parameters that the initiator is willing to use, along with its identity.
• Step 2 : Responder sends a proposal and its identity: The responder sends a proposal message to the initiator, which includes a set of encryption and authentication algorithms and parameters that the responder is willing to use, along with its identity.
• Step 3 : Initiator generates a shared secret key: The initiator generates a shared secret key using its identity, the responder's identity, and the Diffie-Hellman key exchange. The shared secret key is used to protect the subsequent Phase 2 negotiations.

Differences between Main Mode and Aggressive Mode

Both modes involve the negotiation and exchange of authentication and encryption keys, as well as the establishment of a secure channel for further communication, but there a several differences between the two modes as highlighted below.

• Protection against eavesdropping: Main Mode provides better protection against eavesdropping attacks, as it encrypts the identities of the devices during the first two messages. In contrast, Aggressive Mode exchanges the identities in plaintext in the first two messages, which makes it vulnerable to eavesdropping attacks.
• Negotiation flexibility: Main Mode provides greater flexibility in negotiating Phase 1 parameters, as it allows for multiple proposals to be exchanged between the devices. Aggressive Mode, on the other hand, only allows for a single proposal to be exchanged between the devices.
• Speed: Aggressive Mode is faster than Main Mode, as it involves fewer messages and requires less computation. However, this speed comes at the expense of security.

Which mode you would use depends on the specific security and performance requirements of the networked devices. Followings are some of the criteria of selecting which one to use. These are not mandatory criteria and are just general guide lines. You would see exceptions in real application that would not fit into these criteria.

• Site-to-Site VPNs: Main Mode is typically used for site-to-site VPNs, where security is of utmost importance, and there is no need for speed. Site-to-site VPNs are used to connect two or more remote networks over the Internet securely. Main Mode provides greater flexibility in negotiating Phase 1 parameters, and it provides better protection against eavesdropping attacks.
• Remote Access VPNs: Aggressive Mode is typically used for remote access VPNs, where speed is more important than security. Remote access VPNs are used to allow remote users to connect securely to a corporate network over the Internet. Aggressive Mode involves fewer messages and requires less computation, making it faster than Main Mode.
• Mobile Networks: Aggressive Mode is useful in mobile networks, where a large number of mobile clients need to quickly establish a secure connection. Mobile clients may have limited resources and may not be able to support the more computationally intensive Main Mode. In addition, mobile clients may already have prior knowledge of the network they are connecting to, making the exchange of identities in plaintext in the first two messages of Aggressive Mode less of a security concern.
• High-Security Networks: Main Mode is preferred for networks that require the highest levels of security, such as government or military networks. These networks require the highest levels of protection against eavesdropping attacks and require more flexible negotiation of Phase 1 parameters.

Overall Sequence Flow - RFC 4306

Following sequence is based on RFC 4306 2.16. Extensible Authentication Protocol Methods. RFC 4306 defines the protocol and algorithms for IKEv2, which improves upon the security and flexibility of IKEv1.

Acronyms used in the above procedures are as follows.

Followings are descriptions for each step.

• Step 1 : The initiator sends an IKE_SA_INIT message to the responder, indicating that it wishes to establish a secure connection.
• Step 2 : The responder sends an IKE_SA_INIT reply message back to the initiator, containing a list of supported EAP Methods.
• Step 3 : The initiator selects an EAP Method from the list provided by the responder, and includes this information in its next message.
• Step 4 : The responder sends an EAP Request message to the initiator, indicating that it is ready to begin the authentication process using the selected EAP Method.
• Step 5 : The initiator sends an EAP Response message back to the responder, containing the appropriate authentication information for the selected EAP Method.
• Step 6 : The responder continues to send EAP Request messages to the initiator, as needed, until the authentication process is complete.
• Step 7 : Once the authentication process is complete, the responder sends an IKE_AUTH message to the initiator, containing the result of the EAP authentication process.
• Step 8 : The initiator responds with an IKE_AUTH reply message, and the IKEv2 negotiation process continues as usual, with the exchange of additional messages to establish the secure connection.

Comparision between IKEv1 and IKEv2

There are some differences in terms of procedure and use cases as listed below.

• IKEv2 provides better protection against security threats, such as denial-of-service (DoS) attacks and man-in-the-middle (MitM) attacks, by using stronger cryptographic algorithms and providing improved authentication mechanisms.
• IKEv2 also provides better support for mobile and wireless networks, such as those used in smartphones and tablets. It allows for faster and more efficient reconnection to the network after a device has been disconnected, and it supports roaming between networks without the need for re-authentication.
• IKEv2 provides improved flexibility and extensibility over IKEv1. It allows for more fine-grained control over the negotiation of cryptographic parameters, and it provides a framework for the negotiation and implementation of additional security features and protocols.

IKE and ISAKMP

IKE (Internet Key Exchange) and ISAKMP (Internet Security Association and Key Management Protocol) have a closely intertwined relationship:

• ISAKMP is the Foundation: It provides the framework for establishing, negotiating, modifying, and deleting Security Associations (SAs).  Think of it as the underlying messaging and negotiation structure. In short, The general language for negotiating security associations.
• IKE Builds on ISAKMP: It's a specific protocol that uses ISAKMP to achieve its goal of setting up secure tunnels (IPsec SAs) in VPNs.  IKE defines the particular payloads, exchanges, and algorithms used within the ISAKMP framework for this purpose. In short, A specific dialect of that language, tailored for creating IPsec VPN tunnels.

In other words (more plain words),

• IKE is dependent on ISAKMP; it wouldn't exist without it.
• ISAKMP is more general and can be used for other security protocols beyond IKE.
• In practice, when you see "ISAKMP" in packet captures or discussions, it's often in the context of IKE negotiations.

Overall  Sequence Flow - 3GPP 33.402

If you are interested in 3GPP based device (e.g, LTE UE) trying to get access to the core network through WiFi, you may need to focus on this document (3GPP 33.402). However this doesn't mean that you don't have to refer to RFC anymore. RFC is still base framework for this 3GPP document. 3GPP 33.402 is based on RFC 4306 (IKEv2) in terms of overall sequence and in terms of packet structure and negotiation sequence it is based on RFC 2408 (ISAKMP).

• Key Exchange Algorithm : IKE
• Step 1 :  SA Establish
• Step 1
• Step 2~6 :  Auth request/response for AAA
• Step 2
• Step 3
• Step 4
• Step 5
• Step 6
• Step 7~11 :  Auth request/response for RES/XRES Verification
• Step 7
• Step 8
• Step 9
• Step 10
• Step 11
• Step 12~15 :  Auth request/response for AUTH Verification
• Step 12
• Step 13
• Step 14
• Step 15

< Key Exchange Algorithm : IKE >

Overall key exchanging protocol sequence in 33.402 is as shown below. (This is from Figure 8.2.2-1)

Following is Wireshark log capturing the transaction between UE and ePDG. In this log, AAA and HSS side log is not captured. I put the step number of 3GPP procedure on the right end of Wireshark log.

If you managed to decode the whole ISAKMP packet including the Encrypted Payload part, you will see the wireshark log as shown below.

There are a couple of important point where both Initiator and Respondor aquire a complete information to encode/decode the traffic as shown below.

Now let's look into the detailed contents/procedure of each steps.

Step 1 :  SA Establish

This step corresponds to Step 1~2 of RFC 4306.

In this step, UE and ePDG performs roughly following task. (These tasks are not performed by each separate steps, they are all performed in a signal back-and-forth. You will notice how these are performed if you see the detailed contents of ISAKMP packet that will be shown shortly)

• Negotiate Cryptographic Algorithm  
• Exchange Nonces
• Perform a Diffie_Hellman exchange

Actually Step 1 is made up of two sub steps as follows :

• Step 1a : UE --> ePDG : IKE SA INIT
• Step 1b : UE <-- ePDG : IKE SA INIT

In this step,

• Step 1a : UE notifies ePDG "Hey, I want to communicate with you and for the safe/secure communication, here goes the information /my capability for Security Association. (e.g, Key, Nonce, Hash Algorithm, Encryption Algorithm etc)
• Step 1b : ePDG tells UE "OK, I allows you to communicate with me.. for Safe/Secure communication, I want you to use this and this information and algorithm(e.g, Key, Nonce, Hash Algorithm, Encryption Algorithm etc)

Since this step is mainly for information exchange before Security is established, information/data carried by this step is not encrypted.

In terms of contents of the message, I think this step carries the most complicated data structure (ISAKMP format). One example of ISAKMP carried at Step 1a is as follows.

If you have wireshark log, you can easily look into the details of the data structure.. but to let you more familiar with format structure described in RFC 2408, I represented the data as follows. It is very complicated structure and of course you don't have to memorize this structure and value. Just look through the overall structure from the top to bottom and see what are main information/data being carried at this step.

Let's look into the details and functionalities of each part shown in the packet

This packet capture represents the initial stage of an Internet Key Exchange (IKE) negotiation, specifically IKE Phase 1.  IKE is the protocol used to establish a secure tunnel in IPsec Virtual Private Networks (VPNs).  The captured packets reveal the following key aspects of this negotiation:

• Security Association Establishment:
• One device is initiating the process of establishing a secure channel (IKE SA) by proposing cryptographic algorithms and parameters.
• It suggests using AES encryption, HMAC-SHA1 for integrity checks, and a specific Diffie-Hellman group for generating the shared secret key.
• NAT Traversal:
• The devices are exchanging information to detect and accommodate the presence of Network Address Translation (NAT) devices in the network path. This is crucial for IPsec VPNs to function correctly in real-world scenarios where NAT is common.
• Vendor Identification:
• One device is optionally sharing some information about itself (Vendor ID), potentially for compatibility or feature negotiation purposes.
• Packet Breakdown
• ISAKMP Header:
• Identifies this as an ISAKMP packet, the foundation of IKE, and indicates it is a request to establish a Security Association.
• Key Exchange Payload:
• Carries the parameters for the key exchange process that will generate the shared secret for the IKE SA.
• Security Association Payload:
• Defines the proposed cryptographic algorithms and parameters (encryption, integrity, PRF, DH group) for protecting the IKE SA.
• Notify Payload:
• Conveys informational messages, including nonces for replay protection and NAT detection information.
• Vendor ID Payload:
• Provides vendor-specific information.
• NONE Payload:
• May be a placeholder or indicate the end of a particular set of payloads.
• Summary
• One device is saying, "Let's set up a secure connection!"
• It's suggesting specific security methods and also checking if there are any NAT devices that could cause problems.
• It might also be sharing some information about itself to help with compatibility.
• This is just the first step, and more messages will be exchanged before the secure connection is fully established.

Step 2~6 :  Auth request/response for AAA

This step corresponds to Step 3~4 of RFC 4306.

At step 2,

This is an IKEv2 authentication request message that is part of the process of establishing a secure connection (likely an IPsec VPN) between two entities. It includes various payloads for identification, security association setup, traffic selection, and configuration exchange.  This message represents a crucial step in establishing a secure connection. The initiator is authenticating itself, requesting a certificate, proposing security parameters, defining traffic selectors, and requesting configuration information from the responder. This exchange sets the stage for the finalization of the IKE SA and the subsequent establishment of the IPsec tunnel.

UE sends following ID.

• IDi = user ID (in the format of of NAI, 3GPP 23.003 19.3)
• IDr = APN Information

UE begins negotiation of child security association

UE shall send configuration payload (CFG_REQUEST) to abtain IPv4 and/or IPv6 home IP address and/or Home Agent Address

Following is one example of CFG_REQUEST from RFC 4306 2.19.  Requesting an Internal Address on a Remote Network

CP(CFG_REQUEST)=

INTERNAL_ADDRESS(0.0.0.0)

INTERNAL_NETMASK(0.0.0.0)

INTERNAL_DNS(0.0.0.0)

TSi = (0, 0-65535,0.0.0.0-255.255.255.255)

TSr = (0, 0-65535,0.0.0.0-255.255.255.255)

 

Note : format of TSi, TSr is (protocol, port range, address range)

Following is one example of Wireshark log for this step.

Followings are the contents of this message

• IKE Authentication Request:
• Exchange type: IKE_AUTH (35) indicates this is an IKE_AUTH request message, the second step in IKE Phase 1.
• Flags: 0x08 signifies that this is a request message initiated by the initiator.
• Encrypted and Authenticated Payload:
• This payload encapsulates the sensitive information exchanged in this message, protecting it with encryption and integrity checks.
• Identification:
• The initiator identifies itself using an email-like ID (000101010123456789@nai.epc.mnc001.mcc001.3gppnetwork.org) and requests a certificate from the responder.
• The responder is identified using a KEY_ID, which is "ims" in this case (likely an APN name).
• Configuration:
• The initiator is requesting configuration information from the responder, such as IP addresses, subnet masks, and DNS server addresses.
• Security Association:
• The initiator proposes security parameters for the IPsec Encapsulating Security Payload (ESP), including encryption (ENCR_AES_CBC), integrity (AUTH_HMAC_SHA1_96 or AUTH_HMAC_SHA2_256_128), and ESN (Extended Sequence Number) handling.
• Traffic Selectors:
• Both the initiator and responder specify the traffic to be protected by the IPsec SA, which in this case appears to be all IPv4 and IPv6 traffic.

At step 3,

ePDG take out the information from the information (e.g, User ID, APN Info) at step 2 and send it to AAA Server

AAA Server identity the user

combined authentication and authorization is performed for tunnel establishment with ePDG.

At step 4,

AAA Server

• fetch the user profile and authentication vector from HSS/HLR if these parameters are not avaialable in the AAA server
• look up the IMSI of the authenticated user based on the recieved user ID (root NAI)

HSS

• generate authentication vectors with AMF sepration bit = 0 and send them back to AAA Server

AAA Server

• checks if the UE is authorized for non-3GPP access

At Step 5,

AAA Server initiate the authentication challenge. In this case, user identity is not requested.

At Step 6,

This is an IKEv2 authentication response message where the responder (likely an ePDG, Evolved Packet Data Gateway) authenticates itself using a digital signature and initiates an EAP-AKA authentication exchange with the initiator. This message is a crucial step in establishing trust between the initiator and the ePDG. The responder proves its own identity using a certificate and digital signature, and then challenges the initiator to prove its identity using EAP-AKA. This mutual authentication process is essential for securing the IKE SA and proceeding to establish a secure IPsec connection.

ePDG send the response to UE with ePDG identity, certificate and send AUTH parameter to protect the previous message in IKE_SA_INIT exchange.

EAP message (EAP Request/Ack Challenge) received from AAA Server is also included in this response in order to start the EAP proecedure over IKEv2.

 

Followings are the contents of this message

• IKE Authentication Response:
• Exchange type: IKE_AUTH (35) and Flags: 0x20 indicate this is an IKE_AUTH response message, the third step in IKE Phase 1.
• Encrypted and Authenticated Payload:
• This payload protects the sensitive information exchanged in this message.
• Identification:
• The responder identifies itself using an FQDN (Fully Qualified Domain Name): epdg.epc.mnc260.mcc310.pub.3gppnetwork.org, suggesting it's an ePDG in a mobile network.
• Certificate:
• The responder provides its X.509 certificate, which contains its public key and other identifying information, allowing the initiator to verify its authenticity.
• Authentication:
• The responder authenticates itself using an RSA digital signature, proving it possesses the private key corresponding to the certificate.
• EAP-AKA Challenge:
• The responder initiates an EAP-AKA (Extensible Authentication Protocol - Authentication and Key Agreement) exchange to authenticate the initiator. It sends an AKA-Challenge containing:
• AT_RAND: A random challenge value.
• AT_AUTN: Authentication token.
• AT_MAC: Message authentication code to protect the integrity of the challenge.

Step 7~11 :  Auth request/response for RES/XRES Verification

This step corresponds to Step 5~6 of RFC 4306.

At Step 7,

UE checks the authentication parameters and responds to the authentication challenge. (The only payload in this IKEv2 message is the EAP message)

This is an IKEv2 authentication request message where the initiator responds to the EAP-AKA challenge issued by the responder (likely an ePDG) in a previous message.

This message is a crucial step in the mutual authentication process between the initiator and the responder. The initiator is providing its calculated response to the EAP-AKA challenge, allowing the responder to verify its identity and proceed with the IKE SA establishment.

Followings are the contents of this message

• IKE Authentication Request:
• Exchange type: IKE_AUTH (35) and Flags: 0x08 indicate this is an IKE_AUTH request, continuing the authentication exchange in IKE Phase 1.
• Encrypted and Authenticated Payload:
• This payload protects the sensitive authentication information.
• EAP-AKA Challenge Response:
• This is the core of the message. The initiator is responding to the EAP-AKA challenge issued by the responder. The payload includes:
• EAP-AKA Subtype: AKA-Challenge (1): This indicates a response to an AKA challenge.
• AT_RES: The "result" parameter, containing the initiator's calculated response to the challenge.
• AT_MAC: The message authentication code, ensuring the integrity and authenticity of the response.

At Step 8,

ePDG forward the EAP-Response/AKA-Challenge message to AAA Server

At Step 9,

AAA Server sends the final Authentication and Authorization answer to ePDG with the MSK (key material)

At Step 10,

ePDG generate AUTH parameter using the MSK from AAA Server in order to authenticate the IKE_SA_INIT phase messages (These two messages had not been authenticated up to this point since there was no key material available yet.

At Step 11,

ePDG forwards EAP Success/Failure message to the UE

This is an IKEv2 authentication response message where the responder (likely an ePDG) signals the successful completion of the EAP authentication exchange.

This message marks the successful completion of mutual authentication between the initiator and the responder (ePDG) in IKE Phase 1. They can now proceed to negotiate the security parameters for the IPsec tunnel in IKE Phase 2.

Followings are the contents of this message

• IKE Authentication Response:
• Exchange type: IKE_AUTH (35) and Flags: 0x20 indicate this is an IKE_AUTH response message, part of the IKE Phase 1 authentication exchange.
• Encrypted and Authenticated Payload:
• This payload protects the sensitive authentication information.
• EAP Success:
• This is the core of the message. The EAP-Success code indicates that the EAP authentication exchange, initiated by the responder in a previous message, has concluded successfully. This means both sides have successfully proven their identities to each other.

Step 12~15 :  Auth request/response for AUTH Verification

This step corresponds to Step 7~8 of RFC 4306.

At Step 12,

UE generate AUTH parameter using its own copy of MSK in order to authenticate the first IKE_SA_INIT message and this AUTH is sent to ePDG

This is an IKEv2 authentication request message where the initiator authenticates itself to the responder using a shared key message integrity code (likely a pre-shared key). This message is typically one of the final steps in the IKE Phase 1 authentication exchange.

This message represents the initiator's attempt to prove its identity to the responder using a pre-shared key. If the responder has the same pre-shared key and can successfully verify the authentication data, it will consider the initiator authenticated. This successful mutual authentication allows the IKE SA to be established, and the peers can proceed to IKE Phase 2 for IPsec SA negotiation.

Followings are the contents of this message

• IKE Authentication Request:
• Exchange type: IKE_AUTH (35) and Flags: 0x08 indicate this is an IKE_AUTH request message, part of the IKE Phase 1 authentication exchange.
• Encrypted and Authenticated Payload:
• This payload protects the sensitive authentication information.
• Authentication Payload:
• This is the core of the message. The initiator is authenticating itself to the responder using a pre-shared key. The payload includes:
• Authentication Method: Shared Key Message Integrity Code (2): This indicates that a pre-shared key is used for authentication.
• Authentication Data: This contains the calculated message integrity code, generated using the pre-shared key and other message components.

At Step 13,

ePDG checks if the AUTH from UE is correct or not.

At Step 14,

ePDG calculate the AUTH parameter to authenticate the second IKE_SA_INIT message.

 

At Step 15,

ePDG send

• AUTH Parameter calculated at step 14
• the assigned Remote IP address in the configuration payload (CFG_REPLY)
• Security Associations
• the rest of the IKEv2 parameters

Following is one example of CFG_REPLY from RFC 4306 2.19.  Requesting an Internal Address on a Remote Network

CP(CFG_REPLY)=

INTERNAL_ADDRESS(192.0.2.202)

INTERNAL_NETMASK(255.255.255.0)

INTERNAL_SUBNET(192.0.2.0/255.255.255.0)

TSi = (0, 0-65535,192.0.2.202-192.0.2.202)

TSr = (0, 0-65535,192.0.2.0-192.0.2.255)

 

Note : format of TSi, TSr is (protocol, port range, address range)

This is an IKEv2 authentication response message where the responder finalizes the IKE Phase 1 exchange by authenticating itself, providing configuration details to the initiator, and establishing the parameters for the IPsec Security Associations (SAs).

This message completes the IKE Phase 1 exchange. The responder authenticates itself, provides configuration details, and confirms the IPsec SA parameters. This establishes the secure IKE SA, allowing the peers to move on to IKE Phase 2 for Child SA negotiation and secure data transfer.

Followings are the contents of this message

• IKE Authentication Response:
• Exchange type: IKE_AUTH (35) and Flags: 0x20 indicate this is an IKE_AUTH response, the final step in IKE Phase 1.
• Encrypted and Authenticated Payload:
• This payload protects the sensitive information exchanged in this message.
• Authentication:
• The responder authenticates itself using a shared key message integrity code, likely based on a pre-shared key.
• Configuration:
• The responder provides configuration information to the initiator, including:
• INTERNAL_IP4_ADDRESS: An IPv4 address (192.168.1.11) assigned to the initiator within the VPN.
• INTERNAL_IP4_NETMASK: The subnet mask (255.255.255.0) for the assigned IP address.
• INTERNAL_IP4_DNS: IPv4 addresses (192.168.1.12) of DNS servers.
• PRIVATE USE: This likely carries additional vendor-specific configuration data.
• Security Association:
• The responder confirms the security parameters for the IPsec ESP (Encapsulating Security Payload), including:
• ENCR_AES_CBC: Encryption algorithm with a 256-bit key.
• AUTH_HMAC_SHA1_96: Integrity algorithm.
• No ESNs: No Extended Sequence Numbers will be used.
• Traffic Selectors:
• Both the initiator and responder specify the traffic to be protected by the IPsec SA, which appears to be traffic within the subnet 192.168.1.0/24.
• Notify Payloads:
• While the specific notify message types are not shown, these payloads might carry additional information or status updates.

IKEv2 Parameter Details

If you are interested in the full details of the each of the parameters getting involved in IKEv2 process, refer to RFC7296. I will summarize on some of the important parameters later.

Deleting a SA

RFC 5996

1.4.  The INFORMATIONAL Exchange

1.4.1.  Deleting an SA with INFORMATIONAL Exchanges

Similar to ESP and AH SAs, IKE SAs are also deleted by sending an Informational exchange.

Deleting an IKE SA implicitly closes any remaining Child SAs negotiated under it.

The response to a request that deletes the IKE SA is an empty INFORMATIONAL

 

Example >

i) A party send Informational Request (A) with a specific message ID (B) with Delete (C) payload.

ii) The other party send Informational Response (D) with the same message ID (E) with emtpy (F) payload

< sending an Informational request with 'Delete' Payload >

 

< sending an Informational response with 'empty' Payload >

DPD (Dead Peer Detection)

DPD stands for Dead Peer Detection. You can interpret this in two ways as follows.

i) A mechanism that can detect a Peer (the other party of communication) that is dead

ii) A mechanism to check whether a Peer (the other party of communication) is dead or alive.

How can a device or a server can do DPD ?

The method is very simple. It just sends 'INFORMATION' message with empty next payload (Next Payload : NONE) and waits for the same type of INFORMATION message from the other party. If it recieves the response, it consider that the other party is alive. If not, it considers the other party is dead. If it does not get any response for a certain duration, it usually delete the existing SA.

Notation

• HDR (Header) is an ISAKMP header whose exchange type is the mode. When writen as HDR* it indicates payload encryption.
• SA (Security Association) is an SA negotiation payload with one or more proposals. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one
• KE is the key exchange payload which contains the public information exchanged in a Diffie-Hellman exchange. There is no particular encoding (e.g. a TLV) used for the data of a KE payload.
• Nx is the nonce payload;
• x can be: i or r for the ISAKMP(Internet Security Association and Key Management Protocol) initiator and responder respectively.
• IDx is the identification payload for "x".
• x can be: "ii" or "ir" for the ISAKMP initiator and responder respectively during phase one negotiation; or "ui" or "ur" for the user initiator and responder respectively during phase two.
• SIG is the signature payload. The data to sign is exchange- specific.
• CERT is the certificate payload
• CERTREQ Certificate Request
• CP Configuration
• EAP Extensible Authentication
• AUTH Authentication
• TSi Traffic Selector - Initiator
• TSr Traffic Selector - Responder

Appendix

< ISAKMP Header Format >

The ISAKMP Header is the foundational structure of every ISAKMP message. It serves as the "envelope" that encapsulates various payloads (like the Security Association Payload we discussed earlier) and provides essential control information for managing security associations.

The ISAKMP Header provides the essential framework for organizing and interpreting ISAKMP messages. It ensures that the communicating parties can identify the messages, understand their purpose within the SA negotiation, and process the enclosed payloads correctly.

Think of it as the header on a letter, indicating the sender, recipient, and the type of content enclosed.

   (Refer to RFC 2408 for details)

Followings are brief description of each field :

• Initiator Cookie:
• A random value generated by the initiator (the entity initiating the ISAKMP exchange).
• It helps uniquely identify the SA negotiation and prevent replay attacks.
• Responder Cookie:
• A random value generated by the responder in response to the initiator's cookie.
• It serves a similar purpose to the Initiator Cookie in terms of identification and security.
• Next Payload:
• Indicates the type of the first payload carried within this ISAKMP message.
• Its value corresponds to one of the "Next Payload Type" values listed in the table (e.g., 'SA' for Security Association, 'KE' for Key Exchange, etc.).
• Major Version (MjVer) & Minor Version (MnVer):
• Specify the version of the ISAKMP protocol being used.
• Exchange Type:
• Defines the specific type of exchange this ISAKMP message belongs to.
• The table lists various exchange types like 'Base', 'Identity Protection', 'Authentication Only', etc., each serving a distinct purpose in the SA negotiation process.
• Flags:
• Individual bits within this field convey additional control information.
• The table explains the meaning of the first few bits (Encryption, Commit, Authentication Only), which can indicate specific characteristics or requirements for the SA.
• Message ID:
• A unique identifier assigned to this ISAKMP message.
• Useful for tracking and correlating messages within an exchange, especially in cases of retransmission or out-of-order delivery.
• Length:
• Specifies the total length of the entire ISAKMP message, including the header and all the payloads it carries.

< Security Association (SA) Payload >

The Security Association (SA) Payload is a critical component within ISAKMP (and consequently, IKE) messages. Its primary function is to propose, negotiate, or define the specific security parameters and algorithms that will be used to protect the communication channel established between two entities.

The SA Payload is the negotiation table where the two communicating parties lay out their security requirements and preferences. By exchanging and agreeing upon the parameters within these payloads, they establish a mutually acceptable and secure foundation for their communication.

Think of it as the blueprint for the secure tunnel they are building. It dictates how data will be encrypted, integrity checks will be performed, and what keying material will be used.

(Refer to RFC 2408 for details)

Followings are brief description of each field :

• Next Payload:
• This field indicates the type of payload that follows the SA Payload in the ISAKMP message. It helps the receiver understand how to interpret the subsequent data.
• Its value is chosen from the "Next Payload Type" table shown in the original ISAKMP header image you provided.
• RESERVED:
• As the name suggests, this field is reserved for future use and should be set to zero.
• Payload Length:
• Specifies the total length of the entire SA Payload, including the header and all the Situation substructures it contains.
• Domain of Interpretation (DOI):
• Identifies the specific security domain or protocol to which this SA Payload applies.
• Different DOIs may have their own unique set of Situation types and meanings.
• For example, in the context of IKE, the DOI value would likely indicate that the SA Payload is relevant to the IKE protocol itself (for Phase 1) or to the IPsec protocols (for Phase 2).
• Situation:
• This is where the core security parameters and proposals are defined.
• The SA Payload can contain one or more Situation substructures, each representing a specific security proposal or a set of related parameters.
• The format and content of the Situation substructures can vary based on the DOI.
• Generally, they will include details like:
• The type of proposal (e.g., encryption, authentication, key exchange)
• The specific algorithms and their modes of operation
• Key lengths or other relevant parameters

< Key Exchange (KE) Payload >

The Key Exchange (KE) Payload's core purpose is to facilitate the secure exchange of keying material between two communicating entities. This keying material is crucial for establishing a shared secret key, which will then be used to encrypt and decrypt data in the subsequent secure communication channel (e.g., an IPsec VPN tunnel).

The KE Payload is where the "secret handshake" happens. It enables the two parties to securely exchange the necessary information to derive a shared secret key, forming the basis for their subsequent encrypted communication.

(Refer to RFC 2408 for details)

Followings are brief description of each field :

• Next Payload:
• Similar to other ISAKMP payloads, this field indicates the type of payload that follows the KE Payload in the message.
• It guides the receiver on how to interpret the subsequent data.
• RESERVED:
• Reserved for future use and should be set to zero.
• Payload Length:
• Specifies the total length of the entire KE Payload, including the header and all the Key Exchange Data it contains.
• Key Exchange Data:
• This is the heart of the KE Payload, where the actual key exchange information resides.
• This is the data required to generate a session key.  The interpretation of this data is specified by the DOI and the associated Key Exchange algorithm.  This field may also contain pre-placed key indicators.
• The specific content and format of this data depend on the chosen key exchange method.
• Common examples include:
• Diffie-Hellman (DH) public values: Each party shares its DH public value, allowing them to calculate a shared secret key.
• RSA public keys: Used in certain key exchange or authentication schemes.

< Nonce (N) Payload >

The Nonce Payload plays a vital role in enhancing the security of IKE (Internet Key Exchange) negotiations. Its primary function is to provide protection against replay attacks.

The Nonce Payload acts as a "fingerprint" for an IKE message, ensuring its uniqueness and freshness. By incorporating this random value, IKE negotiations become more resilient against replay attacks, enhancing the overall security of the process.

A replay attack is when an attacker captures a legitimate message and maliciously retransmits it later, potentially tricking the receiver into performing unintended actions or revealing sensitive information. The Nonce Payload helps thwart such attacks by incorporating a unique, random value (the nonce) into the IKE message.

The reason/way how nonce can prevent replay are :

• Uniqueness: The sender generates a fresh, random nonce for each IKE message.
• Verification: The receiver checks if it has seen this particular nonce before. If it has, it likely indicates a replay attempt, and the message is discarded.
• Freshness: The use of nonces also contributes to ensuring the freshness of messages, making it harder for an attacker to reuse old, captured messages.

(Refer to RFC 2408 for details)

Followings are brief description of each field :

• Next Payload:
• This field, as in other ISAKMP payloads, specifies the type of payload that follows the Nonce Payload.
• RESERVED:
• Reserved for future use and should be set to zero.
• Payload Length:
• Indicates the total length of the entire Nonce Payload, including the header and all the Nonce Data it contains.
• Nonce Data:
• This field houses the actual random data (the nonce) generated by the sender.
• Nonce Data can be of variable length, accommodating different security requirements or implementations.

< Identification (ID) Payload >

The Identification (ID) Payload serves the crucial purpose of allowing entities involved in an IKE negotiation to identify and authenticate each other.

The ID Payload acts as a form of "digital identification card" within IKE messages. It allows entities to assert their identities and enables the establishment of secure connections based on trust and policy enforcement.

It essentially answers the question, "Who are you?" in the context of establishing a secure communication channel.

How Identification Helps:

• Authentication: By exchanging and verifying identification information, the entities can gain confidence in each other's identities, which is crucial for establishing trust in the secure communication channel.
• Policy Enforcement: The identities can be used to enforce security policies, ensuring that only authorized entities are allowed to participate in the IKE negotiation and subsequent IPsec communication.

(Refer to RFC 2408 for details)

Followings are brief description of each field :

• Next Payload:
• As with other ISAKMP payloads, this field points to the type of payload that follows the ID Payload.
• RESERVED:
• Reserved for future use; should be set to zero.
• Payload Length:
• Specifies the total length of the entire ID Payload, including the header and all the identification data it carries.
• ID Type:
• This field indicates the format and type of identification information being conveyed in the payload.
• Different ID types exist, such as:
• IP Address
• Fully Qualified Domain Name (FQDN)
• Key ID
• And others, depending on the specific DOI (Domain of Interpretation)
• DOI Specific ID Data:
• A 3-byte field that can carry additional identification data specific to the DOI.
• If not used, it must be set to zero.
• Identification Data:
• This field contains the actual identity information, whose format and content are determined by the ID Type field.
• For example, if ID Type is set to "IP Address," this field would contain the IP address of the entity.
• The Identification Data can be of variable length to accommodate different types of identifiers.

< Proposal Payload >

The Proposal Payload is a key component in the negotiation process of IKE (Internet Key Exchange) and ISAKMP. Its main function is to present a set of security proposals, offering options for cryptographic algorithms and parameters that could be used to establish a Security Association (SA).

The Proposal Payload is like a menu of security options. It presents one or more proposals, each with a set of cryptographic algorithms and parameters (defined in the Transform Payloads). The other side in the negotiation can then select one of these proposals or counter with its own, leading to an agreement on the final security settings for the SA.

Think of it as one side in a negotiation presenting their "wish list" of security features they'd prefer to use for the secure communication channel.

(Refer to RFC 2408 for details)

Followings are brief description of each field :

• Next Payload:
• This field, as usual in ISAKMP payloads, indicates the type of payload that follows the Proposal Payload in the message.
• RESERVED:
• Reserved for future use and should be set to zero.
• Payload Length:
• Specifies the total length of the entire Proposal Payload, including the header and any additional data it carries (like the SPI and Transform payloads).
• Proposal #:
• Identifies the specific proposal within the ISAKMP message.
• Multiple Proposal Payloads can be included in a single message, each with a unique Proposal #.
• Proposal-Id:
• A numerical identifier assigned to this specific proposal.
• It aids in distinguishing between different proposals and referencing them during the negotiation.
• SPI Size:
• Indicates the size (in bytes) of the Security Parameter Index (SPI) field that follows.
• The SPI is a value used to identify a specific SA within a security association database.
• # of Transforms:
• Specifies the number of Transform Payloads associated with this proposal.
• Each Transform Payload details a specific combination of security algorithms and parameters.
• SPI (variable size):
• The Security Parameter Index, whose size is defined by the SPI Size field.
• It's a unique identifier for the SA being proposed.

< Transform Payload >

The Transform Payload is a crucial element within the IKE (Internet Key Exchange) and ISAKMP negotiation process. Its core purpose is to specify a particular combination of security algorithms and parameters that could be used to protect the communication channel.  

The Transform Payload is like a detailed ingredient list for a specific security recipe. It specifies the exact algorithms and their settings that will be used to provide confidentiality (encryption), integrity (authentication), or key exchange functionality within the Security Association.

Multiple Transform Payloads within a Proposal offer a range of options, allowing the negotiating parties to find a mutually agreeable combination of security mechanisms.

Think of it as a single "recipe" within a larger security proposal (represented by the Proposal Payload).

(Refer to RFC 2408 for details)

Followings are brief description of each field :

• Next Payload:
• As with other ISAKMP payloads, this field indicates the type of payload that follows the Transform Payload.
• RESERVED:
• Reserved for future use, should be set to zero.
• Payload Length:
• Specifies the total length of the entire Transform Payload, including the header and the SA Attributes.
• Transform #:
• Identifies the specific transform within the associated Proposal Payload.
• Multiple Transform Payloads can be included within a single Proposal, each with a unique Transform #.
• Transform-Id:
• A numerical identifier representing the specific type of transform being proposed.
• Examples include:
• Encryption algorithms (e.g., AES-CBC, 3DES)
• Integrity/authentication algorithms (e.g., HMAC-SHA1, HMAC-MD5)
• Diffie-Hellman groups for key exchange
• Compression algorithms
• RESERVED2:
• Another field reserved for future use, set to zero.
• SA Attributes:
• This field contains the specific parameters and attributes associated with the chosen transform.
• The content and format of these attributes depend on the Transform-Id.
• For example, for an encryption transform, it could include the key length or mode of operation.

< Notify Payload >

The Notify Payload serves as a versatile communication tool within IKE (Internet Key Exchange) and ISAKMP negotiations. It's designed to convey various informational or status messages between the communicating entities. These messages can range from error notifications and status updates to indications of feature support or specific requests.

The Notify Payload acts as a communication channel within IKE/ISAKMP messages, enabling the exchange of vital information and status updates that are essential for successful negotiation and establishment of secure communication channels.

Flexibility and Importance of the Notify are

• The Notify Payload's flexible nature makes it a vital tool for facilitating communication and coordination during the IKE/ISAKMP exchange. It allows the entities to:
• Signal Errors or Issues: If something goes wrong during the negotiation, a Notify Payload can be used to clearly indicate the problem, helping the other side understand and potentially recover from the error.
• Exchange Status Information: Notify Payloads can keep both sides informed about the progress of the negotiation, ensuring synchronization and smooth operation.
• Negotiate Additional Features: They can be used to signal support for or request specific features or capabilities, enhancing the flexibility and adaptability of the IKE/ISAKMP protocol.

(Refer to RFC 2408 for details)

Followings are brief description of each field :

• Next Payload:
• Consistent with other ISAKMP payloads, this field identifies the type of payload that follows the Notify Payload.
• RESERVED:
• Reserved for future use; should be set to zero.
• Payload Length:
• Specifies the total length of the entire Notify Payload, including the header and the specific Notify Payload data it carries.
• Notify Payload:
• This is where the actual notification or status information is contained.
• The structure and content of this field can vary significantly depending on the specific notify message being conveyed.
• Some common examples of notify messages include:
• Error notifications (e.g., invalid proposal, unsupported feature)
• NAT detection messages
• Configuration requests or acknowledgments
• Status updates during the IKE negotiation