This section presents all the standalone security functionalities. Security aspects related to other features are reported in the relevant section.

Summary based on the input provided by China Mobile in SP-220289. Authentication and key management for applications based on 3GPP credential in 5G (AKMA) is a cellular-network-based delegated authentication system specified for the 5G system, helping establish a secure tunnel between the end user and the application server. Using AKMA, a user can log in to an application service only based on the 3GPP credential which is the permanent key stored in the user's tamper-resistant smart card UICC. The application service provider can also delegate the task of user authentication to the mobile network operator by using AKMA. The AKMA architecture and procedures are specified by SA3 in TS 33.535, with the related study showing how its general principles are derived documented in TR 33.835. The AKMA feature introduces a new Network Function into the 5G system, which is the AKMA Anchor Function (AAnF). Its detailed services and API definitions are specified by CT3 in TS 29.535. Earlier generations of cellular networks include two similar standards specified by SA3, which are generic bootstrapping architecture (GBA) and battery-efficient security for very low throughput machine type communication devices (BEST). Since the AKMA feature is deemed as a successor of these systems, the work is launched by SA3 without the involvement of stage 1.

Summary based on the input provided by Qualcomm in SP-220620. The work on AKMA TLS protocol profiles provides the details on how to use the newly introduced AKMA key (see [4]) to provide secure TLS connection between the UE and an Application Function (AF) in the network. The AKMA WID [4] introduced a method of generating keys for use between a UE and an Application Function (AF) in the network. These keys are generated from a key derived by an authentication run over the 5G core (see [2]). The "AKMA TLS protocol profiles" work item specifies how to use these AKMA key to provide secure TLS connections, either using certificate-based TLS and HTTP Digest with the AKMA key in the TLS tunnel or using symmetric key TLS using the AKMA key. The specification of the profiles is based on the methods standardised to utilise GBA keys in TS 33.222 and TS 24.109. The stage 2 of the AKMA TLS protocol profiles work is specified in TS 33.535 while the stage 3 is contained in TS 24.109.

Summary based on the input provided by Vodafone in RP-221340. Release 15 NR and 5G Core enabled optional support for the integrity protection of user plane data. In Release 16, it was made mandatory for UEs to support User Plane Integrity Protection (UPIP) in NR at the full data rate that the UE supports in both the Uplink and Downlink. This provides protection against certain security attacks but only for NR capable devices while using NR and the 5G Core. In Release 17, the SA 3 work item "User Plane Integrity Protection for LTE" was agreed in SP-210105 with the intention of protecting LTE devices from these security attacks. Subsequently, in RP-213669, TSG-RAN agreed the Building Block WID "User Plane Integrity Protection support for EPC connected architectures" to enable full data rate Uu interface UPIP for EPS, but only on EN-DC capable devices. This provides useful protection to NR capable smartphones in case they are, for example, forced off NR and onto an E-UTRA-only connection or an EN-DC connection. The overall security architecture is specified in TS 33.401 and system architecture details are specified in TS 23.501 and TS 23.401. The UE indicates its support for EPS UPIP in the UE Network Capability sent in NAS signalling (TS 24.301) from the UE to the MME. The MME stores this UPIP support information and sends it to the eNB in the S1AP Initial Context Setup Request and Handover Request messages. The eNB uses this indication (and not any information in the UE Radio Access Capabilities IE) to determine whether the UE supports EPS UPIP. The SMF+PGW-C may supply the MME with a security policy (UPIP required/preferred/not needed). The MME stores this policy information and passes it onto the eNB on a per-EPS bearer basis in the Security Indication IE. If the eNB does not receive any security policy, the eNB can be configured with a default UPIP policy to use (e.g. "UPIP preferred"). X2AP (TS 36.423), and S1AP (TS 36.413) signalling supports UPIP continuity at handover. X2AP supports the use of UPIP in the SgNB when EN-DC is in use. E1AP interface signalling (TS 37.483) supports UPIP when the eNB is split into eNB-Control Plane and eNB-User Plane functions. At X2, S1 (intra and inter-MME) and inter-RAT handovers, mechanisms are specified in X2AP and S1AP to ensure that EPS bearers with a security policy of "UPIP required" are not handed over to eNBs that do not support UPIP. RRC signalling (TS 36.331 and TS 38.331) enables the use of UPIP with the UE in both EN-DC and LTE-only configurations. As described in the LS from RAN2 to SA3 in R2-2203663: UPIP for the EPC connected architectures uses NR PDCP and is configured in following way:

• (as is done for legacy LTE UE) an LTE algorithm code point is configured in field integrityProtectionAlgorithm in IE SecurityAlgorithmConfig in the TS 36.331 SecurityModeCommand message, and this is used to derive KUPint (and also to derive KUPEnc, as for legacy LTE UE).
• The NR algorithm code point (corresponding to the LTE algorithm code point used in the SecurityModeCommand) indicated by the integrityProtAlgorithm included in the securityConfig in the TS 38.331 RadioBearerConfig is used to configure the UP IP algorithm applied by NR PDCP to perform integrity protection.
• The integrityProtection indicated in pdcp-Config in the DRB-ToAddMod(list) in the TS 38.331 RadioBearerConfig is used to activate the UP IP for a DRB using the configured algorithm, which can be done only at DRB setup. Consequently, UP IP activation/deactivation for a DRB can be changed only by DRB-release-and-add.

