Skip to main content

Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-14

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9190.
Authors John Preuß Mattsson , Mohit Sethi
Last updated 2021-02-25 (Latest revision 2021-02-02)
Replaces draft-mattsson-eap-tls13
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Joseph A. Salowey
Shepherd write-up Show Last changed 2020-05-17
IESG IESG state Became RFC 9190 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Roman Danyliw
Send notices to Joseph Salowey <joe@salowey.net>
IANA IANA review state Version Changed - Review Needed
IANA expert review state Expert Reviews OK
draft-ietf-emu-eap-tls13-14
Network Working Group                                        J. Mattsson
Internet-Draft                                                  M. Sethi
Updates: 5216 (if approved)                                     Ericsson
Intended status: Standards Track                        February 2, 2021
Expires: August 6, 2021

                       Using EAP-TLS with TLS 1.3
                      draft-ietf-emu-eap-tls13-14

Abstract

   The Extensible Authentication Protocol (EAP), defined in RFC 3748,
   provides a standard mechanism for support of multiple authentication
   methods.  This document specifies the use of EAP-Transport Layer
   Security (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.  EAP-TLS with TLS 1.3 further
   improves security and privacy by always providing forward secrecy,
   never disclosing the peer identity, and by mandating use of
   revocation checking.  This document also provides guidance on
   authorization and resumption for EAP-TLS in general (regardless of
   the underlying TLS version used).  This document updates RFC 5216.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 6, 2021.

Copyright Notice

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

Mattsson & Sethi         Expires August 6, 2021                 [Page 1]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   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, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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

Mattsson & Sethi         Expires August 6, 2021                 [Page 2]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Introduction

   The Extensible Authentication Protocol (EAP), defined in [RFC3748],
   provides a standard mechanism for support of multiple authentication
   methods.  EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies
   an EAP authentication method with certificate-based mutual
   authentication 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 and key establishment in IEEE
   802.11 [IEEE-802.11] (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec)
   networks using IEEE 802.1X [IEEE-802.1X] and it's the default
   mechanism for certificate based authentication in 3GPP 5G [TS.33.501]
   and MulteFire [MulteFire] networks.  Many other EAP methods such as
   EAP-FAST [RFC4851], EAP-TTLS [RFC5281], TEAP [RFC7170], and PEAP
   [PEAP] depend on TLS and EAP-TLS.

   EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346],
   but can also work with TLS 1.2 [RFC5246].  TLS 1.0 and 1.1 are
   formally deprecated and prohibited to negotiate and use
   [I-D.ietf-tls-oldversions-deprecate].  Weaknesses found in TLS 1.2,
   as well as new requirements for security, privacy, and reduced
   latency has led to the specification of TLS 1.3 [RFC8446], which
   obsoletes TLS 1.2 [RFC5246].  TLS 1.3 is in large parts a complete
   remodeling of the TLS handshake protocol including a different
   message flow, different handshake messages, different key schedule,
   different cipher suites, different resumption, different privacy
   protection, and record padding.  This means that significant parts of
   the normative text in the previous EAP-TLS specification [RFC5216]
   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.  It
   does however provide additional guidance on authorization and
   resumption for EAP-TLS in general (regardless of the underlying TLS
   version used).  While this document updates EAP-TLS [RFC5216], it
   remains backwards compatible with it and existing implementations of
   EAP-TLS.  This document only describes differences compared to
   [RFC5216].  All message flow are specific to TLS 1.3 and do not apply
   to TLS 1.2.

   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.
   Privacy, which in EAP-TLS means that the peer username is not

Mattsson & Sethi         Expires August 6, 2021                 [Page 3]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   disclosed, is mandatory and achieved without any additional round-
   trips.  Revocation checking is mandatory and simplified with OCSP
   stapling, and TLS 1.3 introduces more possibilities to reduce
   fragmentation when compared to earlier versions of TLS.

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 be familiar with the terms and concepts used
   in EAP-TLS [RFC5216] and TLS [RFC8446].  The term EAP-TLS peer is
   used for the entity acting as EAP peer and TLS client.  The term EAP-
   TLS server is used for the entity acting as EAP server and TLS
   server.

2.  Protocol Overview

2.1.  Overview of the EAP-TLS Conversation

   This section updates Section 2.1 of [RFC5216].

   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 [RFC5216] 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 [RFC8446] and [RFC5216].

