RFC 9190

EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3

📅 published February 2022, from ietf

RFC 9190: EAP-TLS 1.3 🎀

Okay bestie, let's get the paperwork out of the way first ✨ This is RFC 9190, titled EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3. It was written by J. Preuß Mattsson and M. Sethi, both from Ericsson, and it's a Standards Track document dated February 2022. Its ISSN is 2070-1721. The big news is that it updates RFC 5216 💅 The title block doesn't list anything it obsoletes.

Abstract 🌸

So the Extensible Authentication Protocol (EAP), which is defined in RFC 3748, gives us a standard way to support lots of different authentication methods 🦋 This document says how to use EAP-TLS with TLS 1.3 while still playing nicely with existing EAP-TLS implementations. TLS 1.3 is a huge upgrade with much better security, privacy, and reduced latency compared to older TLS versions.

EAP-TLS with TLS 1.3 (called EAP-TLS 1.3) goes even further 🔥 It always provides forward secrecy, never reveals the peer identity, and makes revocation checking mandatory, all compared to EAP-TLS with earlier TLS versions. The document also gives guidance on authentication, authorization, and resumption for EAP-TLS in general, no matter which TLS version is underneath. And yes, it updates RFC 5216.

Status of This Memo

This is an Internet Standards Track document 🎀

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841.

For the current status of this document, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9190.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License.

Table of Contents 🧚

1.  Introduction
  1.1.  Requirements and Terminology
2.  Protocol Overview
  2.1.  Overview of the EAP-TLS Conversation
    2.1.1.  Authentication
    2.1.2.  Ticket Establishment
    2.1.3.  Resumption
    2.1.4.  Termination
    2.1.5.  No Peer Authentication
    2.1.6.  Hello Retry Request
    2.1.7.  Identity
    2.1.8.  Privacy
    2.1.9.  Fragmentation
  2.2.  Identity Verification
  2.3.  Key Hierarchy
  2.4.  Parameter Negotiation and Compliance Requirements
  2.5.  EAP State Machines
3.  Detailed Description of the EAP-TLS Protocol
4.  IANA Considerations
5.  Security Considerations
  5.1.  Security Claims
  5.2.  Peer and Server Identities
  5.3.  Certificate Validation
  5.4.  Certificate Revocation
  5.5.  Packet Modification Attacks
  5.6.  Authorization
  5.7.  Resumption
  5.8.  Privacy Considerations
  5.9.  Pervasive Monitoring
  5.10. Discovered Vulnerabilities
  5.11. Cross-Protocol Attacks
6.  References
  6.1.  Normative References
  6.2.  Informative references
Appendix A.  Updated References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction ✨

EAP, defined in [RFC3748], gives us a standard mechanism for supporting multiple authentication methods 💖 EAP-TLS [RFC5216] is an EAP authentication method that does certificate-based mutual authentication. It uses the TLS handshake protocol to handle cryptographic algorithms, protocol version negotiation, and establishing shared secret keying material.

EAP-TLS is widely supported for authentication and key establishment in IEEE 802.11 [IEEE-802.11] (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec) networks that use IEEE 802.1X [IEEE-802.1X]. It's also the default mechanism for certificate-based authentication in 3GPP 5G [TS.33.501] and MulteFire [MulteFire] networks 🌈 Lots of other EAP methods depend on TLS and EAP-TLS too, including Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851], Tunneled Transport Layer Security (EAP-TTLS) [RFC5281], the Tunnel Extensible Authentication Protocol (TEAP) [RFC7170], and vendor-specific methods like the Protected Extensible Authentication Protocol (PEAP) [PEAP].

EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346], but it can also work with TLS 1.2 [RFC5246]. TLS 1.0 and 1.1 are formally deprecated, and they are prohibited from being negotiated or used [RFC8996] 🙈 Weaknesses in TLS 1.2, plus new requirements for security, privacy, and reduced latency, led to TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is basically a full remodel of the TLS handshake protocol. It has a different message flow, different handshake messages, a different key schedule, different cipher suites, a different resumption mechanism, different privacy protection, and different record padding. So a lot of the normative text in the older EAP-TLS spec [RFC5216] doesn't apply anymore. That means resumption, privacy handling, and key derivation all need proper handling for EAP-TLS with TLS 1.3 👑

This document updates [RFC5216] to define how to use EAP-TLS with TLS 1.3. When older TLS versions get negotiated, RFC 5216 still applies so backwards compatibility is maintained. This document does add extra guidance on authentication, authorization, and resumption for EAP-TLS, regardless of which TLS version is used. It only describes the differences compared to [RFC5216]. When EAP-TLS is used with TLS 1.3, some references get updated as specified in Appendix A. All message flows are example message flows specific to TLS 1.3, and they don't apply to TLS 1.2 🦋

Here's the important bit. EAP-TLS couples the TLS handshake state machine with the EAP state machine, so new TLS versions could cause incompatibilities. Those can lead to failures or security issues if they aren't carefully integrated into EAP-TLS. That's why implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. ⚠️

This document specifies EAP-TLS 1.3 and does not specify how other TLS-based EAP methods use TLS 1.3. That job is left to other documents such as [TLS-EAP-TYPES] 🧚

Now for the perks ✨ Privacy, which in EAP-TLS means no information about the underlying peer identity is disclosed, is mandatory here and gets achieved without any extra round trips. Revocation checking is also mandatory, and it's simplified with Online Certificate Status Protocol (OCSP) stapling. On top of that, TLS 1.3 gives more ways to reduce fragmentation compared to earlier versions of TLS. It's giving efficiency 💅

1.1. Requirements and Terminology

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀

Readers are expected to already know the terms and concepts from EAP-TLS [RFC5216] and TLS [RFC8446], so no pressure but go read those first 🙈 The term EAP-TLS peer refers to the entity acting as the EAP peer and TLS client. The term EAP-TLS server refers to the entity acting as the EAP server and TLS server.

This document follows the terminology from [TLS-bis], where the master secret gets renamed to the main secret and the exporter_master_secret gets renamed to the exporter_secret. Name changes, iykyk 🌸

2. Protocol Overview 🦋

2.1. Overview of the EAP-TLS Conversation

This section updates Section 2.1 of [RFC5216] by amending it in accordance with the following discussion 💖

If the TLS implementation correctly implements TLS version negotiation, EAP-TLS will automatically leverage that capability. The EAP-TLS implementation needs to know which version of TLS was negotiated, because that's how it correctly supports EAP-TLS 1.3 and still maintains backward compatibility with EAP-TLS 1.2 🧠

