<?xml version="1.0" ?>
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'[] >

<?rfc compact="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-emu-eap-tls13-21" updates="5216"> number="9190" updates="5216" obsoletes="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true"
symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="EAP-TLS 1.3"> 1.3">EAP-TLS 1.3: Using EAP-TLS the Extensible
    Authentication Protocol with TLS 1.3 (EAP-TLS 1.3)
	</title> 1.3</title>

    <seriesInfo name="RFC" value="9190"/>
    <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street/>
				<city> Stockholm</city>
          <city>Kista</city>
          <code>164 40</code>
          <country>Sweden</country>
        </postal>
        <email>john.mattsson@ericsson.com</email>
      </address>
    </author>
    <author initials="M" surname="Sethi" fullname="Mohit Sethi">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street/>
          <city>Jorvas</city>
          <code>02420</code>
          <country>Finland</country>
        </postal>
			<email>mohit@piuha.net</email>
        <email>mohit@iki.fi</email>
      </address>
    </author>
    <date />

	<workgroup>Network Working Group</workgroup> year="2022" month="February"/>
    <workgroup>EMU</workgroup>

<keyword>Extensible Authentication Protocol</keyword>
<keyword>IEEE 802</keyword>
<keyword>5G</keyword>
<keyword>authentication</keyword>
<keyword>identity protection</keyword>
<keyword>privacy</keyword>
<keyword>forward secrecy</keyword>

    <abstract>

      <t>
	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) EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-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, checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216.
      </t>
    </abstract>
  </front>
  <middle>
    <section title='Introduction'> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Extensible Authentication Protocol (EAP), defined in <xref target="RFC3748"/>,
      target="RFC3748" format="default"/>, provides a standard mechanism for
      support of multiple authentication methods. EAP-Transport Layer Security (EAP-TLS) EAP-TLS <xref target="RFC5216"/>
      target="RFC5216" format="default"/> specifies an EAP authentication
      method with certificate-based mutual authentication utilizing the TLS
      handshake protocol for cryptographic algorithms and protocol version
      negotiation and establishment of shared secret keying material. EAP-TLS
      is widely supported for authentication and key establishment in IEEE
      802.11 <xref target="IEEE-802.11"/> target="IEEE-802.11" format="default"/> (Wi-Fi) and IEEE
      802.1AE <xref target="IEEE-802.1AE"/> target="IEEE-802.1AE" format="default"/> (MACsec) networks
      using IEEE 802.1X <xref target="IEEE-802.1X"/> target="IEEE-802.1X" format="default"/> and it's
      the default mechanism for certificate based certificate-based authentication in 3GPP 5G
      <xref target="TS.33.501"/> target="TS.33.501" format="default"/> and MulteFire <xref target="MulteFire"/>
      target="MulteFire" format="default"/> networks.

