IKE

Internet Key Exchange

Security →
Introduced in Rel-6 Also in: Core Network, Radio Access Network

IKE is the protocol used in 3GPP to establish secure, authenticated channels and negotiate Security Associations for IPsec, securing interfaces between network functions and user plane data.

Category
Security
Introduced
Rel-6
Where
Security
Also touches
2 segments
Specifications
17 specs
IKE Description Purpose Related Classification Detected Changes Specifications

Description

Internet Key Exchange (IKE), specifically IKEv1 and IKEv2 defined by the IETF (RFC 2409, RFC 7296), is a protocol used within 3GPP systems to automate the establishment of IPsec Security Associations (SAs). An SA defines the parameters for a secure IPsec tunnel, including the cryptographic algorithms (e.g., AES for encryption, SHA-256 for integrity), keys, and protocol mode (Transport or Tunnel). IKE performs mutual authentication between two peers, negotiates cryptographic suites, and securely establishes shared secret keys to be used by IPsec. It operates in two phases: Phase 1 establishes a secure, authenticated channel (the IKE SA) itself, and Phase 2 uses that channel to negotiate the IPsec SAs (often called Child SAs) that will protect the actual user or signaling data.

Within 3GPP architectures, IKE is a key component of Network Domain Security (NDS/IP), which secures communication between network nodes over IP-based interfaces. For example, it can be used to secure the N2 interface (between (R)AN and AMF) or the N3 interface (between (R)AN and UPF) in 5G systems when deployed over untrusted IP networks. The protocol supports various authentication methods referenced in 3GPP, including pre-shared keys (PSK) and digital certificates (often using X.509 certificates). IKE's Diffie-Hellman key exchange provides perfect forward secrecy (PFS), meaning compromise of a long-term key does not compromise past session keys.

The operation involves the exchange of IKE messages (usually over UDP port 500 or 4500 for NAT traversal). During Phase 1, peers agree on encryption and integrity algorithms for the IKE SA, perform a Diffie-Hellman exchange to generate a shared secret, and authenticate each other. This results in a set of keys used to protect subsequent IKE messages. In Phase 2, within the protection of the IKE SA, the peers negotiate the parameters for the IPsec SAs, including the traffic selectors that define which IP traffic flows the SA will protect. IKEv2 simplifies the process compared to IKEv1 by combining some steps. 3GPP specifications profile the use of IKE and IPsec, specifying mandatory-to-support algorithms and recommended authentication methods for different interfaces.

Purpose & Motivation

IKE was adopted in 3GPP to solve the problem of manually configuring and managing IPsec security associations, which is impractical and error-prone in large, dynamic mobile networks. As 3GPP networks evolved to all-IP architectures (from Release 5 onwards), signaling and user data traversed IP networks that could not be assumed to be physically secure (e.g., between different operator sites or across public internet segments). A standardized, automated mechanism was needed to provide hop-by-hop confidentiality, integrity, and authentication for this IP traffic.

The motivation stemmed from the limitations of relying on physical security or proprietary security solutions. IKE, as a mature IETF standard, provided a vendor-interoperable solution for dynamic key management. It addresses the specific requirements of mobile networks, such as the need to support frequent updates of security associations (e.g., during handovers or session modifications) and to integrate with network-based authentication (like using certificates issued by the operator). Its use in NDS/IP allows operators to build secure IP backbone networks interconnecting core network functions from different vendors and located in different physical locations, mitigating threats like eavesdropping, spoofing, and message modification on these critical internal interfaces.

Classification

Part ofIPSec
Related approachesNDS/IP

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (11 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-6, normative work from Rel-15.

Rel-15 4 changes

In Release 15, the IKE function was updated to clarify IPsec implementation requirements and to expand the scope of Network Domain Security for IP (NDS/IP) by supporting application layer crypto profiles. The release also enhanced general NDS/IP Security Gateway (SEG) support for non-Service-Based Architecture interfaces and provided corrections regarding physical protection notes for NDS/IP use.

  • Update NDS/IP scope with application layer crypto profiles TS 33.210CR0050
  • Clarification of the IPsec implementation requirements TS 33.501CR0208
  • Correction of Note on physical protection for NDS/IP use TS 33.501CR0331
  • General NDS/IP SEG support for non-SBA interfaces TS 33.501CR0642
Rel-16 2 changes

In Release 16, the IKE function was updated to expand the scope of Network Domain Security for IP (NDS/IP) to include application layer cryptographic profiles. This change provided a more comprehensive security framework for network composition. Additionally, the specifications underwent editorial corrections to improve clarity and consistency within the NDS/IP documentation.

  • Update NDS/IP scope with application layer crypto profiles TS 33.210CR0056
  • Editorial corrections to NDS/IP TS 33.210CR0068
Rel-17 2 changes

In Release 17, the IKE function was updated by modernizing its foundational IPsec references. Specifically, the obsolete RFC 7296 reference was replaced with RFC 8247, and other IPsec references were updated to RFC 8221, ensuring the specification aligns with current IETF standards for secure connection establishment between networks.

  • Update IPSec references to rfc8221 TS 33.210CR0073
  • Update IPSec reference from obsolete RFC 7296 to RFC 8247 TS 33.210CR0074
Rel-18 2 changes

In Release 18, the IKE function was enhanced to specifically address the protection of data and analytics exchange in roaming scenarios. The updates included editorial corrections and clarifications to the established procedure for securing this analytics exchange between networks. This refinement ensures a consistent and secure method for the automated negotiation and establishment of secure connections, such as IPSec tunnels, between composing networks under roaming agreements.

  • Editorial change on procedure for protection of analytics exchange in roaming case TS 33.501CR1919
  • Correction on Protection of Data and Analytics Exchange in Roaming Case TS 33.501CR1822
Rel-19 1 change

In Release 19, the IKE function was enhanced to support a reauthentication aspect for IPSec in non-3GPP access. This update facilitates secure, automated network composition and interworking connectivity between 3GPP and other networks. The change enables the maintenance of secure connections and the exchange of AAA information, such as accounting data, during these automated compositions.

  • Reauthentication aspect for IPSec in non 3GPP access TS 33.501CR2055

Explore further

Broader topics and technologies where IKE plays a role.

Defining Specifications

3GPP specifications that define or reference IKE, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 22.980 vj00 Network Composition Feasibility Study Rel-19
TS 24.234 vc20 3GPP-WLAN Interworking Network Selection Rel-12
TS 29.368 vj00 Tsp Reference Point Stage 3 Specification Rel-19
TS 33.102 vj10 3G Security Architecture Specification Rel-19
TS 33.117 vk00 Catalogue of General Security Assurance Requirements Rel-20
TS 33.203 vj10 IMS Security Specification Rel-19
TS 33.210 vj20 UMTS Security for IP Networks Rel-19
TS 33.234 vj00 3GPP-WLAN Interworking Security Rel-19
TS 33.320 vj00 H(e)NB Subsystem Security Architecture Rel-19
TS 33.401 vj10 EPS Security Architecture Rel-19
TS 33.501 vk00 5G Security Architecture and Procedures Rel-20
TS 33.545 vj20 Security for NR Femto Subsystem Rel-19
TS 33.820 v1830 Home NodeB/eNodeB Security Architecture Rel-8
TR 33.938 vj10 3GPP Cryptographic Inventory for 5G Rel-19
TS 36.463 vj00 XwAP Protocol Specification Rel-19
TS 43.318 vj00 Generic Access Network (GAN) Stage 2 Rel-19
TR 43.902 vj00 GAN Enhancements Feasibility Study Rel-19