TLS 1.3 changes both the message flow and the handshake messages compared to earlier TLS versions. So much of Section 2.1 of [RFC5216] simply doesn't apply to TLS 1.3. Except for Sections 2.2 and 5.7, this update only applies when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, [RFC5216] applies 🌈

TLS 1.3 introduces several new handshake messages, including HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general, the underlying TLS libraries handle these, and they aren't visible to EAP-TLS. Still, there are a few things to note 👀

  • The HelloRetryRequest is used by the server to reject the parameters offered in the ClientHello and suggest new parameters. When this message shows up, it increases the number of round trips used by the protocol.
  • The NewSessionTicket message is used to convey resumption information and is covered in Sections 2.1.2 and 2.1.3.
  • The KeyUpdate message is used to update the traffic keys used on a TLS connection. EAP-TLS doesn't encrypt significant amounts of data, so this functionality isn't needed. Implementations SHOULD NOT send this message; however, some TLS libraries may automatically generate and process it 🙃
  • Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT send an early_data extension, and clients MUST NOT send an EndOfEarlyData message 🚫
  • Post-handshake authentication MUST NOT be used in EAP-TLS. Clients MUST NOT send a "post_handshake_auth" extension, and servers MUST NOT request post-handshake client authentication 🚫

After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in [RFC5216], the conversation continues 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, the formatting and processing of the TLS handshake SHALL be done as specified in version 1.3 of TLS. This update only lists additional and different requirements, restrictions, and processing compared to [RFC8446] and [RFC5216] 🎀

2.1.1. Authentication ✨

This section updates Section 2.1.1 of [RFC5216] by amending it in accordance with the following discussion. 💅

Okay bestie, the EAP-TLS server MUST authenticate with a certificate 🔐, and it SHOULD require the EAP-TLS peer to authenticate with a certificate too. Certificates can be any type TLS supports, raw public keys included 🗝️. Pre-Shared Key (PSK) authentication SHALL NOT be used except for resumption 🙅‍♀️, so no PSK drama outside of resumption, periodt.

The full handshake in EAP-TLS with TLS 1.3 always gives you forward secrecy 🔥. It does this by exchanging ephemeral key_share extensions in the ClientHello and ServerHello (for example, containing Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) public keys). SessionID is deprecated in TLS 1.3, so see Sections 4.1.2 and 4.1.3 of [RFC8446] 📖.

TLS 1.3 brought in early application data, and like all application data (other than the protected success indication we'll get to below), it is not used in EAP-TLS 🙅‍♀️. If you're curious about the early_data extension, check Section 4.2.10 of [RFC8446] 🧚. Resumption is handled as described in Section 2.1.3 🌸.

Now the protected success indication 🎀, which comes from [RFC3748]. The EAP-TLS server always sends TLS application data 0x00, see Section 2.5 for the details. Here's a plot twist 🙈: a TLS implementation MAY not allow the EAP-TLS layer to control the order things are sent in, so the application data MAY therefore be sent before a NewSessionTicket. That means TLS application data 0x00 is to be interpreted as success after the EAP-Request that contains TLS application data 0x00. Once the EAP-TLS server has sent an EAP-Request containing TLS application data 0x00 and received an EAP-Response packet of EAP-Type=EAP-TLS with no data, the EAP-TLS server sends EAP-Success 🎉.

Figure 1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication. Neither HelloRetryRequest nor post-handshake messages are sent in this one 🫶.

    EAP-TLS Peer                                      EAP-TLS Server

                                                         EAP-Request/
                                <--------                   Identity
    EAP-Response/
    Identity (Privacy-Friendly) -------->
                                                         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)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Certificate,
    TLS CertificateVerify,
    TLS Finished)               -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                <-------- (TLS Application Data 0x00)
    EAP-Response/
    EAP-Type=EAP-TLS            -------->
                                <--------                EAP-Success

Figure 1: EAP-TLS Mutual Authentication

2.1.2. Ticket Establishment 🎟️

This is a new section when compared to [RFC5216] 🌈.

To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS server MUST send one or more post-handshake NewSessionTicket messages in the initial authentication. Each one is associated with a PSK, a PSK identity, a ticket lifetime, and other parameters 💜. Note that TLS 1.3 [RFC8446] limits the ticket lifetime to a maximum of 604800 seconds (7 days), and EAP-TLS servers MUST respect this upper limit when issuing tickets ⏳.

The NewSessionTicket is sent after the EAP-TLS server has received the client Finished message in the initial authentication. It can go out in the same flight as the TLS server Finished or later 🦋. The PSK tied to the ticket depends on the client Finished, so it can't be pre-computed to be sent in the same flight as the TLS server Finished when client authentication is happening 🙃.

The NewSessionTicket message MUST NOT include an early_data extension 🚫. If the early_data extension is received, it MUST be ignored 🙈. Servers should take into account that fewer NewSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario. In most cases, a single NewSessionTicket will be sufficient ✨.

There's also a mechanism that lets clients say how many tickets they want for future connections. It's defined in [TICKET-REQUESTS] 🍓.

