Content for TS 33.117 Word version: 17.2.0

1… 4.2… 4.2.3… 4.2.3.4… 4.2.3.5… 4.2.4… 4.3… 4.3.4… 4.4…

4.2 Security functional requirements and related test cases 4.2.1 Introduction 4.2.2 Security functional requirements deriving from 3GPP specifications and related test cases 4.2.2.1 Security functional requirements deriving from 3GPP specifications - general approach 4.2.2.2 Security functional requirements derived from 3GPP specifications - general SBA/SBI aspects
...

4.2 Security functional requirements and related test cases p. 10

4.2.1 Introduction p. 10

The present clause describes the security functional requirements and the corresponding test cases, independent of a specific network product class. In particular the proposed security requirements are classified in two groups:

Security functional requirements deriving from 3GPP specifications and detailed in clause 4.2.2
General security functional requirements which include requirements not already addressed in the 3GPP specifications but whose support is also important to ensure a network product conforms to a common security baseline detailed in clause 4.2.3.

4.2.2 Security functional requirements deriving from 3GPP specifications and related test cases p. 10

4.2.2.1 Security functional requirements deriving from 3GPP specifications - general approach p. 10

The present clause describes the general approach taken towards security functional requirements deriving from 3GPP specifications and the corresponding test cases, independent of a specific network product class.

It is assumed for the purpose of the present SCAS that a network product conforms to all mandatory security-related provisions in 3GPP specifications pertaining to it, in particular:

all 3GPP specifications of the 33-series (security specifications) that are pertinent to the network product class;
other 3GPP specifications that make reference to security specifications or are referred to from one of them.

3GPP has decided to develop test specifications for the UE in the TSs of the 34-series under the responsibility of Working Group RAN5. 3GPP saw, however, no need to develop test specifications for network elements. For network elements, 3GPP rather trusts that tests are run under the responsibility of the vendors.

Security procedures pertaining to a network product are typically embedded in non-security procedures and are hence assumed to be tested together with them.

It is the purpose of the present SCAS to identify security requirements from the EPS and 5G security architecture that require special attention in testing as they may:

lead to vulnerabilities when not satisfied;
not be captured through ordinary testing activity for non-security procedures;
address security-relevant failure cases and exceptions or 'negative' requirements of the kind: "The network product shall not…"

It is not an intention of the present document to provide an exhaustive set of test cases that would be sufficient to demonstrate conformance of all security procedures with the above-mentioned specifications.

4.2.2.2 Security functional requirements derived from 3GPP specifications - general SBA/SBI aspects |R16| p. 11

4.2.2.2.1 Introduction p. 11

The purpose of the sub-clauses in clause 4.2.2.2 is to identify and describe the general baseline requirements from SBA security architecture and the corresponding test cases. The general baseline requirements are applicable to all Network Function (NF) within the 5G Core (5GC) utilizing Service-Based Interfaces (SBI), independent of a specific network product class.

4.2.2.2.2 Protection at the transport layer p. 11

Requirement Name:

Protection at the transport layer

Requirement Reference:

Clause 5.9.2.1, clause 13.1, clause 13.3.2 of TS 33.501

Requirement Description:

"NF Service Request and Response procedure shall support mutual authentication between NF consumer and NF producer"

as specified in clause 5.9.2.1 of TS 33.501

"All network functions shall support TLS. Network functions shall support both server-side and client-side certificates.

The TLS profile shall follow the profile given in Annex E of TS 33.310 with the restriction that it shall be compliant with the profile given by HTTP/2 as defined in RFC 7540."

as specified in clause 13.1 of TS 33.501.

"Authentication between network functions within one PLMN shall use one of the following methods:

If the PLMN uses protection at the transport layer as described in clause 13.1, authentication provided by the transport layer protection solution shall be used for authentication between NFs."

as specified in clause 13.3.2 of TS 33.501.

Threat References:

Clause 5.3.6.3 of TR 33.926, Weak cryptographic algorithms

Test case:

Test Name:

TC_PROTECT_TRANSPORT_LAYER

