Content for &nbsp; TS 33.501 &nbsp; Word version:&nbsp; 18.0.0

Figure 13.4.1.1.2-1: NF Service Consumer obtaining access token before NF Service access

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 NF Service Consumer or per NF instance ID of the NF Service Consumer.

Step 2-3.

After storing the NF Profile, NRF responds successfully.

13.4.1.1.2 Service Request Process p. 178

The complete service request is a two-step process including requesting an access token by NF Service Consumer (Step 1, i.e. 1a or 1b), and then verification of the access token by NF Service Producer (Step 2).

Step 1: Access token request

Pre-requisite:

The NF Service consumer (OAuth2.0 client) is registered with the NRF (Authorization Server).
The NF Service Producer (OAuth2.0 resource server) is registered with the NRF (Authorization Server) with optionally "additional scope" information per NF type.
The NRF and NF Service Producer share the required credentials.
The NRF and NF have mutually authenticated each other.

1a. Access token request for accessing services of NF Service Producers of a specific NF type

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.

Reproduction of 3GPP TS 33.501, Fig. 13.4.1.1.2-1: NF Service Consumer obtaining access token before NF Service access

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 Service Producer instance and NF Service Consumer. The NF Service Consumer may also include a list of NSSAIs or list of NSI IDs for the expected NF Service Producer instances.

The message may include the NF Set ID and/or NF Service Set Id of the expected NF Service Producer instances.

The message may include a list of S-NSSAIs of the NF Service Consumer.

The NRF may verify that the input parameters (e.g., NF type) in the access token request match with the corresponding ones in the public key certificate of the NF Service Consumer or those in the NF profile of the NF Service Consumer. The NRF may additionally verify the S-NSSAIs of the NF Service Consumer. The NRF checks whether the NF Service Consumer is authorized to access the requested service(s). For example, the NRF may verify that the NF Service Consumer can serve a slice which is included in the allowed slices for the NF Service Producer. If the NF Service Consumer is authorized, the NRF 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. If the NF Service Consumer is not authorized, the NRF shall not issue an access token to the NF Service Consumer.

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), 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 Service Producer instances. The claims may include the NF Set ID and/or NF Service Set Id of the expected NF Service Producer instances.

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. 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 NF Service Producer NF type listed in claims (scope, audience) during their validity time.

1b. Access token request for accessing services of a specific NF Service Producer instance / NF Service Producer service instance

The following steps describes how the NF Service Consumer obtains an access token before service access to a specific NF Service Producer instance / NF Service Producer service instance. 1. The NF Service Consumer shall request an access token from the NRF for a specific NF Service Producer instance / NF Service Producer service instance. The request shall include the NF Instance Id(s) of the requested NF Service 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 checks whether the NF Service Consumer is authorized to use the requested NF Service Producer instance/NF Service Producer service instance, and then proceeds to generate an access token with the appropriate claims included. If the NF Service Consumer is not authorized, the NRF shall not issue an access token to the NF Service Consumer.

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

Figure 13.4.1.1.2-2: NF Service Consumer requesting service access with an access token

The token shall be included in the Nnrf_AccessToken_Get response sent 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 NF Instance Id or several NF Instance Id(s) of the requested NF Service Producer instance listed in claims (scope, audience) during their validity time.

Step 2: Service access request based on token verification

The following Figure and procedure describe 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.

Reproduction of 3GPP TS 33.501, Fig. 13.4.1.1.2-2: NF Service Consumer requesting service access with an access token

Pre-requisite:

The NF Service Consumer is in possession of a valid access token before requesting service access from the NF Service Producer.

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.

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:

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 applicable (e.g., when the request is for information related to a specific UE), the NF Service Producer may check that the NF Service Consumer is allowed to access (as indicated by the NF Service Producer's NSSAIs in the access token presented by the NF Service Consumer) at least one of the slice(s) that the UE is currently registered to, e.g., by verifying that the UE's allowed NSSAI(s) intersect with the NF Service Producer's NSSAIs in the access token.
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 an NF Service Set ID present, the NF Service Producer shall check if the NF Service Consumer is authorized to access the requested service according to NF Service Producer Service Set ID in the access token claim.
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.
If the CCA is present in the service request, it may verify the CCA as specified in clause 13.3.8.3 and that the subject claim (i.e., the NF Instance Id of the NF Service Consumer) in the access token matches the subject claim in the CCA.

Figure 13.4.1.2.2-1: NF Service Consumer obtaining access token before NF Service access (roaming)

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.

13.4.1.1.3 Access token requests in deployments with several NRFs |R18| p. 181

As described in clause 6.2.6.1 of TS 23.501, an operator network can deploy multiple NRFs, for example due to network slicing or network segmentation.

An NF Service Consumer shall send its access token requests to the NRF where it is registered as OAuth 2.0 client. The NRF authenticates the NF Service Consumer, and may verify the input parameters in the access token request as described under Step 1 in clause 13.4.1.1.2. After successful authentication and verification of the input parameters, the NRF may forward the access token request to another NRF.

If an NRF receives an access token request for an NF Service Producer that is not registered at this NRF, the NRF determines the target NRF where the NF Service Producer is registered as specified in TS 29.510, clause 5.4.2.2.2 step 2a, and forwards the access token request to the target NRF. There can also be several hops of NRFs between the NRF that receives the access token request from the NF Service Consumer and the target NRF where the NF Service Producer is registered.

One possible hierarchical NRF deployment is the local NRF deployment. An NF Service Producer's local NRF is the NRF where the NF Service Producer registered its NF profile. In the local NRF deployment, the NF Service Producer is configured with the public key which corresponds to the private key that its local NRF uses for signing the access token. Thus, when the local NRF receives an access token request from an NF Service Consumer, the local NRF checks if the NF Service Consumer is authorized to receive the requested service and, if yes, issues and signs the access token. In the case when the access token request from the NF Service Consumer was forwarded by another NRF, the local NRF of the NF Service Producer needs to trust the NRF which forwarded the access token request.

13.4.1.1A Service access authorization in interconnect scenarios |R16| p. 182

In the inter-PLMN interconnect scenario, OAuth 2.0 roles are as follows:

The NF Service Consumer's Network Repository Function (cNRF) shall be the OAuth 2.0 Authorization server for the PLMN of the NF Service Consumer (cPLMN) and authenticates the NF Service Consumer.
The NF Service Producer's Network Repository Function (pNRF) shall be OAuth 2.0 Authorization server for the PLMN of the NF Service Producer (pPLMN) and generates the access token.
The NF Service Consumer in the cPLMN shall be the OAuth 2.0 client.
The NF Service Producer in the pPLMN shall be the OAuth 2.0 resource server.

As an example of the inter-PLMN interconnect use case, service access authorization in the roaming scenario where the service consumer NF is located in the visiting PLMN and the service producer NF is located in the home PLMN is specified in clause 13.4.1.2.

13.4.1.2 Service access authorization in roaming scenarios p. 182

13.4.1.2.1 OAuth 2.0 roles p. 182

In the roaming scenario, OAuth 2.0 roles are as follows:

The visiting Network Repository Function (vNRF) shall be the OAuth 2.0 Authorization server for vPLMN and authenticates the NF Service Consumer.
The home Network Repository Function (hNRF) shall be OAuth 2.0 Authorization server for hPLMN and generates the access token.
The NF Service Consumer in the visiting PLMN shall be the OAuth 2.0 client.
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 clause 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 clause 13.4.1.1.

13.4.1.2.2 Service Request Process p. 182

The complete service request is two-step process including requesting an access token by NF Service Consumer (Step 1, i.e. 1a or 1b), and then verification of the access token by NF Service Producer (Step 2).

Step 1: Access token request

Pre-requisite:

The NF Service consumer (OAuth2.0 client) is registered with the vNRF (Authorization Server in the vPLMN).
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 optionally "additional scope" information per NF type.
The two NRFs are implicitly authenticated via N32 mutual authentication of SEPPs.

NOTE:
vSEPP to hSEPP communication is secured via N32. Only transitive trust between vNRF and hNRF can be achieved: The vNRF and vSEPP mutually authenticate, the vSEPP and hSEPP mutually authenticate, and the hSEPP and hNRF mutually authenticate. Hence, vNRF and hNRF can only implicitly authenticate each other.
The NRF in the serving PLMN (vNRF) has authenticated the NF Service Consumer.

For SNPNs with Credentials Holder using AUSF and UDM for primary authentication, the NF Service Consumer and the vNRF are located in the SNPN while the hNRF is located in the Credentials Holder.

1a. Access token request for accessing services of NF Service Producers of a specific NF type

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.

Reproduction of 3GPP TS 33.501, Fig. 13.4.1.2.2-1: NF Service Consumer obtaining access token before NF Service access (roaming)

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 Service Producer instance, NF type of the NF Service Consumer, home and serving PLMN IDs, optionally list of NSSAIs or list of NSI IDs for the expected NF Service Producer instances, optionally NF Set ID and/or the NF Service Set ID of the expected NF Service Producer) from NRF in the same PLMN.

