For authentication and authorization of a UE in 5G LAN communication, the secondary authentication procedures between UE and external data networks via the 5G Network as described in clause 11 shall apply.
The 5G TSC service is described in TS 23.501. It allows the 5G System to be integrated transparently as a bridge in an IEEE TSN network , where the 5GS system acts as one or more TSN Bridges of a TSN network.
After the 5GS TSC-enabled UE is authenticated and data connection is set up, any data received from a TSC bridge or another 5GS TSC-enabled UE shall be transported between DS-TT (in the UE) and NW-TT (in the UPF) in a protected way using the mechanisms for UP security as described in clause 6.6.
The UP security enforcement information shall be set to "required" for data transferred from gNB to a 5GS TSC-enabled UE. This is also applicable to the (g)PTP messages sent in the user plane.
Any AF that has knowledge of deterministic application requirements is able to request TSC services from the 5GS by interfacing with NEF, and as authorized, can be notified of pertinent network events. The security solution as described in clause 12 shall apply.
This Annex provides the security procedures applied to NR IAB architecture and functional entities for supporting wireless backhauling of NR base stations.
The overall stage 2 description for IAB architecture and functional entities are described in TS 23.501 and TS 38.401.
The security requirements and security procedures applied to IAB in EN-DC architecture are defined in both TS 33.401 and in the present document. The security requirements and security procedures between the IAB-node and the MeNB (i.e., when the IAB-node connects via E-UTRA to a MeNB), are defined in TS 33.401 and between the IAB-node and the SgNB (F1 interface) are defined in this clause.
The IAB-node (IAB-UE) shall support ciphering, integrity protection and replay protection of NAS-signalling between the IAB-node (IAB-UE) and the 5GC supporting IAB architecture.
The IAB-node (IAB-UE) shall support ciphering, integrity protection and replay protection of RRC-signalling between the IAB-node (IAB-UE) and the IAB donor.
Mutual authentication between the IAB-node (IAB-UE) and the 5GC supporting IAB architecture shall be supported.
The 5GC supporting IAB architecture shall support ciphering, integrity protection and replay protection of NAS-signalling between the 5GC supporting IAB architecture and the IAB-node (IAB-UE).
Mutual authentication between the 5GC supporting IAB architecture and the IAB-node (IAB-UE) shall be supported.
The 5GC shall decide whether the IAB-node is authorized to operate as IAB-node (gNB-DU).
IAB-node, consists of a UE function (referred to as IAB-UE) and gNB-DU function . IAB integration procedure consists of 3 phases detailed in TS 38.401.
Phase-1: IAB-UE part setup:
The IAB-UE performs registration procedure to the network as a UE as described in TS 23.501 and TS 23.502 in order to register to the 5GC and consequently, the NAS and AS security are established between the IAB-node and 5GC.
Phase-2: BH RLC channel establishment and routing update:
The BH RLC channels and the BAP layer are established and configured in the IAB-node by the IAB-donor using the secured RRC signalling to support routing between the IAB-node and the IAB-donor.
Phase-3: gNB -DU part setup:
F1 security establishment for IAB is performed over the RLC channel.
The Phase-1 results in IAB-UE registration and consequently, AS security establishment between the IAB donor and IAB-node, Phase-2 results in configuration of the IAB-node securely using the established AS security and Phase-3 results in the establishment of secure F1 interface between the IAB-donor and IAB-node.
The IAB-UE function shall behave as a UE, and shall reuse the UE procedures specified in this document for the primary authentication (see clause 6), key derivation and distribution scheme, subscription credential(s) storage requirements, NAS security and AS security.
Authorization of IAB-nodes shall be performed by the 5G core network supporting IAB architecture as described in TS 23.501.
The F1 interface connects the IAB-node (gNB-DU) to the IAB-donor-CU. It consists of the F1-C for control plane and the F1-U for the user plane.
F1 security for IAB is established using the security mechanisms for the F1 interface as specified in clause 9.8.2 of the present document, with IAB node taking the role of gNB-DU and IAB-donor-CU taking the role of gNB-CU.
In addition to the security mechanisms specified in clause 9.8.2 of the present document for the F1 interface, the IKEv2 Pre-shared Secret Key (PSK) authentication shall be supported. When IKEv2 performs a PSK authentication, in the IKE_AUTH request message, the IAB node shall set the ID type to ID_KEY-ID and set its value to PSK ID.
Additionally, to support a flexible plug and play of IAB-node and IAB-donor without a pre-configuration of the PSK(s), dynamic PSK computation for IKEv2 PSK authentication may also be supported. When dynamic PSK is used, the IAB-node and the IAB-donor shall calculate the PSK (KIAB) as specified in the Annex A.23 of this document. The IAB-donor shall uniquely identify the IAB-node's security context (KgNB) using the IAB-node DU IP address. The IAB-donor shall use KIAB as PSK for IKEv2 between IAB-node and the IAB-donor. KIAB is stored in the IAB-node and in the IAB-donor. This key KIAB and the IPsec SA cryptographic keys are taken into use with the establishment of IPsec Security Association (SA) between the IAB-node and the IAB-donor. KIAB remains valid as long as the IAB-node is connected to the IAB-donor or until the IAB-node is re-authenticated. In case of CP-UP separation of IAB-donor-CU (IAB-donor-CU contains IAB-donor-CU-CP and IAB-donor-CU-UP that use different IP address) then, IAB-donor-CU-CP and IAB-node DU shall generate KIAB-CU-CP and KIAB-CU-UP as specified in the Annex A.23 of this document. The key KIAB-CU-CP shall be used for establishment of secure F1 interface between the IAB-node DU and IAB-donor-CU-CP. The IAB-donor-CU-CP shall provide KIAB-CU-UP to the IAB-donor-CU-UP via E1 interface and KIAB-CU-UP shall be used for establishment of secure F1 interface between the IAB-node DU and IAB-donor-CU-UP.
This clause describes the security requirements, procedures and handling for Ultra-Reliable Low-Latency Communication (URLLC). The procedures and handling include the enforcing the security policy for data transmission. The general features for URLLC are described in TS 23.501, TS 38.300 and TS 23.502.
In order to support URLLC services, a UE sets up two redundant PDU sessions over the 5G network, such that the 5GS sets up the user plane paths of the two redundant PDU Sessions to be disjoint as described in clause 5.33 in TS 23.501. However, NG-RAN may realize redundant user plane resources for the two PDU sessions with a single NG-RAN node, or by Dual Connectivity with two NG-RAN nodes, i.e. one PDU session spans from the UE via the MN to a first UPF and the second PDU session spans from the same UE via the SN to a second UPF. Based on the two PDU sessions, the redundant data sent between the UE and the DN takes different paths in the 3GPP network.
The security aspects for redundant PDU sessions transmission by Dual Connectivity are based on the security procedures and description described in clause 6.10 of the present specification. This clause only describes the additional security features.
When dual connectivity is used for redundant transmission, both of the two PDU sessions are initially established via the MN. The SMF(s) shall provide a UP security policy for each of the two PDU sessions to the MN during the PDU session establishment procedure as described in clause 6.6.1. The UP security policy from the SMF(s) for the two PDU sessions used for redundant data transmission shall have the same setting for encryption and for integrity protection. The network (UDM and/or SMF) shall ensure that all the redundant PDU sessions based on the information sent by the UE as described in TS 23.501 shall have same UP security policy setting.
The MN shall be preconfigured or shall have access to the supported security capabilities in the available SN(s), (i.e. to whether UP integrity protection is supported in the SN or not). The MN shall take the received UP security policy into account when selecting the SN.
MN shall ensure that the first and the redundant PDU sessions shall have the same UP security activation status. If the "Preferred" option of the UP security policy is not allowed to be used for URLLC service at the SMF or UDM, which means the SMF or UDM can guaranteethe UP security policy for the first and the redundant PDU sessions are the same and only contains "Not needed", or "Required", then the MN shall forward the UP security policy to the SN as described in clause 6.10.
If the "Preferred" option of the UP security policy is allowed to be used for URLLC services, the following enhancements for the mechanism as described in clause 6.10 for Dual Connectivity shall be applied:
The MN shall make the decision on UP encryption protection and integrity protection according to the UP security policy for these two redundant data transmissions. The MN shall store the applied UP security activation status used for the DRB's established for the first PDU session between the MN and the UE. Then, the MN shall provide the UP security activation status applied for the first PDU session to the SN, when offloading the DRB's for the second PDU session to the SN.
The SN shall use the UP security activation status received from the MN to activate the UP security for the DRB's established for the redundant PDU session between the SN and the UE.
If the user data redundancy is fulfilled by means of two duplicated N3 tunnels, the redundant packets will be transferred between UPF and RAN via two independent N3 tunnels, which are associated with a single PDU Session, over different transport layer path to enhance the reliability of service.
In order to protect the redundant traffic on the N3 reference point, the current mechanism defined in clause 9.3 of the present document shall be reused. The added path for redundancy shall provide equal level of security compared to single path.
In case two N9 tunnels are involved to fulfil the redundancy for one NG-RAN, the security mechanism defined in clause 9.9 shall be used for protecting the redundant data transferring via two N9 tunnels as described above.