Figure 2 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication and ticket establishment of a single ticket 💖.

    EAP-TLS Peer                                      EAP-TLS Server

                                                         EAP-Request/
                                <--------                   Identity
    EAP-Response/
    Identity (Privacy-Friendly) -------->
                                                         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)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Certificate,
    TLS CertificateVerify,
    TLS Finished)               -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                               (TLS NewSessionTicket,
                                <-------- (TLS Application Data 0x00)
    EAP-Response/
    EAP-Type=EAP-TLS            -------->
                                <--------                EAP-Success

Figure 2: EAP-TLS Ticket Establishment

2.1.3. Resumption ✨

Okay bestie, this section updates Section 2.1.2 of [RFC5216] 🎀 by amending it with the discussion below 💅

EAP-TLS usually comes with client authentication 🔐, and it usually chops the TLS flights into a whole bunch of EAP-requests and EAP-responses 😭. Resumption is the glow-up here 🌸 because it cuts down the number of round trips and lets the EAP-TLS server skip the database lookups it would need during a full handshake with client authentication. TLS 1.3 swapped out the session resumption mechanisms from earlier TLS versions for a brand-new PSK exchange ✨. So when EAP-TLS runs on TLS version 1.3, EAP-TLS SHALL use a resumption mechanism that's compatible with TLS 1.3 🦋.

For TLS 1.3, resumption is described in Section 2.2 of [RFC8446] 💜. If the client has received a NewSessionTicket message from the EAP-TLS server, it can use the PSK identity tied to that ticket to negotiate the associated PSK 🍓. If the EAP-TLS server accepts it, the resumed session is treated as authenticated and securely associated with the prior authentication or resumption 👑. Whether to resume is up to the EAP-TLS peer 🧚, but it is RECOMMENDED that the EAP-TLS peer resume if it has a valid ticket that has not been used before 🎀. Whether to accept resumption is left to the EAP-TLS server, but it is RECOMMENDED that the EAP-TLS server accept resumption if the ticket that was issued is still valid 🫶. The EAP-TLS server MAY choose to require a full handshake though 🙈. If a full handshake is required, the negotiation goes ahead as if the session were a new authentication, and the resumption attempt is ignored 💀. In that case, the requirements of Sections 2.1.1 and 2.1.2 apply in their entirety 📜. As described in Appendix C.4 of [RFC8446], reusing a ticket lets passive observers correlate different connections 👀. So EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking preventions in Appendix C.4 of [RFC8446] 🛡️.

It is RECOMMENDED to use Network Access Identifiers (NAIs) with the same realm during resumption and the original full handshake 🌈. This is what lets EAP packets get routed to the same destination as the original full handshake 🚚. If you don't follow this recommendation, resumption is likely impossible 😬. When NAI reuse can happen without privacy implications, it is RECOMMENDED to use the same NAI in the resumption as was used in the original full handshake [RFC7542] 💖. For example, the NAI @realm can safely be reused, since it doesn't give any specific info that would link a user's resumption attempt to the original full handshake 🍀. But reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm lets an on-path attacker associate a resumption attempt with the original full handshake 🚨. The TLS PSK identity is typically derived by the TLS implementation and may be an opaque blob without a routable realm 🫥. So the TLS PSK identity on its own is unsuitable as an NAI in the Identity Response 🙅‍♀️.

Figure 3 shows an example message flow for a later, successful EAP-TLS resumption handshake 🦋. Both sides authenticate with a PSK that was provisioned by an earlier NewSessionTicket, and the server provisions a single new ticket 🎁.

    EAP-TLS Peer                                      EAP-TLS Server

                                                         EAP-Request/
                                <--------                   Identity
    EAP-Response/
    Identity (Privacy-Friendly) -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                <--------                 (TLS Start)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS ClientHello
    + pre_shared_key)           -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                                    (TLS ServerHello,
                                             TLS EncryptedExtensions,
                                <--------               TLS Finished,
                                                TLS NewSessionTicket)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Finished)               -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                <-------- (TLS Application Data 0x00)
    EAP-Response/
    EAP-Type=EAP-TLS            -------->
                                <--------                EAP-Success

                        Figure 3: EAP-TLS Resumption

As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD supply a key_share extension when attempting resumption 🔑. That lets the EAP-TLS server potentially decline resumption and fall back to a full handshake 🔄. If the EAP-TLS peer didn't supply a key_share extension when attempting resumption, the EAP-TLS server needs to send a HelloRetryRequest to say more info is needed to finish the handshake 🙋‍♀️, and the EAP-TLS peer needs to send a second ClientHello with that info 📨. Supplying a key_share and using the psk_dhe_ke pre-shared key exchange mode also matters a lot for limiting the damage from a key compromise 🛡️. When using psk_dhe_ke, TLS 1.3 provides forward secrecy 🌟, which means that compromising the PSK used for resumption doesn't compromise any earlier connections 🧊. The psk_dh_ke key exchange mode MUST be used for resumption unless the deployment has a local requirement to allow configuration of other mechanisms 💅✨.

2.1.4. Termination

This section updates Section 2.1.3 of [RFC5216] by amending it in accordance with the following discussion.

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 [RFC5216] does not apply for TLS 1.3. The two paragraphs below replace the corresponding paragraphs in Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3. The other paragraphs in Section 2.1.3 of [RFC5216] still apply with the exception that SessionID is deprecated.

If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. The message flow ends with a protected success indication from the EAP-TLS server, followed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, followed by EAP-Success from the server.

If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used.

Figures 4, 5, and 6 illustrate message flows in several cases where the EAP-TLS peer or EAP-TLS server sends a TLS Error alert message. In earlier versions of TLS, error alerts could be warnings or fatal. In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are "close_notify" and "user_canceled", both of which indicate that the connection is not going to continue normally; see [RFC8446].

In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a fatal error condition. Failure to send TLS Error alerts means that the peer or server would have no way of determining what went wrong. EAP-TLS 1.3 strengthens this requirement. Whenever an implementation encounters a fatal error condition, it MUST send an appropriate TLS Error alert.

Figure 4 shows an example message flow where the EAP-TLS server rejects the ClientHello with an error alert. The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest; see Section 2.1.6.

EAP-TLS Peer EAP-TLS Server

EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Error Alert) EAP-Response/ EAP-Type=EAP-TLS --------> <-------- EAP-Failure

Figure 4: EAP-TLS Server Rejection of ClientHello

Figure 5 shows an example message flow where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS Error alert.

EAP-TLS Peer EAP-TLS Server

EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> 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) EAP-Response/ EAP-Type=EAP-TLS (TLS Error Alert) --------> <-------- EAP-Failure

Figure 5: EAP-TLS Unsuccessful EAP-TLS Server Authentication

Figure 6 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer fails to authenticate to the EAP-TLS server and the server sends a TLS Error alert.

EAP-TLS Peer EAP-TLS Server

EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> 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) EAP-Response/ EAP-Type=EAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Error Alert) EAP-Response/ EAP-Type=EAP-TLS --------> <-------- EAP-Failure

Figure 6: EAP-TLS Unsuccessful Client Authentication

2.1.5. No Peer Authentication

This is a new section when compared to [RFC5216].

Figure 7 shows an example message flow for a successful EAP-TLS full handshake without peer authentication (e.g., emergency services, as described in [RFC7406]).

EAP-TLS Peer EAP-TLS Server

EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> 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 Certificate, TLS CertificateVerify, <-------- TLS Finished) EAP-Response/ EAP-Type=EAP-TLS (TLS Finished) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Application Data 0x00) EAP-Response/ EAP-Type=EAP-TLS --------> <-------- EAP-Success

Figure 7: EAP-TLS without Peer Authentication

2.1.6. Hello Retry Request

This is a new section when compared to [RFC5216].

