Content for  TS 33.501  Word version:  19.0.0

NRF and NF shall authenticate each other during discovery, registration, and access token request. In direct communication, NF and NRF shall use one of the following methods for authentication:

• 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 mutual authentication of the NRF and NF.
• If the PLMN does not use protection at the transport layer, mutual authentication of NRF and NF may be implicit by NDS/IP or physical security (see clause 13.1).

In indirect communication, NF and NRF shall use one of the following methods for authentication:

• Mutual authentication between NF and NRF provided by the transport layer protection solution.
• Client credentials assertion (CCA) based authentication as specified in clause 13.3.8.
• Implicit, i.e. by relying on authentication between NF Service Consumer and SCP, and between SCP and NRF, provided by the hop-by-hop security protection at the transport layer, NDS/IP, or physical security.

When NRF receives message from unauthenticated NF, NRF shall support error handling, and may send back an error message. The same procedure shall be applied vice versa. After successful authentication between NRF and NF, the NRF shall decide whether the NF is authorized to perform discovery and registration. The NRF shall check 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 shall only return information of those NF Service Producer instances that the NF Service Consumer is authorized to discover. In the non-roaming scenario, 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, as described in clause 4.17.4 of TS 23.502. In the roaming scenario, the NRF of the NF Service Producer shall authorize the Nnrf_NFDiscovery_Request based on the profile of the expected NF/NF Service, the type of the NF Service Consumer and the serving network ID. If the NRF finds NF Service Consumer is not allowed to discover the expected NF instances(s) as described in clause 4.17.4 of TS 23.502, NRF shall support error handling, and may send back an error message. When a NF consumes the Nnrf_NFManagement or the Nnrf_NFDiscovery services provided by the NRF, the usage of the OAuth 2.0 access token for authorization between the NF and the NRF is optional.

In direct communication, 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.
• If the PLMN does not use protection at the transport layer, authentication between NFs within one PLMN may be implicit by NDS/IP or physical security (see clause 13.1).

If the PLMN uses token-based authorization, the network shall use protection at the transport layer as described in clause 13.1.

In indirect communication scenarios, the NF Service Producer and NF Service Consumer shall use implicit authentication by relying on authentication between NF Service Consumer and SCP, and between SCP and NF Service Producer, provided by the transport layer protection solution, NDS/IP, or physical security. If the PLMN uses token-based authorization as specified by clause 13.4.1.2 and the PLMN's policy mandates that the NRF authenticates the NF Service Consumer before granting an access token, the access token indicates to the NF Service Producer that the NF Service Consumer has been authenticated by the NRF. If additional authentication of the NF Service Consumer is required, the NF Service Producer authenticates the NF Service Consumer at the application layer using CCA based authentication as specified in clause 13.3.8. The NF Service Consumer authentication based on CCA based authentication is optional to use, and based on operator policy.

The Inter-PLMN UP Security functionality (IPUPS) as described in clauses 4.2.2 and 5.9.3.4 provide a standardised solution for binding 5G SBA REST Service Operations between the PLMN V-SMF and H-SMF over N16 / N32 to GTP-U over N9 in roaming scenarios.

When an NF receives a message from an unauthenticated NF, the receiving NF shall support error handling, and may send back an error message.

The Client credentials assertion (CCA) is a token signed by the NF Service Consumer. It enables the NF Service Consumer to authenticate towards the receiving end point (NRF, NF Service Producer) by including the signed token in a service request. It includes the NF Service Consumer's NF Instance ID that can be checked against the certificate by the NF Service Producer. The CCA includes a timestamp as basis for restriction of its lifetime. CCAs are expected to be more short-lived than NRF generated access tokens. So, they can be used in deployments with requirements for tokens with shorter lifetime for NF-NF communication. There is a trade-off that when the lifetime of the CCA is too short, it requires the NF Service Consumer to generate a new CCA for every new service request. The CCA cannot be used in the roaming case, as the NF Service Producer in the home PLMN will not be able to verify the signature of the NF Service Consumer in the visited PLMN unless cross-certification process is established between the two PLMNs through one of the mechanisms specified in TS 33.310. CCA does not provide integrity protection on the full service request. Neither does it provide a mechanism for the NF Service Consumer to authenticate the NF Service Producer. In this clause, CCAs are described generally for both NF-NRF communication and NF-NF communication.

CCAs shall be JSON Web Tokens as described in RFC 7519 and are secured with digital signatures based on JSON Web Signature (JWS) as described in RFC 7515. The CCA shall include:

• the NF instance ID of the NF Service Consumer (subject);
• A timestamp (iat) and an expiration time (exp), and
• The NF type of the expected audience (audience), i.e. the type "NRF" and/or the NF type of the NF Service Producer.

The NF Service Consumer shall digitally sign the generated CCA based on its private key as described in RFC 7515. The signed CCA shall include one of the following fields:

• the X.509 URL (x5u) to refer to a resource for the X.509 public key certificate or certificate chain used for signing the client authentication assertion, or
• the X.509 Certificate Chain (x5c) include the X.509 public key certificate or certificate chain used for signing the client authentication assertion.

The verification of the CCA 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.
• It validates the timestamp (iat) and/or the expiration time (exp) as specified in RFC 7519.
  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 the CCA matches its own type.
• It verifies that the NF instance ID of the NFc in the CCA matches the NF instance ID in the public key certificate used for signing the CCA.