Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.2…   6.3…   6.5…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7B…   8…   9…   10…   11…   13…   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   K…   O…

 

K (Normative)  Security for 5GLAN services |R16|Word‑p. 230

K.1  General

5GLAN services are described in TS 23.501 and TS 23.502.

K.2  Authentication and authorization

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.

K.3  Handling of UP security policy

To reduce incremental complexity added by security, all PDU sessions associated with a specific 5G LAN group should have the same UP security policy. When generating the policy enforcement information, and to avoid the redundant double protection, the SMF may consider information by a DN-AAA about DN protection mechanisms already applied.
Editor's Note: Details about SMF obtaining information about DN protection from DN-AAA are ffs.

L (Normative)  Security for TSC service |R16|Word‑p. 231

L.1  General

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 [75], where the 5GS system acts as one or more TSN Bridges of a TSN network.

L.2  Access security for a 5GS TSC-enabled UE

A 5GS TSC-enabled UE accesses the 5G network as described in this document except where differences are provided in the following clauses.

L.3  Protection of user plane data in TSC including gPTP control messages

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 gPTP messages sent in the user plane.
Up

M (Normative)  Security for Integrated Access and Backhaul (IAB) |R16|Word‑p. 232

M.1  General

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 TS 33.401.
Up

M.2  Security requirements and features

M.2.1  Requirements on the IAB-node (IAB-UE)

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.

M.2.2  Requirements on the IAB donor

The IAB donor shall support ciphering, integrity protection and replay protection of RRC-signalling between the IAB donor and the IAB-node (IAB-UE).

M.2.3  Requirements on the 5GC supporting IAB architecture

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).

M.2.4  Requirements for secure environment

The security requirements for secure environment of the IAB-node (gNB-DU) and the IAB-donor are described in clause 5.3.8 of this document.

M.2.5  Requirements on the F1 interface

The security requirements on the F1 interface between the IAB-node (gNB-DU) and the IAB-donor-CU are described in clause 5.3.9 of this document.

M.3  IAB-node Integration ProcedureWord‑p. 233

M.3.1  General

IAB-node, consists of a UE function (referred to as IAB-UE) and gNB-DU function [2]. 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.
Up

M.3.2  Authentication and Authorization of IAB-node (Phase-1)

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.
Up

M.3.3  Security mechanisms for F1 interface between the IAB-node (gNB-DU) and the IAB-donor-CU (Phase-3)

M.3.3.1  General

The following clause applies to F1 interface between the IAB-node (gNB-DU) and the IAB-donor-CU.

M.3.3.2  Security mechanisms for the F1 interface

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 (K gNB) 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.
Up

M.4  Protection of management traffic between IAB-node and OAMWord‑p. 234
If management traffic uses the user plane via PDU session, it shall be protected using the user plane security mechanism as specified in clause 6.6.

N (Normative)  Security for URLLC services |R16|Word‑p. 235

N.1  General

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 23.501 [2], 38.300 [52] and TS 23.502.

N.2  Security support on redundant transmission

N.2.1  Redundant user plane paths based on dual connectivity

N.2.1.1  Introduction

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.
Up

N.2.1.2  Security policy aspects

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.
Up

N.2.2  Redundant transmission on N3/N9 interfacesWord‑p. 236
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.
[not reproduced yet]
Figure N.2.2-1: Redundant transmission with two N3 tunnels between the UPF and a single NG-RAN node
Up
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 NDS/IP mechanism shall be used for protecting the redundant data transferring via two N9 tunnels as described above.
Up


Up   Top   ToC