TR 33.926 [6], clause H.2.2.1, No Authorization of NF discovery based on Authorization Parameters

NF discovery authorization for specific scopes

TS 33.501 [3], clause 13.3.1.3, TS 23.502 [4], clause 4.17.4, and TS 29.510 [5], clause 6.2.3.2.3.1.

NRF is expected to be able to ensure that NF Discovery and registration requests are authorized as specified in TS 33.501 [3], clause 5.9.2.1.

The NRF checks that the values of the authorization parameters in the NF (Service) Profile of an NF Service Producer allows an NF Service Consumer to discover the NF Service Producer. In the response message, the NRF only returns information of those NF Service Producer instances that the NF Service Consumer is authorized to discover, as specified in the TS 33.501 [3], clause 13.3.1.3.

The NRF authorizes the Nnrf_NFDiscovery_Request. Based on the profile of the expected NF/NF service and the type of the NF service consumer, the NRF determines whether the NF service consumer is allowed to discover the expected NF instance(s). If the expected NF instance(s) or NF service instance(s) are deployed in a certain network slice, NRF authorizes the discovery request according to the discovery configuration of the Network Slice, e.g. the expected NF instance(s) are only discoverable by the NF in the same network slice as specified in TS 23.502 [4], clause 4.17.4.

Based on operator's policies, a discovery request not including the requester's information necessary to validate the authorization parameters in NF Profiles can be rejected or accepted but with only returning in the discovery response NF Instances whose authorization parameters allow any NF Service Consumer to access their services. The authorization parameters in NF Profile are those used by NRF to determine whether a given NF Instance / NF Service Instance can be discovered by an NF Service Consumer in order to consume its offered services (e.g. "allowedNfTypes", "allowedNfDomains", etc.), as specified in TS 29.510 [5], clause 6.2.3.2.3.1, Note 12.

If included, the requester-snssais IE is expected to contain the list of S-NSSAI of the requester NF. The NRF is expected to use this to return only those NF profiles of NF Instances allowing to be discovered from the slice(s) identified by this IE, according to the "allowedNssais" list in the NF Profile and NF Service as specified in TS 29.510 [5], clause 6.2.3.2.3.1.

Ensure that the NRF being tested does not authorize a discovery request from an NF service consumer instance that lacks the correct authorization provided in the request, based on the parameters prefixed with "allowed" (e.g., allowedNfTypes, allowedNfDomains, allowedNssais...) provided by the NF service producer profile.

• Test environment with the NF1 and NF2, which may be simulated. The NF2 will attempt to discover NF1.

• The NRF documentation provides information on whether unauthorized requests are rejected or accepted, but only returns NF Instances in the discovery response whose service the NF service consumer is authorized to access. If this is configurable, the tester is required to test both options.

• If the NRF under test does not support parameters from the allowedList in the table below, the test steps regarding these parameters are not applicable.

For all Test Case specific parameters defined in the table 4.2.2.2.1-1, the tester shall repeat the following execution steps.

Table 4.2.2.2.1-1 Test Case Specific Parameter Sets

----------------------------------------------------------------------------------------------------------------------------- Test Case parameter NF1 parameter NF2 allowedList (NF1) requester-type (NF2) ----------- -------------------------- -------------------------- --------------------- ------------------------------------- A NfType NF1 NfType NF2 allowedNfTypes requester-nf-type

B PLMN NF1 PLMN NF2 allowedPlmns requester-plmn-list

C FQDN NF1 FQDN NF2 allowedNfDomains requester-nf-instance-fqdn

D SNPN NF1 SNPN NF2 allowedSnpns requester-snpn-list

E S-NSSAI NF1 S-NSSAI NF2 allowedNssais requester-snssais

F S-NSSAI NF1 and PLMN NF1 S-NSSAI NF2 and PLMN NF2 allowedPlmns requester-plmn-specific-snssai-list -----------------------------------------------------------------------------------------------------------------------------

