TR 33.926 [5], clause D.2.2.2 -- Control plane data integrity protection.

Integrity protection of RRC-signalling

TS 33.501 [2], clause 5.3.3

The gNB supports integrity protection and replay protection of RRC-signalling as specified in TS 33.501 [2], clause 5.3.3.

To verify that the RRC-signalling data sent between UE and gNB over the NG RAN air interface are integrity protected.

• The gNB network product shall be connected in emulated/real network environments. UE may be simulated.

• Tester shall have access to the integrity algorithm and the integrity protection keys.

• The tester can capture the message via the NG RAN air interface, or can capture the message at the UE.

• The NIA0 is disabled at UE and gNB.

1. The tester triggers the gNB to send AS SMC message to the UE, and UE responses AS SMP.

2. The tester checks any RRC message sent by gNB after sending AS SMC and before UE enters CM-Idle state is integrity protected.

Any RRC-signalling over the NG RAN air interface is integrity protected after gNB sending AS SMC.

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

TR 33.926 [5], clause D.2.2.2 -- Control plane data integrity protection.

Integrity protection of RRC-signalling

TS 33.501 [2], clause 5.3.3

To verify that the RRC-signalling data sent between UE and gNB over the NG RAN air interface are integrity protected.

• The gNB network product shall be connected in emulated/real network environments. UE may be simulated.

• Tester shall have access to the integrity algorithm and the integrity protection keys.

• The tester can capture the message via the NG RAN air interface, or can capture the message at the UE.

The NIA0 is disabled at UE and gNB.

1. The NIA0 is disabled at UE and gNB.

2. gNB sends AS SMC message to the UE, and UE responses AS SMP.

3. Check any RRC message sent by gNB after sending AS SMC and before UE enters CM-Idle state is integrity protected.

Any RRC-signalling over the NG RAN air interface is integrity protected after gNB sending AS SMC.

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

TR 33.926 [5], clause D.2.2.8 -- Security Policy Enforcement.

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

TS 33.501 [2], clause 5.3.2

The gNB activates ciphering of user data based on the security policy sent by the SMF as specified in TS 33.501 [2], clause 5.3.2.

To verify that activation of confidentiality protection for user data is based on the security policy sent by the SMF via AMF

• The gNB 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.

• RRC ciphering is already activated at the gNB.

All execution steps are to be performed two times. Once with the UP security policies' ciphering protection in step 2 set to "required" and the second time set to "not needed".

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.

3. The tester shall capture the RRC reconfiguration procedure between gNB to UE over NG RAN air interface. And filter the RRC reconfiguration message sent by gNB to UE.

4. The tester shall decrypt the RRC Reconfiguration message and retrieve the UP ciphering protection indication present in the captured message.

5. The tester shall verify if the UP security policy received at gNB is same as the UP ciphering protection indication notified by the gNB to the UE in the RRC Reconfiguration message.

6. Tester shall capture the RRC Reconfiguration complete message sent between UE and gNB.

7. Tester shall capture the user plane data sent between UE and gNB using any network analyser.

When the received UP cipher protection indication is set to "required", the captured user plane data appear to be garbled (i.e. no longer plaintext) and the user plane packets are confidentiality protected based on the UP security policy sent by the SMF.

When the received UP cipher protection indication is set to "not needed", the captured user plane data appear to be plaintext and the user plane packets are not confidentiality protected based on the UP security policy sent by the SMF.

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

TR 33.926 [5], clause D.2.2.8 -- Security Policy Enforcement.

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

TS 33.501 [2], clause 5.3.2

• The gNB 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.

• RRC ciphering is already activated at the gNB.

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.

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

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

5. The tester shall verify if the UP security policy received at gNB is same as the UP ciphering protection indication notified by the gNB to the UE in the RRC connection Reconfiguration message.

6. Tester shall capture the RRC connection Reconfiguration complete message sent between UE and gNB.

When the received UP cipher protection indication is set to "required", the captured user plane data appear to be garbled (i.e. no longer plaintext) and the user plane packets are confidentiality protected based on the UP security policy sent by the SMF.

When the received UP cipher protection indication is set to "not needed", the captured user plane data appear to be plaintext and the user plane packets are not confidentiality protected based on the UP security policy sent by the SMF.

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

TR 33.926 [5], clause D.2.2.8 -- Security Policy Enforcement.

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

TS 33.501 [2], clause 5.3.2

The gNB activates integrity protection of user data based on the security policy sent by the SMF as specified in TS 33.501 [2], clause 5.3.2.

To verify that activation of integrity protection for user data packets is based on the security policy sent by the SMF.

• The gNB 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.

• RRC integrity is activated at the gNB.

All execution steps are to be performed two times. Once with the UP security policies' ciphering protection in step 2 set to "required" and the second time set to "not needed".

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 RRC reconfiguration message sent by gNB to UE over NG RAN air interface.

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

