5 gNB-CU-CP-specific security requirements and related test cases

33.5233GPP5G Security Assurance Specification (SCAS)Release 18Split gNB product classesTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Introduction

gNB-CU-CP specific security requirements include both requirements derived from gNB-CU-CP-specific security functional requirements as well as security requirements derived from threats specific to gNB-CU-CP as described in TR 33.926 [4]. Generic security requirements and test cases common to other network product classes have been captured in TS 33.117 [2] and are not repeated in the present document.

5.2 Security functional adaptations of requirements and related test cases

5.2.1 Introduction

The present clause contains gNB-CU-CP-specific security functional adaptations of requirements and related test cases. Many of the security functional requirements are directly inherited from the gNB product class.

5.2.2 Requirements and test cases deriving from 3GPP specifications

5.2.2.1 Security functional requirements on the gNB-CU-CP deriving from 3GPP specifications – TS 33.501 [3]

Editor’s Note: The ‘X’ in the clauses for the references to threats will need to be aligned with the final Annex allocation in TR 33.926.

5.2.2.1.1 Security functional requirements inherited from gNB

The following security functional requirements from clause 4.2.2.1 of TS 33.511 [6] apply to the gNB-CU-CP by changing the gNB to gNB-CU-CP for the entity under test in the test cases and with the below changes of threat reference:

4.2.2.1.1 Integrity protection of RRC-signalling

Threat References: TR 33.926 [4], clause X.2.2.2 – Control plane data integrity protection.

4.2.2.1.4 RRC integrity check failure

Threat References: TR 33.926 [4], clause X.2.2.2 – Control plane data integrity protection.

4.2.2.1.6 Ciphering of RRC-signalling

Threat References: TR 33.926 [4], clause X.2.2.1 – Control plane data confidentiality protection.

4.2.2.1.9 Replay protection of RRC-signalling

Threat References: TR 33.926 [4], clause X.2.2.2 – Control plane data integrity protection.

4.2.2.1.12 AS algorithms selection

Threat References: TR 33.926 [4], clause X.2.2.3 – AS algorithm selection and use.

4.2.2.1.13 Key refresh at the gNB

Threat References: TR 33.926 [4], clause X.2.2.5 – Key Reuse.

4.2.2.1.14 Bidding down prevention in Xn-handovers

Threat References: TR 33.926 [4], clause X.2.2.4 – Bidding Down on Xn-Handover.

4.2.2.1.15 AS protection algorithm selection in gNB change

Threat References: TR 33.926 [4], clause X.2.2.3 – AS algorithm selection and use.

4.2.2.1.18 Key update at the gNB on dual connectivity

Threat References: TR 33.926 [4], clause X.2.2.5 – Key Reuse.

4.2.2.1.19 UP security activation in Inactive scenario

Threat Reference: TR 33.926 [4], clause X.2.2.7 – State transition from inactive state to connected state.

5.2.2.1.2 Control plane data confidentiality protection over N2/Xn/F1/E1 interface

NOTE 1: This is based on the security functional requirement on the gNB given in 4.2.2.1.16 of TS 33.511 [6] but modified as the gNB-CU-CP supports the F1 and E1 interfaces.

Requirement Name: Control plane data confidentiality protection over N2/Xn/F1/E1 interface.

Requirement Reference: TS 33.501 [3], clauses 5.3.9, 5.3.10, 9.2 and 9.4

Requirement Description: "F1-C interface shall support confidentiality, integrity and replay protection.", "The E1 interface between CU-CP and CU-UP shall be confidentiality, integrity and replay protected.", "The transport of control plane data over N2 shall be integrity, confidentiality and replay-protected." and "The transport of control plane data and user data over Xn shall be integrity, confidentiality and replay-protected." as specified in TS 33.501 [3], clauses 5.3.9, 5.3.10, 9.2 and 9.4.

Threat References: TR 33.926 [4], clause X.2.2.1 – Control plane data confidentiality protection.

Test Case: the test case in subclause 4.2.3.2.4 of TS 33.117 [2]

5.2.2.1.3 Control plane data integrity protection over N2/Xn/F1/E1 interface

NOTE 1: This is based on the security functional requirement on the gNB given in 4.2.2.1.17 of TS 33.511 [6] but modified as the CU-CP supports the F1 and E1 interfaces.

Requirement Name: Control plane data integrity protection over N2/Xn/F1/E1 interface.

Requirement Reference: TS 33.501 [3], clauses 5.3.9, 5.3.10, 9.2 and 9.4.

Requirement Description: "F1-C interface shall support confidentiality, integrity and replay protection.", "The E1 interface between CU-CP and CU-UP shall be confidentiality, integrity and replay protected.", "The transport of control plane data over N2 shall be integrity, confidentiality and replay-protected." "The transport of control plane data and user data over Xn shall be integrity, confidentiality and replay-protected." as specified in TS 33.501 [3], clauses 5.3.9, 5.3.10, 9.2 and 9.4.

Threat References: TR 33.926 [4], clause X.2.2.2 – Control plane data integrity protection.

Test Case: the test case in subclause 4.2.3.2.4 of TS 33.117 [2].

5.2.2.1.4 Ciphering of user data based on the security policy sent by the SMF

NOTE 1: This is based on the security functional requirement on the gNB given in 4.2.2.1.10 of TS 33.511 [6] but modified as the gNB-CU-CP informs both the gNB-CU-UP and UE whether to use a non-NULL ciphering algorithm or not.

