Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · Security

IKE

Internet Key Exchange

Security →

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.

Introduced
Rel-6
Where
Security
Specifications
17 specs
Also in
Radio Access Network, Core Network
IKE Description Purpose What changed Neighbours 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.

What changed in its specifications

The latest release-to-release comparison of specifications that define IKE. Each summary describes the whole specification, not only this term.

TS 24.234Rel-9 → Rel-10

Formalization of WLAN files adds optional WLAN parameter storage and new direct access conditions to HPLMN, affecting selection procedures.

Full comparison in TS 24.234 →
TS 29.368Rel-11 → Rel-12

Rel-12 adds device trigger recall and replace procedures, new AVPs, and new signalling flows over Tsp for MTCe enhancements.

Full comparison in TS 29.368 →

Evolution Across Releases

An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.

Rel-6 Initial

IKE was introduced in 3GPP Release 6 as a core component of the Network Domain Security for IP-based protocols (NDS/IP) framework. It was specified as the key management protocol for dynamically setting up IPsec security associations to protect signaling and user plane traffic between network elements within and between security domains.

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 read
TS 24.234 vc20 3GPP-WLAN Interworking Network Selection Rel-12 read
TS 29.368 vj00 Tsp Reference Point Stage 3 Specification Rel-19 read
TS 33.102 vj10 3G Security Architecture Specification Rel-19 read
TS 33.117 vk20 Catalogue of Security Requirements and Tests Rel-20 read
TS 33.203 vk00 IMS Security Features and Mechanisms Rel-20 read
TS 33.210 vk00 Network Domain Security for IP Networks Rel-20 read
TS 33.234 vj00 3GPP-WLAN Interworking Security Rel-19 read
TS 33.320 vj00 H(e)NB Subsystem Security Architecture Rel-19 read
TS 33.401 vj20 EPS Security Architecture Rel-19 read
TS 33.501 vk30 5G Security Architecture Rel-20 read
TS 33.545 vk10 NR Femto Security Architecture Rel-20 read
TS 33.820 v830 H(e)NB Security Threats and Countermeasures Rel-8 read
TS 33.938 vj30 5G Standalone Cryptographic Inventory Rel-19 read
TS 36.463 vj00 XwAP Protocol Specification Rel-19 read
TS 43.318 vj00 Generic Access Network (GAN) Stage 2 Rel-19 read
TR 43.902 vj00 GAN Enhancements Feasibility Study Rel-19 read