Tech-invite  3GPPspace  IETF RFCs  SIP
index  N  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.501  Word version:  18.2.0

Top   Top   Up   Prev   Next
1…   4…   5…   5.3…   5.9…   5.10…   6…   6.1.3…   6.1.4…   6.2…   6.2.2…   6.3…   6.4…   6.5…   6.6…   6.7…   6.8…   6.9…   6.10…   6.11   6.12…   6.13   6.14…   6.15…   6.16…   7…   7A…   7A.2.3…   7B…   8…   9…   10…   11…   12…   13…   13.2.2…   13.2.4…   13.3…   13.4…   14…   15…   16…   A…   B…   C…   D…   E…   F…   G…   I…   I.9…   J…   K…   M…   N…   O…   P…   R   S…   T…   U…   V…   W…   X…   Y…   Z… 
M Security for Integrated Access and Backhaul (IAB)  M.1 General  M.2 Security requirements and features  M.2.1 Requirements on the IAB-node (IAB-UE)  M.2.2 Requirements on the IAB donor  M.2.3 Requirements on the 5GC supporting IAB architecture  M.2.4 Requirements for secure environment  M.2.5 Requirements on the F1 interface  M.3 IAB-node Integration Procedure  M.3.1 General  M.3.2 Authentication and Authorization of IAB-node (Phase-1)  M.3.3 Security mechanisms for F1 interface between the IAB-node (gNB-DU) and the IAB-donor-CU (Phase-3)  M.4 Protection of management traffic between IAB-node and OAM 
...

 

M (Normative)  Security for Integrated Access and Backhaul (IAB) |R16|  p. 262

M.1  General  p. 262

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

M.2  Security requirements and features  p. 262

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

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  p. 262

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  p. 262

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  p. 262

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  p. 262

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 Procedure  p. 263

M.3.1  General  p. 263

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

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

M.3.3.1  General  p. 263

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  p. 263

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

M.4  Protection of management traffic between IAB-node and OAM  p. 264

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.

Up   Top   ToC