AKA

Authentication and Key Agreement

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

AKA is the fundamental 3GPP security protocol for mutual authentication between a user's device and the network and for establishing session keys to encrypt and protect communications.

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

Description

The Authentication and Key Agreement (AKA) protocol is a challenge-response mechanism that provides mutual authentication and cryptographic key derivation in 3GPP networks. It operates between the User Equipment (UE) and the network's Authentication Centre (AuC), which resides within the Home Subscriber Server (HSS) in 4G/5G or the Home Location Register (HLR) in 3G. The core of AKA is a shared secret key (K), which is securely stored in both the UE's Universal Subscriber Identity Module (USIM) and the AuC. This long-term key is never transmitted over the air.

The protocol execution begins when the serving network requests authentication vectors from the HSS/AuC. The AuC generates one or more authentication vectors using the subscriber's key K and a sequence number (SQN). Each vector contains a random challenge (RAND), an expected response (XRES), a cipher key (CK), an integrity key (IK), and an authentication token (AUTN). The AUTN itself contains the SQN and a Message Authentication Code (MAC), which allows the UE to verify the network's authenticity. The serving network (e.g., via the MME in 4G or AMF in 5G) sends the RAND and AUTN to the UE.

Upon receipt, the USIM in the UE uses its stored key K and the received RAND to compute its own version of the expected response (RES), cipher key (CK), integrity key (IK), and the MAC. It first verifies the AUTN by checking the MAC to ensure the challenge originated from a genuine network and by checking the SQN to ensure it is fresh and not a replay of an old authentication. If successful, the UE sends the RES back to the network. The network compares the received RES with the XRES; a match completes mutual authentication. The derived CK and IK are then used by the UE and the network's access stratum to enable confidentiality and integrity protection for all subsequent signaling and user data traffic.

AKA's design is robust, providing key separation—different keys are derived for different purposes (ciphering, integrity) and different network domains (access stratum, non-access stratum). It also supports synchronization mechanisms to handle cases where the sequence numbers in the UE and AuC become mismatched. In 5G, AKA was enhanced to 5G AKA, which includes improved home network control, the derivation of a anchor key (KAUSF) for better key hierarchy, and the inclusion of the serving network name in key derivation to bind keys to a specific network, mitigating certain attack vectors. The protocol's execution is transparent to the user but is triggered during initial network attachment, handovers between different core network types, or periodically for re-authentication.

Purpose & Motivation

AKA was created to address critical security shortcomings in predecessor cellular systems, most notably the weak and one-way authentication in GSM. In GSM, only the network authenticated the user, leaving it vulnerable to fake base station (IMSI catcher) attacks. Furthermore, GSM's encryption algorithms and key lengths were eventually found to be cryptographically weak. The primary purpose of AKA, introduced with 3G (UMTS), was to establish strong, mutual authentication and to generate robust, session-specific cryptographic keys to ensure both confidentiality and integrity of communications.

The protocol solves the problem of securely bootstrapping a trusted session in a hostile radio environment. It ensures that a user is connecting to a legitimate, authorized network and not a malicious impersonator, while simultaneously proving to the network that the user is a valid subscriber. This mutual trust is foundational for all other security services. By deriving fresh, ephemeral cipher and integrity keys (CK/IK) from a long-term secret for every authentication instance, AKA limits the impact of a potential key compromise and provides forward secrecy for user data within a session.

Historically, the development of AKA was motivated by the need for a standardized, future-proof security foundation that could evolve with network generations. Its design incorporated lessons from GSM and fixed-line authentication protocols. The use of a sequence number (SQN) mechanism, while introducing complexity for synchronization, was a deliberate choice to provide replay protection and enable the home network to maintain state. AKA's purpose has expanded from 3G to form the bedrock of the 3GPP security architecture, being adapted and enhanced in each subsequent generation (EPS-AKA for 4G, 5G AKA for 5G) to address new threats like linkability of subscribers and to support new architectural paradigms like network slicing and separation of the control and user planes.

Classification

