DTLS specified in RFC 9147 is used in 5G system in standalone mode to protect the following:

• N2 interface (see clause 9.2 of TS 33.501).
• Xn interface (see clause 9.4 of TS 33.501).
• DIAMETER or GTP-based interfaces (see clause 9.5 of TS 33.501).
• gNB internal interfaces (see clause 9.8 of TS 33.501).

Security profiles for DTLS implementation and usage in 3GPP are given in clause 6.2 of TS 33.210 and the certificate profile is given in clause 6.1.3a of TS 33.310. DTLS employs symmetric cryptography for confidentiality and integrity protection. DTLS employs asymmetric cryptography for digital signature and key agreement.

TLS specified in RFC 8446 is used in 5G system in standalone mode to protect the following:

• NIDD interfaces (see clause 6.16.3 of TS 33.501).
• DIAMETER or GTP-based interfaces (see clause 9.5 of TS 33.501).
• NEF - AF interface (see clauses 12.2 and 12.3 of TS 33.501).
• Interfaces between network functions (see clauses 13.1, 13.2, 13.5 of TS 33.501).
• N32 interface (see clause 13.2 of TS 33.501).
• Network slice management interfaces (see clauses 15.2 and 15.3 of TS 33.501).
• Message Service interfaces for MIoT over the 5G System (see clauses Y.2 - Y.4 of TS 33.501).
  Security profiles for TLS implementation and usage in 3GPP are given in clause 6.2 of TS 33.210 and the certificate profile is given in clause 6.1.3a of TS 33.310.

TLS employs symmetric cryptography for confidentiality and integrity protection. TLS employs asymmetric cryptography for digital signature and key agreement.

EAP-TLS [5] [6] is used in 5G system in standalone mode to realise the following:

• Mutual authentication between UE and AUSF (see Annex B, Annex I of TS 33.501)
• Mutual authentication between UE and AAA (see Annex I of TS 33.501)
• Mutual authentication between N5GC and AUSF (see Annex O of TS 33.501)

The 3GPP TLS protocol profile related to supported TLS versions and supported TLS cipher suites in 3GPP networks is specified in clause 6.2 of TS 33.210. The 3GPP profile of TLS certificates is specified in clause 6.1.3a of TS 33.310. EAP-TLS employs asymmetric cryptography for authentication and key agreement. EAP-TLS employs symmetric cryptography for authentication and key agreement. EAP-TLS employs hash function for session key derivation.

ECIES is used in 5G system in standalone mode for the following:

• Confidentiality and Integrity Protection of the SUPI (see Annex C.3 of TS 33.501).

The ECIES profiles follow the terminology and processing specified in SECG version 2 [7] and [8]. The security profiles for the ECIES implementation and usage in 3GPP is given in clause C.3.4 of TS 33.501. ECIES employs asymmetric cryptography for the key agreement of the symmetric keys. ECIES employs symmetric cryptography for the confidentiality and integrity protection of the SUPI.

PKI is used in 5G system in standalone mode for the following:

• Issuing of X.509 certificates (see clause 4 of TS 33.310).
• PKI architecture for NDS/AF (see clause 5.1 of TS 33.310).

PKI employs asymmetric cryptography for certificate signing and verification. PKI employs hash function for computation of digests.

Online Certificate Status Protocol (OCSP) specified in RFC 6960 is used in 5G system in standalone mode for the following:

• Certificate status request, i.e., OCSP stapling (see clause B.2.2 of TS 33.501).
• Revocation of subscriber certificates (see clause B.2.2 of TS 33.501).

OCSP and the related profiles are in clause 6.1b of TS 33.310. OCSP employs asymmetric cryptography for digital signing and signature verification. OCSP employs hash algorithms for computation of digests.

The QUIC and MPQUIC are used in 5G system in standalone mode for the following:

• QUIC is used for the security of connection between UPF and AS proxy (see clause 18 of TS 33.501).
• MPQUIC steering functionality is used for ATSSS (see Annex AA of TS 33.501).

For the QUIC establishment, the RFC 9001 mandates the use of TLS with the exception of TLS_AES_128_CCM_8_SHA256.

The COSE [10] is used in 5G system in standalone mode for the following:

• OSCORE [12] for cryptographic algorithm selection between UE and BSE (reference point Ua) (see clause P.3.3 of TS 33.220).

COSE employs asymmetric cryptography for digital signature and key agreement. COSE employs symmetric cryptography for confidentiality and integrity protection. COSE employs hash functions for session key derivation.

MIKEY-SAKKE is used in the 5G system to securely transport cryptographic keys for Mission Critical Services. It is used in the following scenarios:

• Group Master Keys (GMKs) from a Group Management Server to a Group Management Client on a MC UE (see Annex E clause E.2 of TS 33.180)
• Private Call Keys (PCKs) between MC UEs (see Annex E clause E.3 of TS 33.180)
• Client-Server keys (CSKs) between MCX Server and MC client (see Annex E clause E.3 of TS 33.180)
• Multicast Signalling Keys (MuSiK) from MCX Servers to MC clients (see Annex E clause E.3 of TS 33.180)

Security profiles for MIKEY-SAKKE are left for implementation. MIKEY-SAKKE is specified in RFC 6509. MIKEY-SAKKE employs asymmetric cryptography for key distribution.

IKEv2 protocol is specified in RFC 7296 to perform authentication and setup Security Associations (SA) for IPsec tunnels. The IPsec ESP protocol is described in clause 4.2.15. IKEv2 is used in 5G system to provide security for the following:

• Untrusted non-3GPP access to the 5G core network (see clause 7 of TS 33.501) and trusted non-3GPP access to the 5G core network (see clause 7 of TS 33.501)
• IP based interfaces for 5GC and 5G-AN according to NDS/IP (see clause 9 of TS 33.501)
• N2 interface between the AMF and the 5G-AN (see clause 9.2 of TS 33.501)
• N3 interface between the UPF and 5G-AN (see clause 9.3 of TS 33.501)
• Xn interface between 5G-AN (see clause 9.4 of TS 33.501)
• F1 and E1 of the gNB internal interfaces (see clause 9.8 of TS 33.501)
• Non-SBA interfaces internal to 5GC and between PLMNs (see clause 9.9 of TS 33.501)
• F1 interface between the IAB-node (gNB-DU) and the IAB-donor-CU (see clause M.3.3 and M.5 of TS 33.501)

Security profiles for IKEv2 implementation and usage in 3GPP are given in clauses 5.2, 5.4, and 5.6 of TS 33.210 and clauses 5, 6.2, and 7.5 of TS 33.310. IKEv2 employs symmetric cryptography for confidentiality and integrity protection. IKEv2 employs asymmetric cryptography for digital signature and key agreement. IKEv2 employs both symmetric cryptography and asymmetric cryptography for authentication.

The PDCP security protocol between the UE and the NG-RAN is responsible for the security protection of the following scenarios in 5G system:

• RRC integrity and confidentiality protection between UE and gNB (see clause 6.5.1 and 6.5.2 of TS 33.501).
• User plane data integrity and confidentiality protection between UE and gNB (see clause 6.6.3 and 6.6.4 of TS 33.501).

PDCP security protocol employs symmetric cryptography for confidentiality and integrity protection.

The NAS security mechanisms are to protect NAS signaling and data between the UE and the AMF over the N1 reference point in 5G system:

• NAS signaling integrity and confidentiality protection between UE and AMF (see clause 6.4.3 and 6.4.4 of TS 33.501).
• Integrity and confidentiality protection for small user data or SMS as payload of a NAS message between UE and AMF (see clauses 6.16.1 and 6.4.7 of TS 33.501).

NAS security protocol employs symmetric cryptography for confidentiality and integrity protection.

EAP-AKA' enables mutual authentication between the UE and AUSF and provides keying material that can be used between the UE and the serving network in subsequent security procedures. The long term key K and the SUPI are preconfigured in the USIM (in the UE) and in the UDM/ARPF. EAP-AKA' is specified in RFC 5448. The 3GPP 5G profile for EAP-AKA' is specified in the normative Annex F of TS 33.501. KDF for key generation is HMAC-SHA-256 as per Annex B.2.0 of TS 33.220. EAP-AKA' requires functions as described for 128 Bit MILENAGE in TS 35.205, 128 Bit or 256 Bit TUAK in TS 35.231 and in TS 35.234 for 256 Bit MILENAGE. EAP-AKA' employs symmetric cryptography for authentication and key agreement. EAP-AKA' employs hash function for session key derivation.

5G-AKA enables mutual authentication between the UE and AUSF with proof of successful authentication of the UE from the visited network. 5G-AKA provides keying material that can be used between the UE and the serving network in subsequent security procedures. The long term key K and the SUPI are preconfigured in the USIM (in the UE) and in the UDM/ARPF.

• 5G-AKA is specified in TS 33.501.
• KDF for key generation is HMAC-SHA-256 as per Annex B.2.0 of TS 33.220.