Many other EAP methods such as EAP-FAST <xref target="RFC4851"/>, EAP-TTLS Flexible Authentication via Secure Tunneling
(EAP-FAST) <xref target="RFC4851" format="default"/>, Tunneled Transport Layer
Security (EAP-TTLS) <xref target="RFC5281"/>, TEAP target="RFC5281" format="default"/>, the Tunnel
Extensible Authentication Protocol (TEAP) <xref target="RFC7170"/>, and PEAP target="RFC7170"
format="default"/>, as well as vendor-specific EAP methods such as the
Protected Extensible Authentication Protocol (PEAP) <xref target="PEAP"/> target="PEAP"
format="default"/>, depend on TLS and EAP-TLS.</t> EAP-TLS.

      </t>

      <t>EAP-TLS <xref target="RFC5216"/> target="RFC5216" format="default"/> references TLS 1.0
      <xref target="RFC2246"/> target="RFC2246" format="default"/> and TLS 1.1 <xref target="RFC4346"/>,
      target="RFC4346" format="default"/> but can also work with TLS 1.2 <xref target="RFC5246"/>.
      target="RFC5246" format="default"/>. TLS 1.0 and 1.1 are formally
      deprecated and prohibited to negotiate and use from being negotiated or used <xref target="RFC8996"/>. target="RFC8996"
      format="default"/>. Weaknesses found in TLS 1.2, 1.2 as well as new
      requirements for security, privacy, and reduced latency have led to the
      specification of TLS 1.3 <xref target="RFC8446"/>, target="RFC8446" format="default"/>,
      which obsoletes TLS 1.2 <xref target="RFC5246"/>. target="RFC5246" format="default"/>. TLS
      1.3 is in large parts part a complete remodeling of the TLS handshake
      protocol including a different message flow, different handshake
      messages, different key schedule, different cipher suites, different
      resumption mechanism, different privacy protection, and different record
      padding. This means that significant parts of the normative text in the
      previous EAP-TLS specification <xref target="RFC5216"/> target="RFC5216" format="default"/>
      are not applicable to EAP-TLS with TLS 1.3. Therefore, aspects such as
      resumption, privacy handling, and key derivation need to be
      appropriately addressed for EAP-TLS with TLS 1.3.</t>
      <t>This document updates <xref target="RFC5216"/> target="RFC5216" format="default"/> to define how to use EAP-TLS with TLS 1.3. When older TLS versions are negotiated, RFC 5216 applies to maintain backwards compatibility. However, this document does provide additional guidance on authentication, authorization, and resumption for EAP-TLS regardless of the underlying TLS version used. This document only describes differences compared to <xref target="RFC5216"/>. target="RFC5216" format="default"/>. When EAP-TLS is used with TLS 1.3, some references are updated as specified in <xref target="updateref"/>. target="updateref" format="default"/>. All message flow flows are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state machine with the EAP state machine machine, it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol. Therefore, implementations MUST <bcp14>MUST</bcp14> limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator.</t>
      <t>This document specifies EAP-TLS 1.3 and does not specify how other TLS-based EAP methods use TLS 1.3. The specification for how other TLS-based EAP methods use TLS 1.3 is left to other documents such as <xref target="I-D.ietf-emu-tls-eap-types"/>.</t> target="I-D.ietf-emu-tls-eap-types" format="default"/>.</t>
      <t>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 no information about the underlying peer identity is disclosed, is mandatory and achieved without any additional round-trips. round trips. Revocation checking is mandatory and simplified with OCSP Online Certificate Status Protocol (OCSP) stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS.</t>
      <section title='Requirements numbered="true" toc="default">
        <name>Requirements and Terminology'>
		<t>The Terminology</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target='RFC2119'/> target="RFC2119"/> <xref target='RFC8174'/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

	<t>Readers are expected to be familiar with the terms and concepts used in EAP-TLS <xref target="RFC5216"/> target="RFC5216" format="default"/> and TLS <xref target="RFC8446"/>. target="RFC8446" format="default"/>. 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.</t>
        <t>This document follows the terminology from <xref target="I-D.ietf-tls-rfc8446bis"/> target="I-D.ietf-tls-rfc8446bis" format="default"/> where the master secret is renamed to the main secret and the exporter_master_secret is renamed to the exporter_secret.</t>
      </section>
    </section>

    <section title='Protocol Overview'> numbered="true" toc="default">
      <name>Protocol Overview</name>
      <section title='Overview numbered="true" toc="default">
        <name>Overview of the EAP-TLS Conversation'> Conversation</name>
        <t>This section updates Section 2.1 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of"
        section="2.1" format="default"/> by amending it in accordance with the
        following discussion.</t>
        <t>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 to correctly support EAP-TLS 1.3 as well as to maintain
        backward compatibility with EAP-TLS 1.2.</t>
        <t>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 <xref target="RFC5216"/>
        target="RFC5216" sectionFormat="of" section="2.1" format="default"/>
        does not apply for TLS 1.3. Except for Sections <xref
        target="identity" format="counter"/> and <xref target="secres"
        format="counter"/>, this update applies only when TLS 1.3 is
        negotiated. When TLS 1.2 is negotiated, then <xref target="RFC5216"/> target="RFC5216"
        format="default"/> applies.</t>
        <t>TLS 1.3 introduces several new handshake messages including
        HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general, these
        messages will be handled by the underlying TLS libraries and are not
        visible to EAP-TLS, EAP-TLS; however, there are a few things to note:

			<list style="symbols">
			<t>The

        </t>
        <ul spacing="normal">
          <li>The HelloRetryRequest is used by the server to reject the
          parameters offered in the ClientHello and suggest new
          parameters. When this message is encountered encountered, it will increase the
          number of round trips used by the protocol.</t>

			<t>The protocol.</li>
          <li>The NewSessionTicket message is used to convey resumption information and is covered in Sections <xref target="ticket" format="counter"/> and <xref target="resumption" format="counter"/>.</t>

			<t>The format="counter"/>.</li>
          <li>The KeyUpdate message is used to update the traffic keys used on
          a TLS connection. EAP-TLS does not encrypt significant amounts of
          data so this functionality is not needed. Implementations SHOULD NOT
          <bcp14>SHOULD NOT</bcp14> send this message, however message; however, some TLS
          libraries may automatically generate and process this message.</t>

			<t>Early message.</li>
          <li>Early Data MUST NOT <bcp14>MUST NOT</bcp14> be used in EAP-TLS. EAP-TLS servers MUST NOT <bcp14>MUST NOT</bcp14> send an early_data extension and clients MUST NOT <bcp14>MUST NOT</bcp14> send an EndOfEarlyData message.</t>

			<t>Post-handshake message.</li>
          <li>Post-handshake authentication MUST NOT <bcp14>MUST NOT</bcp14> be used in EAP-TLS. Clients MUST NOT <bcp14>MUST NOT</bcp14> send a "post_handshake_auth" extension and Servers MUST NOT <bcp14>MUST NOT</bcp14> request post-handshake client authentication.</t>
			</list></t> authentication.</li>
        </ul>
        <t>After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in <xref target="RFC5216"/> target="RFC5216" format="default"/>, 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, the formatting and processing of the TLS handshake SHALL <bcp14>SHALL</bcp14> be done as specified in version 1.3 of TLS. This update only lists additional and different requirements, restrictions, and processing compared to <xref target="RFC8446"/> target="RFC8446" format="default"/> and <xref target="RFC5216"/>.</t> target="RFC5216" format="default"/>.</t>
        <section title='Authentication' anchor="section_auth"> anchor="section_auth" numbered="true" toc="default">
          <name>Authentication</name>
          <t>This section updates Section 2.1.1 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of" section="2.1.1"  format="default"/> by amending it in accordance with the following discussion.</t>

	  <t>The EAP-TLS server MUST <bcp14>MUST</bcp14> authenticate with a
	  certificate and SHOULD <bcp14>SHOULD</bcp14> 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 <bcp14>SHALL NOT</bcp14> be used except for
	  resumption. The full handshake in EAP-TLS with TLS 1.3 always
	  provides forward secrecy by exchange of ephemeral "key_share"
	  extensions in the ClientHello and ServerHello (e.g., containing ephemeral ECDHE
	  Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) public keys). SessionID is deprecated in TLS 1.3, 1.3;

	  see Sections 4.1.2 <xref target="RFC8446" section="4.1.2"
	  sectionFormat="bare" /> and 4.1.3 <xref target="RFC8446" section="4.1.3"
	  sectionFormat="bare"/> of <xref target="RFC8446"/>. TLS 1.3
	  introduced early application data which that like all application data
	  (other than the protected success indication described below) is not
	  used in EAP-TLS; see Section 4.2.10 of <xref target="RFC8446"/> target="RFC8446" sectionFormat="of"
	  section="4.2.10" format="default"/> for additional information on
	  the "early_data" extension. Resumption is handled as described in
	  <xref target="resumption"/>. target="resumption" format="default"/>. As a protected success
	  indication <xref target="RFC3748"/> target="RFC3748" format="default"/>, the EAP-TLS
	  server always sends TLS application data 0x00, 0x00; see Section 2.5. <xref
	  target="state"/>. Note that a TLS implementation MAY <bcp14>MAY</bcp14>
	  not allow the EAP-TLS layer to control in which order things are
	  sent and the application data MAY <bcp14>MAY</bcp14> therefore be sent
	  before a NewSessionTicket. TLS application data 0x00 is therefore to
	  be interpreted as success after the EAP-Request that contains TLS
	  application data 0x00. After the EAP-TLS server has sent an
	  EAP-Request containing the TLS application data 0x00 and received an
	  EAP-Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS
	  server sends EAP-Success.</t>
          <t><xref target="figbase1"/> target="figbase1" format="default"/> shows an example
          message flow for a successful EAP-TLS full handshake with mutual
          authentication (and neither HelloRetryRequest nor post-handshake
          messages are sent).</t>
          <figure anchor="figbase1" title="EAP-TLS mutual authentication" align="center"><artwork><![CDATA[ anchor="figbase1">
            <name>EAP-TLS Mutual Authentication</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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
]]></artwork></figure>
]]></artwork>
          </figure>
        </section>

	<section title='Ticket Establishment' anchor="ticket"> anchor="ticket" numbered="true" toc="default">
          <name>Ticket Establishment</name>
          <t>This is a new section when compared to <xref target="RFC5216"/>.</t> target="RFC5216" format="default"/>.</t>

          <t>To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS server MUST <bcp14>MUST</bcp14> send one or more post-handshake NewSessionTicket messages (each associated with a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication. Note that TLS 1.3 <xref target="RFC8446"/> target="RFC8446" format="default"/> limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS servers MUST <bcp14>MUST</bcp14> 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 NewSessionTicket can be sent in the same flight as the TLS server Finished or later. The PSK associated with the ticket depends on the client Finished and cannot be pre-computed (so as to be sent in the same flight as the TLS server Finished) in handshakes with client authentication. The NewSessionTicket message MUST NOT <bcp14>MUST NOT</bcp14> include an "early_data" extension. If the "early_data" extension is received received, then it MUST <bcp14>MUST</bcp14> 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 cases, a single NewSessionTicket will be sufficient. A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in <xref target="I-D.ietf-tls-ticketrequests"/>.</t> target="I-D.ietf-tls-ticketrequests" format="default"/>.</t>
          <t><xref target="figbase2"/> target="figbase2" format="default"/> shows an example message flow for a successful EAP-TLS full handshake with mutual authentication and ticket establishment of a single ticket.</t>
          <figure anchor="figbase2" title="EAP-TLS ticket establishment" align="center"><artwork><![CDATA[ anchor="figbase2">
            <name>EAP-TLS Ticket Establishment</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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
]]></artwork></figure>
]]></artwork>
          </figure>
        </section>
        <section title="Resumption" anchor="resumption"> anchor="resumption" numbered="true" toc="default">
          <name>Resumption</name>
          <t>This section updates Section 2.1.2 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of" section="2.1.2" format="default"/> by amending it in accordance with the following discussion.</t>
          <t>EAP-TLS is typically used with client authentication and
          typically fragments the TLS flights into a large number of EAP requests
          EAP-requests and EAP responses. EAP-responses. Resumption significantly reduces the
          number of round-trips round trips and enables the EAP-TLS server to omit
          database lookups needed during a full handshake with client
          authentication. 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, EAP-TLS SHALL <bcp14>SHALL</bcp14> use a
          resumption mechanism compatible with version 1.3 of TLS.</t>
          <t>For TLS 1.3, resumption is described in Section 2.2 of <xref target="RFC8446"/>. target="RFC8446"
          sectionFormat="of" section="2.2" format="default"/>. If the client
          has received a NewSessionTicket message from the EAP-TLS server, the
          client can use the PSK identity associated with the ticket to
          negotiate the use of the associated PSK. If the EAP-TLS server
          accepts it, then the resumed session has been deemed to be authenticated,
          authenticated and securely associated with the prior authentication
          or resumption. It is up to the EAP-TLS peer to use resumption, but
          it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the EAP-TLS peer use
          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 <bcp14>RECOMMENDED</bcp14> that the EAP-TLS
          server accept resumption if the ticket which that was issued is still
          valid. However, the EAP-TLS server MAY <bcp14>MAY</bcp14> choose to
          require a full handshake. In the case a full handshake is required,
          the negotiation proceeds as if the session was a new authentication,
          and the resumption attempt is ignored. The requirements of Sections
          <xref target="section_auth" format="counter"/> and <xref
          target="ticket" format="counter"/> then apply in their entirety. As
          described in Appendix C.4 of <xref target="RFC8446"/>, target="RFC8446" format="default"
          sectionFormat="of" section="C.4" />, reuse of a ticket allows
          passive observers to correlate different connections. EAP-TLS peers
          and EAP-TLS servers SHOULD <bcp14>SHOULD</bcp14> follow the client tracking
          preventions in Appendix C.4 of <xref target="RFC8446"/>.</t> target="RFC8446" format="default"
          sectionFormat="of" section="C.4" />.</t>
          <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use a Network Access
          Identifiers (NAIs) with the same realm during resumption and the
          original full handshake. This requirement allows EAP packets to be
          routed to the same destination as the original full handshake. If
          this recommendation is not followed, resumption is likely
          impossible. When NAI reuse can be done without privacy implications,
          it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use the same NAI in the resumption,
          resumption as was used in the original full handshake <xref target="RFC7542"/>.
          target="RFC7542" format="default"/>. 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
          on its own is therefore unsuitable as a an NAI in the Identity
          Response.</t>
          <t><xref target="figresumption"/> target="figresumption" format="default"/> shows an example message flow for a subsequent successful EAP-TLS resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server provisions a single new ticket.</t>
          <figure anchor="figresumption" title="EAP-TLS resumption" align="center"><artwork><![CDATA[ anchor="figresumption">
            <name>EAP-TLS Resumption</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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
]]></artwork></figure>
]]></artwork>
          </figure>
          <t>As specified in Section 2.2 of <xref target="RFC8446"/>, target="RFC8446" sectionFormat="of"
          section="2.2" format="default"/>, the EAP-TLS peer SHOULD
          <bcp14>SHOULD</bcp14> 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 a 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 compromise of the PSK used for
          resumption does not compromise any earlier connections. The
          "psk_dh_ke" key-exchange key exchange mode MUST <bcp14>MUST</bcp14> be used for
          resumption unless the deployment has a local requirement to allow
          configuration of other mechanisms.</t>
        </section>
        <section title='Termination'> numbered="true" toc="default">
          <name>Termination</name>
          <t>This section updates Section 2.1.3 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of" section="2.1.3" format="default"/> by amending it in accordance with the following discussion.</t>
          <t>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 <xref target="RFC5216"/> target="RFC5216" sectionFormat="of" section="2.1.3"
          format="default"/> does not apply for TLS 1.3. The two paragraphs
          below replace the corresponding paragraphs in Section 2.1.3 of <xref target="RFC5216"/> target="RFC5216"
          sectionFormat="of" section="2.1.3" format="default"/> when EAP-TLS
          is used with TLS 1.3. The other paragraphs in Section 2.1.3 of <xref target="RFC5216"/> target="RFC5216"
          sectionFormat="of" section="2.1.3" format="default"/> still apply
          with the exception that SessionID is deprecated.
			<list>
				<t>If
          </t>

	    <t indent="3">If the EAP-TLS peer authenticates successfully, the EAP-TLS
	    server MUST <bcp14>MUST</bcp14> 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.</t>

				<t>If
            <t indent="3">If the EAP-TLS server authenticates successfully, the EAP-TLS
            peer MUST <bcp14>MUST</bcp14> send an EAP-Response message with
            EAP-Type=EAP-TLS containing TLS records conforming to the version
            of TLS used.</t>
			</list> used.
	    </t>

