3GPP 24.501 v20.0.0 — the document's own text
4.6.2.4 Network slice-specific authentication and authorization
The UE and network may support network slice-specific authentication and authorization.
A serving PLMN or SNPN shall perform network slice-specific authentication and authorization for the S-NSSAI(s) of the HPLMN or the subscribed SNPN which are subject to it based on subscription information. The UE shall indicate whether it supports network slice-specific authentication and authorization in the 5GMM Capability IE in the REGISTRATION REQUEST message as specified in clauses 5.5.1.2.2 and 5.5.1.3.2.
The upper layer stores an association between each S-NSSAI and its corresponding credentials for the network slice-specific authentication and authorization.
NOTE 1: The credentials for network slice-specific authentication and authorization and how to provision them in the upper layer are out of the scope of 3GPP.
The network slice-specific authentication and authorization procedure shall not be performed unless the primary authentication and key agreement procedure as specified in the clause 5.4.1 has successfully been completed.
The AMF informs the UE about S-NSSAI(s) for which network slice-specific authentication and authorization (except for re-NSSAA) will be performed or is ongoing in the pending NSSAI. The AMF informs the UE about S-NSSAI(s) for which NSSAA procedure is completed as success in the allowed NSSAI or in the partially allowed NSSAI. The AMF informs the UE about S-NSSAI(s) for which NSSAA procedure is completed as failure in the rejected NSSAI for the failed or revoked NSSAA. The AMF stores and handles allowed NSSAI, partially allowed NSSAI, pending NSSAI, rejected NSSAI, and 5GS registration result in the REGISTRATION ACCEPT message according to clauses 5.5.1.2.4 and 5.5.1.3.4.
NOTE 2: The AMF maintains the NSSAA procedure status for each S-NSSAI, as specified in 3GPP TS 29.518 [20B] and the NSSAA procedure status for each S-NSSAI is not impacted by NSAC as specified in clauses 4.6.2.5 and 4.6.3.1.
NOTE 3: Upon completion of NSSAA procedures, it can happen that the total number of S-NSSAIs which need to be included in the allowed NSSAI exceeds eight. In this case, it is up to the AMF implementation on how to pick up the S-NSSAIs included in the allowed NSSAI.
NOTE 4: It can happen that one or more S-NSSAIs included in the received allowed NSSAI, are not the S-NSSAIs that the UE intends to register to. In this case, it is up to the UE implementation on how to use these S-NSSAIs.
To perform network slice-specific authentication and authorization for an S-NSSAI, the AMF invokes an EAP-based network slice-specific authentication and authorization procedure for the S-NSSAI, see clause 5.4.7 and 3GPP TS 23.502 [9] using the EAP framework as described in 3GPP TS 33.501 [24].
The AMF updates the allowed NSSAI, the partially allowed NSSAI and the rejected NSSAI using the generic UE configuration update procedure as specified in the clause 5.4.4 after the network slice-specific authentication and authorization procedure is completed.
The AMF shall send the pending NSSAI containing all S-NSSAIs for which the network slice-specific authentication and authorization procedure (except for re-NSSAA) will be performed or is ongoing in the REGISTRATION ACCEPT message. The AMF shall also include in the REGISTRATION ACCEPT message the allowed NSSAI containing one or more S-NSSAIs from the requested NSSAI which are allowed by the AMF and for which network slice-specific authentication and authorization is not required, if any. The AMF shall also include in the REGISTRATION ACCEPT message the partially allowed NSSAI containing one or more S-NSSAIs from the requested NSSAI which are allowed by the AMF in a list of TAs within the current registration area and for which network slice-specific authentication and authorization is not required, if any.
The network slice-specific re-authentication and re-authorization procedure or the network slice-specific authorization revocation procedure can be invoked by the network for a UE supporting NSSAA at any time. After the network performs the network slice-specific re-authentication and re-authorization procedure or network slice-specific authorization revocation procedure:
- if network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked for some but not all S-NSSAIs in the allowed NSSAI or the partially allowed NSSAI,, the AMF updates the allowed NSSAI or the partially allowed NSSAI and the rejected NSSAI accordingly using the generic UE configuration update procedure as specified in the clause 5.4.4 and inform the SMF to release all PDU sessions associated with the S-NSSAI for which network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked;
- if network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked for all S-NSSAIs in the allowed NSSAI or the partially allowed NSSAI but there are one or more default S-NSSAIs which are not subject to network slice-specific authentication and authorization or for which the network slice-specific authentication and authorization has been successfully performed, the AMF updates the allowed NSSAI or the partially allowed NSSAI containing these default S-NSSAIs and the rejected NSSAI accordingly using the generic UE configuration update procedure as specified in the clause 5.4.4. The AMF shall also inform the SMF to release all PDU sessions associated with the S-NSSAI for which network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked; or
- if network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked for all S-NSSAIs in the allowed NSSAI or the partially allowed NSSAI and all default S-NSSAIs are subject to network slice-specific authentication and authorization, and the network slice-specific authentication and authorization has not been successfully performed for any of these default S-NSSAIs, then AMF performs the network-initiated de-registration procedure and includes the rejected NSSAI in the DEREGISTRATION REQUEST message as specified in the clause 5.5.2.3 except when the UE has an emergency PDU session established or the UE is establishing an emergency PDU session. In this case the AMF shall send the CONFIGURATION UPDATE COMMAND message containing rejected NSSAI and inform the SMF to release all PDU sessions associated with the S-NSSAI for which network slice-specific re-authentication and re-authorization fails or network slice-specific authorization is revoked. After the emergency PDU session is released, the AMF performs the network-initiated de-registration procedure as specified in the clause 5.5.2.3.
The UE does not include in the requested NSSAI any of the S-NSSAIs from the pending NSSAI that the UE stores, regardless of the access type. When the UE storing a pending NSSAI intends to register to one or more additional S-NSSAIs not included in the pending NSSAI, the UE initiates the registration procedure with a requested NSSAI containing these S-NSSAIs as described in clause 5.5.1.3.2. In this case, the requested NSSAI shall also include one or more S-NSSAIs from the allowed NSSAI or the partially allowed NSSAI, if the UE still wants to use the S-NSSAI(s) from the allowed NSSAI or the partially allowed NSSAI.
During the registration procedure, when the AMF receives a requested NSSAI from a UE over an access type, for which there is a pending NSSAI including one or more S-NSSAIs that were previously requested over the same access type, the AMF considers S-NSSAIs included in the requested NSSAI and S-NSSAIs in the pending NSSAI that were previously requested over the same access type as requested S-NSSAIs by the UE. The AMF handles the requested S-NSSAIs as described in clause 5.5.1.3.4.
When performing the network slice-specific re-authentication and re-authorization procedure if the S-NSSAI is included in the allowed NSSAI for both 3GPP and non-3GPP accesses, and the UE is registered to both 3GPP and non-3GPP accesses in the same PLMN, then the AMF selects an access type to perform network slice-specific re-authentication and re-authorization based upon operator policy.
If network slice-specific authorization is revoked for an S-NSSAI that is in the current allowed NSSAI for an access type or for an S-NSSAI that is in the current partially allowed NSSAI for 3GPP access type, the AMF shall:
- provide a new allowed NSSAI or a new partially allowed NSSAI, excluding the S-NSSAI for which the network slice-specific authorization is revoked; and
- provide a new rejected NSSAI for the failed or revoked NSSAA, including the S-NSSAI for which the network slice-specific authorization is revoked, with the rejection cause "S-NSSAI not available due to the failed or revoked network slice-specific authentication and authorization",
to the UE using the generic UE configuration update procedure as specified in the clause 5.4.4 and inform the SMF to release all PDU sessions associated with the S-NSSAI for which the network slice-specific authorization is revoked for this access type.
If the UE requests the establishment of a new PDU session or the modification of a PDU session for an S-NSSAI for which the AMF is performing network slice-specific re-authentication and re-authorization procedure, the AMF may determine to not forward the 5GSM message to the SMF as described in clause 5.4.5.2.4.
NOTE 5: If the AMF receives the HTTP code set to "4xx" or "5xx" as specified in 3GPP TS 29.500 [20AA] or the AMF detects that the NSSAAF failure as specified in 3GPP TS 29.526 [21A] during the NSSAA procedure for an S-NSSAI, then the AMF considers the NSSAA procedure has failed for this S-NSSAI.