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.

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

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 the user data packets are confidentiality protected 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.

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.

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

1. Tester shall check that the captured UP data is activated/de-activated according to the UP security policy.

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 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 the user data packets are confidentiality protected 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.

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.

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

1. Tester shall check that the captured UP data is activated/de-activated according to the UP security policy.

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 the user data packets are integrity protected 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 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.

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

When the received UP integrity protection is set to "required", the user plane data packet contains a message authentication code and the user plane packets are integrity protected based on the security policy sent by the SMF.

When the received UP interity protection is set to "not needed", the user plane data packet message authentication code is not present and 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 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 the user data packets are integrity protected 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 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.

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

When the received UP integrity protection is set to "required", the user plane data packet contains a message authentication code and the user plane packets are integrity protected based on the security policy sent by the SMF.

When the received UP interity protection is set to "not needed", the user plane data packet message authentication code is not present and 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], 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 serving network selects the algorithms to use dependent on: the UE security capabilities of the UE, the configured allowed list of security capabilities of the currently serving network entity as specified in TS 33.501 [2], clause 5.11.2.

"Each gNB/ng-eNB 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 UE sends 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], 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 serving network selects the algorithms to use dependent on: the UE security capabilities of the UE, the configured allowed list of security capabilities of the currently serving network entity as specified in TS 33.501 [2], clause 5.11.2.

"Each gNB/ng-eNB 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 UE sends 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

Test Case :

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

Part of log that shows all the DRB identities and the intra-cell handover or the transition from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE and then back to RRC_CONNECTED. This part can be presented, for example, as a screenshot.

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

Test Case :

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

Part of log that shows all the DRB identities and the intra-cell handover or the transition from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE and then back to RRC_CONNECTED. This part can be presented, for example, as a screenshot.

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 target gNB sends 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], 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 target gNB sends 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:

Source gNB transfers the ciphering and integrity algorithms used in the source cell to the target gNB in the handover request message.

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:

AMF sends the UE NR security capability to the Target gNB.

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:

1. The UE checks the message authentication code on the handover command message.

2. The MAC in the handover complete message is verified, and the AS integrity protection algorithm is selected and applied correctly.

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:

Source gNB transfers the ciphering and integrity algorithms used in the source cell to the target gNB in the handover request message.

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:

AMF sends the UE NR security capability to the Target gNB.

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:

1. The UE checks the message authentication code on the handover command message.

2. The MAC in the handover complete message is verified, and the AS integrity protection algorithm is selected and applied correctly.

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

Part of log that shows the SN Counter values before and after wrapping around and the intra-cell handover or the transition from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE and then back to RRC_CONNECTED. 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

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

Part of log that shows the SN Counter values before and after wrapping around and the intra-cell handover or the transition from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE and then back to RRC_CONNECTED. This part can be presented, for example, as a screenshot.

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.

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.

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.

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.

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.

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.

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.

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

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

2b) The gNB verifies the integrity of the RRC message from the UE.

The RRC message is discarded by the gNB after step 1a) or after step 2b).

Sample copies of the log files.

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.

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

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

2b) The gNB verifies the integrity of the RRC message from the UE.

The RRC message is discarded by the gNB after step 1a) or after step 2b).

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.

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

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

2b) The gNB verifies the integrity of the PDCP PDU from the UE.

The PDCP PDU is discarded by the gNB after step 1a) or after step 2b).

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

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.

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

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

2b) The gNB verifies the integrity of the PDCP PDU from the UE.

The PDCP PDU is discarded by the gNB after step 1a) or after step 2b).

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

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

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

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.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 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.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 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 RRC-signalling 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 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.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 RRC-signalling 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 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 active 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 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.

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