5. Tester shall check whether UP integrity is enabled /disabled to verify if the UP security policy received at gNB is same as the UP integrity protection indication notified by the gNB to the UE in the RRC reconfiguration message.

6. Tester shall capture the user plane data sent between UE and gNB using any network analyser.

When the received UP integrity protection is set to "required", the user plane packets are integrity protected based on the security policy sent by the SMF.

When the received UP integrity protection is set to "not needed", the user plane packets are not integrity protected based on the security policy sent by the SMF.

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

TR 33.926 [5], clause D.2.2.8 -- Security Policy Enforcement.

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

TS 33.501 [2], clause 5.3.2

• The gNB 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.

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

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 RRC connection reconfiguration message sent by gNB to UE over NG RAN air interface.

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

5. Tester shall check whether UP integrity is enabled /disabled to verify if the UP security policy received at gNB is same as the UP integrity protection indication notified by the gNB to the UE in the RRC connection reconfiguration message.

6. Tester shall capture the user plane data sent between UE and gNB using any network analyser.

The tester shall check whether the user plane data packet contains a message authentication code.

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

TR 33.926 [5], D.2.2.5 -- AS algorithm selection and use

AS algorithms selection

TS 33.501 [2], clause 6.7.3.0 and clause 5.11.2.

The gNB selects the algorithms to use dependent on: the UE security capabilities of the UE, the configured allowed list of security capabilities of the currently gNB as specified in TS 33.501 [2], clause 5.11.2.

Each gNB is configured via network management with lists of algorithms which are allowed for usage. There is one list for integrity algorithms, and one for ciphering algorithms. These lists are ordered according to a priority decided by the operator as specified in TS 33.501 [2], clause 6.7.3.0.

Verify that the gNB selects the algorithms with the highest priority in its configured list.

Test environment with the gNB has been pre-configured with allowed security algorithms with priority.

1. The tester triggers the UE to send registration request message to the gNB.

2. The gNB receives UE context setup request message.

3. The gNB sends the AS SECURITY MODE COMMAND message.

4. The UE replies with the AS SECURITY MODE COMPLETE message.

The gNB initiates the SECURITY MODE COMMAND message that includes the chosen algorithm with the highest priority according to the ordered lists and is contained in the UE NR security capabilities.

The MAC in the AS SECURITY MODE COMPLETE message is verified, and the AS protection algorithms are selected and applied correctly.

Sample copies of the log files.

TR 33.926 [5], clause D.2.2.7 Key Reuse

Key refresh at the gNB

TS 33.501 [2], clause 6.9.4.1; TS 38.331 [6], clause 5.3.1.2

Key refresh is possible for K~gNB~, K~RRC-enc~, K~RRC-int~, K~UP-enc~, and K~UP-int~ (if available), and is to be initiated by the gNB/ng-eNB when a PDCP COUNTs are about to be re-used with the same Radio Bearer identity and with the same K~gNB~. as specified in TS 33.501 [2], clause 6.9.4.1.

The network is responsible for avoiding reuse of the COUNT with the same RB identity and with the same key, e.g. due to the transfer of large volumes of data, release and establishment of new RBs, and multiple termination point changes for RLC-UM bearers and multiple termination point changes for RLC-AM bearer with SN terminated PDCP re-establishment (COUNT reset) due to SN only full configuration whilst the key stream inputs (i.e. bearer ID, security key) at MN have not been updated. In order to avoid such re-use, the network e.g. uses different RB identities for RB establishments, change the AS security key, or an RRC_CONNECTED to RRC_IDLE/RRC_INACTIVE and then to RRC_CONNECTED transition as specified in TS 38.331 [6], clause 5.3.1.2.

Verify that the gNB performs K~gNB~ refresh when DRB-IDs are about to be reused under the following conditions:

• the successive Radio Bearer establishment uses the same RB identity while the PDCP COUNT is reset to 0, or

• the PDCP COUNT is reset to 0 but the RB identity is increased after multiple calls and wraps around.

The UE, AMF and SMF may be simulated.

1. The tester triggers the gNB to send the AS Security Mode Command message to the UE.

2. The UE responds with the AS Security Mode Complete message.

3. A DRB is set up.

4. The tester sets up and tears down the DRB for multiple times within one active radio connection without the UE going to idle (e.g. by triggering the UE to make multiple IMS calls, or by triggering the SMF to request PDU session modification and deactivation via the AMF), until the DRB ID is reused.

Before DRB ID reuse, the gNB takes a new K~gNB~ into use by e.g. triggering an intra-cell handover or triggering a transition from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE and then back to RRC_CONNECTED.

NOTE: Random Access Procedure defined in clause 9.2.6 of TS 38.300[8] runs in the above procedures.

Part of log that shows all the DRB identities and the corresponding procedure. This part can be presented, for example, as a screenshot.

