The present document contains objectives, requirements and test cases that are specific to the gNB network product class. It refers to the Catalogue of General Security Assurance Requirements and formulates specific adaptions of the requirements and test cases given there, as well as specifying requirements and test cases unique to the gNB network product class.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
5GC
gNB specific security requirements include both requirements derived from gNB-specific security functional requirements as well as security requirements derived from threats specific to gNB as described in TR 33.926. Generic security requirements and test cases common to other network product classes have been captured in TS 33.117 and are not repeated in the present document.
"The RRC integrity checks shall be 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 shall be discarded. This can happen on the gNB side or on the ME side." as specified in clause 6.5.1 of TS 33.501.
"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 shall be discarded." as specified in clause 6.6.4 of TS 33.501.
To verify that the user data packets are replay protected over the NG RAN air interface.
Pre-Condition:
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.
Execution Steps:
The tester shall capture the user plane data sent between UE and gNB using any network analyser over the NG RAN air interface.
Tester shall filter user plane data packets sent between UE and gNB.
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.
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.
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.
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.
Expected Results:
The user plane packets sent between the UE and gNB over the NG air interface is replay protected.
Expected format of evidence:
Evidence suitable for the interface, e.g. Screenshot containing the operational results.
To verify the replay protection of RRC-signalling between UE and gNB over the NG RAN air interface.
Pre-Condition:
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.
Execution Steps:
The tester shall capture the data sent between UE and the gNB using any network analyser over the NG RAN air interface.
Tester shall filter RRC signalling packets.
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.
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.
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.
Expected Results:
The RRC signalling over the NG RAN air interface is replay protected.
Expected format of evidence:
Evidence suitable for the interface, e.g. Screenshot containing the operational results.
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.
The tester shall decrypt the RRC connection Reconfiguration message and retrieve the UP ciphering protection indication presenting in the decrypted message.
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.
Tester shall check that the captured UP data is activated/de-activated according to the UP security policy.
Expected Results:
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.
Expected format of evidence:
Evidence suitable for the interface, e.g. Screenshot containing the operational results.
To verify that the user data packets are integrity protected based on the security policy sent by the SMF.
Pre-Condition:
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.
Execution Steps:
The tester triggers PDU session establishment procedure by sending PDU session establishment request message.
Tester shall trigger the SMF to send the UP security policy with integrity protection is "required" or "not needed" to the gNB.
The tester shall capture the RRC connection reconfiguration message sent by gNB to UE over NG RAN air interface.
The tester shall decrypt the RRC connection reconfiguration message and retrieve the UP integrity protection indication presenting in the decrypted message.
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.
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.
Expected Results:
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.
Expected format of evidence:
Evidence suitable for the interface, e.g. Screenshot containing the operational results.
"The serving network shall select 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 clause 5.11.2 of TS 33.501.
"Each gNB shall be configured via network management with lists of algorithms which are allowed for usage. There shall be one list for integrity algorithms, and one for ciphering algorithms. These lists shall be ordered according to a priority decided by the operator." as specified in clause 6.7.3.0 of TS 33.501.
Verify that the gNB selects the algorithms with the highest priority in its configured list.
Pre-Conditions:
Test environment with the gNB has been pre-configured with allowed security algorithms with priority.
Execution Steps
The UE sends registration request message to the gNB.
The gNB receives UE context setup request message.
The gNB sends the AS SECURITY MODE COMMAND message.
The UE replies with the AS SECURITY MODE COMPLETE message.
Expected Results:
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.
"Key refresh shall be possible for KgNB, KRRC-enc, KRRC-int, KUP-int, and KUP-enc and shall be initiated by the gNB when a PDCP COUNTs are about to be re-used with the same Radio Bearer identity and with the same KgNB." as specified in clause 6.9.4.1 of TS 33.501.
"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. In order to avoid such re-use, the network may e.g. use 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 clause 5.3.1.2 of TS 38.331.
Verify that the gNB performs KgNB 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.
Pre-Conditions:
The UE, AMF and SMF may be simulated.
Execution Steps
The gNB sends the AS Security Mode Command message to the UE.
The UE responds with the AS Security Mode Complete message.
A DRB is set up.
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.
Expected Results:
Before DRB ID reuse, the gNB takes a new KgNB 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.
Expected format of evidence:
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.
"In the Path-Switch message, the target gNB shall send the UE's 5G security capabilities, UP security policy with corresponding PDU session ID received from the source gNB to the AMF." as specified in clause 6.7.3.1 of TS 33.501.
"The target gNB shall select the algorithm with highest priority from the UE's 5G security capabilities according to the locally configured prioritized list of algorithms (this applies for both integrity and ciphering algorithms). The chosen algorithms shall be indicated to the UE in the Handover Command message if the target gNB selects different algorithms compared to the source gNB" as specified in clause 6.7.3.1 and clause 6.7.3.2 of TS 33.501.
Verify that AS protection algorithm is selected correctly.
Pre-Conditions:
Test environment with source gNB, target gNB and AMF. Source gNB and AMF may be simulated.
Execution Steps:
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.
Expected Results:
For both test cases:
The UE checks the message authentication code on the handover command message.
The MAC in the handover complete message is verified, and the AS integrity protection algorithm is selected and applied correctly.
"The transport of control plane data over N2 shall be integrity, confidentiality and replay-protected." "The transport of control plane data and user data over Xn shall be integrity, confidentiality and replay-protected." as specified in clauses 9.2 and 9.4 of TS 33.501.
"The transport of control plane data over N2 shall be integrity, confidentiality and replay-protected." "The transport of control plane data and user data over Xn shall be integrity, confidentiality and replay-protected." as specified in clauses 9.2 and 9.4 of TS 33.501.
"When executing the procedure for adding subsequent radio bearer(s) to the same SN, the MN shall, for each new radio bearer, assign a radio bearer identity that has not previously been used since the last KSN 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 shall increment the SN Counter and compute a fresh KSN, and then shall perform a SN Modification procedure to update the KSN" as specified in clause 6.10.2.1 of TS 33.501.
"The MN shall 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 the present document. When the root key is refreshed, the SN Counter is reset to '0' as defined above." as specified in clause 6.10.3.1 of TS 33.501.
Verify that the gNB under test acting as a Master Node (MN) performs KSN update when DRB-IDs are about to be reused.
Pre-Conditions:
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
Execution Steps
The gNB under test establishes RRC connection and AS security context with the UE.
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 KSN sent to the SN.
A SCG bearer is set up between the UE and the SN.
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.
Expected Results:
Before DRB ID reuse, the gNB under test generates a new KSN and sends it via the SN Modification Request message to the SN.
Expected format of evidence:
Evidence suitable for the interface, e.g. text representation of the captured SN Modification Request message.
Test Case 2:
Test Name:
TC_GNB_DC_KEY_UPDATE_SN_COUNTER
Purpose:
Verify that the gNB under test acting as a Master Node (MN) performs KNG-RAN( AS root key) update when SN COUNTER is about to wrap around.
Pre-Conditions:
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.
Execution Steps
The gNB under test establishes RRC connection and AS security context with the UE.
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 KSN sent to the SN and increases the value of SN Counter.
A SCG bearer is set up between the UE and the SN.
The gNB under test is triggered to execute the SN Modification procedure to provide updated KSN to SN, until the SN Counter value wraps around.
Expected Results:
Before SN Counter wraps around, the gNB under test takes a new KNG-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.
Expected format of evidence:
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.
"If the UP security activation status can be supported in the target gNB/ng-eNB, the target gNB/ng-eNB shall use the UP security activations that the UE used at the last source cell. Otherwise, the target gNB/ng-eNB shall respond with an RRC Setup message to establish a new RRC connection with the UE." as specified in clause 6.8.2.1.3 of TS 33.501.
Verify that the target gNB/ng-eNB uses the UP security activation status to activate the UP security.
Pre-Conditions:
The gNB network product shall be connected in emulated/real network environments.
The UE may be simulated.
Execution Steps
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.
The gNB sends RRC Release message with a suspend config to the UE.
The tester deletes the UP security activation status of the UE.
The tester triggers the UE to send RRC Resume message.
In case of remote base station auto deployment, Router Advertisement can be processed. Apart from the above exceptions, there are no gNB-specific additions to clause 4.2.4 of TS 33.117.