As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a HelloRetryRequest message in response to a ClientHello if the EAP-TLS server finds an acceptable set of parameters but the initial ClientHello does not contain all the needed information to continue the handshake. One use case is if the EAP-TLS server does not support the groups in the "key_share" extension (or there is no "key_share" extension) but supports one of the groups in the "supported_groups" extension. In this case, the client should send a new ClientHello with a "key_share" that the EAP-TLS server supports.

Figure 8 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication and HelloRetryRequest. Note the extra round trip as a result of the HelloRetryRequest.

EAP-TLS Peer EAP-TLS Server

EAP-Request/ <-------- Identity EAP-Response/ Identity (Privacy-Friendly) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS ClientHello) --------> EAP-Request/ EAP-Type=EAP-TLS (TLS HelloRetryRequest) <-------- 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) EAP-Response/ EAP-Type=EAP-TLS (TLS Certificate, TLS CertificateVerify, TLS Finished) --------> EAP-Request/ EAP-Type=EAP-TLS <-------- (TLS Application Data 0x00) EAP-Response/ EAP-Type=EAP-TLS --------> <-------- EAP-Success

Figure 8: EAP-TLS with Hello Retry Request

2.1.7. Identity ✨

okay so this is a brand-new section compared to [RFC5216], so pay attention bestie 👀🎀

It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity Response, because those identities are routable AND privacy-friendly 🦋 Opaque blobs are allowed by [RFC3748], but they're giving "not routable" energy, so such identities are NOT RECOMMENDED. They should only be considered in local deployments where the EAP-TLS peer, EAP authenticator, and EAP-TLS server all belong to the same network 🏠

Here's a fun one: many client certificates already contain an identity like an email address, which is basically already in NAI format 💌 When the client certificate has an NAI as its subject name or alternative subject name, an anonymous NAI SHOULD be derived from the NAI in the certificate. See Section 2.1.8 for the deets. More identity details live in Sections 2.1.3, 2.1.8, 2.2, and 5.8 🧚

2.1.8. Privacy 🙈

This section updates Section 2.1.4 of [RFC5216] by amending it in accordance with the following discussion.

EAP-TLS 1.3 is a huge privacy glow-up compared to earlier versions of EAP-TLS 💅 It forbids cipher suites without confidentiality, which means TLS 1.3 is always encrypting big chunks of the TLS handshake, including the certificate messages. Iconic 🔒

EAP-TLS peer and server implementations supporting TLS 1.3 MUST support anonymous Network Access Identifiers (NAIs) (Section 2.4 of [RFC7542]). A client supporting TLS 1.3 MUST NOT send its username (or any other permanent identifiers) in cleartext in the Identity Response (or any message used instead of the Identity Response). Not me sending my real name in plain text 💀

Following [RFC7542], it is RECOMMENDED to omit the username, so the NAI is just @realm. But other constructions are allowed too, like a fixed username such as anonymous@realm, or an encrypted username such as xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm 🦋 Just remember the NAI MUST be a UTF-8 string as defined by the grammar in Section 2.2 of [RFC7542]. No cap, that's a must-have ✨

The HelloRequest message that was used for privacy in EAP-TLS 1.2 does not exist in TLS 1.3. Since the certificate messages in TLS 1.3 are encrypted, there's no need to send an empty certificate_list and do a second handshake just for privacy (which EAP-TLS needed with earlier versions of TLS). When EAP-TLS is used with TLS version 1.3, the EAP-TLS peer and EAP-TLS server SHALL follow the processing specified by version 1.3 of TLS 🌸 That means the EAP-TLS peer only sends an empty certificate_list if it doesn't have an appropriate certificate to send, and the EAP-TLS server MAY treat an empty certificate_list as a terminal condition.

EAP-TLS with TLS 1.3 is ALWAYS used with privacy, and it doesn't add any extra round trips. The message flow with privacy is just the normal message flow, as shown in Figure 1 🧚‍♀️

2.1.9. Fragmentation 🧩

This section updates Section 2.1.5 of [RFC5216] by amending it in accordance with the following discussion.

Counting the ContentType (1 byte), ProtocolVersion (2 bytes), and length (2 bytes) headers, a single TLS record may be up to 16645 octets in length. EAP-TLS fragmentation support comes from adding a flags octet within the EAP-Response and EAP-Request packets, plus a (conditional) TLS Message Length field of four octets 🍓 Implementations MUST NOT set the L bit in unfragmented messages, but they MUST accept unfragmented messages with and without the L bit set. Both rules, no exceptions 🫶

Some EAP implementations and access networks may limit how many EAP packet exchanges they can handle. To avoid fragmentation, it is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and trust anchor certificates small, and to keep the certificate chains short. It is also RECOMMENDED to use mechanisms that reduce the sizes of Certificate messages. For a detailed discussion on reducing message sizes to prevent fragmentation, check out [RFC9191] 📚✨

2.2. Identity Verification 🕵️‍♀️

This section replaces Section 2.2 of [RFC5216] with the following discussion. The guidance here is relevant for EAP-TLS in general, no matter which underlying TLS version is used.

The EAP peer identity in the EAP-Response/Identity is NOT authenticated by EAP-TLS, bestie. So unauthenticated information MUST NOT be used for accounting purposes or to give authorization 🚫 The authenticator and the EAP-TLS server MAY examine the identity presented in EAP-Response/Identity for things like routing and EAP method selection. EAP-TLS servers MAY reject conversations if the identity doesn't match their policy. This applies to resumption too, so see Sections 2.1.3, 5.6, and 5.7.

The EAP server identity in the TLS server certificate is typically a fully qualified domain name (FQDN) in the SubjectAltName (SAN) extension. Since EAP-TLS deployments may use more than one EAP server, each with a different certificate, EAP peer implementations SHOULD allow for configuring one or more trusted root certificates (CA certificate) to authenticate the server certificate. They should also allow for one or more server names to match against the SubjectAltName (SAN) extension in the server certificate. If any configured name matches any name in the SAN extension, then the name check passes ✅ To make matching easier, an EAP-TLS deployment can assign a name to represent an authorized EAP server, and EAP Server certificates can include that name in the list of SANs for each certificate representing an EAP-TLS server.

