Content for TS 33.501 Word version: 19.0.0

1… 4… 5… 5.3… 5.9… 5.10… 6… 6.1.3… 6.1.4… 6.2… 6.2.2… 6.3… 6.4… 6.5… 6.6… 6.7… 6.8… 6.9… 6.10… 6.11 6.12… 6.13 6.14… 6.15… 6.16… 7… 7A… 7A.2.3… 7B… 8… 9… 10… 11… 12… 13… 13.2.2… 13.2.4… 13.3… 13.4… 14… 15… 16… A… B… C… D… E… F… G… I… I.9… J… K… M… N… O… P… R S… T… U… V… W… X… Y… Z…

I.1 General I.2 Authentication in standalone non-public networks I.2.1 General I.2.2 EAP framework, selection of authentication method, and EAP method credentials I.2.2.1 General I.2.2.2 Credentials holder using AAA server for primary authentication I.2.3 Key hierarchy, key derivation and key distribution I.2.3.1 General I.2.3.2 Credentials holder using AAA server for primary authentication I.2.4 Credentials Holder using AUSF and UDM for primary authentication I.3 Serving network name for standalone non-public networks I.3.1 General I.3.2 Definition of SN Id for standalone non-public networks I.4 Modification of CAG ID list in the UE I.5 SUPI privacy for standalone non-public networks I.6 Authentication in Public Network Integrated Non-Public Networks (PNI-NPN) I.7 Authorization aspects in SNPNs I.7.1 Credentials holder using AUSF and UDM for primary authentication I.8 SEPP and interconnect related security procedures I.8.1 Credentials holder using AUSF and UDM for primary authentication
...

I (Normative) Non-public networks |R16| p. 256

I.1 General p. 256

This Annex provides details on security for non-public networks. Most of the security procedures are the same as public networks so this Annex only summarizes and specifies where there are exceptions to the normal procedures.

The feature for support of non-public networks (NPN) by 5GS is described in clause 5.30 of TS 23.501.

I.2 Authentication in standalone non-public networks p. 256

I.2.1 General p. 256

One of the major differences of non-public networks is that authentication methods other than AKA based ones may be used in a standalone non-public network (SNPN). When an AKA-based authentication method is used, clause 6.1 shall apply. When an authentication method other than 5G AKA or EAP-AKA' is used, only the non-AKA specific parts of clause 6.1 shall apply. An example of running such an authentication method is given in Annex B with EAP-TLS.

The choice of the supported authentication methods for access to SNPNs follows the principles described in clause I.2.2 and clause I.2.3.

The authentication server can be an internal authentication server or an external authentication server. The internal authentication server is the AUSF, and the authentication method can be 5G-AKA or EAP-AKA' as described in clause 6.1, or can be EAP-TLS as described in Annex B. When external authentication server is the AAA, the primary authentication procedure is described in Annex I.2.2.2.2. When external authentication server is an AUSF, then the primary authentication procedure is described in Annex I.2.4. The UDM decides to run primary authentication with internal authentication server or external authentication server.

I.2.2 EAP framework, selection of authentication method, and EAP method credentials p. 256

I.2.2.1 General |R17| p. 256

The EAP authentication framework is supported by the 5GS as described in clause 6.1.1.2.

The UE and the SNPN may support 5G AKA, EAP-AKA', or any other key-generating EAP authentication method.

Selection of the authentication methods is dependent on NPN configuration.

When an EAP authentication method other than EAP-AKA' is selected, the chosen method determines the credentials needed in the UE and network. These credentials, called the EAP-method credentials, shall be used for authentication.

I.2.2.2 Credentials holder using AAA server for primary authentication |R17| p. 257

I.2.2.2.1 General p. 257

The procedures described in this clause enables UEs to access an SNPN which makes use of a credential management system managed by a credential provider external to the SNPN.

In this scenario the authentication server role is taken by the AAA Server. The AUSF acts as EAP authenticator and interacts with the AAA Server to execute the primary authentication procedure.

The architecture for SNPN access using credentials from a Credentials Holder using AAA Server is described in clause 5.30.2.9.2 of TS 23.501.

I.2.2.2.2 Procedure p. 257

Reproduction of 3GPP TS 33.501, Fig. I.2.2.2.2-1: Primary authentication with external domain

Figure I.2.2.2.2-1: Primary authentication with external domain

Step 0.

The UE shall be configured with credentials from the Credentials holder e.g. SUPI containing a network-specific identifier and credentials for the key-generating EAP-method used. As part of configuration of the credentials, the UE shall also be configured with an indication that the UE shall use MSK for the derivation of KAUSF after the success of the primary authentication. The exact procedures used to configure the UE are not specified in the present document.

