Using EAP-TLS with TLS 1.3

Using EAP-TLS with TLS 1.3 Ericsson

Stockholm 164 40 Sweden john.mattsson@ericsson.com

Ericsson

Jorvas 02420 Finland mohit@piuha.net

Network Working Group This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security, privacy, and reduced latency when compared to earlier versions of TLS. This document updates RFC 5216.

The Extensible Authentication Protocol (EAP), defined in , provides a standard mechanism for support of multiple authentication methods. EAP-Transport Layer Security (EAP-TLS) specifies an EAP authentication method with certificate-based mutual authentication and key derivation utilizing the TLS handshake protocol for cryptographic algorithms and protocol version negotiation, mutual authentication, and establishment of shared secret keying material. EAP-TLS is widely supported for authentication in IEEE 802.11 networks (Wi-Fi) using IEEE 802.1X and it's the default mechanism for certificate based authentication in MulteFire and 3GPP 5G networks. EAP-TLS references TLS 1.0 and TLS 1.1 , but works perfectly also with TLS 1.2 . Weaknesses found in previous versions of TLS, as well as new requirements for security, privacy, and reduced latency has led to the development of TLS 1.3 , which in large parts is a complete remodeling of the TLS handshake protocol including a different message flow, different handshake messages, different key schedule, different cipher suites, different resumption, and different privacy protection. This means that significant parts of the normative text in the previous EAP-TLS specification are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, aspects such as resumption, privacy handling, and key derivation need to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). This document defines how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is used with older versions of TLS. While this document updates EAP-TLS , it remains backwards compatible with it and existing implementations of EAP-TLS. This document only describes differences compared to . In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. When EAP-TLS is used with support for privacy, TLS 1.3 requires two fewer round-trips. TLS 1.3 also introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts used in EAP-TLS and TLS 1.3 .

TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, much of Section 2.1 of RFC5216 does not apply for TLS 1.3 (or higher). After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in the conversation will continue with the TLS handshake protocol encapsulated in the data fields of EAP-Response and EAP-Request packets. When EAP-TLS is used with TLS version 1.3 or higher, the formatting and processing of the TLS handshake SHALL be done as specified in that version of TLS. This document only lists additional and different requirements, restrictions, and processing compared to and . The EAP server MUST authenticate with a certificate and SHOULD require the EAP peer to authenticate with a certificate. Certificates can be of any type supported by TLS including raw public keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except for resumption. SessionID is deprecated in TLS 1.3 and the EAP server SHALL ignore the legacy_session_id field if TLS 1.3 is negotiated. Resumption is handled as described in . After the TLS handshake has completed, the EAP server sends EAP-Success. As stated in , the TLS cipher suite shall not be used to protect application data. This applies also for early application data. When EAP-TLS is used with TLS 1.3, early application data SHALL NOT be used. In the case where EAP-TLS with mutual authentication is successful, the conversation will appear as shown in . The EAP server commits to not send any more handshake messages by sending an empty TLS record, see .

EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=EAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS CertificateRequest, TLS Certificate, TLS CertificateVerify, TLS Finished, <-------- TLS empty record) EAP-Response/ EAP-Type=EAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> <-------- EAP-Success ]]> When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support of resumption in the initial authentication. To indicate support of resumption, the EAP server sends a NewSessionTicket message (containing a PSK and other parameters) after it has received the Finished message. In the case where EAP-TLS with mutual authentication and ticket establishment is successful, the conversation will appear as shown in .

TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange. When EAP-TLS is used with TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism compatible with that version of TLS. For TLS 1.3, resumption is described in Section 2.2 of . If the client has received a NewSessionTicket message from the server, the client can use the PSK identity received in the ticket to negotiate the use of the associated PSK. If the server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake. It is left up to the EAP peer whether to use resumption, but a EAP peer SHOULD use resumption as long as it has a valid ticket cached. It is RECOMMENDED that the EAP server accept resumption as long as the ticket is valid. However, the server MAY choose to require a full authentication. A subsequent authentication using resumption, where both sides authenticate successfully is shown in .

EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=EAP-TLS (TLS ServerHello, TLS EncryptedExtensions, TLS Finished, <-------- TLS empty record) EAP-Response/ EAP-Type=EAP-TLS (TLS Finished) --------> <-------- EAP-Success ]]> As specified in Section 2.2 of , the EAP peer SHOULD supply a "key_share" extension when offering resumption, which allows the EAP server to decline resumption and continue the handshake as a full handshake. The message flow in this case is given by or . If the EAP peer did not supply a "key_share" extension when offering resumption, the EAP server needs to reject the ClientHello and the EAP peer needs to restart a full handshake. The message flow in this case is given by followed by or .

TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, some normative text in Section 2.1.3 of RFC 5216 does not apply for TLS 1.3 or higher. The two paragraphs below replaces the corresponding paragraphs in Section 2.1.3 of RFC 5216 when EAP-TLS is used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of RFC 5216 still apply with the exception that SessionID is deprecated. If the EAP server authenticates successfully the EAP peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing TLS records confirming the processing in the version of TLS used. If the EAP peer authenticates successfully the EAP server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records confirming to the processing in the version of TLS used. The message flow ends with the EAP server sending a EAP-Success message. In the case where the server rejects the ClientHello, the conversation will appear as shown in .

EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Alert Message) EAP-Response/ EAP-Type=EAP-TLS --------> <-------- EAP-Failure ]]> In the case where server authentication is unsuccessful, the conversation will appear as shown in .

TLS 1.3 significantly improves privacy when compared to earlier versions of TLS by forbidding cipher suites without confidentiality and encrypting large parts of the TLS handshake including the certificate messages. EAP-TLS peer and server implementations supporting TLS 1.3 or higher MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 in ) and the client MUST confidentiality protect its identity (e.g. using Anonymous NAIs) when the EAP-TLS server is known to support TLS 1.3 or higher. As the certificate messages in TLS 1.3 are encrypted, there is no need to send an empty certificate_list or perform a second handshake (as needed by EAP-TLS with earlier versions of TLS). When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer and EAP-TLS server SHALL follow the processing specified by the used version of TLS. For TLS 1.3 this means that the EAP-TLS peer only sends an empty certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server MAY treat an empty certificate_list as a terminal condition. When EAP-TLS is used with TLS 1.3 and privacy, no extra round-trips are added and the message flow looks just like a normal message flow with the only difference that an anonymous NAI is used. In the case where EAP-TLS with mutual authentication and privacy is successful, the conversation will appear as shown in .

Including ContentType and ProtocolVersion a single TLS record may be up to 16387 octets in length. Some EAP implementations and access networks may limit the number of EAP packet exchanges that can be handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes of client, server, and trust anchor certificates small and the length of the certificate chains short. It addition, it is RECOMMENDED to use mechanisms that reduce the sizes of Certificate messages. While Elliptic Curve Cryptography (ECC) was optional for earlier version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of ). To avoid fragmentation, the use of ECC in certificates, signature algorithms, and groups are RECOMMENDED when using EAP-TLS with TLS 1.3 or higher. At a 128-bit security level, this reduces public key sizes from 384 bytes (RSA and DHE) to 32 bytes (ECDHE) and signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA). An EAP-TLS deployment MAY further reduce the certificate sizes by limiting the number of Subject Alternative Names. Endpoints SHOULD reduce the sizes of Certificate messages by omitting certificates that the other endpoint is known to possess. When using TLS 1.3, all certificates that specifies a trust anchor may be omitted (see Section 4.4.2 of ). When using TLS 1.2 or earlier, only the self-signed certificate that specifies the root certificate authority may be omitted (see Section 7.4.2 of ). EAP-TLS peers and servers SHOULD support and use the Cached Information Extension as specified in . EAP-TLS peers and servers MAY use other extensions for reducing the sizes of Certificate messages, e.g. certificate compression .

No updates to .

TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier versions of TLS with HKDF and completely changes the Key Schedule. The key hierarchies shown in Section 2.3 of are therefore not correct when EAP-TLS is used with TLS version 1.3 or higher. For TLS 1.3 the key schedule is described in Section 7.1 of . When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, IV, and Method-Id SHALL be derived from the exporter_master_secret using the TLS exporter interface (for TLS 1.3 this is defined in Section 7.5 of ).

By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation without having to extract the Master Secret, ClientHello.random, and ServerHello.random in a non-standard way. All other parameters such as MSK and EMSK are derived as specified in EAP-TLS , Section 2.3. The use of these keys is specific to the lower layer, as described .

TLS 1.3 cipher suites are defined differently than in earlier versions of TLS (see Section B.4 of ), and the cipher suites discussed in Section 2.4 of can therefore not be used when EAP-TLS is used with TLS version 1.3 or higher. The requirements on protocol version and compression given in Section 2.4 of still apply. When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS peers and servers MUST comply with the requirements for the TLS version used. For TLS 1.3 the compliance requirements are defined in Section 9 of .

TLS 1.3 introduces Post-Handshake messages. These Post-Handshake messages use the handshake content type and can be sent after the main handshake. One such Post-Handshake message is NewSessionTicket. The NewSessopmTicket can be used for resumption. After sending TLS Finished, the EAP server may send any number of Post-Handshake messages in separate EAP-Requests. To decrease the uncertainty for the EAP peer, the following procedure MUST be followed: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by appending an empty application data record (i.e. a TLS record with TLSPlaintext.type = application_data and TLSPlaintext.length = 0) to the last handshake record. After sending an empty application data record, the EAP server may only send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message. Note that the use of an empty application data record does not violate the requirement that the TLS cipher suite shall not be used to protect application data, as the application data is the empty string, no application data is protected.

