← Book home
Part 2 · Authentication and Access Security
6

5G-AKA — The Complete Message Flow

Every message, every parameter, from SUCI to anchor key

“If Chapter 5 gave you the map, this chapter walks every street — and shows you exactly where the two failure alarms live.” — HOW TO READ THIS CHAPTER

This is the chapter you will return to with a packet capture open beside it. We trace one complete 5G-AKA run from the UE’s registration request to the anchor key KSEAF sitting in the SEAF — naming every parameter (RAND, AUTN, XRES*, HXRES*, RES*, KAUSF, KSEAF), every service operation, every comparison, and the two ways it can fail: MAC failure and synchronization failure.

🎯 Learning objectives
📘 Standards reference box — Chapter 6
SpecificationTitleRelease / version verified
TS 33.5015G security — 5G-AKA procedure (clause 6.1.3) + Annex A (KDF)Rel-18, v18.11.0 (2026-04)
TS 23.502Procedures — registration & authentication call flowRel-19, v19.5.0
TS 24.501NAS — Authentication Request/Response messagesRel-18/19 edition
TS 29.509 / 29.503Nausf / Nudm service APIsRel-18 edition

Checked June 2026 — verify against the latest 3GPP version.

6.1 The Master Sequence

Before the details, here is the whole run on one page. Read it top to bottom; every later diagram is a zoom into one band of it.

FIGURE 6.1End-to-End 5G-AKA Master Sequence
UE / USIM SEAF / AMF AUSF (home) UDM / ARPF ① Registration Request ( SUCI ) ② Nausf_UEAuthentication_Authenticate ( SUCI, SN-name ) ③ Nudm_UEAuthentication_Get ( SUCI, SN-name ) ④ SIDF: SUCI→SUPI ARPF: f1–f5 → 5G HE AV (XRES*) ⑤ 5G HE AV ( RAND, AUTN, XRES*, K_AUSF ), SUPI ⑥ AUSF: XRES*→HXRES* stores K_AUSF, XRES* ⑦ 5G SE AV ( RAND, AUTN, HXRES* ) ⑧ NAS Authentication Request ( RAND, AUTN, ngKSI, ABBA ) ⑨ USIM: verify AUTN (MAC + SQN) → RES, CK, IK ME: RES → RES* ⑩ NAS Authentication Response ( RES* ) ⑪ SEAF: hash RES* = HXRES*? (local screen) ⑫ Nausf…Authenticate ( RES* ) ⑬ AUSF: RES*=XRES*? the authoritative check ⑭ Nudm…ResultConfirmation ⑮ success + K_SEAF + SUPI → SEAF anchors it
Purpose: the whole procedure at a glance. Bands ①–⑤ carry the SUCI home; ⑥–⑨ deliver and verify the challenge; ⑩–⑮ verify the UE and anchor the key. Keep this open as the index to the rest of the chapter.

6.2 Step ①–② — Registration Request and the AUSF Call

The UE begins a registration carrying its SUCI (Chapter 4) and its UE security capabilities (the NEA/NIA algorithms it supports — Chapter 8 will need these). The AMF, hosting the SEAF, picks an AUSF in the subscriber’s home network (resolved from the SUCI’s home network ID) and calls Nausf_UEAuthentication_Authenticate, attaching the serving network name — the string that will bind every key to this network.

FIGURE 6.2Registration Request and the Nausf Authenticate Call
📱 UEno valid GUTI Registration Request → SUCI (concealed identity) UE security capabilities (NEA/NIA) Requested NSSAI, 5GS reg type → to AMF over NAS AMF / SEAF resolves home network from SUCI builds SN name string selects an AUSF AUSF (home) EAP-server-capable Nausf…Authenticate (SUCI, SN-name) KEEP THESE FOR LATER the UE security capabilities ride along now but are USED in the NAS Security Mode Command (Ch 8) — the AMF must echo them back protected to defeat bidding-down
Purpose: what the UE actually sends, and the two things the AMF adds. The SN name is the seed of all key binding; the UE capabilities are the seed of bidding-down defense.

