Description
The Network Access Identifier (NAI) is a critical identifier defined in IETF RFC 7542 and adopted by 3GPP for use in access authentication. Its primary format is 'username@realm'. The 'username' part uniquely identifies the user within the context of the specified 'realm'. The 'realm' is a crucial component that denotes the administrative domain responsible for authenticating the user, typically the user's home service provider (e.g., operator.com). This structure is essential for roaming.
During network access, when a user (UE) attempts to connect to a visited network (e.g., while roaming internationally), the UE presents its NAI in the access request. The visited network's access point (e.g., a PDN Gateway in 5G, or a AAA proxy) examines the realm portion of the NAI. Since the realm is not local, the visited network's AAA infrastructure forwards the authentication request, containing the NAI, to the AAA server in the user's home realm. This routing is often done through a hierarchy of proxy AAA servers.
The home AAA server (e.g., HSS/UDM in 3GPP) uses the username part of the NAI to look up the user's subscription profile and authentication credentials. It then engages in an authentication protocol (like EAP-AKA') with the UE. The NAI remains constant throughout this process, ensuring the home network knows exactly which user is being authenticated. In 3GPP systems, the NAI is often derived from the user's International Mobile Subscriber Identity (IMSI) or a subscription permanent identifier (SUPI) in a privacy-preserving way (e.g., creating a pseudonym).
The NAI's role extends beyond initial access. It is used in accounting records (e.g., RADIUS Accounting messages) to correlate usage data with a specific user and their home realm for billing and settlement between roaming partners. It is a carrier-grade identifier designed for scalability and global uniqueness, forming the backbone of interoperable authentication in heterogeneous and roaming-enabled network environments.
Purpose & Motivation
The NAI was created to solve the fundamental problem of uniquely and unambiguously identifying a mobile user in a world of multiple, interconnected network service providers (roaming). Before standardization, different networks used various, often incompatible, formats for user IDs (e.g., simple usernames, MSISDNs), which caused severe problems in routing authentication requests during roaming and made inter-operator accounting complex.
The primary motivation was to enable seamless and secure network access authentication for roaming users. The 'user@realm' structure provides a simple, yet powerful, way to embed routing information (the realm) directly into the user's identity. This allows any visited network to determine, without prior knowledge of the user, where to send the authentication request. It decouples the visited network's authentication infrastructure from the home network's user database.
3GPP adopted the NAI to integrate its core network authentication (using Diameter and later HTTP/2-based protocols) with the broader Internet authentication framework established by the IETF. It addresses the limitations of using only an IMSI or MSISDN, which do not explicitly contain domain routing information and can raise privacy concerns if transmitted in clear text. The NAI format is extensible and supports privacy enhancements like pseudonymous or fast re-authentication identities, making it a versatile and future-proof cornerstone for secure, scalable mobile access.
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (23 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the NAI format was formally introduced for the SUPI definition and for the SUCI encoding. It was also specified as an identifier for non-3GPP access, with subsequent clarifications provided for SUCI using NAI and for the usage of decorated NAI.
In Release 17, the specification introduced clarifications and corrections for the Network Access Identifier (NAI) format and its usage in several specific contexts. These updates included corrections for NSWO (Non-Seamless WLAN Offload) and the handling of the NID (Network Identifier) within a SUCI (Subscription Concealed Identifier) when formatted as an NAI. Furthermore, the release provided clarifications on the NAI format for a PRUK (ProSe Relay User Key) ID and for the identifier provided by an N5CW device.
In Release 18, the enhancements for the Network Access Identifier (NAI) primarily focused on defining and clarifying the use of a "decorated NAI" for specific access scenarios. This included standardized support for decorated NAIs in Non-Seamless WLAN Offload (NSWO) and for SNPN authentication, with particular attention to scenarios involving N5CW devices and credentials owned by a Credentials Holder (CH). The work also involved resolving editorial notes and providing guidance on NAI format corrections and privacy mitigation for variable-length NAIs.
- Resolve EN on NAI construction for SNPN authentication TS 24.502CR0242
- Decorated NAI for NSWO TS 24.502CR0288
- MPS for WLAN NAI decoration TS 31.102CR1033
- Clarification on NAI format in NSWO scenario TS 23.501CR4803
- Clarification/Alignment on usage of Decorated NAI for 5G-NSWO in case of SNPNs. TS 23.501CR5252
- MPS for WLAN NAI decoration TS 24.302CR0772
+ 7 more changes
Explore further
Broader topics and technologies where NAI plays a role.
Defining Specifications
3GPP specifications that define or reference NAI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 22.495 v1700 | NGN Requirements for IMS Services | Rel-7 |
| TS 23.228 vj50 | IMS Stage-2 Service Description | Rel-19 |
| TS 23.234 vd10 | 3GPP-WLAN Interworking Index | Rel-13 |
| TS 23.501 vk00 | 5G System Architecture Stage 2 | Rel-20 |
| TR 23.923 v1300 | Mobile IP+ Feasibility Study for UMTS/GPRS | Rel-4 |
| TS 24.229 vj50 | IMS call control protocol based on SIP and SDP | Rel-19 |
| TS 24.234 vc20 | 3GPP-WLAN Interworking Network Selection | Rel-12 |
| 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.502 vj20 | 5G Core Access via Non-3GPP Networks; Stage 3 | Rel-19 |
| TS 24.554 vj40 | 5G Proximity Services (ProSe) Protocols | Rel-19 |
| TS 24.890 vg00 | 5G NAS Protocol for 5GS Stage 3 | Rel-16 |
| TS 29.061 vj00 | Packet Domain Interworking for PLMN | Rel-19 |
| TS 29.275 vj00 | PMIPv6 Mobility & Tunnelling Protocols Stage 3 | Rel-19 |
| TS 29.503 vj50 | UDM Service Based Interface Stage 3 | Rel-19 |
| TS 29.562 vj40 | HSS Services for IMS & GBA Interworking | Rel-19 |
| TS 31.102 vj40 | USIM Application Specification | Rel-19 |
| TS 31.103 vj00 | ISIM Application Specification | Rel-19 |
| TS 32.182 vj00 | UDC Common Baseline Information Model (CBIM) | Rel-19 |
| TS 33.107 vj00 | Lawful Interception Architecture & Functions | Rel-19 |
| TS 33.501 vk00 | 5G Security Architecture and Procedures | Rel-20 |
| TS 33.503 vj20 | Security for Proximity Services (ProSe) in 5G | Rel-19 |
| TS 33.822 v1800 | Security Architecture for Inter-Access Mobility | Rel-8 |
| TS 33.835 vg10 | Study on authentication and key management for apps | Rel-16 |