No updates to .

This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the EAP-TLS 1.3 protocol in accordance with . This memo requires IANA to add the following labels to the TLS Exporter Label Registry defined by . These labels are used in derivation of Key_Material, IV and Method-Id as defined in : "EXPORTER_EAP_TLS_Key_Material" "EXPORTER_EAP_TLS_IV" "EXPORTER_EAP_TLS_Method-Id"

Using EAP-TLS with TLS 1.3 does not change the security claims for EAP-TLS as given in Section 4.1 of . However, it strengthens several of the claims as described in the following updates to the notes given in Section 4.1 of . [2] Confidentiality: The TLS 1.3 handshake offers much better confidentiality than earlier versions of TLS by mandating cipher suites with confidentiality and encrypting certificates and some of the extensions, see . When using EAP-TLS with TLS 1.3, the use of privacy does not cause any additional round-trips. [3] Key strength: TLS 1.3 forbids all algorithms with known weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 only supports cryptographic algorithms offering at least 112-bit security, see . [4] Cryptographic Negotiation: TLS 1.3 increases the number of cryptographic parameters that are negotiated in the handshake. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF hash algorithm, key exchange groups, and signature algorithm, see Section 4.1.1 of .

No updates to .

The OCSP status handling in TLS 1.3 is different from earlier versions of TLS, see Section 4.4.2.1 of . In TLS 1.3 the OCSP information is carried in the CertificateEntry containing the associated certificate instead of a separate CertificateStatus message as in . This enables sending OCSP information for all certificates in the certificate chain. EAP-TLS peers and servers supporting TLS 1.3 SHOULD support Certificate Status Requests (OCSP stapling) as specified in and Section 4.4.2.1 of . The use of Certificate Status Requests to determine the current status of the EAP server's certificate is RECOMMENDED.

No updates to .

suggests that the privacy considerations of IETF protocols be documented. TLS 1.3 offers much better privacy than earlier versions of TLS as discussed in . In this section, we only discuss the privacy properties of EAP-TLS with TLS 1.3. For privacy properties of TLS 1.3 itself, see . EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in EAP packets. Additionally, the EAP peer sends an identity in the first EAP-Response. The fields in the EAP-TLS Request and the EAP-TLS Response packets do not contain any cleartext privacy sensitive information. It is strongly RECOMMENDED to confidentiality protect the identity (e.g. using Anonymous NAIs), as the username part of the NAI may otherwise enable identification and tracking of the user. However, as with other EAP methods, even when privacy-friendly identifiers or EAP tunneling is used, the domain name (i.e. the realm) in the NAI is still typically visible. How much privacy sensitive information the domain name leaks is highly dependent on how many other users are using the same domain name in the particular access network. If all EAP peers have the same domain, no additional information is leaked. If a domain name is used by a small subset of the EAP peers, it may aid an attacker in tracking or identifying the user. An EAP peer with a policy allowing communication with EAP servers supporting only TLS 1.2 (or lower) without privacy and with RSA key exchange is vulnerable to disclosure of the peer username. An active attacker can in this case make the EAP peer believe that an EAP server supporting TLS 1.3 does not support privacy. The attacker can simply impersonate the EAP server and negotiate TLS 1.2 (or lower)with RSA key exchange and send an TLS alert message when the EAP peer tries to use privacy by sending an empty certificate message. Since the attacker (impersonating the EAP server) does not provide a proof-of-possession of the private key until the Finished message when RSA key exchange is used, an EAP peer may inadvertently disclose its identity (username) to an attacker. Therefore, it is RECOMMENDED for EAP peers to not use EAP-TLS with TLS 1.2 (or lower) and RSA based ciphersuites without privacy.

As required by , work on IETF protocols needs to consider the effects of pervasive monitoring and mitigate them when possible. Pervasive Monitoring is widespread surveillance of users. By encrypting more information, TLS 1.3 offers much better protection against pervasive monitoring. In addition to the privacy attacks discussed above, surveillance on a large scale may enable tracking of a user over a wider geographical area and across different access networks. Using information from EAP-TLS together with information gathered from other protocols increases the risk of identifying individual users.

IEEE Standard for Local and metropolitan area networks -- Port-Based Network Access Control Institute of Electrical and Electronics Engineers IEEE Standard for Information technology—Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Institute of Electrical and Electronics Engineers Security architecture and procedures for 5G System 3GPP MulteFire Release 1.0.1 specification MulteFire

All the following references in are updated as specified below when EAP-TLS is used with TLS 1.3 or higher. All references to are updated with . All references to are updated with . All references to are updated with .

The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba, Eric Rescorla, Jari Arkko, Jim Schaad, Jouni Malinen, and Vesa Torvinen for comments and suggestions on the draft.