AUTN

Authentication Token

Security →
Introduced in Rel-2 Also in: Services, Core Network, User Equipment

AUTN is a network-generated token used in 3GPP AKA protocols to authenticate the network to the user equipment, proving its legitimacy and enabling mutual authentication.

Category
Security
Introduced
Rel-2
Where
Security
Also touches
3 segments
Specifications
13 specs
AUTN Description Purpose Detected Changes Specifications

Description

The Authentication Token (AUTN) is a critical component within the 3GPP Authentication and Key Agreement (AKA) framework, used in UMTS, LTE, and 5G systems. It is generated by the network's Authentication Centre (AuC) and sent to the User Equipment (UE) as part of an authentication vector during the primary authentication procedure. The AUTN serves a singular, vital purpose: to authenticate the serving network to the UE. This provides mutual authentication, as the UE also authenticates itself to the network using a separate response parameter (RES).

Technically, the AUTN is a concatenated bit string composed of several sub-components. The primary elements are a Message Authentication Code (MAC) and a Sequence Number (SQN). The MAC is calculated by the AuC using the secret subscriber key (K) and a set of input parameters including the SQN, a random challenge (RAND), and the serving network identifier. This MAC proves the token originated from a legitimate entity possessing the correct key. The SQN is a freshness parameter that ensures the authentication request is new and guards against replay attacks. The UE, which also possesses the secret key K, independently computes an expected MAC (XMAC) from the received RAND and SQN. If the computed XMAC matches the MAC within the AUTN, the network is verified as authentic.

Upon receiving the AUTN, the UE performs several checks. First, it verifies the MAC to confirm the network's authenticity. Second, it checks the SQN to ensure it is within an acceptable range, confirming the request's freshness and preventing the network from reusing old authentication vectors. If these checks pass, the UE considers the network legitimate and proceeds to generate its authentication response. The successful validation of AUTN triggers the derivation of the Ciphering Key (CK) and Integrity Key (IK) from the same secret key K and the RAND, establishing the secure keys for subsequent encrypted and integrity-protected communication.

In the overall network architecture, the AUTN is part of the authentication vector (AV), typically a quintet (for 3G/4G) or a quintet/vector (for 5G) that includes RAND, AUTN, XRES (Expected Response), CK, and IK. This vector is generated by the AuC/ARPF (Authentication credential Repository and Processing Function) and delivered to the serving network node (e.g., VLR/SGSN/MME/AMF). The serving node then forwards the RAND and AUTN to the UE to initiate the challenge. The AUTN's role is thus pivotal in the initial handshake, establishing a trusted relationship before any user data is exchanged.

Purpose & Motivation

AUTN was created to address a critical security flaw in previous cellular generations (e.g., GSM), which only provided one-way authentication (network authenticating the user). This asymmetry left systems vulnerable to false base station attacks, where a rogue network element could impersonate a legitimate operator to intercept communications or track users. The primary purpose of AUTN is to enable mutual authentication, ensuring the UE can verify it is connecting to a genuine, authorized 3GPP network.

Historically, GSM's security relied on a shared secret (Ki) and a challenge-response mechanism, but the network's legitimacy was never cryptographically proven to the handset. The introduction of AUTN in 3G UMTS (Release 99) as part of the UMTS AKA protocol fundamentally changed this paradigm. It solved the problem of network authentication by providing a verifiable token, thereby mitigating man-in-the-middle and impersonation attacks. This was a necessary evolution to support new services, increased data privacy concerns, and the growing value of mobile transactions.