2.1.1.  Mutual Authentication

   This section updates Section 2.1.1 of [RFC5216].

   The EAP-TLS server MUST authenticate with a certificate and SHOULD
   require the EAP-TLS 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.  The full handshake in EAP-TLS with TLS 1.3 always
   provide forward secrecy by exchange of ephemeral "key_share"

Mattsson & Sethi         Expires August 6, 2021                 [Page 4]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   extentions in the ClientHello and ServerHello (e.g. containing
   ephemeral ECDHE public keys).  SessionID is deprecated in TLS 1.3,
   see Sections 4.1.2 and 4.1.3 of [RFC8446].  TLS 1.3 introduced early
   application data which like all other application data is not used in
   EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information
   of the "early_data" extension.  Resumption is handled as described in
   Section 2.1.3.  TLS 1.3 introduced the Post-Handshake KeyUpdate
   message which is not useful and not expected in EAP-TLS.  The EAP-TLS
   server always commits to not send any more handshake messages by
   sending a TLS close_notify alert.  After the EAP-TLS server has
   received an empty EAP-Response to the EAP-Request containing the TLS
   close_notify alert, the EAP-TLS server sends EAP-Success.

   In the case where EAP-TLS with mutual authentication is successful
   (and neither HelloRetryRequest nor Post-Handshake messages are sent)
   the conversation will appear as shown in Figure 1.

Mattsson & Sethi         Expires August 6, 2021                 [Page 5]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

    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 close_notify)
    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 NewSessionTicket messages (each
   containing a PSK, a PSK identity, a ticket lifetime, and other
   parameters) in the initial authentication.  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.  The PSK associated with the ticket depends on the
   client Finished and cannot be pre-computed in handshakes with client

Mattsson & Sethi         Expires August 6, 2021                 [Page 6]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   authentication.  The NewSessionTicket message MUST NOT include an
   "early_data" extension.  A mechanism by which clients can specify the
   desired number of tickets needed for future connections is defined in
   [I-D.ietf-tls-ticketrequests].

   In the case where EAP-TLS with mutual authentication and ticket
   establishment with two tickets is successful, the conversation will
   appear as shown in Figure 2.

    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 NewSessionTicket,
                                 <--------          TLS close_notify)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Success

                  Figure 2: EAP-TLS ticket establishment

Mattsson & Sethi         Expires August 6, 2021                 [Page 7]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

2.1.3.  Resumption

   This section updates Section 2.1.2 of [RFC5216].

   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 [RFC8446].  If
   the client has received a NewSessionTicket message from the EAP-TLS
   server, the client can use the PSK identity received in the ticket to
   negotiate the use of the associated PSK.  If the EAP-TLS 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 up to the EAP-TLS peer whether to offer
   resumption, ut it is RECOMMENDED that the EAP-TLS peer offer
   resumption if it has a valid ticket that has not been used before.
   It is left to the EAP-TLS server whether to accept resumption, but it
   is RECOMMENDED that the EAP-TLS server accept resumption if the
   ticket that it issued is still valid.  However, the EAP-TLS server
   MAY choose to require a full handshake.  As in a full handshake,
   sending a NewSessionTicket is optional.  As described in Appendix C.4
   of [RFC8446], reuse of a ticket allows passive observers to correlate
   different connections.  EAP-TLS peers and EAP-TLS servers SHOULD
   follow the client tracking preventions in Appendix C.4 of [RFC8446].

   It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the
   same realm in the resumption and the original full handshake.  This
   requirement allows EAP packets to be routable to the same destination
   as the original full handshake.  If this recommendation is not
   followed, resumption is likely to be impossible.  When NAI reuse can
   be done without privacy implications, it is RECOMMENDED to use the
   same anonymous NAI in the resumption, as was used in the original
   full handshake [RFC7542].  For example, the NAI @realm can safely be
   reused since it does not provide any specific information to
   associate a user's resumption attempt with the original full
   handshake.  However, reusing the NAI
   P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path attacker to
   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.  The TLS PSK identity
   is therefore in general unsuitable for deriving a NAI to use in the
   Identity Response.

   A subsequent successful resumption handshake where both sides
   authenticate via a PSK provisioned via an earlier NewSessionTicket