Purpose:

Verify that TLS protocol for NF mutual authentication and NF transport layer protection is implemented in the network products based on the profile required.

Procedure and execution steps:

Pre-Conditions:

Network product documentation containing information about supported TLS protocol and certificates is provided by the vendor.

A peer implementing the TLS protocol configured by the vendor shall be available.

The tester shall base the tests on the profile defined by 3GPP in Annex E of TS 33.310 with the restriction that it shall be compliant with the profile given by HTTP/2 as defined in RFC 7540.

Execution Steps:

The tester shall check that compliance with the TLS profile can be inferred from detailed provisions in the network product documentation.
The tester shall establish a secure connection between the network product under test and the peer and verify that all TLS protocol versions and combinations of cryptographic algorithms that are mandated by the TLS profile are supported by the network product under test.
The tester shall try to establish a secure connection between the network product under test and the peer and verify that this is not possible when the peer only offers a feature, including protocol version and combination of cryptographic algorithms, that is forbidden by the TLS profile.

Expected Results:

The network product under test and the peer establish TLS if the TLS profiles used by the peer are compliant with the profile requirements in TS 33.310 Annex E and RFC 7540.
The network product under test and the peer fail to establish TLS if the TLS profiles used by the peer are forbidden in TS 33.310 Annex E or RFC 7540.

Expected format of evidence:

Provide evidence of the check of the product documentation in plain text. Save the logs and the communication flow in a .pcap file.

4.2.2.2.3 Authorization of NF service access p. 12

4.2.2.2.3.1 Authorization token verification failure handling wthin one PLMN p. 12

Requirement Name:

Authorization token verification failure handling wthin one PLMN

Requirement Reference:

Clause 13.4.1.1 of TS 33.501

Requirement Description:

"13.4.1.1 Service access authorization within the PLMN

The NF Service producer shall verify the access token as follows:
- The NF Service producer ensures the integrity of the access token by verifying the signature using NRF's public key or checking the MAC value using the shared secret. If integrity check is successful, the NF Service producer shall verify the claims in the access token as follows:
  
  NOTE:
  Void.
- It checks that the audience claim in the access token matches its own identity or the type of NF service producer. If a list of NSSAIs or list of NSI IDs is present, the NF service producer shall check that it serves the corresponding slice(s).
- If an NF Set ID present, the NF Service Producer shall check the NF Set ID in the claim matches its own NF Set ID.
- If the access token contains "additional scope" information (i.e. allowed resources and allowed actions (service operations) on the resources), it checks that the additional scope matches the requested service operation.
- If scope is present, it checks that the scope matches the requested service operation.
- It checks that the access token has not expired by verifying the expiration time in the access token against the current data/time.
If the verification is successful, the NF Service producer shall execute the requested service and responds back to the NF Service consumer. Otherwise it shall reply based on Oauth 2.0 error response defined in RFC 6749. The NF service consumer may store the received token(s). Stored tokens may be re-used for accessing service(s) from producer NF type listed in claims (scope, audience) during their validity time.

Threat References:

Clause 6.3.3.1 of TR 33.926, Incorrect Verification of Access Tokens

Test Case:

Test Name:

TC_AUTHORIZATION_TOKEN_VERIFICATION_FAILURE_ONE_PLMN

Purpose:

Verify that the NF service producer does not grant service access if the verification of authorization token from a NF service consumer in the same PLMN fails.

Procedure and execution steps:

Pre-Conditions:

Test environment with a NF service consumer.
The NF service consumer may be simulated.
The network product under test has already mutually authenticated with the NF service consumer.
The tester shall have access to the interface between the NF service consumer and the network product under test.
The tester has the NRF's private key or the shared key.
The network product under test is preconfigured with the NRF's public key or the shared key.

Execution Steps:

The network product under test receives the access token sent from the NF service consumer, verifies the access token based on Oauth 2.0.

Test Cases 1~4 are tests on failure handling by the network product under test when the mandatory claims in access token failed verification.

Test Case 1: Verification failure of the access token integrity

