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.4  Authorization of NF service access

13.4.1  OAuth 2.0 based authorization of Network Function service access

13.4.1.0  General

The authorization framework described in clause 13.4.1 allows NF service producers to authorize the requests from NF service requestors.
The authorization framework uses the OAuth 2.0 framework as specified in RFC 6749 [43]. Grants shall be of the type Client Credentials Grant, as described in clause 4.4 of RFC 6749 [43]. Access tokens shall be JSON Web Tokens as described in RFC 7519 [44] and are secured with digital signatures or Message Authentication Codes (MAC) based on JSON Web Signature (JWS) as described in RFC 7515 [45].
The basic extent provided by the authorization token is at service level (i.e. the "scope" claim includes allowed services per NF type). Depending on the NF service producer configuration, higher level of granularity for the authorization token can be defined adding "additional scope" information within the token e.g. to authorize specific service operations and/or resources/data sets within service operations per NF consumer type.
The authorization framework described in clause 13.4.1 is mandatory to support for NRF and NF.
Up

13.4.1.1  Service access authorization within the PLMN

OAuth 2.0 roles, as defined in clause 1.1 of RFC 6749 [43], are as follows:
  1. The Network Resource Function (NRF) shall be the OAuth 2.0 Authorization server.
  2. The NF service consumer shall be the OAuth 2.0 client.
  3. The NF service producer shall be the OAuth 2.0 resource server.
OAuth 2.0 client (NF service consumer) registration with the OAuth 2.0 authorization server (NRF)
The NF service registration procedure, as defined in clause 4.17.1 of TS 23.502, shall be used to register the OAuth 2.0 client (NF service consumer) with the OAuth 2.0 Authorization server (NRF), as described in clause 2.0 of RFC 6749 [43]. The client id, used during OAuth 2.0 registration, shall be the NF Instance Id of the NF.
OAuth 2.0 resource server (NF service producer) registration with the OAuth 2.0 authorization server (NRF)
The NF service registration procedure, as defined in clause 4.17.1 of TS 23.502, shall be used to register the OAuth 2.0 resource server (NF service producer) with the OAuth 2.0 Authorization server (NRF). The NF service producer, as part of its NF profile, may include "additional scope" information related to the allowed service operations and resources per NF consumer type.
[not reproduced yet]
Figure 13.4.1.1-1b: NF service producer registers in NRF
Up
Step 1.
The NF service producer registers as OAuth 2.0 resource server in the NRF. The NF profile configuration data of the NF service producer may include the "additional scope". The "additional scope" information indicates the resources and the actions (service operations) that are allowed on these resources for the NF service consumer. These resources may be per NF type of the consumer or per NF instance ID of the consumer.
Step 2-3.
After storing the NF Profile, NRF responds successfully.
Access token request before service access
The following procedure describes how the NF service consumer obtains an access token before service access to NF service producers of a specific NF type.
Pre-requisite:
  1. The NF Service consumer (OAuth2.0 client) is registered with the NRF (Authorization Server).
  2. The NF Service producer (OAuth2.0 resource server) is registered with the NRF (Authorization Server) with "additional scope" information per NF type.
  3. The NRF and NF service producer share the required credentials.
  4. The NRF and NF have mutually authenticated each other.