Mattsson & Sethi         Expires August 6, 2021                 [Page 8]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   and where the server provisions a single new ticket is shown in
   Figure 3.

    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 Finished)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Finished)                -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                               (TLS NewSessionTicket,
                                 <--------          TLS close_notify)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Success

                       Figure 3: EAP-TLS resumption

   A subsequent successful resumption handshake where both sides
   authenticate via a PSK provisioned via an earlier NewSessionTicket
   and where the server does not provision any new tickets is shown in
   Figure 4.

Mattsson & Sethi         Expires August 6, 2021                 [Page 9]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

    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 Finished)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Finished)                -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                 <--------         (TLS close_notify)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Success

                       Figure 4: EAP-TLS resumption

   As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD
   supply a "key_share" extension when attempting resumption, which
   allows the EAP-TLS server to potentially decline resumption and fall
   back to a full handshake.  If the EAP-TLS peer did not supply a
   "key_share" extension when attempting resumption, the EAP-TLS server
   needs to send HelloRetryRequest to signal that additional information
   is needed to complete the handshake, and the EAP-TLS peer needs to
   send a second ClientHello containing that information.  Providing a
   "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode
   is also important in order to limit the impact of a key compromise.
   When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning
   that key leakage does not compromise any earlier connections.  It is
   RECOMMMENDED to use "psk_dhe_ke" for resumption.

2.1.4.  Termination

   This section updates Section 2.1.3 of [RFC5216].

Mattsson & Sethi         Expires August 6, 2021                [Page 10]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   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 or higher.
   The two paragraphs below replaces the corresponding paragraphs in
   Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or
   higher.  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 the EAP-TLS server sending an EAP-Success message.

      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 5, 6, and 7 illustrate message flows in several cases where
   the EAP-TLS peer or EAP-TLS server sends a TLS fatal 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_cancelled", both of which
   indicate that the connection is not going to continue normally, see
   [RFC8446].

   In the case where the EAP-TLS server rejects the ClientHello with a
   fatal error, the conversation will appear as shown in Figure 5.  The
   EAP-TLS server can also partly reject the ClientHello with a
   HelloRetryRequest, see Section 2.1.6.

Mattsson & Sethi         Expires August 6, 2021                [Page 11]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

    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 Fatal Alert)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Failure

             Figure 5: EAP-TLS server rejection of ClientHello

   In the case where EAP-TLS server authentication is unsuccessful, the
   conversation will appear as shown in Figure 6.

Mattsson & Sethi         Expires August 6, 2021                [Page 12]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

    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 Fatal Alert)
                                 -------->
                                 <--------               EAP-Failure

       Figure 6: EAP-TLS unsuccessful EAP-TLS server authentication

   In the case 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, the conversation will appear as shown in Figure 7.

Mattsson & Sethi         Expires August 6, 2021                [Page 13]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

    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 Fatal Alert)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Failure

           Figure 7: EAP-TLS unsuccessful client authentication

2.1.5.  No Peer Authentication

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

   In the case where EAP-TLS is used without peer authentication (e.g.,
   emergency services, as described in [RFC7406]) the conversation will
   appear as shown in Figure 8.

Mattsson & Sethi         Expires August 6, 2021                [Page 14]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

    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 close_notify)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Success

               Figure 8: 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.

   The case of a successful EAP-TLS mutual authentication after the EAP-
   TLS server has sent a HelloRetryRequest message is shown in Figure 9.
   Note the extra round-trip as a result of the HelloRetryRequest.

Mattsson & Sethi         Expires August 6, 2021                [Page 15]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

    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 close_notify)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Success

                Figure 9: EAP-TLS with Hello Retry Request

2.1.7.  Identity

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

   It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity
   Response as such identities are routable and privacy-friendly.  While
   opaque blobs are allowed by [RFC3748], such identities are NOT