TR 33.926 [5], clause D.2.2.7 Key Reuse

Key refresh at the gNB

TS 33.501 [2], clause 6.9.4.1; TS 38.331 [6], clause 5.3.1.2

Verify that the gNB performs K~gNB~ refresh when DRB-IDs are about to be reused under the following conditions:

• the successive Radio Bearer establishment uses the same RB identity while the PDCP COUNT is reset to 0, or

• the PDCP COUNT is reset to 0 but the RB identity is increased after multiple calls and wraps around.

The UE, AMF and SMF may be simulated.

1. The gNB sends the AS Security Mode Command message to the UE.

2. The UE responds with the AS Security Mode Complete message.

3. A DRB is set up.

4. DRB is set up and torn down for multiple times within one active radio connection without the UE going to idle (e.g. by the UE making multiple IMS calls, or by the SMF requesting PDU session modification and deactivation via the AMF), until the DRB ID is reused.

Before DRB ID reuse, the gNB takes a new K~gNB~ into use by e.g. triggering an intra-cell handover or triggering a transition from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE and then back to RRC_CONNECTED.

TR 33.926 [5], clause D.2.2.6 Bidding Down on Xn-Handover

Bidding Down Prevention

TS 33.501 [2], clause 6.7.3.1

In the Path-Switch message, the target gNB/ng-eNB sends the UE's 5G security capabilities received from the source gNB/ng-eNB to the AMF. as specified in TS 33.501 [2], clause 6.7.3.1.

Verify that bidding down is prevented in Xn-handovers.

Test environment with source gNB and target gNB, and the source gNB may be simulated.

The tester triggers the target gNB to send the path-switch message to the AMF.

The UE NR security capabilities are in the path-switch message.

Snapshots containing the result.

TR 33.926 [5], D.2.2.5 -- AS algorithm selection and use

AS protection algorithm selection in gNB change.

TS 33.501 [2], clauses 6.7.3.1 and 6.7.3.2

The target gNB/ng-eNB selects the algorithm with highest priority from the received 5G security capabilities of the UE according to the prioritized locally configured list of algorithms (this applies for both integrity and ciphering algorithms). The chosen algorithms are indicated to the UE in the Handover Command message if the target gNB/ng-eNB selects different algorithms compared to the source gNB/ng-eNB as specified in TS 33.501 [2], clause 6.7.3.1, and clause 6.7.3.2.

Verify that AS protection algorithm is selected correctly.

Test environment with source gNB, target gNB and AMF. Source gNB and AMF may be simulated.

Test Case 1:

1. The tester triggers the source gNB to transfer the ciphering and integrity algorithms used in the source cell to the target gNB in the handover request message.

2. Target gNB verifies the algorithms and selects AS algorithms which have the highest priority according to the ordered lists. Target gNB includes the algorithm in the handover command.

Test Case 2:

1. The tester triggers the AMF to send the UE NR security capability to the Target gNB.

2. The target gNB selects the AS algorithms which have the highest priority according to the ordered lists in the HANDOVER COMMAND.

The above test cases assume that the algorithms selected by the target gNB are different from the ones received from the source gNB.

For both test cases:

The selected AS ciphering and integrity protection algorithms in the handover complete message have the highest priority according to the ordered list.

The MAC in the handover complete message is valid and is based on the correctly selected AS ciphering and integrity protection algorithms.

Snapshots containing the result.

TR 33.926 [5], clause D.2.2.7 Key Reuse

Test Case 1:

Key update at the gNB on dual connectivity

TS 33.501 [2], clause 6.10.2.1; clause 6.10.2.2.1; clause 6.10.3.1.

When executing the procedure for adding subsequent radio bearer(s) to the same SN, the MN is expected to, for each new radio bearer, assign a radio bearer identity that has not previously been used since the last K~SN~ change. If the MN cannot allocate an unused radio bearer identity for a new radio bearer in the SN, due to radio bearer identity space exhaustion, the MN is expected to increment the SN Counter and compute a fresh K~SN~, and then is expected to perform a SN Modification procedure to update the K~SN~ as specified in TS 33.501 [2], clause 6.10.2.1.

The MN is expected to refresh the root key of the 5G AS security context associated with the SN Counter before the SN Counter wraps around. Refreshing the root key is done using intra cell handover as described in subclause 6.7.3.3 of TS 33.501 [2]. When the root key is refreshed, the SN Counter is reset to '0' as defined above. in that same clause; as specified in TS 33.501 [2], clause 6.10.3.1.

NOTE: The following testcases are only tested when the NR-NR DC, NE-DC and EN-DC scenarios are deployed.

Verify that the gNB under test acting as a Master Node (MN) performs K~SN~ update when DRB-IDs are about to be reused.

• Test environment with a gNB or ng-eNB acting as the Secondary Node (SN), which may be simulated