Summary based on the input provided by Nokia in SP-220426 (which replaced CP-220150). Non-seamless WLAN offload (NSWO) is an optional capability of a UE supporting WLAN radio access. A UE supporting non-seamless WLAN offload may, while connected to WLAN access, route specific IP flows via the WLAN access without traversing the 3GPP core network. For authentication 5G NSWO uses EAP-AKA' as specified in IETF RFC 5448. A new network function, called NSWOF, supports authentication for NSWO in 5GS. The NSWOF interfaces the WLAN access network via SWa and the AUSF via the Nausf service-based interface (SBI). The AUSF retrieves NSWO-specific authentication information from the UDM via the Nudm service-based interface. In addition, the USIM and/or ME can be configured to use 5G NSWO. 5G NSWO co-existence with EPS NSWO is considered. Also, different configurations for NSWO roaming are described.

Summary based on the input provided by Ericsson in SP-220321. The existing Generic Bootstrapping Architecture (GBA) was firstly introduced in Rel-6 and prior to Rel-17 the architecture included network functions interacting with each other via dedicated reference point interfaces. The integration of the Generic Bootstrapping Architecture (GBA) to the 5G Core (5GC) introduces Service Based Interfaces (SBA) for the related GBA Network Functions as well as specific GBA services for the User Data Management (UDM) network function in 5GC. In this way GBA can be used in 5GC deployments. The 3GPP authentication infrastructure employed in GBA includes Home Network (HN) functions User Equipment (UE) functions and the 3GPP AKA (Authentication and Key Agreement) protocol. This infrastructure is a very valuable asset of 3GPP operators and could be leveraged to enable application functions in the network and on the User Equipment (UE) side to establish shared cryptographic material based on 3GPP credentials. This is the motivation and purpose of the Generic Bootstrapping Architecture (GBA) and GBA Push features developed in 3GPP since Rel-6. The GBA architecture in releases prior to Rel-17 includes a Bootstrapping Server Function (BSF) which is the anchor of the cryptographic key hierarchy, the Home Subscriber System (HSS), which handles the user subscriptions and provides authentication vectors to the BSF, UE applications and Network Application Functions (NAFs). GBA includes a bootstrapping protocol for authentication and key agreement for a root security key between the UE and BSF and a framework of application session protocols (Ua protocols) to establish an application security key between a UE and a NAF. The application security key is derived from the bootstrapping key. The GBA Push feature includes a protocol between the NAF and the UE in order to establish the application security key with a more efficient message exchange suitable for constrained devices. GBA is specified to support at least the following Diameter-based reference point interfaces: (a) Zh between the BSF and HSS for mutual authentication between the HN and the UE, (b) Zn between the BSF and NAF for the application security key establishment and (c) Zpn between the BSF and a GBA Push enabled NAF (Push-NAF) for a combined mutual authentication and application security key establishment. The use of these interfaces has allowed GBA to be used in 3G and also in 4G core networks since the HSS in 3G and 4G supported Diameter-based interfaces. With the advent of 5G, the 5G Core (5GC) has introduced Network Functions which expose SBA interfaces and among other network functions a new subscription management network function, the User Data Management (UDM). Enabling GBA and GBA Push functionality to be used in 5GC, resulted in the inclusion of the GBA and GBA Push functions in SBA as well as the specification of the SBA interfaces for the BSF, HSS and UDM. More specifically, a Service Based Interface (SBI) capable BSF exposes not only the aforementioned reference point interfaces but also SBA interfaces towards an SBI capable NAF. An SBI capable HSS provides an SBA interface for the BSF to retrieve authentication vectors and other GBA related subscription information for the GBA and GBA Push procedures. Finally, the UDM exposes a new service operation for an SBI capable BSF to retrieve authentication vectors provided by the UDM.

Summary based on the input provided by KPN in SP-221202. This work item updates the BEST feature (Battery Efficient Security for very low Throughput Machine Type Communication (MTC) devices) for use in 5G networks. The original BEST feature (based on WI 730050 BEST_MTC_Sec) was defined for LTE and made use of LTE architecture and a UMTS based key agreement procedure. The result of the work item is a BEST feature applicable to a range of architectures and key agreement procedures:

• the original LTE architecture using UMTS based key agreement procedure;
• an updated LTE architecture using LTE based key agreement procedure;
• a 5G architecture using 5G based key agreement procedure;
• an LTE or 5G architecture using GBA as key agreement procedure;
• a 5G architecture using AKMA as key agreement procedure; and
• a 5G architecture using a proprietary key agreement procedure.