1. The tester configures NF1 with parameter NF1 and NF2 with parameter NF2, where the two parameter values are different. The tester should select the mandatory and optional profile parameters for NF1 and NF2 such that they do not conflict with other authorization test cases in this section.

2. The tester configures NF1 to ensure that it is not accessible by NF2 by disallowing parameter NF2 via the allowedList parameter in the profile NF1.

3. The tester triggers NF1 to register as a new NF instance via the NFManagement API at the NRF under test.

4. The tester triggers NF2 to send an Nnrf_NFDiscovery_Request message to the NRF under test with target-nf-type set to NfType NF1 and requester-type parameter set to the corresponding parameter NF2.

If the NRF under test is configured to reject unauthorized requests, the NRF responds with a "403 Forbidden" status code, as specified in clause 5.3.2.2.2 of TS 29.510 [5].

If the NRF under test is configured to accept unauthorised requests, but only returns NF instances whose authorisation is accepted in the discovery response, the discovery response will not contain any information about the NF1.

Evidence suitable for the interface, e.g., evidence can be presented in the form of packet trace (pcap-file).

NRF is expected to be able to ensure that NF Discovery and registration requests are authorized as specified in TS 33.501 [3], clause 5.9.2.1.

The NRF authorizes the Nnrf_NFDiscovery_Request. Based on the profile of the expected NF/NF service and the type of the NF service consumer, the NRF determines whether the NF service consumer is allowed to discover the expected NF instance(s). If the expected NF instance(s) or NF service instance(s) are deployed in a certain network slice, NRF authorizes the discovery request according to the discovery configuration of the Network Slice, e.g. the expected NF instance(s) are only discoverable by the NF in the same network slice as specified in TS 23.502 [4], clause 4.17.4.

If included, the requester-snssais IE is expected to contain the list of S-NSSAI of the requester NF. The NRF is expected to use this to return only those NF profiles of NF Instances allowing to be discovered from the slice(s) identified by this IE, according to the "allowedNssais" list in the NF Profile and NF Service as specified in TS 29.510 [5], clause 6.2.3.2.3.1.

• Test environment with the NF1 and NF2, which may be simulated.

• The NF2 is configured with a list of S-NSSAI, which contains slice A but not slice B.

• The NF1 is configured as a NF instance belonging to slice B and is connected in emulated/real network environment.

• The NF1 and NF2 is successfully authenticated with the NRF under test.

1. The NF2 registers at the NRF under test with a list of S-NSSAI.

2. The NF1 sends an Nnrf_NFDiscovery_Request to the NRF under test with the expected service name of NF2, NF type of the expected NF2.

3. The NRF under test determines that NF2 instance only allows discovery from NFs belonging to slice A, according to the "allowedNssais" list stored in NF2 Profile.

TR 33.926 [4], clause 6.3.4.1, Incorrect validation of client credentials assertion

NOTE 1: The following test case only applies if the NF under test implements verification of client credentials assertions.

NOTE 2: This test case is an extension to TC_CLIENT_CREDENTIALS_ASSERTION_VALIDATION in TS 33.117 [2] and only includes the NRF-specific test for the validity of the iat value.

If the verification of the CCA fails at the receiving entity (e.g. NRF or NF service producer), a "403 Forbidden" response is returned with the cause attribute set to "CCA_VERIFICATION_FAILURE", as stated in TS 29.500 [21], clause 6.7.5.

Correct handling of client credentials assertion validation failure

TS 33.501 [10], clause 13.3.8.3: TS 29.500 [21], clause 6.7.5

The verification of the Client credentials assertion is 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 [16].

• It validates the timestamp (iat) and/or the expiration time (exp) as specified in RFC 7519 [17].

• If the receiving node is the NRF, 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 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.

Verify that the NF under test correctly handles client credentials assertion validation failure. This test case specifically verifies that the NRF under test verifies that the iat value is valid.

• 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 NRF under test is preconfigured with the certificate of the consumer NF.

• The NRF under test is configured to require assertions for NF consumer authentication for at least one of its services.