Mattsson & Sethi         Expires August 6, 2021                [Page 16]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   RECOMMENDED as they are not routable and should only be considered in
   local deployments where the EAP-TLS peer, EAP authenticator, and EAP-
   TLS server all belong to the same network.  Many client certificates
   contain an identity such as an email address, which is already in NAI
   format.  When the client certificate contains a NAI as subject name
   or alternative subject name, an anonymous NAI SHOULD be derived from
   the NAI in the certificate, see Section 2.1.8.  More details on
   identities are described 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].

   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 [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its
   username in cleartext in the Identity Response.  Following [RFC7542],
   it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but
   other constructions such as a fixed username (e.g. anonymous@realm)
   or an encrypted username (e.g.,
   xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed.
   Note that the NAI MUST be a UTF-8 string as defined by the grammar in
   Section 2.2 of [RFC7542].

   As the certificate messages in TLS 1.3 are encrypted, there is no
   need to send an empty certificate_list and perform a second handshake
   for privacy (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.

   EAP-TLS with TLS 1.3 is always used with privacy.  This does not add
   any extra round-trips and 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].

Mattsson & Sethi         Expires August 6, 2021                [Page 17]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   Including 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 is provided through addition
   of a flags octet within the EAP-Response and EAP-Request packets, as
   well as a TLS Message Length field of four octets.  Implementations
   MUST NOT set the L bit in unfragmented messages, but MUST accept
   unfragmented messages with and without the L bit set.

   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 EAP-TLS peer, EAP-TLS server, and
   trust anchor certificates small and the length of the certificate
   chains short.  In addition, it is RECOMMENDED to use mechanisms that
   reduce the sizes of Certificate messages.  For a detailed discussion
   on reducing message sizes to prevent fragmentation, see
   [I-D.ietf-emu-eaptlscert].

2.2.  Identity Verification

   This section updates Section 2.2 of [RFC5216].

   The identity provided in the EAP-Response/Identity is not
   authenticated by EAP-TLS.  Unauthenticated information SHALL 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 purposes such as routing and
   EAP method selection.  EAP-TLS servers MAY reject conversations if
   the identity does not match their policy.  Note that this also
   applies to resumption, see Sections 2.1.3, 5.6, and 5.7.

2.3.  Key Hierarchy

   This section updates Section 2.3 of [RFC5216].

   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 [RFC5216] 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 [RFC8446].

   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 [RFC5705] (for TLS 1.3 this is
   defined in Section 7.5 of [RFC8446]).

Mattsson & Sethi         Expires August 6, 2021                [Page 18]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   Type-Code  = 0x0D
   MSK        = TLS-Exporter("EXPORTER_EAP_TLS_MSK_"+Type-Code,
                               "",64)
   EMSK       = TLS-Exporter("EXPORTER_EAP_TLS_EMSK_"+Type-Code,
                               "",64)
   Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id_"+Type-Code,
                               "",64)
   Session-Id = Type-Code || Method-Id

   A zero-length context (indicated by "") is used in the TLS exporter
   interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is
   appended to the label strings.  Other TLS based EAP methods can use
   exporters in a similar fashion by replacing the EAP-TLS Type-Code
   with their own Type-Code (encoded as a hexadecimal string).

   [RFC5247] deprecates the use of IV.  Thus, 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 it used by lower
   layers.

   Note that the key derivation MUST use the length values given above.
   While in TLS 1.2 and earlier it was possible to truncate the output
   by requesting less data from the TLS-Exporter function, this 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.  Failure
   to do so will result in incorrect values being calculated for the
   above keying material.

   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.

2.4.  Parameter Negotiation and Compliance Requirements

   This section updates Section 2.4 of [RFC5216].

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

   When EAP-TLS is used with TLS version 1.3 or higher, 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.) for the TLS
   version used.  For TLS 1.3 the compliance requirements are defined in

Mattsson & Sethi         Expires August 6, 2021                [Page 19]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   Section 9 of [RFC8446].  In EAP-TLS with TLS 1.3, only cipher suites
   with confidentiality SHALL be supported.

   While EAP-TLS does not protect any application data except for the
   Commitment Message, 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

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

   TLS 1.3 [RFC8446] 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 NewSessionTicket can be used for resumption.
   After sending TLS Finished, the EAP-TLS server may send any number of
   Post-Handshake messages in separate EAP-Requests.  To decrease the
   uncertainty for the EAP-TLS peer, the following procedure MUST be
   followed:

   When an EAP-TLS server has sent its last handshake message (Finished
   or a Post-Handshake), it commits to not sending any more handshake
   messages by sending a TLS close_notify alert.  After sending the
   alert, the EAP-TLS server may only send an EAP-Success or an EAP-
   Failure.  Using the TLS close_notify however results in an extra EAP-
   Request and EAP-Response exchange between the peer and the server.

3.  Detailed Description of the EAP-TLS Protocol

   No updates to Section 3 of [RFC5216].