6.3 Step ③–⑤ — Vector Generation in the UDM/ARPF

The AUSF forwards to the UDM via Nudm_UEAuthentication_Get. Inside the UDM: the SIDF de-conceals SUCI → SUPI (Chapter 4), the UDM selects the method (Chapter 5), and the ARPF generates the 5G HE AV (Home Environment Authentication Vector). Critically, the ARPF computes XRES* and derives KAUSF from CK, IK with the SN name folded in.

FIGURE 6.3Inside the UDM/ARPF — Building the 5G HE AV
Nudm…Get (SUCI, SN-name) arrives from AUSF SIDF: SUCI → SUPI + read method = 5G-AKA ARPF (with K 🔑) fresh RAND, next SQN f1→MAC f2→XRES f3→CK f4→IK f5→AK AUTN = (SQN⊕AK)∥AMF∥MAC (MILENAGE / TUAK) 5G KDF (Annex A) XRES* = KDF( CK,IK, SN-name, RAND, XRES ) K_AUSF = KDF( CK,IK, SN-name, SQN⊕AK ) 5G HE AV → RAND AUTN XRES* K_AUSF + SUPI → back to AUSF the SN name enters here, in the home network — so the keys are network-bound from the very first derivation
Purpose: where the 5G-specific transformations happen. Note XRES* (not raw XRES) and KAUSF are the new layer 5G adds on top of classic AKA — and both already carry the serving network name.
FIGURE 6.4RAND and AUTN — Structure and What Each Part Proves
RAND 128-bit fresh random — the challenge AUTN — the network’s proof token (128 bits) SQN ⊕ AK48 bits AMF16 bits MAC64 bits proves FRESHNESS SQN counters replay; AK hides it USIM checks SQN in window mgmt bits separation bit = 1 (5G) proves AUTHENTICITY MAC = f1(K, SQN,RAND,AMF) only home network can build it the USIM checks MAC first (is this my network?) then SQN (is this fresh?) — two checks, two distinct failure types (§6.10)
Purpose: the anatomy of the token that finally let phones trust networks. The two halves it verifies map exactly to the two failure modes you will diagnose at the end of this chapter.

6.5 Step ⑥–⑦ — The AUSF Hashes, the SEAF Receives

The AUSF receives the 5G HE AV, stores XRES* and KAUSF, and computes HXRES* = a hash of XRES* (with RAND). It builds the 5G SE AV (Serving Environment AV) containing only RAND, AUTN, and HXRES* — and sends it to the SEAF. The serving network never receives XRES* or KAUSF; it gets a hash it can compare against, and nothing it could use to forge a success.

FIGURE 6.5XRES* → HXRES* — the Hash That Protects the Home Secret
AUSF keeps (home) XRES* — the real answer K_AUSF — visit key root compute HXRES* = SHA-256( RAND ∥ XRES* ) , truncated store K_SEAF (derived, held back) 5G SE AV SEAF receives (serving) RAND AUTN HXRES* (only the hash) WHY THIS MATTERS a compromised SEAF holds only HXRES* — a one-way hash it cannot derive a valid RES* so it cannot fake a UE success
Purpose: the elegant split. The serving network can screen the answer (compare hashes) but cannot manufacture one — the authoritative secret never leaves home.
FIGURE 6.6Step ⑧ — the NAS Authentication Request on the Air
SEAF / AMF sends over NAS (N1) 📱 UE Authentication Request ← RAND · AUTN · ngKSI · ABBA RAND/AUTNthe challenge + proof ngKSIlabels the new key set (so later messages reference it) ABBAAnti-Bidding-down Between Architectures — bound into K_AMF
Purpose: the message your trace will show as Authentication request. Two new 5G parameters ride here: ngKSI (key set label) and ABBA (binds the security context to the feature set, blocking architecture downgrade).

6.6 Step ⑨ — The USIM Verifies, the ME Computes RES*