<t>Figures <xref target="figterm1" format="counter"/>, <xref target="figterm2" format="counter"/>, and <xref target="figterm3" format="counter"/> 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, normally; see <xref target="RFC8446"/>.</t> target="RFC8446" format="default"/>.</t>
          <t>In TLS 1.3 <xref target="RFC8446"/>, target="RFC8446" format="default"/>, 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 <bcp14>MUST</bcp14> send an appropriate TLS Error alert.</t>
          <t><xref target="figterm1"/> target="figterm1" format="default"/> 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, HelloRetryRequest; see <xref target="helloretry"/>.</t> target="helloretry" format="default"/>.</t>
          <figure anchor="figterm1" title="EAP-TLS server rejection anchor="figterm1">
            <name>EAP-TLS Server Rejection of ClientHello" align="center"><artwork><![CDATA[ ClientHello</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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
]]></artwork></figure>
]]></artwork>
          </figure>
          <t><xref target="figterm2"/> target="figterm2" format="default"/> shows an example message flow where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS Error alert.</t>
          <figure anchor="figterm2" title="EAP-TLS unsuccessful anchor="figterm2">
            <name>EAP-TLS Unsuccessful EAP-TLS server authentication" align="center"><artwork><![CDATA[ Server Authentication</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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
]]></artwork></figure>
]]></artwork>
          </figure>
          <t><xref target="figterm3"/> target="figterm3" format="default"/> 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.</t>
          <figure anchor="figterm3" title="EAP-TLS unsuccessful client authentication" align="center"><artwork><![CDATA[ anchor="figterm3">
            <name>EAP-TLS Unsuccessful Client Authentication</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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
]]></artwork></figure>
]]></artwork>
          </figure>
        </section>
        <section title='No numbered="true" toc="default">
          <name>No Peer Authentication'> Authentication</name>
          <t>This is a new section when compared to <xref target="RFC5216"/>.</t> target="RFC5216" format="default"/>.</t>
          <t><xref target="figbase3"/> target="figbase3" format="default"/> shows an example message flow for a successful EAP-TLS full handshake without peer authentication (e.g., emergency services, as described in <xref target="RFC7406"/>).</t> target="RFC7406" format="default"/>).</t>
          <figure anchor="figbase3" title="EAP-TLS anchor="figbase3">
            <name>EAP-TLS without peer authentication" align="center"><artwork><![CDATA[ Peer Authentication</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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
]]></artwork></figure>
]]></artwork>
          </figure>
        </section>
        <section title="Hello anchor="helloretry" numbered="true" toc="default">
          <name>Hello Retry Request" anchor="helloretry"> Request</name>
          <t>This is a new section when compared to <xref target="RFC5216"/>.</t> target="RFC5216" format="default"/>.</t>
          <t>As defined in TLS 1.3 <xref target="RFC8446"/>, target="RFC8446" format="default"/>,
          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), extension) but supports one of
          the groups in the "supported_groups" extension. In this case case, the
          client should send a new ClientHello with a "key_share" that the
          EAP-TLS server supports.</t>
          <t><xref target="fighelloretryrequest"/> target="fighelloretryrequest" format="default"/> shows an example message flow for a successful EAP-TLS full handshake with mutual authentication and HelloRetryRequest. Note the extra round-trip round trip as a result of the HelloRetryRequest.</t>
          <figure anchor="fighelloretryrequest" title="EAP-TLS anchor="fighelloretryrequest">
            <name>EAP-TLS with Hello Retry Request" align="center"><artwork><![CDATA[ Request</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 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
]]></artwork></figure>
]]></artwork>
          </figure>
        </section>
        <section title='Identity'> numbered="true" toc="default">
          <name>Identity</name>
          <t>This is a new section when compared to <xref target="RFC5216"/>.</t> target="RFC5216" format="default"/>.</t>
          <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use anonymous NAIs <xref target="RFC7542"/>
          target="RFC7542" format="default"/> in the Identity Response as such
          identities are routable and privacy-friendly. While opaque blobs are
          allowed by <xref target="RFC3748"/>, target="RFC3748" format="default"/>, such
          identities are NOT RECOMMENDED <bcp14>NOT RECOMMENDED</bcp14> 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 an NAI as subject name or alternative
          subject name, an anonymous NAI SHOULD <bcp14>SHOULD</bcp14> be derived from
          the NAI in the certificate, certificate; see <xref target="privacy"/>. target="privacy"
          format="default"/>. More details on identities are described in
          Sections <xref target="resumption" format="counter"/>, <xref
          target="privacy" format="counter"/>, <xref target="identity"
          format="counter"/>, and <xref target="privcon"
          format="counter"/>.</t>
        </section>
        <section title="Privacy" anchor="privacy"> anchor="privacy" numbered="true" toc="default">
          <name>Privacy</name>
          <t>This section updates Section 2.1.4 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of"
          section="2.1.4" format="default"/> by amending it in accordance with
          the following discussion.</t>
          <t>EAP-TLS 1.3 significantly improves privacy when compared to
          earlier versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites
          without confidentiality confidentiality, which means that TLS 1.3 is always
          encrypting large parts of the TLS handshake including the
          certificate messages.</t>

          <t>EAP-TLS peer and server implementations supporting TLS 1.3 MUST
          <bcp14>MUST</bcp14> support anonymous Network Access Identifiers
          (NAIs) (Section 2.4 in <xref target="RFC7542"/>) and a (<xref target="RFC7542" sectionFormat="of" section="2.4"
          format="default"/>). A client supporting TLS 1.3 MUST NOT <bcp14>MUST
          NOT</bcp14> send its username (or any other permanent identifiers)
          in cleartext in the Identity Response. Response (or any message used instead
          of the Identity Response). Following <xref target="RFC7542"/>, target="RFC7542"
          format="default"/>, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> 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 <bcp14>MUST</bcp14> be a UTF-8 string as
          defined by the grammar in Section 2.2 of <xref target="RFC7542"/>.</t> target="RFC7542" section="2.2"
          sectionFormat="of" format="default"/>.</t>
          <t>The HelloRequest message used for privacy in EAP-TLS 1.2 does not exist in TLS 1.3 but 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 1.3, the EAP-TLS peer and EAP-TLS server SHALL <bcp14>SHALL</bcp14> follow the processing specified by version 1.3 of TLS. 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 <bcp14>MAY</bcp14> treat an empty certificate_list as a terminal condition.</t>
          <t>EAP-TLS with TLS 1.3 is always used with privacy. This does not add any extra round-trips round trips and the message flow with privacy is just the normal message flow as shown in <xref target="figbase1"/>.</t> target="figbase1" format="default"/>.</t>
        </section>
        <section title='Fragmentation'> numbered="true" toc="default">
          <name>Fragmentation</name>
          <t>This section updates Section 2.1.5 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of" section="2.1.5" format="default"/> by amending it in accordance with the following discussion.</t>
          <t>Including ContentType (1 byte), ProtocolVersion (2 bytes), and
          length (2 bytes) headers 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 (conditional) TLS Message Length field of four
          octets. Implementations MUST NOT <bcp14>MUST NOT</bcp14> set the L bit in
          unfragmented messages, but MUST they <bcp14>MUST</bcp14> accept unfragmented
          messages with and without the L bit set.</t>
          <t>Some EAP implementations and access networks may limit the number
          of EAP packet exchanges that can be handled. To avoid fragmentation,
          it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> 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
          <bcp14>RECOMMENDED</bcp14> to use mechanisms that reduce the sizes
          of Certificate messages. For a detailed discussion on reducing
          message sizes to prevent fragmentation, see <xref target="I-D.ietf-emu-eaptlscert"/>.</t> target="RFC9191"
          format="default"/>.</t>
        </section>
      </section>
      <section title='Identity Verification' anchor="identity"> anchor="identity" numbered="true" toc="default">
        <name>Identity Verification</name>
        <t>This section updates Section 2.2 of replaces <xref target="RFC5216"/> by amending it in accordance target="RFC5216" sectionFormat="of"
        section="2.2" format="default"/> with the following discussion. The
        guidance in this section is relevant for EAP-TLS in general
        (regardless of the underlying TLS version used).</t>
        <t>The EAP peer identity provided in the EAP-Response/Identity is not
        authenticated by EAP-TLS. Unauthenticated information MUST NOT <bcp14>MUST
        NOT</bcp14> be used for accounting purposes or to give
        authorization. The authenticator and the EAP-TLS server MAY
        <bcp14>MAY</bcp14> examine the identity presented in
        EAP-Response/Identity for purposes such as routing and EAP method
        selection. EAP-TLS servers MAY <bcp14>MAY</bcp14> reject conversations if
        the identity does not match their policy. Note that this also applies
        to resumption, resumption; see Sections <xref target="resumption"
        format="counter"/>, <xref target="secauth" format="counter"/>, and
        <xref target="secres" format="counter"/>.</t>
        <t>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 <bcp14>SHOULD</bcp14> allow for the 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 in the server certificate. If any of the configured names match any of the names in the SAN extension extension, then the name check passes. To simplify name matching, an EAP-TLS deployment can assign a name to represent an authorized EAP server and EAP Server certificates can include this name in the list of SANs for each certificate that represents an EAP-TLS server. If server name matching is not used, then it degrades the confidence that the EAP server with which it is interacting is authoritative for the given network. If name matching is not used with a public root CA, then effectively any server can obtain a certificate which that will be trusted for EAP authentication by the Peer. peer. While this guidance to verify domain names is new, and was not mentioned in <xref target="RFC5216"/>, target="RFC5216" format="default"/>, it has been widely implemented in EAP-TLS peers. As such, it is believed that this section contains minimal new interoperability or implementation requirements on EAP-TLS peers and can be applied to earlier versions of TLS.</t>

        <t>The process of configuring a root CA certificate and a server name is non-trivial and therefore non-trivial; therefore, automated methods of provisioning are RECOMMENDED. <bcp14>RECOMMENDED</bcp14>. For example, the eduroam federation <xref target="RFC7593"/> target="RFC7593" format="default"/> provides a Configuration Assistant Tool (CAT) to automate the configuration process. In the absence of a trusted root CA certificate (user configured or system-wide), EAP peers MAY <bcp14>MAY</bcp14> 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 ensures that the server presents the same stored certificate on subsequent interactions. Use of a TOFU mechanism does not allow for the server certificate to change without out-of-band validation of the certificate and is therefore 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 and should only be used if there are adequate controls in place to mitigate this risk.</t>
      </section>

      <section title='Key Hierarchy' anchor="keyheirarchy"> anchor="keyhierarchy" numbered="true" toc="default">
        <name>Key Hierarchy</name>

        <t>This section updates Section 2.3 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of" section="2.3" format="default"/> by replacing it in accordance with the following discussion.</t>
        <t>TLS 1.3 replaces the TLS pseudorandom function (PRF) used in
        earlier versions of TLS with HKDF the HMAC-based Key Derivation Function
        (HKDF) and completely changes the Key Schedule. key schedule. The key hierarchies
        shown in Section 2.3 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of" section="2.3"
        format="default"/> are therefore 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 <xref target="RFC8446"/>.</t>
        target="RFC8446" sectionFormat="of" section="7.1"
        format="default"/>.</t>
        <t>When EAP-TLS is used with TLS version 1.3 1.3, the Key_Material and
        Method-Id SHALL <bcp14>SHALL</bcp14> be derived from the exporter_secret
        using the TLS exporter interface <xref target="RFC5705"/> target="RFC5705"
        format="default"/> (for TLS 1.3 1.3, this is defined in Section 7.5 of <xref target="RFC8446"/>).
        target="RFC8446" sectionFormat="of" section="7.5"
        format="default"/>). Type is the value of the EAP Type field defined
        in Section 2 of <xref target="RFC3748"/>. target="RFC3748" section="2" sectionFormat="of"
        format="default"/>. For EAP-TLS EAP-TLS, the Type field has value 0x0D.</t>