• The NRF under test has implemented the client credentials assertion (CCA) authentication method as specified in TS 33.501 [10], clause 13.3.8.3.

• The tester has the private key of the consumer NF.

• The tester has access to the interface between the consumer NF and the NRF under test.

1. The tester computes a client credentials assertion correctly, except that the timestamp (iat) value is in the future. The tester should make sure that the expiration time is greater than the timestamp (iat) value.

2. The tester includes the client credentials assertion in the service request sent from the consumer NF to the NRF under test via the SCP.

3. The tester captures the response sent back by the NRF under test.

The NRF under test rejects the consumer NF's service request with a 403 Forbidden HTTP status code and sends back an error message according to the description TS 29.500 [21], clause 6.7.5.

Evidence suitable for the interface, e.g., evidence can be presented in the form of log messages or a packet trace. A packet trace should at least contain the messages sent between the NRF and the NF service consumer.

TR 33.926 [6], clause H.2.2.Y, Elevation of privilege via failure to verify access token request

Access token request verification

TS 33.501 [3], clause 13.4.1.1.2

According to TS 33.501 [3], clause 13.4.1.1.2, the NRF verifies the input parameters in the access token request as follows:

• It checks that the NF Instance ID and, if available, NF type and PLMN ID(s), in the access token request match the corresponding ones in the public key certificate of the NF service consumer or those in the NF profile of the NF service consumer. If the verification of the access token request fails at the NRF, the NRF shall return "400 Bad Request" status code, and "error" attribute set to "invalid_client", as stated in TS 29.510 [5], clause 5.4.2.2, and the access token request is not further processed.

• Based on the input attributes (e.g., NF Type, PLMN ID(s), scope), it checks that the NF service consumer is authorized to access the requested services from the NF service producer. When certain parameters in the access token request are not supported by the NRF, the NRF shall ignore the unsupported parameters and continue processing the request with the rest of the parameters.

• If available, it verifies the S-NSSAIs of the NF service consumer and checks whether there are restrictions on the NF service consumer to access NF Service Producers' services of a specific NF type depending on the slices for which they offer their services.

If the access token request fails, the NRF shall return an appropriate error status code (e.g., "400 Bad Request", "401 Unauthorized", "403 Forbidden")

Verify that the NRF under test correctly handles access token request verification.

• The NRF under test is preconfigured with either the public key certificate or NF profile of the NF service consumer.

• The NRF under test is preconfigured with notional access token request authorization policies for an NF service consumer and the tester is provided documentation necessary to generate authorized access token requests.

• Test environment includes an NF service consumer.

• The NF service consumer may be simulated.

Test Cases A~B are tests on failure handling by the NRF under test when the access token request failed verification

Test Case A: invalid client

1. The tester constructs an access token request correctly, except that the NF instance ID is different from the NF instance ID of the NF service consumer public key certificate. The NF service consumer sends the access token request to the NRF under test.

2. The NRF under test recognizes the NF instance ID does not match the NF instance ID of the NF service consumer public key certificate.

3. The access token request verification fails, and the NRF sends an appropriate response, as specified in TS 29.510 [5] clause 5.4.2.2 (e.g., 400 bad request, 403 forbidden, or 3XX for redirection).

Test Case B: unauthorized request

1. The tester constructs an access token request correctly, except that the input attributes (e.g., NF Type, PLMN ID(s), scope) are not authorized based on preconfigured authorization policies. The NF service consumer sends the access token request to the NRF under test.

2. The NRF under test recognizes that at least one of the input attributes implies the NF service consumer is not authorized for the requested services

3. The access token request verification fails, and the NRF sends an appropriate response, as specified in TS 29.510 [5] clause 5.4.2.2 (e.g., 400 bad request, 403 forbidden, or 3XX for redirection).

For test cases A~B on verification failure of the access token request parameters, the NRF under test rejects the NF service consumer's service request.

Evidence suitable for the interface, e.g., evidence can be presented in the form of log messages or a packet trace. A packet trace should at least contain the messages sent between the NRF and the NF service consumer.