Content for TS 33.501 Word version: 18.4.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…

U.1 Introduction U.2 Procedure
...

U Primary authentication using EAP-TTLS in SNPNs |R17| p. 287

U.1 Introduction p. 287

In SNPN, when a credential holder is located outside of the 5GC of the SNPN, EAP-TTLS can be used to authenticate the UE. EAP-TTLS consists of two phases of authentication. In the first phase, a TLS tunnel is established between the UE and the EAP-TTLS server on AUSF. In the second phase, a legacy authentication protocol can be run between the UE and the credential holder (namely AAA) through the established TLS tunnel.

After the successful completion of EAP-TTLS, the AUSF and the UE derive the KAUSF from the EMSK.

UE is provisioned with a trust anchor to enable verification of the EAP-TTLS server certificate. The provisioning of trust anchor on the UE is outside the scope of this document.

U.2 Procedure p. 287

Reproduction of 3GPP TS 33.501, Fig. U.2-1: Primary authentication using EAP-TTLS and AAA

Figure U.2-1: Primary authentication using EAP-TTLS and AAA

Step 0.

The UE is configured with the trust anchor needed to authenticate the certificate of the EAP-TTLS server running on the AUSF. Further, the UE is configured with the credentials required to authenticate with the AAA server.

Steps 1-17 are same as the steps 1-17 in clause B.2.1.1 in Annex B, except in the following steps:

Step 1.

The SUPI in the NAI format, i.e., username@realm, is used.

Step 5.

EAP-TTLS is selected by the UDM as the authentication method.

Step 6-17.

EAP-TTLS phase 1 is executed between the AUSF and the UE. EAP-Type is set to EAP-TTLS and the authentication of the UE using TLS client certificate is skipped. Since TLS client certificate is not used in EAP-TTLS, the UE need not be configured with UE certificate.

Step 18-27.

After EAP-TTLS phase 1 is successfully completed, the UE runs EAP-TTLS phase 2 authentication with the AAA as specified in RFC 5281 via NSSAAF. The phase 2 authentication method used is outside the scope of the present document but MS-CHAPv2 is depicted here as an example to show that the Nnssaaf_AIW_Authentication service offered by NSSAAF carries AVPs if the phase 2 authentication method is non-EAP.NOTE: As referenced in Section 14.1.11 of RFC 5281, allowing the use of phase 2 (inner) authentication method outside of tunnelled protocol leads to Man-in-the-Middle (MitM) vulnerability. Thus, it is assumed that the UE does not allow the use of phase 2 authentication method outside of TLS tunnel (i.e., the UE does not respond to requests for phase 2 authentication outside of the TLS tunnel). In environments where the use of phase 2 authentication outside of the tunnelled protocol cannot be prevented, EAP-TTLS implementations need to address this vulnerability by using EAP channel binding or cryptographic binding described in RFC 6678.

Step 28-31.

After EAP-TTLS phase 2 authentication is successfully completed, the rest of the procedures are same as steps 18-21 described in clause B.2.1.1, except that the EAP-Type is set to EAP-TTLS in the EAP Response message from the UE to the AUSF.