One framework, two methods, and the home network’s final word
“Authentication is the moment a network decides to spend money on you. Everything before it is a stranger knocking.”
— WHY THIS IS THE MOST EXECUTED SECURITY PROCEDURE ON EARTH
Several billion times a day, somewhere between a phone and a vault of secret keys, the 5G authentication framework runs. It must work on a beach in a foreign country, inside a factory with private credentials, over Wi-Fi, and on a satellite link — and it must never let a fake network or a fake subscriber through. This chapter explains the framework’s architecture; Chapter 6 then walks the full 5G-AKA message flow byte by byte.
🎯 Learning objectives
Explain the unified authentication framework and why it covers all access types.
Contrast 5G-AKA and EAP-AKA′ — flow, trust, when each is used.
Assign the roles: UE, SEAF, AUSF, UDM/ARPF.
Dissect an authentication vector and the functions that build it.
Explain serving network name binding and increased home control.
Place NSWO and AKMA in the framework.
📘 Standards reference box — Chapter 5
Specification
Title
Release / version verified
TS 33.501
5G security — authentication clauses
Rel-18, v18.11.0 (2026-04)
RFC 5448 / RFC 9048
EAP-AKA′ (IETF)
current
TS 33.102
3G AKA foundations
Rel-17/18 edition
TS 33.535
AKMA
Rel-18 edition
TS 35.205-208 / 35.231-233
MILENAGE / TUAK algorithm sets
current
Checked June 2026 — verify against the latest 3GPP version.
5.1 One Framework, Every Access
4G had separate authentication stories for LTE access and non-3GPP (Wi-Fi) access. 5G unified them: one framework, one anchor key, every access type — NR, LTE connected to 5GC, untrusted Wi-Fi via N3IWF, trusted non-3GPP, wireline. The result of any successful authentication is the same object: KSEAF, the anchor key held by the serving network’s SEAF, from which all subsequent keys grow (Chapter 7).
FIGURE 5.1The Unified Authentication Framework — All Roads to One Anchor
Purpose: the framework’s core promise. Whatever the radio (or wire), authentication converges on the same roles and the same anchor key.
5.2 The Four Roles
Every authentication involves four parties — memorize their one-line jobs:
Role
Lives in
Job in one line
UE (USIM)
subscriber device
proves possession of K; verifies the network via AUTN
SEAF
AMF, serving network
runs the serving side; receives and anchors K_SEAF
AUSF
home network
home-side server: verifies the final proof, issues K_SEAF, records the verdict
UDM/ARPF
home network
picks the method, generates the vector from K, de-conceals SUCI (SIDF)
FIGURE 5.2Authentication Roles — Who Does What, Who Sees What
Purpose: the cast and their secrets. Note what the serving network is structurally denied: K stays home, and even the expected response only reaches it as a hash.
5.3 5G-AKA in Brief
5G-AKA is the native method — 3G AKA’s grandchild, upgraded with home control. The shape (full flow in Chapter 6): UDM builds a vector from K; the challenge (RAND, AUTN) travels via AUSF and SEAF to the UE; the USIM verifies AUTN and answers; the SEAF pre-checks a hash of the response, but the AUSF in the home network performs the authoritative check.
FIGURE 5.35G-AKA — the High-Level Flow
Purpose: shape before detail. Two verification points — a fast local hash check, then the authoritative home check. Chapter 6 expands every arrow.
5.4 EAP-AKA′ in Brief
EAP-AKA′ (RFC 9048) wraps the same AKA cryptography in the EAP (Extensible Authentication Protocol) framework. The architectural difference is trust placement: in EAP, the AUSF is the EAP server and the only verifier — the SEAF is a pass-through authenticator with no pre-check at all. Same USIM, same K, same vector math; different protocol envelope and slightly different key derivation (CK′/IK′, with the serving network name bound inside the vector derivation itself).
FIGURE 5.4EAP-AKA′ — the High-Level Flow
Purpose: the EAP shape. One verifier, full home control by construction — the visited network is a courier.
Choosing between them
FIGURE 5.55G-AKA vs EAP-AKA′ — Side by Side
Purpose: the decision card. Same cryptography, different trust topology — and in private networks (Ch 21) the EAP envelope also admits entirely different credentials (certificates via EAP-TLS).
5.5 Authentication Vectors: the Home Network’s Ammunition
An authentication vector (AV) is a one-time package proving the home network’s knowledge of K. The ARPF computes, from K and a fresh RAND + sequence number SQN, via the MILENAGE or TUAK function families (f1…f5):
MAC (f1) — network authentication code, packed into AUTN
XRES (f2) — expected subscriber response
CK, IK (f3, f4) — cipher and integrity keys (raw material for the tree)
AK (f5) — anonymity key concealing the SQN inside AUTN
FIGURE 5.6The Vector Factory — f1…f5 Inside the ARPF
Purpose: where vectors come from. Note the AMF “separation bit” — set to 1, it marks the vector as 5G-only, blocking cross-generation vector reuse attacks.
💡 Key idea
The AV design lets the home network delegate the challenge without delegating the secret. A serving network can run authentication for millions of roamers while the key K never leaves the home ARPF — only single-use, SN-bound evidence derived from it travels.
5.6 Mutual Authentication: Who Proves What
FIGURE 5.7Mutual Authentication — Who Proves What to Whom
Purpose: the symmetric contract. Each side both proves and judges — the asymmetry of 2G is gone.
Serving network name binding
The serving network name — the string 5G:mnc<MNC>.mcc<MCC>.3gppnetwork.org — enters the key derivations (KAUSF, KSEAF; inside the vector for EAP-AKA′). Consequence: keys minted for one network are cryptographically useless in another. The UE computes the same name independently from the network it believes it is on — a mismatch breaks the keys, killing network-spoofing-by-relay tricks.
FIGURE 5.8Serving Network Name — Construction and Binding
Purpose: the quiet masterpiece of 5G authentication. One string in the KDF closes an entire class of network-impersonation attacks.
Increased home control
4G let the visited MME judge authentication alone — and roaming-fraud history shows what followed: visited networks asserting a subscriber was present (and billable) when they were not. 5G moves the verdict home: the AUSF verifies RES* itself, then informs the UDM of every result (Nudm_UEAuthentication_ResultConfirmation). The home network can refuse service when claimed location and authentication history don’t add up.
FIGURE 5.9Increased Home Control — Why the AUSF Gets the Final Word
Purpose: the roaming-fraud lesson institutionalized. The visited network can hurry the process along but can no longer manufacture its outcome.
5.7 Method Selection and Non-3GPP Access
The UDM chooses the method, per subscriber — it de-conceals the SUCI, reads the subscription’s authentication policy, and returns either a 5G-AKA vector or an EAP-AKA′ start to the AUSF. The UE doesn’t request a method; it answers whatever arrives. (In SNPNs, the choice extends to key-based EAP methods like EAP-TLS — Chapter 21.)
FIGURE 5.10Authentication Method Selection in the UDM
Purpose: who decides. Method choice is subscription data in the UDM — which is why the same phone can authenticate differently in your public and private networks.
Untrusted non-3GPP access: the N3IWF path
Over public Wi-Fi, the UE builds an IPsec tunnel to the N3IWF (Non-3GPP InterWorking Function) using IKEv2; the very same NAS registration and authentication run inside it; EAP-5G encapsulates NAS over IKEv2 during setup. Result: identical authentication, identical anchor key, identical NAS security — over someone else’s Wi-Fi.
FIGURE 5.11Untrusted Non-3GPP Access — Same Authentication via N3IWF
Purpose: unified means unified. The coffee-shop Wi-Fi becomes just another untrusted pipe; 5G security rides inside it end-to-end.
5.8 Two Framework Extensions: NSWO and AKMA
NSWO (Non-Seamless WLAN Offload, Rel-17): authenticate to a Wi-Fi network itself with your USIM credentials via the 5GC (EAP-AKA′ to the AUSF through an NSWO function) — Wi-Fi traffic stays local, no 5G session, but the SIM vouches for you.
AKMA (Authentication and Key Management for Applications, TS 33.535): reuse the network authentication to bootstrap application keys. From KAUSF, the UE and the AAnF (AKMA Anchor Function) derive KAKMA → per-application keys KAF. An app gets a SIM-rooted shared key without passwords and without running its own AKA.
Purpose: the framework pays dividends beyond access. One successful network authentication can securely bootstrap every operator-partnered application — Chapter 12 returns to this at the NEF.
FIGURE 5.13Vector Anatomy — What Home Keeps vs What Serving Receives
Purpose: the two vector flavors and the trust story they encode. The hash trick (HXRES*) lets the SEAF pre-screen without holding anything forgeable.
FIGURE 5.14Trusted Non-3GPP and Wireline — the Other Two Doors
Purpose: completeness of the “every access” claim — fixed-mobile convergence rides the same four roles.
FIGURE 5.15The Framework on One Card — Decision Map
Purpose: the chapter as a single revision card — every question this framework answers, and where the answer lives.
5.9 The Practical Operator View
Pick MILENAGE or TUAK consciously and protect the operator constants (OP/OP_c, TOP/TOP_c) like K itself — they live in the same HSM conversation.
Set per-subscriber method policy deliberately: public consumers on 5G-AKA, private/SNPN populations on EAP where it buys flexibility.
Watch authentication KPIs by failure cause (MAC failure vs sync failure vs no-response) — Chapter 26 builds the funnel; the framework defines the causes.
For non-3GPP access, treat the N3IWF as an internet-exposed VPN gateway — harden and monitor it like one.
Common misconfiguration risks
Default/example MILENAGE OP values from vendor docs left in production HSS/UDM migrations.
SQN management mis-set across UDM redundancy — storms of sync failures.
Challenge, network proof token, (5G) expected response, its hash
MILENAGE / TUAK
The two standardized algorithm sets implementing f1–f5
SN name
Serving network name string bound into key derivations
N3IWF / TNGF / W-AGF
Gateways for untrusted / trusted non-3GPP / wireline access
NSWO / AKMA / AAnF
SIM-auth for plain Wi-Fi / application key bootstrapping / its anchor function
Real network example. A European MVNO migrating subscribers onto a host operator’s 5G SA core saw a burst of authentication failures — only for roamers in one partner country. Root cause: the partner’s SEAF sent a malformed serving network name (legacy formatting from a 4G-era config). The home AUSF derived different keys than the UEs did, and every attach died at the SMC step. The trail that found it: failure cause analysis showed successful AUTN verification (no MAC failures) but consistent post-auth security mode failures — exactly the SN-name-mismatch signature. The framework’s binding worked as designed; the configuration didn’t.
Confirm which algorithm set (MILENAGE/TUAK) and which operator constants are live — and where they are stored.
5G-AKA: SEAF hash pre-check + AUSF final check. EAP-AKA′: AUSF is sole verifier; SEAF is a pass-through.
Vectors are single-use evidence built by f1–f5 from K; the serving network gets HXRES*, never XRES*; the SN name binds all keys to one network.
Home control = home verdict + result confirmation: the 4G roaming-fraud lesson, fixed in architecture.
Extensions: NSWO (SIM-auth for plain Wi-Fi), AKMA (application keys from K_AUSF).
? Review Questions
Why does the serving network receive HXRES* instead of XRES*, and what attack does this design choice frustrate?
In EAP-AKA′, what exactly does the SEAF verify? What does that imply about trust placement?
The UDM — not the UE, not the AMF — selects the authentication method. Give two reasons this is the right place.
Explain how the AMF field’s “separation bit” prevents a 5G vector from being abused against a 4G network.
Walk through what breaks, step by step, when a SEAF presents serving network name X while the UE computes name Y.
Your roaming partner claims your subscriber authenticated at 03:14. Which two 5G records let you verify or refute this — and which 4G gap do they close?
What security does the N3IWF path give a subscriber on hostile café Wi-Fi, layer by layer?
How does AKMA give an application a shared key without the app ever seeing AKA — and what single key does it all grow from?
🧪 Mini lab — watch the method choice happen
In Open5GS, the UDM/AUSF debug logs show the full framework in action. (1) Register a UERANSIM UE and grep the logs for the Nudm_UEAuthentication_Get exchange — find the method decision and the vector hand-off. (2) Locate the HXRES* computation in the AUSF log and the SEAF-side comparison in the AMF log — two different processes, exactly as Figure 5.3 draws. (3) Change the UE’s key K in the UERANSIM config (one hex digit) and watch where the flow now dies — confirm it is a MAC failure at the USIM side, not at the network. You have just located all four roles in running code.