Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.2…   6.3…   6.5…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7B…   8…   9…   10…   11…   13…   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   K…   O…

 

13.3  Authentication and static authorization

13.3.1  Authentication and authorization between network functions and NRF

13.3.1.1  Direct communication |R16|

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

13.3.1.2  Indirect communication |R16|

In indirect communication, NF and the 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 and authentication as specified in clause 13.3.8.
  • Implicit, 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.
Up

13.3.1.3  Authorization of discovery request and error handling |R16|Word‑p. 167
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.
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 Provider 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.
Up

13.3.2  Authentication and authorization between network functions

13.3.2.1  Direct communication |R16|

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

13.3.2.2  Indirect communication |R16|

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 Producer at the application layer using Client credentials assertion and authentication as specified in clause 13.3.8.
The NF service consumer authentication based on Client credentials assertion and authentication is optional to use, and based on operator policy.
Up

13.3.2.3  Inter-PLMN NF to NF communication |R16|

The present document does not 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. To prevent injection or spoofing of UP traffic over N9, it is recommended to use a common firewall that can correlate HTTP/2 methods and GTP-U in order to bind and filter out any malicious traffic on N9. Use of a common firewall may place other implementation restrictions (e.g. co-location of SMF, SEPP and UPF) in order to allow use of a common firewall.
Up

13.3.2.4  Error handling |R16|Word‑p. 168
When an NF receives message from other unauthenticated NF, the NF shall support error handling, and may send back an error message.

13.3.3  Authentication and authorization between SEPP and network functions

Authentication between SEPP and network functions within one PLMN shall use one of the following methods:
  • If the PLMN uses protection at the transport layer, authentication provided by the transport layer protection solution shall be used for authentication between SEPP and NFs.
  • If the PLMN does not use protection at the transport layer, authentication between SEPP and NFs within one PLMN may be implicit by NDS/IP or physical security (see clause 13.1).
A network function and the SEPP shall mutually authenticate before the SEPP forwards messages sent by the network function to network functions in other PLMN, and before the SEPP forwards messages sent by other network functions in other PLMN to the network function.
Up

13.3.4  Authentication and authorization between SEPPs

Authentication and authorization between SEPPs in different PLMN is defined in clause 13.2.

13.3.6  Authentication and authorization between SCP and network functions |R16|

The SCP and network functions shall use one of the following methods described in clause 13.1 to mutually authenticate each other before service layer messages can be exchanged on that interface:
  • If the PLMN uses protection at the transport layer, authentication provided by the transport layer protection solution shall be used for mutual authentication of the SCP and the network functions.
  • If the PLMN does not use protection at the transport layer, mutual authentication of the SCP and network functions may be implicit by NDS/IP or physical security.
Authentication between the SCP and the Network Function may be implicit by co-location.
Editor's Note: Authoriziation between SCP and NFs is ffs.
Up

13.3.7  Authentication and authorization between SCPs |R16|Word‑p. 169
SCPs shall use one of the following methods as described in 13.1 to mutually authenticate each other before service layer messages can be exchanged on that interface:
  • If the PLMN uses protection at the transport layer, authentication provided by the transport layer protection solution shall be used for mutual authentication of the SCPs.
  • If the PLMN does not use protection at the transport layer, mutual authentication of the two SCPs may be implicit by NDS/IP or physical security.
Editor's Note: Authorization between SCPs is ffs.
Up

13.3.8  Client credentials assertion and authentication |R16|

13.3.8.1  General

Client credentials assertions are tokens 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 assertion includes a timestamp as basis for restriction of the lifetime of the assertion.
Client credentials assertions 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 assertion is too short, it requires the consumer to generate a new assertion for every new service request.
Client credentials assertion 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 Producer in the visited PLMN unless cross-certification process is established between the two PLMNs through one of the mechanisms specified in TS 33.310.
Client credentials assertion do 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, Client credentials assertions are described generally for both NF-NRF communication and NF-NF communication.
Up

13.3.8.2  Client credentials assertion

Client credentials assertions shall be JSON Web Tokens as described in RFC 7519 [44] and are secured with digital signatures based on JSON Web Signature (JWS) as described in RFC 7515 [45].
The Client credentials assertion 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", "NF service Producer", or "NRF" and "NF Service Producer".
The NF Service consumer shall digitally sign the generated Client credentials assertion based on its private key as described in RFC 7515 [45]. The signed Client credentials assertion 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.
Up

13.3.8.3  Verification of Client credentials assertionWord‑p. 170
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 [45].
  • If validates the timestamp (iat) and/or the expiration time (exp) as specified in RFC 7519 [44].
    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 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.
Up


Up   Top   ToC