[not reproduced yet]
Figure 13.4.1.1-1: NF service consumer obtaining access token before NF service access
Up
Step 1.
The NF service consumer shall request an access token from the NRF in the same PLMN using the Nnrf_AccessToken_Get request operation. The message shall include the NF Instance Id(s) of the NF service consumer, the requested "scope" including the expected NF service name(s) and optionally "additional scope" information (i.e. requested resources and requested actions (service operations) on the resources), NF type of the expected NF producer instance and NF consumer. The service consumer may also include a list of NSSAIs or list of NSI IDs for the expected NF producer instances.
The message may include the NF Set ID of the expected NF service producer instances.
Step 2.
The NRF may optionally authorize the NF service consumer. It shall then generate an access token with appropriate claims included. The NRF shall digitally sign the generated access token based on a shared secret or private key as described in RFC 7515 [45].
The claims in the token shall include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s), scope (scope), expiration time (expiration) and optionally "additional scope" information (allowed resources and allowed actions (service operations) on the resources). The claims may include a list of NSSAIs or NSI IDs for the expected NF producer instances. The claims may include the NF Set ID of the expected NF service producer instances.
Step 3.
If the authorization is successful, the NRF shall send access token to the NF service consumer in the Nnrf_AccessToken_Get response operation,otherwise it shall reply based on Oauth 2.0 error response defined in RFC 6749 [43]. The other parameters (e.g., the expiration time , allowed scope ) sent by NRF in addition to the access token are described in TS 29.510.
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.
Access token request for a specific NF Producer/NF Producer service instance
The NF service consumer shall request an access token from the NRF for a specific NF Producer instance/NF Producer service instance. The request shall include the NF Instance Id(s) of the requested NF Producer, the expected NF service name, optionally "additional scope" information (allowed resources and allowed actions (service operations) on the resources) and NF Instance Id of the NF service consumer.
The NRF may optionally authorize the NF service consumer to use the requested NF Producer instance/NF Producer service instance, and then proceeds to generate an access token with the appropriate claims included.
The claims in the token shall include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF Instance Id or several NF Instance Id(s) of the requested NF Service Producer (audience), expected service name(s) (scope) , optionally "additional scope" information (allowed resources and allowed actions (service operations) on the resources), and expiration time (expiration). The token shall be included in the Nnrf_AccessToken_Get response sent to the NF service consumer.
Service access request based on token verification
The following figure and procedure describes how authorization is performed during Service request of the NF service consumer. Prior to the request, the NF service consumer may perform Nnrf_NFDiscovery_Request operation with the requested additional scopes to select a suitable NF service producer (resource server) which is able to authorize the Service Access request.
[not reproduced yet]
Figure 13.4.1.1-2: NF service consumer requesting service access with an access token
Up
Pre-requisite: The NF service consumer is in possession of a valid access token before requesting service access from the NF Service producer.
Step 1.
The NF Service consumer requests service from the NF service producer. The NF Service Consumer shall include the access token.
The NF Service consumer and NF service producer shall authenticate each other following clause 13.3.
2. The NF Service producer shall verify the token as follows:
  • The NF Service producer ensures the integrity of the 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 token as follows:
  • 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 scope is present, it checks that the scope matches the requested service operation.
  • 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.
  • It checks that the access token has not expired by verifying the expiration time in the access token against the current data/time.
3. 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 [43]. 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.
Up