• Test environment with a UE, SMF and AMF, which may be simulated

1. The tester triggers the gNB under test to establish RRC connection and AS security context with the UE.

2. The gNB under test establishes security context between the UE and the SN for the given AS security context shared between the gNB under test and the UE; and generates a K~SN~ sent to the SN.

3. A SCG bearer is set up between the UE and the SN.

4. The tester triggers the gNB under test to execute the SN Modification procedure to provide additional available DRB IDs to be used for SN terminated bearers (e.g. by triggering the UE to make multiple IMS calls, or by triggering the SMF to request PDU session modification and deactivation via the AMF), until the DRB IDs are reused.

• Before DRB ID reuse, the gNB under test generates a new K~SN~ and sends it via the SN Modification Request message to the SN.

Evidence suitable for the interface, e.g. text representation of the captured SN Modification Request message.

Test Case 2:

TR 33.926 [5], clause D.2.2.7 Key Reuse

Test Case 1:

Key update at the gNB on dual connectivity

NOTE: The following testcases are only tested when the NR-NR DC, NE-DC and EN-DC scenarios are deployed.

Verify that the gNB under test acting as a Master Node (MN) performs K~SN~ update when DRB-IDs are about to be reused.

• Test environment with a gNB or ng-eNB acting as the Secondary Node (SN), which may be simulated

• Test environment with a UE, SMF and AMF, which may be simulated

1. The gNB under test establishes RRC connection and AS security context with the UE.

2. The gNB under test establishes security context between the UE and the SN for the given AS security context shared between the gNB under test and the UE; and generates a K~SN~ sent to the SN.

3. A SCG bearer is set up between the UE and the SN.

4. The gNB under test is triggered to execute the SN Modification procedure to provide additional available DRB IDs to be used for SN terminated bearers (e.g. by the UE making multiple IMS calls, or by the SMF requesting PDU session modification and deactivation via the AMF), until the DRB IDs are reused,

• Before DRB ID reuse, the gNB under test generates a new K~SN~ and sends it via the SN Modification Request message to the SN.

Evidence suitable for the interface, e.g. text representation of the captured SN Modification Request message.

Test Case 2:

TR 33.926 [5], clause D.2.2.7 Key Reuse

Test Case 1:

Key update at the gNB on dual connectivity

TS 33.501 [2], clause 6.10.2.1; clause 6.10.2.2.1; clause 6.10.3.1.

When executing the procedure for adding subsequent radio bearer(s) to the same SN, the MN is expected to, for each new radio bearer, assign a radio bearer identity that has not previously been used since the last K~SN~ change. If the MN cannot allocate an unused radio bearer identity for a new radio bearer in the SN, due to radio bearer identity space exhaustion, the MN is expected to increment the SN Counter and compute a fresh K~SN~, and then is expected to perform a SN Modification procedure to update the K~SN~ as specified in TS 33.501 [2], clause 6.10.2.1.

The MN is expected to refresh the root key of the 5G AS security context associated with the SN Counter before the SN Counter wraps around. Refreshing the root key is done using intra cell handover as described in subclause 6.7.3.3 of TS 33.501 [2]. When the root key is refreshed, the SN Counter is reset to '0' as defined above. in that same clause; as specified in TS 33.501 [2], clause 6.10.3.1.

NOTE: The following testcases are only tested when the NR-NR DC, NE-DC and EN-DC scenarios are deployed.

Verify that the gNB under test acting as a Master Node (MN) performs K~NG-RAN~(AS root key) update when SN COUNTER is about to wrap around.

• Test environment with a gNB or ng-eNB acting as the Secondary Node (SN), which may be simulated

• Test environment with a UE, SMF and AMF, which may be simulated.

1. The tester triggers the gNB under test to establish RRC connection and AS security context with the UE.

2. The gNB under test establishes security context between the UE and the SN for the given AS security context shared between the gNB under test and the UE; and generates a K~SN~ sent to the SN and increases the value of SN Counter.

3. A SCG bearer is set up between the UE and the SN.

4. The tester triggers the gNB under test to execute the SN Modification procedure to provide updated K~SN~ to SN, until the SN Counter value wraps around.

• Before SN Counter wraps around, the gNB under test takes a new K~NG-RAN~ into use by e.g. triggering an intra-cell handover or triggering a transition from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE and then back to RRC_CONNECTED.

NOTE: Random Access Procedure defined in clause 9.2.6 of TS 38.300[8] runs in the above procedures.

Part of log that shows the SN Counter values before and after wrapping around and the corresponding procedure. This part can be presented, for example, as a screenshot.

TR 33.926 [5], clause D.2.2.7 Key Reuse

Test Case 1:

Key update at the gNB on dual connectivity

NOTE: The following testcases are only tested when the NR-NR DC, NE-DC and EN-DC scenarios are deployed.

