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…

7A.2.3 Key hierarchy for trusted non-3GPP access 7A.2.4 Authentication for devices that do not support 5GC NAS over WLAN access
...

7A.2.3 Key hierarchy for trusted non-3GPP access p. 135

The key hierarchy described in clause 6.2.1 applies, with the following changes:

The key derived for non-3GPP access is called KTNGF in the context of trusted access.
The key KTNGF received from AMF is used for two different purposes; to setup IPSec SAs between the UE and the TNGF and to create WLAN keys between the UE and the TNAP.
To separate the keys for these purposes, the key hierarchy in Figure 7A.2.3-1 shall be used. The KTIPSec key is used to setup IPSec SAs and the KTNAP key is used to setup access security.
The keys KTIPSec and KTNAP are derived as described in Clause A.22.

Reproduction of 3GPP TS 33.501, Fig. 7A.2.3-1: Key hierarchy for trusted non-3GPP access

Figure 7A.2.3-1: Key hierarchy for trusted non-3GPP access

7A.2.4 Authentication for devices that do not support 5GC NAS over WLAN access p. 136

A N5CW device is capable to register to 5GC with 3GPP credentials and to establish 5GC connectivity via a trusted WLAN access network. The reference architecture is captured in clause 4.2.8.5.2 of TS 23.501. The 3GPP credentials are stored as defined in clause 6.1.1.1. The Trusted WLAN Interworking Function (TWIF) provides interworking functionality that enables connectivity with 5GC and implements the NAS protocol stack and exchanges NAS messages with the AMF on behalf of the N5CW device. A single EAP-AKA' authentication procedure is executed for connecting the N5CW device both to the trusted WLAN access network and to the 5G core network.

Reproduction of 3GPP TS 33.501, Fig. 7A.2.4-1: Authentication Procedure for N5CW

Figure 7A.2.4-1: Authentication Procedure for N5CW

Step 0.

The N5CW device selects a PLMN and a trusted WLAN that supports "5G connectivity-without-NAS" to this PLMN by using the procedure specified in clause 6.3.12a of TS 23.501, "Access Network selection for devices that do not support 5GC NAS over WLAN".

Steps 1-10: Initial registration to 5GC.

Step 1.

The N5CW device associates with the trusted WLAN network and the EAP-AKA' authentication procedure is initiated.

Step 2.

The N5CW device shall provide its Network Access Identity (NAI) The Trusted WLAN Access Point (TWAP) selects a Trusted WLAN Interworking Function (TWIF), e.g. based on the received realm, and sends an AAA request to the selected TWIF.

If the N5CW device registers to 5GC over 3GPP access for the first time when the above procedure is initiated, then the NAI shall include the SUCI. The SUCI shall be constructed as specified in clause 6.12.2.

If the N5CW device has registered to 5GC over 3GPP access when the above procedure is initiated, then the NAI includes the 5G-GUTI assigned to the N5CW device over 3GPP access. This enables the TWIF in step 4a below to select the same AMF as the one serving the N5CW device over 3GPP access.

Step 3.

The TWIF shall create a 5GC Registration Request message on behalf of the N5CW device. The TWIF shall use default values to populate the parameters in the Registration Request message, which are the same for all N5CW devices that do not support 5G NAS. The Registration type indicates "Initial Registration".

Step 4.

The TWIF shall select an AMF (e.g. by using the 5G-GUTI in the NAI, if provided by the N5CW device) and shall send an N2 message to the AMF including the Registration Request, the User Location and an AN Type.

Step 5.

In case the AMF triggers an authentication procedure, it sends a request to AUSF by sending Nausf_UEAuthentication_Authenticate Request message. The Nausf_UEAuthentication_Authenticate Request message contains SUCI or SUPI (in case of a valid 5G-GUTI is received by the AMF). The request message contains also an indication that the request is from a N5CW device.

Even if the AMF already has a security context identified by 5G-GUTI, the AMF shall initiate the primary authentication.

Step 6.

The AUSF shall send Nudm_UEAuthentication_Get Request to the UDM including SUCI or SUPI and the N5CW indication.

Step 7.

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. The UDM may select an authentication method based on the "realm" part of the SUPI, the N5CW device indicator, a combination of the "realm" part and the N5CW device indicator, or the UDM local policy.

Step 8.

The EAP-AKA' procedure will be trigged to perform mutual authentication between the N5CW device and the home network as specified in clause 6.1.3.1.

EAP-AKA' takes place between the N5CW device and AUSF. Over the N2 interface, the EAP messages are encapsulated within NAS Authentication messages. The EAP-AKA' messages exchanged between the N5CW Device and the TWIF shall be encapsulated into the layer-2 packets, e.g. into IEEE 802.3/802.1x packets, into IEEE 802.11/802.1x packets, into PPP packets, etc.

Step 9.

The NAS security context is not required in this scenario. The AMF shall derive an KTWIF key from the received KAMF key as specified in Annex A.9. NAS security between AMF and TWIF is established similar to unauthenticated emergency calls, i.e. with NULL encryption and NULL integrity protection.

Step 10a.

The AMF shall send NAS Security Mode Command to the TWIF. The NAS Security Mode Command shall contain the EAP-Success message and the NULL security algorithms.

Step 10b.

The TWIF shall not forward the EAP-Success to the N5CW directly, instead, it shall store the EAP-Success message and wait for KTWIF.

Step 10c.

The TWIF shall send the NAS Security Mode Complete message to the AMF.

Step 11.

The AMF sends an N2 Initial Context Setup Request and provides the KTWIF key to TWIF.

Step 12.

The TWIF shall derive a TNAP key, KTNAP, from the KTWIF key as specified in Appendix A.22 and send the TNAP key and the EAP-Success message to the Trusted WLAN Access Point, which forwards the EAP-Success to the N5CW device. The TNAP key corresponds to the PMK (Pairwise Master Key) which is used to secure the WLAN air-interface communication according to IEEE 802.11 [80]. A layer-2 or layer-3 connection is established between the Trusted WLAN Access Point and the TWIF for transporting all user-plane traffic of the N5CW device to TWIF. This connection is later bound to an N3 connection that is created for this N5CW device.

Step 13.

The TWIF shall send N2 Initial Context Setup Response message to the AMF.

Step 14.

The following steps are captured in clause 4.12b.2 of TS 23.502.