If server name matching isn't used, the confidence that the EAP server is authoritative for the given network gets weaker 📉 And if name matching isn't used with a public root CA, then effectively ANY server can obtain a certificate that will be trusted for EAP authentication by the peer. Yikes 😭 While this domain name verification guidance is new (it wasn't mentioned in [RFC5216]), it has been widely implemented in EAP-TLS peers. So it's believed that this section contains minimal new interoperability or implementation requirements on EAP-TLS peers, and it can be applied to earlier versions of TLS too 🌈

Configuring a root CA certificate and a server name is non-trivial, so automated methods of provisioning are RECOMMENDED 🤖 For example, the eduroam federation [RFC7593] provides a Configuration Assistant Tool (CAT) to automate the configuration process. Without a trusted root CA certificate (user configured or system-wide), EAP peers MAY implement a trust on first use (TOFU) mechanism, where the peer trusts and stores the server certificate during the first connection attempt. The EAP peer then makes sure the server presents the same stored certificate on later interactions.

TOFU is a bit of a risky vibe. Using it doesn't allow the server certificate to change without out-of-band validation of the certificate, so it's not suitable for many deployments, including ones where multiple EAP servers are deployed for high availability. TOFU mechanisms increase the susceptibility to traffic interception attacks, so they should only be used if there are adequate controls in place to mitigate this risk 🚨

2.3. Key Hierarchy 🔑

This section updates Section 2.3 of [RFC5216] by replacing it in accordance with the following discussion.

TLS 1.3 replaces the TLS pseudorandom function (PRF) from earlier versions of TLS with the HMAC-based Key Derivation Function (HKDF), and it completely changes the key schedule 🔄 That means the key hierarchies shown in Section 2.3 of [RFC5216] are NOT correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3, the key schedule is described in Section 7.1 of [RFC8446].

When EAP-TLS is used with TLS version 1.3, the Key_Material and Method-Id SHALL be derived from the exporter_secret using the TLS exporter interface [RFC5705] (for TLS 1.3, this is defined in Section 7.5 of [RFC8446]) ✨ Type is the value of the EAP Type field defined in Section 2 of [RFC3748]. For EAP-TLS, the Type field has the value 0x0D.

Type = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
                            Type, 128)
Method-Id    = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
                            Type, 64)
Session-Id   = Type || Method-Id

The MSK and EMSK are derived from the Key_Material in the same way as with EAP-TLS [RFC5216], Section 2.3. Here are the definitions repeated for simplicity:

MSK          = Key_Material(0, 63)
EMSK         = Key_Material(64, 127)

Other TLS-based EAP methods can use the TLS exporter in a similar fashion. See [TLS-EAP-TYPES] 📖

[RFC5247] deprecates the use of an Initialization Vector (IV), so RECV-IV and SEND-IV are NOT exported in EAP-TLS with TLS 1.3 🙅‍♀️ As noted in [RFC5247], lower layers use the MSK in a lower-layer-dependent manner. EAP-TLS with TLS 1.3 exports the MSK and does not specify how lower layers use it.

Note that the key derivation MUST use the length values given above 🧮 In TLS 1.2 and earlier, it was possible to truncate the output by requesting less data from the TLS-Exporter function, but that practice is not possible with TLS 1.3. If an implementation intends to use only a part of the output of the TLS-Exporter function, then it MUST ask for the full output and then only use the desired part. Skip this and you'll calculate incorrect values for the keying material above 😬

By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation that provides a public API for the exporter 🧩 Also, when TLS 1.2 is used with the EAP-TLS exporter [RFC5705], it generates the same key material as in EAP-TLS [RFC5216] 💜

2.4. Parameter Negotiation and Compliance Requirements 📋

This section updates Section 2.4 of [RFC5216] by amending it in accordance with the following discussion.

TLS 1.3 cipher suites are defined differently than in earlier versions of TLS (see Appendix B.4 of [RFC8446]), so the cipher suites discussed in Section 2.4 of [RFC5216] can NOT be used when EAP-TLS is used with TLS version 1.3 🙃

When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory-to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. In EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL be supported 🔐

While EAP-TLS doesn't protect any application data except for the 0x00 byte that serves as the protected success indication, the negotiated cipher suites and algorithms MAY be used to secure data, as done in other TLS-based EAP methods 🦋

2.5. EAP State Machines

Okay bestie, this section is brand new compared to [RFC5216] 💅 and it only applies to TLS 1.3 ✨. [RFC4137] has a proposed state machine for EAP, which is very textbook of it 📚.

TLS 1.3 [RFC8446] brings in post-handshake messages 🦋. They use the handshake content type and can show up after the main handshake is done. Examples are NewSessionTicket, which is the one used for resumption 🎀, and KeyUpdate, which is not useful and not expected in EAP-TLS 🙈. After sending TLS Finished, the EAP-TLS server may send any number of post-handshake messages in one or more EAP-Requests.

To give a protected success result indication and to decrease the uncertainty for the EAP-TLS peer 🫶, the following procedure MUST be followed:

When an EAP-TLS server has successfully processed the TLS client Finished and sent its last handshake message (Finished or a post-handshake message), it sends an encrypted TLS record with application data 0x00 ✨. That encrypted record is a protected success result indication, as defined in [RFC3748] 💖. After sending an EAP-Request that contains the protected success result indication, the EAP-TLS server must not send any more EAP-Requests and may only send an EAP-Success. The EAP-TLS server MUST NOT send an encrypted TLS record with application data 0x00 before it has successfully processed the client Finished and sent its last handshake message 🚫.

TLS Error alerts SHOULD be considered a failure result indication, as defined in [RFC3748] 🥀. Implementations following [RFC4137] set the alternate indication of failure variable altReject after sending or receiving an error alert. After sending or receiving a TLS Error alert, the EAP-TLS server may only send an EAP-Failure. Protected TLS Error alerts are protected failure result indications, and unprotected TLS Error alerts are not 🔐.

The keying material can be derived after the TLS server Finished has been sent or received 🔑. Implementations following [RFC4137] can then set the eapKeyData and aaaEapKeyData variables.

The keying material can be made available to lower layers and the authenticator after the authenticated success result indication has been sent or received 🌸. Implementations following [RFC4137] can set the eapKeyAvailable and aaaEapKeyAvailable variables.

3. Detailed Description of the EAP-TLS Protocol

Good news, nothing new here 🌈. There are no updates to Section 3 of [RFC5216].

4. IANA Considerations

This section is the guidance for the Internet Assigned Numbers Authority (IANA) about registering values related to EAP-TLS 1.3, following [RFC8126] 📋.

Per this document, IANA has added the following labels to the "TLS Exporter Labels" registry defined by [RFC5705] 🧾. These labels are used in the derivation of Key_Material and Method-Id, as defined in Section 2.3 ✨:

  +===============================+=========+=============+======+
  | Value                         | DTLS-OK | Recommended | Note |
  +===============================+=========+=============+======+
  | EXPORTER_EAP_TLS_Key_Material |    N    |      Y      |      |
  +-------------------------------+---------+-------------+------+
  | EXPORTER_EAP_TLS_Method-Id    |    N    |      Y      |      |
  +-------------------------------+---------+-------------+------+

                     Table 1: TLS Exporter Labels