• Test environment with a gNB or ng-eNB acting as the Secondary Node (SN), which may be simulated

• Test environment with a UE, SMF and AMF, which may be simulated.

1. The gNB under test establishes RRC connection and AS security context with the UE.

2. The gNB under test establishes security context between the UE and the SN for the given AS security context shared between the gNB under test and the UE; and generates a K~SN~ sent to the SN and increases the value of SN Counter;

3. A SCG bearer is set up between the UE and the SN.

4. The gNB under test is triggered to execute the SN Modification procedure to provide updated K~SN~ to SN, until the SN Counter value wraps around.

• Before SN Counter wraps around, the gNB under test takes a new K~NG-RAN~ into use by e.g. triggering an intra-cell handover or triggering a transition from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE and then back to RRC_CONNECTED.

TR 33.926 [5], clause D.2.2.9 State transition from inactive state to connected state.

UP security activation in Inactive scenario

TS 33.501 [2], clause 6.8.2.1.3.

If the UP security activation status can be supported in the target gNB/ng-eNB, the target gNB/ng-eNB uses the UP security activations that the UE used at the last source cell. Otherwise, the target gNB/ng-eNB responds with an RRC Setup message to establish a new RRC connection with the UE as specified in TS 33.501 [2], clause 6.8.2.1.3.

Verify that the target gNB/ng-eNB uses the UP security activation status to activate the UP security.

• The gNB network product shall be connected in emulated/real network environments.

• The UE may be simulated.

1. The tester shall complete a Registration Procedure and PDU Session establishment procedure to make sure the gNB configure the UP security, and get the UP security activation status.

2. The gNB sends RRC Release message with a suspend config to the UE.

3. The tester deletes the UP security activation status of the UE.

4. The tester triggers the UE to send RRC Resume message.

The gNB sends RRC Setup message to the UE.

Screenshot containing the operational results.

UP security activation in Inactive scenario

TS 33.501 [2], clause 6.8.2.1.3.

Verify that the target gNB/ng-eNB uses the UP security activation status to activate the UP security.

• The gNB network product shall be connected in emulated/real network environments.

• The UE may be simulated.

1. The gNB under test establishes RRC connection and AS security context with the UE.

2. The gNB under test establishes security context between the UE and the SN for the given AS security context shared between the gNB under test and the UE; and generates a K~SN~ sent to the SN and increases the value of SN Counter;

3. A SCG bearer is set up between the UE and the SN.

4. The gNB under test is triggered to execute the SN Modification procedure to provide updated K~SN~ to SN, until the SN Counter value wraps around.

TR 33.926 [5], clause D.2.2.4 -- User plane data integrity protection.

Integrity protection of user data between the UE and the gNB.

TS 33.501 [2], clause 5.3.3

The gNB supports integrity protection and replay protection of user data between the UE and the gNB as specified in TS 33.501 [2], clause 5.3.3.

NOTE: This requirement does not apply to the gNB that is used as a secondary node connecting to the EPC.

To verify that the user data packets are integrity protected over the NG RAN air interface.

• The gNB network product shall be connected in emulated/real network environments. UE may be simulated.

• Tester shall enable the user plane integrity protection and ensure NIA0 is not used.

• Tester shall have knowledge of integrity algorithm and integrity protection keys.

• The tester can capture the message via the NG RAN air interface, or can capture the message at the UE.

• The NIA0 is disabled at the UE and gNB.

1. The tester triggers the gNB to send RRCConnectionReconfiguration with integrity protection indication "on".

2. The tester checks any User data sent by gNB after sending RRCConnectionReconfiguration and before UE enters CM-Idle state is Integrity protected.

Any user plane packets sent between UE and gNB over the NG RAN air interface after gNB sending RRCConnectionReconfiguration is integrity protected.

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

TR 33.926 [5], clause D.2.2.4 -- User plane data integrity protection.

Integrity protection of user data between the UE and the gNB.

TS 33.501 [2], clause 5.3.3

NOTE: This requirement does not apply to the gNB that is used as a secondary node connecting to the EPC.

To verify that the user data packets are integrity protected over the NG RAN air interface.

• The gNB network product shall be connected in emulated/real network environments. UE may be simulated.

• Tester shall enable the user plane integrity protection and ensure NIA0 is not used.

• Tester shall have knowledge of integrity algorithm and integrity protection keys.

• The tester can capture the message via the NG RAN air interface, or can capture the message at the UE.

The NIA0 is disabled at the UE and gNB.

1. The NIA0 is disabled at UE and gNB.

2. gNB sends RRCConnectionReconfiguration with integrity protection indication "on".

3. Check any User data sent by gNB after sending RRCConnectionReconfiguration and before UE enters CM-Idle state is Integrity protected.

Any user plane packets sent between UE and gNB over the NG RAN air interface after gNB sending RRCConnectionReconfiguration is integrity protected.

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