13.4.1.2  Service access authorization in roaming scenariosWord‑p. 174
In the roaming scenario, OAuth 2.0 roles are as follows:
a. The visiting Network Resource Function (vNRF) shall be the OAuth 2.0 Authorization server for vPLMN and authenticates the NF service consumer.
b. The home Network Resource Function (hNRF) shall be OAuth 2.0 Authorization server for hPLMN and generates the access token.
c. The NF service consumer in the visiting PLMN shall be the OAuth 2.0 client.
d. The NF service producer in the home PLMN shall be the OAuth 2.0 resource server.
OAuth 2.0 client (NF service consumer) registration with the OAuth 2.0 authorization server (NRF) in the vPLMN
Same as in the non-roaming scenario in 13.4.1.1.
OAuth 2.0 resource server (NF service producer) registration with the OAuth 2.0 authorization server (NRF) in the hPLMN
Same as in the non-roaming scenario in 13.4.1.1.
Obtaining access token independently before NF service access
The following procedure describes how the NF service consumer obtains an access token for NF service producers of a specific NF type for use in the roaming scenario.
[not reproduced yet]
Figure 13.4.1.2-1: NF service consumer obtaining access token before NF service access (roaming)
Up
Pre-requisite:
a. The NF Service consumer (OAuth2.0 client) is registered with the vNRF (Authorization Server in the vPLMN).
b. The hNRF and NF service producer share the required credentials. Additionally, the NF Service producer (OAuth2.0 resource server) is registered with the hNRF (Authorization Server in the hPLMN) with "additional scope" information per NF type.
c. The two NRFs have mutually authenticated each other.
d. The NRF in the serving PLMN and NF service consumer have mutually authenticated each other.
1. The NF service consumer shall invoke Nnrf_AccessToken_Get Request (NF Instance Id of the NF service consumer,the requested "scope" including the expected NF service Name (s) and optionally "additional scope" information (i.e. requested resources and requested actions (service operations) on the resources), NF Type of the expected NF Producer instance, NF type of the NF consumer, home and serving PLMN IDs, optionally list of NSSAIs or list of NSI IDs for the expected NF producer instances, optionally NF Set ID of the expected NF service producer) from NRF in the same PLMN.
2. The NRF in serving PLMN shall identify the NRF in home PLMN (hNRF) based on the home PLMN ID, and request an access token from hNRF as described in clause 4.17.5 of TS 23.502. The vNRF shall forward the parameters it obtained from the NF service consumer, including NF service consumer type, to the hNRF.
3. The hNRF may optionally authorize the NF service consumer and shall generate an access token with appropriate claims included as defined in clause 13.4.1.1. The hNRF shall digitally sign the generated access token based on a shared secret or private key as described in RFC 7515 [45].
The claims in the token shall include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer appended with its PLMN ID (subject), NF type of the NF Service Producer appended with its PLMN ID (audience), expected services name(s),scope (scope) and expiration time (expiration), and optionally "additional scope" information (allowed resources and allowed actions (service operations) on the resources). The claims may include a list of NSSAIs or NSI IDs for the expected NF producer instances The claims may include the NF Set ID of the expected NF service producer instances.
4. If the authorization is successful, the access token shall be included in Nnrf_AccessToken_Get Response message to the vNRF. Otherwise it shall reply based on Oauth 2.0 error response defined in RFC 6749 [43]. 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. The other parameters (e.g., the expiration time, allowed scope) sent by NRF in addition to the access token are described in TS 29.510.
5. The vNRF shall forward the Nnrf_AccessToken_Get Response or error message to the NF service consumer.
Obtain access token for a specific NF Producer/NF Producer service instance
The NF service consumer shall request an access token from the NRF for a specific NF Producer instance/NF Producer service instance. The request shall include the NF Instance Id of the requested NF Producer, appended with its PLMN ID the expected NF service name and NF Instance Id of the NF service consumer, appended with its PLMN ID.
The NRF in the visiting PLMN shall forward the request to the NRF in the home PLMN.
The NRF may optionally authorize the NF service consumer to use the requested NF Producer instance/NF Producer service instance and shall then proceed to generate an access token with the appropriate claims included.
The claims in the token shall include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer appended with its PLMN ID (subject), NF Instance Id of the requested NF Service Producer appended with its PLMN ID (audience), expected service name(s) (scope) and expiration time (expiration). The token shall be included in the Nnrf_AccessToken_Get response sent to the NRF in the visiting PLMN. The NRF in the visiting PLMN shall forward the Nnrf_AccessToken_Get response message to the NF service consumer. 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.
Service access request based on token verification
In addition to the steps described in the non-roaming scenario in 13.4.1.1, the NF service producer shall verify that the PLMN-ID contained in the API request is equal to the one inside the access token.
[not reproduced yet]
Figure 13.4.1.2-2: NF service consumer requesting service access with an access token in roaming case
Up
The NF service producer shall check that the home PLMN ID of audience claim in the access token matches its own PLMN identity.
The pSEPP shall check that the serving PLMN ID of subject claim in the access token matches the remote PLMN ID corresponding to the N32-f context Id in the N32 message.