5. Security Considerations

Okay this part is SERIOUS 😤💀. The security considerations of TLS 1.3 [RFC8446] apply to EAP-TLS 1.3, so everything in that document comes along for the ride 🛡️.

5.1. Security Claims

Using EAP-TLS with TLS 1.3 does not change the security claims for EAP-TLS as given in Section 5.1 of [RFC5216] 📜. However, it strengthens several of those claims, as described in the following updates to the notes given in Section 5.1 of [RFC5216] 💪.

[1] Mutual authentication: By mandating revocation checking of certificates, the authentication in EAP-TLS with TLS 1.3 is stronger, because authentication with revoked certificates will always fail 🚫🪪.

[2] Confidentiality: The TLS 1.3 handshake offers much better confidentiality than earlier versions of TLS 🤫. EAP-TLS with TLS 1.3 mandates use of cipher suites that ensure confidentiality. TLS 1.3 also encrypts certificates and some of the extensions 🎀. When using EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not cause any additional round trips ⚡.

[3] Cryptographic strength: TLS 1.3 only defines strong algorithms without major weaknesses, and EAP-TLS with TLS 1.3 always provides forward secrecy; see [RFC8446] 🔥. Weak algorithms such as 3DES, CBC mode, RC4, SHA-1, MD5, P-192, and RSA-1024 have not been registered for use in TLS 1.3 🗑️.

[4] Cryptographic negotiation: The TLS layer handles the negotiation of cryptographic parameters 🤝. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic negotiation of the AEAD algorithm, HKDF hash algorithm, key exchange groups, and signature algorithm; see Section 4.1.1 of [RFC8446] 👑.

5.2. Peer and Server Identities

No updates to Section 5.2 of [RFC5216] 🙌. Note that Section 2.2 has additional discussion on identities 🪪.

5.3. Certificate Validation

No updates to Section 5.3 of [RFC5216] 🙆. In addition to Section 5.3 of [RFC5216], guidance on server certificate validation can be found in [RFC6125] 📖.

5.4. Certificate Revocation

This section updates Section 5.4 of [RFC5216] by amending it in accordance with the following discussion 📝.

There are a number of reasons (for example key compromise, CA compromise, privilege withdrawn, and so on) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have to be revoked before their expiry date 💔. Revoking the EAP-TLS server's certificate is complicated by the fact that the EAP-TLS peer may not have Internet connectivity until authentication completes 😩.

When EAP-TLS is used with TLS 1.3, the revocation status of all the certificates in the certificate chains MUST be checked (except the trust anchor) 🔍. An implementation may use the Certificate Revocation List (CRL), Online Certificate Status Protocol (OSCP), or other standardized or proprietary methods for revocation checking 🛠️. Examples of proprietary methods are non-standard formats for distributing revocation lists, as well as certificates with very short lifetimes ⏳.

EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) as specified in [RFC6066] and Section 4.4.2.1 of [RFC8446] 📌. It is RECOMMENDED that EAP-TLS peers and EAP-TLS servers use OCSP stapling for verifying the status of the EAP-TLS server's certificate chain 💜. When an EAP-TLS peer uses Certificate Status Requests to check the revocation status of the EAP-TLS server's certificate chain, it MUST treat a CertificateEntry (but not the trust anchor) without a valid CertificateStatus extension as invalid, and abort the handshake with an appropriate alert 🚨. The OCSP status handling in TLS 1.3 is different from earlier versions of TLS; see Section 4.4.2.1 of [RFC8446] 🔄. In TLS 1.3, the OCSP information is carried in the CertificateEntry containing the associated certificate, instead of a separate CertificateStatus message as in [RFC6066]. This enables sending OCSP information for all certificates in the certificate chain (except the trust anchor) 🌟.

To enable revocation checking in situations where EAP-TLS peers do not implement or use OCSP stapling, and where network connectivity is not available before authentication completes, EAP-TLS peer implementations MUST also support checking for certificate revocation after authentication completes and network connectivity is available 🌐. An EAP peer implementation SHOULD NOT trust the network (or any services) until it has verified the revocation status of the server certificate after receiving network connectivity 🙅. An EAP peer MUST use a secure transport to verify the revocation status of the server certificate 🔒. An EAP peer SHOULD NOT send any other traffic before revocation checking for the server certificate is complete 🤐.

5.5. Packet Modification Attacks

This section updates Section 5.5 of [RFC5216] by amending it in accordance with the following discussion 🦹.

As described in [RFC3748] and Section 5.5 of [RFC5216], the only information that is integrity and replay protected in EAP-TLS is the part of the TLS Data that TLS protects 🛡️. Everything else in the EAP-TLS message exchange can be modified, spoofed, or replayed 😱. That includes the EAP-Request and EAP-Response headers, the identity in the Identity Response, the EAP-TLS packet header fields, Type, Flags, EAP-Success, and EAP-Failure 💀.

Protected TLS Error alerts are protected failure result indications, and they let the EAP-TLS peer and EAP-TLS server determine that the failure result was not spoofed by an attacker 🕵️‍♀️. Protected failure result indications provide integrity and replay protection but MAY be unauthenticated 🙈. Protected failure results do not significantly improve availability, because TLS 1.3 treats most malformed data as a fatal error 🥲.

5.6. Authorization ✨

This is a new section when compared to [RFC5216]. The guidance here is relevant for EAP-TLS in general, no matter which TLS version is underneath 🦋

Okay so EAP servers usually want the EAP peer to show a valid certificate, and if one isn't provided they'll fail the connection 💅 Some deployments might allow no peer authentication for some or all connections. When peer authentication isn't used, EAP-TLS server implementations MUST take care to limit network access appropriately for unauthenticated peers, and implementations MUST use resumption with caution to ensure that a resumed session is not granted more privilege than was intended for the original session. An example of limiting network access would be to invoke a vendor's walled garden or quarantine network functionality 🔥