TBD

Expired Certificate checking at base station

TS 33.310 [10], clause 7.2

Certificate Management Protocol v2 (CMPv2) [11] may be the supported protocol to provide certificate lifecycle management capabilities for TLS entities. All TLS entities and TLS CAs may support initial enrolment by the TLS entity to the TLS CA via CMPv2, i.e. receiving a certificate from the TLS CA, and updating the key of the certificate via CMPv2 before the certificate expires.

Verify that the gNB can check whether its certificate issued by operator CA is about to expire and to act accordingly.

• If the gNB under test does not support handling certificates as defined in clause 9 of TS 33.310[10], this test does not apply.

• The gNB network product is connected in emulated/real network environments.

• A TLS CA may be emulated, if needed.

• The gNB is configured the necessary information to connect with the CA server.

• Optionally, the vendor may provide necessary information in a document, e.g. describing how to handle the case when a gNB checks the operator certificate is about to be expired.

1. The tester configures the gNB with certificates that is assigned by operator CA.

2. The tester configures the UTC timer of gNB to the time when its own certificate is about to be expired.

3. The gNB initiates the CMPv2 procedure to get the new operator certificate.

• The gNB raises an alarm or requests a new certificate from the CA.

• The gNB received a new operator certificate.

The logs and the communication flow in a .pcap file.

Peer certificate checking at base station

TS 33.310 [10], clause 9.5.1

• The base station may be pre-provisioned with the operator root CA certificate.

• If the base station is not pre-provisioned with the operator root CA certificate, then the base station takes the operator root certificate from the certificates received in the initialization response. The selection is based on checking which root certificate can be used to validate the received base station certificate.

NOTE1: Examples on validation factors defined in clause 6.3.1 of TS 33.310[10] can be taken into consideration, for example, whether the certificated has been revoked, expired, on the CRL distribution point is empty, etc.

Verify that the gNB has the ability to check the peer certificate is valid or not.

• If the gNB under test does not support handling certificates as defined in clause 9 of TS 33.310[10], this test does not apply.

• The gNB is configured with or has obtained an operator root CA certificate.

• The gNB network product shall be connected in emulated/real network environments.

• A peer, e.g., AMF, SEG, gNB may be emulated.

NOTE2: According to 5GS, only AMF, SEG/UPF, gNB can connect to a gNB. The peer means the network function that provides the operator assigned certificate to the gNB for establishing the N2, N3, Xn interfaces.

• The gNB is configured the necessary information to connect with the peer.

• Optionally, the vendor may provide necessary information in a document, e.g., describing the checking factors and how to handle the case when a gNB validate the certificate is invalid.

1. The tester configures the peer with an invalid certificate e.g., by using a wrong signature or a certificate that has expired.

2. The tester triggers the gNB to connect to the peer.

The gNB does not connect with the peer and may raise an alarm at the same time.

The logs and the communication flow in a .pcap file.

TR 33.926 [5], clause D.2.2.2, Control plane data integrity protection

RRC integrity check failure

TS 33.501 [2], clause 6.5.1

