Description
The AKMA Key IDentifier (A-KID) is a critical security parameter within the 3GPP Authentication and Key Management for Applications (AKMA) framework, introduced in Release 16. It serves as a unique reference or pointer to a specific AKMA Application Key (K_AKMA) that is securely generated and stored by the AKMA Anchor Function (AAnF) in the home network. The A-KID is generated by the AAnF and is bound to the specific UE and the AAnF instance that produced the K_AKMA. Its structure and usage are defined across multiple 3GPP specifications, including TS 33.535 for the AKMA procedures and TS 24.501 for its transport in Non-Access Stratum (NAS) signaling.
Architecturally, the A-KID is generated by the AAnF after a successful primary authentication of the UE (e.g., using 5G AKA or EAP-AKA'). During this process, the AAnF derives the K_AKMA from the anchor key established during that authentication. The AAnF then creates the A-KID, which typically includes information to uniquely identify the key context, such as the SUPI of the UE, the identifier of the AAnF (AAnF-ID), and potentially a key index or freshness parameter. This A-KID is then provided to the UE, often within the NAS security mode command or similar procedure, allowing the UE to store it for future use with application services.
When a UE wants to access an AKMA-enabled application service (hosted by an Application Function, AF), it presents the A-KID to the AF as part of the service authentication request. The AF, which does not possess the K_AKMA, uses this A-KID to query the correct AAnF (identified within the A-KID) via the N33 reference point. The AAnF validates the request, retrieves the corresponding K_AKMA using the A-KID, and derives application-specific keys (like K_AF) which it then provides securely to the AF. This process allows the AF and the UE to establish a secure session using keys rooted in the 3GPP credential, without the AF ever handling the long-term subscriber key.
The role of the A-KID in the network is fundamental to the AKMA security model. It acts as a secure token that authorizes key retrieval, ensuring that only an AF with a valid request corresponding to that specific UE and key context can obtain the derived keys. It prevents key confusion attacks by uniquely binding the retrieval request to a single K_AKMA instance. The design also supports key lifecycle management; for example, if a K_AKMA is renewed or revoked, a new A-KID would be issued, rendering the old identifier invalid for key retrieval, thus providing a mechanism for forward secrecy at the application key level.
Purpose & Motivation
The A-KID was created to solve the problem of secure and scalable authentication for third-party application services (like streaming, IoT, or enterprise services) that wish to leverage the strong, subscription-based authentication of 3GPP networks without integrating directly with core network nodes like the UDM/AUSF. Before AKMA, applications often relied on separate credential databases (usernames/passwords, OAuth tokens) or less secure methods, creating friction for users and management overhead for operators. The purpose of the A-KID is to provide the essential 'key' to this new paradigm—a secure, network-issued identifier that unlocks cryptographically strong, network-derived keys for applications.
The historical context is the industry shift towards service-based architectures and open exposure of network capabilities in 5G. While solutions like GBA (Generic Bootstrapping Architecture) existed in earlier releases, they were often seen as complex and not fully aligned with the 5G core's cloud-native principles. AKMA, and by extension the A-KID, was designed as a more integrated, 5G-native solution. The A-KID specifically addresses the limitation of how an application function, which is untrusted relative to the home network, can securely and unambiguously request the keys needed to authenticate a user. It replaces the need for the application to know intricate details about the user's core network session, providing a simple, opaque identifier that the network can map to the rich security context established during primary authentication.
Furthermore, the A-KID enables important security properties. It solves the problem of key identification and routing in a distributed system where multiple AAnFs may exist. By encoding routing information (like the AAnF-ID), it ensures the AF contacts the correct network function to retrieve keys. It also addresses the problem of key lifecycle management from the application's perspective. The AF does not need to understand when a subscriber's key is refreshed; it simply presents the A-KID it receives from the UE. If the key is no longer valid, the AAnF will reject the request based on the A-KID, prompting the UE and AF to establish a new session with a fresh A-KID, thereby maintaining security.
What changed in its specifications
The latest release-to-release comparison of specifications that define A-KID. Each summary describes the whole specification, not only this term.
Standalone security aspects update HTTP references and specify authentication algorithm values. AKMA adds TLS usage over Ua* with new definitions, and GBA updates authentication algorithm and TLS version details for 5GC bootstrapping.
Full comparison in TS 24.109 →Rel-19 adds satellite NG-RAN access text, LP-WUS/WUR assistance and disabling, ATUC RAT utilization control, and network-controlled slice selection with S-NSSAI time validity to TS 24.501. It also adds ATSSS Phase 4 multi-access and 5G ProSe multi-hop relay support.
Full comparison in TS 24.501 →Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (2 CRs across 1 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-16, normative work from Rel-17.
Defining Specifications
3GPP specifications that define or reference A-KID, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 24.109 vj00 | HTTP Digest AKA & GAA Stage 3 | Rel-19 read |
| TS 24.501 vk10 | 5GS NAS Protocol Specification | Rel-20 read |
| TS 29.522 vk10 | NEF Northbound Interface | Rel-20 read |
| TS 29.535 vk10 | AAnF Service Based Interface | Rel-20 read |
| TS 33.127 vj80 | Lawful Interception Architecture | Rel-19 read |
| TS 33.535 vj00 | 5G AKMA: Authentication and Key Management for Apps | Rel-19 read |
| TR 33.741 vi01 | Home Network Triggered Authentication | Rel-18 read |