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.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (89 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the A-KID function was newly introduced to provide a UE identifier during the initial registration procedure. This enhancement is part of the Authentication and Key Management for Applications (AKMA) framework, which establishes a security association identified by a bootstrapping transaction identifier (B-TID) and key material. The specification also removed editorial notes regarding the home network public key and its identifier, streamlining the associated procedures.
In Release 16, the A-KID function was enhanced with clarifications and corrections to the AKMA procedures, including error response handling and re-authentication. The release also introduced an explicit AKMA context description and provided clarifications for the AKMA Service-Based Architecture (SBA) interfaces. Furthermore, updates were made to align key lifetimes and to update the reference point interface names within the AKMA framework.
- Identifier Association TS 33.127CR0097
- Correction of certain erroneous Information Element Identifiers TS 24.501CR2033
- Packet filter identifier setting when requesting new packet filters TS 24.501CR2536
- Corrections to specify non-local ID as a target type rather than as target identifier TS 33.127CR0095
- Clarifications on error response handling in AKMA process TS 33.535CR0009
- Re-authentication in AKMA TS 33.535CR0013
+ 7 more changes
In Release 17, the AKMA (Authentication and Key Management for Applications) function was enhanced to include a dedicated TLS 1.3 profile using AKMA keys for securing the Ua* interface between the UE and the Application Function. This release also introduced procedures for the UE and AF to choose between AKMA and AKA-based GBA, and specified how the UE obtains the K_AKMA key and the A-KID identifier from NAS signaling. Furthermore, it added clarifications on key derivation and handling for scenarios like a missing K_AUSF.
- Adding profiles of TLS to use AKMA keys TS 24.109CR0070
- Adding AKMA based profile for TLS 1.3 TS 24.109CR0072
- The impact on UE due to the introduction of Authentication and Key Management for Applications (AKMA) TS 24.501CR2794
- CR adding LI for AKMA (stage 2) TS 33.127CR0140
- AAnF checks AKMA service for UE and AF in clause 6.3 TS 33.535CR0055
- Profiling the GBA TLS protocols for use with AKMA TS 33.535CR0066
+ 32 more changes
In Release 18, the AKMA function was enhanced to support new Ua protocols, specifically adding DTLS and IETF OSCORE as defined in TS 33.535. The release also introduced AKMA roaming policy control in the AAnF and updated procedures to support roaming restrictions and SUPI-based access in AKMA Application Key information. Furthermore, it included refinements for service disabling notifications via the NEF and updates to related UDM services.
- Protecting the N3IWF/TNGF identifier information in the REGISTRATION REJECT message TS 24.501CR5932
- Update AKMA procedures to support Roaming restrictions. TS 29.535CR0046
- AKMA phase 2 security enhancement TS 33.535CR0154
- Add AKMA Ua protocol based on DTLS to TS 33.535 TS 33.535CR0164
- IETF OSCORE as AKMA Ua protocol TS 33.535CR0175
- AKMA roaming policy control in AAnF TS 33.535CR0207
+ 18 more changes
In Release 19, the enhancements for the A-KID function were focused on clarifying and correcting procedures for AKMA services, specifically for roaming scenarios. The release introduced clarifications for the Application Function (AF) disabling encryption for a roaming UE when using AKMA services. Additionally, corrections were made to the name of the data type used for conveying the AKMA service disablement notification to ensure consistency.
- Support of reject QoS differentiation for non-3GPP device identifier(s) TS 24.501CR6926
- Procedure update for QoS differentiation of non-3GPP device identifiers TS 24.501CR6994
- Suspending QoS differentiation for non-3GPP device identifier TS 24.501CR7087
- Correction to the inconsistent LCS correlation identifier TS 24.501CR6380
- Support of multiple Non-3GPP device identifiers for QoS differentiation TS 24.501CR6925
- QoS differentiation for non-3GPP device identifiers clean up TS 24.501CR6993
+ 6 more changes
Explore further
Broader topics and technologies where A-KID plays a role.
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 |
| TS 24.501 vj50 | 5G NAS Protocols Specification | Rel-19 |
| TS 29.522 vj40 | 5G NEF Northbound APIs Stage 3 | Rel-19 |
| TS 29.535 vj40 | 5G AKMA Anchor Services Stage 3 Protocol | Rel-19 |
| TS 33.127 vj50 | Lawful Interception Architecture and Functions | Rel-19 |
| TS 33.535 vj00 | 5G AKMA: Authentication and Key Management for Apps | Rel-19 |
| TR 33.741 vi01 | Home Network Triggered Authentication | Rel-18 |