This is the moment the subscriber side does its work. The USIM recomputes AK (f5), recovers SQN, recomputes the expected MAC (f1) and compares — is this my network? — then checks SQN is in range — is this fresh?. On success it outputs RES (f2), CK (f3), IK (f4). The ME then derives RES* from RES with the SN name and RAND, mirroring the ARPF’s XRES* computation.

FIGURE 6.7USIM Verification and RES* Derivation
received: RAND, AUTN into the USIM ① AK=f5(K,RAND); SQN = (SQN⊕AK) ⊕ AK ② MAC check: f1(K,...) = AUTN.MAC? NO → MAC FAILURE (§6.10) ③ SQN in acceptable range? NO → SYNC FAILURE + AUTS (§6.10) ✓ output RES=f2, CK=f3, IK=f4 ME derives RES* RES* = KDF( CK,IK, SN-name, RAND, RES ) same KDF the ARPF used for XRES* → Authentication Response ( RES* ) also derives K_AUSF, K_SEAF locally (mirrors the network) WHY RES* MIRRORS XRES* the network already computed XRES* from the SAME inputs (CK, IK, SN-name, RAND) using the SAME KDF. If the UE holds the right K and is on the right network, RES* will EQUAL XRES* — bit for bit. Any wrong key, wrong network name, or replayed/tampered challenge makes them differ → authentication fails. the UE proves K without ever transmitting K or RES in the clear-equivalent
Purpose: the subscriber’s half of the proof — and the origin of the two failure modes. MAC failure means “not my network”; sync failure means “my network, but stale.”

6.7 Step ⑪–⑬ — The Two-Stage Comparison

5G-AKA verifies the response twice, on purpose. The SEAF hashes the received RES* and compares to HXRES* — a fast local screen that lets a roaming network reject obvious garbage without a home round-trip. Then the AUSF compares the actual RES* to the stored XRES* — the authoritative verdict that decides whether KSEAF is ever released.

FIGURE 6.8The Two-Stage Comparison — Local Screen, then Home Verdict
📱 UEsends RES* RES* STAGE 1 — SEAF (serving) compute HRES* = hash(RAND ∥ RES*) HRES* == HXRES* ? NO → reject locally (no home trip) YES → forward RES* to AUSF ↓ RES* STAGE 2 — AUSF (home) RES* == XRES* ? the AUTHORITATIVE check — exact match, no hashing YES → release K_SEAF WHY TWO CHECKS? Stage 1 — efficiency & DoS resistance a roaming SEAF drops bad responses instantly, without a slow round-trip to a foreign home network Stage 2 — trust & home control the SEAF can be fooled by a lucky hash collision in theory; only the exact XRES* match releases keys
Purpose: why the design checks twice. Stage 1 is a cheap doorman; Stage 2 is the judge. Keys move only after the judge rules.

6.8 Step ⑮ — KAUSF and KSEAF Delivered

On the AUSF’s success, it derives KSEAF = KDF(KAUSF, SN name) and returns it to the SEAF, along with the SUPI. The SEAF stores KSEAF as the anchor and the procedure is done — every key the UE will use grows from here (Chapter 7). KAUSF stays in the AUSF for SoR/UPU protection and AKMA.

FIGURE 6.9KAUSF → KSEAF — Derivation and Delivery
K_AUSF stays in AUSF + UE → SoR/UPU, AKMA (Ch 5) KDF(·, SN-name) K_SEAF the ANCHOR key released only after Stage-2 pass SEAF stores it + receives SUPI (now learns identity) authentication COMPLETE K_AMF (Ch 7) NAS keys K_gNB AS keys → PDCP authentication delivers exactly ONE thing to the serving network: K_SEAF. Everything else is local derivation — the subject of Chapter 7.
Purpose: the payoff. One run of 5G-AKA yields one anchor key, network-bound, released only on the home network’s verdict — the seed of the entire key tree.
FIGURE 6.10Step ⑭ — Authentication Result Confirmation (Home Control)
AUSFknows the verdict Nudm_UEAuthentication_ResultConfirmation ( SUPI, success/fail, timestamp, SN-name ) UDMrecords it this record is the 4G roaming-fraud fix: the home network now has an auditable, per-authentication trail of where its subscribers really authenticated
Purpose: the small message with big consequences. Without it, “increased home control” would be a slogan; with it, the UDM can refuse service that contradicts authentication history.