The RRC integrity checks are performed both in the ME and the gNB. In case failed integrity check (i.e. faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message is discarded. This can happen on the gNB side or on the ME side, as specified in TS 33.501 [2], clause 6.5.1.

Verify that RRC integrity check failure is handled correctly by the gNB.

Test environment with a UE. The UE may be simulated. RRC integrity protection is activated at the gNB.

The UE sends a RRC message to the gNB without MAC-I;

or

The UE sends a RRC message to the gNB with a wrong MAC-I.

NOTE: RRC integrity protection is provided by PDCP. In a PDCP message without MAC-I, the last 4 Bytes of the PCDP Data will be interpreted as a wrong MAC-I and therefore the integrity check will fail.

The RRC message is discarded by the gNB.

Sample copies of the log files.

RRC integrity check failure

TS 33.501 [2], clause 6.5.1

Verify that RRC integrity check failure is handled correctly by the gNB.

Test environment with a UE. The UE may be simulated. RRC integrity protection is activated at the gNB.

Sample copies of the log files.

TR 33.926 [5], clause D.2.2.4, User plane data integrity protection

UP integrity check failure

TS 33.501 [2], clause 6.6.4

If the gNB or the UE receives a PDCP PDU which fails integrity check with faulty or missing MAC-I after the start of integrity protection, the PDU is discarded as specified in TS 33.501 [2], clause 6.6.4.2.

Verify that UP integrity check failure is handled correctly by the gNB.

Test environment with a UE. The UE may be simulated. UP integrity protection is activated at the gNB.

The UE sends a PDCP PDU to the gNB without MAC-I;

or

The UE sends a PDCP PDU to the gNB with a wrong MAC-I.

NOTE: In a PDCP PDU message without MAC-I, the last 4 Bytes of the PCDP PDU Data will be interpreted as a wrong MAC-I and therefore the integrity check will fail.

The PDCP PDU is discarded by the gNB.

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

UP integrity check failure

TS 33.501 [2], clause 6.6.4

Verify that UP integrity check failure is handled correctly by the gNB.

Test environment with a UE. The UE may be simulated. UP integrity protection is activated at the gNB.

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

TR 33.926 [5], clause D.2.2.1 -- Control plane data confidentiality protection.

Ciphering of RRC-signalling

TS 33.501 [2], clause 5.3.2

The gNB supports ciphering of RRC-signalling as specified in TS 33.501 [2], clause 5.3.2.

To verify that the RRC-signalling data sent between UE and gNB over the NG RAN air interface are confidentiality protected.

• The gNB network product shall be connected in emulated/real network environments. The UE may be simulated.

• The tester shall have access to the NG RAN air interface or can capture the message at the UE.

1. The tester triggers the UE to send a Registraton Request to the AMF.

2. The AMF sends a KgNB and the UE security capability to the gNB.

3. The gNB selects an algorithm and sends AS SMC to the UE.

4. The gNB receive AS SMP from the UE.

Control plane packets sent to the UE after the gNB sends AS SMC is ciphered.

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

TR 33.926 [5], clause D.2.2.1 -- Control plane data confidentiality protection.

Ciphering of RRC-signalling

TS 33.501 [2], clause 5.3.2

To verify that the RRC-signalling data sent between UE and gNB over the NG RAN air interface are confidentiality protected.

• The gNB network product shall be connected in emulated/real network environments. The UE may be simulated.

• The tester shall have access to the NG RAN air interface or can capture the message at the UE.

1. The UE sends a Registraton Request to the AMF.

2. The AMF sends a KgNB and the UE security capability to the gNB.

3. The gNB selects an algorithm and sends AS SMC to the UE.

4. The gNB receive AS SMP from the UE.Expected Results:

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

TR 33.926 [5], clause D.2.2.3 -- User plane data confidentiality protection at gNB

Ciphering of user data between the UE and the gNB

TS 33.501 [2], clause 5.3.2

The gNB supports ciphering of user data between the UE and the gNB. as specified in TS 33.501 [2], clause 5.3.2.

To verify that the user data packets are confidentiality protected over the NG RAN air interface.

• The gNB network product shall be connected in emulated/real network environments. The UE may be simulated.

• The tester shall have access to the NG RAN air interface or can capture the message at the UE.

1. The tester triggers theUE to send PDU session establishment Request to the SMF.

2. The SMF sends a UP security policy with UP ciphering required or preferred to the gNB.

3. The gNB sends RRCConnectionReconfiguration with ciphering protection indication "on".

4. The tester checks any user data sent by the gNB after sending RRCConnectionReconfiguration and before the UE enters into CM-Idle state.

The user plane packets sent to the UE after the gNB sends RRCConnectionReconfiguration is confidentiality protected.

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

TR 33.926 [5], clause D.2.2.3 -- User plane data confidentiality protection at gNB

Ciphering of user data between the UE and the gNB

TS 33.501 [2], clause 5.3.2

To verify that the user data packets are confidentiality protected over the NG RAN air interface.

• The gNB network product shall be connected in emulated/real network environments. The UE may be simulated.

• The tester shall have access to the NG RAN air interface or can capture the message at the UE.

1. The UE sends PDU session establishment Request to the SMF.

2. The SMF sends a UP security policy with UP ciphering required or preferred to the gNB.

3. The gNB sends RRCConnectionReconfiguration with ciphering protection indication "on".

4. Check any user data sent by the gNB after sending RRCConnectionReconfiguration and before the UE enters into CM-Idle state.

The user plane packets sent to the UE after the gNB sends RRCConnectionReconfiguration is confidentiality protected.

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

TR 33.926 [5], clause D.2.2.4 -- User plane data integrity protection.

Replay protection of user data between the UE and the gNB.

TS 33.501 [2], clause 5.3.3

The gNB supports integrity protection and replay protection of user data as specified in TS 33.501 [2], clause 5.3.3.

To verify that the user data packets are replay protected over the NG RAN air interface.

• The gNB network product shall be connected in emulated/real network environments. The UE may be simulated.

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

• The tester shall have access to the N3 interface.

• The tester shall activate the user plane integrity protection of user data packets.

1. The tester shall capture the user plane data sent between UE and gNB using any network analyser over the NG RAN air interface.

2. Tester shall filter user plane data packets sent between UE and gNB.

3. Tester shall replay the captured user plane packets or shall use any packet crafting tool to create a user plane packet similar to the captured user plane packet and replay to the gNB.

4. Tester shall check whether the replayed user plane packets were processed by the gNB by capturing over NG RAN air interface to see if any corresponding response message is received from the gNB or by verifying the gNB log files if there are entries about UP packet discard or by capturing the N3 interface to see if any of the replayed user plane packets have been forwarded by the gNB.

5. Tester shall confirm that gNB provides replay protection by dropping/ignoring the replayed packet if no corresponding response is received from the gNB to the replayed packet or if the gNB logs include corresponding log entries or if no replayed user plane packets have been forwarded over the N3 interface.

6. Tester shall verify from the result that if the replayed user plane packets are not accepted by gNB, the NG RAN air interface is replay protected.

The user plane packets sent between the UE and gNB over the NG air interface is replay protected.

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

• Log files, e.g., containing corresponding log events.

TR 33.926 [5], clause D.2.2.4 -- User plane data integrity protection.

Replay protection of user data between the UE and the gNB.

TS 33.501 [2], clause 5.3.3

To verify that the user data packets are replay protected over the NG RAN air interface.

• The gNB network product shall be connected in emulated/real network environments. The UE may be simulated.

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

• The tester shall active the user plane integrity protection of the RRC-signalling packets.

1. The tester shall capture the user plane data sent between UE and gNB using any network analyser over the NG RAN air interface.

2. Tester shall filter user plane data packets sent between UE and gNB.

3. Tester shall replay the captured user plane packets or shall use any packet crafting tool to create a user plane packet similar to the captured user plane packet and replay to the gNB.

4. Tester shall check whether the replayed user plane packets were processed by the gNB by capturing over NG RAN air interface to see if any corresponding response message is received from the gNB.

5. Tester shall confirm that gNB provides replay protection by dropping/ignoring the replayed packet if no corresponding response is received from the gNB to the replayed packet.

6. Tester shall verify from the result that if the replayed user plane packets are not accepted by gNB, the NG RAN air interface is replay protected.

The user plane packets sent between the UE and gNB over the NG air interface is replay protected.

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

TR 33.926 [5], clause D.2.2.2 -- Control plane data integrity protection.

Replay protection of RRC-signalling.

TS 33.501 [2], clause 5.3.3

The gNB supports integrity protection and replay protection of RRC-signalling as specified in TS 33.501 [2], clause 5.3.3.

To verify the replay protection of RRC-signalling between UE and gNB over the NG RAN air interface.

• The gNB network product shall be connected in emulated/real network environments.

• Tester shall have knowledge of the integrity algorithm and the corresponding protection keys.

• The tester shall have access to the NG RANs air interface.

• The tester shall have access to the N2 interface.

• The tester shall activate the integrity protection of RRC-signalling.

1. The tester shall capture the data sent between UE and the gNB using any network analyser over the NG RAN air interface.

2. Tester shall filter RRC signalling packets.

3. Tester shall check for the PDCP COUNT of the filtered RRC signalling packets and shall use any packet crafting tool to create RRC signalling packets similar to the captured packets or the tester shall replay the captured RRC uplink packet to the gNB to perform the replay attack over gNB.

4. Tester shall check whether the replayed RRC signalling packets were processed by the gNB or not, by capturing over NG RAN air interface to see if any corresponding response message is received from the gNB or by verifying the gNB log files if there are entries about RRC packet discard or by capturing the N2 interface to see if any of the replayed user plane packets have been forwarded by the gNB.

5. Tester shall confirm that gNB provides replay protection by dropping/ignoring the replayed packet if no corresponding response is sent by the gNB to the replayed packet or if the gNB logs include corresponding log entries or if no replayed user plane packets have been forwarded over the N2 interface.

The RRC signalling over the NG RAN air interface is replay protected.

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

• Log files, e.g., containing corresponding log events.

TR 33.926 [5], clause D.2.2.2 -- Control plane data integrity protection.

Replay protection of RRC-signalling.

TS 33.501 [2], clause 5.3.3

To verify the replay protection of RRC-signalling between UE and gNB over the NG RAN air interface.

• The gNB network product shall be connected in emulated/real network environments.

• Tester shall have knowledge of the integrity algorithm and the corresponding protection keys.

• The tester shall have access to the NG RANs air interface.

• The tester shall active the user plane integrity protection of the user data packets.

1. The tester shall capture the data sent between UE and the gNB using any network analyser over the NG RAN air interface.

2. Tester shall filter RRC signalling packets.

3. Tester shall check for the RRC SQN of the filtered RRC signalling packets and shall use any packet crafting tool to create RRC signalling packets similar to the captured packets or the tester shall replay the captured RRC uplink packet to the gNB to perform the replay attack over gNB.

4. Tester shall check whether the replayed RRC signalling packets were processed by the gNB or not, by capturing over NG RAN air interface to see if any corresponding response message is received from the gNB.

5. Tester shall confirm that gNB provides replay protection by dropping/ignoring the replayed packet if no corresponding response is sent by the gNB to the replayed packet.

The RRC signalling over the NG RAN air interface is replay protected.

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