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…

6.0 General 6.1 Primary authentication and key agreement 6.1.1 Authentication framework 6.1.1.1 General 6.1.1.2 EAP framework 6.1.1.3 Granularity of anchor key binding to serving network 6.1.1.4 Construction of the serving network name 6.1.1.4.1 Serving network name 6.1.1.4.2 Construction of the serving network name by the UE 6.1.1.4.3 Construction of the serving network name by the SEAF 6.1.2 Initiation of authentication and selection of authentication method
...

6 Security procedures between UE and 5G network functions p. 45

6.0 General p. 45

When the UE is capable of connecting to 5GC and EPC and connected to an ng-eNB which is connected to both EPC and 5GC, the UE has the ability to select which core network to connect to as described in clause 4.8.4 in TS 24.501. If the UE selects the EPC, the UE shall use security procedure as in TS 33.401. Otherwise, if the UE selects 5GC, the UE shall use the security procedures as per this document.

For an ng-eNB which can connect to EPC and 5GC, the ng-eNB shall choose the corresponding security procedures based on the UE selected type of core netowrk, i.e., when EPC is selected, the ng-eNB shall use security procedures as described in TS 33.401. On the other hand, when 5GC is selected, the ng-eNB shall use security procedures as described in this document.

6.1 Primary authentication and key agreement p. 45

6.1.1 Authentication framework p. 45

6.1.1.1 General p. 45

The purpose of the primary authentication and key agreement procedures is to enable mutual authentication between the UE and the network and provide keying material that can be used between the UE and the serving network in subsequent security procedures. The keying material generated by the primary authentication and key agreement procedure results in an anchor key called the KSEAF provided by the AUSF of the home network to the SEAF of the serving network.

Keys for more than one security context can be derived from the KSEAF without the need of a new authentication run. A concrete example of this is that an authentication run over a 3GPP access network can also provide keys to establish security between the UE and a N3IWF used in untrusted non-3GPP access.

The anchor key KSEAF is derived from an intermediate key called the KAUSF. The KAUSF is established between the UE and HN resulting from the primary authentication procedure. The KAUSF may be securely stored in the AUSF based on the home operator's policy on using such key e.g. if the control plane solution for Steering of Roaming (see clause 6.14) or UE Parameter Update procedures (see clause 6.15) or AKMA are supported by the HPLMN.

UE and serving network shall support EAP-AKA' and 5G AKA authentication methods.

The USIM shall reside on a UICC. The UICC may be removable or non-removable.

If the terminal supports 3GPP access capabilities, the credentials used with EAP-AKA' and 5G AKA for non-3GPP access networks shall reside on the UICC.

Upon successful completion of the 5G AKA primary authentication, the AMF shall initiate NAS security mode command procedure (see clause 6.7.2) with the UE.

6.1.1.2 EAP framework p. 46

The EAP framework is specified in RFC 3748. It defines the following roles: peer, pass-through authenticator and back-end authentication server. The back-end authentication server acts as the EAP server, which terminates the EAP authentication method with the peer. In the 5G system, the EAP framework is supported in the following way:

The UE takes the role of the peer.
The SEAF takes the role of pass-through authenticator.
The AUSF takes the role of the backend authentication server.

6.1.1.3 Granularity of anchor key binding to serving network p. 46

The primary authentication and key agreement procedures shall bind the KSEAF to the serving network. The binding to the serving network prevents one serving network from claiming to be a different serving network, and thus provides implicit serving network authentication to the UE.

This implicit serving network authentication shall be provided to the UE irrespective of the access network technology, so it applies to both 3GPP and non-3GPP access networks.

Furthermore, the anchor key provided to the serving network shall also be specific to the authentication having taken place between the UE and a 5G core network, i.e. the KSEAF shall be cryptographically separate from the key KASME delivered from the home network to the serving network in earlier mobile network generations.

The anchor key binding shall be achieved by including a parameter called "serving network name" into the chain of key derivations that leads from the long-term subscriber key to the anchor key.

The value of serving network name is defined in subclause 6.1.1.4 of the present document.

The chain of key derivations that leads from the long-term subscriber key to the anchor key is specified in subclause 6.1.3 of the present document for each (class) of authentication methods. The key derivation rules are specified in Annex A.

