rfc9190xml2.original.xml   rfc9190.xml 
<?xml version="1.0" ?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'[] >
<?rfc compact="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-emu-eap-tls13-21" upda
tes="5216">
<front>
<title abbrev="EAP-TLS 1.3">
Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)
</title>
<author initials="J." surname="Preuß Mattsson" fullname="John Preuß Matts
son">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city> Stockholm</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>
</address>
</author>
<date />
<workgroup>Network Working Group</workgroup>
<abstract>
<t>
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provid
es a standard mechanism for support of multiple authentication methods. This doc
ument specifies the use of EAP-Transport Layer Security (EAP-TLS) with TLS 1.3 w
hile remaining backwards compatible with existing implementations of EAP-TLS. TL
S 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) fur
ther improves security and privacy by always providing forward secrecy, never di
sclosing the peer identity, and by mandating use of revocation checking, when co
mpared to EAP-TLS with earlier versions of TLS. This document also provides guid
ance on authentication, authorization, and resumption for EAP-TLS in general (re
gardless of the underlying TLS version used). This document updates RFC 5216.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>The Extensible Authentication Protocol (EAP), defined in <xref target=
"RFC3748"/>, provides a standard mechanism for support of multiple authenticatio
n methods. EAP-Transport Layer Security (EAP-TLS) <xref target="RFC5216"/> speci
fies an EAP authentication method with certificate-based mutual authentication u
tilizing the TLS handshake protocol for cryptographic algorithms and protocol ve
rsion 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"/> (Wi-Fi) and IEEE 802.1AE <xref target="IEEE-802.1AE"/> (M
ACsec) networks using IEEE 802.1X <xref target="IEEE-802.1X"/> and it's the defa
ult mechanism for certificate based authentication in 3GPP 5G <xref target="TS.3
3.501"/> and MulteFire <xref target="MulteFire"/> networks. Many other EAP metho
ds such as EAP-FAST <xref target="RFC4851"/>, EAP-TTLS <xref target="RFC5281"/>,
TEAP <xref target="RFC7170"/>, and PEAP <xref target="PEAP"/> depend on TLS and
EAP-TLS.</t>
<t>EAP-TLS <xref target="RFC5216"/> references TLS 1.0 <xref target="RFC2
246"/> and TLS 1.1 <xref target="RFC4346"/>, but can also work with TLS 1.2 <xre
f target="RFC5246"/>. TLS 1.0 and 1.1 are formally deprecated and prohibited to
negotiate and use <xref target="RFC8996"/>. Weaknesses found in TLS 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"/>, which obsoletes TLS 1.2 <xref
target="RFC5246"/>. TLS 1.3 is in large parts a complete remodeling of the TLS
handshake protocol including a different message flow, different handshake messa
ges, different key schedule, different cipher suites, different resumption mecha
nism, different privacy protection, and different record padding. This means tha
t significant parts of the normative text in the previous EAP-TLS specification
<xref target="RFC5216"/> are not applicable to EAP-TLS with TLS 1.3. Therefore,
aspects such as resumption, privacy handling, and key derivation need to be appr
opriately addressed for EAP-TLS with TLS 1.3.</t>
<t>This document updates <xref target="RFC5216"/> to define how to use EA
P-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 regardles
s of the underlying TLS version used. This document only describes differences c
ompared to <xref target="RFC5216"/>. When EAP-TLS is used with TLS 1.3, some ref
erences are updated as specified in <xref target="updateref"/>. All message flow
are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. Sinc
e EAP-TLS couples the TLS handshake state machine with the EAP state 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-T
LS protocol. Therefore, implementations MUST 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 me
thods use TLS 1.3 is left to other documents such as <xref target="I-D.ietf-emu-
tls-eap-types"/>.</t>
<t>In addition to the improved security and privacy offered by TLS 1.3, t
here are other significant benefits of using EAP-TLS with TLS 1.3. Privacy, whic
h in EAP-TLS means that no information about the underlying peer identity is dis
closed, is mandatory and achieved without any additional round-trips. Revocation
checking is mandatory and simplified with OCSP stapling, and TLS 1.3 introduces
more possibilities to reduce fragmentation when compared to earlier versions of
TLS.</t>
<section title='Requirements and Terminology'>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTI
ONAL" in this document are to be interpreted as described in BCP 14 <xref target
='RFC2119'/> <xref target='RFC8174'/> when, and only when, they appear in all ca
pitals, as shown here.</t>
<t>Readers are expected to be familiar with the terms and concept
s used in EAP-TLS <xref target="RFC5216"/> and TLS <xref target="RFC8446"/>. The
term EAP-TLS peer is used for the entity acting as EAP peer and TLS client. The
term EAP-TLS server is used for the entity acting as EAP server and TLS server.
</t>
<t>This document follows the terminology from <xref target="I-D.i
etf-tls-rfc8446bis"/> where the master secret is renamed to the main secret and
the exporter_master_secret is renamed to the exporter_secret.</t>
</section>
</section> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<section title='Protocol Overview'> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-emu-eap-tls13-21" number="9190" updates="5216" obsoletes="" submissionType
="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true"
symRefs="true" sortRefs="true" version="3">
<section title='Overview of the EAP-TLS Conversation'> <front>
<t>This section updates Section 2.1 of <xref target="RFC5 <title abbrev="EAP-TLS 1.3">EAP-TLS 1.3: Using the Extensible
216"/> by amending it in accordance with the following discussion.</t> Authentication Protocol with TLS 1.3</title>
<t>If the TLS implementation correctly implements TLS ver <seriesInfo name="RFC" value="9190"/>
sion negotiation, EAP-TLS will automatically leverage that capability. The EAP-T <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson
LS 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 <organization>Ericsson</organization>
1.2.</t> <address>
<postal>
<street/>
<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@iki.fi</email>
</address>
</author>
<date year="2022" month="February"/>
<workgroup>EMU</workgroup>
<t>TLS 1.3 changes both the message flow and the handshak <keyword>Extensible Authentication Protocol</keyword>
e messages compared to earlier versions of TLS. Therefore, much of Section 2.1 o <keyword>IEEE 802</keyword>
f <xref target="RFC5216"/> does not apply for TLS 1.3. Except for Sections <xref <keyword>5G</keyword>
target="identity" format="counter"/> and <xref target="secres" format="counter" <keyword>authentication</keyword>
/>, this update applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotia <keyword>identity protection</keyword>
ted, then <xref target="RFC5216"/> applies.</t> <keyword>privacy</keyword>
<keyword>forward secrecy</keyword>
<t>TLS 1.3 introduces several new handshake messages incl uding HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general, these mess ages will be handled by the underlying TLS libraries and are not visible to EAP- TLS, however, there are a few things to note: <abstract>
<list style="symbols"> <t>
<t>The HelloRetryRequest is used by the server to reject The Extensible Authentication Protocol (EAP), defined in RFC 3748, provid
the parameters offered in the ClientHello and suggest new parameters. When this es a standard mechanism for support of multiple authentication methods. This doc
message is encountered it will increase the number of round trips used by the pr ument specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compat
otocol.</t> ible with existing implementations of EAP-TLS. TLS 1.3 provides significantly im
proved security and privacy, and reduced latency when compared to earlier versio
ns of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and priv
acy by always providing forward secrecy, never disclosing the peer identity, and
by mandating use of revocation checking when compared to EAP-TLS with earlier v
ersions of TLS. This document also provides guidance on authentication, authoriz
ation, and resumption for EAP-TLS in general (regardless of the underlying TLS v
ersion used). This document updates RFC 5216.
</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>The Extensible Authentication Protocol (EAP), defined in <xref
target="RFC3748" format="default"/>, provides a standard mechanism for
support of multiple authentication methods. EAP-TLS <xref
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" format="default"/> (Wi-Fi) and IEEE
802.1AE <xref target="IEEE-802.1AE" format="default"/> (MACsec) networks
using IEEE 802.1X <xref target="IEEE-802.1X" format="default"/> and it's
the default mechanism for certificate-based authentication in 3GPP 5G
<xref target="TS.33.501" format="default"/> and MulteFire <xref
target="MulteFire" format="default"/> networks.
<t>The NewSessionTicket message is used to convey resumpt Many other EAP methods such as Flexible Authentication via Secure Tunneling
ion information and is covered in Sections <xref target="ticket" format="counter (EAP-FAST) <xref target="RFC4851" format="default"/>, Tunneled Transport Layer
"/> and <xref target="resumption" format="counter"/>.</t> Security (EAP-TTLS) <xref target="RFC5281" format="default"/>, the Tunnel
Extensible Authentication Protocol (TEAP) <xref target="RFC7170"
format="default"/>, as well as vendor-specific EAP methods such as the
Protected Extensible Authentication Protocol (PEAP) <xref target="PEAP"
format="default"/>, depend on TLS and EAP-TLS.
<t>The KeyUpdate message is used to update the traffic ke ys used on a TLS connection. EAP-TLS does not encrypt significant amounts of dat a so this functionality is not needed. Implementations SHOULD NOT send this mess age, however some TLS libraries may automatically generate and process this mess age.</t> </t>
<t>Early Data MUST NOT be used in EAP-TLS. EAP-TLS server <t>EAP-TLS <xref target="RFC5216" format="default"/> references TLS 1.0
s MUST NOT send an early_data extension and clients MUST NOT send an EndOfEarlyD <xref target="RFC2246" format="default"/> and TLS 1.1 <xref
ata message.</t> target="RFC4346" format="default"/> but can also work with TLS 1.2 <xref
target="RFC5246" format="default"/>. TLS 1.0 and 1.1 are formally
deprecated and prohibited from being negotiated or used <xref target="RFC8
996"
format="default"/>. Weaknesses found in TLS 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" format="default"/>,
which obsoletes TLS 1.2 <xref target="RFC5246" format="default"/>. TLS
1.3 is in large 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" 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" format="default"/> to defi
ne 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 pr
ovide additional guidance on authentication, authorization, and resumption for E
AP-TLS regardless of the underlying TLS version used. This document only describ
es differences compared to <xref target="RFC5216" format="default"/>. When EAP-T
LS is used with TLS 1.3, some references are updated as specified in <xref targe
t="updateref" format="default"/>. All message flows are example message flows sp
ecific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS couples the TLS han
dshake state machine with the EAP state machine, it is possible that new version
s of TLS will cause incompatibilities that introduce failures or security issues
if they are not carefully integrated into the EAP-TLS protocol. Therefore, impl
ementations <bcp14>MUST</bcp14> limit the maximum TLS version they use to 1.3, u
nless 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 met
hods use TLS 1.3 is left to other documents such as <xref target="I-D.ietf-emu-t
ls-eap-types" format="default"/>.</t>
<t>In addition to the improved security and privacy offered by TLS 1.3, th
ere 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 disc
losed, is mandatory and achieved without any additional round trips. Revocation
checking is mandatory and simplified with Online Certificate Status Protocol (OC
SP) stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation
when compared to earlier versions of TLS.</t>
<section numbered="true" toc="default">
<name>Requirements and Terminology</name>
<t>Post-handshake authentication MUST NOT be used in EAP- <t>
TLS. Clients MUST NOT send a "post_handshake_auth" extension and Servers MUST NO The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
T request post-handshake client authentication.</t> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
</list></t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>After receiving an EAP-Request packet with EAP-Type=EA <t>Readers are expected to be familiar with the terms and concepts used i
P-TLS as described in <xref target="RFC5216"/> the conversation will continue wi n EAP-TLS <xref target="RFC5216" format="default"/> and TLS <xref target="RFC844
th the TLS handshake protocol encapsulated in the data fields of EAP-Response an 6" format="default"/>. The term EAP-TLS peer is used for the entity acting as EA
d EAP-Request packets. When EAP-TLS is used with TLS version 1.3, the formatting P peer and TLS client. The term EAP-TLS server is used for the entity acting as
and processing of the TLS handshake SHALL be done as specified in version 1.3 o EAP server and TLS server.</t>
f TLS. This update only lists additional and different requirements, restriction <t>This document follows the terminology from <xref target="I-D.ietf-tls
s, and processing compared to <xref target="RFC8446"/> and <xref target="RFC5216 -rfc8446bis" format="default"/> where the master secret is renamed to the main s
"/>.</t> ecret and the exporter_master_secret is renamed to the exporter_secret.</t>
</section>
</section>
<section title='Authentication' anchor="section_auth"> <section numbered="true" toc="default">
<t>This section updates Section 2.1.1 of <xref target="RF <name>Protocol Overview</name>
C5216"/> by amending it in accordance with the following discussion.</t> <section numbered="true" toc="default">
<name>Overview of the EAP-TLS Conversation</name>
<t>This section updates <xref 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 <xref
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"
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; however, there are a few things to note:
<t>The EAP-TLS server MUST authenticate with a certificat </t>
e and SHOULD require the EAP-TLS peer to authenticate with a certificate. Certif <ul spacing="normal">
icates can be of any type supported by TLS including raw public keys. Pre-Shared <li>The HelloRetryRequest is used by the server to reject the
Key (PSK) authentication SHALL NOT be used except for resumption. The full hand parameters offered in the ClientHello and suggest new
shake in EAP-TLS with TLS 1.3 always provides forward secrecy by exchange of eph parameters. When this message is encountered, it will increase the
emeral "key_share" extensions in the ClientHello and ServerHello (e.g., containi number of round trips used by the protocol.</li>
ng ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3, see Section <li>The NewSessionTicket message is used to convey resumption informat
s 4.1.2 and 4.1.3 of <xref target="RFC8446"/>. TLS 1.3 introduced early applicat ion and is covered in Sections <xref target="ticket" format="counter"/> and <xre
ion data which like all application data (other than the protected success indic f target="resumption" format="counter"/>.</li>
ation described below) is not used in EAP-TLS; see Section 4.2.10 of <xref targe <li>The KeyUpdate message is used to update the traffic keys used on
t="RFC8446"/> for additional information on the "early_data" extension. Resumpti a TLS connection. EAP-TLS does not encrypt significant amounts of
on is handled as described in <xref target="resumption"/>. As a protected succes data so this functionality is not needed. Implementations
s indication <xref target="RFC3748"/> the EAP-TLS server always sends TLS applic <bcp14>SHOULD NOT</bcp14> send this message; however, some TLS
ation data 0x00, see Section 2.5. Note that a TLS implementation MAY not allow t libraries may automatically generate and process this message.</li>
he EAP-TLS layer to control in which order things are sent and the application d <li>Early Data <bcp14>MUST NOT</bcp14> be used in EAP-TLS. EAP-TLS ser
ata MAY therefore be sent before a NewSessionTicket. TLS application data 0x00 i vers <bcp14>MUST NOT</bcp14> send an early_data extension and clients <bcp14>MUS
s therefore to be interpreted as success after the EAP-Request that contains TLS T NOT</bcp14> send an EndOfEarlyData message.</li>
application data 0x00. After the EAP-TLS server has sent an EAP-Request contain <li>Post-handshake authentication <bcp14>MUST NOT</bcp14> be used in E
ing the TLS application data 0x00 and received an EAP-Response packet of EAP-Typ AP-TLS. Clients <bcp14>MUST NOT</bcp14> send a "post_handshake_auth" extension a
e=EAP-TLS and no data, the EAP-TLS server sends EAP-Success.</t> nd Servers <bcp14>MUST NOT</bcp14> request post-handshake client authentication.
</li>
</ul>
<t>After receiving an EAP-Request packet with EAP-Type=EAP-TLS as descri
bed in <xref 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 formatt
ing and processing of the TLS handshake <bcp14>SHALL</bcp14> be done as specifie
d in version 1.3 of TLS. This update only lists additional and different require
ments, restrictions, and processing compared to <xref target="RFC8446" format="d
efault"/> and <xref target="RFC5216" format="default"/>.</t>
<section anchor="section_auth" numbered="true" toc="default">
<name>Authentication</name>
<t>This section updates <xref target="RFC5216" sectionFormat="of" sect
ion="2.1.1" format="default"/> by amending it in accordance with the following
discussion.</t>
<t><xref target="figbase1"/> shows an example message flo <t>The EAP-TLS server <bcp14>MUST</bcp14> authenticate with a
w for a successful EAP-TLS full handshake with mutual authentication (and neithe certificate and <bcp14>SHOULD</bcp14> require the EAP-TLS peer to
r HelloRetryRequest nor post-handshake messages are sent).</t> authenticate with a certificate. Certificates can be of any type
supported by TLS including raw public keys. Pre-Shared Key (PSK)
authentication <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 Elliptic Curve Diffie-Hellman (ECDHE) public keys). SessionID
is deprecated in TLS 1.3;
<figure anchor="figbase1" title="EAP-TLS mutual authentication" align="center">< see Sections <xref target="RFC8446" section="4.1.2"
artwork><![CDATA[ sectionFormat="bare" /> and <xref target="RFC8446" section="4.1.3"
sectionFormat="bare"/> of <xref target="RFC8446"/>. TLS 1.3
introduced early application data that like all application data
(other than the protected success indication described below) is not
used in EAP-TLS; see <xref 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" format="default"/>. As a protected success
indication <xref target="RFC3748" format="default"/>, the EAP-TLS
server always sends TLS application data 0x00; see <xref
target="state"/>. Note that a TLS implementation <bcp14>MAY</bcp14>
not allow the EAP-TLS layer to control in which order things are
sent and the application data <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" 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">
<name>EAP-TLS Mutual Authentication</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
skipping to change at line 144 skipping to change at line 238
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00) <-------- (TLS Application Data 0x00)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
]]></artwork></figure> ]]></artwork>
</section> </figure>
</section>
<section title='Ticket Establishment' anchor="ticket">
<t>This is a new section when compared to <xref target="R
FC5216"/>.</t>
<t>To enable resumption when using EAP-TLS with TLS 1.3,
the EAP-TLS server MUST send one or more post-handshake NewSessionTicket message
s (each associated with a PSK, a PSK identity, a ticket lifetime, and other para
meters) in the initial authentication. Note that TLS 1.3 <xref target="RFC8446"/
> limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS
servers MUST respect this upper limit when issuing tickets. The NewSessionTicke
t is sent after the EAP-TLS server has received the client Finished message in t
he initial authentication. The NewSessionTicket can be sent in the same flight a
s the TLS server Finished or later. The PSK associated with the ticket depends o
n the client Finished and cannot be pre-computed (so as to be sent in the same f
light as the TLS server Finished) in handshakes with client authentication. The
NewSessionTicket message MUST NOT include an "early_data" extension. If the "ear
ly_data" extension is received then it MUST be ignored. Servers should take into
account that fewer NewSessionTickets will likely be needed in EAP-TLS than in t
he usual HTTPS connection scenario. In most cases a single NewSessionTicket will
be sufficient. A mechanism by which clients can specify the desired number of t
ickets needed for future connections is defined in <xref target="I-D.ietf-tls-ti
cketrequests"/>.</t>
<t><xref target="figbase2"/> shows an example message flo <section anchor="ticket" numbered="true" toc="default">
w for a successful EAP-TLS full handshake with mutual authentication and ticket <name>Ticket Establishment</name>
establishment of a single ticket.</t> <t>This is a new section when compared to <xref target="RFC5216" forma
t="default"/>.</t>
<figure anchor="figbase2" title="EAP-TLS ticket establishment" align="center"><a <t>To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS s
rtwork><![CDATA[ erver <bcp14>MUST</bcp14> send one or more post-handshake NewSessionTicket messa
ges (each associated with a PSK, a PSK identity, a ticket lifetime, and other pa
rameters) in the initial authentication. Note that TLS 1.3 <xref target="RFC8446
" format="default"/> limits the ticket lifetime to a maximum of 604800 seconds (
7 days) and EAP-TLS servers <bcp14>MUST</bcp14> respect this upper limit when is
suing tickets. The NewSessionTicket is sent after the EAP-TLS server has receive
d the client Finished message in the initial authentication. The NewSessionTicke
t can be sent in the same flight as the TLS server Finished or later. The PSK as
sociated with the ticket depends on the client Finished and cannot be pre-comput
ed (so as to be sent in the same flight as the TLS server Finished) in handshake
s with client authentication. The NewSessionTicket message <bcp14>MUST NOT</bcp1
4> include an "early_data" extension. If the "early_data" extension is received,
then it <bcp14>MUST</bcp14> be ignored. Servers should take into account that f
ewer NewSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS
connection scenario. In most 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"
format="default"/>.</t>
<t><xref target="figbase2" format="default"/> shows an example message
flow for a successful EAP-TLS full handshake with mutual authentication and tic
ket establishment of a single ticket.</t>
<figure anchor="figbase2">
<name>EAP-TLS Ticket Establishment</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
skipping to change at line 187 skipping to change at line 283
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS NewSessionTicket, (TLS NewSessionTicket,
<-------- (TLS Application Data 0x00) <-------- (TLS Application Data 0x00)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
]]></artwork></figure> ]]></artwork>
</section> </figure>
</section>
<section title="Resumption" anchor="resumption"> <section anchor="resumption" numbered="true" toc="default">
<t>This section updates Section 2.1.2 of <xref target="RF <name>Resumption</name>
C5216"/> by amending it in accordance with the following discussion.</t> <t>This section updates <xref target="RFC5216" sectionFormat="of" sect
ion="2.1.2" format="default"/> by amending it in accordance with the following d
<t>EAP-TLS is typically used with client authentication a iscussion.</t>
nd typically fragments the TLS flights into a large number of EAP requests and E <t>EAP-TLS is typically used with client authentication and
AP responses. Resumption significantly reduces the number of round-trips and ena typically fragments the TLS flights into a large number of
bles the EAP-TLS server to omit database lookups needed during a full handshake EAP-requests and EAP-responses. Resumption significantly reduces the
with client authentication. TLS 1.3 replaces the session resumption mechanisms i number of round trips and enables the EAP-TLS server to omit
n earlier versions of TLS with a new PSK exchange. When EAP-TLS is used with TLS database lookups needed during a full handshake with client
version 1.3, EAP-TLS SHALL use a resumption mechanism compatible with version 1 authentication. TLS 1.3 replaces the session resumption mechanisms
.3 of TLS.</t> in earlier versions of TLS with a new PSK exchange. When EAP-TLS is
used with TLS version 1.3, EAP-TLS <bcp14>SHALL</bcp14> use a
<t>For TLS 1.3, resumption is described in Section 2.2 of resumption mechanism compatible with version 1.3 of TLS.</t>
<xref target="RFC8446"/>. If the client has received a NewSessionTicket message <t>For TLS 1.3, resumption is described in <xref target="RFC8446"
from the EAP-TLS server, the client can use the PSK identity associated with th sectionFormat="of" section="2.2" format="default"/>. If the client
e ticket to negotiate the use of the associated PSK. If the EAP-TLS server accep has received a NewSessionTicket message from the EAP-TLS server, the
ts it, then the resumed session has been deemed to be authenticated, and securel client can use the PSK identity associated with the ticket to
y associated with the prior authentication or resumption. It is up to the EAP-TL negotiate the use of the associated PSK. If the EAP-TLS server
S peer to use resumption, but it is RECOMMENDED that the EAP-TLS peer use resump accepts it, then the resumed session has been deemed to be
tion if it has a valid ticket that has not been used before. It is left to the E authenticated and securely associated with the prior authentication
AP-TLS server whether to accept resumption, but it is RECOMMENDED that the EAP-T or resumption. It is up to the EAP-TLS peer to use resumption, but
LS server accept resumption if the ticket which was issued is still valid. Howev it is <bcp14>RECOMMENDED</bcp14> that the EAP-TLS peer use
er, the EAP-TLS server MAY choose to require a full handshake. In the case a ful resumption if it has a valid ticket that has not been used
l handshake is required, the negotiation proceeds as if the session was a new au before. It is left to the EAP-TLS server whether to accept
thentication, and the resumption attempt is ignored. The requirements of Section resumption, but it is <bcp14>RECOMMENDED</bcp14> that the EAP-TLS
s <xref target="section_auth" format="counter"/> and <xref target="ticket" forma server accept resumption if the ticket that was issued is still
t="counter"/> then apply in their entirety. As described in Appendix C.4 of <xre valid. However, the EAP-TLS server <bcp14>MAY</bcp14> choose to
f target="RFC8446"/>, reuse of a ticket allows passive observers to correlate di require a full handshake. In the case a full handshake is required,
fferent connections. EAP-TLS peers and EAP-TLS servers SHOULD follow the client the negotiation proceeds as if the session was a new authentication,
tracking preventions in Appendix C.4 of <xref target="RFC8446"/>.</t> and the resumption attempt is ignored. The requirements of Sections
<xref target="section_auth" format="counter"/> and <xref
<t>It is RECOMMENDED to use a Network Access Identifiers target="ticket" format="counter"/> then apply in their entirety. As
(NAIs) with the same realm during resumption and the original full handshake. Th described in <xref target="RFC8446" format="default"
is requirement allows EAP packets to be routed to the same destination as the or sectionFormat="of" section="C.4" />, reuse of a ticket allows
iginal full handshake. If this recommendation is not followed, resumption is lik passive observers to correlate different connections. EAP-TLS peers
ely impossible. When NAI reuse can be done without privacy implications, it is R and EAP-TLS servers <bcp14>SHOULD</bcp14> follow the client tracking
ECOMMENDED to use the same NAI in the resumption, as was used in the original fu preventions in <xref target="RFC8446" format="default"
ll handshake <xref target="RFC7542"/>. For example, the NAI @realm can safely be sectionFormat="of" section="C.4" />.</t>
reused since it does not provide any specific information to associate a user's <t>It is <bcp14>RECOMMENDED</bcp14> to use Network Access
resumption attempt with the original full handshake. However, reusing the NAI P Identifiers (NAIs) with the same realm during resumption and the
2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path attacker to associate a res original full handshake. This requirement allows EAP packets to be
umption attempt with the original full handshake. The TLS PSK identity is typica routed to the same destination as the original full handshake. If
lly derived by the TLS implementation and may be an opaque blob without a routab this recommendation is not followed, resumption is likely
le realm. The TLS PSK identity on its own is therefore unsuitable as a NAI in th impossible. When NAI reuse can be done without privacy implications,
e Identity Response.</t> it is <bcp14>RECOMMENDED</bcp14> to use the same NAI in the
resumption as was used in the original full handshake <xref
<t><xref target="figresumption"/> shows an example messag target="RFC7542" format="default"/>. For example, the NAI @realm can
e flow for a subsequent successful EAP-TLS resumption handshake where both sides safely be reused since it does not provide any specific information
authenticate via a PSK provisioned via an earlier NewSessionTicket and where th to associate a user's resumption attempt with the original full
e server provisions a single new ticket.</t> handshake. However, reusing the NAI
P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path attacker to
<figure anchor="figresumption" title="EAP-TLS resumption" align="center"><artwor associate a resumption attempt with the original full handshake. The
k><![CDATA[ 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 an NAI in the Identity
Response.</t>
<t><xref target="figresumption" format="default"/> shows an example me
ssage flow for a subsequent successful EAP-TLS resumption handshake where both s
ides authenticate via a PSK provisioned via an earlier NewSessionTicket and wher
e the server provisions a single new ticket.</t>
<figure anchor="figresumption">
<name>EAP-TLS Resumption</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
skipping to change at line 230 skipping to change at line 373
TLS NewSessionTicket) TLS NewSessionTicket)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00) <-------- (TLS Application Data 0x00)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
]]></artwork></figure> ]]></artwork>
</figure>
<t>As specified in Section 2.2 of <xref target="RFC8446"/ <t>As specified in <xref target="RFC8446" sectionFormat="of"
>, the EAP-TLS peer SHOULD supply a "key_share" extension when attempting resump section="2.2" format="default"/>, the EAP-TLS peer
tion, which allows the EAP-TLS server to potentially decline resumption and fall <bcp14>SHOULD</bcp14> supply a "key_share" extension when attempting
back to a full handshake. If the EAP-TLS peer did not supply a "key_share" exte resumption, which allows the EAP-TLS server to potentially decline
nsion when attempting resumption, the EAP-TLS server needs to send HelloRetryReq resumption and fall back to a full handshake. If the EAP-TLS peer
uest to signal that additional information is needed to complete the handshake, did not supply a "key_share" extension when attempting resumption,
and the EAP-TLS peer needs to send a second ClientHello containing that informat the EAP-TLS server needs to send a HelloRetryRequest to signal that
ion. Providing a "key_share" and using the "psk_dhe_ke" pre-shared key exchange additional information is needed to complete the handshake, and the
mode is also important in order to limit the impact of a key compromise. When us EAP-TLS peer needs to send a second ClientHello containing that
ing "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning that compromise of th information. Providing a "key_share" and using the "psk_dhe_ke"
e PSK used for resumption does not compromise any earlier connections. The "psk_ pre-shared key exchange mode is also important in order to limit the
dh_ke" key-exchange mode MUST be used for resumption unless the deployment has a impact of a key compromise. When using "psk_dhe_ke", TLS 1.3
local requirement to allow configuration of other mechanisms.</t> provides forward secrecy meaning that compromise of the PSK used for
resumption does not compromise any earlier connections. The
</section> "psk_dh_ke" key exchange mode <bcp14>MUST</bcp14> be used for
resumption unless the deployment has a local requirement to allow
<section title='Termination'> configuration of other mechanisms.</t>
<t>This section updates Section 2.1.3 of <xref target="RF </section>
C5216"/> by amending it in accordance with the following discussion.</t> <section numbered="true" toc="default">
<name>Termination</name>
<t>TLS 1.3 changes both the message flow and the handshak <t>This section updates <xref target="RFC5216" sectionFormat="of" sect
e messages compared to earlier versions of TLS. Therefore, some normative text i ion="2.1.3" format="default"/> by amending it in accordance with the following d
n Section 2.1.3 of <xref target="RFC5216"/> does not apply for TLS 1.3. The two iscussion.</t>
paragraphs below replace the corresponding paragraphs in Section 2.1.3 of <xref <t>TLS 1.3 changes both the message flow and the handshake messages
target="RFC5216"/> when EAP-TLS is used with TLS 1.3. The other paragraphs in Se compared to earlier versions of TLS. Therefore, some normative text
ction 2.1.3 of <xref target="RFC5216"/> still apply with the exception that Sess in <xref target="RFC5216" sectionFormat="of" section="2.1.3"
ionID is deprecated. format="default"/> does not apply for TLS 1.3. The two paragraphs
<list> below replace the corresponding paragraphs in <xref target="RFC5216"
<t>If the EAP-TLS peer authenticates successfully sectionFormat="of" section="2.1.3" format="default"/> when EAP-TLS
, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS conta is used with TLS 1.3. The other paragraphs in <xref target="RFC5216"
ining TLS records conforming to the version of TLS used. The message flow ends w sectionFormat="of" section="2.1.3" format="default"/> still apply
ith a protected success indication from the EAP-TLS server, followed by an EAP-R with the exception that SessionID is deprecated.
esponse packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, followed b </t>
y EAP-Success from the server.</t>
<t>If the EAP-TLS server authenticates successful
ly, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS con
taining TLS records conforming to the version of TLS used.</t>
</list>
</t>
<t>Figures <xref target="figterm1" format="counter"/>, <x
ref target="figterm2" format="counter"/>, and <xref target="figterm3" format="co
unter"/> 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 a
lerts 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", bo
th of which indicate that the connection is not going to continue normally, see
<xref target="RFC8446"/>.</t>
<t>In TLS 1.3 <xref target="RFC8446"/>, error alerts are
not mandatory to send after a fatal error condition. Failure to send TLS Error a
lerts means that the peer or server would have no way of determining what went w
rong. EAP-TLS 1.3 strengthens this requirement. Whenever an implementation encou
nters a fatal error condition, it MUST send an appropriate TLS Error alert.</t>
<t><xref target="figterm1"/> shows an example message flo <t indent="3">If the EAP-TLS peer authenticates successfully, the EAP
w where the EAP-TLS server rejects the ClientHello with an error alert. The EAP- -TLS
TLS server can also partly reject the ClientHello with a HelloRetryRequest, see server <bcp14>MUST</bcp14> send an EAP-Request packet with
<xref target="helloretry"/>.</t> 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 indent="3">If the EAP-TLS server authenticates successfully, the
EAP-TLS
peer <bcp14>MUST</bcp14> send an EAP-Response message with
EAP-Type=EAP-TLS containing TLS records conforming to the version
of TLS used.
</t>
<figure anchor="figterm1" title="EAP-TLS server rejection of ClientHello" align= <t>Figures <xref target="figterm1" format="counter"/>, <xref target="figterm2" f
"center"><artwork><![CDATA[ ormat="counter"/>, and <xref target="figterm3" format="counter"/> illustrate mes
sage 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 th
at the connection is not going to continue normally; see <xref target="RFC8446"
format="default"/>.</t>
<t>In TLS 1.3 <xref target="RFC8446" format="default"/>, error alerts
are not mandatory to send after a fatal error condition. Failure to send TLS Err
or alerts means that the peer or server would have no way of determining what we
nt wrong. EAP-TLS 1.3 strengthens this requirement. Whenever an implementation e
ncounters a fatal error condition, it <bcp14>MUST</bcp14> send an appropriate TL
S Error alert.</t>
<t><xref 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;
see <xref target="helloretry" format="default"/>.</t>
<figure anchor="figterm1">
<name>EAP-TLS Server Rejection of ClientHello</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Error Alert) <-------- (TLS Error Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Failure <-------- EAP-Failure
]]></artwork></figure> ]]></artwork>
</figure>
<t><xref target="figterm2"/> shows an example message flow where <t><xref target="figterm2" format="default"/> shows an example message
EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS E flow where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer s
rror alert.</t> ends a TLS Error alert.</t>
<figure anchor="figterm2">
<figure anchor="figterm2" title="EAP-TLS unsuccessful EAP-TLS server authenticat <name>EAP-TLS Unsuccessful EAP-TLS Server Authentication</name>
ion" align="center"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
skipping to change at line 302 skipping to change at line 475
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished) <-------- TLS Finished)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Error Alert) (TLS Error Alert)
--------> -------->
<-------- EAP-Failure <-------- EAP-Failure
]]></artwork></figure> ]]></artwork>
</figure>
<t><xref target="figterm3"/> shows an example message flow where <t><xref target="figterm3" format="default"/> shows an example message
the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-T flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, b
LS peer fails to authenticate to the EAP-TLS server and the server sends a TLS E ut the EAP-TLS peer fails to authenticate to the EAP-TLS server and the server s
rror alert.</t> ends a TLS Error alert.</t>
<figure anchor="figterm3">
<figure anchor="figterm3" title="EAP-TLS unsuccessful client authentication" ali <name>EAP-TLS Unsuccessful Client Authentication</name>
gn="center"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
skipping to change at line 338 skipping to change at line 512
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Error Alert) <-------- (TLS Error Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Failure <-------- EAP-Failure
]]></artwork></figure> ]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title='No Peer Authentication'> <name>No Peer Authentication</name>
<t>This is a new section when compared to <xref target="R <t>This is a new section when compared to <xref target="RFC5216" forma
FC5216"/>.</t> t="default"/>.</t>
<t><xref target="figbase3" format="default"/> shows an example message
<t><xref target="figbase3"/> shows an example message flo flow for a successful EAP-TLS full handshake without peer authentication (e.g.,
w for a successful EAP-TLS full handshake without peer authentication (e.g., eme emergency services, as described in <xref target="RFC7406" format="default"/>).
rgency services, as described in <xref target="RFC7406"/>).</t> </t>
<figure anchor="figbase3">
<figure anchor="figbase3" title="EAP-TLS without peer authentication" align="cen <name>EAP-TLS without Peer Authentication</name>
ter"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
skipping to change at line 376 skipping to change at line 550
<-------- TLS Finished) <-------- TLS Finished)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00) <-------- (TLS Application Data 0x00)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
]]></artwork></figure> ]]></artwork>
</section> </figure>
</section>
<section title="Hello Retry Request" anchor="helloretry"> <section anchor="helloretry" numbered="true" toc="default">
<t>This is a new section when compared to <xref target="R <name>Hello Retry Request</name>
FC5216"/>.</t> <t>This is a new section when compared to <xref target="RFC5216" forma
t="default"/>.</t>
<t>As defined in TLS 1.3 <xref target="RFC8446"/>, EAP-TL <t>As defined in TLS 1.3 <xref target="RFC8446" format="default"/>,
S servers can send a HelloRetryRequest message in response to a ClientHello if t EAP-TLS servers can send a HelloRetryRequest message in response to
he EAP-TLS server finds an acceptable set of parameters but the initial ClientHe a ClientHello if the EAP-TLS server finds an acceptable set of
llo does not contain all the needed information to continue the handshake. One u parameters but the initial ClientHello does not contain all the
se case is if the EAP-TLS server does not support the groups in the "key_share" needed information to continue the handshake. One use case is if the
extension (or there is no "key_share" extension), but supports one of the groups EAP-TLS server does not support the groups in the "key_share"
in the "supported_groups" extension. In this case the client should send a new extension (or there is no "key_share" extension) but supports one of
ClientHello with a "key_share" that the EAP-TLS server supports.</t> the groups in the "supported_groups" extension. In this case, the
client should send a new ClientHello with a "key_share" that the
<t><xref target="fighelloretryrequest"/> shows an example EAP-TLS server supports.</t>
message flow for a successful EAP-TLS full handshake with mutual authentication <t><xref target="fighelloretryrequest" format="default"/> shows an exa
and HelloRetryRequest. Note the extra round-trip as a result of the HelloRetryR mple message flow for a successful EAP-TLS full handshake with mutual authentica
equest.</t> tion and HelloRetryRequest. Note the extra round trip as a result of the HelloRe
tryRequest.</t>
<figure anchor="fighelloretryrequest" title="EAP-TLS with Hello Retry Request" a <figure anchor="fighelloretryrequest">
lign="center"><artwork><![CDATA[ <name>EAP-TLS with Hello Retry Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
skipping to change at line 425 skipping to change at line 608
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00) <-------- (TLS Application Data 0x00)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
]]></artwork></figure> ]]></artwork>
</section> </figure>
</section>
<section title='Identity'> <section numbered="true" toc="default">
<t>This is a new section when compared to <xref target="R <name>Identity</name>
FC5216"/>.</t> <t>This is a new section when compared to <xref target="RFC5216" forma
t="default"/>.</t>
<t>It is RECOMMENDED to use anonymous NAIs <xref target=" <t>It is <bcp14>RECOMMENDED</bcp14> to use anonymous NAIs <xref
RFC7542"/> in the Identity Response as such identities are routable and privacy- target="RFC7542" format="default"/> in the Identity Response as such
friendly. While opaque blobs are allowed by <xref target="RFC3748"/>, such ident identities are routable and privacy-friendly. While opaque blobs are
ities are NOT RECOMMENDED as they are not routable and should only be considered allowed by <xref target="RFC3748" format="default"/>, such
in local deployments where the EAP-TLS peer, EAP authenticator, and EAP-TLS ser identities are <bcp14>NOT RECOMMENDED</bcp14> as they are not
ver all belong to the same network. Many client certificates contain an identity routable and should only be considered in local deployments where
such as an email address, which is already in NAI format. When the client certi the EAP-TLS peer, EAP authenticator, and EAP-TLS server all belong
ficate contains a NAI as subject name or alternative subject name, an anonymous to the same network. Many client certificates contain an identity
NAI SHOULD be derived from the NAI in the certificate, see <xref target="privacy such as an email address, which is already in NAI format. When the
"/>. More details on identities are described in Sections <xref target="resumpti client certificate contains an NAI as subject name or alternative
on" format="counter"/>, <xref target="privacy" format="counter"/>, <xref target= subject name, an anonymous NAI <bcp14>SHOULD</bcp14> be derived from
"identity" format="counter"/>, and <xref target="privcon" format="counter"/>.</t the NAI in the certificate; see <xref target="privacy"
> format="default"/>. More details on identities are described in
</section> Sections <xref target="resumption" format="counter"/>, <xref
target="privacy" format="counter"/>, <xref target="identity"
<section title="Privacy" anchor="privacy"> format="counter"/>, and <xref target="privcon"
<t>This section updates Section 2.1.4 of <xref target="RF format="counter"/>.</t>
C5216"/> by amending it in accordance with the following discussion.</t> </section>
<section anchor="privacy" numbered="true" toc="default">
<t>EAP-TLS 1.3 significantly improves privacy when compar <name>Privacy</name>
ed to earlier versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites without con <t>This section updates <xref target="RFC5216" sectionFormat="of"
fidentiality which means that TLS 1.3 is always encrypting large parts of the TL section="2.1.4" format="default"/> by amending it in accordance with
S handshake including the certificate messages.</t> the following discussion.</t>
<t>EAP-TLS 1.3 significantly improves privacy when compared to
<t>EAP-TLS peer and server implementations supporting TLS earlier versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites
1.3 MUST support anonymous Network Access Identifiers (NAIs) (Section 2.4 in <x without confidentiality, which means that TLS 1.3 is always
ref target="RFC7542"/>) and a client supporting TLS 1.3 MUST NOT send its userna encrypting large parts of the TLS handshake including the
me in cleartext in the Identity Response. Following <xref target="RFC7542"/>, it certificate messages.</t>
is RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constr
uctions such as a fixed username (e.g., anonymous@realm) or an encrypted usernam
e (e.g., xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. Note t
hat the NAI MUST be a UTF-8 string as defined by the grammar in Section 2.2 of <
xref target="RFC7542"/>.</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 encr
ypted, there is no need to send an empty certificate_list and perform a second h
andshake for privacy (as needed by EAP-TLS with earlier versions of TLS). When E
AP-TLS is used with TLS version 1.3 the EAP-TLS peer and EAP-TLS server SHALL fo
llow 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 ce
rtificate to send, and the EAP-TLS server MAY 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 and the message flow with privacy is just th
e normal message flow as shown in <xref target="figbase1"/>.</t>
</section>
<section title='Fragmentation'>
<t>This section updates Section 2.1.5 of <xref target="RF
C5216"/> by amending it in accordance with the following discussion.</t>
<t>Including ContentType (1 byte), ProtocolVersion (2 byt
es), and length (2 bytes) headers a single TLS record may be up to 16645 octets
in length. EAP-TLS fragmentation support is provided through addition of a flags
octet within the EAP-Response and EAP-Request packets, as well as a (conditiona
l) TLS Message Length field of four octets. Implementations MUST NOT set the L b
it in unfragmented messages, but MUST accept unfragmented messages with and with
out the L bit set.</t>
<t>Some EAP implementations and access networks may limi
t the number of EAP packet exchanges that can be handled. To avoid fragmentation
, it is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and trust
anchor certificates small and the length of the certificate chains short. In ad
dition, it is RECOMMENDED to use mechanisms that reduce the sizes of Certificate
messages. For a detailed discussion on reducing message sizes to prevent fragme
ntation, see <xref target="I-D.ietf-emu-eaptlscert"/>.</t>
</section>
</section>
<section title='Identity Verification' anchor="identity">
<t>This section updates Section 2.2 of <xref target="RFC5216"/> b
y amending it in accordance with the following discussion. The guidance in this
section is relevant for EAP-TLS in general (regardless of the underlying TLS ver
sion used).</t>
<t>The EAP peer identity provided in the EAP-Response/Identity is
not authenticated by EAP-TLS. Unauthenticated information MUST NOT be used for
accounting purposes or to give authorization. The authenticator and the EAP-TLS
server MAY examine the identity presented in EAP-Response/Identity for purposes
such as routing and EAP method selection. EAP-TLS servers MAY reject conversatio
ns if the identity does not match their policy. Note that this also applies to r
esumption, see Sections <xref target="resumption" format="counter"/>, <xref targ
et="secauth" format="counter"/>, and <xref target="secres" format="counter"/>.</
t>
<t>The EAP server identity in the TLS server certificate is typic
ally 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 differe
nt certificate, EAP peer implementations SHOULD allow for the configuration of o
ne or more trusted root certificates (CA certificate) to authenticate the server
certificate and one or more server names to match against the SubjectAltName (S
AN) extension in the server certificate. If any of the configured names match an
y of the names in the SAN extension then the name check passes. To simplify name
matching, an EAP-TLS deployment can assign a name to represent an authorized EA
P server and EAP Server certificates can include this name in the list of SANs f
or each certificate that represents an EAP-TLS server. If server name matching i
s 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 use
d with a public root CA, then effectively any server can obtain a certificate wh
ich will be trusted for EAP authentication by the Peer. While this guidance to v
erify domain names is new, and was not mentioned in <xref target="RFC5216"/>, 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 automated methods of provisioning are RECOMMEN
DED. For example, the eduroam federation <xref target="RFC7593"/> provides a Con
figuration Assistant Tool (CAT) to automate the configuration process. In the ab
sence of a trusted root CA certificate (user configured or system-wide), EAP pee
rs MAY implement a trust on first use (TOFU) mechanism where the peer trusts and
stores the server certificate during the first connection attempt. The EAP peer
ensures that the server presents the same stored certificate on subsequent inte
ractions. Use of a TOFU mechanism does not allow for the server certificate to c
hange without out-of-band validation of the certificate and is therefore not sui
table for many deployments including ones where multiple EAP servers are deploye
d for high availability. TOFU mechanisms increase the susceptibility to traffic
interception attacks and should only be used if there are adequate controls in p
lace to mitigate this risk.</t>
</section>
<section title='Key Hierarchy' anchor="keyheirarchy"> <t>EAP-TLS peer and server implementations supporting TLS 1.3
<t>This section updates Section 2.3 of <xref target="RFC5216"/> b <bcp14>MUST</bcp14> support anonymous Network Access Identifiers
y replacing it in accordance with the following discussion.</t> (NAIs) (<xref target="RFC7542" sectionFormat="of" section="2.4"
format="default"/>). A client supporting TLS 1.3 <bcp14>MUST
NOT</bcp14> send its username (or any other permanent identifiers)
in cleartext in the Identity Response (or any message used instead
of the Identity Response). Following <xref target="RFC7542"
format="default"/>, it is <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 <bcp14>MUST</bcp14> be a UTF-8 string as
defined by the grammar in <xref target="RFC7542" section="2.2"
sectionFormat="of" format="default"/>.</t>
<t>The HelloRequest message used for privacy in EAP-TLS 1.2 does not e
xist 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 use
d with TLS version 1.3, the EAP-TLS peer and EAP-TLS server <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 <bcp14>MAY</bcp14> treat an empty c
ertificate_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 and the message flow with privacy is just the normal mess
age flow as shown in <xref target="figbase1" format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Fragmentation</name>
<t>This section updates <xref target="RFC5216" sectionFormat="of" sect
ion="2.1.5" format="default"/> by amending it in accordance with the following d
iscussion.</t>
<t>Including ContentType (1 byte), ProtocolVersion (2 bytes), and
length (2 bytes) headers, a single TLS record may be up to 16645
octets in length. EAP-TLS fragmentation support is provided through
addition of a flags octet within the EAP-Response and EAP-Request
packets, as well as a (conditional) TLS Message Length field of four
octets. Implementations <bcp14>MUST NOT</bcp14> set the L bit in
unfragmented messages, but they <bcp14>MUST</bcp14> accept unfragmente
d
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 <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
<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="RFC9191"
format="default"/>.</t>
</section>
</section>
<section anchor="identity" numbered="true" toc="default">
<name>Identity Verification</name>
<t>This section replaces <xref 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 <bcp14>MUST
NOT</bcp14> be used for accounting purposes or to give
authorization. The authenticator and the EAP-TLS server
<bcp14>MAY</bcp14> examine the identity presented in
EAP-Response/Identity for purposes such as routing and EAP method
selection. EAP-TLS servers <bcp14>MAY</bcp14> reject conversations if
the identity does not match their policy. Note that this also applies
to 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 cert
ificate, EAP peer implementations <bcp14>SHOULD</bcp14> allow for the configurat
ion of one or more trusted root certificates (CA certificate) to authenticate th
e server certificate and one or more server names to match against the SubjectAl
tName (SAN) extension in the server certificate. If any of the configured names
match any of the names in the SAN extension, then the name check passes. To simp
lify name matching, an EAP-TLS deployment can assign a name to represent an auth
orized 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 m
atching is not used, then it degrades the confidence that the EAP server with wh
ich it is interacting is authoritative for the given network. If name matching i
s not used with a public root CA, then effectively any server can obtain a certi
ficate that will be trusted for EAP authentication by the peer. While this guida
nce to verify domain names is new, and was not mentioned in <xref target="RFC521
6" format="default"/>, it has been widely implemented in EAP-TLS peers. As such,
it is believed that this section contains minimal new interoperability or imple
mentation requirements on EAP-TLS peers and can be applied to earlier versions o
f TLS.</t>
<t>TLS 1.3 replaces the TLS pseudorandom function (PRF) used in e <t>The process of configuring a root CA certificate and a server name is
arlier versions of TLS with HKDF and completely changes the Key Schedule. The ke non-trivial; therefore, automated methods of provisioning are <bcp14>RECOMMENDE
y hierarchies shown in Section 2.3 of <xref target="RFC5216"/> are therefore not D</bcp14>. For example, the eduroam federation <xref target="RFC7593" format="de
correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 the key schedule fault"/> provides a Configuration Assistant Tool (CAT) to automate the configura
is described in Section 7.1 of <xref target="RFC8446"/>.</t> tion process. In the absence of a trusted root CA certificate (user configured o
r system-wide), EAP peers <bcp14>MAY</bcp14> implement a trust on first use (TOF
U) 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 th
e certificate and is therefore not suitable for many deployments including ones
where multiple EAP servers are deployed for high availability. TOFU mechanisms i
ncrease the susceptibility to traffic interception attacks and should only be us
ed if there are adequate controls in place to mitigate this risk.</t>
</section>
<t>When EAP-TLS is used with TLS version 1.3 the Key_Material and <section anchor="keyhierarchy" numbered="true" toc="default">
Method-Id SHALL be derived from the exporter_secret using the TLS exporter inte <name>Key Hierarchy</name>
rface <xref target="RFC5705"/> (for TLS 1.3 this is defined in Section 7.5 of <x
ref target="RFC8446"/>). Type is the value of the EAP Type field defined in Sect
ion 2 of <xref target="RFC3748"/>. For EAP-TLS the Type field has value 0x0D.</t
>
<figure><artwork><![CDATA[ <t>This section updates <xref target="RFC5216" sectionFormat="of" sectio
n="2.3" format="default"/> by replacing it in accordance with the following disc
ussion.</t>
<t>TLS 1.3 replaces the TLS pseudorandom function (PRF) used in
earlier versions of TLS with the HMAC-based Key Derivation Function
(HKDF) and completely changes the key schedule. The key hierarchies
shown in <xref 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 <xref
target="RFC8446" sectionFormat="of" section="7.1"
format="default"/>.</t>
<t>When EAP-TLS is used with TLS version 1.3, the Key_Material and
Method-Id <bcp14>SHALL</bcp14> be derived from the exporter_secret
using the TLS exporter interface <xref target="RFC5705"
format="default"/> (for TLS 1.3, this is defined in <xref
target="RFC8446" sectionFormat="of" section="7.5"
format="default"/>). Type is the value of the EAP Type field defined
in <xref target="RFC3748" section="2" sectionFormat="of"
format="default"/>. For EAP-TLS, the Type field has value 0x0D.</t>
<sourcecode><![CDATA[
Type = 0x0D Type = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type, 128) Type, 128)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
Type, 64) Type, 64)
Session-Id = Type || Method-Id Session-Id = Type || Method-Id
]]></artwork></figure> ]]></sourcecode>
<t>The MSK and EMSK are derived from the Key_Material in the same
<t>The MSK and EMSK are derived from the Key_Material in the same manner as with EAP-TLS <xref target="RFC5216" sectionFormat="comma"
manner as with EAP-TLS <xref target="RFC5216"/>, Section 2.3. The definitions a section="2.3" format="default"/>. The definitions are repeated below
re repeated below for simplicity:</t> for simplicity:</t>
<sourcecode><![CDATA[
<figure><artwork><![CDATA[
MSK = Key_Material(0, 63) MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127) EMSK = Key_Material(64, 127)
]]></artwork></figure> ]]></sourcecode>
<t>Other TLS based EAP methods can use the TLS exporter in a simi
lar fashion, see <xref target="I-D.ietf-emu-tls-eap-types"/>.</t>
<t><xref target="RFC5247"/> deprecates the use of IV. Thus, RECV-
IV and SEND-IV are not exported in EAP-TLS with TLS 1.3. As noted in <xref targe
t="RFC5247"/>, lower layers use the MSK in a lower-layer-dependent manner. EAP-T
LS with TLS 1.3 exports the MSK and does not specify how it is used by lower lay
ers.</t>
<t>Note that the key derivation MUST use the length values given
above. While in TLS 1.2 and earlier it was possible to truncate the output by re
questing less data from the TLS-Exporter function, this practice is not possible
with TLS 1.3. If an implementation intends to use only a part of the output of
the TLS-Exporter function, then it MUST ask for the full output and then only us
e the desired part. Failure to do so will result in incorrect values being calcu
lated for the above keying material.</t>
<t>By using the TLS exporter, EAP-TLS can use any TLS 1.3 impleme
ntation which provides a public API for the exporter. Note that when TLS 1.2 is
used with the EAP-TLS exporter <xref target="RFC5705"/> it generates the same ke
y material as in EAP-TLS <xref target="RFC5216"/>.</t>
</section>
<section title='Parameter Negotiation and Compliance Requirements'>
<t>This section updates Section 2.4 of <xref target="RFC5216"/> b
y 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"/>), and the cipher su
ites discussed in Section 2.4 of <xref target="RFC5216"/> can therefore not be u
sed 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 a
nd EAP-TLS servers MUST comply with the compliance requirements (mandatory-to-im
plement cipher suites, signature algorithms, key exchange algorithms, extensions
, etc.) defined in Section 9 of <xref target="RFC8446"/>. In EAP-TLS with TLS 1.
3, only cipher suites with confidentiality SHALL 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 ciphe
r suites and algorithms MAY be used to secure data as done in other TLS-based EA
P methods.</t>
</section>
<section title='EAP State Machines' anchor="state">
<t>This is a new section when compared to <xref target="RFC5216"/
> and only applies to TLS 1.3. <xref target="RFC4137"/> offers a proposed state
machine for EAP.</t>
<t>TLS 1.3 <xref target="RFC8446"/> introduces post-handshake mes
sages. These post-handshake messages use the handshake content type and can be s
ent after the main handshake. Examples of post-handshake messages are NewSession
Ticket, 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 decrea
se the uncertainty for the EAP-TLS peer, the following procedure MUST be followe
d:</t>
<t>When an EAP-TLS server has successfully processed the TLS clie
nt Finished and sent its last handshake message (Finished or a post-handshake me
ssage), it sends an encrypted TLS record with application data 0x00. The encrypt
ed TLS record with application data 0x00 is a protected success result indicatio
n, as defined in <xref target="RFC3748"/>. After sending an EAP-Request that con
tains the protected success result indication, the EAP-TLS server must not send
any more EAP-Request and may only send an EAP-Success. The EAP-TLS server MUST N
OT send an encrypted TLS record with application data 0x00 alert before it has s
uccessfully processed the client finished and sent its last handshake message.</
t>
<t>TLS Error alerts SHOULD be considered a failure result indicat
ion, as defined in <xref target="RFC3748"/>. Implementations following <xref tar
get="RFC4137"/> set the alternate indication of failure variable altReject after
sending or receiving an error alert. After sending or receiving a TLS Error ale
rt, the EAP-TLS server may only send an EAP-Failure. Protected TLS Error alerts
are protected failure result indications, unprotected TLS Error alerts are not.<
/t>
<t>The keying material can be derived after the TLS server Finish
ed has been sent or received. Implementations following <xref target="RFC4137"/>
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 sen
t or received. Implementations following <xref target="RFC4137"/> can set the ea
pKeyAvailable and aaaEapKeyAvailable variables.</t>
</section>
</section>
<section title='Detailed Description of the EAP-TLS Protocol'>
<t>No updates to Section 3 of <xref target="RFC5216"/>.</t>
</section>
<section title='IANA considerations'>
<t>This section provides guidance to the Internet Assigned Numbers Author
ity (IANA) regarding registration of values related to the EAP-TLS 1.3 protocol
in accordance with <xref target="RFC8126"/>.</t>
<t>This document requires IANA to add the following labels to the TLS Exp
orter Label Registry defined by <xref target="RFC5705"/>. These labels are used
in derivation of Key_Material and Method-Id as defined in <xref target="keyheira
rchy"/>:</t>
<texttable title="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>
</section>
<section title='Security Considerations' anchor="seccon">
<t>The security considerations of TLS 1.3 <xref target="RFC8446"/
> apply to EAP-TLS 1.3</t>
<section title="Security Claims">
<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"/>. However, it st
rengthens several of the claims as described in the following updates to the not
es given in Section 5.1 of <xref target="RFC5216"/>.</t>
<t>[1] Mutual authentication: By mandating revocation checking of
certificates, the authentication in EAP-TLS with TLS 1.3 is stronger as authent
ication with revoked certificates will always fail.</t>
<t>[2] Confidentiality: The TLS 1.3 handshake offers much better
confidentiality than earlier versions of TLS. EAP-TLS with TLS 1.3 mandates use
of cipher suites that ensure confidentiality. TLS 1.3 also encrypts certificates
and some of the extensions. When using EAP-TLS with TLS 1.3, the use of privacy
is mandatory and does not cause any additional round-trips.</t>
<t>[3] Cryptographic strength: TLS 1.3 only defines strong algori
thms without major weaknesses and EAP-TLS with TLS 1.3 always provides forward s
ecrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC mode, RC4, SHA-1, MD5,
P-192, and RSA-1024 have not been registered for use in TLS 1.3.</t>
<t>[4] Cryptographic Negotiation: The TLS layer handles the negot
iation of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP-TLS i
nherits the cryptographic negotiation of AEAD algorithm, HKDF hash algorithm, ke
y exchange groups, and signature algorithm, see Section 4.1.1 of <xref target="R
FC8446"/>.</t>
</section>
<section title="Peer and Server Identities">
<t>No updates to section 5.2 of <xref target="RFC5216"/>. Note th
at <xref target="identity"/> has additional discussion on identities.</t>
</section>
<section title="Certificate Validation">
<t>No updates to section 5.3 of <xref target="RFC5216"/>. In addi
tion to section 5.3 of <xref target="RFC5216"/>, guidance on server certificate
validation can be found in <xref target="RFC6125"/>.</t>
</section>
<section title="Certificate Revocation">
<t>This section updates Section 5.4 of <xref target="RFC5216"/> b
y amending it in accordance with the following discussion.</t>
<t>There are a number of reasons (e.g., key compromise, CA compro
mise, privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA cer
tificates 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 h
ave Internet connectivity until authentication completes.</t>
<t>When EAP-TLS is used with TLS 1.3, the revocation status of al
l the certificates in the certificate chains MUST be checked (except the trust a
nchor). An implementation may use Certificate Revocation List (CRL), Online Cert
ificate Status Protocol (OSCP), or other standardized/proprietary methods for re
vocation checking. Examples of proprietary methods are non-standard formats for
distribution of revocation lists as well as certificates with very short lifetim
e.</t>
<t>EAP-TLS servers supporting TLS 1.3 MUST implement Certificate
Status Requests (OCSP stapling) as specified in <xref target="RFC6066"/> and Sec
tion 4.4.2.1 of <xref target="RFC8446"/>. It is RECOMMENDED that EAP-TLS peers a
nd EAP-TLS servers use OCSP stapling for verifying the status of the EAP-TLS ser
ver's certificate chain. When an EAP-TLS peer uses Certificate Status Requests t
o check the revocation status of the EAP-TLS server's certificate chain it MUST
treat a CertificateEntry (except the trust anchor) without a valid CertificateSt
atus extension as invalid and abort the handshake with an appropriate alert. The
OCSP status handling in TLS 1.3 is different from earlier versions of TLS, see
Section 4.4.2.1 of <xref target="RFC8446"/>. In TLS 1.3 the OCSP information is
carried in the CertificateEntry containing the associated certificate instead of
a separate CertificateStatus message as in <xref target="RFC6066"/>. This enabl
es sending OCSP information for all certificates in the certificate chain (excep
t the trust anchor).</t>
<t>To enable revocation checking in situations where EAP-TLS peer
s do not implement or use OCSP stapling, and where network connectivity is not a
vailable prior to authentication completion, EAP-TLS peer implementations MUST a
lso support checking for certificate revocation after authentication completes a
nd network connectivity is available. An EAP peer implementation SHOULD NOT trus
t the network (and any services) until it has verified the revocation status of
the server certificate after receiving network connectivity. An EAP peer MUST us
e a secure transport to verify the revocation status of the server certificate.
An EAP peer SHOULD NOT send any other traffic before revocation checking for the
server certificate is complete.</t>
</section>
<section title="Packet Modification Attacks">
<t>This section updates Section 5.5 of <xref target="RFC5216"/> b
y amending it in accordance with the following discussion.</t>
<t>As described in <xref target="RFC3748"/> and Section 5.5 of <x
ref target="RFC5216"/>, the only information that is integrity and replay protec
ted in EAP-TLS are the parts of the TLS Data that TLS protects. All other inform
ation in the EAP-TLS message exchange including EAP-Request and EAP-Response hea
ders, the identity in the 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 indica
tions and enables the EAP-TLS peer and EAP-TLS server to determine that the fail
ure result was not spoofed by an attacker. Protected failure result indications
provide integrity and replay protection but MAY be unauthenticated. Protected fa
ilure results do not significantly improve availability as TLS 1.3 treats most m
alformed data as a fatal error.</t>
</section>
<section title="Authorization" anchor="secauth">
<t>This is a new section when compared to <xref target="RFC5216"/
>. The guidance in this section is relevant for EAP-TLS in general (regardless o
f the underlying TLS version used).</t>
<t>EAP servers will usually require the EAP peer to provide a val
id certificate and will fail the connection if one is not provided. Some deploym
ents may permit no peer authentication for some or all connections. When peer au
thentication is not used, EAP-TLS server implementations MUST take care to limit
network access appropriately for unauthenticated peers and implementations MUST
use resumption with caution to ensure that a resumed session is not granted mor
e privilege than was intended for the original session. An example of limiting n
etwork access would be to invoke a vendor's walled garden or quarantine network
functionality.</t>
<t>EAP-TLS is typically encapsulated in other protocols, such as
PPP <xref target="RFC1661"/>, RADIUS <xref target="RFC2865"/>, Diameter <xref ta
rget="RFC6733"/>, or PANA <xref target="RFC5191"/>. The encapsulating protocols
can also provide additional, non-EAP information to an EAP-TLS server. This info
rmation can include, but is not limited to, information about the authenticator,
information about the EAP-TLS peer, or information about the protocol layers ab
ove or below EAP (MAC addresses, IP addresses, port numbers, Wi-Fi SSID, etc.).
EAP-TLS servers implementing EAP-TLS inside those protocols can make policy deci
sions and enforce authorization based on a combination of information from the E
AP-TLS exchange and non-EAP information.</t>
<t>As noted in <xref target="identity"/>, the identity presented
in EAP-Response/Identity is not authenticated by EAP-TLS and is therefore trivia
l for an attacker to forge, modify, or replay. Authorization and accounting MUST
be based on authenticated information such as information in the certificate or
the PSK identity and cached data provisioned for resumption as described in <xr
ef target="secres"/>. Note that the requirements for Network Access Identifiers
(NAIs) specified in Section 4 of <xref target="RFC7542"/> still apply and MUST b
e followed. </t>
<t>EAP-TLS servers MAY reject conversations based on non-EAP info
rmation provided by the encapsulating protocol, for 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 r
oot certificates (CA certificate) to authenticate the server certificate and one
or more server names to match against the SubjectAltName (SAN) extension, EAP p
eer implementations MAY allow binding the configured acceptable SAN to a specifi
c 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">
<t>This is a new section when compared to <xref target="RFC5216"/
>. The guidance in this section is relevant for EAP-TLS in general (regardless o
f the underlying TLS version used).</t>
<t>There are a number of security issues related to resumption th
at are not described in <xref target="RFC5216"/>. The problems, guidelines, and
requirements in this section therefore applies to EAP-TLS when it is used with a
ny version of TLS.</t>
<t>When resumption occurs, it is based on cached information at t
he TLS layer. To perform resumption securely, the EAP-TLS peer and EAP-TLS serve
r need to be able to securely retrieve authorization information such as certifi
cate chains from the initial full handshake. This document uses the term "cached
data" to describe such information. Authorization during resumption MUST be bas
ed on such cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh re
vocation checks on the cached certificate data. Any security policies for author
ization MUST be followed also for resumption. The certificates may have been rev
oked since the initial full handshake and the authorizations of the other party
may have been reduced. If the cached revocation data is not sufficiently current
, the EAP-TLS peer or EAP-TLS server MAY force a full TLS handshake.</t>
<t>There are two ways to retrieve the cached data from the origin
al full handshake. The first method is that the EAP-TLS server and client cache
the information locally. The cached information is identified by an identifier.
For TLS versions before 1.3, the identifier can be the session ID, for TLS 1.3,
the identifier is the PSK identity. The second method for retrieving cached info
rmation is via <xref target="RFC5077"/> or <xref target="RFC8446"/>, where the E
AP-TLS server avoids storing information locally and instead encapsulates the in
formation into a ticket which 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 s
till needs to cache the original handshake information locally and will obtain i
t while determining the session ID or PSK identity to use for resumption. Howeve
r, the EAP-TLS server is able to decrypt the ticket or PSK to obtain the origina
l handshake information.</t>
<t>The EAP-TLS server or EAP client MUST cache data during the in
itial full handshake sufficient to allow authorization decisions to be made duri
ng resumption. If cached data cannot be retrieved securely, resumption MUST NOT
be done.</t>
<t>The above requirements also apply if the EAP-TLS server expect <t>Other TLS-based EAP methods can use the TLS exporter in a similar
s some system to perform accounting for the session. Since accounting must be ti fashion; see <xref target="I-D.ietf-emu-tls-eap-types"
ed to an authenticated identity, and resumption does not supply such an identity format="default"/>.</t>
, accounting is impossible without access to cached data. Therefore, systems whi <t><xref target="RFC5247" format="default"/> deprecates the use of an
ch expect to perform accounting for the session SHOULD cache an identifier which Initialization Vector (IV). Thus, RECV-IV and SEND-IV are not exported
can be used in subsequent accounting.</t> in EAP-TLS with TLS 1.3. As noted in <xref 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 <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 <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 that provides a public API for the exporter. Note that
when TLS 1.2 is used with the EAP-TLS exporter <xref target="RFC5705"
format="default"/> it generates the same key material as in EAP-TLS
<xref target="RFC5216" format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Parameter Negotiation and Compliance Requirements</name>
<t>This section updates <xref target="RFC5216" sectionFormat="of" sectio
n="2.4" format="default"/> by amending it in accordance with the following discu
ssion.</t>
<t>TLS 1.3 cipher suites are defined differently than in earlier
versions of TLS (see <xref target="RFC8446" section="B.4"
sectionFormat="of" format="default"/>), and the cipher suites
discussed in <xref 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 <bcp14>MUST</bcp14> comply with the compliance requirements (mandato
ry-to-implement cipher suites, signature algorithms, key exchange algorithms, ex
tensions, etc.) defined in <xref target="RFC8446" sectionFormat="of" section="9"
format="default"/>. In EAP-TLS with TLS 1.3, only cipher suites with confidenti
ality <bcp14>SHALL</bcp14> be supported.</t>
<t>While EAP-TLS does not protect any application data except for the 0x
00 byte that serves as protected success indication, the negotiated cipher suite
s and algorithms <bcp14>MAY</bcp14> be used to secure data as done in other TLS-
based EAP methods.</t>
</section>
<section anchor="state" numbered="true" toc="default">
<name>EAP State Machines</name>
<t>This is a new section when compared to <xref target="RFC5216" format=
"default"/> and only applies to TLS 1.3. <xref target="RFC4137" format="default"
/> offers a proposed state machine for EAP.</t>
<t>As suggested in <xref target="RFC8446"/>, EAP-TLS peers MUST N <t>TLS 1.3 <xref target="RFC8446" format="default"/> introduces
OT store resumption PSKs or tickets (and associated cached data) for longer than post-handshake messages. These post-handshake messages use the
604800 seconds (7 days), regardless of the PSK or ticket lifetime. The EAP-TLS handshake content type and can be sent after the main
peer MAY delete them earlier based on local policy. The cached data MAY also be handshake. Examples of post-handshake messages are NewSessionTicket,
removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certific which is used for resumption and KeyUpdate, which is not useful and
ate chain has been revoked or has expired. In all such cases, an attempt at resu not expected in EAP-TLS. After sending TLS Finished, the EAP-TLS
mption results in a full TLS handshake instead.</t> 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 <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" format="default"/>. After sending an EAP-Request that
contains the protected success result indication, the EAP-TLS server
must not send any more EAP-Requests and may only send an
EAP-Success. The EAP-TLS server <bcp14>MUST NOT</bcp14> send an
encrypted TLS record with application data 0x00 before it has
successfully processed the client Finished and sent its last handshake
message.</t>
<t>Information from the EAP-TLS exchange (e.g., the identity prov <t>TLS Error alerts <bcp14>SHOULD</bcp14> be considered a failure
ided in EAP-Response/Identity) as well as non-EAP information (e.g., IP addresse result indication, as defined in <xref target="RFC3748"
s) may change between the initial full handshake and resumption. This change cre format="default"/>. Implementations following <xref target="RFC4137"
ates a "time-of-check time-of-use" (TOCTOU) security vulnerability. A malicious format="default"/> set the alternate indication of failure variable
or compromised user could supply one set of data during the initial authenticati altReject after sending or receiving an error alert. After sending or
on, and a different set of data during resumption, potentially allowing them to receiving a TLS Error alert, the EAP-TLS server may only send an
obtain access that they should not have.</t> 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" 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" format="default"/> can set the eapKeyAvailable and
aaaEapKeyAvailable variables.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Detailed Description of the EAP-TLS Protocol</name>
<t>There are no updates to <xref target="RFC5216" section="3" sectionForma
t="of"
format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This section provides guidance to the Internet Assigned Numbers Authori
ty (IANA) regarding registration of values related to EAP-TLS 1.3 in accordance
with <xref target="RFC8126" format="default"/>.</t>
<t>Per this document, IANA has added the following labels to the "TLS
Exporter Labels" registry defined by <xref target="RFC5705"
format="default"/>. These labels are used in derivation of Key_Material
and Method-Id as defined in <xref target="keyhierarchy"
format="default"/>:</t>
<table anchor="exporter-label" align="center">
<name>TLS Exporter 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>
<t>If any authorization, accounting, or policy decisions were mad <tr>
e with information that has changed between the initial full handshake and resum <td align="left">EXPORTER_EAP_TLS_Method-Id</td>
ption, and if change may lead to a different decision, such decisions MUST be re <td align="center">N</td>
evaluated. It is RECOMMENDED that authorization, accounting, and policy decision <td align="center">Y</td>
s are reevaluated based on the information given in the resumption. EAP-TLS serv <td align="left"/>
ers MAY reject resumption where the information supplied during resumption does </tr>
not match the information supplied during the original authentication. If a safe </tbody>
decision is not possible, EAP-TLS servers SHOULD reject the resumption and cont </table>
inue with a full handshake.</t> </section>
<section anchor="seccon" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security considerations of TLS 1.3 <xref target="RFC8446" format="d
efault"/> apply to EAP-TLS 1.3.</t>
<section numbered="true" toc="default">
<name>Security Claims</name>
<t>Using EAP-TLS with TLS 1.3 does not change the security claims for EA
P-TLS as given in <xref 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 <xref target="RFC5216" sectionFormat="of
" section="5.1" format="default"/>.</t>
<t>Section 2.2 and 4.2.11 of <xref target="RFC8446"/> provides se <dl indent="4">
curity considerations for TLS 1.3 resumption.</t> <dt>[1] Mutual authentication:
</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.
</dd>
</section> <dt>[2] Confidentiality:
</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.
</dd>
<section title="Privacy Considerations" anchor="privcon"> <dt>[3] Cryptographic strength:
<t>This is a new section when compared to <xref target="RFC5216"/ </dt>
>.</t> <dd>TLS 1.3 only defines strong algorithms without major weaknesses
and EAP-TLS with TLS 1.3 always provides forward secrecy; see <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.
</dd>
<t>TLS 1.3 offers much better privacy than earlier versions of TL <dt>[4] Cryptographic negotiation:
S as discussed in <xref target="privacy"/>. In this section, we only discuss the </dt>
privacy properties of EAP-TLS with TLS 1.3. For privacy properties of TLS 1.3 i <dd>The TLS layer handles the negotiation of cryptographic
tself, see <xref target="RFC8446"/>.</t> parameters. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits the
cryptographic negotiation of the AEAD algorithm, HKDF hash
algorithm, key exchange groups, and signature algorithm; see <xref
target="RFC8446" sectionFormat="of" section="4.1.1"
format="default"/>.
</dd>
</dl>
<t>EAP-TLS sends the standard TLS 1.3 handshake messages encapsul </section>
ated in EAP packets. Additionally, the EAP-TLS peer sends an identity in the fir <section numbered="true" toc="default">
st EAP-Response. The other fields in the EAP-TLS Request and the EAP-TLS Respons <name>Peer and Server Identities</name>
e packets do not contain any cleartext privacy-sensitive information.</t> <t>No updates to <xref target="RFC5216" sectionFormat="of"
section="5.2" format="default"/>. Note that <xref target="identity"
format="default"/> has additional discussion on identities.</t>
</section>
<section numbered="true" toc="default">
<name>Certificate Validation</name>
<t>No updates to <xref target="RFC5216" sectionFormat="of" section="5.3"
format="default"/>. In addition to <xref target="RFC5216" sectionFormat="of" se
ction="5.3" format="default"/>, guidance on server certificate validation can be
found in <xref target="RFC6125" format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Certificate Revocation</name>
<t>This section updates <xref target="RFC5216" sectionFormat="of" sectio
n="5.4" format="default"/> by amending it in accordance with the following discu
ssion.</t>
<t>There are a number of reasons (e.g., key compromise, CA compromise, p
rivilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificat
es 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 Int
ernet 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 <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>Tracking of users by eavesdropping on identity responses or ce <t>EAP-TLS servers supporting TLS 1.3 <bcp14>MUST</bcp14> implement
rtificates is a well-known problem in many EAP methods. When EAP-TLS is used wit Certificate Status Requests (OCSP stapling) as specified in <xref
h TLS 1.3, all certificates are encrypted, and the username part of the identity target="RFC6066" format="default"/> and <xref target="RFC8446"
response is not revealed (e.g., using anonymous NAIs). Note that even though al sectionFormat="of" section="4.4.2.1" format="default"/>. It is
l certificates are encrypted, the server's identity is only protected against pa <bcp14>RECOMMENDED</bcp14> that EAP-TLS peers and EAP-TLS servers use
ssive attackers while the client's identity is protected against both passive an OCSP stapling for verifying the status of the EAP-TLS server's
d active attackers. As with other EAP methods, even when privacy-friendly identi certificate chain. When an EAP-TLS peer uses Certificate Status
fiers or EAP tunneling is used, the domain name (i.e., the realm) in the NAI is Requests to check the revocation status of the EAP-TLS server's
still typically visible. How much privacy-sensitive information the domain name certificate chain, it <bcp14>MUST</bcp14> treat a CertificateEntry
leaks is highly dependent on how many other users are using the same domain name (but not the trust anchor) without a valid CertificateStatus extension
in the particular access network. If all EAP-TLS peers have the same domain, no as invalid and abort the handshake with an appropriate alert. The OCSP
additional information is leaked. If a domain name is used by a small subset of status handling in TLS 1.3 is different from earlier versions of TLS;
the EAP-TLS peers, it may aid an attacker in tracking or identifying the user.< see <xref target="RFC8446" sectionFormat="of" section="4.4.2.1"
/t> format="default"/>. In TLS 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"
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 no
t implement or use OCSP stapling, and where network connectivity is not availabl
e prior to authentication completion, EAP-TLS peer implementations <bcp14>MUST</
bcp14> also support checking for certificate revocation after authentication com
pletes and network connectivity is available. An EAP peer implementation <bcp14>
SHOULD NOT</bcp14> trust the network (and any services) until it has verified th
e revocation status of the server certificate after receiving network connectivi
ty. An EAP peer <bcp14>MUST</bcp14> use a secure transport to verify the revocat
ion status of the server certificate. An EAP peer <bcp14>SHOULD NOT</bcp14> send
any other traffic before revocation checking for the server certificate is comp
lete.</t>
</section>
<section numbered="true" toc="default">
<name>Packet Modification Attacks</name>
<t>This section updates <xref 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" format="default"/> and <xref
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, EAP-TLS packet header
fields, Type, Flags, EAP-Success, and EAP-Failure can be modified,
spoofed, or replayed.</t>
<t>Protected TLS Error alerts are protected failure result indications
and 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
<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 anchor="secauth" numbered="true" toc="default">
<name>Authorization</name>
<t>This is a new section when compared to <xref target="RFC5216" format=
"default"/>. The guidance in this section is relevant for EAP-TLS in general (re
gardless 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 <bcp14>MUST</bcp14> take care to limit network access
appropriately for unauthenticated peers, and implementations
<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 such as PPP
<xref target="RFC1661" format="default"/>, RADIUS <xref
target="RFC2865" format="default"/>, Diameter <xref target="RFC6733"
format="default"/>, or the Protocol for Carrying Authentication for
Network Access (PANA) <xref 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 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" 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 <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" format="default"/>. Note that the
requirements for Network Access Identifiers (NAIs) specified in <xref
target="RFC7542" sectionFormat="of" section="4" format="default"/>
still apply and <bcp14>MUST</bcp14> be followed. </t>
<t>EAP-TLS servers <bcp14>MAY</bcp14> reject conversations based on
non-EAP information provided by the encapsulating protocol, for
example if the MAC address of the authenticator does not match the
expected policy.</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 <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>
<t>Without padding, information about the size of the client cert <section anchor="secres" numbered="true" toc="default">
ificate is leaked from the size of the EAP-TLS packets. The EAP-TLS packets size <name>Resumption</name>
s may therefore leak information that can be used to track or identify the user. <t>This is a new section when compared to <xref target="RFC5216"
If all client certificates have the same length, no information is leaked. EAP- format="default"/>. The guidance in this section is relevant for
TLS peers SHOULD use record padding, see Section 5.4 of <xref target="RFC8446"/> EAP-TLS in general (regardless of the underlying TLS version
to reduce information leakage of certificate sizes.</t> used).</t>
<t>There are a number of security issues related to resumption that
are not described in <xref target="RFC5216" format="default"/>. The
problems, guidelines, and requirements in this section therefore 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 <bcp14>MUST</bcp14> be
based on such cached data. The EAP-TLS peer and EAP-TLS server
<bcp14>MAY</bcp14> perform fresh revocation checks on the cached
certificate data. Any security policies for authorization
<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 <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; for TLS 1.3, the identifier is the PSK identity. The
second method for retrieving cached information is via <xref
target="RFC5077" format="default"/> or <xref target="RFC8446"
format="default"/>, where the EAP-TLS server avoids storing
information locally and instead encapsulates the information into a
ticket that is sent to the client for storage. This ticket is
encrypted using a key that only the EAP-TLS server knows. Note that
the client still needs to cache the original handshake information
locally and 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 <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 <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 that expect to perform accounting for
the session <bcp14>SHOULD</bcp14> cache an identifier that can be used
in subsequent accounting.</t>
<t>As suggested in <xref target="RFC8446" format="default"/>, EAP-TLS
peers <bcp14>MUST NOT</bcp14> store resumption PSKs or tickets (and
associated cached data) for longer than 604800 seconds (7 days)
regardless of the PSK or ticket lifetime. The EAP-TLS peer
<bcp14>MAY</bcp14> delete them earlier based on local policy. The
cached data <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>If anonymous NAIs are not used, the privacy-friendly identifie <t>Information from the EAP-TLS exchange (e.g., the identity provided
rs need to be generated with care. The identities MUST be generated in a cryptog in EAP-Response/Identity) as well as non-EAP information (e.g., IP
raphically secure way so that it is computationally infeasible for an attacker t addresses) may change between the initial full handshake and
o differentiate two identities belonging to the same user from two identities be resumption. This change creates a "time-of-check time-of-use" (TOCTOU)
longing to different users in the same realm. This can be achieved, for instance security vulnerability. A malicious or compromised user could supply
, by using random or pseudo-random usernames such as random byte strings or ciph one set of data during the initial authentication, and a different set
ertexts and only using the pseudo-random usernames a single time. Note that the of data during resumption, potentially allowing them to obtain access
privacy-friendly usernames also MUST NOT include substrings that can be used to that they should not have.</t>
relate the identity to a specific user. Similarly, privacy-friendly username MUS <t>If any authorization, accounting, or policy decisions were made
T NOT be formed by a fixed mapping that stays the same across multiple different with information that has changed between the initial full handshake
authentications.</t> and resumption, and if change may lead to a different decision, such
decisions <bcp14>MUST</bcp14> be reevaluated. It is
<bcp14>RECOMMENDED</bcp14> that authorization, accounting, and policy
decisions are reevaluated based on the information given in the
resumption. EAP-TLS servers <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 <bcp14>SHOULD</bcp14> reject
the resumption and continue with a full handshake.</t>
<t>Sections <xref target="RFC8446" sectionFormat="bare" section="2.2"
/> and <xref target="RFC8446" section="4.2.11" sectionFormat="bare"/>
of <xref target="RFC8446"/> provide security considerations for TLS
1.3 resumption.</t>
</section>
<section anchor="privcon" numbered="true" toc="default">
<name>Privacy Considerations</name>
<t>This is a new section when compared to <xref target="RFC5216" format=
"default"/>.</t>
<t>TLS 1.3 offers much better privacy than earlier versions of TLS as di
scussed in <xref target="privacy" format="default"/>. In this section, we only d
iscuss the privacy properties of EAP-TLS with TLS 1.3. For privacy properties of
TLS 1.3 itself, see <xref 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 packe
ts do not contain any cleartext privacy-sensitive information.</t>
<t>Tracking of users by eavesdropping on Identity Responses or
certificates is a well-known problem in many EAP methods. When EAP-TLS
is used with TLS 1.3, all certificates are encrypted, and the username
part of the 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
<bcp14>SHOULD</bcp14> use record padding; see <xref 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 <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 <bcp14>MUST
NOT</bcp14> include substrings that can be used to relate the identity
to a specific user. Similarly, privacy-friendly 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 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
<bcp14>RECOMMENDED</bcp14> for EAP-TLS peers to not use EAP-TLS with
TLS 1.2 and static RSA-based cipher suites without privacy. This
implies that an EAP-TLS peer <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 numbered="true" toc="default">
<name>Pervasive Monitoring</name>
<t>This is a new section when compared to <xref target="RFC5216" format=
"default"/>.</t>
<t>An EAP-TLS peer with a policy allowing communication with EAP- <t>Pervasive monitoring refers to widespread surveillance of users. In
TLS servers supporting only TLS 1.2 without privacy and with a static RSA key ex the context of EAP-TLS, pervasive monitoring attacks can target
change is vulnerable to disclosure of the EAP-TLS peer username. An active attac EAP-TLS peer devices for tracking them (and their users) when they
ker can in this case make the EAP-TLS peer believe that an EAP-TLS server suppor join a network. By encrypting more information, mandating the use of
ting TLS 1.3 only supports TLS 1.2 without privacy. The attacker can simply impe privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3
rsonate the EAP-TLS server and negotiate TLS 1.2 with static RSA key exchange an offers much better protection against pervasive monitoring. In
d send an TLS alert message when the EAP-TLS peer tries to use privacy by sendin addition to the privacy attacks discussed above, surveillance on a
g an empty certificate message. Since the attacker (impersonating the EAP-TLS se large scale may enable tracking of a user over a wide geographical
rver) does not provide a proof-of-possession of the private key until the Finish area and across different access networks. Using information from
ed message when a static RSA key exchange is used, an EAP-TLS peer may inadverte EAP-TLS together with information gathered from other protocols
ntly disclose its identity (username) to an attacker. Therefore, it is RECOMMEND increases the risk of identifying individual users.</t>
ED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and static RSA based cipher <t>
suites without privacy. This implies that an EAP-TLS peer SHOULD NOT continue t In TLS 1.3, the post-handshake key update mechanism provides
he EAP authentication attempt if a TLS 1.2 EAP-TLS server sends an EAP-TLS/Reque forward secrecy for the traffic secrets. EAP-TLS 1.3 does not
st with a TLS alert message in response to an empty certificate message from the provide a similar mechanism for MSK and EMSK. Implementation using
peer.</t> the exported MSK and EMSK can achieve forward secrecy by frequently
</section> deriving new keys in a similar way as described in <xref
target="RFC8446" sectionFormat="of" section="7.2"/>.
<section title="Pervasive Monitoring"> </t>
<t>This is a new section when compared to <xref target="RFC5216"/ </section>
>.</t> <section numbered="true" toc="default">
<name>Discovered Vulnerabilities</name>
<t>This is a new section when compared to <xref 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" format="default"/> summarizes the attacks that were
known at the time of publishing, and BCP 195 <xref target="RFC7525"/> <x
ref 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 <bcp14>MUST</bcp14> mitigate known attacks. EAP-TLS
implementations need to monitor and follow new EAP- and TLS-related
security guidance and requirements such as <xref target="RFC8447"
format="default"/> and <xref target="RFC9155" format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Cross-Protocol Attacks</name>
<t>This is a new section when compared to <xref 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 and
then "resume" that session in another protocol. <xref
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 and do not indicate that the
certificates are suitable for use with HTTPS or other protocols on the
named host.</t>
<t><xref target="resumption" format="default"/> suggests that
authorization rules should be reapplied on resumption but does not
mandate this behavior. As a result, this cross-protocol resumption
could allow the attacker to bypass authorization 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 <bcp14>RECOMMENDED</bcp14> to help keep
different protocol usages separate.</t>
</section>
</section>
</middle>
<back>
<t>Pervasive monitoring refers to widespread surveillance of user <displayreference target="I-D.ietf-emu-tls-eap-types" to="TLS-EAP-TYPES"/>
s. In the context of EAP-TLS, pervasive monitoring attacks can target EAP-TLS pe <displayreference target="I-D.ietf-tls-rfc8446bis" to="TLS-bis"/>
er devices for tracking them (and their users) as and when they join a network. <displayreference target="I-D.ietf-tls-ticketrequests" to="TICKET-REQUESTS"/>
By encrypting more information, mandating the use of privacy, and always providi
ng forward secrecy, EAP-TLS with TLS 1.3 offers much better protection against p
ervasive monitoring. In addition to the privacy attacks discussed above, surveil
lance on a large scale may enable tracking of a user over a wide geographical ar
ea and across different access networks. Using information from EAP-TLS together
with information gathered from other protocols increases the risk of identifyin
g individual users.</t>
</section> <references>
<name>References</name>
<section title="Discovered Vulnerabilities"> <references>
<t>This is a new section when compared to <xref target="RFC5216"/ <name>Normative References</name>
>.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3748.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5216.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5705.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6066.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7542.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
</references>
<references>
<name>Informative references</name>
<t>Over the years, there have been several serious attacks on ear <reference anchor="IEEE-802.1X">
lier versions of Transport Layer Security (TLS), including attacks on its most c <front>
ommonly used ciphers and modes of operation. <xref target="RFC7457"/> summarizes <title>IEEE Standard for Local and Metropolitan Area
the attacks that were known at the time of publishing and BCP 195 <xref target= Networks--Port-Based Network Access Control</title>
"RFC7525"/> <xref target="RFC8996"/> provides recommendations and requirements f <author>
or improving the security of deployed services that use TLS. However, many of th <organization>IEEE</organization>
e attacks are less serious for EAP-TLS as EAP-TLS only uses the TLS handshake an </author>
d does not protect any application data. EAP-TLS implementations MUST mitigate k <date month="February" year="2020"/>
nown attacks. EAP-TLS implementations need to monitor and follow new EAP and TLS </front>
related security guidance and requirements such as <xref target="RFC8447"/> and
<xref target="I-D.ietf-tls-md5-sha1-deprecate"/>.</t>
</section> <seriesInfo name="IEEE Std." value="802.1X-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9018454"/>
</reference>
<section title="Cross-Protocol Attacks"> <reference anchor="IEEE-802.11">
<t>This is a new section when compared to <xref target="RFC5216"/ <front>
>.</t> <title>IEEE Standard for Information technology-Telecommunications a
nd information exchange between systems Local and metropolitan area networks-Spe
cific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physi
cal Layer (PHY) Specifications</title>
<author>
<organization>IEEE</organization>
</author>
<date month="February" year="2021"/>
</front>
<t>Allowing the same certificate to be used in multiple protocols <seriesInfo name="IEEE Std." value="802.11-2020"/>
can potentially allow an attacker to authenticate via one protocol, and then "r <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7786995"/>
esume" that session in another protocol. <xref target="identity"/> above suggest </reference>
s that certificates typically have one or more FQDNs in the SAN extension. Howev
er, those fields are for EAP validation only, and do not indicate that the certi
ficates are suitable for use on WWW (or other) protocol server on the named host
.</t>
<t><xref target="resumption"/> above suggests that authorization <reference anchor="IEEE-802.1AE">
rules should be re-applied on resumption, but does not mandate this behavior. As <front>
a result, this cross-protocol resumption could allow the attacker to bypass aut <title>IEEE Standard for Local and metropolitan area networks -- Med
horization policies, and to obtain undesired access to secured systems. Along wi ia Access Control (MAC) Security</title>
th making sure that appropriate authorization information is available and used <author>
during resumption, using different certificates and resumption caches for differ <organization>IEEE</organization>
ent protocols is RECOMMENDED to help keep different protocol usages separate.</t </author>
> <date month="December" year="2018"/>
</section> </front>
</section>
</middle> <seriesInfo name="IEEE Std." value="802.1AE-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
</reference>
<back> <reference anchor="TS.33.501">
<front>
<title>Security architecture and procedures for 5G system</title>
<author>
<organization>3GPP</organization>
</author>
<date month="January" year="2022"/>
</front>
<refcontent>Release 17
</refcontent>
<seriesInfo name="TS" value="33.501"/>
</reference>
<references title='Normative References'> <reference anchor="MulteFire">
<?rfc include='reference.RFC.2119'?> <front>
<?rfc include='reference.RFC.3748'?> <title>MulteFire Release 1.1 Specification</title>
<?rfc include='reference.RFC.5216'?> <author>
<?rfc include='reference.RFC.5280'?> <organization>MulteFire Alliance</organization>
<?rfc include='reference.RFC.5705'?> </author>
<?rfc include='reference.RFC.6066'?> <date year="2019"/>
<?rfc include='reference.RFC.6960'?> </front>
<?rfc include='reference.RFC.7542'?> </reference>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.RFC.8446'?>
</references>
<references title='Informative references'> <reference anchor="PEAP">
<reference anchor="IEEE-802.1X"> <front>
<front> <title>[MS-PEAP]: Protected Extensible Authentication Protocol
<title>IEEE Standard for Local and metropolitan area networks -- Por (PEAP)</title>
t-Based Network Access Control</title> <author>
<author> <organization>Microsoft Corporation</organization>
<organization>Institute of Electrical and Electronics Engineers</o </author>
rganization> <date month="June" year="2021"/>
</author> </front>
<date month="February" year="2020" /> </reference>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name="IEEE Standard 802.1X-2020" value="" /> FC.1661.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor="IEEE-802.11"> FC.2246.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>IEEE Standard for Information technology—Telecommunications a FC.2560.xml"/>
nd information exchange between systems Local and metropolitan area networks—Spe <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
cific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physi FC.2865.xml"/>
cal Layer (PHY) Specifications</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author> FC.3280.xml"/>
<organization>Institute of Electrical and Electronics Engineers</o <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
rganization> FC.4137.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date month="February" year="2021" /> FC.4282.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name="IEEE Standard 802.11-2020" value="" /> FC.4346.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor="IEEE-802.1AE"> FC.4851.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>IEEE Standard for Local and metropolitan area networks -- Med FC.5077.xml"/>
ia Access Control (MAC) Security</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author> FC.5191.xml"/>
<organization>Institute of Electrical and Electronics Engineers</o <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
rganization> FC.5246.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date month="December" year="2018" /> FC.5247.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name="IEEE Standard 802.1AE-2018" value="" /> FC.5281.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor="TS.33.501"> FC.6125.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<title>Security architecture and procedures for 5G System</title> FC.6733.xml"/>
<author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization>3GPP</organization> FC.7170.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date month="September" year="2021" /> FC.7406.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name="3GPP TS" value="33.501 17.3.0" /> FC.7457.xml"/>
</reference> <xi:include
<reference anchor="MulteFire"> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.x
<front> ml"/>
<title>MulteFire Release 1.1 specification</title> <xi:include
<author> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8996.x
<organization>MulteFire</organization> ml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date year="2019" /> FC.7593.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</reference> FC.8126.xml"/>
<reference anchor="PEAP"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.8447.xml"/>
<title>[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
)</title> FC.9155.xml"/>
<author>
<organization>Microsoft Corporation</organization>
</author>
<date month="June" year="2021" />
</front>
</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'?>
</references>
<section title="Updated References" anchor="updateref"> <reference anchor='RFC9191'>
<t> <front>
All the following references in <xref target="RFC5216"/> are updated as s <title>Handling Large Certificates and Long Certificate Chains in TLS-Based EAP
pecified below when EAP-TLS is used with TLS 1.3. Methods</title>
</t> <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>
<t> <xi:include
All references to <xref target="RFC2560"/> are updated to refer to <xref href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-ticketrequ
target="RFC6960"/>. ests.xml"/>
</t>
<t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
All references to <xref target="RFC3280"/> are updated to refer to <xref .ietf-emu-tls-eap-types.xml"/>
target="RFC5280"/>. References to Section 4.2.1.13 of <xref target="RFC3280"/> a
re updated to refer to Section 4.2.1.12 of <xref target="RFC5280"/>.
</t>
<t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
All references to <xref target="RFC4282"/> are updated to refer to <xref .ietf-tls-rfc8446bis.xml"/>
target="RFC7542"/>. References to Section 2.1 of <xref target="RFC4282"/> are up
dated to refer to Section 2.2 of <xref target="RFC7542"/>.
</t>
</section>
<section title="Acknowledgments" numbered="false"> </references>
<t> </references>
The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, Alan D <section anchor="updateref" numbered="true" toc="default">
eKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, Eric Rescorla, Ji <name>Updated References</name>
m Schaad, Joseph Salowey, Martin Thomson, Vesa Torvinen, Hannes Tschofenig, and <t>
Heikki Vatiainen for comments and suggestions on the draft. Special thanks to th The following references in <xref target="RFC5216" format="default"/> are
e document shepherd Joseph Salowey. updated as specified below when EAP-TLS is used with TLS 1.3.
</t> </t>
</section>
<section title="Contributors" numbered="false"> <ul>
<li>
<t> <t>
Alan DeKok, FreeRADIUS All references to <xref target="RFC2560" format="default"/> are updated t
</t> o refer to <xref target="RFC6960" format="default"/>.
</section> </t>
</li>
<li>
<t>
All references to <xref target="RFC3280" format="default"/> are
updated to refer to <xref target="RFC5280"
format="default"/>. References to <xref target="RFC3280"
section="4.2.1.13" sectionFormat="of" format="default"/> are updated
to refer to <xref target="RFC5280" sectionFormat="of"
section="4.2.1.12" format="default"/>.
</t>
</li>
<li>
<t>
All references to <xref target="RFC4282" format="default"/> are
updated to refer to <xref target="RFC7542"
format="default"/>. References to <xref target="RFC4282"
sectionFormat="of" section="2.1" format="default"/> are updated to
refer to <xref target="RFC7542" sectionFormat="of" section="2.2" format="
default"/>.
</t>
</li>
</ul>
</section>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The authors want to thank <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 this document. Special thanks to the Document Shepherd
<contact fullname="Joseph Salowey"/>.
</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>
<contact fullname="Alan DeKok"/>, FreeRADIUS
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 69 change blocks. 
1193 lines changed or deleted 1413 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/