It is further assumed that there exists a trust relation between the SNPN and the Credentials holder AAA Server. These entities need to be mutually authenticated, and the information transferred on the interface need to be confidentiality, integrity and replay protected.

When the procedures of this clause are used for onboarding purposes, the onboarding specific adaptations includes: the 'credentials' used is 'Default credentials', the 'SUPI' used is 'onboarding SUPI', the 'SUCI' used is 'onboarding SUCI' respectively.

Step 1.

The UE shall select the SNPN and initiate UE registration in the SNPN.

For construction of the SUCI, existing methods in clause 6.12 can be used. Otherwise, if the EAP method supports SUPI privacy, the UE may send an anonymous value SUCI based on configuration.

Step 2.

The AMF within the SNPN shall initiate a primary authentication for the UE using a Nausf_UEAuthentication_Authenticate service operation with the AUSF. The AMF shall discover and select an AUSF based on criterions specified in clause 5.30.2.9.2 of TS 23.501.

Step 3.

In the case of onboarding, steps 3-5 are omitted. If steps 3-5 are not omitted, the AUSF shall initiate a Nudm_UEAuthentication_Get service operation. The AUSF shall discover and select a UDM based on criterions specified in clause 5.30.2.9 of TS 23.501.

Step 4.

In case the UDM receives a SUCI, the UDM shall resolve the SUCI to the SUPI before checking the authentication method applicable for the SUPI. The UDM decides to run primary authentication with an external entity based on subscription data.

In case the UDM receives an anonymous SUCI, the UDM decides to run primary authentication with an external entity based the realm part of the SUPI in NAI format.

In case the UDM receives an anonymous SUCI that does not contain the realm part, the UDM shall abort the procedure. Otherwise, the UDM authorizes the UE based on realm part of SUCI and send the anonymous SUPI and the indicator to the AUSF as described in step5.

The anonymous SUPI shall be a NAI format.

Step 5.

In case the UDM received a SUCI in previous steps, the UDM shall provide the AUSF with the SUPI or anonymous SUPI and shall indicate to the AUSF to run primary authentication with a AAA Server in an external Credentials holder.

When a Credentials Holder using AAA Server is used for primary authentication, the AUSF uses the MSK to derive KAUSF. It is strongly recommended that the same credentials that are used for authentication between UE and the 5G SNPN are not used for the authentication between the UE and a non-5G network, assuming that 5G SNPN and non-5G network are in different security domains.

Step 6.

Based on the indication from the UDM, the AUSF shall select an NSSAAF as defined in TS 23.501 and initiate a Nnssaaf_AIWF_Authenticate service operation towards that NSSAAF as defined in clause 14.4.2.

Step 7.

The NSSAAF shall select AAA Server based on the domain name corresponding to the realm part of the SUPI. The NSSAAF shall perform related protocol conversion and relay EAP messages to the AAA Server.

Step 8.

The UE and AAA Server shall perform mutual authentication. The AAA Server shall act as the EAP Server for the purpose of primary authentication. The EAP Identity received by the AAA Server in the EAP-Response/Identity message in step 7 may contain anonymised SUPI. In such cases, AAA Server uses the EAP-method specific EAP Identity request/response messages to obtain the UE identifier as part of the EAP authentication between the UE and the AAA Server.

Step 9.

After successful authentication, the MSK and the SUPI (i.e., the UE identifier that is used for the successful EAP authentication) shall be provided from the AAA Server to the NSSAAF.

Step 10.

The NSSAAF returns the MSK and the SUPI to the AUSF using the Nnssaaf_AIWF_Authenticate service operation response message. The SUPI received from the AAA shall be used when deriving 5G keys (e.g., KAMF) that requires SUPI as an input for the key derivation.

Step 11-13.

In case of onboarding or SUCI received in step 2 is not anonymous, steps 11-13 are omitted. Otherwise, the AUSF verifies that the SUPI corresponds to a valid subscription in the SNPN by informing the UDM about the authentication result for the received SUPI using a Nudm_UEAuthentication_ResultConfirmation service operation. The UDM stores the authentication state for the SUPI and if there is not a subscription corresponding to the SUPI, the UDM shall return an error.

If the verification of the SUPI is not successful, then the AUSF rejects the UE access to the SNPN.

Step 14.

The AUSF shall use the most significant 256 bits of MSK as the KAUSF. The AUSF shall also derive KSEAF from the KAUSF as defined in Annex A.6.

Step 15.

The AUSF shall send the successful indication together with the SUPI of the UE to the AMF/SEAF together with the resulting KSEAF.

Step 16.

The AMF shall send the EAP success in a NAS message.

Step 17.

The UE shall derive the KAUSF from MSK as described in step 11 according to the pre-configured indication as described in step 0.