5G-AKA requires functions as described for 128 Bit MILENAGE in TS 35.205, 128 Bit or 256 Bit TUAK in TS 35.231 and in TS 35.234 for 256 Bit MILENAGE. 5G-AKA employs symmetric cryptography for authentication and key agreement. 5G-AKA employs hash function for session key derivation.

IPsec ESP specified in RFC 4303, RFC 8221, RFC 8750 is used in 5G system to provide security for the following:

• Untrusted non-3GPP access to the 5G core network (see clause 7 of TS 33.501) and trusted non-3GPP access to the 5G core network (see clause 7 of TS 33.501)
• IP based interfaces for 5GC and 5G-AN according to NDS/IP (see clause 9 of TS 33.501)
• N2 interface between the AMF and the 5G-AN (see clause 9.2 of TS 33.501)
• N3 interface between the UPF and 5G-AN (see clause 9.3 of TS 33.501)
• Xn interface between 5G-AN (see clause 9.4 of TS 33.501)
• F1 and E1 of the gNB internal interfaces (see clause 9.8 of TS 33.501)
• Non-SBA interfaces internal to 5GC and between PLMNs (see clause 9.9 of TS 33.501)
• F1 interface between the IAB-node (gNB-DU) and the IAB-donor-CU (see Annex M.3.3 and M.5 of TS 33.501)
• Policy discrimination of GTP-C, GTP-U and protection of GTP-C transport protocol (see Annex B of TS 33.210)
• Protection of IMS protocols and interfaces for all SIP signalling traversing inter-security domain boundaries. (see Annex C of TS 33.210)
• Protection of UTRAN/GERAN IP transport protocols and interfaces for all RANAP and RNSAP messages traversing inter-security domain boundaries. (see Annex D of TS 33.210)

Security profile for IPsec ESP implementation in 3GPP are given in clause 5.3 of TS 33.210. IPSec ESP employs symmetric cryptography for confidentiality, integrity and replay protection. Keying happens using IKEv2 (Internet Key Exchange Protocol Version 2 (IKEv2) as mentioned in clause 4.2.10.

The KDF is used in 5G system in standalone mode and is defined in the normative Annex A of TS 33.501.

• The generic KDF for the purpose of a cryptographic key computation is specified in the normative Annex B.2 of TS 33.220.

The KDF employs hash function for key derivation.

JSON Web Encryption (JWE) specified in RFC 7516 and/or JSON Web Signature (JWS) specified in RFC 7515 are used in 5G system in standalone mode to protect the following:

• N32 interface (see clause 13.2 of TS 33.501).
• NF service access (see clause 13.4 of TS 33.501).

Profiles for JWE/JWS implementation and usage in 3GPP are given in clause 6.3 of TS 33.210. JWE/JWS employ symmetric cryptography for confidentiality and integrity protection. JWE/JWS employ asymmetric cryptography for digital signature and key agreement.

EAP-TTLS is an authentication protocol specified in RFC 5281. EAP-TTLS is used in 5G system to provide security for the following:

• Security of UE onboarding in SNPNs (clause I.9 of TS 33.501)
• Primary authentication using EAP-TTLS in SNPNs (Annex U of TS 33.501)
• Authentication of AUN3 devices using additional EAP methods (clause Z.2 of TS 33.501)

EAP-TTLS employs both asymmetric cryptography and symmetric cryptography for authentication and key agreement. EAP-TTLS employs hash function for session key derivation.

The OAuth 2.0 protocol is an authorization framework enabling a third-party application to obtain limited access to an HTTP service as specified in RFC 6749. The usage of bearer tokens in OAuth 2.0 and JSON Web Token (JWT) are specified in RFC 6750 and RFC 7519 respectively. The former requires TLS (see also in the clause 4.2.2) to secure transmission of token whereas the latter uses JSON Web Signature (JWS) (see also in the clause 4.2.17) for integrity protection of token. OAuth 2.0, using JWT bearer token, is used in 5G system to provide security for the following:

• Authorization of Application Function (clause 12.4 of TS 33.501)
• Authorization for the Service Based Interface (clauses 13 and 14 of TS 33.501 and clause 6.7 of TS 29.500)
• Authentication for the management service for network slices (clause 15 of TS 33.501)
• Authorization of NF Service for network automation (clause X.2 of TS 33.501)

Cryptographic algorithms, features and usage types for TLS and JWT are described in clauses 4.2.2 and 4.2.17 respectively.

The following Table summarizes the security related protocols used in 3GPP employing symmetric cryptographic algorithms including hash functions (5G System).

The following Table summarizes the security related protocols used in 3GPP employing asymmetric cryptographic algorithms (5G System).