6.9 Step §6.10 — The Two Failure Paths

When authentication fails on the UE side, which failure it is tells you exactly what is wrong. This is the single most useful diagnostic in 5G authentication.

FIGURE 6.11MAC Failure vs Synchronization Failure — Diagnosis
USIM checks AUTN (Figure 6.7, steps ②③) MAC wrong SQN out of range MAC FAILURE meaning: this is NOT my network, or the message was tampered UE → Authentication Failure cause = "MAC failure" suspect: rogue gNB, wrong K/OP, relay SYNCHRONIZATION FAILURE meaning: right network, but the SQN counters drifted apart UE → Authentication Failure cause = "synch failure" + AUTS recoverable: network resyncs SQN AUSF/UDM: AUTS → recover UE’s SQN generate FRESH vector, retry once MAC failure does NOT auto-recover repeated MAC failures in one area = investigate for a false base station (Ch 24, 27)
Purpose: the diagnostic fork every SOC analyst needs. Sync failures are routine and self-healing; a cluster of MAC failures in one cell is a rogue-base-station signature.
FIGURE 6.12The AUTS Resynchronization Sequence
UE SEAF AUSF UDM/ARPF Auth Failure (cause=synch failure, AUTS) Nausf…Authenticate (RAND, AUTS) Nudm…Get (RAND, AUTS) ARPF: AUTS → SQN_MS reset SQN, new vector fresh 5G HE AV (new RAND, in-range SQN) → retry from step ⑦ AUTS is itself MAC-protected (f1*) — a fake base station cannot forge a resync to push the SQN to a chosen value
Purpose: how the network recovers from drift. The AUTS token carries the UE’s own sequence counter, MAC-protected so it can’t be abused to manipulate SQN.
FIGURE 6.13A Subtle Threat — AKA Linkability and the Rel-16+ Hardening
THE CLASSIC LEAK an attacker replays a captured Authentication Request to many UEs. The TARGET UE answers "synch failure" (it has seen this SQN); OTHER UEs answer "MAC failure". → the differing answer identifies the target a presence/tracking oracle, despite SUCI (academic: "fixing AKA linkability") THE DIRECTION OF FIX 3GPP studied encrypting/uniforming the failure responses so the two cases are indistinguishable to an eavesdropper. Mitigations evolved across releases — verify the exact mechanism in your target release of TS 33.501. lesson: even a "failure" is information
Purpose: a reminder that authentication privacy is more than identity concealment. Even the type of failure can leak presence — which is why 3GPP keeps refining AKA. Verify your release’s exact behavior.
FIGURE 6.14Parameter Ledger — Where Each Value Lives
parameter computed by who sees it purpose KUSIM + ARPF onlyroot secret RAND/AUTNARPFeveryone (on air)challenge + network proof XRES*ARPFAUSF onlyexpected answer (home) HXRES*AUSFSEAFlocal screen value RES*MESEAF → AUSFUE’s proof of K K_AUSFARPF + UEAUSF + UESoR/UPU, AKMA K_SEAFAUSF + UESEAF + UEthe anchor → key tree SUPISIDFhome; SEAF after successreal identity read the "who sees it" column top to bottom: the serving network never holds K, XRES*, or K_AUSF — only screen values and the anchor
Purpose: the whole trust model as a ledger. If you can reproduce this column “who sees it,” you understand 5G-AKA’s security.
FIGURE 6.15Performance & Security View — Round-Trips That Matter
UE→AMFreg + SUCI AMF→AUSF→UDMhome round-trip (roaming = slow) challenge→UEUSIM compute SEAF screenlocal, fast (HXRES*) AUSF verdict2nd home trip + K_SEAF SECURITY ↔ PERFORMANCE the SEAF’s local screen (HXRES*) exists precisely to avoid wasting the expensive home round-trips on junk responses — security and latency engineering met here
Purpose: the procedure as latency, which matters for capacity and DoS planning. The two red dots are the home round-trips; the SEAF screen guards them.