<figure><artwork><![CDATA[
        <sourcecode><![CDATA[
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
]]></artwork></figure>
]]></sourcecode>
        <t>The MSK and EMSK are derived from the Key_Material in the same
        manner as with EAP-TLS <xref target="RFC5216"/>, Section 2.3. target="RFC5216" sectionFormat="comma"
        section="2.3" format="default"/>. The definitions are repeated below
        for simplicity:</t>

<figure><artwork><![CDATA[
        <sourcecode><![CDATA[
MSK          = Key_Material(0, 63)
EMSK         = Key_Material(64, 127)
]]></artwork></figure>
]]></sourcecode>

        <t>Other TLS based TLS-based EAP methods can use the TLS exporter in a similar fashion,
        fashion; see <xref target="I-D.ietf-emu-tls-eap-types"/>.</t> target="I-D.ietf-emu-tls-eap-types"
        format="default"/>.</t>
        <t><xref target="RFC5247"/> target="RFC5247" format="default"/> deprecates the use of IV. an
        Initialization Vector (IV). Thus, RECV-IV and SEND-IV are not exported
        in EAP-TLS with TLS 1.3. As noted in <xref target="RFC5247"/>, target="RFC5247"
        format="default"/>, 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 is used by lower layers.</t>
        <t>Note that the key derivation MUST <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> 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.</t>
        <t>By using the TLS exporter, EAP-TLS can use any TLS 1.3
        implementation which that provides a public API for the exporter. Note that
        when TLS 1.2 is used with the EAP-TLS exporter <xref target="RFC5705"/> target="RFC5705"
        format="default"/> it generates the same key material as in EAP-TLS
        <xref target="RFC5216"/>.</t> target="RFC5216" format="default"/>.</t>
      </section>
      <section title='Parameter numbered="true" toc="default">
        <name>Parameter Negotiation and Compliance Requirements'> Requirements</name>
        <t>This section updates Section 2.4 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of" section="2.4" format="default"/> by amending it in accordance with the following discussion.</t>
        <t>TLS 1.3 cipher suites are defined differently than in earlier
        versions of TLS (see Section B.4 of <xref target="RFC8446"/>), target="RFC8446" section="B.4"
        sectionFormat="of" format="default"/>), and the cipher suites
        discussed in Section 2.4 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of" section="2.4"
        format="default"/> can therefore not be used when EAP-TLS is used with
        TLS version 1.3.</t>
        <t>When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST <bcp14>MUST</bcp14> comply with the compliance requirements (mandatory-to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of <xref target="RFC8446"/>. target="RFC8446" sectionFormat="of" section="9" format="default"/>. In EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL <bcp14>SHALL</bcp14> be supported.</t>
        <t>While EAP-TLS does not protect any application data except for the 0x00 byte that serves as protected success indication, the negotiated cipher suites and algorithms MAY <bcp14>MAY</bcp14> be used to secure data as done in other TLS-based EAP methods.</t>
      </section>
      <section title='EAP anchor="state" numbered="true" toc="default">
        <name>EAP State Machines' anchor="state"> Machines</name>
        <t>This is a new section when compared to <xref target="RFC5216"/> target="RFC5216" format="default"/> and only applies to TLS 1.3. <xref target="RFC4137"/> target="RFC4137" format="default"/> offers a proposed state machine for EAP.</t>

	<t>TLS 1.3 <xref target="RFC8446"/> target="RFC8446" format="default"/> introduces
        post-handshake messages. These post-handshake messages use the
        handshake content type and can be sent after the main
        handshake. Examples of post-handshake messages are NewSessionTicket,
        which is 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.</t>
        <t>To provide a protected success result indication and to decrease the uncertainty for the EAP-TLS peer, the following procedure MUST <bcp14>MUST</bcp14> be followed:</t>
        <t>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. The encrypted TLS record with application data
        0x00 is a protected success result indication, as defined in <xref target="RFC3748"/>.
        target="RFC3748" format="default"/>. After sending an EAP-Request that
        contains the protected success result indication, the EAP-TLS server
        must not send any more EAP-Request EAP-Requests and may only send an
        EAP-Success. The EAP-TLS server MUST NOT <bcp14>MUST NOT</bcp14> send an
        encrypted TLS record with application data 0x00 alert before it has
        successfully processed the client finished Finished and sent its last handshake
        message.</t>

        <t>TLS Error alerts SHOULD <bcp14>SHOULD</bcp14> be considered a failure
        result indication, as defined in <xref target="RFC3748"/>. target="RFC3748"
        format="default"/>. Implementations following <xref target="RFC4137"/> target="RFC4137"
        format="default"/> 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.</t>
        <t>The keying material can be derived after the TLS server Finished
        has been sent or received. Implementations following <xref target="RFC4137"/>
        target="RFC4137" format="default"/> can then set the eapKeyData and
        aaaEapKeyData variables.</t>
        <t>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 <xref target="RFC4137"/>
        target="RFC4137" format="default"/> can set the eapKeyAvailable and
        aaaEapKeyAvailable variables.</t>
      </section>
    </section>
    <section title='Detailed numbered="true" toc="default">
      <name>Detailed Description of the EAP-TLS Protocol'>
	<t>No Protocol</name>
      <t>There are no updates to Section 3 of <xref target="RFC5216"/>.</t> target="RFC5216" section="3" sectionFormat="of"
      format="default"/>.</t>
    </section>
    <section title='IANA considerations'> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>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 <xref target="RFC8126"/>.</t>

	<t>This document requires target="RFC8126" format="default"/>.</t>
      <t>Per this document, IANA to add has added the following labels to the TLS "TLS
      Exporter Label Registry Labels" registry defined by <xref target="RFC5705"/>. target="RFC5705"
      format="default"/>. These labels are used in derivation of Key_Material
      and Method-Id as defined in <xref target="keyheirarchy"/>:</t>
	<texttable title="TLS target="keyhierarchy"
      format="default"/>:</t>
      <table anchor="exporter-label" align="center">
        <name>TLS Exporter Label Registry" anchor="exporter-label">
            <ttcol align="left">Value</ttcol>
            <ttcol align="left">DTLS-OK</ttcol>
            <ttcol align="left">Recommended</ttcol>
            <ttcol align="left">Note</ttcol>
            <c>EXPORTER_EAP_TLS_Key_Material</c>
            <c>N</c>
            <c>Y</c>
            <c></c>
            <c></c><c></c><c></c><c></c>
            <c>EXPORTER_EAP_TLS_Method-Id</c>
            <c>N</c>
            <c>Y</c>
            <c></c>
    </texttable> Labels</name>
        <thead>
          <tr>
            <th align="left">Value</th>
            <th align="left">DTLS-OK</th>
            <th align="left">Recommended</th>
            <th align="left">Note</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">EXPORTER_EAP_TLS_Key_Material</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="left"/>
          </tr>

          <tr>
            <td align="left">EXPORTER_EAP_TLS_Method-Id</td>
            <td align="center">N</td>
            <td align="center">Y</td>
            <td align="left"/>
          </tr>
        </tbody>
      </table>
    </section>
    <section title='Security Considerations' anchor="seccon"> anchor="seccon" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations of TLS 1.3 <xref target="RFC8446"/> target="RFC8446" format="default"/> apply to EAP-TLS 1.3</t> 1.3.</t>
      <section title="Security Claims"> numbered="true" toc="default">
        <name>Security Claims</name>
        <t>Using EAP-TLS with TLS 1.3 does not change the security claims for EAP-TLS as given in Section 5.1 of <xref target="RFC5216"/>. target="RFC5216" sectionFormat="of" section="5.1" format="default"/>. However, it strengthens several of the claims as described in the following updates to the notes given in Section 5.1 of <xref target="RFC5216"/>.</t>

		<t>[1] target="RFC5216" sectionFormat="of" section="5.1" format="default"/>.</t>

	<dl indent="4">
	  <dt>[1] Mutual authentication: By
	  </dt>
	  <dd>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.</t>

		<t>[2] fail.
	  </dd>

	  <dt>[2] Confidentiality: The
	  </dt>
	  <dd>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.</t>

		<t>[3] round trips.
	  </dd>

	  <dt>[3] Cryptographic strength: TLS
	  </dt>
	  <dd>TLS 1.3 only defines strong algorithms without major weaknesses
	  and EAP-TLS with TLS 1.3 always provides forward secrecy, secrecy; see [RFC8446]. <xref
	  target="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.</t>

		<t>[4] 1.3.
	  </dd>

	  <dt>[4] Cryptographic Negotiation: The negotiation:
	  </dt>
	  <dd>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, algorithm; see Section 4.1.1 of <xref target="RFC8446"/>.</t>
	  target="RFC8446" sectionFormat="of" section="4.1.1"
	  format="default"/>.
	  </dd>
</dl>

      </section>
      <section title="Peer numbered="true" toc="default">
        <name>Peer and Server Identities"> Identities</name>
        <t>No updates to section 5.2 of <xref target="RFC5216"/>. target="RFC5216" sectionFormat="of"
        section="5.2" format="default"/>. Note that <xref target="identity"/> target="identity"
        format="default"/> has additional discussion on identities.</t>
      </section>
      <section title="Certificate Validation"> numbered="true" toc="default">
        <name>Certificate Validation</name>
        <t>No updates to section 5.3 of <xref target="RFC5216"/>. target="RFC5216" sectionFormat="of" section="5.3" format="default"/>. In addition to section 5.3 of <xref target="RFC5216"/>, target="RFC5216" sectionFormat="of" section="5.3" format="default"/>, guidance on server certificate validation can be found in <xref target="RFC6125"/>.</t> target="RFC6125" format="default"/>.</t>
      </section>
      <section title="Certificate Revocation"> numbered="true" toc="default">
        <name>Certificate Revocation</name>
        <t>This section updates Section 5.4 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of" section="5.4" format="default"/> by amending it in accordance with the following discussion.</t>
        <t>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.</t>
        <t>When EAP-TLS is used with TLS 1.3, the revocation status of all the
        certificates in the certificate chains MUST <bcp14>MUST</bcp14> be checked
        (except the trust anchor). An implementation may use the Certificate
        Revocation List (CRL), Online Certificate Status Protocol (OSCP), or
        other standardized/proprietary methods for revocation
        checking. Examples of proprietary methods are non-standard formats for
        distribution of revocation lists as well as certificates with very
        short lifetime.</t>

        <t>EAP-TLS servers supporting TLS 1.3 MUST <bcp14>MUST</bcp14> implement
        Certificate Status Requests (OCSP stapling) as specified in <xref target="RFC6066"/>
        target="RFC6066" format="default"/> and Section 4.4.2.1 of <xref target="RFC8446"/>. target="RFC8446"
        sectionFormat="of" section="4.4.2.1" format="default"/>. It is RECOMMENDED
        <bcp14>RECOMMENDED</bcp14> 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 chain, it MUST <bcp14>MUST</bcp14> treat a CertificateEntry (except
        (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, TLS;
        see Section 4.4.2.1 of <xref target="RFC8446"/>. target="RFC8446" sectionFormat="of" section="4.4.2.1"
        format="default"/>. In TLS 1.3 1.3, the OCSP information is carried in the
        CertificateEntry containing the associated certificate instead of a
        separate CertificateStatus message as in <xref target="RFC6066"/>. target="RFC6066"
        format="default"/>. This enables sending OCSP information for all
        certificates in the certificate chain (except the trust anchor).</t>
        <t>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 <bcp14>MUST</bcp14> also support checking for certificate revocation after authentication completes and network connectivity is available. An EAP peer implementation SHOULD NOT <bcp14>SHOULD NOT</bcp14> trust the network (and any services) until it has verified the revocation status of the server certificate after receiving network connectivity. An EAP peer MUST <bcp14>MUST</bcp14> use a secure transport to verify the revocation status of the server certificate. An EAP peer SHOULD NOT <bcp14>SHOULD NOT</bcp14> send any other traffic before revocation checking for the server certificate is complete.</t>
      </section>
      <section title="Packet numbered="true" toc="default">
        <name>Packet Modification Attacks"> Attacks</name>
        <t>This section updates Section 5.5 of <xref target="RFC5216"/> target="RFC5216" sectionFormat="of"
        section="5.5" format="default"/> by amending it in accordance with the
        following discussion.</t>
        <t>As described in <xref target="RFC3748"/> target="RFC3748" format="default"/> and Section 5.5 of <xref target="RFC5216"/>,
        target="RFC5216" section="5.5" sectionFormat="of" format="default"/>,
        the only information that is integrity and replay protected in EAP-TLS
        are the parts of the TLS Data that TLS protects. All other information
        in the EAP-TLS message exchange including EAP-Request and EAP-Response
        headers, the identity in the identity response, Identity Response, EAP-TLS packet header
        fields, Type, and Flags, EAP-Success, and EAP-Failure can be modified,
        spoofed, or replayed.</t>
        <t>Protected TLS Error alerts are protected failure result indications
        and enables enable the EAP-TLS peer and EAP-TLS server to determine that the
        failure result was not spoofed by an attacker. Protected failure
        result indications provide integrity and replay protection but MAY
        <bcp14>MAY</bcp14> be unauthenticated. Protected failure results do
        not significantly improve availability as TLS 1.3 treats most
        malformed data as a fatal error.</t>
      </section>
      <section title="Authorization" anchor="secauth"> anchor="secauth" numbered="true" toc="default">
        <name>Authorization</name>
        <t>This is a new section when compared to <xref target="RFC5216"/>. target="RFC5216" format="default"/>. The guidance in this section is relevant for EAP-TLS in general (regardless of the underlying TLS version used).</t>
        <t>EAP servers will usually require the EAP peer to provide a valid
        certificate and will fail the connection if one is not provided. Some
        deployments may permit no peer authentication for some or all
        connections. When peer authentication is not used, EAP-TLS server
        implementations MUST <bcp14>MUST</bcp14> take care to limit network access
        appropriately for unauthenticated peers peers, and implementations MUST
        <bcp14>MUST</bcp14> 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.</t>
        <t>EAP-TLS is typically encapsulated in other protocols, protocols such as PPP
        <xref target="RFC1661"/>, target="RFC1661" format="default"/>, RADIUS <xref target="RFC2865"/>,
        target="RFC2865" format="default"/>, Diameter <xref target="RFC6733"/>, target="RFC6733"
        format="default"/>, or PANA the Protocol for Carrying Authentication for
        Network Access (PANA) <xref target="RFC5191"/>. target="RFC5191" format="default"/>. 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, Wi-Fi SSID, 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.</t>
        <t>As noted in <xref target="identity"/>, target="identity" format="default"/>, 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 <bcp14>MUST</bcp14> be based on
        authenticated information such as information in the certificate or
        the PSK identity and cached data provisioned for resumption as
        described in <xref target="secres"/>. target="secres" format="default"/>. Note that the
        requirements for Network Access Identifiers (NAIs) specified in Section 4 of <xref target="RFC7542"/>
        target="RFC7542" sectionFormat="of" section="4" format="default"/>
        still apply and MUST <bcp14>MUST</bcp14> be followed. </t>
        <t>EAP-TLS servers MAY <bcp14>MAY</bcp14> reject conversations based on
        non-EAP information provided by the encapsulating protocol, for example,
        example if the MAC address of the authenticator does not match the
        expected policy.</t>
        <t>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 <bcp14>MAY</bcp14> allow binding
        the configured acceptable SAN to a specific CA (or CAs) that should
        have issued the server certificate to prevent attacks from rogue or
        compromised CAs.</t>
      </section>

      <section title="Resumption" anchor="secres"> anchor="secres" numbered="true" toc="default">
        <name>Resumption</name>
        <t>This is a new section when compared to <xref target="RFC5216"/>. target="RFC5216"
        format="default"/>. The guidance in this section is relevant for
        EAP-TLS in general (regardless of the underlying TLS version
        used).</t>
        <t>There are a number of security issues related to resumption that
        are not described in <xref target="RFC5216"/>. target="RFC5216" format="default"/>. The
        problems, guidelines, and requirements in this section therefore applies apply
        to EAP-TLS when it is used with any version of TLS.</t>
        <t>When resumption occurs, it is based on cached information at the
        TLS layer. To perform resumption 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 such
        information. Authorization during resumption MUST <bcp14>MUST</bcp14> be
        based on such cached data. The EAP-TLS peer and EAP-TLS server MAY
        <bcp14>MAY</bcp14> perform fresh revocation checks on the cached
        certificate data. Any security policies for authorization MUST
        <bcp14>MUST</bcp14> 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 <bcp14>MAY</bcp14> force a full TLS handshake.</t>
        <t>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, ID; for TLS 1.3, the identifier is the PSK identity. The
        second method for retrieving cached information is via <xref target="RFC5077"/>
        target="RFC5077" format="default"/> or <xref target="RFC8446"/>, target="RFC8446"
        format="default"/>, where the EAP-TLS server avoids storing
        information locally and instead encapsulates the information into a
        ticket which 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 will obtain it 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 obtain the original handshake
        information.</t>
        <t>The EAP-TLS server or EAP client MUST <bcp14>MUST</bcp14> 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 <bcp14>MUST NOT</bcp14> be done.</t>
        <t>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 that expect to perform accounting for
        the session SHOULD <bcp14>SHOULD</bcp14> cache an identifier which that can be used
        in subsequent accounting.</t>
        <t>As suggested in <xref target="RFC8446"/>, target="RFC8446" format="default"/>, EAP-TLS
        peers MUST NOT <bcp14>MUST NOT</bcp14> store resumption PSKs or tickets (and
        associated cached data) for longer than 604800 seconds (7 days), days)
        regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY
        <bcp14>MAY</bcp14> delete them earlier based on local policy. The
        cached data MAY <bcp14>MAY</bcp14> 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.</t>

	<t>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.</t>
        <t>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 <bcp14>MUST</bcp14> be reevaluated. It is RECOMMENDED
        <bcp14>RECOMMENDED</bcp14> that authorization, accounting, and policy
        decisions are reevaluated based on the information given in the
        resumption. EAP-TLS servers MAY <bcp14>MAY</bcp14> 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 <bcp14>SHOULD</bcp14> reject
        the resumption and continue with a full handshake.</t>

		<t>Section 2.2
        <t>Sections <xref target="RFC8446" sectionFormat="bare" section="2.2"
        /> and 4.2.11 <xref target="RFC8446" section="4.2.11" sectionFormat="bare"/>
        of <xref target="RFC8446"/> provides provide security considerations for TLS
        1.3 resumption.</t>
      </section>
      <section title="Privacy Considerations" anchor="privcon"> anchor="privcon" numbered="true" toc="default">
        <name>Privacy Considerations</name>
        <t>This is a new section when compared to <xref target="RFC5216"/>.</t> target="RFC5216" format="default"/>.</t>
        <t>TLS 1.3 offers much better privacy than earlier versions of TLS as discussed in <xref target="privacy"/>. target="privacy" format="default"/>. 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 <xref target="RFC8446"/>.</t> target="RFC8446" format="default"/>.</t>
        <t>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.</t>
        <t>Tracking of users by eavesdropping on identity responses 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 username
        part of the identity response Identity Response is not revealed (e.g., 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 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.</t>
        <t>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
        <bcp14>SHOULD</bcp14> use record padding, padding; see Section 5.4 of <xref target="RFC8446"/> target="RFC8446"
        sectionFormat="of" section="5.4" format="default"/> to reduce
        information leakage of certificate sizes.</t>
        <t>If anonymous NAIs are not used, the privacy-friendly identifiers
        need to be generated with care. The identities MUST <bcp14>MUST</bcp14> 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 the pseudo-random usernames a single
        time. Note that the privacy-friendly usernames also MUST NOT <bcp14>MUST
        NOT</bcp14> include substrings that can be used to relate the identity
        to a specific user. Similarly, privacy-friendly username MUST NOT usernames <bcp14>MUST
        NOT</bcp14> be formed by a fixed mapping that stays the same across
        multiple different authentications.</t>
        <t>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 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) 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 RECOMMENDED
        <bcp14>RECOMMENDED</bcp14> for EAP-TLS peers to not use EAP-TLS with
        TLS 1.2 and static RSA based RSA-based cipher suites without privacy. This
        implies that an EAP-TLS peer SHOULD NOT <bcp14>SHOULD NOT</bcp14> 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.</t>
      </section>
      <section title="Pervasive Monitoring"> numbered="true" toc="default">
        <name>Pervasive Monitoring</name>
        <t>This is a new section when compared to <xref target="RFC5216"/>.</t> target="RFC5216" format="default"/>.</t>

	<t>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 wide 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.</t>
	<t>
	   In TLS 1.3, the post-handshake key update mechanism provides
	   forward secrecy for the traffic secrets. EAP-TLS 1.3 does not
	   provide a similar mechanism for MSK and EMSK.  Implementation using
	   the exported MSK and EMSK can achieve forward secrecy by frequently
	   deriving new keys in a similar way as described in <xref
	   target="RFC8446" sectionFormat="of" section="7.2"/>.

	</t>
      </section>
      <section title="Discovered Vulnerabilities"> numbered="true" toc="default">
        <name>Discovered Vulnerabilities</name>
        <t>This is a new section when compared to <xref target="RFC5216"/>.</t> target="RFC5216" format="default"/>.</t>
        <t>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. <xref target="RFC7457"/>
        target="RFC7457" format="default"/> summarizes the attacks that were
        known at the time of publishing publishing, and BCP 195 <xref target="RFC7525"/> <xref target="RFC8996"/> provides recommendations and requirements 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 <bcp14>MUST</bcp14> mitigate known attacks. EAP-TLS
        implementations need to monitor and follow new EAP EAP- and TLS related TLS-related
        security guidance and requirements such as <xref target="RFC8447"/> target="RFC8447"
        format="default"/> and <xref target="I-D.ietf-tls-md5-sha1-deprecate"/>.</t> target="RFC9155" format="default"/>.</t>
      </section>
      <section title="Cross-Protocol Attacks"> numbered="true" toc="default">
        <name>Cross-Protocol Attacks</name>
        <t>This is a new section when compared to <xref target="RFC5216"/>.</t> target="RFC5216" format="default"/>.</t>
        <t>Allowing the same certificate to be used in multiple protocols can
        potentially allow an attacker to authenticate via one protocol, protocol and
        then "resume" that session in another protocol. <xref target="identity"/> above
        target="identity" format="default"/> suggests that certificates
        typically have one or more FQDNs in the SAN extension. However, those
        fields are for EAP validation only, only and do not indicate that the
        certificates are suitable for use on WWW (or other) protocol server with HTTPS or other protocols on the
        named host.</t>
        <t><xref target="resumption"/> above target="resumption" format="default"/> suggests that
        authorization rules should be re-applied reapplied on resumption, resumption but does not
        mandate this behavior. As a result, this cross-protocol resumption
        could allow the attacker to bypass authorization policies, policies and to
        obtain undesired access to secured systems. Along with making sure
        that appropriate authorization information is available and used
        during resumption, using different certificates and resumption caches
        for different protocols is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to help keep
        different protocol usages separate.</t>
      </section>
    </section>
  </middle>
  <back>

<references title='Normative References'>
	<?rfc include='reference.RFC.2119'?>
	<?rfc include='reference.RFC.3748'?>
	<?rfc include='reference.RFC.5216'?>
	<?rfc include='reference.RFC.5280'?>
	<?rfc include='reference.RFC.5705'?>
	<?rfc include='reference.RFC.6066'?>
	<?rfc include='reference.RFC.6960'?>
	<?rfc include='reference.RFC.7542'?>
	<?rfc include='reference.RFC.8174'?>
	<?rfc include='reference.RFC.8446'?>

<displayreference target="I-D.ietf-emu-tls-eap-types" to="TLS-EAP-TYPES"/>
<displayreference target="I-D.ietf-tls-rfc8446bis" to="TLS-bis"/>
<displayreference target="I-D.ietf-tls-ticketrequests" to="TICKET-REQUESTS"/>

<references>
      <name>References</name>

      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5216.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5705.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6960.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7542.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
      </references>

<references title='Informative references'>
      <references>
        <name>Informative references</name>

        <reference anchor="IEEE-802.1X">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks -- Port-Based Metropolitan Area
            Networks--Port-Based Network Access Control</title>
            <author>
	       <organization>Institute of Electrical and Electronics Engineers</organization>
              <organization>IEEE</organization>
            </author>
            <date month="February" year="2020" /> year="2020"/>
          </front>

          <seriesInfo name="IEEE Standard 802.1X-2020" value="" /> Std." value="802.1X-2020"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9018454"/>
        </reference>

        <reference anchor="IEEE-802.11">
          <front>
            <title>IEEE Standard for Information technology—Telecommunications technology-Telecommunications and information exchange between systems Local and metropolitan area networks—Specific networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications</title>
            <author>
	       <organization>Institute of Electrical and Electronics Engineers</organization>
              <organization>IEEE</organization>
            </author>
            <date month="February" year="2021" /> year="2021"/>
          </front>

          <seriesInfo name="IEEE Standard 802.11-2020" value="" /> Std." value="802.11-2020"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7786995"/>
        </reference>

        <reference anchor="IEEE-802.1AE">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Security</title>
            <author>
	       <organization>Institute of Electrical and Electronics Engineers</organization>
              <organization>IEEE</organization>
            </author>
            <date month="December" year="2018" /> year="2018"/>
          </front>

          <seriesInfo name="IEEE Standard 802.1AE-2018" value="" /> Std." value="802.1AE-2018"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
        </reference>

        <reference anchor="TS.33.501">
          <front>
            <title>Security architecture and procedures for 5G System</title> system</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date month="September" year="2021" /> month="January" year="2022"/>
          </front>
	  <refcontent>Release 17
	  </refcontent>
          <seriesInfo name="3GPP TS" value="33.501 17.3.0" /> name="TS" value="33.501"/>
        </reference>

        <reference anchor="MulteFire">
          <front>
            <title>MulteFire Release 1.1 specification</title> Specification</title>
            <author>
	       <organization>MulteFire</organization>
              <organization>MulteFire Alliance</organization>
            </author>
            <date year="2019" /> year="2019"/>
          </front>
        </reference>

        <reference anchor="PEAP">
          <front>
            <title>[MS-PEAP]: Protected Extensible Authentication Protocol
            (PEAP)</title>
            <author>
              <organization>Microsoft Corporation</organization>
            </author>
            <date month="June" year="2021" year="2021"/>
          </front>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1661.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2246.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2560.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3280.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4137.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4282.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4346.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4851.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5077.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5191.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5247.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5281.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6733.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7170.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7406.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7457.xml"/>
       <xi:include
           href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
       <xi:include
           href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7593.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8447.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9155.xml"/>

<reference anchor='RFC9191'>
<front>
<title>Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods</title>
<author initials='M' surname='Sethi' fullname='Mohit Sethi'>
<organization />
</author>
<author initials='J' surname='Preuß Mattsson' fullname='John Preuß Mattsson'>
<organization />
</author>
<author initials='S' surname='Turner' fullname='Sean Turner'>
<organization />
</author>
<date year='2022' month='February' />
</front>
<seriesInfo name="RFC" value="9191"/>
<seriesInfo name="DOI" value="10.17487/RFC9191"/>
</reference>
	<?rfc include='reference.RFC.1661'?>
	<?rfc include='reference.RFC.2246'?>
	<?rfc include='reference.RFC.2560'?>
	<?rfc include='reference.RFC.2865'?>
	<?rfc include='reference.RFC.3280'?>
	<?rfc include='reference.RFC.4137'?>
	<?rfc include='reference.RFC.4282'?>
	<?rfc include='reference.RFC.4346'?>
	<?rfc include='reference.RFC.4851'?>
	<?rfc include='reference.RFC.5077'?>
	<?rfc include='reference.RFC.5191'?>
	<?rfc include='reference.RFC.5246'?>
	<?rfc include='reference.RFC.5247'?>
	<?rfc include='reference.RFC.5281'?>
	<?rfc include='reference.RFC.6125'?>
	<?rfc include='reference.RFC.6733'?>
	<?rfc include='reference.RFC.7170'?>
	<?rfc include='reference.RFC.7406'?>
	<?rfc include='reference.RFC.7457'?>
	<?rfc include='reference.RFC.7525'?>
	<?rfc include='reference.RFC.7593'?>
	<?rfc include='reference.RFC.8126'?>
	<?rfc include='reference.RFC.8447'?>
	<?rfc include='reference.RFC.8996'?>
	<?rfc include='reference.I-D.ietf-tls-md5-sha1-deprecate'?>
	<?rfc include='reference.I-D.ietf-emu-eaptlscert'?>
	<?rfc include='reference.I-D.ietf-tls-ticketrequests'?>
	<?rfc include='reference.I-D.ietf-emu-tls-eap-types'?>
	<?rfc include='reference.I-D.ietf-tls-rfc8446bis'?>

<xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-ticketrequests.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-emu-tls-eap-types.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-rfc8446bis.xml"/>

      </references>
    </references>
    <section title="Updated References" anchor="updateref"> anchor="updateref" numbered="true" toc="default">
      <name>Updated References</name>
      <t>
	All the
	The following references in <xref target="RFC5216"/> target="RFC5216" format="default"/> are updated as specified below when EAP-TLS is used with TLS 1.3.
      </t>

      <ul>
<li>
	<t>
	All references to <xref target="RFC2560"/> target="RFC2560" format="default"/> are updated to refer to <xref target="RFC6960"/>. target="RFC6960" format="default"/>.
      </t>
</li>
<li>
      <t>
	All references to <xref target="RFC3280"/> target="RFC3280" format="default"/> are
	updated to refer to <xref target="RFC5280"/>. target="RFC5280"
	format="default"/>. References to Section 4.2.1.13 of <xref target="RFC3280"/> target="RFC3280"
	section="4.2.1.13" sectionFormat="of" format="default"/> are updated
	to refer to Section 4.2.1.12 of <xref target="RFC5280"/>. target="RFC5280" sectionFormat="of"
	section="4.2.1.12" format="default"/>.
      </t>
</li>
<li>
<t>
	All references to <xref target="RFC4282"/> target="RFC4282" format="default"/> are
	updated to refer to <xref target="RFC7542"/>. target="RFC7542"
	format="default"/>. References to Section 2.1 of <xref target="RFC4282"/> target="RFC4282"
	sectionFormat="of" section="2.1" format="default"/> are updated to
	refer to Section 2.2 of <xref target="RFC7542"/>. target="RFC7542" sectionFormat="of" section="2.2" format="default"/>.
      </t>
</li>
      </ul>
    </section>
    <section title="Acknowledgments" numbered="false"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
	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, Hannes Tschofenig, and Heikki Vatiainen <contact fullname="Bernard Aboba"/>,
	<contact fullname="Jari Arkko"/>, <contact fullname="Terry Burton"/>,
	<contact fullname="Alan DeKok"/>, <contact fullname="Ari Keränen"/>,
	<contact fullname="Benjamin Kaduk"/>, <contact fullname="Jouni
	Malinen"/>, <contact fullname="Oleg Pekar"/>, <contact fullname="Eric
	Rescorla"/>, <contact fullname="Jim Schaad"/>, <contact
	fullname="Joseph Salowey"/>, <contact fullname="Martin Thomson"/>,
	<contact fullname="Vesa Torvinen"/>, <contact fullname="Hannes
	Tschofenig"/>, and <contact fullname="Heikki Vatiainen"/> for comments
	and suggestions on the draft. this document. Special thanks to the document shepherd Joseph Salowey. Document Shepherd
	<contact fullname="Joseph Salowey"/>.
      </t>
    </section>
    <section title="Contributors" numbered="false"> numbered="false" toc="default">
      <name>Contributors</name>
      <t>
	Alan DeKok,
	<contact fullname="Alan DeKok"/>, FreeRADIUS
      </t>
    </section>

</back>
</rfc>