Part ofHSS

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (243 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 74 changes

In Release 15, key enhancements to the AKA function included the addition of the ABBA parameter to the 5G primary authentication procedure and the introduction of a stage 2 solution for Steering of Roaming (SOR) based on authentication during registration. The release also provided clarifications and corrections for the EAP-based primary authentication procedure and specified rules for the concurrent running of authentication and NAS security mode control procedures. Furthermore, it standardized the authentication response parameter information element to be of a fixed length.

  • UE configuration for NAS signalling low priority via OMA-DM or USIM not applicable in 5GS TS 24.501CR0084
  • Preferred list terminating at ME or USIM TS 24.501CR0212
  • Stage 2 solution of Steering Of Roaming (SOR) based on Authentication procedure during Registration (Alternative 3) TS 24.890CR0013
  • Rules on concurrent running of authentication and NAS SMC procedure TS 33.501CR0004
  • Clarifications to: Protection at the network or transport layer, Authorization and authentication between network functions and the NRF TS 33.501CR0147
  • Baseline CR for June version of RAN2 TS 38.300 (RAN3 part) covering agreements of RAN3#100 TS 38.300CR0041

+ 68 more changes

Rel-16 49 changes

In Release 16, the AKA function was enhanced to support network slice-specific authentication and authorization, including procedures for failure and revocation, and introduced the use of a pending NSSAI. It also expanded primary authentication to formally support EAP methods beyond EAP-AKA' and EAP-TLS, and added specific handling for authentication in Restricted Local Operator Services (RLOS) scenarios. Furthermore, the release defined new authentication procedures for indirect communication and for devices accessing the 5G Core (N5GC).

  • Authentication and security handling for restricted local operator services TS 24.301CR3162
  • Abnormal case handling when authentication is not accepted TS 24.301CR3193
  • RLOS integrity and authentication handling TS 24.301CR3266
  • Authentication and security handling for RLOS TS 24.301CR3334
  • Slice-specific authentication and authorization procedure TS 24.501CR1450
  • Primary authentication using EAP methods other than EAP-AKA' and EAP-TLS TS 24.501CR1510

+ 43 more changes

Rel-17 85 changes

In Release 17, key AKA enhancements included the introduction of Authentication and Key Management for Applications (AKMA) and new procedures for Multi-USIM UEs, such as using the Service Request to remove paging restrictions. The release also expanded authentication methods by defining EAP-TTLS with two phases of authentication and specifying authentication and key agreement for 5G ProSe UE-to-network relays. Furthermore, it introduced the usage of an indication to derive KAUSF from an MSK following a successful primary authentication and key agreement procedure.

  • Update of HTTP Digest Access Authentication and reference update for HTTP/1.1 protocol TS 24.109CR0069
  • GBA-based shared secret with PSK authentication in TLS 1.3 TS 24.109CR0071
  • Using Service Request procedure for removing paging restrictions in EPS for a Multi-USIM UE TS 24.301CR3517
  • Leaving procedure and Reject Paging Indication for Multi-USIM UEs in EPS TS 24.301CR3534
  • Multi-USIM UE support indications in EPS TS 24.301CR3514
  • UUAA re-authentication, re-authorization, and revocation TS 24.301CR3628

+ 79 more changes

Rel-18 28 changes

In Release 18, the AKA function was extended to support new scenarios including the authentication of AUN3 devices behind a Residential Gateway (RG) and the authentication and key agreement procedure for 5G ProSe UE-to-UE relays. It also introduced the Home Network triggered primary authentication procedure and clarified the handling of authentication failures, such as defining a specific ESM cause for user authentication or authorization failure. Additionally, enhancements were made for scenarios involving Non-Seamless WLAN Offload (NSWO) and for the mutual authentication between network functions using the NF Instance ID.

  • Authentication for AUN3 devices supporting 5G key hierarchy TS 24.501CR5811
  • Impact on NAS signalling for supporting authentication of AUN3 devices supporting and not supporting 5G key hierarchy TS 24.501CR5812
  • Authentication and key agreement procedure for 5G ProSe UE-to-UE relay TS 24.501CR5820
  • Authentication for UE behind 5G-RG and FN-RG using NSWO TS 33.501CR1593
  • Authentication of AUN3 devices behind RG TS 33.501CR1614
  • Introducing Home Trigger primrary authentication procedure TS 33.501CR1670

+ 22 more changes

Rel-19 7 changes

In Release 19, the AKA function was updated with specific corrections to the handling of the AUTHENTICATION REJECT message, particularly for a UE configured to use the T3245 timer, and to the requirements for resetting the attempt counter upon an authentication reject. Additionally, the release included a correction to the Information Element length for the Service-level AA container used in Service-level authentication command and complete messages.

  • Corrected requirements for attempt counter reset at authentication reject TS 24.301CR4214
  • Correction in handling AUTHENTICATION REJECT message by a UE configured to use T3245 TS 24.301CR4599
  • Corrected requirements for attempt counter reset at authentication reject TS 24.501CR6675
  • Correction in handling AUTHENTICATION REJECT message by a UE configured to use T3245 TS 24.501CR7066
  • Correction of IE length for Service-level AA container in Service-level authentication command/complete message TS 24.501CR7092
  • Correct mutual authentication requirement TS 33.501CR2163

+ 1 more changes

Explore further

Broader topics and technologies where AKA plays a role.

Defining Specifications

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

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 23.234 vd10 3GPP-WLAN Interworking Index Rel-13
TR 23.758 vh00 Study on Edge Application Architecture Rel-17
TS 23.804 v1700 SMS/MMS over IP Access Support Rel-7
TS 24.109 vj00 HTTP Digest AKA & GAA Stage 3 Rel-19
TS 24.234 vc20 3GPP-WLAN Interworking Network Selection Rel-12
TS 24.301 vj60 NAS protocol for Evolved Packet System Rel-19
TS 24.302 vj00 Access to EPC via non-3GPP networks; Stage 3 Rel-19
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 24.890 vg00 5G NAS Protocol for 5GS Stage 3 Rel-16
TS 29.109 vj00 GAA Bootstrapping Interfaces (Zh, Dz, Zn, Zpn) Rel-19
TS 29.826 vd10 P-CSCF Restoration Enhancements for WLAN Rel-13
TS 31.103 vj00 ISIM Application Specification Rel-19
TR 31.900 vj00 3GPP TS 31.900: Security Interworking Guidance Rel-19
TS 32.181 vj00 User Data Convergence Management Framework Rel-19
TS 32.808 v1800 Common User Profile Storage Framework Rel-8
TS 33.102 vj10 3G Security Architecture Specification Rel-19
TS 33.127 vj50 Lawful Interception Architecture and Functions Rel-19
TS 33.141 vj00 Security for Presence Service (Ut reference point) Rel-19
TS 33.203 vj10 IMS Security Specification Rel-19
TS 33.220 vj00 Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) Rel-19
TS 33.221 vj00 Subscriber Certificate Distribution via GBA 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.402 vj00 Security for non-3GPP access to EPS Rel-19
TS 33.501 vk00 5G Security Architecture and Procedures Rel-20
TS 33.514 vk00 5G Security Assurance for UDM Rel-20
TS 33.545 vj20 Security for NR Femto Subsystem Rel-19
TS 33.804 vc00 Non-UICC SSO using SIP Digest credentials Rel-12
TS 33.820 v1830 Home NodeB/eNodeB Security Architecture Rel-8
TS 33.835 vg10 Study on authentication and key management for apps Rel-16
TR 33.841 vg10 Security aspects; Study on 256-bit algorithms for 5G Rel-16
TS 33.843 vf10 Security Study for ProSe UE-to-Network Relay Rel-15
TS 33.859 vb10 UTRAN Key Hierarchy Enhancement Study Rel-11
TS 33.863 ve20 Security for Battery-Efficient IoT Device to Enterprise Rel-14
TR 33.919 vj00 GAA Overview TR Rel-19
TR 33.924 vj00 GBA-OpenID Interworking Specification Rel-19
TS 34.229 vj21 IMS SIP/SDP UE Conformance Testing for 5GS Rel-19
TS 35.235 vj00 MILENAGE-256 Algorithm Set Specification Rel-19
TS 35.236 vj00 MILENAGE-256 Algorithm Set Specification Rel-19
TS 35.249 vj10 f5** Algorithm for MILENAGE and Tuak Rel-19
TR 35.937 vj00 MILENAGE-256 Algorithm Set Specification Rel-19
TS 38.300 vj00 NG-RAN Overall Description Rel-19
TS 43.318 vj00 Generic Access Network (GAN) Stage 2 Rel-19
TR 43.902 vj00 GAN Enhancements Feasibility Study Rel-19
TS 44.318 vj00 Generic Access Network (GAN) Interface Procedures Rel-19