3GPP TS 33.501
Security architecture and procedures for 5G System
V18.6.0 (2024-09) — Release 18 33-Series Security 1. Scope
▶This document specifies the security architecture and security procedures for 5G. It covers:
- Security features and mechanisms for user equipment (UE) and network
- Security of network domain interfaces
- Security for Non-3GPP access to 5G core via N3IWF, TNGF, and W-AGF
- Security for Service-Based Architecture (SBA) and Service-Based Interfaces (SBI)
- Security between serving network and home network (SEPP)
- Network slicing security
- User plane integrity protection
This is THE master 5G security specification. All SCAS test catalogues (TS 33.512–33.522) derive their security requirements from this document.
2. References
▶| Ref | Document | Title | Link |
|---|---|---|---|
| [1] | 3GPP TS 23.501 | System architecture for the 5G System | Portal |
| [2] | 3GPP TS 23.502 | Procedures for the 5G System | Portal |
| [3] | 3GPP TS 33.210 | NDS; IP network layer security | Portal |
| [4] | 3GPP TS 33.310 | NDS; Authentication Framework (AF) | Portal |
| [5] | IETF RFC 5448 | EAP-AKA' (improved EAP-AKA) | RFC 5448 |
| [6] | IETF RFC 6749 | The OAuth 2.0 Authorization Framework | RFC 6749 |
| [7] | IETF RFC 7515 | JSON Web Signature (JWS) | RFC 7515 |
| [8] | IETF RFC 7519 | JSON Web Token (JWT) | RFC 7519 |
| [9] | IETF RFC 7523 | JWT Profile for OAuth 2.0 Client Auth | RFC 7523 |
| [10] | IETF RFC 7540 | HTTP/2 | RFC 7540 |
| [11] | IETF RFC 8446 | TLS 1.3 | RFC 8446 |
| [12] | 3GPP TS 29.500 | 5GS Technical Realization of SBA | Portal |
| [13] | 3GPP TS 35.231–235 | TUAK Algorithm Set | Portal |
| [14] | IETF RFC 5905 | NTPv4 | RFC 5905 |
| [15] | GSMA FS.34 | NESAS Development and Lifecycle Assessment | GSMA |
3. Definitions, Symbols and Abbreviations
▶| Term | Definition |
|---|---|
| 5G-AKA | 5G Authentication and Key Agreement — primary authentication method for 5G |
| 5G-GUTI | 5G Globally Unique Temporary Identifier |
| AUSF | Authentication Server Function — handles authentication in 5GC |
| EAP-AKA' | Extensible Authentication Protocol — AKA' variant for 5G |
| KAMF | Key for AMF, derived from KSEAF |
| KAUSF | Key for AUSF, derived during 5G-AKA/EAP-AKA' |
| KgNB | Key for gNB, derived from KAMF |
| KNASenc | Key for NAS confidentiality protection |
| KNASint | Key for NAS integrity protection |
| KRRCenc | Key for RRC confidentiality |
| KRRCint | Key for RRC integrity |
| KSEAF | Key for SEAF, derived from KAUSF |
| KUPenc | Key for user plane confidentiality |
| KUPint | Key for user plane integrity (new in 5G) |
| N3IWF | Non-3GPP Interworking Function |
| SEAF | Security Anchor Function (co-located with AMF) |
| SEPP | Security Edge Protection Proxy — secures inter-PLMN signaling |
| SIDF | Subscription Identifier De-concealing Function (in UDM) |
| SUCI | Subscription Concealed Identifier — encrypted form of SUPI |
| SUPI | Subscription Permanent Identifier |
4. Overview of 5G Security Architecture
▶The 5G security architecture is organized into the following security domains:
┌───────────────────────────────────────────────────────────────────────────┐
│ 5G SECURITY DOMAINS │
├───────────────┬───────────────┬──────────────┬───────────────────────────┤
│ (I) Network │ (II) Network │ (III) User │ (IV) SBA Domain │
│ Access │ Domain │ Domain │ Security │
│ Security │ Security │ Security │ │
│ │ │ │ │
│ • 5G-AKA │ • NDS/IP │ • USIM/ME │ • TLS on SBI │
│ • EAP-AKA' │ • IPsec/TLS │ • SUPI/SUCI │ • OAuth 2.0 tokens │
│ • NAS sec │ • SEPP │ • 5G-GUTI │ • NF service AuthZ │
│ • AS sec │ • GTP-U sec │ • Key store │ • Client Credentials │
│ • UP sec │ │ │ • NRF trust │
└───────────────┴───────────────┴──────────────┴───────────────────────────┘
Key Improvement over 4G: 5G adds user plane integrity protection (KUPint), SUPI concealment via SUCI, unified authentication framework (supporting both 5G-AKA and EAP-AKA'), and full SBA security with OAuth 2.0-based NF authorization.
4.1 Security Architecture Diagram
▶
UE gNB AMF/SEAF AUSF UDM/SIDF/ARPF
│ │ │ │ │
│◄─────────►│ AS Security │ │ │
│ K_gNB │ (RRC+UP) │ │ │
│ │ │ │ │
│◄─────────────────────────►│ NAS Security │ │
│ K_NASenc/int │ │ │
│ │ │ │
│ ──── Authentication ────────────────────────────────► │
│ 5G-AKA or EAP-AKA' K_AUSF → K │
│ │ │ ────────► │
│ │ K_SEAF │ │
│ │◄──────────────│ │
│ │ K_AMF │ │
│ │──────►K_gNB │ │
│ │ │ │
├──SUCI (concealed SUPI)───┼───────────────┼─────────────►│
│ │ │ SIDF │
│ │ │ deconceal │
│ │ │◄─────────────│
5. Security for NG-RAN (Access Stratum)
▶5.1 General
▶The security between the UE and the NG-RAN (gNB) is based on the key KgNB derived from KAMF. This key is used to derive:
- KRRCenc — RRC ciphering key
- KRRCint — RRC integrity key
- KUPenc — User Plane ciphering key
- KUPint — User Plane integrity key (new in 5G)
Mandatory: RRC integrity protection is mandatory. UP integrity protection is mandatory for the control plane and optional for the user plane based on operator policy.
5.2 5G Key Hierarchy
▶
K (in USIM and ARPF/UDM)
│
┌────────┴────────┐
│ CK' / IK' │ (via 5G-AKA or EAP-AKA')
└────────┬─────────┘
│
K_AUSF (in AUSF)
│
K_SEAF (in SEAF/AMF)
│
K_AMF (in AMF)
│
┌───────────────┼───────────────┐
│ │ │
K_NASenc K_NASint K_gNB
│
┌───────────────┼───────────────┐
│ │ │
K_RRCenc K_RRCint K_UPenc
│
K_UPint
| Key | Length | Derived From | Location | Purpose |
|---|---|---|---|---|
| K | 256-bit | — | USIM, ARPF | Permanent subscriber key |
| KAUSF | 256-bit | CK', IK' | AUSF | Anchor key from authentication |
| KSEAF | 256-bit | KAUSF | SEAF (AMF) | Serving network anchor |
| KAMF | 256-bit | KSEAF | AMF | AMF-specific key |
| KNASenc | 128-bit | KAMF | UE, AMF | NAS ciphering |
| KNASint | 128-bit | KAMF | UE, AMF | NAS integrity |
| KgNB | 256-bit | KAMF | gNB | gNB key derivation base |
| KRRCenc | 128-bit | KgNB | UE, gNB | RRC ciphering |
| KRRCint | 128-bit | KgNB | UE, gNB | RRC integrity (mandatory) |
| KUPenc | 128-bit | KgNB | UE, gNB | UP ciphering |
| KUPint | 128-bit | KgNB | UE, gNB | UP integrity (5G new) |
5.3 Key Derivation Functions
▶Key derivation uses KDF as specified in Annex A of this specification, based on HMAC-SHA-256. Inputs include:
- FC: Function code distinguishing derivation type
- P0..Pn: Input parameters (SUPI, serving network name, NAS uplink count, etc.)
- L0..Ln: Lengths of each parameter
Key derivations defined:
| Output | Input Key | FC | Parameters |
|---|---|---|---|
| KSEAF | KAUSF | 0x6C | Serving network name |
| KAMF | KSEAF | 0x6D | SUPI, ABBA parameter |
| KNASenc | KAMF | 0x69 | Algorithm type (NAS-enc), Algorithm ID |
| KNASint | KAMF | 0x69 | Algorithm type (NAS-int), Algorithm ID |
| KgNB | KAMF | 0x6E | NAS uplink count, Access type |
| KRRCenc | KgNB | 0x69 | Algorithm type (RRC-enc), Algorithm ID |
| KRRCint | KgNB | 0x69 | Algorithm type (RRC-int), Algorithm ID |
| KUPenc | KgNB | 0x69 | Algorithm type (UP-enc), Algorithm ID |
| KUPint | KgNB | 0x69 | Algorithm type (UP-int), Algorithm ID |
5.4 Security Algorithms
▶| Algorithm ID | Ciphering | Integrity |
|---|---|---|
| NEA0 / NIA0 | Null (no ciphering) | Null (no integrity) — forbidden for NAS |
| NEA1 / NIA1 | 128-SNOW3G | 128-SNOW3G |
| NEA2 / NIA2 | 128-AES (CTR) | 128-AES (CMAC) |
| NEA3 / NIA3 | 128-ZUC | 128-ZUC |
NIA0 (null integrity) is forbidden for NAS. NAS integrity protection must always be activated. NEA0 may be used only when explicitly permitted by operator policy.
6. Authentication Procedures
▶6.1 5G-AKA (5G Authentication and Key Agreement)
▶5G-AKA is the primary authentication mechanism. It is based on EPS-AKA but with enhanced home network control.
UE SEAF/AMF AUSF UDM/ARPF
│ │ │ │
│──Registration──►│ │ │
│ Request │ │ │
│ (SUCI/5G-GUTI)│── Nausf_UE │ │
│ │ Authenticate──►│ │
│ │ Request │──Nudm_UE │
│ │ │ Authenticate──►│
│ │ │ Get Request │
│ │ │ │── Generate AV
│ │ │ │ (RAND, AUTN,
│ │ │◄── 5G HE AV ────│ XRES*, K_AUSF)
│ │ │ (RAND, AUTN, │
│ │ │ HXRES*, K_SEAF)│
│ │◄── 5G SE AV ────│ │
│ │ (RAND, AUTN, │ │
│◄─Auth Request───│ HXRES*) │ │
│ (RAND, AUTN) │ │ │
│ │ │ │
│── Compute ── │ │ │
│ RES*, CK', IK' │ │ │
│ │ │ │
│──Auth Response─►│ │ │
│ (RES*) │── Compute │ │
│ │ HRES*=SHA256 │ │
│ │ Compare │ │
│ │ HRES*==HXRES* │ │
│ │── Nausf Confirm─►│ │
│ │ (RES*) │── Compare │
│ │ │ RES*==XRES* │
│ │◄── Success ─────│ (home control) │
│ │ (K_SEAF) │ │
Home Network Control: Unlike 4G EPS-AKA, in 5G-AKA the AUSF in the home network verifies RES* against XRES* (home confirmation). The serving network only compares HRES* vs HXRES* (hashed comparison). This prevents the serving network from impersonating the subscriber.
6.2 EAP-AKA' Authentication
▶EAP-AKA' (RFC 5448, RFC 9048) is the alternative authentication method for 5G. Key differences from 5G-AKA:
- Uses EAP framework — extensible and suitable for non-3GPP access
- AUSF acts as EAP server
- CK'/IK' derived using serving network name (AT_KDF_INPUT)
- Same final key hierarchy (KAUSF → KSEAF → KAMF)
When to use EAP-AKA': Mandatory for untrusted non-3GPP access via N3IWF. Optional for 3GPP access (operator choice). Both 5G-AKA and EAP-AKA' must be supported by the AUSF.
6.3 SUPI Concealment (SUCI)
▶The Subscription Permanent Identifier (SUPI) is never transmitted in cleartext over the air interface. Instead, the UE conceals it into a SUCI using the home network's public key.
| Aspect | Detail |
|---|---|
| Protection Scheme | ECIES (Profile A: Curve25519 / Profile B: secp256r1) |
| SUCI Format | SUPI Type | Home Network ID | Routing Indicator | Protection Scheme | HN Public Key ID | Scheme Output |
| De-concealment | Performed by SIDF (co-located with UDM) using HN private key |
| Null Scheme | Null protection scheme (scheme ID 0) sends SUPI in clear — for testing only, forbidden in production |
Mandatory in 5G: SUPI concealment is mandatory. Operators must provision ECIES public keys in the USIM. The null scheme shall not be used in production networks.
7. Security Between Serving and Home Network
▶Security between the serving network (SN) and home network (HN) addresses roaming scenarios and inter-PLMN communication. Key aspects:
- Home control of authentication: AUSF in HN verifies RES* (not just the SN)
- KAUSF storage: KAUSF is stored in HN AUSF for re-authentication and key derivation
- Serving Network Name binding: Keys are bound to the specific serving network name, preventing misuse across SNs
- SEPP: All inter-PLMN signaling via SBI goes through the Security Edge Protection Proxy (see clause 14)
8. Visibility and Configurability of Security
▶The UE shall indicate to the user:
- Whether the access link between UE and serving network is ciphered
- The serving network identity
The home operator shall be able to configure:
- Whether to accept a UE connection if integrity protection of NAS is not supported
- The preferred algorithm priority lists for NAS and AS ciphering/integrity
- Whether to use 5G-AKA or EAP-AKA' as the preferred authentication method
9. Security for NAS Signaling
▶9.1 NAS Security Mode Command Procedure
▶The NAS Security Mode Command (SMC) procedure activates NAS security between UE and AMF. The procedure:
- AMF selects algorithms based on UE capabilities and operator policy
- AMF derives KNASenc and KNASint from KAMF
- AMF sends NAS Security Mode Command (integrity protected with KNASint)
- UE verifies integrity, derives the same keys, responds with NAS Security Mode Complete (ciphered + integrity protected)
NAS integrity is mandatory from the first SMC onwards. All subsequent NAS messages must be integrity protected. Ciphering is activated simultaneously.
9.2 NAS COUNT and Replay Protection
▶NAS messages include a NAS COUNT (sequence number) for replay protection. Key rules:
- Separate uplink and downlink NAS COUNTs
- NAS COUNT = NAS overflow counter (16 bits) || NAS sequence number (8 bits)
- If NAS COUNT wraps around, a new NAS security context must be established
- On receiving a message with a NAS SQN lower than expected, the message is discarded
10. Access Stratum (AS) Security
▶AS security protects the radio interface between UE and gNB. Activated via the AS Security Mode Command.
| Protection | Key | Mandatory | Notes |
|---|---|---|---|
| RRC Ciphering | KRRCenc | Yes | All RRC signaling after AS SMC |
| RRC Integrity | KRRCint | Yes | Mandatory, cannot be deactivated |
| UP Ciphering | KUPenc | Yes | DRB data ciphering |
| UP Integrity | KUPint | Per-DRB | New in 5G; rate limited; operator policy + UE capability |
User Plane Integrity Protection (UPIP): This is a key 5G enhancement. UP integrity is mandatory for the gNB to support. Activation per DRB is policy-based. A maximum data rate limit for UPIP is negotiated during PDU session establishment.
11. Security for Inter-system Handover
▶Covers security during handover between 5G NR and 4G E-UTRA (LTE):
- 5G → 4G: KAMF is mapped to KASME for EPS use. CK'/IK' are derived for the target eNB.
- 4G → 5G: Mapped security context from EPS. Re-authentication is recommended by the 5G network after handover for forward security.
- Idle mode: When UE moves between systems in idle mode, the target system derives keys from the mapped security context.
Forward Security: After handover from 4G to 5G, a fresh 5G-AKA or EAP-AKA' authentication should be performed to ensure forward security (previous 4G keys cannot derive future 5G keys).
12. Security for Non-3GPP Access (N3IWF / TNGF / W-AGF)
▶Non-3GPP access (WiFi, wired) connects to 5GC via the N3IWF (untrusted), TNGF (trusted non-3GPP), or W-AGF (wireline).
| Entity | Access Type | Protocol | Authentication |
|---|---|---|---|
| N3IWF | Untrusted WiFi | IKEv2/IPsec | EAP-AKA' over IKEv2 (mandatory) |
| TNGF | Trusted Non-3GPP | 802.1X/EAP | EAP-AKA' or 5G-AKA via EAP-5G |
| W-AGF | Wireline (FN-RG/5G-RG) | PPPoE/IPoE | Line-based or EAP-AKA' |
N3IWF Security: An IPsec tunnel (ESP) is established between UE and N3IWF after EAP-AKA' authentication. NAS messages between UE and AMF are carried inside this IPsec tunnel. The NAS security (ciphering + integrity) operates on top of the IPsec protection.
13. Security for Service-Based Architecture (SBA)
▶Key Section: This is the clause most referenced by TS 33.117 test cases (TC_TLS_PROTECTION, TC_AUTHORIZATION_TOKEN, TC_CLIENT_CREDENTIALS). All SBA NF security requirements originate here.
13.1 TLS Protection on SBI
▶All HTTP/2 communication on the SBI shall be protected using TLS. Requirements:
- TLS 1.2 (RFC 5246) or TLS 1.3 (RFC 8446) — TLS 1.3 is preferred
- Mutual authentication using X.509 certificates per TS 33.310
- Certificate profiles per TS 33.310 clause 6.1
- Cipher suites restricted to those in TS 33.210 Annex E
| TLS Version | Mandatory Cipher Suites |
|---|---|
| TLS 1.2 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
| TLS 1.3 | TLS_AES_128_GCM_SHA256TLS_AES_256_GCM_SHA384 |
13.2 NF Service Access Tokens (OAuth 2.0)
▶NF service authorization uses OAuth 2.0 (RFC 6749) with the NRF as the authorization server.
NF Consumer NRF NF Producer
│ │ │
│──Token Request────►│ │
│ (NF Instance ID, │ │
│ target NF type, │ │
│ requested scope) │ │
│ │── Validate request │
│ │ Check authorization │
│ │ Generate JWT token │
│◄──Access Token─────│ │
│ (signed JWT) │ │
│ │ │
│──Service Request─────────────────────────────►│
│ (Authorization: │ │
│ Bearer <token>) │ │── Validate JWT
│ │ │ (sig, claims,
│◄──Service Response───────────────────────────│ expiry, scope)
Access token is a signed JWT (RFC 7519) containing claims per TS 29.510:
| Claim | Description | Validated By |
|---|---|---|
iss | Issuer — NRF NF Instance ID | NF Producer (must be known NRF) |
sub | Subject — NF Consumer NF Instance ID | NF Producer (must match TLS client cert) |
aud | Audience — NF Producer NF type or specific NF Instance ID | NF Producer (must match self) |
scope | Authorized services/operations | NF Producer (must cover requested service) |
exp | Expiration time | NF Producer (must not be expired) |
producerSnssaiList | Allowed S-NSSAIs (if applicable) | NF Producer (network slicing constraint) |
producerNfSetId | NF Set targeted | NF Producer (set-level authorization) |
TR 33.926 §5.3.8.1 Misuse by Authorized Users — token reuse, cross-NF abuse ▶
13.3 Client Credentials Assertion
▶When requesting an access token from the NRF, the NF Consumer presents a client credentials assertion per RFC 7523. This is a signed JWT proving the NF Consumer's identity.
| Assertion Claim | Value | Validation |
|---|---|---|
iss | NF Consumer NF Instance ID | Must match TLS client certificate |
sub | NF Consumer NF Instance ID | Must equal iss |
aud | NRF NF Instance ID or NRF URI | NRF validates against own identity |
exp | Expiration | Must not be expired |
jti | Unique token ID | Optional: for replay detection |
13.4 Authorization Policies and Scope
▶The NRF determines authorization based on:
- NF type-level: NF Consumer type X can access NF Producer type Y
- Service-level: Specific service operations authorized (e.g., Nsmf_PDUSession_Create)
- Instance-level: Specific NF instance authorized for specific producer instance
- Slice-level: Authorization constrained to specific S-NSSAIs
Scope validation is critical: The NF Producer must validate that the access token's scope covers the specific service operation being requested. Failure to validate scope enables unauthorized service access.
14. Security Edge Protection Proxy (SEPP)
▶The SEPP is deployed at the border of each PLMN to protect inter-PLMN signaling in 5G SBA roaming. See TS 33.522 for SCAS requirements.
VPLMN HPLMN
┌──────────────┐ ┌──────────────┐
│ NF Consumer │ │ NF Producer │
│ (e.g. AMF) │ │ (e.g. AUSF) │
└──────┬───────┘ └──────┬───────┘
│ SBI (internal) │ SBI (internal)
▼ ▼
┌──────────────┐ N32 TLS/PRINS ┌──────────────┐
│ vSEPP │◄────────────────────────────►│ hSEPP │
│ │ (application layer │ │
│ • Topology │ information protection) │ • Topology │
│ hiding │ │ hiding │
│ • Message │ N32-c: TLS (handshake) │ • Message │
│ filtering │ N32-f: JOSE (per-IE │ filtering │
│ │ protection) │ │
└───────────────┘ └───────────────┘
| Feature | Description |
|---|---|
| N32-c | Control plane between SEPPs — initial handshake using TLS to negotiate parameters and exchange capabilities |
| N32-f | Forwarding plane — actual inter-PLMN SBI messages. Protected using JOSE (JWE+JWS) per-IE or TLS |
| PRINS | Protocol for N32 Interconnect Security — application-layer protection that enables modification-resistant IEs |
| Topology Hiding | SEPP replaces internal NF addresses with scrambled identifiers before forwarding to the other PLMN |
| IE Protection Policy | Per-IE cipher/integrity policy — some IEs encrypted, some integrity-protected, some both, some neither (for IPX use) |
15. Network Slicing Security
▶Key security requirements for network slicing:
- Slice isolation: Compromise of one slice must not affect other slices
- NSSAI handling: The Requested NSSAI is sent in the Registration Request. The AMF validates it.
- NSSAAF: Network Slice-Specific Authentication and Authorization Function — performs secondary slice-specific authentication
- S-NSSAI confidentiality: S-NSSAI values should be protected in transit (via NAS ciphering)
Slice-Specific Authentication (NSSAAF)
Clause 16.2
Procedure
- UE requests a specific S-NSSAI in the PDU Session Establishment Request
- AMF triggers slice-specific authentication via NSSAAF
- NSSAAF performs EAP-based authentication with the AAA server of the slice tenant
- On success, UE is authorized to use the requested network slice
- On failure, the UE is denied access to that specific slice
16. User Plane Security
▶User plane security covers the protection of user data in transit between UE and the network.
16.x GTP-U Security Considerations
▶GTP-U is used on the N3 (gNB↔UPF), N9 (UPF↔UPF), and S1-U/S5/S8 (4G) interfaces for user plane transport. Security considerations:
| Interface | Endpoints | Protocol | Security Requirement |
|---|---|---|---|
| N3 | gNB ↔ UPF | GTP-U | IPsec per TS 33.210 (if not on trusted transport) |
| N9 | UPF ↔ UPF | GTP-U | IPsec per TS 33.210 (if not on trusted transport) |
| N4 | SMF ↔ UPF | PFCP | TLS or IPsec (control plane for UP) |
| S1-U | eNB ↔ SGW | GTP-U | IPsec per TS 33.210 |
| S5/S8 | SGW ↔ PGW | GTP-U/C | IPsec per TS 33.210 (S8: inter-PLMN mandatory) |
GTP-U filtering is crucial at network boundaries. See TS 33.117 §4.2.6 TC_GTP-U_FILTERING and TC_GTP-C_FILTERING for specific SCAS test cases. The TS 33.513 (UPF SCAS) adds UPF-specific GTP filtering tests.
TR 33.926 §5.3.6.15 Lack of GNP traffic isolation ▶
TR 33.926 §5.3.7.3 Insecure Network Services ▶
17. Lawful Intercept Considerations
▶TS 33.501 requires that security mechanisms do not prevent lawful intercept. Key principles:
- LI architecture is specified in TS 33.127 and TS 33.128
- Encryption keys used for UE traffic must be available to LI functions when legally mandated
- SUCI concealment: the SIDF can provide SUPI to authorized LI entities
- End-to-end encryption between UEs is outside the scope of 3GPP security and may not be interceptable