13.4.1.3  Service access authorization in indirect communication scenarios |R16|Word‑p. 177
13.4.1.3.1  Authorization for indirect communication without delegated discovery procedure
13.4.1.3.1.1  With mutual authentication between NF Service Consumer and NRF at the transport layer
This clause covers the scenario where the NF Service Consumer and the NRF are connected over a mutually authenticated TLS connection.
[not reproduced yet]
Figure 13.4.1.3.1.1-1: Authorization and service invocation procedure, for indirect communication without delegated discovery, with mutual authentication between NF and NRF at the transport layer
Up
Discovery of the NF Service Producer:
0. Optionally, the NF Service Consumer may discover the NF Service Producer before requesting authorization to invoke the services of the NF Service Producer.
NF Service Consumer authorization:
1-2.
After mutual authentication between NF Service Consumer and NRF at the transport layer, the NF Service Consumer and NRF perform the "Access token request before service access" procedure as described in clause 13.4.1.1. If the NF Service Consumer has already discovered the NF Service Producer, it can also perform the "Access token request for a specific NF Service Producer/NF Service Producer instance" procedure as described in clause 13.4.1.1.
Service request:
The NF Service Consumer, SCP, NRF and NF Service Producer perform the procedure "Indirect Communication without delegated discovery Procedure" described in clause 4.17.11 of TS 23.502. The following steps describe how the access token received from steps 1 and 2 is used in this procedure.
3. If no cached data is available, the NF Service Consumer discovers the NF Service Producer via the SCP.
4. The NF Service Consumer sends a service request for the specific service to the SCP. The service request includes the access token as received in step 2, and may include the NF Service Consumer client credentials assertion as defined in clause 13.3.8.
5. The SCP selects a NF Service Producer instance, performs the API root modifications and forwards the received request to the selected NF Service Producer instance. The request contains the access token and may contain the NF Service Consumer client credentials assertion if received in step 4.
6. To authorize the access, the NF Service Producer authenticates the service consumer NF using one of the methods described in clause 13.3.2.2 and if successful, it validates the access token as described in clause 13.4.1.1 by verifying the signature and checking if the requested service is part of the token's scope.
7. If the checks in step 6 are successful, the NF Service Producer processes the service request and provides a service response.
8. The SCP performs reverse API root modifications and forwards the service response.
Up
13.4.1.3.1.2  Without mutual authentication between NF and NRF at the transport layerWord‑p. 178
When there is no mutual authentication between NF Service Consumer and NRF at the transport layer, the NF Service Consumer performs the following procedure to obtain the access token from NRF and uses it for service access at the NF Service Producer. In this clause, the authentication of NF service consumer by the NRF and by the NF service producer is based on any of the methods described in clauses 13.3.1.2 and 13.3.2.2.
[not reproduced yet]
Figure 13.4.1.3.1.2-1: Authorization and service invocation procedure, for indirect communication without delegated discovery, without mutual authentication between NF and NRF at the transport layer
Up
0. Optionally, the NF Service Consumer may discover the NF Service Producer before requesting authorization to invoke the services of the NF Service Producer.
1. The NF Service Consumer sends an access token request (Nnrf_AccessToken_Get Request) to the SCP with parameters as specified in 13.4.1.1. The access token request may additionally include the NF Service Consumer client credentials assertion as defined in clause 13.3.8.
2. The SCP forwards the access token request (Nnrf_AccessToken_Get Request) to the NRF. The request may include the NF Service Consumer client credentials assertion if received in step 1.
3. The NRF authenticates the service consumer NF using one of the methods described in clause 13.3.1.2. If the NF Service Consumer authentication is successful and the NF Service Consumer is authorized based on the NRF policy, the NRF issues an access token as described in clause 13.4.1.1. The NRF uses the NF Service Consumer NF Instance ID as the subject of the access token.
4. The NRF sends the access token to the SCP in an access token response (Nnrf_AccessToken_Get Response).
5. The SCP forwards the access token response (Nnrf_AccessToken_Get Response) to the NF Service Consumer, including the access token.
6. The NF Service Consumer sends the service request to the SCP. The service request includes the access token received in Step 5 and may include the NF Service Consumer client credentials assertion,
7. The SCP forwards the service request to the NF Service Producer. The service request includes the access token received in step 6, and may include the NF Service Consumer client credentials assertion if received in step 6.
8. The NF Service Producer authenticates the NF service consumer by one of the methods described in clause 13.3.2.2 and if successful, it validates the access token as described in clause 13.4.1.1.
9. If the validation of the access token is successful, the NF Service Producer sends the service response to the SCP.
10. The SCP forwards the service response to the NF Service Consumer.
Up
13.4.1.3.2  Authorization for indirect communication with delegated discovery procedureWord‑p. 179
This clause covers the scenario where the NF Service Consumer use the SCP to discover and select the NF Service Producer instance that can process the service request.
[not reproduced yet]
Figure 13.4.1.3.2-1: Authorization and service invocation procedure, for indirect communication with delegated discovery
Up
1. The NF Service Consumer sends a service request to the SCP. The service request may include the NF Service Consumer client credentials assertion as defined in clause 13.3.8.
2. The SCP may perform a service discovery with the NRF.
3. The SCP sends an access token request (Nnrf_AccessToken_Get Request) to the NRF. The access token request includes parameters as defined in clause 13.4.1.1. The access token request may include the NF Service Consumer client credentials assertion if received in Step 1.
4. The NRF authenticates the NF service consumer using one of the methods described in clause 13.3.1.2. If cNF authentication is successful and the NF Service Consumer is authorized based on the NRF policy, the NRF issues an access token as described in clause 13.4.1.1. The NRF uses the NF Service Consumer instance ID as the subject of the access token.
5. The NRF sends the access token to the SCP in an access token response (Nnrf_AccessToken_Get Response).
6. The SCP sends the service request to the NF Service Producer. The service request includes the access token received in Step 5, and may include the NF Service Consumer client credentials assertion if received in Step 1.
7. The NF Service Producer authenticates the NF service consumer by one of the methods described in clause 13.3.2.2 and if successful, it validates the access token as described in clause 13.4.1.1.
8. If the validation of the access token is successful, the NF Service Producer sends the service response to the SCP.
9. The SCP forwards the service response to the NF Service Consumer.
Up