The tester computes an access token correctly, except that the signature or the MAC is incorrect, e.g., the signature or the MAC is randomly selected, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.
The integrity verification of the access token by the network product under test fails.

Test Case 2: Incorrect audience claim in the access token

The tester computes an access token correctly, except that the audience claim is incorrect, i.e., the audience claim in the access token does not match the identity or the type of the network product under test, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.
The network product under test verifies that the integrity of the access token is valid. However, the audience claim in the access token does not match its identity or type.

Test Case 3: Incorrect scope claim in the access token

The tester computes an access token correctly, except that the scope is incorrect, i.e., the scope does not match the requested service operation, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.
The network product under test verifies that the integrity of the access token and the audience claim are valid. However, the scope does not match the requested service operation.

Test Case 4: Expired access token

The tester computes an access token correctly, except that the expiration time has expired against the current data/time, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.
The network product under test verifies that the integrity of the access token, the audience and scope claims are all valid. However, the expiration time in the access token has expired against the current data/time.

Test Cases 5~8 are tests on failure handling by the network product under test when the optional claims in access token failed verification.

Test Case 5: Incorrect list of S-NSSAIs in the access token

The tester computes an access token correctly, except that the list of S-NSSAIs is incorrect, i.e., the network product under test does not serve the slices indicated in the list of S-NSSAIs, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.
The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the list of S--NSSAIs included in the access token.

Test Case 6: Incorrect list of NSIs in the access token

The tester computes an access token correctly, except that the list of NSIs is incorrect, i.e., the network product under test does not serve the slices indicated in the list of NSIs, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.
The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the list of NSIs included in the access token.

Test Case 7: Incorrect NF Set ID in the access token

The tester computes an access token correctly, except that the NF Set ID is incorrect, i.e. the NF Set ID in the claim does not match the NF Set ID of the network product under test, and then includes the access token in the NF Service Request sent from NF service consumer to the network product under test.
The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the NF Set ID included in the access token.

Test Case 8: Incorrect additional scope in the access token

The tester computes an access token correctly, except that the additional scope information is incorrect, i.e. the allowed resources and allowed actions on the resources do not match the requested service operations, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test.
The network product under test verifies that the integrity of the access token, the audience, scope and expiration time claims are all valid. Then it further checks the additional scope included in the access token.

Expected Results:

For test cases 1~4 on verification failure of mandatory claims in the access token, the network product under test rejects the NF service consumer's service request based on Oauth 2.0 error response defined in RFC 6749.

For test cases 5~8 on verification failure of optional claims in the access token, if the network product under test understands these optional claims (list of S-NSSAIs, list of NSIs, NF Set ID, additional scope), it rejects the NF service consumer's service request based on Oauth 2.0 error response defined in RFC 6749.

Expected format of evidence:

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

4.2.2.2.3.2 Authorization token verification failure handling in different PLMNs p. 14

Requirement Name:

Authorization token verification failure handling in different PLMNs

Requirement Reference:

Clause 13.4.1.2 of TS 33.501

Requirement Description:

"The NF service producer shall check that the home PLMN ID of audience claim in the access token matches its own PLMN identity."

Threat References:

Clause 6.3.3.1 of TR 33.926, Incorrect Verification of Access Tokens

Test Case:

Test Name:

TC_AUTHORIZATION_TOKEN_VERIFICATION_FAILURE_DIFF_PLMN

Purpose:

Verify that the NF service producer does not grant service access if the verification of authorization token from a NF service consumer in a different PLMN fails.

Procedure and execution steps:

Pre-Conditions:

Test environment with a NF service consumer and two SEPPs (one cSEPP, one pSEPP).
The NF service consumer and SEPPs may be simulated.
The network product under test has already mutually authenticated with the NF service consumer in a different PLMN via the SEPPs.
The tester has the NRF's private key or the shared key.
The network product under test is preconfigured with the NRF's public key or the shared key.
The tester shall have access to the interfaces of the NF service consumer and the network product under test.

Execution Steps:

The network product under test receives the access token sent from the NF service consumer, verifies the access token in accordance with the execution steps in 4.2.2.1.2.1, with the following additional test cases:

Test Case 1: incorrect PLMN ID of the NF service producer in the access token

The test computes an access token correctly, except that the PLMN ID in the producerPlmnId claim of the access token is empty or different from the home PLMN ID of the network product under test, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test through the SEPPs.
The network product under test receives the access token sent from the NF service consumer through the SEPPs, verifies that the PLMN ID in the producerPlmnId claim of the access token is different from its own home PLMN identity.

Test Case 2: absent PLMN ID of the NF service producer in the access token

The test computes an access token correctly, except that no producerPlmnId claim is included in the access token, and then includes the access token in the NF Service Request sent from the NF service consumer to the network product under test through the SEPPs.
The network product under test receives the access token sent from the NF service consumer through the SEPPs, verifies that the access token is not a token to be used by the NF service consumer in a different PLMN, based on the absence of PLMN ID of the NF service producer in the access token.

Expected Results:

For both test cases 1 and 2, the network product under test rejects the NF service consumer's service request based on Oauth 2.0 error response defined in RFC 6749.

Expected format of evidence:

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

4.2.2.2.4 Authentication for Indirect Communication |R17| p. 16

4.2.2.2.4.1 Correct handling of client credentials assertion validation failure p. 16

Requirement Name:

Correct handling of client credentials assertion validation failure

Requirement Reference:

Clause 13.3.8.3 of TS 33.501

Requirement Description:

"The verification of the Client credentials assertion shall be performed by the receiving node, i.e., NRF or NF Service Producer in the following way:

It validates the signature of the JWS as described in RFC 7515.
If validates the timestamp (iat) and/or the expiration time (exp) as specified in RFC 7519.
F, the NRF validates the timestamp (iat) and the expiration time (exp).
If the receiving node is the NF Service Producer, the NF service Producer validates the expiration time and it may validate the timestamp.
It checks that the audience claim in the the client credentials assertion matches its own type.

It verifies that the NF instance ID in the client credentials assertion matches the NF instance ID in the public key certificate used for signing the assertion".

Threat References:

TR 33.926, clause 6.3.x.1, Incorrect validation of client credentials assertion

Test Case:

Test Name:

TC_CLIENT_CREDENTIALS_ASSERTION_VALIDATION

Purpose:

Verify that the NF under test correctly handles client credentials assertion validation failure.

Procedure and execution steps:

Pre-Conditions:

Test environment with a consumer NF and a SCP, which may be simulated. (Potentially simulated) consumer NF and (potentially simulated) SCP can be combined for the testing purpose.
The NF under test is preconfigured with the certificate of the consumer NF.
The NF under test is configured to require assertions for NF consumer authentication for at least one of its services.
The tester has the private key of the consumer NF.
The tester has access to the interface between the consumer NF and the NF under test.

Execution Steps:

Test Case 1: Failed verification of the client credentials assertion integrity

The tester computes a client credentials assertion correctly, except that the signature is incorrect, and then includes the client credentials assertion in the service request sent from the consumer NF to the NF under test via the SCP.
The integrity verification of the client credentials assertion by the NF under test fails.

Test Case 2: Incorrect audience claim in the client credentials assertion

The tester computes a client credentials assertion correctly, except that the audience claim is incorrect, i.e., the audience claim in the client credentials assertion does not match the type of the NF under test, and then includes the signed client credentials assertion in the service request sent from the consumer NF to the NF under test via the SCP.
The NF under test verifies that the audience claim in the client credentials assertion does not match its type.

Test Case 3: Expired client credentials assertion

The tester computes an access token correctly, except that the expiration time (exp) has expired against the current time, and then includes the signed client credentials assertion in the service request sent from the consumer NF to the NF under test via the SCP.
The NF under test verifies that the expiration time in the client credentials assertion has expired against the current time.

Expected Results:

For test cases 1~3, the NF under test rejects the consumer NF's service request and sends back an error message.

Expected format of evidence:

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