Tech-invite  3GPPspace  IETFspace
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:  19.1.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.5 IAB inter-CU topology adaptation and backhaul RLF recovery procedure 
...

 

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

M.1  General  p. 280

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

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

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

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

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

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

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

M.3.1  General  p. 281

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

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

M.3.3.1  General  p. 281

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

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. The KIAB is associated with the IAB-node DU IP address in the IAB-donor. In the IKE_AUTH request message, the IAB node shall set the ID type to ID_IPV4_ADDR/ID_IPV6_ADDR and set its value to the IAB-node DU IP address in the Idi payload. 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. 282

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.

M.5  IAB inter-CU topology adaptation and backhaul RLF recovery procedure |R17|  p. 282

In case of the inter-CU migration as specified in TS 38.401, the IAB-MT is migrated from a source IAB-donor-CU to a target IAB-donor-CU. The migrating IAB-node becomes a boundary IAB-node since its IAB-DU retains F1AP with the source IAB-donor-CU after its IAB-MT obtains RRC connectivity with the target IAB-donor-CU (c.f. TS 38.401).
In case IPsec tunnel mode is used for F1 interface protection, the migrating/descendant/Recovery IAB-node may use MOBIKE (RFC 4555) to migrate the IPsec tunnel to the new IP outer addresses as specified in TS 38.401.
In IPsec transport mode for the non-dynamic PSK case, the establishment of the IPsec SAs follows the procedures in Annex M.3.3.2 of the present document. In IPsec transport mode for the dynamic PSK case, the establishment of the IPsec SAs may be performed by initiating new IKEv2 procedure using the stored KIAB associated with the old IP address as the PSK for the corresponding new IP address. The identical mapping between the old IP address with the new IP address between the IAB-node and the IAB-donor-CU is performed using the old IP address present in the IDi payload and the new IP address in the IP header of the IKEv2_AUTH request message or provided by the target/new IAB-donor-CU. In case of multiple IP addresses for IAB-node, the IKEv2 procedure is performed for each IP address. Once the IKEv2 authentication is successful, the KIAB is associated with the new IAB-node DU IP address in the IAB-donor.
Up

Up   Top   ToC