EAP-TLS is typically encapsulated in other protocols such as PPP [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or the Protocol for Carrying Authentication for Network Access (PANA) [RFC5191]. The encapsulating protocols can also hand extra, non-EAP information to an EAP-TLS server 🧚 That information can include, but is not limited to, details about the authenticator, details about the EAP-TLS peer, or details about the protocol layers above or below EAP (MAC addresses, IP addresses, port numbers, Wi-Fi Service Set Identifiers (SSIDs), etc.). EAP-TLS servers implementing EAP-TLS inside those protocols can make policy decisions and enforce authorization based on a combination of information from the EAP-TLS exchange and non-EAP information. It's giving full toolkit energy 👑

As noted in Section 2.2, the identity presented in EAP-Response/Identity is not authenticated by EAP-TLS, so it's trivial for an attacker to forge, modify, or replay 💀 That means authorization and accounting MUST be based on authenticated information, such as information in the certificate, or the PSK identity and cached data provisioned for resumption as described in Section 5.7. Note that the requirements for Network Access Identifiers (NAIs) specified in Section 4 of [RFC7542] still apply and MUST be followed 🫶

EAP-TLS servers MAY reject conversations based on non-EAP information provided by the encapsulating protocol, for example if the MAC address of the authenticator does not match the expected policy 🙈

In addition to allowing configuration of one or more trusted root certificates (CA certificate) to authenticate the server certificate, and one or more server names to match against the SubjectAltName (SAN) extension, EAP peer implementations MAY allow binding the configured acceptable SAN to a specific CA (or CAs) that should have issued the server certificate. This helps prevent attacks from rogue or compromised CAs 🛡️

5.7. Resumption ✨

This is a new section when compared to [RFC5216]. The guidance here is relevant for EAP-TLS in general, no matter which TLS version is underneath 🌸

There are a bunch of security issues related to resumption that [RFC5216] doesn't describe, so the problems, guidelines, and requirements in this section apply to EAP-TLS when it's used with any version of TLS 😭

When resumption happens, it's based on cached information at the TLS layer. To resume securely, the EAP-TLS peer and EAP-TLS server need to be able to securely retrieve authorization information, such as certificate chains, from the initial full handshake. This document uses the term "cached data" to describe that information. Authorization during resumption MUST be based on such cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh revocation checks on the cached certificate data. Any security policies for authorization MUST also be followed for resumption. Certificates may have been revoked since the initial full handshake, and the authorizations of the other party may have been reduced. If the cached revocation data isn't sufficiently current, the EAP-TLS peer or EAP-TLS server MAY force a full TLS handshake 👀

There are two ways to retrieve the cached data from the original full handshake. The first method is that the EAP-TLS server and client cache the information locally. The cached information is identified by an identifier. For TLS versions before 1.3, the identifier can be the session ID. For TLS 1.3, the identifier is the PSK identity. The second method for retrieving cached information is via [RFC5077] or [RFC8446], where the EAP-TLS server avoids storing information locally and instead encapsulates the information into a ticket that is sent to the client for storage. This ticket is encrypted using a key that only the EAP-TLS server knows. Note that the client still needs to cache the original handshake information locally, and it will obtain that information while determining the session ID or PSK identity to use for resumption. However, the EAP-TLS server is able to decrypt the ticket or PSK to get the original handshake information 🧠

The EAP-TLS server or EAP client MUST cache data during the initial full handshake, sufficient to allow authorization decisions to be made during resumption. If cached data cannot be retrieved securely, resumption MUST NOT be done 🚫

The above requirements also apply if the EAP-TLS server expects some system to perform accounting for the session. Accounting has to be tied to an authenticated identity, and resumption doesn't supply one, so accounting is impossible without access to cached data. That's why systems that expect to perform accounting for the session SHOULD cache an identifier that can be used in subsequent accounting 📝

As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption PSKs or tickets (and associated cached data) for longer than 604800 seconds (7 days), regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY delete them earlier based on local policy. The cached data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain has been revoked or has expired. In all of these cases, an attempt at resumption results in a full TLS handshake instead ⏳

⚠️ Here's the TOCTOU part, bestie. Information from the EAP-TLS exchange (for example the identity provided in EAP-Response/Identity) as well as non-EAP information (for example IP addresses) may change between the initial full handshake and resumption. This change creates a "time-of-check time-of-use" (TOCTOU) security vulnerability. A malicious or compromised user could supply one set of data during the initial authentication and a different set during resumption, potentially getting access they shouldn't have. Not it 🙅‍♀️

If any authorization, accounting, or policy decisions were made with information that has changed between the initial full handshake and resumption, and if that change may lead to a different decision, such decisions MUST be reevaluated. It is RECOMMENDED that authorization, accounting, and policy decisions are reevaluated based on the information given in the resumption. EAP-TLS servers MAY reject resumption where the information supplied during resumption does not match the information supplied during the original authentication. If a safe decision isn't possible, EAP-TLS servers SHOULD reject the resumption and continue with a full handshake 🔐

Sections 2.2 and 4.2.11 of [RFC8446] provide security considerations for TLS 1.3 resumption 💜

5.8. Privacy Considerations ✨

This is a new section when compared to [RFC5216] 🎀

TLS 1.3 offers much better privacy than earlier versions of TLS, as discussed in Section 2.1.8 🌈 In this section, we only talk about the privacy properties of EAP-TLS with TLS 1.3. For the privacy properties of TLS 1.3 itself, see [RFC8446].

EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in EAP packets. On top of that, the EAP-TLS peer sends an identity in the first EAP-Response. The other fields in the EAP-TLS Request and the EAP-TLS Response packets don't contain any cleartext privacy-sensitive information ✨

Tracking users by eavesdropping on Identity Responses or certificates is a well-known problem in lots of EAP methods, so this matters 👁️ When EAP-TLS is used with TLS 1.3, all certificates are encrypted, and the username part of the Identity Response isn't revealed (for example, by using anonymous NAIs). Note that even though all certificates are encrypted, the server's identity is only protected against passive attackers, while the client's identity is protected against both passive and active attackers. 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 depends a lot on how many other users are using the same domain name in the particular access network. If all EAP-TLS peers have the same domain, no additional information leaks. But if a domain name is used by a small subset of the EAP-TLS peers, it may help an attacker track or identify the user 🕵️‍♀️

Without padding, information about the size of the client certificate is leaked from the size of the EAP-TLS packets. The EAP-TLS packet sizes may therefore leak information that can be used to track or identify the user. If all client certificates have the same length, no information leaks. EAP-TLS peers SHOULD use record padding; see Section 5.4 of [RFC8446] to reduce information leakage of certificate sizes 🌷

If anonymous NAIs aren't used, the privacy-friendly identifiers need to be generated with care. The identities MUST be generated in a cryptographically secure way, so that it is computationally infeasible for an attacker to differentiate two identities belonging to the same user from two identities belonging to different users in the same realm. This can be achieved, for instance, by using random or pseudo-random usernames, such as random byte strings or ciphertexts, and only using each pseudo-random username a single time. Note that privacy-friendly usernames also MUST NOT include substrings that can be used to relate the identity to a specific user. Similarly, privacy-friendly usernames MUST NOT be formed by a fixed mapping that stays the same across multiple different authentications 🫧

An EAP-TLS peer with a policy allowing communication with EAP-TLS servers that only support TLS 1.2 without privacy and with a static RSA key exchange is vulnerable to disclosure of the EAP-TLS peer username. An active attacker can, in this case, make the EAP-TLS peer believe that an EAP-TLS server supporting TLS 1.3 only supports TLS 1.2 without privacy. The attacker can simply impersonate the EAP-TLS server, negotiate TLS 1.2 with static RSA key exchange, and send a TLS alert message when the EAP-TLS peer tries to use privacy by sending an empty certificate message. Since the attacker (impersonating the EAP-TLS server) doesn't provide a proof-of-possession of the private key until the Finished message when a static RSA key exchange is used, an EAP-TLS peer may inadvertently disclose its identity (username) to an attacker. That's why it is RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and static RSA-based cipher suites without privacy. This implies that an EAP-TLS peer SHOULD NOT continue the EAP authentication attempt if a TLS 1.2 EAP-TLS server sends an EAP-TLS/Request with a TLS alert message in response to an empty certificate message from the peer 🚨

5.9. Pervasive Monitoring 🔍

This is a new section when compared to [RFC5216].

okay so pervasive monitoring is basically when someone is watching users everywhere 👀. With EAP-TLS, attackers can go after peer devices and track them (and their people) every time they join a network 🫣. BUT by encrypting more stuff, making privacy mandatory, and always giving you forward secrecy, EAP-TLS with TLS 1.3 is way more protected against this 💪✨. On top of the privacy attacks we already covered, large-scale surveillance could track someone across a wide geographic area and across different access networks 🌍. And if you mix EAP-TLS info with info from other protocols, it gets much easier to figure out who a specific person is 😬.

In TLS 1.3, the post-handshake key update mechanism gives forward secrecy for the traffic secrets 🔄. EAP-TLS 1.3 does not provide a similar mechanism for MSK and EMSK 🙅. Implementations using the exported MSK and EMSK can get forward secrecy by frequently deriving new keys, in a similar way to what's described in Section 7.2 of [RFC8446] 🔑💖.

5.10. Discovered Vulnerabilities 🕵️‍♀️

This is a new section when compared to [RFC5216].

Over the years, there have been a bunch of serious attacks on earlier versions of Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation 😩. [RFC7457] sums up the attacks that were known when it was published, and BCP 195 [RFC7525] [RFC8996] gives recommendations and requirements for making deployed TLS services more secure 🔐. Honestly, though, a lot of these attacks are less serious for EAP-TLS, since EAP-TLS only uses the TLS handshake and doesn't protect any application data 🤷‍♀️. Still, the rule is:

EAP-TLS implementations MUST mitigate known attacks. 🚨

EAP-TLS implementations also need to keep an eye on new EAP- and TLS-related security guidance and requirements, like [RFC8447] and [RFC9155] 👀✨.

5.11. Cross-Protocol Attacks 🎭

This is a new section when compared to [RFC5216].

Okay, this one is spicy 🌶️. If the same certificate gets used across multiple protocols, an attacker could authenticate through one protocol and then "resume" that session in another one 😱. Section 2.2 says certificates typically have one or more FQDNs in the SAN extension. But those fields are only for EAP validation, and they don't mean the certificate is suitable for HTTPS or other protocols on the named host 🙅‍♀️.

Section 2.1.3 suggests that authorization rules should be reapplied on resumption, but it doesn't mandate this behavior 🤔. So this cross-protocol resumption could let an attacker bypass authorization policies and get access to secured systems they shouldn't be touching 💀. Besides making sure the right authorization info is available and used during resumption, using different certificates and resumption caches for different protocols is RECOMMENDED to keep each protocol's usage separate 🧱💜.

6. References 📚

6.1. Normative References 📖

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
           Levkowetz, Ed., "Extensible Authentication Protocol
           (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
           <https://www.rfc-editor.org/info/rfc3748>.

[RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
           Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
           March 2008, <https://www.rfc-editor.org/info/rfc5216>.

[RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
           Housley, R., and W. Polk, "Internet X.509 Public Key
           Infrastructure Certificate and Certificate Revocation List
           (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
           <https://www.rfc-editor.org/info/rfc5280>.

[RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
           Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
           March 2010, <https://www.rfc-editor.org/info/rfc5705>.

[RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
           Extensions: Extension Definitions", RFC 6066,
           DOI 10.17487/RFC6066, January 2011,
           <https://www.rfc-editor.org/info/rfc6066>.

[RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
           Galperin, S., and C. Adams, "X.509 Internet Public Key
           Infrastructure Online Certificate Status Protocol - OCSP",
           RFC 6960, DOI 10.17487/RFC6960, June 2013,
           <https://www.rfc-editor.org/info/rfc6960>.

[RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
           DOI 10.17487/RFC7542, May 2015,
           <https://www.rfc-editor.org/info/rfc7542>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

6.2. Informative references 📚✨

Okay bestie, these are the extra-credit reads that go with everything above. Every one is listed in full so you can look it up. 🤓

Appendix A. Updated References 🦋

Okay so this part is about references that got a glow-up. When EAP-TLS is used with TLS 1.3, the references in [RFC5216] get updated like this. 💅

  • All references to [RFC2560] are updated to refer to [RFC6960].
  • All references to [RFC3280] are updated to refer to [RFC5280]. References to Section 4.2.1.13 of [RFC3280] are updated to refer to Section 4.2.1.12 of [RFC5280].
  • All references to [RFC4282] are updated to refer to [RFC7542]. References to Section 2.1 of [RFC4282] are updated to refer to Section 2.2 of [RFC7542].

Acknowledgments 🫶

The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, Alan DeKok, Ari Keränen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and suggestions on this document. Special thanks to the Document Shepherd Joseph Salowey. 💖🌈

Contributors 🧚

Alan DeKok, FreeRADIUS 💜

Authors' Addresses 🎀

John Preuß Mattsson
Ericsson
SE-164 40 Kista
Sweden

Email: john.mattsson@ericsson.com


Mohit Sethi
Ericsson
FI-02420 Jorvas
Finland

Email: mohit@iki.fi
📦 where this page comes from