13.5  Security capability negotiation between SEPPsWord‑p. 180
The security capability negotiation allows the SEPPs to negotiate which security mechanism to use for protecting NF service related signalling over N32. There shall be an agreed security mechanism between a pair of SEPPs before conveying NF service related signalling over N32.
When a SEPP notices that it does not have an agreed security mechanism for N32 protection with a peer SEPP or if the security capabilities of the SEPP have been updated, the SEPP shall perform security capability negotiation with the peer SEPP in order to determine, which security mechanism to use for protecting NF service related signalling over N32. Certificate based authentication shall follow the profiles given in TS 33.210, clause 6.2.
A mutually authenticated TLS connection as defined in clause 13.1 shall be used for protecting security capability negotiation over N32. The TLS connection shall provide integrity, confidentiality and replay protection.
[not reproduced yet]
Figure 13.5-1: Security capability negotiation
Up
Step 1.
The SEPP which initiated the TLS connection shall send a Registration Request message to the responding SEPP including the initiating SEPP's supported security mechanisms for protecting the NF service related signalling over N32 (see table Table 13.5-1). The security mechanisms shall be ordered in the initiating SEPP's priority order.
Step 2.
The responding SEPP shall compare the received security capabilities to its own supported security capabilities and selects, based on its local policy (e.g. based on whether there are IPX providers on the path between the SEPPs), a security mechanism, which is supported by both initiating SEPP and responding SEPP.
Step 3.
The responding SEPP shall send a Registration Response message to initiating SEPP including selected security mechanism for protecting the NF service related signalling over N32.
Editor's Note: The exact message names are FFS.
N32 protection mechanism
Description

Mechanism 1
PRINS (described in clause 13.2)
Mechanism 2
TLS
Mechanism n
Reserved

If the selected security mechanism is PRINS the SEPPs shall behave as specified in clause 13.2.
If the selected security mechanism is TLS the SEPPs shall forward the NF service related signalling over N32 using the existing TLS connection as specified in clause 13.1.
If the selected security mechanism is a mechanism other than the ones specified in Table 13.5-1, the two SEPPs shall terminate the TLS connection.
Up


Up   Top   ToC