6.10 The Practical Operator View

Common misconfiguration risks

6.11 Threats and Mitigations

ThreatWhere it strikesDefense in this flow
Challenge replaystep ⑧ on the airSQN freshness; sync-failure path; AV single-use
Fake networkstep ⑨ MAC checkAUTN MAC from K — unforgeable
Forged success by visited NWstep ⑬AUSF holds XRES*; SEAF holds only HXRES*
SQN manipulation via resyncAUTS pathAUTS MAC-protected (f1*)
Linkability via failure typesteps ⑨ responsesrelease-specific hardening — verify your version
Vector interceptionsteps ②–⑤ interconnectSBA TLS, SEPP, HXRES* not XRES*

6.12 Terminology, Example, Checklist

TermMeaning
5G HE AV / 5G SE AVHome-environment vector (RAND,AUTN,XRES*,K_AUSF) / serving-environment vector (RAND,AUTN,HXRES*)
XRES* / HXRES* / RES*Expected response / its hash (to SEAF) / the UE’s computed response
K_AUSF / K_SEAFHome-anchored key / the serving anchor key released on success
ngKSI / ABBAKey-set identifier labeling the new context / anti-bidding-down parameter bound into K_AMF
AUTSResynchronization token returned on a sync failure (MAC-protected)
MAC failure / synch failureWrong/fake network or tampering / SQN out of range (recoverable)

Real network example. An operator’s NOC opened a P1 on a “5G authentication outage” — thousands of sync failures in an hour, all from one region. The 5G-AKA knowledge above solved it in minutes: sync failures are recoverable and network-side, so this was not an attack and not the UEs. The cause: a UDM node had been restored from a backup snapshot, rewinding its SQN array; every returning subscriber’s USIM (with a higher SQN) rejected the stale vectors and demanded resync. Fix: let the AUTS resync drain naturally and correct the SQN-storage replication. Had the same volume been MAC failures, the response would have been the opposite — a rogue-base-station hunt.

Chapter Summary

? Review Questions

  1. List, in order, every message in a successful 5G-AKA run and the one new value each introduces.
  2. Why does the AUSF send HXRES* to the SEAF instead of XRES*? What does this prevent a malicious SEAF from doing?
  3. Explain how RES* can equal XRES* without RES* ever revealing K — and what three inputs both derivations share.
  4. A trace shows AUTN verified successfully but the attach still fails at the security mode step. What do you suspect, and why is it not a MAC failure?
  5. Distinguish MAC failure from synch failure: cause, recoverability, and the correct operational response to a cluster of each.
  6. Why is the AUTS token MAC-protected, and what attack would be possible if it weren’t?
  7. At which exact step does the serving network learn the SUPI, and why is that timing important for privacy?
  8. Where does the serving network name enter the derivations of XRES* and K_AUSF, and what does binding it there achieve?
🧪 Mini lab — capture a full 5G-AKA run

With Open5GS + UERANSIM and Wireshark (Chapter 33 setup): (1) Register a UE and capture the NAS exchange — locate Authentication request (read RAND, AUTN, ngKSI, ABBA) and Authentication response (RES*). (2) In the AUSF/UDM logs, find XRES* generation and the RES*==XRES* comparison — confirm they happen in the home functions, not the AMF. (3) Now corrupt one byte of the UE’s key K and re-register: confirm a MAC failure at the USIM. (4) Restore K but force an SQN mismatch (re-use an old config / restore a DB snapshot) and confirm a synch failure with an AUTS token, followed by automatic recovery. You have now reproduced both failure paths — the two most valuable signatures in 5G authentication diagnostics.