Section: B.2.1.1 Security procedures
Content: EAP-TLS is a mutual authentication EAP method that can be used by the EAP peer and the EAP server to authenticate each other. It is specified in RFC 5216 [38] and draft-ietf-emu-eap-tls13 [76]. The 3GPP TLS protocol profile related to supported TLS versions and supported TLS cipher suites in 3GPP networks is specified in clause 6.2 of TS 33.210[ Network Domain Security (NDS); IP network layer security ]  [3]. The 3GPP profile of TLS certificates is specified in clause 6.1.3a of TS 33.310[ Network Domain Security (NDS); Authentication Framework (AF) ]  [5]. EAP-TLS supports several TLS versions, and the negotiation of the TLS version is part of EAP-TLS. The main principle of negotiation goes as follows. The EAP server indicates the support for EAP-TLS in the EAP-Request. If the peer chooses EAP-TLS, it responds with an EAP-Response indicating in the ClientHello message which TLS versions the peer supports. The EAP server chooses the TLS version, and indicates the chosen version in the ServerHello message. The TLS procedure described in the RFC 5216 [38] is applicable to TLS 1.2 defined in RFC 5246 [40]. The TLS procedure described in the draft-ietf-emu-eap-tls13 [76] is applicable to TLS 1.3 defined in RFC 8446 [77]. The procedure below is based on the unified authentication framework from the present document, procedures from TS 23.502[ Procedures for the 5G System (5GS) ]  [8] and RFC 5216 [38]. The procedure for EAP-TLS with TLS 1.2 is presented here as an example, and other potential procedures are possible, e.g. if TLS resumption is used. Figure B.2.1.1-1: Using EAP-TLS Authentication Procedures over 5G Networks for initial authentication 1. The UE sends the Registration Request message to the SEAF, containing SUCI. If the SUPI is in NAI format, only the username part of the NAI is encrypted using the selected protection scheme and included in the SUCI, together with the realm part in the NAI needed for UDM routing. Privacy considerations are described in Clause B.2.2. 2. The SEAF sends Nausf_UEAuthentication_Authenticate Request message to the AUSF. The SUCI and the serving network name (as described in clause 6.1.1.4) are included in the message. 3. AUSF sends the the Nudm_UEAuthentication_Get Request, containing SUCI and the serving network name, to UDM. The general rules for UDM selection apply. 4. The SIDF located within the UDM de-conceals the SUCI to SUPI if SUCI is received in the message. The UDM then selects the primary authentication method. 5. If the UDM chooses to use EAP-TLS, it sends the SUPI and an indicator to choose EAP-TLS to AUSF in the Nudm_UEAuthentication_Get Response. 6. With the received SUPI and the indicator, the AUSF chooses EAP-TLS as the authentication method. The AUSF sends thea Nausf_UEAuthentication_Authenticate Response message containing EAP-Request/EAP-TLS [TLS start] message to the SEAF. 7. The SEAF forwards the EAP-Request/EAP-TLS [TLS start] in the Authentication Request message to the UE. This message also includes the ngKSI and the ABBA parameter. In fact, the SEAF shall always include the ngKSI and ABBA parameter in all EAP-Authentication request message. ngKSI will be used by the UE and AMF to identify the partial native security context that is created if the authentication is successful. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. During an EAP authentication, the value of the ngKSI and the ABBA parameter sent by the SEAF to the UE shall not be changed. 8. After receiving the EAP-TLS [TLS-start] message from SEAF, the UE replies with an EAP-Response/EAP-TLS [client_hello] to the SEAF in the Authentication Response message. The contents of TLS client_hello are defined in the TLS specification of the TLS version in use. NOTE1: The EAP framework supports negotiation of EAP methods. If the UE does not support EAP-TLS, it should follow the rule described in RFC 3748 [27] to negotiate another EAP method. In 5G system, UDM typically knows which EAP method and credentials are supported by the subscriber, and consequently EAP based negotiation may never be used. 9. The SEAF forwards the EAP-Response/EAP-TLS [client hello] message to AUSF in the Nausf_UEAuthentication_Authenticate Request. 10. The AUSF replies to the SEAF with EAP-Request/EAP-TLS in the Nausf_UEAuthentication_Authenticate Response, which further includes information elements such as server_hello, server_certificate, server_key_exchange, certificate_request, server_hello_done. These information elements are defined in the RFCs for the corresponding TLS version in use. 11. The SEAF forwards the EAP-Request/EAP-TLS message with server_hello and other information elements to the UE through Authentication Request message. This message also includes the ngKSI and the ABBA parameter. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. 12. The UE authenticates the server with the received message from step 11. NOTE 2: The UE is required to be pre-configured with a UE certificate and also certificates that can be used to verify server certificates. 13. If the TLS server authentication is successful, then the UE replies with EAP-Response/EAP-TLS in Authentication Response message, which further contains information element such as client_certificate, client_key_exchange, client_certificate_verify, change_cipher_spec, client_finished etc. Privacy considerations are described in Clause B.2.1.2. 14. The SEAF forwards the message with EAP-Response/EAP-TLS message with client_certificate and other information elements to the AUSF in the Nausf_UEAuthentication_Authenticate Request. 15. The AUSF authenticates the UE based on the message received. The AUSF verifies that the client certificate provided by the UE belongs to the subscriber identified by the SUPI. If there is a miss-match in the subscriber identifiers in the SUPI, the AUSF does not accept the client certificate. If the AUSF has successfully verified this message, the AUSF continues to step 16, otherwise it returns an EAP-failure. NOTE 2: The AUSF is required to be pre-configured with the root or any intermediary CA certificates that can be used to verify UE certificates. Deployment of certificate revocation lists (CRLs) and online certificate status protocol (OCSP) are described in clause B.2.2. 16. The AUSF sends EAP-Request/EAP-TLS message with change_cipher_spec and server_finished to the SEAF in the Nausf_UEAuthentication_Authenticate Response. 17. The SEAF forwards EAP-Request/EAP-TLS message from step 16 to the UE with Authentication Request message. This message also includes the ngKSI and the ABBA parameter. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. 18. The UE sends an empty EAP-TLS message to the SEAF in Authentication Response message. 19. The SEAF further forwards the EAP-Response/EAP-TLS message to the AUSF in the Nausf_UEAuthentication_Authenticate Request. 20. The AUSF uses the most significant 256 bits of EMSK as the KAUSF and then calculates KSEAF from KAUSF as described in Annex A.6. The AUSF sends an EAP-Success message to the SEAF together with the SUPI and the derived anchor key in the Nausf_UEAuthentication_Authenticate Response. 21. The SEAF forwards the EAP-Success message to the UE and the authentication procedure is finished. This message also includes the ngKSI and the ABBA parameter. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. Then the SEAF derives the KAMF from the KSEAF, the ABBA parameter and the SUPI according to Annex A.7, and provides the ngKSI and the KAMF to the AMF. On receiving the EAP-Success message, the UE derives EMSK and uses the most significant 256 bits of the EMSK as the KAUSF and then calculates KSEAF in the same way as the AUSF. The UE derives the KAMF from the KSEAF, the ABBA parameter and the SUPI according to Annex A.7. NOTE 3: Step 21 could be NAS Security Mode Command or Authentication Result. NOTE 4: The ABBA parameter is included to enable the bidding down protection of security features that may be introduced later. NOTE 5: As an implementation option, the UE creates the temporary security context as described in step 21 after receiving the EAP message that allows EMSK to be calculated. The UE turns this temporary security context into a partial security context when it receives the EAP Success. The UE removes the temporary security context if the EAP authentication fails.