Requirement Name: Ciphering of user data based on the security policy sent by the SMF.

Requirement Reference: TS 33.501 [3], clause 5.3.2.

Requirement Description: "The gNB shall activate ciphering of user data based on the security policy sent by the SMF" as specified in TS 33.501 [3], clause 5.3.2.

Threat References: TR 33.926 [4], clause X.2.2.6 – Security Policy Enforcement.

Test Case:

Test Name: TC-UP-DATA-CIP-SMF_gNB-CU-CP

Purpose: To verify that the user data packets are confidentiality protected based on the security policy sent by the SMF via AMF

Pre-Condition:

– The gNB-CU-CP network product shall be connected in emulated/real network environments. The UE and the 5GC may be simulated.

– The tester shall have access to the NG RAN air interface.

– The tester shall have knowledge of the RRC and UP ciphering algorithm and protection keys and of the security keys etc needed to decrypt the messages on the E1 interface.

– RRC ciphering is already activated at the gNB.

Execution Steps:

1. The tester triggers PDU session establishment procedure by sending PDU session establishment request message.

2. Tester shall trigger the SMF to send the UP security policy with ciphering protection "required" or "not needed" to the gNB-CU-CP.

3. The tester shall capture the Bearer Context Setup Request message sent to the gNB-CU-UP over the E1 interface.

4. The tester shall decrypt the Bearer Context Setup Request message.

5. The tester shall capture the RRC connection reconfiguration procedure between gNB-CU-CP to UE over NG RAN air interface. And filter the RRC connection reconfiguration message sent by gNB-CU-CP to UE.

6. The tester shall decrypt the RRC connection Reconfiguration message and retrieve the UP ciphering protection indication presenting in the decrypted message.

7. The tester shall verify if the UP ciphering policy received at gNB-CU-CP is same as the UP ciphering protection indication notified by the gNB-CU-CP to the UE in the RRC connection Reconfiguration message and the gNB-CU-UP in the Bearer Context Setup Request message.

Expected Results:

Both the messages indicate that ciphering is to be used inline with the received policy.

Expected format of evidence:

Evidence suitable for the interface, e.g. Screenshot containing the operational results.

5.2.2.1.5 Integrity of user data based on the security policy sent by the SMF

NOTE 1: This is based on the security functional requirement on the gNB given in 4.2.2.1.11 of TS 33.511 [6] but modified as the gNB-CU-CP informs both the gNB-CU-UP and UE whether to use a non-NULL integrity algorithm or not.

Requirement Name: Integrity of user data based on the security policy sent by the SMF.

Requirement Reference: TS 33.501 [3], clause 5.3.2.

Requirement Description: "The gNB shall provide integrity protection of user data based on the security policy sent by the SMF" as specified in TS 33.501 [3], clause 5.3.2.

Threat References: TR 33.926 [4], clause X.2.2.6 – Security Policy Enforcement.

Test Case:

Test Name: TC-UP-DATA-INT-SMF_gNB-CU-CP

Purpose: To verify that the user data packets are integrity protected based on the security policy sent by the SMF.

Pre-Condition:

– The gNB-CU-CP network product shall be connected in emulated/real network environments. The UE and the 5GC may be simulated.

– The tester shall have access to the NG RAN air interface.

– The tester shall have knowledge of the integrity algorithm and protection keys and of the security keys etc needed to decrypt the messages on the E1 interface.

– RRC integrity and cipher are already activated at the gNB.

Execution Steps:

1. The tester triggers PDU session establishment procedure by sending PDU session establishment request message.

2. Tester shall trigger the SMF to send the UP security policy with integrity protection is "required" or "not needed" to the gNB.

3. The tester shall capture the Bearer Context Setup Request message sent to the gNB-CU-UP over the E1 interface.

4. The tester shall decrypt the Bearer Context Setup Request message.

5. The tester shall capture the RRC connection reconfiguration message sent by gNB to UE over NG RAN air interface.

6. The tester shall decrypt the RRC connection reconfiguration message and retrieve the UP integrity protection indication presenting in the decrypted message.

7. Tester shall check whether UP integrity policy received at gNB-CU-UP is same as the UP integrity protection indication notified by the gNB-CU-CP to the UE in the RRC connection reconfiguration message and the gNB-CU-UP in the Bearer Context Setup Request message.

Expected Results:

Both the messages indicate that integrity is to be used inline with the received policy.

Expected format of evidence:

Evidence suitable for the interface, e.g. Screenshot containing the operational results.

5.2.3 Technical Baseline

The baseline technical requirements are identical to the ones for the gNB product class given in clause 4.2.3 of TS 33.511 [6].

5.2.4 Operating systems

There are no gNB-CU specific additions to clause 4.2.4 of TS 33.117 [2].

5.2.5 Web servers

There are no gNB-CU-CP specific additions to clause 4.2.5 of TS 33.117 [2].

5.2.6 Network devices

These requirements are identical to the ones for the gNB product class given in clause 4.2.6 of TS 33.511 [6] except the GTP-U Filtering case in clause 4.2.6.2.4 of TS 33.117 [2] as the gNB-CU-CP does not support user plane interfaces.

5.3 Adaptations of hardening requirements and related test cases

These requirements are identical to the ones for the gNB product class given in clause 4.3 of TS 33.511 [6].

5.4 Adaptations of basic vulnerability testing requirements and related test cases

There are no gNB-CU-CP specific additions to clause 4.4 of TS 33.117 [2].