4.  IANA considerations

   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 [RFC8126].

   This memo requires IANA to add the following labels to the TLS
   Exporter Label Registry defined by [RFC5705].  These labels are used
   in derivation of Key_Material, IV and Method-Id as defined in
   Section 2.3:

Mattsson & Sethi         Expires August 6, 2021                [Page 20]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

      +-----------------------------+---------+-------------+------+
      | Value                       | DTLS-OK | Recommended | Note |
      +-----------------------------+---------+-------------+------+
      | EXPORTER_EAP_TLS_MSK_       | N       | Y           |      |
      |                             |         |             |      |
      | EXPORTER_EAP_TLS_EMSK_      | N       | Y           |      |
      |                             |         |             |      |
      | EXPORTER_EAP_TLS_Method-Id_ | N       | Y           |      |
      +-----------------------------+---------+-------------+------+

                   Table 1: TLS Exporter Label Registry

5.  Security Considerations

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 the 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
   as 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 define strong algorithms
   without major weaknesses and EAP-TLS with TLS 1.3 always provide
   forward secrecy, see [RFC8446].  Weak algorithms such as 3DES, CBC
   mode, RC4, SHA-1, MD5, P-192, and RSA-1024 can therefore not be
   negotiated.

   [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 [RFC8446].

Mattsson & Sethi         Expires August 6, 2021                [Page 21]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

5.2.  Peer and Server Identities

   No updates to section 5.2 of [RFC5216].

5.3.  Certificate Validation

   No updates to section 5.3 of [RFC5216].

5.4.  Certificate Revocation

   This section updates Section 5.4 of [RFC5216].

   While certificates may have long validity periods, there are a number
   of reasons (e.g., key compromise, CA compromise, privilege withdrawn,
   etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have
   to be revoked before their expiry date.  Revocation of 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 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 and distribution of
   revocation lists as well as certificates with very short lifetime.

   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
   (except 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 prior to authentication completion, EAP-TLS peer
   implementations MUST also support checking for certificate revocation
   after authentication completes and network connectivity is available.

Mattsson & Sethi         Expires August 6, 2021                [Page 22]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   An implementation MAY enforce limited authorization before revocation
   checking has been done.

5.5.  Packet Modification Attacks

   No updates to Section 5.5 of [RFC5216].

5.6.  Authorization

   This is a new section when compared to [RFC5216].  The guidance in
   this section is relevant for EAP-TLS in general (regardless of the
   underlying TLS version used).

   EAP-TLS is typically encapsulated in other protocols, such as PPP
   [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191].
   The encapsulating protocols can also provide additional, non-EAP
   information to an EAP-TLS server.  This information can include, but
   is not limited to, information about the authenticator, information
   about the EAP-TLS peer, or information about the protocol layers
   above or below EAP (MAC addresses, IP addresses, port numbers, WiFi
   SSID, 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.

   As noted in Section 2.2, the identity presented in EAP-Response/
   Identity is not authenticated by EAP-TLS and is therefore trivial for
   an attacker to forge, modify, or replay.  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.

5.7.  Resumption

   This is a new section when compared to [RFC5216].  The guidance in
   this section is relevant for EAP-TLS in general (regardless of the
   underlying TLS version used).

   There are a number of security issues related to resumption that are
   not described in [RFC5216].  The problems, guidelines, and
   requirements in this section therefore applies to all version of TLS.

Mattsson & Sethi         Expires August 6, 2021                [Page 23]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   When resumption occurs, it is based on cached information at the TLS
   layer.  To perform resumption in a secure way, 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.  We use the term "cached data" to describe such
   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 be followed also for resumption.  The
   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 is not 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 or PSK
   which is sent to the client for storage.  This ticket or PSK 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 will use the session ID or PSK identity to lookup this
   information during resumption.  However, the EAP-TLS server is able
   to decrypt the ticket or PSK to obtain the original handshake
   information.

   If the EAP-TLS server or EAP client do not apply any authorization
   policies, they MAY allow resumption where no cached data is
   available.  In all other cases, they MUST cache data during the
   initial full handshake to enable resumption.  The cached data MUST be
   sufficient to make authorization decisions during resumption.  If
   cached data cannot be retrieved in a secure way, resumption MUST NOT
   be done.

   The above requirements also apply if the EAP-TLS server expects some
   system to perform accounting for the session.  Since accounting must
   be tied to an authenticated identity, and resumption does not supply
   such an identity, accounting is impossible without access to cached
   data.  Therefore systems which expect to perform accounting for the
   session SHOULD cache an identifier which 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 7 days,

Mattsson & Sethi         Expires August 6, 2021                [Page 24]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   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
   such cases, an attempt at resumption results in a full TLS handshake
   instead.

   Information from the EAP-TLS exchange (e.g., the identity provided in
   EAP-Response/Identity) as well as non-EAP information (e.g., 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 of data during resumption, potentially allowing them to
   obtain access that they should not have.

   If any authorization, accounting, or policy decisions were made with
   information that has changed between the initial full handshake and
   resumption, and if 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 is not possible, EAP-TLS servers SHOULD reject the
   resumption and continue with a full handshake.

   Section 2.2 and 4.2.11,[RFC8446] provides security considerations for
   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 discuss the
   privacy properties of EAP-TLS with TLS 1.3.  For privacy properties
   of TLS 1.3 itself, see [RFC8446].

   EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in
   EAP packets.  Additionally, 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 do not contain any cleartext privacy
   sensitive information.

   Tracking of users by eavesdropping on identity responses or
   certificates is a well-known problem in many EAP methods.  When EAP-
   TLS is used with TLS 1.3, all certificates are encrypted, and the

Mattsson & Sethi         Expires August 6, 2021                [Page 25]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   username part of the identity response is always confidentiality
   protected (e.g., using anonymous NAIs).  Note that even though all
   certificates are encrypted, the server's identity is only protected
   against passive attackers while 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 is highly dependent 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 is leaked.  If a
   domain name is used by a small subset of the EAP-TLS peers, it may
   aid an attacker in tracking or identifying 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 packets
   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 is leaked.  EAP-TLS peers SHOULD use record padding,
   see Section 5.4 of [RFC8446] to reduce information leakage of
   certificate sizes.

   If anonymous NAIs are not used, the privacy-friendly identifiers need
   to be generated with care.  The identities MUST be generated in a
   cryptographically secure way so that 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 the pseudo-random usernames a single time.  Note that
   the privacy-friendly usernames also MUST NOT include substrings that
   can be used to relate the identity to a specific user.  Similarly,
   privacy-friendly username 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 supporting only 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 and negotiate TLS 1.2 with static RSA key exchange and send an
   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) does not 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.  Therefore, it is

Mattsson & Sethi         Expires August 6, 2021                [Page 26]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   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 handshake 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].

   Pervasive monitoring refers to widespread surveillance of users.  In
   the context of EAP-TLS, pervasive monitoring attacks can target EAP-
   TLS peer devices for tracking them (and their users) as and when they
   join a network.  By encrypting more information, mandating the use of
   privacy, and always providing forward secrecy, EAP-TLS with 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.

5.10.  Discovered Vulnerabilities

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

   Over the years, there have been several serious attacks on earlier
   versions of Transport Layer Security (TLS), including attacks on its
   most commonly used ciphers and modes of operation.  [RFC7457]
   summarizes the attacks that were known at the time of publishing and
   BCP 195 [RFC7525] provides recommendations for improving the security
   of deployed services that use TLS.  However, many of the attacks are
   less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and
   does not protect any application data.  EAP-TLS implementations MUST
   mitigate known attacks.  EAP-TLS implementations need to monitor and
   follow new EAP and TLS related security guidance and requirements
   such as [RFC8447], [I-D.ietf-tls-oldversions-deprecate],
   [I-D.ietf-tls-md5-sha1-deprecate].

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>.

Mattsson & Sethi         Expires August 6, 2021                [Page 27]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   [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>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [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>.

Mattsson & Sethi         Expires August 6, 2021                [Page 28]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

6.2.  Informative references

   [I-D.ietf-emu-eaptlscert]
              Sethi, M., Mattsson, J., and S. Turner, "Handling Large
              Certificates and Long Certificate Chains in TLS-based EAP
              Methods", draft-ietf-emu-eaptlscert-08 (work in progress),
              November 2020.

   [I-D.ietf-tls-md5-sha1-deprecate]
              Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
              MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf-
              tls-md5-sha1-deprecate-04 (work in progress), October
              2020.

   [I-D.ietf-tls-oldversions-deprecate]
              Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and
              TLSv1.1", draft-ietf-tls-oldversions-deprecate-12 (work in
              progress), January 2021.

   [I-D.ietf-tls-ticketrequests]
              Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket
              Requests", draft-ietf-tls-ticketrequests-07 (work in
              progress), December 2020.

   [IEEE-802.11]
              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", IEEE Std 802.11-2016
              (Revision of IEEE Std 802.11-2012) , December 2016.

   [IEEE-802.1AE]
              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Local and metropolitan area networks -- Media
              Access Control (MAC) Security", IEEE Standard
              802.1AE-2018 , December 2018.

   [IEEE-802.1X]
              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Local and metropolitan area networks -- Port-
              Based Network Access Control", IEEE Standard 802.1X-2020 ,
              January 2020.

   [MulteFire]
              MulteFire, "MulteFire Release 1.1 specification", 2019.

Mattsson & Sethi         Expires August 6, 2021                [Page 29]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   [PEAP]     Microsoft Corporation, "[MS-PEAP]: Protected Extensible
              Authentication Protocol (PEAP)", 2018.

   [RFC1661]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
              STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
              <https://www.rfc-editor.org/info/rfc1661>.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, DOI 10.17487/RFC2246, January 1999,
              <https://www.rfc-editor.org/info/rfc2246>.

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

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <https://www.rfc-editor.org/info/rfc2865>.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              DOI 10.17487/RFC3280, April 2002,
              <https://www.rfc-editor.org/info/rfc3280>.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282,
              DOI 10.17487/RFC4282, December 2005,
              <https://www.rfc-editor.org/info/rfc4282>.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346,
              DOI 10.17487/RFC4346, April 2006,
              <https://www.rfc-editor.org/info/rfc4346>.

   [RFC4851]  Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
              Flexible Authentication via Secure Tunneling Extensible
              Authentication Protocol Method (EAP-FAST)", RFC 4851,
              DOI 10.17487/RFC4851, May 2007,
              <https://www.rfc-editor.org/info/rfc4851>.

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
              January 2008, <https://www.rfc-editor.org/info/rfc5077>.

Mattsson & Sethi         Expires August 6, 2021                [Page 30]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   [RFC5191]  Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
              and A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
              May 2008, <https://www.rfc-editor.org/info/rfc5191>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, DOI 10.17487/RFC5247, August 2008,
              <https://www.rfc-editor.org/info/rfc5247>.

   [RFC5281]  Funk, P. and S. Blake-Wilson, "Extensible Authentication
              Protocol Tunneled Transport Layer Security Authenticated
              Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
              DOI 10.17487/RFC5281, August 2008,
              <https://www.rfc-editor.org/info/rfc5281>.

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <https://www.rfc-editor.org/info/rfc6733>.

   [RFC7170]  Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
              "Tunnel Extensible Authentication Protocol (TEAP) Version
              1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
              <https://www.rfc-editor.org/info/rfc7170>.

   [RFC7406]  Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H.,
              and D. Kroeselberg, "Extensions to the Emergency Services
              Architecture for Dealing With Unauthenticated and
              Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406,
              December 2014, <https://www.rfc-editor.org/info/rfc7406>.

   [RFC7457]  Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
              Known Attacks on Transport Layer Security (TLS) and
              Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
              February 2015, <https://www.rfc-editor.org/info/rfc7457>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

Mattsson & Sethi         Expires August 6, 2021                [Page 31]
Internet-Draft            EAP-TLS with TLS 1.3             February 2021

   [RFC8447]  Salowey, J. and S. Turner, "IANA Registry Updates for TLS
              and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
              <https://www.rfc-editor.org/info/rfc8447>.

   [TS.33.501]
              3GPP, "Security architecture and procedures for 5G
              System", 3GPP TS 33.501 17.0.0, December 2020.

Appendix A.  Updated references

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

   All references to [RFC2560] are updated with [RFC6960].

   All references to [RFC3280] are updated with [RFC5280].

   All references to [RFC4282] are updated with [RFC7542].

Acknowledgments

   The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton,
   Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar,
   Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa
   Torvinen, and Hannes Tschofenig for comments and suggestions on the
   draft.

Contributors

   Alan DeKok, FreeRADIUS

Authors' Addresses

   John Preuss Mattsson
   Ericsson
    Stockholm  164 40
   Sweden

   Email: john.mattsson@ericsson.com

   Mohit Sethi
   Ericsson
   Jorvas  02420
   Finland

   Email: mohit@piuha.net

Mattsson & Sethi         Expires August 6, 2021                [Page 32]