For SNPNs with Credentials Holder using AUSF and UDM for primary authentication, the SNPN ID of the serving SNPN is included instead of the serving PLMN ID and the SNPN ID or the PLMN ID of the Credentials Holder is included instead of the home PLMN ID.

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.

The hNRF checks whether the NF Service Consumer is authorized to access the requested service(s). If the NF Service Consumer is authorized, the hNRF 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. If the NF service consumer is not authorized, the hNRF shall not issue an access token to the NF Service Consumer.

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) 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 Service Producer instances. The claims may include the NF Set ID and/or the NF Service Set ID of the expected NF Service Producer instances.

For SNPNs with Credentials Holder using AUSF and UDM for primary authentication, the SNPN ID of the serving SNPN is included instead of the NF Service Consumer's PLMN ID and the SNPN ID or the PLMN ID of the Credentials Holder is included instead of the NF Service Producer's PLMN ID.

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.

The vNRF shall forward the Nnrf_AccessToken_Get Response or error 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 NF Service 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.

1b. Obtain access token for accessing services of a specific NF Service Producer instance / NF Service Producer service instance

The following steps describes how the NF Service Consumer obtains an access token before service access to a specific NF Service Producer instance / NF Service Producer service instance.

The NF Service Consumer shall request an access token from the NRF for a specific NF Service Producer instance / NF Service Producer service instance. The request shall include the NF Instance Id of the requested NF Service 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 in the home PLMN checks whether the NF Service Consumer is authorized to use the requested NF Service Producer instance/NF Service Producer service instance and shall then proceed to generate an access token with the appropriate claims included. If the NF Service Consumer is not authorized, the NRF in the home PLMN shall not issue an access token to the NF Service Consumer.

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.

Figure 13.4.1.2.2-2: NF Service Consumer requesting service access with an access token in roaming case

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 NF Instance Id or several NF Instance Id(s) of the requested NF Service Producer listed in claims (scope, audience) during their validity time.

Step 2:Service access request based on token verification

In addition to the steps described in the non-roaming scenario in clause 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.

Reproduction of 3GPP TS 33.501, Fig. 13.4.1.2.2-2: NF Service Consumer requesting service access with an access token in roaming case

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

For SNPNs with Credentials Holder using AUSF and UDM for primary authentication, the NF Service Producer verifies the SNPN ID of the serving SNPN contained in the API request instead of the PLMN-ID, and the SNPN ID or the PLMN ID of the Credentials Holder instead of the home PLMN ID.

The pSEPP shall check that the serving PLMN ID of subject claim in the access token matches the remote PLMN ID. If PRINS is used, this can be achieved by the pSEPP checking the PLMN ID of the serving network in the access token against the PLMN ID(s) in the N32-f context.

If the peer network is an SNPN, the pSEPP shall check that the SNPN ID of the NF Service Consumer in the access token matches the SNPN ID of the peer network.

13.4.1.3 Service access authorization in indirect communication scenarios |R16| p. 186

13.4.1.3.1 Authorization for indirect communication without delegated discovery procedure p. 186

13.4.1.3.1.1 With mutual authentication between NF Service Consumer and NRF at the transport layer p. 186

This clause covers the scenario where the NF Service Consumer and the NRF are connected over a mutually authenticated TLS connection.

Reproduction of 3GPP TS 33.501, Fig. 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

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

Discovery of the NF Service Producer:

Step 0.

Optionally, the NF Service Consumer may discover the NF Service Producer before requesting authorization to invoke the services of the NF Service Producer. E.g. if the NF Service Consumer has not yet discovered the NF Service Producer, then it may run the discovery procedure.

NF Service Consumer authorization:

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

If no cached data is available, the NF Service Consumer discovers the NF Service Producer via the SCP.

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 CCA as defined in clause 13.3.8.

If the CCA is included, the NF type of the expected audience in the CCA shall contain "NF Service Producer".

If the NF Service Consumer allows reselection of a target NF Service Producer by the SCP, the expected audience in the CCA shall also contain NF type "NRF".

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

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 CCA if received in step 4.

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