6.1.1.4 Construction of the serving network name p. 47

6.1.1.4.1 Serving network name p. 47

The serving network name is used in the derivation of the anchor key. It serves a dual purpose, namely:

It binds the anchor key to the serving network by including the serving network identifier (SN Id).
It makes sure that the anchor key is specific for authentication between a 5G core network and a UE by including a service code set to "5G".

In 5G AKA, the serving network name has a similar purpose of binding the RES* and XRES* to the serving network.

The serving network name is the concatenation of a service code and the SN Id with a separation character ":" such that the service code prepends the SN Id.

The SN Id identifies the serving PLMN and, except for standalone non-public networks, is defined as SNN-network-identifier in TS 24.501.

6.1.1.4.2 Construction of the serving network name by the UE p. 47

The UE shall construct the serving network name as follows:

It shall set the service code to "5G".
It shall set the network identifier to the SN Id of the network that it is authenticating to.
Concatenate the service code and the SN Id with the separation character ":".

6.1.1.4.3 Construction of the serving network name by the SEAF p. 47

The SEAF shall construct the serving network name as follows:

It shall set the service code to "5G".
It shall set the network identifier to the SN Id of the serving network to which the authentication data is sent by the AUSF.
It shall concatenate the service code and the SN Id with the separation character ":".

6.1.2 Initiation of authentication and selection of authentication method p. 48

The initiation of the primary authentication is shown in Figure 6.1.2-1.

Reproduction of 3GPP TS 33.501, Fig. 6.1.2-1: Initiation of authentication procedure and selection of authentication method

Figure 6.1.2-1: Initiation of authentication procedure and selection of authentication method

The SEAF may initiate an authentication with the UE during any procedure establishing a signalling connection with the UE, according to the SEAF's policy. The UE shall use SUCI or 5G-GUTI in the Registration Request.

The SEAF shall invoke the Nausf_UEAuthentication service by sending a Nausf_UEAuthentication_Authenticate Request message to the AUSF whenever the SEAF wishes to initiate an authentication.

The Nausf_UEAuthentication_Authenticate Request message shall contain either:

SUCI, as defined in the current specification, or
SUPI, as defined in TS 23.501.

The SEAF shall include the SUPI in the Nausf_UEAuthentication_Authenticate Request message in case the SEAF has a valid 5G-GUTI and re-authenticates the UE. Otherwise the SUCI is included in Nausf_UEAuthentication_Authenticate Request. SUPI/SUCI structure is part of stage 3 protocol design.

The Nausf_UEAuthentication_Authenticate Request shall furthermore contain:

the serving network name, as defined in subclause 6.1.1.4 of the present document.

The Nausf_UEAuthentication_Authenticate Request may furthermore contain:

Disaster Roaming service indication, as specified in clause 4.2.2.2 of TS 23.502.

Upon receiving the Nausf_UEAuthentication_Authenticate Request message, the AUSF shall check that the requesting SEAF in the serving network identified by the 3gpp-Sbi-Originating-Network-Id header specified in TS 29.500 is entitled to use the serving network name in the Nausf_UEAuthentication_Authenticate Request. For the case that the 3gpp-Sbi-Originating-Network-Id header is not included, the AUSF may authorize the serving network based on its name available in the Nausf_UEAuthentication_Authenticate Request message..

The AUSF shall store the received serving network name temporarily. If the serving network is not authorized to use the serving network name, the AUSF shall respond with "serving network not authorized" in the Nausf_UEAuthentication_Authenticate Response.

For the Disaster Roaming, the AUSF shall check the local configuration and, if allowed, the AUSF sends Nudm_UEAuthentication_Get Request to the UDM.

The Nudm_UEAuthentication_Get Request sent from AUSF to UDM includes the following information:

SUCI or SUPI;
the serving network name;
if received from SEAF, Disaster Roaming service indication;

Upon reception of the Nudm_UEAuthentication_Get Request, the UDM shall invoke SIDF if a SUCI is received. SIDF shall de-conceal SUCI to gain SUPI before UDM can process the request.

Based on SUPI, the UDM/ARPF shall choose the authentication method.

For the Disaster Roaming, the UDM shall check the local configuration and, if allowed, the UDM proceeds with the chosen authentication method.