Furthermore, AUTN incorporates freshness through the SQN, which addresses replay attacks where an adversary could capture and reuse old authentication messages. By forcing the network to prove it is using a fresh, sequentially appropriate challenge, AUTN ensures the entire authentication exchange is current and secure. This combination of authenticity and freshness checks forms the bedrock of trust for all subsequent secure communications in 3GPP networks, from voice calls in 3G to high-speed data and IoT services in 4G and 5G.

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (102 CRs across 6 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-2, normative work from Rel-15.

Rel-15 35 changes

In Release 15, the specifications for the AUTN function were updated with clarifications and corrections to several key authentication procedures. This included specific corrections to the secondary authentication procedure, the primary authentication framework, and the handling of unused 5G authentication vectors. Furthermore, the release introduced new details for token-based authorization and authentication within the Service-Based Architecture (SBA), including updates to the Access Token Request mechanism.

  • 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
  • Corrections to secondary authentication procedure TS 33.501CR0064
  • Corrections related to authentication related services TS 33.501CR0080
  • Clarifications to: Initiation of authentication and selection of authentication method TS 33.501CR0084
  • Clarifications to: Authentication procedures TS 33.501CR0115

+ 29 more changes

Rel-16 22 changes

In Release 16, the scope of the AUTN function was expanded beyond primary user authentication to explicitly include new token-based authorization procedures for indirect communication between network functions, such as SeCoPs. The release also introduced specific enhancements for authentication and authorization within Network Slice selection and for Private Non-Public Networks (PNI-NPN). Furthermore, it added support for using symmetric keys for Access Token signatures and detailed the re-use and verification parameters for these tokens in delegated discovery scenarios.

  • Authentication and authorization between SeCoP and network functions TS 33.501CR0693
  • Authentication and authorization between SeCoPs TS 33.501CR0694
  • Resource Level Authorization using Access Tokens TS 33.501CR0755
  • Authentication in indirect communication scenarios TS 33.501CR0808
  • Network slice specific authentication and authorization clauses TS 33.501CR0853
  • Token-based authorization in indirect communication scenarios TS 33.501CR0854

+ 16 more changes

Rel-17 19 changes

In Release 17, the enhancements to the AUTN function and related authentication procedures included clarifications on authentication for User Equipment behind 5G-RG and FN-RG, and the introduction of authentication in the user plane procedure for Multicast/Broadcast Services (MBS). The release also provided corrections and clarifications for secondary authentication during UE onboarding and revised the procedures for network slice re-authentication and revocation by the AAA-S. Furthermore, it introduced mechanisms for access token misuse prevention and clarified the support for authentication methods within a Standalone Non-Public Network (SNPN).

  • 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
  • Change the procedure of network slice re-authentication and revocation by AAA-S TS 33.501CR1091
  • Removing Editor's note on Credentials Holder using AUSF and UDM for primary authentication TS 33.501CR1307
  • Usage of AN ID for NSWO authentication TS 33.501CR1317
  • Corrections and clarifications to secondary authentication during UE onboarding TS 33.501CR1388

+ 13 more changes

Rel-18 19 changes

In Release 18, the authentication token (AUTN) function was enhanced to support new scenarios like primary authentication triggered by the home network and the authentication of devices behind a Residential Gateway (RG). It also introduced clarifications and validations for access token requests in roaming, hierarchical NRF deployments, and interconnect scenarios, strengthening the security framework for service-based interfaces.

  • 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
  • Use of NF Instance ID in the mutual authentication between the NF Consumer and NRF TS 33.501CR1761
  • Access token request handling by NRF TS 33.501CR1667
  • Clarification on access token request for accessing services TS 33.501CR1728

+ 13 more changes

Rel-19 6 changes

In Release 19, key enhancements to the Authentication Token (AUTN) function included support for the `iat` claim in the access token and the introduction of public key distribution for issuer claim verification. The release also clarified token-based authorization for indirect communication when a Network Function is selected at the target PLMN and refined the access token's handling of S-NSSAI lists. Furthermore, Release 19 deprecated the use of the `requesterPlmnList` in the Access Token Request.

  • Support iat claim in the access token TS 33.501CR2051
  • Token-based authorization for indirect communication scenarios when NF is selected at target PLMN TS 33.501CR2135
  • Public key distribution and Issuer claim verification of the Access Token TS 33.501CR2152
  • Correct mutual authentication requirement TS 33.501CR2163
  • Clarification on access token with respect to a list of S-NSSAIs TS 33.501CR2187
  • Deprecation of the use of the requesterPlmnList in the Access Token Request TS 33.501CR2192
Rel-20 1 change

In Release 20, the primary update to the Authentication Token (AUTN) function was a correction for roaming scenarios to ensure proper alignment with network procedures. Specifically, the change replaced the method of appending PLMN ID claims within the access token with the use of distinct PLMN ID-specific claims. This refinement aimed to improve the clarity and correctness of the authentication and registration process for roaming user equipment.

  • Correction of misalignment with TS 29.510: Replace appended PLMN ID access token claims with PLMN ID specific claims in roaming TS 33.501CR2214

Explore further

Broader topics and technologies where AUTN plays a role.

Defining Specifications

3GPP specifications that define or reference AUTN, 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.060 vj00 GPRS Service Description Stage 2 Rel-19
TS 24.109 vj00 HTTP Digest AKA & GAA Stage 3 Rel-19
TS 24.229 vj50 IMS call control protocol based on SIP and SDP Rel-19
TS 29.109 vj00 GAA Bootstrapping Interfaces (Zh, Dz, Zn, Zpn) Rel-19
TS 31.102 vj40 USIM Application Specification Rel-19
TS 31.103 vj00 ISIM Application Specification Rel-19
TR 31.900 vj00 3GPP TS 31.900: Security Interworking Guidance Rel-19
TS 33.102 vj10 3G Security Architecture Specification Rel-19
TS 33.105 vj00 3G Security: Cryptographic Algorithm Requirements Rel-19
TS 33.401 vj10 EPS Security Architecture Rel-19
TS 33.501 vk00 5G Security Architecture and Procedures Rel-20
TS 33.835 vg10 Study on authentication and key management for apps Rel-16