Step 7.

If the checks in step 6 are successful, the NF Service Producer processes the service request and provides a service response.

Step 8.

The SCP performs reverse API root modifications and forwards the service response.

13.4.1.3.1.2 Without mutual authentication between NF and NRF at the transport layer p. 187

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.

Reproduction of 3GPP TS 33.501, Fig. 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

Step 0.

Optionally, the NF Service Consumer may discover the NF Service Producer before requesting authorization to invoke the services of the NF Service Producer.

The NF Service Consumer sends an access token request (Nnrf_AccessToken_Get Request) to the SCP with parameters as specified in clause 13.4.1.1. The access token request may additionally include the NF Service Consumer CCA as defined in clause 13.3.8.

If the CCA is included, the NF type of the expected audience in CCA shall contain "NRF".

The SCP forwards the access token request (Nnrf_AccessToken_Get Request) to the NRF. The request may include the NF Service Consumer CCA if received in step 1.

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.

The NRF sends the access token to the SCP in an access token response (Nnrf_AccessToken_Get Response).

Figure 13.4.1.3.2-1: Authorization and service invocation procedure, for indirect communication with delegated discovery

The SCP forwards the access token response (Nnrf_AccessToken_Get Response) to the NF Service Consumer, including the access token.

Step 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 CCA.

If the CCA is included, the NF type of the expected audience in CCA shall contain "NF Service Producer".

If the NF Service Consumer allows reselection of a target NF Service Producer by the SCP, the expected audience in the CCA shall also contain NF type "NRF".

Step 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 CCA if received in step 6.

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

Step 9.

If the validation of the access token is successful, the NF Service Producer sends the service response to the SCP.

Step 10.

The SCP forwards the service response to the NF Service Consumer.

13.4.1.3.2 Authorization for indirect communication with delegated discovery procedure p. 188

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.

Reproduction of 3GPP TS 33.501, Fig. 13.4.1.3.2-1: Authorization and service invocation procedure, for indirect communication with delegated discovery

The NF Service Consumer sends a service request to the SCP. The service request may include the NF Service Consumer's CCA as defined in clause 13.3.8. The NF Service Consumer may include an access token in the service request if it has received an access token in a previous service response. If a previously received access token has expired, the NF Service Consumer may include discovery parameters as specified in TS 29.500, clause 5.2.3.2.7 in the service request.

If the CCA is included, the NF type of the expected audience in CCA shall contain "NRF" and "NF Service Producer".

The SCP may perform a service discovery with the NRF. If NF Service Consumer has included an access token in step 1, or if the SCP has a cached granted access token, then SCP may reuse the access token and proceeds to step 6.

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's CCA if received in Step 1.

The NRF authenticates the NF Service Consumer using one of the methods described in clause 13.3.1.2. If 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 instance ID as the subject of the access token.

Figure 13.5-1: Security capability negotiation

The NRF sends the access token to the SCP in an access token response (Nnrf_AccessToken_Get Response).

Step 6.

The SCP sends the service request to the NF Service Producer. The service request includes an access token (i.e., received in Step 1, received in Step 5, or previously cached), and may include the NF Service Consumer's CCA if received in Step 1.

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

Step 8.

If the validation of the access token is successful, the NF Service Producer sends the service response to the SCP.

Step 9.

The SCP forwards the service response to the NF Service Consumer. The SCP may include the access token in the service response to NF Service Consumer for possible re-use in subsequent service requests.

13.5 Security capability negotiation between SEPPs p. 190

The security capability negotiation over N32-c allows the SEPPs to negotiate which security mechanism to use for protecting NF service-related signalling over N32-f. There shall be an agreed security mechanism between a pair of SEPPs before conveying NF service-related signalling over N32-f.

When a SEPP notices that it does not have an agreed security mechanism for N32-f 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 over N32-c in order to determine, which security mechanism to use for protecting NF service-related signalling over N32-f. 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-c. The TLS connection shall provide integrity, confidentiality and replay protection.

Reproduction of 3GPP TS 33.501, Fig. 13.5-1: Security capability negotiation

The SEPP which initiated the TLS connection shall issue a POST request to the exchange-capability resource of the responding SEPP including the initiating SEPP's supported security mechanisms for protecting the NF service-related signalling over N32-f (see Table 13.5-1). The security mechanisms shall be ordered in the initiating SEPP's priority order.

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.