S.3 Authentication procedure

33.5013GPPRelease 18Security architecture and procedures for 5G SystemTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

S.3.1 5G NSWO co-existence with EPS NSWO

An HPLMN that supports 5G NWSO and wants the UE to use 5G NSWO shall configure the UE to use 5G NSWO. This configuration shall be either on the USIM or ME, with configuration on the USIM taking precedence over the ME.

A UE that supports 5G NSWO and is configured to use 5G NSWO shall always use 5G NSWO as described in clause S.3.2 (i.e., it shall not use EPS NSWO defined in TS 23.402[97]). Otherwise, the UE may use EPS NSWO (e.g., UE does not support 5G NSWO or not configured to use 5G NSWO).

NOTE: Such a configuration ensures that the UE supporting 5G NSWO cannot be downgraded to use EPS NSWO.

The network may support both 5G NSWO and EPS NSWO. In such a case, the routing of the AAA messages is determined by the network based on the realm part of the UE Identity (e.g., realm contains epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org (EPS NSWO) or 5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org (5G NSWO)). Which entities in the network perform this routing decision is dependent on the network configuration.

S.3.2 5G NSWO procedures

Figure: S.3-1: Authentication procedure for NSWO in 5GS

1. The UE establishes a WLAN connection between the UE and the WLAN Access Network (AN), using procedures specified in IEEE 802.11[80].

2. The WLAN AN sends an EAP Identity/Request to the UE.

3. The UE sends an EAP Response/Identity message. If the UE determines to use the NSWO service, the UE shall use the SUCI in NAI format (i.e., username@realm format as specified in clause 28.7.3 of TS 23.003[19]) as its identity irrespective of whether SUPI Type configured on the USIM is IMSI or NAI. If the SUPI Type configured on the USIM is IMSI, the UE shall construct the SUCI in NAI format with username containing the encrypted MSIN and the realm part containing the MCC/MNC.

4. The EAP Response/Identity message shall be routed over the SWa interface towards the NSWOF based on the realm part of the SUCI.

NOTE 1: NSWOF acts as SBI/AAA proxy between the AUSF and the WLAN Access Network.

5. The NSWOF shall send the message Nausf_UEAuthentication_Authenticate Request with SUCI, Access Network Identity and NSWO indicator towards the AUSF. NSWO_indicator is used to indicate to the AUSF that the authentication request is for Non-seamless WLAN offload purposes. The NSWOF shall set the Access Network Identity to "5G:NSWO".

6. Based on the NSWO_indicator, the AUSF (acting as the EAP authentication server) shall send a Nudm_UEAuthentication_Get Request to the UDM, including SUCI and the Access Network Identity and NSWO indicator.

7. Upon reception of the Nudm_UEAuthentication_Get Request, the UDM shall invoke SIDF. SIDF shall de-conceal SUCI to gain SUPI before UDM can process the request. Based on the NSWO indicator, the UDM/ARPF shall select the EAP-AKA´ authentication method and generate an authentication vector using the Access Network Identity as the KDF input parameter. The UDM shall include the EAP-AKA’ authentication vector (RAND, AUTN, XRES, CK´ and IK´) and may include SUPI to AUSF in a Nudm_UEAuthentication_Get Response message.

8. The AUSF shall store XRES for future verification. The AUSF shall send the EAP-Request/AKA’-Challenge message to the NSWOF in a Nausf_UEAuthentication_Authenticate Response message.

NOTE: The Access Network Identity is carried in the AT_KDF_INPUT attribute in EAP-AKA’ as defined in RFC 5448 [12].

9. The NSWOF shall send the EAP-Request/AKA’-Challenge message to the WLAN AN over the SWa interface.

10. The WLAN AN forwards the EAP-Request/AKA’-Challenge message to the UE.

11. At receipt of the RAND and AUTN in the EAP-Request/AKA’-Challenge message, the ME shall obtain the Access Network Identity from the EAP signalling and the USIM in the UE shall verify the freshness of the AV’ by checking whether AUTN can be accepted as described in TS 33.102 [40]. If so, the USIM computes a response RES. The USIM shall return RES, CK, IK to the ME. The ME shall derive CK’ and IK’ using the Access Network Identity as the KDF input parameter. If the verification of the AUTN fails on the USIM, then the USIM and ME shall proceed as described in sub-clause 6.1.3.3. The UE may derive MSK from CK’ and IK’ as per Annex F and as described in RFC 5448[12]. When the UE is performing NSWO authentication, the K_AUSF shall not be generated by the UE.

12. The UE shall send the EAP-Response/AKA’-Challenge message to the WLAN AN.

13. The WLAN AN forwards the EAP-Response/AKA’-Challenge message over the SWa interface to the NSWOF.

14. The NSWOF shall send the Nausf_UEAuthentication_Authenticate Request with EAP-Response/AKA’-Challenge message to AUSF.

15. The AUSF shall verify if the received response RES matches the stored and expected response XRES. If the AUSF has successfully verified, it continues as follows to step 16, otherwise it returns an error to the NSWOF. The AUSF shall derive the required MSK key from CK’ and IK’ as per Annex F and as described in RFC 5448[12], based on the NSWO indicator received in step 5. The AUSF shall not generate the K_AUSF.

16. The AUSF shall send Nausf_UEAuthentication_Authenticate Response message with EAP-Success and MSK key to NSWOF. The AUSF may optionally provide the SUPI to NSWOF. The AUSF/UDM shall not perform the linking increased home control to subsequent procedures (as stated in present document clause 6.1.4).

17. The NSWOF shall send the EAP-success and MSK to WLAN AN over the SWa interface. The EAP-Success message is forwarded from WLAN AN to the UE.

18. Upon receiving the EAP-Success message, the UE derives the MSK as specified in step 11, if it has not derived the MSK earlier. The UE uses the first 256-bit of MSK as PMK to perform 4-way handshake to establish a secure connection with the WLAN AN.