I.2.3 Key hierarchy, key derivation and key distribution p. 259

I.2.3.1 General |R17| p. 259

The text in clauses 6.2.1 and 6.2.2 cannot apply directly for an EAP authentication method other than EAP-AKA' as these clauses assume that an AKA-based authentication method is used. The major differences are the way in which KAUSF is calculated and that the UDM/ARPF is not necessarily involved in the key derivation or distribution.

Depending on the selected authentication method, the KAUSF is generated as follows:

For 5G AKA and EAP-AKA' refer to clause 6.2.1.
When using a key-generating EAP authentication method other than EAP-AKA', the key derivation of KAUSF is based on the EAP-method credentials in the UE and AUSF and shall be done as shown in Figure I.2.3.1-1.

Reproduction of 3GPP TS 33.501, Fig. I.2.3.1-1: KAUSF derivation for key-generating EAP authentication methods other than EAP-AKA'

Figure I.2.3.1-1: KAUSF derivation for key-generating EAP authentication methods other than EAP-AKA'

KAUSF shall be derived by the AUSF and UE from the EMSK created by the EAP authentication as for EAP-AKA'.

All of Figure 6.2.1-1, Figure 6.2.2-1 and Figure 6.2.2-2 from the KAUSF downwards are used without modification. Similarly, text relating to the key hierarchy, key derivation and key distribution in clauses 6.2.1, 6.2.2.1 and 6.2.2.2 for keys derived from KAUSF (e.g. KSEAF, KAMF, KgNB etc) apply without modification.

I.2.3.2 Credentials holder using AAA server for primary authentication |R17| p. 260

When running primary authentication towards an external Credentials holder using AAA server for authentication as specified in clause I.2.2.2 the derivation of KAUSF is based on the EAP-method credentials in the UE and AAA-S and shall be done as shown in Figure I.2.3.2-1.

Reproduction of 3GPP TS 33.501, Fig. I.2.3.2-1: KAUSF derivation for primary authentication towards an external Credentials holder using AAA server

Figure I.2.3.2-1: KAUSF derivation for primary authentication towards an external Credentials holder using AAA server

KAUSF shall be derived by the AUSF and UE from the MSK derived during the EAP authentication as specified in clause I.2.2.2.1.

I.2.4 Credentials Holder using AUSF and UDM for primary authentication |R17| p. 260

The 5G System architecture for SNPN with Credentials Holder using AUSF and UDM for primary authentication and authorization is described in clause 5.30.2.9.3 of TS 23.501.

The requirements and procedures for primary authentication using AUSF and UDM as described in the present document apply, for 5G AKA, EAP-AKA', EAP-TLS or any other key-generating EAP method.

I.3 Serving network name for standalone non-public networks p. 261

I.3.1 General p. 261

The identification of standalone non-public networks uses Network Identifier (NID) in addition to PLMN ID. This means the definition of SN Id in clause 6.1.1.4.1 for the derivation of KSEAF for all authentication methods, CK' and IK' for EAP-AKA', and KAUSF and (X)RES* for 5G AKA needs modification for standalone non-public networks.

I.3.2 Definition of SN Id for standalone non-public networks p. 261

For standalone non-public networks, the SN Id (used in the input for various key/parameter derivations) identifies the serving SNPN.

It is defined as follows:

SN Id = PLMN ID:NID

and is specified in detail in TS 24.501.

I.4 Modification of CAG ID list in the UE p. 261

The following requirements apply to NAS messages that modify the list of CAG IDs stored in the UE:

the AMF shall only send such a NAS message once NAS security has been established; and
the UE shall only modify its list of CAG IDs after successful integrity verification of the integrity protected NAS message requesting such a modification.

I.5 SUPI privacy for standalone non-public networks p. 261

The UE shall support SUPI privacy as defined in clause 6.12 with the following exception. When using an authentication method other than 5G AKA or EAP-AKA', the location of the functionality related to SUPI privacy in the UE is out of scope.

In scenarios where the EAP-method supports privacy, the UE may send an anonymous SUCI based on configuration.

Furthermore, the privacy considerations for EAP TLS (given in Annex B.2.1.2) should be taken into account when using an authentication method other than 5G AKA or EAP-AKA'.

I.6 Authentication in Public Network Integrated Non-Public Networks (PNI-NPN) p. 261

For public network integrated NPN (PNI-NPN), the primary authentication shall be performed with the public network as described in clause 6.1. Secondary authentication as described in clause 11 and slice-specific authentication as described in the main body can take place after a successful primary authentication.

Requirements for Security Edge Protection Proxy (SEPP), clause 5.9.3.2
Protection between SEPPs, clause 13.1.2.