Content for TS 33.401 Word version: 19.1.0

1… 4 5… 6… 6.2… 7… 7.2.5… 7.2.8 7.2.9… 7.3… 8… 9… 10… 11… 15… A… B… C… C.1.6 C.2… C.2.7 C.2.8 C.3… C.4.7 D… E… E.2… E.3… F… G… H… I… K…

K.1 General K.2 IAB-node integration procedure N.1 General N.2 Security aspects of split MME architecture N.3 Security aspects of full EPC in each satellite

K (Normative) Security for Integrated Access and Backhaul (IAB) in EN-DC |R16| p. 167

K.1 General p. 167

This Annex provides the security procedures applied to IAB-node when connecting to EPC. The IAB reference architecture, when connected to EPC, is defined in TS 23.401.

IAB-node consists of a gNB-DU function and a UE function (referred to as IAB-UE). The IAB-UE function reuses UE procedures defined in this document to connect to EPC.

In an IAB (Integrated Access and Backhaul) architecture, the IAB-node can access the network using either standalone mode or EN-DC mode. Overall description of IAB feature in standalone mode is in TS 38.300. The EN-DC specific details are defined in TS 36.331, TS 36.413, and TS 36.423.

When using the EN-DC mode, as shown in Figure K.1-1, the IAB-node connects via E-UTRA to a MeNB, and the IAB-donor terminates X2-C as SgNB.

Copy of original 3GPP image for 3GPP TS 33.401, Fig. K.1-1: IAB architecture when IAB-node is using EN-DC

Figure K.1-1: IAB architecture when IAB-node is using EN-DC
(⇒ copy of original 3GPP image)

The present document only deals with security aspects of IAB in the EN-DC mode. The security aspects of IAB in standalone mode (including authentication and authorization of IAB-nodes, and security of F1 interfaces) are defined in TS 33.501.

K.2 IAB-node integration procedure p. 167

K.2.1 Authentication and Authorization of IAB-node p. 167

The IAB-UE function shall behave as a UE, and shall reuse the UE procedures specified in this specification, when connecting to EPC, for the authentication, key derivation and distribution scheme, subscription credential(s) storage requirements, NAS security and AS security.

Authorization of IAB-nodes shall be performed by the EPC supporting IAB architecture as described in TS 23.401.

A summary of Authentication and Authorization of IAB-node is illustrated in Figure K.2-1.

Copy of original 3GPP image for 3GPP TS 33.401, Fig. K.2-1: Summary of authentication and authorization of IAB-nodes

Figure K.2-1: Summary of authentication and authorization of IAB-nodes
(⇒ copy of original 3GPP image)

The indication of being an IAB-node is signalled from the IAB-node to the eNB as defined in TS 36.331.
This indication is signalled from the eNB to the MME as defined in TS 36.413.
Mutual authentication between the IAB-node and the EPC supporting the IAB architecture shall be performed using the authentication and key agreement procedure defined in the clause 6.1 of the present document.
After successful authentication and validity check, the indication that the IAB-node is authorized is signalled from the MME to the eNB as defined in TS 36.413.
During EN-DC procedures, the indication of IAB-node is signalled from the MeNB to the SgNB as defined in TS 36.423.
During handover procedures, the indication of IAB-node is signalled from the one eNB to another eNB as defined in TS 36.423.

L Security Aspects of DNS and ICMP |R16| p. 169

L.1 General p. 169

The security measures specified in Annex P of TS 33.501 can be used to protect the DNS and ICMP messages that are carried over the user plane.

M (Normative) Protection of management traffic between IAB-node and OAM |R16| p. 170

If management traffic uses the user plane via PDN session, it shall be protected using the user plane security mechanism as specified in the present document.

N (Normative) Security for Store and Forward Satellite operation |R19| p. 171

N.1 General p. 171

This Annex describes the security aspects of Store and Forward Satellite operation. The general features of Store and Forward Satellite operation are described in TS 23.401.

There are two example deployment options for Store and Forward Satellite operation given in Annex O of TS 23.401, i.e. Split MME architecture and Full EPC in each satellite. In both cases, regular LTE procedures shall be used to provide the security between the UE and network, e.g. authentication and protection of traffic between the UE and network.

The security of communications between the proxies on satellite and the ground station(s) is out of 3GPP scope.

N.2 Security aspects of split MME architecture p. 171

Mutual authentication between the UE and the network in a split MME architecture can involve more than one satellite (i.e., more than one MME-onboard), in which case the ground segment of the network is responsible for the selection and provisioning of MME-onboard the same, or another satellite, with the necessary information (e.g., Authentication Vector) to perform or finish an authentication procedure. The MME on-board obtains the EPS authentication vectors when the feeder link is available and stores the authentication vectors when the service link is unavailable.

According to clause 4.13.9.1 of TS 23.401 the MME rejects a NAS procedure if the MME-onboard cannot complete the NAS procedure with the information it has available. Hence the NAS security is terminated on the MME-onboard, and the ground segment of the network ensures that the latest NAS security context of the UE, or an Authentication Vector, is available at the MME-onboard.

N.3 Security aspects of full EPC in each satellite p. 171

The security credentials required for the mutual authentication between the UE and network are stored in the HSS onboard the satellite. To enable having only a satellite-specific subscriber key stored in the satellite, IOPS-based keying method described in Annex F of the present document is used to limit the impact of exposing long-term keys in the HSS onboard the satellite.