Authentication — Primary Authentication (5G-AKA / EAP-AKA')¶

Learning objectives¶

After reading this page, you will be able to:

• Explain the Why (why authentication is needed) as the foundation for preventing impersonation, ensuring legitimate charging, and protecting communication.
• Explain the essence of 5G-AKA / EAP-AKA' as mutual authentication (the network verifies the UE, and the UE verifies the network).
• Explain the differences between the two schemes 5G-AKA and EAP-AKA' (message structure, round trips, presence or absence of the EAP framework).
• Follow the call flow of each scheme in the order the players appear: UE(USIM) / SEAF(AMF) / AUSF / UDM(ARPF).
• Explain where and by whom (UDM/SIDF) the de-concealment of SUCI → SUPI is performed.
• Follow each step of authentication vector (AV) generation → RES*/XRES* and HRES*/HXRES* verification → KAUSF/KSEAF derivation.
• Distinguish the three major failures — MAC failure / Synch failure (SQN out of sync) / RES* mismatch — and explain AUTS resynchronization.

Prerequisites¶

It will go more smoothly if you first understand the following. If you haven't yet, start from the curriculum.

• The big picture of Registration (authentication was outlined as part of the registration procedure) → Initial Registration
• SUCI / SUPI (the real name SUPI, and the SUCI that conceals it) → Registration Basic Concept
• NAS / N1 (the layer that carries control messages between UE and AMF) → N1
• The roles of the NFs involved in authentication → AMF / AUSF / UDM

What you'll learn in this chapter¶

This chapter focuses on primary authentication itself. That is, for the two schemes 5G-AKA and EAP-AKA', it precisely covers the details of the message round trips, each step of key derivation, and failures and resynchronization.

• For an overview of authentication and its place within the whole of registration, see the Registration chapter;
• For the full picture of the key hierarchy, see the AUSF key hierarchy (to avoid duplication, this chapter concentrates on key derivation within the procedure).

Note that secondary authentication (Secondary Authentication — per-PDU-session authentication with an external DN) is out of scope for this chapter (see Next Step).

Why — why authentication is needed¶

Let's start from the Why (why it is needed). If the network accepted terminals unconditionally, the following problems would arise.

• Impersonation — Someone impersonates another's subscription to hijack communication and charging.
• Charging fraud — You cannot determine who used the service, so you cannot charge correctly.
• No foundation for communication protection — You cannot establish the shared key used for encryption and integrity protection.

Authentication is the procedure of using cryptographic techniques to confirm "is this terminal really the genuine subscriber?" and, at the same time, agreeing on the key that protects subsequent communication. It is important that 5G authentication is not one-way but mutual authentication.

• Network → UE: Confirms whether the UE is a legitimate subscriber (verification of the response RES*).
• UE → Network: Confirms whether the entity it connects to is not a fake base station (a spoofing network) (verification of AUTN).

Overview¶

Primary authentication is built on the following relationship among three parties.

• AMF(SEAF) — The starting point of authentication. Closest to the UE, it triggers authentication and exchanges challenge/response with the UE. The SEAF (Security Anchor Function) is co-located in the AMF.
• AUSF — The server of authentication. Standing between the UDM and the AMF, it verifies the response and derives the anchor key KSEAF.
• UDM(ARPF/SIDF) — The source of authentication information. The ARPF, which holds the permanent key K, generates the authentication vector (AV), and the SIDF de-conceals SUCI → SUPI.

flowchart LR
    UE([UE / USIM]) -->|"1. Auth trigger (SUCI)"| AMF["AMF / SEAF"]
    AMF -->|"2. Auth request (N12)"| AUSF[AUSF]
    AUSF -->|"3. AV request (N13)"| UDM["UDM (ARPF / SIDF)"]
    UDM -->|"4. SUCI de-concealment + AV generation"| AUSF
    AUSF -->|"5. RAND/AUTN"| AMF
    AMF -->|"6. challenge/response"| UE

Basic Concept — a beginner-friendly explanation¶

The core of primary authentication is AKA = Authentication and Key Agreement. As the name says, it performs "authentication (identity verification)" and "key agreement (establishment of a shared key)" at the same time.

1. The shared secret key K and challenge-response¶

• Shared secret key K — A long-term key held only by the USIM (UE side) and the network-side ARPF (which logically belongs to the UDM). It never travels over the air.
• Challenge-response — A scheme in which the network sends a random number RAND (the question) and the UE returns the answer RES* computed using K. Because you cannot produce the correct answer without knowing K, this serves as identity verification.

2. Mutual authentication (bidirectional verification)¶

• The network verifies the UE (verifies RES* against XRES*).
• The UE verifies the network (the USIM verifies AUTN = Authentication Token). AUTN contains the MAC (tamper detection) and the SQN (sequence number), and cannot be produced by anything other than a legitimate network.

3. Key agreement (KAUSF → KSEAF)¶

When authentication succeeds, the same key is derived on both sides from the same AKA computation. This key is derived down the chain of upper keys KAUSF → KSEAF → KAMF → … and is used for the encryption and integrity protection of NAS/AS (for the full picture of the hierarchy, see the AUSF key hierarchy).

4. SUCI / SUPI / SIDF (who de-conceals the real name)¶

• SUPI — The subscriber's real name (equivalent to IMSI). It must not be carried in the clear over the air.
• SUCI — SUPI encrypted with the home network public key to conceal it. It may be carried over the air.
• SIDF (Subscription Identifier De-concealing Function) — The function that de-conceals SUCI back to SUPI using the home network private key. It belongs to the UDM, and only the SIDF is allowed to handle the private key (TS 33.501 §6.12.2).

Architecture¶

These are the functional elements involved in primary authentication and the interfaces that connect them. The point that the SIDF handles SUCI de-concealment and the point that the ARPF generates the AV are the leading roles of this chapter.

flowchart LR
    subgraph UEside["UE"]
      USIM["USIM
(holds K)"]
    end
    subgraph Serving["Serving / Visited network"]
      SEAF["AMF / SEAF"]
    end
    subgraph Home["Home network"]
      AUSF["AUSF
(derives KAUSF/KSEAF)"]
      UDM["UDM"]
      ARPF["ARPF
(holds K, generates AV)"]
      SIDF["SIDF
(de-conceals SUCI→SUPI)"]
    end

    USIM -- "N1 (NAS)" --> SEAF
    SEAF -- "N12 (Nausf)" --> AUSF
    AUSF -- "N13 (Nudm)" --> UDM
    UDM --- ARPF
    UDM --- SIDF

• USIM — Holds the shared key K. A tamper-resistant card that performs AUTN verification and RES computation.
• AMF / SEAF — The starting point of authentication. It exchanges challenge/response with the UE over NAS, performs the HRES* check, and receives KSEAF.
• AUSF — Response verification and KAUSF/KSEAF derivation. Relays between the UDM and the AMF.
• UDM / ARPF / SIDF — The ARPF generates the AV, and the SIDF de-conceals SUCI. The source of authentication information.

The detailed key hierarchy diagram is consolidated in the AUSF key hierarchy to avoid duplication. This chapter concentrates on "which key is born at which step within the procedure."

Network Function¶

Interface / Protocol¶

These are the interfaces and protocols used in this procedure.

For protocol details, see the Protocol Dictionary, and for a list of interfaces, see the Interface Dictionary. For individual pages, see N12 (AMF⇔AUSF) / N13 (AUSF⇔UDM).

Procedure — Call Flow¶

This is the heart of this page. There are two schemes for primary authentication, and the UDM selects which one to use (based on the SUCI/SUPI and the subscriber data; TS 33.501 §6.1.2). The AMF(SEAF) does not specify the scheme to the Nausf and follows the UDM's decision.

(A) 5G-AKA Call Flow¶

sequenceDiagram
    autonumber
    participant UE as UE / USIM
    participant SEAF as AMF / SEAF
    participant AUSF
    participant UDM as UDM (ARPF / SIDF)

    Note over UE,SEAF: Auth trigger (SUCI or SUPI already determined)
    SEAF->>AUSF: Nausf_UEAuthentication_Authenticate
(SUCI or SUPI, SN-name)
    Note right of SEAF: TS 33.501 §6.1.2
    AUSF->>UDM: Nudm_UEAuthentication_Get
(SUCI or SUPI, SN-name)
    Note right of UDM: If SUCI, SIDF de-conceals to SUPI
TS 33.501 §6.12.2
    Note right of UDM: ARPF selects scheme=5G-AKA and
generates HE AV(RAND,AUTN,XRES*,KAUSF)
TS 33.501 §6.1.3.2
    UDM-->>AUSF: 5G HE AV (RAND, AUTN, XRES*, KAUSF) + SUPI
    Note right of AUSF: AUSF derives HXRES* from XRES* and
KSEAF from KAUSF → into SE AV
    AUSF-->>SEAF: 5G SE AV (RAND, AUTN, HXRES*)
    SEAF->>UE: Authentication Request (NAS: RAND, AUTN, ngKSI, ABBA)
    Note right of UE: USIM verifies AUTN(MAC/SQN)→
computes RES→ME(UE) generates RES*
    UE->>SEAF: Authentication Response (NAS: RES*)
    Note right of SEAF: SEAF computes HRES* from RES* and
verifies against HXRES* (first-stage check)
    SEAF->>AUSF: Nausf_UEAuthentication_Authenticate (RES*)
    Note right of AUSF: AUSF verifies RES* against XRES* (final decision)
TS 33.501 §6.1.3.2
    AUSF-->>SEAF: Authentication result (success) + KSEAF
    Note over UE,AUSF: Success→KSEAF established→on to KAMF derivation

Step-by-step explanation (numbers correspond to the diagram above)¶

1. SEAF→AUSF: Starts authentication with Nausf_UEAuthentication_Authenticate. Passes the SUCI (first time) or the SUPI (when the GUTI is known) and the SN-name (Serving Network name).
2. AUSF→UDM: Issues Nudm_UEAuthentication_Get.
3. (Inside UDM) SUCI de-concealment: If it arrived as a SUCI, the SIDF de-conceals it to SUPI using the home private key (TS 33.501 §6.12.2).
4. (Inside UDM) AV generation: The ARPF selects the scheme (5G-AKA) and generates the 5G HE AV = RAND, AUTN, XRES*, KAUSF (TS 33.501 §6.1.3.2).
5. UDM→AUSF: Returns the HE AV and the SUPI.
6. (Inside AUSF) Derivation: The AUSF computes XRES*→HXRES* and KAUSF→KSEAF, and builds the 5G SE AV = RAND, AUTN, HXRES* (it holds KSEAF at this point and hands it over after success).
7. AUSF→SEAF: Passes the SE AV (RAND, AUTN, HXRES*).
8. SEAF→UE: Authentication Request (NAS). In addition to RAND and AUTN, it includes ngKSI (the key set identifier) and ABBA (the backward-compatibility protection parameter).
9. (Inside USIM) Verification and computation: The USIM verifies the MAC and SQN of AUTN (confirming the network's legitimacy). If OK, it computes RES and generates RES*.
10. UE→SEAF: Authentication Response (NAS: RES*).
11. (Inside SEAF) First-stage check: The SEAF computes RES*→HRES* and verifies it against HXRES*. If they differ here, the SEAF can reject (a front-end check to reduce round trips).
12. SEAF→AUSF: Sends RES* and requests the final verification.
13. (Inside AUSF) Final check: The AUSF verifies RES* against XRES* (TS 33.501 §6.1.3.2).
14. AUSF→SEAF: On success, returns KSEAF. From here the SEAF derives KAMF and proceeds to establishing subsequent NAS security.

(B) EAP-AKA' Call Flow¶

EAP-AKA' runs AKA' on top of the EAP (Extensible Authentication Protocol) framework. The AUSF behaves as the EAP server and the UE as the EAP peer, while the AMF(SEAF) merely relays the EAP messages over NAS (passthrough) (TS 33.501 §6.1.3.1 / RFC 5448).

sequenceDiagram
    autonumber
    participant UE as UE / USIM (EAP peer)
    participant SEAF as AMF / SEAF (passthrough)
    participant AUSF as AUSF (EAP server)
    participant UDM as UDM (ARPF / SIDF)

    SEAF->>AUSF: Nausf_UEAuthentication_Authenticate (SUCI/SUPI, SN-name)
    AUSF->>UDM: Nudm_UEAuthentication_Get (SUCI/SUPI, SN-name)
    Note right of UDM: SIDF de-conceals SUCI / ARPF selects scheme=EAP-AKA'
generates AV(RAND,AUTN,XRES,CK',IK')
TS 33.501 §6.1.3.1
    UDM-->>AUSF: EAP-AKA' AV + SUPI
    AUSF-->>SEAF: EAP-Request/AKA'-Challenge (RAND, AUTN, MAC)
    SEAF->>UE: Authentication Request (EAP encapsulated in NAS)
    Note right of UE: USIM verifies AUTN→computes RES→computes MAC
    UE->>SEAF: Authentication Response (EAP in NAS)
    SEAF->>AUSF: EAP-Response/AKA'-Challenge (RES, MAC)
    Note right of AUSF: AUSF verifies RES against XRES and the MAC
on success, derives KAUSF→KSEAF
    AUSF-->>SEAF: EAP-Success + KSEAF
    SEAF->>UE: Authentication Result (NAS: EAP-Success)
    Note over UE,AUSF: Success→KSEAF established

Step-by-step explanation (numbers correspond to the diagram above)¶

1-2. SEAF→AUSF→UDM is the same entry point as 5G-AKA (Nausf → Nudm_UEAuthentication_Get). 3. (Inside UDM) The SIDF de-conceals the SUCI, the ARPF selects scheme=EAP-AKA' and generates the AV for EAP-AKA' (RAND, AUTN, XRES, CK', IK') (TS 33.501 §6.1.3.1). 4. UDM→AUSF: Returns the AV and the SUPI. 5. AUSF→SEAF→UE: The EAP-Request/AKA'-Challenge (RAND, AUTN, MAC), which the SEAF encapsulates in NAS (Authentication Request) and sends to the UE. 6. (Inside USIM) AUTN verification → RES computation → response MAC computation. 7. UE→SEAF→AUSF: The EAP-Response/AKA'-Challenge (RES, MAC) is carried over NAS to the AUSF. 8. (Inside AUSF) Verifies RES against XRES and the MAC. On success, derives KAUSF→KSEAF. 9. AUSF→SEAF→UE: Notifies EAP-Success (carried as Authentication Result in NAS). KSEAF is passed to the SEAF in the Nausf response.

Signal Flow¶

The main messages / service operations are organized in a table.

Main IE terms: RAND (random challenge) / AUTN (network→UE authentication token) / RES* (UE→network response) / XRES* (the correct answer the network expects) / HXRES* (hash of XRES*, for the SEAF check) / KSEAF (anchor key) / KAUSF (key held by AUSF) / ABBA (backward-compatibility protection) / SUCI (concealed ID) / SUPI (real name) / AUTS (SQN resynchronization token). For details, see the Message Dictionary.

State Machine¶

This is the state transition of primary authentication as seen from the USIM/UE (basis: TS 33.501 §6.1 / TS 24.501 §5.4.1).

stateDiagram-v2
    [*] --> Idle: Before authentication
    Idle --> AwaitChallenge: SEAF starts auth (obtains AV via Nausf/Nudm)
    AwaitChallenge --> VerifyingAUTN: Authentication Request received (RAND,AUTN)
    VerifyingAUTN --> ComputingRES: AUTN verification OK
    VerifyingAUTN --> MACFailure: MAC mismatch
    VerifyingAUTN --> SynchFailure: SQN out of range
    ComputingRES --> Success: RES*/XRES* match
    ComputingRES --> ResMismatch: RES*/XRES* mismatch
    MACFailure --> [*]: Authentication Failure(cause=MAC failure)→Reject
    SynchFailure --> Resync: Authentication Failure(cause=Synch failure, AUTS)
    Resync --> AwaitChallenge: Network resyncs SQN with AUTS→new AV
    ResMismatch --> [*]: Authentication Reject
    Success --> [*]: KSEAF established→on to NAS security

• VerifyingAUTN — The transient state where the USIM verifies the MAC and SQN of AUTN. It branches into two kinds of failure here.
• MAC failure — The MAC of AUTN does not match, i.e., suspicion of a key mismatch / fake network. The UE moves toward rejection as authentication failure.
• Synch failure — The MAC matches but the SQN is out of range (the counters on the network side and the UE side have drifted apart). The UE returns AUTS to request resynchronization.
• ResMismatch — On the network side, RES*/XRES* do not match, resulting in an Authentication Reject.

Packet Analysis (Wireshark)¶

Because primary authentication is a NAS message, capture it with nas-5gs. The point that NAS is carried nested inside NGAP (N2) is the same as in Registration's Packet Analysis.

Main display filters¶

Points to note when decoding (main IEs)¶

• RAND / AUTN (inside Authentication Request) — The challenge random number and the network's authentication token.
• RES* (inside Authentication Response) — The UE's response.
• ngKSI / ABBA (inside Authentication Request) — The key set identifier and the backward-compatibility protection parameter.
• Authentication failure parameter (AUTS) (inside Authentication Failure) — The resynchronization token at Synch failure.
• In the case of EAP-AKA', you see an EAP message encapsulated in NAS.

Configuration¶

These are the structural-level essentials of the configuration needed to make primary authentication work. Specific values and vendor-specific details (Cisco, etc.) are implementation-dependent, and no fictitious values are written here.

UE/USIM side¶

• Writing of K (the subscriber's permanent key) and OPc (a value derived from the operator key). If these do not match the network side, you get a MAC failure.
• Configuration of SUPI/IMSI, the home network public key (for SUCI generation), and the Protection Scheme.

UDM/UDR side (e.g., Open5GS / free5GC)¶

• Registration of the subscriber (SUPI/IMSI) and provisioning of the authentication information (K, OPc) (must match the USIM side).
• Management of the SQN (sequence number) counter. Drift causes Synch failure.
• Configuration of the home network private key (used by the SIDF for SUCI de-concealment) and the Protection Scheme.
• Configuration of the authentication scheme the ARPF selects (5G-AKA / EAP-AKA').

Trouble Shooting¶

Here is the triage of typical authentication failures. For details on Cause values, see the Cause Dictionary.

Comparison with EPC¶

Let's contrast 4G (EPC) EPS-AKA with 5G authentication.

Release differences¶

Uncertain items are marked to be confirmed and not asserted.

• Rel-15 — The primary authentication of 5G-AKA / EAP-AKA', SUCI/SUPI and SIDF, KAUSF/KSEAF, and ABBA were established (the basis of TS 33.501).
• Rel-16 — The generation in which extensions to security functions progressed (the extent to which they are woven into the authentication procedure itself is to be confirmed).
• Rel-17 / Rel-18 (5G-Advanced) — Feature extensions continue (concrete differences to the primary authentication procedure are to be confirmed).

3GPP Specification¶

FAQ¶

Summary¶

• Primary authentication is mutual authentication (bidirectional verification of network→UE and UE→network), performing authentication and key agreement at the same time (AKA).
• The three-party relationship is AMF(SEAF)=starting point / AUSF=server, final check, KSEAF derivation / UDM(ARPF=AV generation, SIDF=SUCI de-concealment)=source.
• There are two schemes, 5G-AKA and EAP-AKA', and the selector is the UDM.
• 5G-AKA uses RES*/XRES* + the SEAF's HRES*/HXRES* first-stage check, while EAP-AKA' uses the EAP framework with the SEAF passing through.
• SUCI→SUPI de-concealment is performed by the home UDM/SIDF, which keeps the private key from leaving.
• The three major failure patterns: MAC failure (key mismatch) / Synch failure (SQN → AUTS resynchronization) / RES* mismatch (Reject).
• The basis is TS 33.501 §6.1 (§6.1.3.1 EAP-AKA' / §6.1.3.2 5G-AKA) / TS 24.501 §5.4.1.

Practice — comprehension check and exercises¶

Comprehension check¶

Exercises¶

Question: Reorder the following main 5G-AKA steps into the correct order.

A. AUSF verifies RES* against XRES* (final decision)
B. SEAF → AUSF: Nausf_UEAuthentication_Authenticate (start authentication)
C. USIM verifies AUTN and computes RES/RES*
D. AUSF → UDM: Nudm_UEAuthentication_Get
E. SEAF verifies HRES* against HXRES* (first-stage check)
F. UDM (SIDF de-conceals SUCI, ARPF generates AV) → AUSF: HE AV(RAND,AUTN,XRES*,KAUSF)
G. SEAF → UE: Authentication Request(RAND,AUTN,ngKSI,ABBA)
H. AUSF derives XRES*→HXRES*, KAUSF→KSEAF and sends the SE AV to the SEAF

Next Step¶

Here are the next steps for deepening your understanding.

• Security chapter (details of NAS security and the key hierarchy KSEAF/KAMF)
• PDU Session chapter (includes Secondary Authentication)
• Related NFs: AUSF (has the key hierarchy diagram) / UDM (ARPF/SIDF) / AMF (co-located SEAF)
• The big picture of the procedure: Initial Registration (the place of authentication)
• Dictionaries: Message Dictionary / Cause Dictionary / Protocol Dictionary / NF Dictionary / Interface Dictionary