The creation, modification, and termination of a Network Slice Instance (NSI) is part of the Management Services provided by the 5G management systems. A management service is accessed by management service consumers via standardized service interfaces given in TS 28.533. The typical service consumers for the above NSI provisioning and NSI provisioning exposure are operators and vertical industry respecitively, as described in TS 28.531. These management services are securely protected through mutual authentication and authorization below.
If a management service consumer resides outside the 3GPP operator's trust domain, mutual authentication shall be performed between the management service consumer and the management service producer using TLS. TLS shall follow, the profile given in clause 6.2 of TS 33.210 and either 1) the client and server certificates with the profiles given in clause 6.1.3a of TS 33.310 or 2) pre-shared keys following RFC 5489 for TLS 1.2 and RFC 8446 for TLS 1.3. The structure of the PKI used for the certificates is out of scope of the present document. The identities in the end entity certificates shall be used for authentication and policy checks. The key distribution of pre-shared keys for TLS is up to the operator's security policy and out of scope of the present document.
TLS shall be used to provide mutual authentication, integrity protection, replay protection and confidentiality protection for the interface between the management service producer and the management service consumer residing outside the 3GPP operator's trust domain. Security profiles for TLS implementation and usage shall follow the TLS profile given in clause 6.2 of TS 33.210 and the certificate profile given in clause 6.1.3a of TS 33.310. The identities in the end entity certificates shall be used for authentication and policy checks.
After the mutual authentication, the management service producer determines whether the management service consumer is authorized to send requests to the management service producer. The management service producer shall authorize the requests from the management service consumer using the one of the following two options: 1) OAuth-based authorization mechanism following RFC 6749; 2) based on the local policy of the management service producer.
This clause specifies the relationship between primary authentication (as described in Clause 6.1) and authorization for network slice access (as described in TS 23.502) for a UE. Authorization from a home/serving PLMN is required for a UE to gain access to a network slice, identified by an S-NSSAI. An authorized S-NSSAI (i.e. allowed S-NSSAI) shall be granted to a UE only after the UE has completed successfully primary authentication. At the end of the primary authentication, the AMF and UE may receive a list of allowed S-NSSAI, which the UE is authorized to access.
For certain S-NSSAIs, additional Network Slice Specific Authentication and Authorization (NSSAA) is required. This clause in addition specifies the pre-requisite for an NSSAA procedure that is described in clause 16.3, with reference to the following Figure 16.2-1.
For an initial Registration Request, the AMF/SEAF shall invoke Primary authentication as described in clause 6.1.2 of the present document. For a subsequent Registration Request, the Primary authentication may be skipped if the UE has already been authenticated and the AMF has valid security context.
This clause specifies the optional-to-use NSSAA between a UE and an AAA server (AAA-S) which may be owned by an external 3rd party enterprise. NSSAA uses a User ID and credentials, different from the 3GPP subscription credentials (e.g. SUPI and credentials used for PLMN access) and takes place after the primary authentication.
The EAP framework specified in RFC 3748 shall be used for NSSAA between the UE and the AAA server. The SEAF/AMF shall perform the role of the EAP Authenticator and communicates with the AAA-S via the NSSAAF. The NSSAAF undertakes any AAA protocol interworking with the AAA-S. Multiple EAP methods are possible for NSSAA. If the AAA-S belongs to a third party the NSSAAF contacts the AAA-S via a AAA-P. The NSSAAF and the AAA-P may be co-located.
To protect privacy of the EAP ID used for the EAP based NSSAA, a privacy-protection capable EAP method is recommended, if privacy protection is required.
The steps involved in NSSAA are described below.
For S-NSSAIs that are requiring NSSAA, based on change of subscription information, or triggered by the AAA-S, the AMF may trigger the start of the NSSAA procedure.
If NSSAA is triggered as a result of Registration procedure, the AMF may determine, based on UE Context in the AMF, that for some or all S-NSSAI(s) subject to NSSAA, the UE has already been authenticated following a Registration procedure on a first access. Depending on NSSAA result (e.g. success/failure) from the previous Registration, the AMF may decide, based on Network policies, to skip NSSAA for these S-NSSAIs during the Registration on a second access.
If the NSSAA procedure corresponds to a re-authentication and re-authorization procedure triggered as a result of AAA Server-triggered UE re-authentication and re-authorization for one or more S-NSSAIs, as described in clause 16.4, or triggered by the AMF based on operator policy or a subscription change and if S-NSSAIs that are requiring Network Slice-Specific Authentication and Authorization are included in the Allowed NSSAI for each Access Type, the AMF selects an Access Type to be used to perform the NSSAA procedure based on network policies.
If the AAA-P is present (e.g. because the AAA-S belongs to a third party and the operator deploys a proxy towards third parties), the NSSAAF forwards the EAP ID Response message to the AAA-P, otherwise the NSSAAF forwards the message directly to the AAA-S. NSSAAF routes to the AAA-S based on the S-NSSAI. The NSSAAF/AAA-P forwards the EAP Identity message to the AAA-S together with S-NSSAI and GPSI. The AAA-S stores the GPSI to create an association with the EAP ID in the EAP ID response message so the AAA-S can later use it to revoke authorisation or to trigger reauthentication. The AAA-S uses the EAP-ID and S-NSSAI to identify for which UE and slice authorisation is requested.
Based on the result of Slice specific authentication (EAP-Success/Failure), if a new Allowed NSSAI or new Rejected NSSAIs needs to be delivered to the UE, or if the AMF re-allocation is required, the AMF initiates the UE Configuration Update procedure, for each Access Type, as described in clause 184.108.40.206 of TS 23.502.
If the NSSAA procedure can not be completed (e.g. due to server error or UE becoming unreachable), the AMF sets the status of the corresponding S-NSSAI subject to Network Slice-Specific Authentication and Authorization in the UE context as defined in TS 29.526, so that an NSSAA is executed next time the UE requests to register with the S-NSSAI.
The AAA-S requests the re-authentication and re-authorization for the Network Slice specified by the S-NSSAI/ENSI in the Re-Auth Request message, for the UE identified by the GPSI in this message. This message is sent to an AAA-P, if the AAA-P is used (e.g. the AAA Server belongs to a third party), otherwise it may be sent directly to the NSSAAF. If an AAA-P is present, the AAA-P relays the Reauthentication Request to the NSSAAF.
The NSSAAF checks whether the AAA-S is authorized to request the re-authentication and re-authorization by checking the local configuration of AAA-S address per S-NSSAI. If success,the NSSAAF requests UDM for the AMF serving the UE using the Nudm_UECM_Get (GPSI, AMF Registration) service operation. The UDM provides the NSSAAF with the AMF ID of the AMF serving the UE.
If the AMF is registered in UDM, the NSSAAF requests the relevant AMF to re-authenticate/re-authorize the S-NSSAI for the UE using the Nnssaaf_NSSAA_Re-authenticationNotification service operation. The AMF is implicitly subscribed to receive Nnssaaf_NSSAA_Re-authenticationNotification service operations. The NSSAAF may discover the Callback URI for the Nnssaaf_NSSAA_Re-authenticationNotification service operation exposed by the AMF via the NRF.
The AMF acknowledges the notification of Re-authentication request.
If the UE is registered with the S-NSSAI in the Mapping Of Allowed NSSAI, the AMF triggers the NSSAA procedure defined in clause 16.3 for the UE identified by the GPSI and the Network Slice identified by the S-NSSAI received from the NSSAAF.
If the UE is registered but the S-NSSAI is not in the Mapping Of Allowed NSSAI, the AMF removes any status of the corresponding S-NSSAI subject to Network Slice-Specific Authentication and Authorization in the UE context it may have kept, so that an NSSAA is executed next time the UE requests to register with the S-NSSAI.
The slice specific AAA-S requests the revocation of authorization for the Network Slice identified by the GPSI in the AAA Protocol Revoke Authorization Request message. This message is sent to NSSAAF instance interfacing with AAA-S or AAA-P if it is used.
The AAA-P, if present, relays the request to the NSSAAF.
The NSSAAF checks whether the AAA-S is authorized to request the revocation by checking the local configuration of AAA-S address per S-NSSAI. If success,the NSSAAF requests UDM for the AMF serving the UE using the Nudm_UECM_Get (GPSI, AMF Registration) service operation. The UDM provides the NSSAAF with the AMF ID of the AMF serving the UE.
If the AMF is registered in UDM, the NSSAAF request the relevant AMF to revoke the S-NSSAI authorization for the UE using the Nnssaaf_NSSAA_RevocationNotification service operation.
The AMF is implicitly subscribed to receive Nnssaaf_NSSAA_RevocationNotification service operations. The NSSAAF may discover the Callback URI for the Nnssaaf_NSSAA_RevocationNotification service operation exposed by the AMF via the NRF. The AMF acknowledges the Notification of Revocation request.
The AMF removes any status it may have kept of the corresponding S-NSSAI subject to Network Slice-Specific Authentication and Authorisation in the UE context and sends the UE Configuration Update message to revoke the S-NSSAI from the current Allowed NSSAI, for any Access Type for which NSSAA had been successfully run on this S-NSSAI. The AMF provides a new Allowed NSSAI to the UE by removing the S-NSSAI for which authorization has been revoked. The AMF provides new rejected NSSAIs to the UE including the S-NSSAI for which authorization has been revoked. If no S-NSSAI is left in Allowed NSSAI for an access after the revocation, and a Default NSSAI exists that requires no NSSAA or for which a NSSAA did not previously fail over this access, then the AMF may provide a new Allowed NSSAI to the UE containing the Default NSSAI. If no S-NSSAI is left in Allowed NSSAI for an access after the revocation, and no Default NSSAI can be provided to the UE in the Allowed NSSAI or a previous NSSAA failed for the Default NSSAI over this access, then the AMF shall execute the Network-initiated Deregistration procedure for the access as described in subclause 220.127.116.11.3 of TS 23.502, and it shall include in the explicit De-Registration Request message the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.
If an AF is deployed within the 3GPP operator domain, an S-NSSAI is allowed to be sent to the AF. The baseline procedure for notifying the AF slice usage information (e.g. number of UEs and PDU Sessions in the slice indicated by the S-NSSAI) and the procedure for retrieving slice usage information by the AF are defined in TS 23.502.
If an AF is deployed outside the 3GPP operator domain, an S-NSSAI is not allowed to be sent to the AF as required in clause 18.104.22.168. The procedure for notifying the AF slice usage information (e.g. number of UEs and PDU Sessions in the slice indicated by the S-NSSAI) and the procedure for retrieving slice usage information by the AF are described in clause 16.6.3.
To subscribe or unsubscribe for the number of UEs or the number of PDU Sessions per network slice notification with the NSACF, the AF sends Nnef_EventExposure_Subscribe/Unsubscribe Request (Event ID, Event Filter, Event Reporting information) message to the NEF as described in TS 23.502. The Event Filter parameter shall be ENSI for an AF deployed outside the 3GPP operator domain. Other parameters are specified in TS 23.502.
The NEF confirms with Nnef_ SliceStatusEventExposure _Subscribe/Unsubscribe Response message to the AF.
The Event Filter parameter is the mapped ENSI for the AF deployed outside the 3GPP operator domain.
The NEF checks whether the AF is authorised for the requested subscription based on the AF token. It needs to check whether the token claims match the AF's identity and the Event Filter parameter. If authorised, the NEF may query the NRF to find the NSACF responsible for the requested S-NSSAI (NEF needs to map to S-NSSAI based on ENSI for the AF deployed outside the 3GPP operator domain).
The NEF forwards the request to the NSACF with Nnsacf_SliceEventExposure_Subscribe/Unsubscribe Request (Event ID, Event Filter, Event Reporting information). The Event Filter parameter shall be the mapped S-NSSAI for the AF deployed outside the 3GPP operator domain.
The NEF forwards the message to the AF for single NSACF or aggregates reporting information for multiple NSACFs in the Nnef_EventExposure_Notify (Event ID, Event Filter, Event Reporting information) message as described in TS 23.502. The Event Filter parameter shall be the mapped ENSI from the S-NSSAI for the AF deployed outside the 3GPP operator domain.