rfc9427xml2.original.xml   rfc9427.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!DOCTYPE rfc [
C.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC3748 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY zwsp "&#8203;">
C.3748.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC5216 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY wj "&#8288;">
C.5216.xml">
<!ENTITY RFC5705 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5705.xml">
<!ENTITY RFC7170 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7170.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8446.xml">
<!ENTITY RFC9190 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9190.xml">
<!ENTITY I-D.josefsson-pppext-eap-tls-eap SYSTEM "https://xml2rfc.ietf.org/publi
c/rfc/bibxml3/reference.I-D.josefsson-pppext-eap-tls-eap.xml">
<!ENTITY RFC1994 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.1994.xml">
<!ENTITY RFC2433 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2433.xml">
<!ENTITY RFC2759 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2759.xml">
<!ENTITY RFC4137 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4137.xml">
<!ENTITY RFC4851 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4851.xml">
<!ENTITY RFC5281 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5281.xml">
<!ENTITY RFC5422 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5422.xml">
<!ENTITY RFC7542 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7542.xml">
<!ENTITY RFC7585 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7585.xml">
]> ]>
<rfc submissionType="IETF" docName="draft-ietf-emu-tls-eap-types-13" category="s
td" updates="4851, 5281, 7170" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2023-03-01T23:53:37Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc toc="yes"?>
<front>
<title>TLS-based EAP types and TLS 1.3</title>
<author fullname="Alan DeKok" initials="A." surname="DeKok"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<organization>The FreeRADIUS Server Project</organization> std" consensus="true" docName="draft-ietf-emu-tls-eap-types-13" number="9427" up
dates="4851, 5281, 7170" ipr="trust200902" obsoletes="" xml:lang="en" symRefs="t
rue" sortRefs="true" tocInclude="true" version="3">
<front>
<title abbrev="TLS-Based EAP Types for Use with TLS 1.3">TLS-Based Extensibl
e Authentication Protocol (EAP) Types for Use with TLS 1.3</title>
<seriesInfo name="RFC" value="9427"/>
<author fullname="Alan DeKok" initials="A." surname="DeKok">
<organization abbrev="FreeRADIUS">The FreeRADIUS Server Project</organizat
ion>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<region></region> <region/>
<country></country> <country/>
</postal> </postal>
<email>aland@freeradius.org</email> <email>aland@freeradius.org</email>
</address> </address>
</author> </author>
<date year="2023" month="March"/> <date year="2023" month="June"/>
<abstract><t> <area>sec</area>
EAP-TLS (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many <workgroup>emu</workgroup>
other EAP types also depend on TLS, such as EAP-FAST (RFC 4851), EAP-
TTLS (RFC 5281), TEAP (RFC 7170), and possibly many vendor specific
EAP methods. This document updates those methods in order to use the
new key derivation methods available in TLS 1.3. Additional changes
necessitated by TLS 1.3 are also discussed.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sect-1"><t>
EAP-TLS has been updated for TLS 1.3 in <xref target="RFC9190"/>. Many other
EAP
types also depend on TLS, such as EAP-FAST <xref target="RFC4851"/>, EAP-TTLS
<xref target="RFC5281"/>, TEAP <xref target="RFC7170"/>, and possibly many ve
ndor specific EAP
methods such as PEAP <xref target="I-D.josefsson-pppext-eap-tls-eap"/>. All
of these methods use key derivation
functions which are no longer applicable to TLS 1.3. As such, all of
those methods are incompatible with TLS 1.3.</t>
<t> <abstract>
This document updates those methods in order to be used with TLS 1.3. <t>
The Extensible Authentication Protocol-TLS (EAP-TLS) (RFC 5216) has been upda
ted for TLS
1.3 in RFC 9190. Many other EAP Types
also depend on TLS, such as EAP-Flexible Authentication via Secure Tunneling
(EAP-FAST) (RFC 4851), EAP-Tunneled TLS (EAP-TTLS) (RFC 5281), the Tunnel Extens
ible Authentication Protocol (TEAP) (RFC 7170). It is possible that many vendor-
specific EAP methods, such as the Protected Extensible Authentication Protocol (
PEAP), depend on TLS as well. This document
updates those methods in order to use the new key derivation methods
available in TLS 1.3. Additional changes necessitated by TLS 1.3 are also
discussed.</t>
</abstract>
</front>
<middle>
<section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name>
<t>
EAP-TLS has been updated for TLS 1.3 in <xref target="RFC9190" format="defaul
t"/>. Many other EAP
Types also depend on TLS, such as EAP-FAST <xref target="RFC4851" format="def
ault"/>, EAP-TTLS
<xref target="RFC5281" format="default"/>, and TEAP <xref target="RFC7170" fo
rmat="default"/>. It is possible that many vendor-specific EAP
methods, such as PEAP <xref target="I-D.josefsson-pppext-eap-tls-eap" format=
"default"/>, depend on TLS as well. All of these methods use key derivation
functions that are no longer applicable to TLS 1.3; thus, these methods are i
ncompatible with TLS 1.3.</t>
<t>
This document updates these methods in order to be used with TLS 1.3.
These changes involve defining new key derivation functions. We also These changes involve defining new key derivation functions. We also
discuss implementation issues in order to highlight differences discuss implementation issues in order to highlight differences
between TLS 1.3 and earlier versions of TLS.</t> between TLS 1.3 and earlier versions of TLS.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Using TLS-Based EAP Methods with TLS 1.3</name>
<section title="Requirements Language" anchor="sect-1.1"><t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", In general, all of the requirements in <xref target="RFC9190" format="default
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "/> apply to other EAP
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the
y appear in all
capitals, as shown here.</t>
</section>
</section>
<section title="Using TLS-based EAP methods with TLS 1.3" anchor="sect-2"
><t>
In general, all of the requirements of <xref target="RFC9190"/> apply to othe
r EAP
methods that wish to use TLS 1.3. Unless otherwise required herein, methods that wish to use TLS 1.3. Unless otherwise required herein,
implementations of EAP methods that wish to use TLS 1.3 MUST follow implementations of EAP methods that wish to use TLS 1.3 <bcp14>MUST</bcp14> f
the guidelines in <xref target="RFC9190"/>.</t> ollow
the guidelines in <xref target="RFC9190" format="default"/>.</t>
<t> <t>
There remain some differences between EAP-TLS and other TLS-based EAP There remain some differences between EAP-TLS and other TLS-based EAP
methods which are addressed by this document. The main difference is methods that are addressed by this document. The main difference is
that <xref target="RFC9190"/> uses the EAP-TLS Type (value 0x0D) in a number that <xref target="RFC9190" format="default"/> uses the EAP-TLS Type (value 0
of x0D) in a number of
calculations, whereas other method types will use their own Type calculations, whereas other method types will use their own Type
value instead of the EAP-TLS Type value. This topic is discussed value instead of the EAP-TLS Type value. This topic is discussed
further below in <xref target="sect-2.1"/>.</t> further in <xref target="sect-2.1" format="default"/>.</t>
<t>
<t> An additional difference is that <xref target="RFC9190" sectionFormat="comma"
An additional difference is that <xref target="RFC9190"/> <xref target="sect- section="2.5"/> requires the EAP server to send a
2.5"/> requires that protected success result indication
once the EAP-TLS handshake has completed, the EAP server sends a once the EAP-TLS handshake has completed. This indication is composed of
protected success result indication. This indication is composed of
one octet (0x00) of application data. Other TLS-based EAP methods one octet (0x00) of application data. Other TLS-based EAP methods
also use this result indication, but only during resumption. When also use this result indication, but only during resumption. When
other TLS-based EAP methods use full authentication, the result other TLS-based EAP methods use full authentication, the result
indication is not needed, and is not used. This topic is explained indication is not needed or used. This topic is explained
in more detail below, in <xref target="sect-3"/> and <xref target="sect-4"/>. in more detail in Sections <xref target="sect-3" format="counter"/> and <xref
</t> target="sect-4" format="counter"/>.</t>
<t>
<t> Finally, this document includes clarifications on how various TLS-
Finally, the document includes clarifications on how various TLS-
based parameters are calculated when using TLS 1.3. These parameters based parameters are calculated when using TLS 1.3. These parameters
are different for each EAP method, so they are discussed separately.</t> are different for each EAP method, so they are discussed separately.</t>
<section anchor="sect-2.1" numbered="true" toc="default">
<section title="Key Derivation" anchor="sect-2.1"><t> <name>Key Derivation</name>
<t>
The key derivation for TLS-based EAP methods depends on the value of The key derivation for TLS-based EAP methods depends on the value of
the EAP Type as defined by <xref target="IANA"/> in the Extensible Authentica the EAP Type as defined by <xref target="IANA" format="default"/> in the "Ext
tion ensible Authentication
Protocol (EAP) Registry. The most important definition is of the Protocol (EAP) Registry". The most important definition is of the
Type field, as first defined in <xref target="RFC3748"/> Section 2:</t> Type field, as first defined in <xref target="RFC3748" sectionFormat="comma"
section="2"/>:</t>
<figure><artwork><![CDATA[ <t indent="3">Type = value of the EAP Method type</t>
Type = value of the EAP Method type <t>
]]></artwork>
</figure>
<t>
For the purposes of this specification, when we refer to logical For the purposes of this specification, when we refer to logical
Type, we mean that the logical Type is defined to be 1 octet for Type, we mean that the logical Type is defined as one octet for
values smaller than 254 (the value for the Expanded Type), and when values smaller than 254 (the value for the Expanded Type). When
Expanded EAP Types are used, the logical Type is defined to be the Expanded EAP Types are used, the logical Type is defined as the
concatenation of the fields required to define the Expanded Type, concatenation of the fields required to define the Expanded Type,
including the Type with value 0xfe, Vendor-Id (in network byte order) including the Type with value 0xfe, Vendor-Id (in network byte order),
and Vendor-Type fields (in network byte order) defined in <xref target="RFC37 and Vendor-Type fields (in network byte order) defined in <xref target="R
48"/> FC3748" sectionFormat="comma" section="5.7"/>, as given below:</t>
Section 5.7, as given below:</t>
<figure><artwork><![CDATA[ <artwork name="" type=""><![CDATA[
Type = 0xFE || Vendor-Id || Vendor-Type Type = 0xFE || Vendor-Id || Vendor-Type
]]></artwork> ]]></artwork>
</figure> <t>
<t> This definition does not alter the meaning of Type in <xref target="RFC3748"
This definition does not alter the meaning of Type in <xref target="RFC3748"/ format="default"/> or
>, or
change the structure of EAP packets. Instead, this definition allows change the structure of EAP packets. Instead, this definition allows
us to simplify references to EAP Types, by using a logical "Type" us to simplify references to EAP Types by using a logical "Type"
instead of referring to "the Type field or the Type field with value 0xfe, pl us the Vendor-ID and Vendor-Type". For example, the value of instead of referring to "the Type field or the Type field with value 0xfe, pl us the Vendor-ID and Vendor-Type". For example, the value of
Type for PEAP is simply 0x19.</t> Type for PEAP is simply 0x19.</t>
<t>
<t> Note that unlike TLS 1.2 and earlier, the calculation of the TLS-Exporter fun
Note that unlike TLS 1.2 and earlier, the calculation of TLS-Exporter ction
depends on the length passed to it. Implementations therefore MUST depends on the length passed to it. Therefore, implementations <bcp14>MUST</
bcp14>
pass the correct length instead of passing a large length and pass the correct length instead of passing a large length and
truncating the output. Any output calculated using a larger length truncating the output. Any output calculated using a larger length
value, and which is then truncated, will be different from the output value, which is then truncated, will be different from the output
which was calculated using the correct length.</t> that was calculated using the correct length.</t>
<t>
<t>
Unless otherwise discussed below, the key derivation functions for Unless otherwise discussed below, the key derivation functions for
all TLS-based EAP Types are defined in <xref target="RFC9190"/> <xref target= "sect-2.3"/>, and all TLS-based EAP Types are defined in <xref target="RFC9190" sectionFormat=" comma" section="2.3"/> and
reproduced here for clarity. These definitions include ones for the reproduced here for clarity. These definitions include ones for the
Master Session Key (MSK) and the Extended Master Session Key (EMSK):</t> Master Session Key (MSK) and the Extended Master Session Key (EMSK):</t>
<artwork name="" type=""><![CDATA[
<figure><artwork><![CDATA[ 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 MSK = Key_Material(0, 63)
MSK = Key_Material(0, 63) EMSK = Key_Material(64, 127)
EMSK = Key_Material(64, 127)
]]></artwork> ]]></artwork>
</figure> <t>
<t> We note that these definitions reuse the EAP-TLS exporter labels
We note that these definitions re-use the EAP-TLS exporter labels,
and change the derivation only by adding a dependency on the logical and change the derivation only by adding a dependency on the logical
Type. The reason for this change is simplicity. The inclusion of Type. The reason for this change is simplicity. The inclusion of
the EAP type makes the derivation method-specific. There is no need the EAP Type makes the derivation method specific. There is no need
to use different labels for different EAP types, as was done earlier.</t> to use different labels for different EAP Types as was done earlier.</t>
<t>
<t> These definitions apply in their entirety to EAP-TTLS <xref target="RFC5281"
These definitions apply in their entirety to EAP-TTLS <xref target="RFC5281"/ format="default"/> and
> and PEAP as defined in <xref target="I-D.josefsson-pppext-eap-tls-eap" format="de
PEAP as defined in <xref target="I-D.josefsson-pppext-eap-tls-eap"/> and <xre fault"/> and <xref target="MSPEAP" format="default"/>. Some definitions apply t
f target="MSPEAP"/>. Some definitions apply to o
EAP-FAST and TEAP, with exceptions as noted below.</t> EAP-FAST and TEAP with exceptions as noted below.</t>
<t>
<t> It is <bcp14>RECOMMENDED</bcp14> that vendor-defined and TLS-based EAP method
It is RECOMMENDED that vendor-defined TLS-based EAP methods use the s use the
above definitions for TLS 1.3. There is no compelling reason to use above definitions for TLS 1.3. There is no compelling reason to use
different definitions.</t> different definitions.</t>
</section>
</section> <section anchor="sect-2.2" numbered="true" toc="default">
<name>TEAP</name>
<section title="TEAP" anchor="sect-2.2"><t> <t>
TEAP previously used a Protected Access Credential (PAC), which is TEAP previously used a Protected Access Credential (PAC), which is
functionally equivalent to session tickets provided by TLS 1.3 which functionally equivalent to session tickets provided by TLS 1.3 that
contain a pre-shared key (PSK) along with other data. As such, the contain a pre-shared key (PSK) along with other data. As such, the
use of a PAC is deprecated for TEAP in TLS 1.3. PAC provisioning as use of a PAC is deprecated for TEAP in TLS 1.3. PAC provisioning, as
defined in <xref target="RFC7170"/> Section 3.8.1 is also no longer part of T defined in <xref target="RFC7170" sectionFormat="comma" section="3.8.1"/>, is
EAP also no longer part of TEAP
when TLS 1.3 is used.</t> when TLS 1.3 is used.</t>
<t>
<t> <xref target="RFC7170" sectionFormat="comma" section="5.2"/> gives a definiti
<xref target="RFC7170"/> Section 5.2 gives a definition for the Inner Method on for the Inner Method Session
Session Key (IMSK), which depends on the TLS Pseudorandom Function (PRF) (also known
Key (IMSK), which depends on the TLS-PRF. When the j'th inner method as TLS-PRF). When the j'th inner method
generates an EMSK, we update that definition for TLS 1.3 as:</t> generates an EMSK, we update that definition for TLS 1.3 as:</t>
<artwork name="" type=""><![CDATA[
<figure><artwork><![CDATA[ IMSK[j] = TLS-Exporter("TEAPbindkey@ietf.org", secret, 32)
IMSK[j] = TLS-Exporter("TEAPbindkey@ietf.org", secret, 32)
]]></artwork> ]]></artwork>
</figure> <t>
<t>
The secret is the EMSK or MSK from the j'th inner method. When an The secret is the EMSK or MSK from the j'th inner method. When an
inner method does not provide an EMSK or MSK, IMSK[j] is 32 octets of inner method does not provide an EMSK or MSK, IMSK[j] is 32 octets of
zero.</t> zero.</t>
<t>
<t>
The other key derivations for TEAP are given here. All derivations The other key derivations for TEAP are given here. All derivations
not given here are the same as given above in the previous section. not given here are the same as given above in the previous section.
These derivations are also used for EAP-FAST, but using the EAP-FAST These derivations are also used for EAP-FAST, but using the EAP-FAST
Type.</t> Type.</t>
<t>
The derivation of the IMSKs, Inner Method
Compound Keys (IMCKs), and Compound Session Keys (CMKs) is given below.</t>
<artwork name="" type=""><![CDATA[
session_key_seed = TLS-Exporter("EXPORTER: teap session key seed",
Type, 40)
<t> S-IMCK[0] = session_key_seed
The derivation of the Inner Method Session Keys (IMSK), Inner Method For j = 1 to n-1 do
Compound Keys (IMCK), and Compound Session Keys (CMK) is given below.</t> IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
S-IMCK[j-1] || IMSK[j], 60)
<figure><artwork><![CDATA[ S-IMCK[j] = first 40 octets of IMCK[j]
session_key_seed = TLS-Exporter("EXPORTER: teap session key seed", CMK[j] = last 20 octets of IMCK[j]
Type, 40)
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
S-IMCK[j-1] || IMSK[j], 60)
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]
]]></artwork> ]]></artwork>
</figure> <t indent="3">
<t> Note: In these definitions, || denotes concatenation.</t>
In these definitions, || denotes concatenation.</t> <t>
In TLS 1.3, the derivation of IMCK[j] uses both a different label
<t> and a different order of concatenating fields than what was used by TEAP
In TLS 1.3, the derivation of IMCK[j] uses both a different label,
and a different order of concatenating fields, than was used by TEAP
with TLS 1.2. Similarly, the session_key_seed in TLS 1.3 uses the with TLS 1.2. Similarly, the session_key_seed in TLS 1.3 uses the
Type as the context, where in TLS 1.2 the context was a zero-length Type as the context. In TLS 1.2, the context was a zero-length
field.</t> field.</t>
<t>
<t>
The outer MSK and EMSK are then derived from the final ("n"th) inner The outer MSK and EMSK are then derived from the final ("n"th) inner
method, as follows:</t> method, as follows:</t>
<figure><artwork><![CDATA[ <artwork name="" type=""><![CDATA[
MSK = TLS-Exporter("EXPORTER: Session Key Generating Function", MSK = TLS-Exporter(
S-IMCK[n], 64) "EXPORTER: Session Key Generating Function",
S-IMCK[n], 64)
EMSK = TLS-Exporter("EXPORTER: Extended Session Key Generating Function", EMSK = TLS-Exporter(
S-IMCK[n], 64) "EXPORTER: Extended Session Key Generating Function",
S-IMCK[n], 64)
]]></artwork> ]]></artwork>
</figure> <t>
<t> The TEAP Compound Message Authentication Code (MAC) defined in <xref target="
The TEAP Compound MAC defined in <xref target="RFC7170"/> Section 5.3 remains RFC7170" sectionFormat="comma" section="5.3"/> remains the
the same, but the MAC for TLS 1.3 is
same, but the message authentication code (MAC) for TLS 1.3 is computed with the Hashed Message Authentication Code (HMAC) algorithm negotia
computed with the HMAC algorithm negotiated for HKDF in the key ted for the HMAC-based Key Derivation Function (HKDF) in the key
schedule, as per section 7.1 of RFC 8446. That is, the MAC used is schedule, as per <xref target="RFC8446" sectionFormat="comma" section="7.1"/>
the MAC derived from the TLS handshake.</t> . That is, the MAC used is
the MAC derived from the TLS handshake:</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Compound-MAC = MAC( CMK[n], BUFFER ) Compound-MAC = MAC( CMK[n], BUFFER )
]]></artwork> ]]></artwork>
</figure> <t>
<t> where we define CMK[n] as the CMK taken from the final ("n"th) inner
Where we define CMK[n] as the CMK taken from the final ("n"th) inner
method.</t> method.</t>
<t>
For TLS 1.3, the MAC is computed with
the HMAC algorithm negotiated for HKDF in the key schedule, as per <xref targ
et="RFC8446" sectionFormat="comma" section="7.1"/>.
<t> That is, the MAC used is the MAC derived
For TLS 1.3, the message authentication code (MAC) is computed with
the HMAC algorithm negotiated for HKDF in the key schedule, as per
section 7.1 of RFC 8446. That is, the MAC used is the MAC derived
from the TLS handshake.</t> from the TLS handshake.</t>
<t>
<t> The definition of BUFFER is unchanged from <xref target="RFC7170" sectionForm
The definition of BUFFER is unchanged from <xref target="RFC7170"/> Section 5 at="comma" section="5.3"/>.</t>
.3.</t> <section anchor="sect-2.2.1" numbered="true" toc="default">
<name>Client Certificates</name>
<section title="Client Certificates" anchor="sect-2.2.1"><t> <t>
The use of client certificates is still permitted when using TEAP The use of client certificates is still permitted when using TEAP
with TLS 1.3. However, if the client certificate is accepted, then with TLS 1.3. However, if the client certificate is accepted, then
the EAP peer MUST proceed with additional authentication of Phase 2, the EAP peer <bcp14>MUST</bcp14> proceed with additional authentication of Ph
as per <xref target="RFC7170"/> Section 7.6. If there is no Phase 2 data, th ase 2,
en the EAP server MUST reject the session.</t> as per <xref target="RFC7170" sectionFormat="comma" section="7.6"/>. If ther
e is no Phase 2 data, then the EAP server <bcp14>MUST</bcp14> reject the session
<t> .</t>
That is, while <xref target="RFC7170"/> Section 7.6 permits "Authentication o <t>
f the client via client certificate during phase 1, with no additional authentic While <xref target="RFC5281" sectionFormat="comma" section="7.6"/> permits "a
ation or information exchange required.", this practice is uthentication of the client via client certificate during phase 1, with no addit
ional authentication or information exchange required," this practice is
forbidden when TEAP is used with TLS 1.3. If there is a requirement forbidden when TEAP is used with TLS 1.3. If there is a requirement
to use client certificates with no inner tunnel methods, then EAP-TLS to use client certificates with no inner tunnel methods, then EAP-TLS
should be used instead of TEAP.</t> should be used instead of TEAP.</t>
<t>
<t> <xref target="RFC7170" sectionFormat="comma" section="7.4.1"/> suggests that
<xref target="RFC7170"/> Section 7.4.1 suggest that client certificates shoul client certificates should be
d be sent in Phase 2 of the TEAP exchange "since TLS client certificates are sent
sent in Phase 2 of the TEAP exchange, "since TLS client certificates are sent in the clear". While TLS 1.3 no longer sends client
in the clear". While TLS 1.3 no longer sends client
certificates in the clear, TEAP implementations need to distinguish certificates in the clear, TEAP implementations need to distinguish
identities for both User and Machine using the Identity-Type TLV identities for both User and Machine using the Identity-Type TLV
(with values 1 and 2, respectively). When a client certificate is (with values 1 and 2, respectively). When a client certificate is
sent outside of the TLS tunnel, it MUST include Identity-Type as an sent outside of the TLS tunnel, it <bcp14>MUST</bcp14> include Identity-Type
outer TLV, in order to signal the type of identity which that client as an
outer TLV in order to signal the type of identity which that client
certificate is for.</t> certificate is for.</t>
</section>
</section> </section>
<section anchor="sect-2.3" numbered="true" toc="default">
</section> <name>EAP-FAST</name>
<t>
<section title="EAP-FAST" anchor="sect-2.3"><t> For EAP-FAST, the session_key_seed is also part of the key_block as
For EAP-FAST, the session_key_seed is also part of the key_block, as defined in <xref target="RFC4851" sectionFormat="comma" section="5.1"/>.</t>
defined in <xref target="RFC4851"/> Section 5.1.</t> <t>
The definitions of S-IMCK[n], MSK, and EMSK are the same as given
<t>
The definition of S-IMCK[n], MSK, and EMSK are the same as given
above for TEAP. We reiterate that the EAP-FAST Type must be used above for TEAP. We reiterate that the EAP-FAST Type must be used
when deriving the session_key_seed, and not the TEAP Type.</t> when deriving the session_key_seed and not the TEAP Type.</t>
<t>
<t> Unlike <xref target="RFC4851" sectionFormat="comma" section="5.2"/>, the defi
Unlike <xref target="RFC4851"/> Section 5.2, the definition of IMCK[j] places nition of IMCK[j] places the
the reference to S-IMCK after the textual label and then concatenates the
reference to S-IMCK after the textual label, and the concatenates the IMSK instead of the MSK.</t>
IMSK instead of MSK.</t> <t>
EAP-FAST previously used a PAC that is functionally equivalent to
<t> session tickets provided by TLS 1.3, which contain a PSK along with other dat
EAP-FAST previously used a PAC, which is functionally equivalent to a. As such, the use of a PAC is deprecated
session tickets provided by TLS 1.3 which contain a pre-shared key for EAP-FAST in TLS 1.3. PAC provisioning <xref target="RFC5422" format="defa
(PSK) along with other data. As such, the use of a PAC is deprecated ult"/> is also no longer
for EAP-FAST in TLS 1.3. PAC provisioning <xref target="RFC5422"/> is also no
longer
part of EAP-FAST when TLS 1.3 is used.</t> part of EAP-FAST when TLS 1.3 is used.</t>
<t>
<t> The T-PRF given in <xref target="RFC4851" sectionFormat="comma" section="5.5"
The T-PRF given in <xref target="RFC4851"/> Section 5.5 is not used for TLS 1 /> is not used for TLS 1.3.
.3.
Instead, it is replaced with the TLS 1.3 TLS-Exporter function.</t> Instead, it is replaced with the TLS 1.3 TLS-Exporter function.</t>
<section anchor="sect-2.3.1" numbered="true" toc="default">
<section title="Client Certificates" anchor="sect-2.3.1"><t> <name>Client Certificates</name>
<t>
The use of client certificates is still permitted when using EAP-FAST The use of client certificates is still permitted when using EAP-FAST
with TLS 1.3. However, if the client certificate is accepted, then with TLS 1.3. However, if the client certificate is accepted, then
the EAP peer MUST proceed with additional authentication of Phase 2, the EAP peer <bcp14>MUST</bcp14> proceed with additional authentication of Ph
as per <xref target="RFC4851"/> Section 7.4.1. If there is no Phase 2 data, ase 2,
then as per <xref target="RFC4851" sectionFormat="comma" section="7.4.1"/>. If th
the EAP server MUST reject the session.</t> ere is no Phase 2 data, then
the EAP server <bcp14>MUST</bcp14> reject the session.</t>
<t> <t>
That is, while <xref target="RFC4851"/> implicitly permits the use of client While <xref target="RFC4851" format="default"/> implicitly permits the use of
client
certificates without proceeding to Phase 2, this practice is certificates without proceeding to Phase 2, this practice is
forbidden when EAP-FAST is used with TLS 1.3. If there is a forbidden when EAP-FAST is used with TLS 1.3. If there is a
requirement to use client certificates with no inner tunnel methods, requirement to use client certificates with no inner tunnel methods,
then EAP-TLS should be used instead of EAP-FAST.</t> then EAP-TLS should be used instead of EAP-FAST.</t>
</section>
</section> </section>
<section anchor="sect-2.4" numbered="true" toc="default">
</section> <name>EAP-TTLS</name>
<t>
<section title="EAP-TTLS" anchor="sect-2.4"><t> <xref target="RFC5281" sectionFormat="comma" section="11.1"/> defines an impl
<xref target="RFC5281"/> Section 11.1 defines an implicit challenge when the icit challenge when the inner
inner methods of the Challenge Handshake Authentication Protocol (CHAP) <xref targe
methods of CHAP <xref target="RFC1994"/>, MS-CHAP <xref target="RFC2433"/>, o t="RFC1994" format="default"/>, Microsoft CHAP (MS-CHAP) <xref target="RFC2433"
r MS-CHAPv2 <xref target="RFC2759"/> format="default"/>, or MS-CHAPv2 <xref target="RFC2759" format="default"/>
are used. The derivation for TLS 1.3 is instead given as</t> are used. The derivation for TLS 1.3 is instead given as:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n) EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n)
]]></artwork> ]]></artwork>
</figure> <t>
<t> There is no "context_value" (<xref target="RFC8446" sectionFormat="comma" sec
There is no "context_value" (<xref target="RFC8446"/> Section 7.5) passed to tion="7.5"/>) passed to the
the
TLS-Exporter function. The value "n" given here is the length of the TLS-Exporter function. The value "n" given here is the length of the
data required, which <xref target="RFC5281"/> requires it to be 17 octets for data required; <xref target="RFC5281" format="default"/> requires it to be 17
CHAP octets for CHAP
(Section 11.2.2) and MS-CHAPv2 (Section 11.2.4), and to be 9 octets (<xref target="RFC5281" sectionFormat="comma" section="11.2.2"/>) and MS-CHAP
for MS-CHAP (Section 11.2.3).</t> v2 (<xref target="RFC5281" sectionFormat="comma" section="11.2.4"/>), and 9 octe
ts
<t> for MS-CHAP (<xref target="RFC5281" sectionFormat="comma" section="11.2.3"/>)
When PAP, CHAP, or MS-CHAPv1 are used as inner authentication .</t>
<t>
When the Password Authentication Protocol (PAP), CHAP, or MS-CHAPv1 are used
as inner authentication
methods, there is no opportunity for the EAP server to send a methods, there is no opportunity for the EAP server to send a
protected success indication, as is done in <xref target="RFC9190"/> <xref ta rget="sect-2.5"/>. protected success indication, as is done in <xref target="RFC9190" sectionFor mat="comma" section="2.5"/>.
Instead, when TLS session tickets are disabled, the response from the Instead, when TLS session tickets are disabled, the response from the
EAP server MUST be either EAP-Success or EAP-Failure. These EAP server <bcp14>MUST</bcp14> be either EAP-Success or EAP-Failure. These
responses are unprotected, and can be forged by a skilled attacker.</t> responses are unprotected and can be forged by a skilled attacker.</t>
<t>
<t>
Where TLS session tickets are enabled, the response from the EAP Where TLS session tickets are enabled, the response from the EAP
server may also continue TLS negotiation with a TLS NewSessionTicket server may also continue TLS negotiation with a TLS NewSessionTicket
message. Since this message is protected by TLS, it can serve as the message. Since this message is protected by TLS, it can serve as the
protected success indication.</t> protected success indication.</t>
<t>
<t> Therefore, it is <bcp14>RECOMMENDED</bcp14> that EAP servers always send a TL
It is therefore RECOMMENDED that EAP servers always send a TLS S
NewSessionTicket message, even if resumption is not configured. When NewSessionTicket message, even if resumption is not configured. When
the EAP peer attempts to use the ticket, the EAP server can instead the EAP peer attempts to use the ticket, the EAP server can instead
request a full authentication. As noted earlier, implementations request a full authentication. As noted earlier, implementations
SHOULD NOT send TLS NewSessionTicket messages until the "inner tunnel" authen tication has completed, in order to take full advantage <bcp14>SHOULD NOT</bcp14> send TLS NewSessionTicket messages until the "inner tunnel" authentication has completed in order to take full advantage
of the message as a protected success indication.</t> of the message as a protected success indication.</t>
<t>
<t>
When resumption is not used, the TLS NewSessionTicket message is not When resumption is not used, the TLS NewSessionTicket message is not
available, and some authentication methods will not have a protected available and some authentication methods will not have a protected
success indication. While we would like to always have a protected success indication. While we would like to always have a protected
success indication, limitations of the underlying protocols, success indication, limitations of the underlying protocols,
implementations, and deployment requirements make that impossible.</t> implementations, and deployment requirements make that impossible.</t>
<t>
<t> EAP peers <bcp14>MUST</bcp14> continue running their EAP state machine until
EAP peers MUST continue running their EAP state machine until they they
receive either an EAP-Success, or an EAP-Failure. Receiving a TLS receive either an EAP-Success or an EAP-Failure. Receiving a TLS
NewSessionTicket message in response to inner method PAP, CHAP, or NewSessionTicket message in response to inner method PAP, CHAP, or
MS-CHAP authentication is normal, and MUST NOT be treated as a MS-CHAP authentication is normal and <bcp14>MUST NOT</bcp14> be treated as a
failure.</t> failure.</t>
<section anchor="sect-2.4.1" numbered="true" toc="default">
<section title="Client Certificates" anchor="sect-2.4.1"><t> <name>Client Certificates</name>
<xref target="RFC5281"/> Section 7.6 permits "Authentication of the client vi <t>
a client certificate during phase 1, with no additional authentication or inform <xref target="RFC5281" sectionFormat="comma" section="7.6"/> permits "authent
ation exchange required.". This practice is forbidden when ication of the client via client certificate during phase 1, with no additional
authentication or information exchange required." This practice is forbidden whe
n
EAP-TTLS is used with TLS 1.3. If there is a requirement to use EAP-TTLS is used with TLS 1.3. If there is a requirement to use
client certificates with no inner tunnel methods, then EAP-TLS should client certificates with no inner tunnel methods, then EAP-TLS should
be used instead of EAP-TTLS.</t> be used instead of EAP-TTLS.</t>
<t>
<t>
The use of client certificates is still permitted when using EAP-TTLS The use of client certificates is still permitted when using EAP-TTLS
with TLS 1.3. However, if the client certificate is accepted, then with TLS 1.3. However, if the client certificate is accepted, then
the EAP peer MUST proceed with additional authentication of Phase 2, the EAP peer <bcp14>MUST</bcp14> proceed with additional authentication of Ph
as per <xref target="RFC5281"/> Section 7.2 and following. If there is no Ph ase 2,
ase 2 as per <xref target="RFC5281" sectionFormat="comma" section="7.2"/>. If ther
data, then the EAP server MUST reject the session.</t> e is no Phase 2
data, then the EAP server <bcp14>MUST</bcp14> reject the session.</t>
</section> </section>
</section>
</section> <section anchor="sect-2.5" numbered="true" toc="default">
<name>PEAP</name>
<section title="PEAP" anchor="sect-2.5"><t> <t>
When PEAP uses crypto binding, it uses a different key calculation When PEAP uses crypto binding, it uses a different key calculation
defined in <xref target="PEAP-MPPE"/> which consumes inner EAP method keying defined in <xref target="PEAP-MPPE" format="default"/> that consumes inner EA
material. The pseudo-random function (PRF+) used in <xref target="PEAP-MPPE" P method keying
/> is material. The PRF+ function used in <xref target="PEAP-MPPE" format="default"
not taken from the TLS exporter, but is instead calculated via a /> is
different method which is given in <xref target="PEAP-PRF"/>. That derivatio not taken from the TLS exporter but is instead calculated via a
n different method that is given in <xref target="PEAP-PRF" format="default"/>.
That derivation
remains unchanged in this specification.</t> remains unchanged in this specification.</t>
<t>
<t>
Note that the above derivation uses SHA-1, which may be formally Note that the above derivation uses SHA-1, which may be formally
deprecated in the near future.</t> deprecated in the near future.</t>
<t>
However, the PRF+ calculation uses a PEAP
Tunnel Key (TK), which is defined in <xref target="PEAP-TK" format="default"/
> as:
<t> </t>
However, the pseudo-random function (PRF+) calculation uses a PEAP <blockquote>... the TK is the first 60 octets of the Key_Material, as
Tunnel Key which is defined in <xref target="PEAP-PRF"/> as: specified in <xref target="RFC5216" format="default"/>: TLS-PRF-128 (maste
r secret, "client EAP encryption", client.random || server.random).</blockquote>
<list> <t>
<t>... the TK is the first 60 octets of the Key_Material, as We note that the text in <xref target="PEAP-PRF" format="default"/> does not
specified in <xref target="RFC5216"/>: TLS-PRF-128 (master secret, "client define Key_Material.
EAP encryption", client.random || server.random).</t> Instead, it defines TK as the first octets of Key_Material and gives
</list></t> a definition of Key_Material that is appropriate for TLS versions
<t>
We note that the text in <xref target="PEAP-PRF"/> does not define Key_Materi
al.
Instead, it defines TK as the first octets of Key_Material, and gives
a definition of Key_Material which is appropriate for TLS versions
before TLS 1.3.</t> before TLS 1.3.</t>
<t>
<t>
For TLS 1.3, the TK should be derived from the Key_Material defined For TLS 1.3, the TK should be derived from the Key_Material defined
here in <xref target="sect-2.1"/>, instead of using the TLS-PRF-128 derivatio here in <xref target="sect-2.1" format="default"/> instead of using the TLS-P
n RF-128 derivation
given in <xref target="PEAP-PRF"/>. The method defined in <xref target="PEAP given in <xref target="PEAP-PRF" format="default"/>. The method defined in <
-TK"/> MUST NOT be xref target="PEAP-TK" format="default"/> <bcp14>MUST NOT</bcp14> be
used.</t> used.</t>
<section anchor="sect-2.5.1" numbered="true" toc="default">
<section title="Client Certificates" anchor="sect-2.5.1"><t> <name>Client Certificates</name>
As with EAP-TTLS, <xref target="I-D.josefsson-pppext-eap-tls-eap"/> permits t <t>
he use of client certificates in As with EAP-TTLS, <xref target="I-D.josefsson-pppext-eap-tls-eap" format="def
ault"/> permits the use of client certificates in
addition to inner tunnel methods. The practice of using client addition to inner tunnel methods. The practice of using client
certificates with no "inner method" is forbidden when PEAP is used certificates with no "inner method" is forbidden when PEAP is used
with TLS 1.3. If there is a requirement to use client certificates with TLS 1.3. If there is a requirement to use client certificates
with no inner tunnel methods, then EAP-TLS should be used instead of with no inner tunnel methods, then EAP-TLS should be used instead of
PEAP.</t> PEAP.</t>
<t>
<t>
The use of client certificates is still permitted when using PEAP The use of client certificates is still permitted when using PEAP
with TLS 1.3. However, if the client certificate is accepted, then with TLS 1.3. However, if the client certificate is accepted, then
the EAP peer MUST proceed with additional authentication of the inner the EAP peer <bcp14>MUST</bcp14> proceed with additional authentication of th e inner
tunnel. If there is no inner tunnel authentication data, then the tunnel. If there is no inner tunnel authentication data, then the
EAP server MUST reject the session.</t> EAP server <bcp14>MUST</bcp14> reject the session.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-3" numbered="true" toc="default">
<name>Application Data</name>
</section> <t>
<section title="Application Data" anchor="sect-3"><t>
Unlike previous TLS versions, TLS 1.3 can continue negotiation after Unlike previous TLS versions, TLS 1.3 can continue negotiation after
the initial TLS handshake has been completed, which TLS 1.3 calls the the initial TLS handshake has been completed; TLS 1.3 calls this the
"CONNECTED" state. Some implementations use receipt of a Finished "CONNECTED" state. Some implementations use receipt of a Finished
message as an indication that TLS negotiation has completed, and that message as an indication that TLS negotiation has completed and that
an "inner tunnel" session can now be negotiated. This assumption is an "inner tunnel" session can now be negotiated. This assumption is
not always correct with TLS 1.3.</t> not always correct with TLS 1.3.</t>
<t>
<t>
Earlier TLS versions did not send application data along with the Earlier TLS versions did not send application data along with the
Finished message. It was then possible for implementations to assume Finished message. It was then possible for implementations to assume
that a receipt of a Finished message also meant that there was no that a receipt of a Finished message also meant that there was no
application data available, and that another round trip was required.</t> application data available and that another round trip was required.</t>
<t>
<t>
This assumption is not true with TLS 1.3, and applications relying on This assumption is not true with TLS 1.3, and applications relying on
that behavior will not operate correctly with TLS 1.3.</t> that behavior will not operate correctly with TLS 1.3.</t>
<t>
<t> As a result, implementations <bcp14>MUST</bcp14> check for application data o
As a result, implementations MUST check for application data once the nce the
TLS session has been established. This check MUST be performed TLS session has been established. This check <bcp14>MUST</bcp14> be performe
d
before proceeding with another round trip of TLS negotiation. TLS- before proceeding with another round trip of TLS negotiation. TLS-
based EAP methods such as EAP-TTLS, PEAP, and EAP-FAST each have based EAP methods, such as EAP-TTLS, PEAP, and EAP-FAST, each have
method-specific application data which MUST be processed according to method-specific application data that <bcp14>MUST</bcp14> be processed accord
the EAP type.</t> ing to
the EAP Type.</t>
<t> <t>
TLS 1.3 in <xref target="RFC8446"/> Section 4.6.1 also permits NewSessionTick TLS 1.3 in <xref target="RFC8446" sectionFormat="comma" section="4.6.1"/> als
et o permits NewSessionTicket
messages to be sent after the server has received the client Finished messages to be sent after the server has received the client Finished
message, which is a change from earlier TLS versions. This change message, which is a change from earlier TLS versions. This change
can cause implementations to fail in a number of different ways, due can cause implementations to fail in a number of different ways due
to a reliance on implicit behavior seen in earlier TLS versions.</t> to a reliance on implicit behavior seen in earlier TLS versions.</t>
<t>
<t> In order to correct this failure, we require that implementations
In order to correct this failure, we require that if the underlying <bcp14>MUST NOT</bcp14> send or expect to receive application data in the TLS
TLS connection is still performing negotiation, then implementations session if the underlying
MUST NOT send, or expect to receive application data in the TLS TLS connection is still performing negotiation. Implementations <bcp14>MUST<
session. Implementations MUST delay processing of application data /bcp14> delay processing of application data
until such time as the TLS negotiation has finished. If the TLS until such time as the TLS negotiation has finished. If the TLS
negotiation is successful, then the application data can be examined. negotiation is successful, then the application data can be examined.
If the TLS negotiation is unsuccessful, then the application data is If the TLS negotiation is unsuccessful, then the application data is
untrusted, and therefore MUST be discarded without being examined.</t> untrusted; therefore, it <bcp14>MUST</bcp14> be discarded without being exami
ned.</t>
<t> <t>
The default for many TLS library implementations is to send a The default for many TLS library implementations is to send a
NewSessionTicket message immediately after, or along with, the NewSessionTicket message immediately after or along with the
Finished message. This ticket could be used for resumption, even if Finished message. This ticket could be used for resumption, even if
the "inner tunnel" authentication has not been completed. If the the "inner tunnel" authentication has not been completed. If the
ticket could be used, then it could allow a malicious EAP peer to ticket could be used, then it could allow a malicious EAP peer to
completely bypass the "inner tunnel" authentication.</t> completely bypass the "inner tunnel" authentication.</t>
<t>
<t> Therefore, the EAP server <bcp14>MUST NOT</bcp14> permit any session ticket t
Therefore, the EAP server MUST NOT permit any session ticket to o
successfully resume authentication, unless the inner tunnel successfully resume authentication unless the inner tunnel
authentication has completed successfully. The alternative would authentication has completed successfully. The alternative would
allow an attacker to bypass authentication by obtaining a session allow an attacker to bypass authentication by obtaining a session
ticket, and then immediately closing the current session, and ticket, immediately closing the current session, and
"resuming" using the session ticket.</t> "resuming" using the session ticket.</t>
<t>
<t> To protect against that attack, implementations <bcp14>SHOULD NOT</bcp14> sen
To protect against that attack, implementations SHOULD NOT send d
NewSessionTicket messages until the "inner tunnel" authentication has NewSessionTicket messages until the "inner tunnel" authentication has
completed. There is no reason to send session tickets which will completed. There is no reason to send session tickets that will
later be invalidated or ignored. However, we recognize that this later be invalidated or ignored. However, we recognize that this
suggestion may not always be possible to implement with some suggestion may not always be possible to implement with some
available TLS libraries. As such, EAP servers MUST take care to available TLS libraries. As such, EAP servers <bcp14>MUST</bcp14> take care
either invalidate or discard session tickets which are associated to
either invalidate or discard session tickets that are associated
with sessions that terminate in EAP Failure.</t> with sessions that terminate in EAP Failure.</t>
<t>
<t> The NewSessionTicket message <bcp14>SHOULD</bcp14> also be sent along with ot
The NewSessionTicket message SHOULD also be sent along with other her
application data, if possible. Sending that message alone prolongs application data, if possible. Sending that message alone prolongs
the packet exchange to no benefit. In addition to prolonging the the packet exchange to no benefit. In addition to prolonging the
packet exchange, using a separate NewSessionTicket message can lead packet exchange, using a separate NewSessionTicket message can lead
to non-interoperable implementations.</t> to non-interoperable implementations.</t>
<t>
<t> <xref target="RFC9190" sectionFormat="comma" section="2.5"/> requires a prote
<xref target="RFC9190"/> <xref target="sect-2.5"/> requires a protected resul cted result indication, which indicates that TLS negotiation has finished. Meth
t indication which ods that use
indicates that TLS negotiation has finished. Methods which use "inner tunnel" methods <bcp14>MUST</bcp14> instead begin their "inner tunnel"
"inner tunnel" methods MUST instead begin their "inner tunnel"
negotiation by sending Type-specific application data.</t> negotiation by sending Type-specific application data.</t>
<section anchor="sect-3.1" numbered="true" toc="default">
<section title="Identities" anchor="sect-3.1"><t> <name>Identities</name>
For EAP-TLS, <xref target="RFC9190"/> Sections 2.1.3 and 2.1.7 recommend the <t>
use of For EAP-TLS, Sections <xref target="RFC9190" sectionFormat="bare" section="2.
anonymous Network Access Identifiers (NAIs) <xref target="RFC7542"/> in the E 1.3"/> and <xref target="RFC9190" sectionFormat="bare" section="2.1.7"/> of <xre
AP f target="RFC9190"/> recommend the use of
anonymous Network Access Identifiers (NAIs) <xref target="RFC7542" format="de
fault"/> in the EAP
Response/Identity packet. However, as EAP-TLS does not send Response/Identity packet. However, as EAP-TLS does not send
application data inside of the TLS tunnel, that specification does application data inside of the TLS tunnel, that specification does
not address the subject of "inner" identities in tunneled EAP not address the subject of "inner" identities in tunneled EAP
methods. This subject must, however, be addressed for the tunneled methods. However, this subject must be addressed for the tunneled
methods.</t> methods.</t>
<t>
<t> Using an anonymous NAI for the outer identity as per <xref target="RFC7542" s
Using an anonymous NAI for the outer identity as per <xref target="RFC7542"/> ectionFormat="comma" section="2.4"/> has a few benefits. An NAI allows the EAP
<xref target="sect-2.4"/> has a few benefits. An NAI allows the EAP session session to be
to be routed in a AAA framework as described in <xref target="RFC7542" sectionForma
routed in an AAA framework as described in <xref target="RFC7542"/> <xref tar t="comma" section="3"/>.
get="sect-3"/>.
Using an anonymous realm also ensures that user identifiers are kept Using an anonymous realm also ensures that user identifiers are kept
private.</t> private.</t>
<t>
<t>
As for the inner identity, we define it generically as the As for the inner identity, we define it generically as the
identification information carried inside of the TLS tunnel. For identification information carried inside of the TLS tunnel. For
PEAP, that identity may be an EAP Response/Identity. For EAP-TTLS, PEAP, that identity may be an EAP Response/Identity. For EAP-TTLS,
it may be the User-Name attribute. Vendor-specific EAP methods which it may be the User-Name attribute. Vendor-specific EAP methods that
use TLS will generally also have an inner identity. This identity is use TLS will generally also have an inner identity.
carried inside of the TLS tunnel, and is therefore both routed to the This identity is
correct destination by the outer identity, and kept private by the carried inside of the TLS tunnel and is therefore both routed to the
correct destination by the outer identity and kept private by the
use of TLS.</t> use of TLS.</t>
<t>
<t>
In other words, we can view the outer TLS layer of tunneled EAP In other words, we can view the outer TLS layer of tunneled EAP
methods as a secure transport layer which is responsible for getting methods as a secure transport layer that is responsible for getting
the actual (inner) authentication credentials securely from the EAP the actual (inner) authentication credentials securely from the EAP
peer to the EAP server. The EAP server then uses the inner identity peer to the EAP server. The EAP server then uses the inner identity
and inner authentication data to identify and authenticate a and inner authentication data to identify and authenticate a
particular user.</t> particular user.</t>
<t>
<t>
As the authentication data is routed to the correct destination, As the authentication data is routed to the correct destination,
there is little reason for the inner identity to also contain a there is little reason for the inner identity to also contain a
realm. We therefore have a few recommendations on the inner and realm. Therefore, we have a few recommendations on the inner and
outer identities, along with their relationship to each other.</t> outer identities, along with their relationship to each other.</t>
<t>
<t> The outer identity <bcp14>SHOULD</bcp14> use an anonymous NAI realm that allo
The outer identity SHOULD use an anonymous NAI realm, which allows ws
for both user privacy, and for the EAP session to be routed in an AAA for both user privacy and for the EAP session to be routed in a AAA
framework as described in <xref target="RFC7542"/> <xref target="sect-3"/>. framework as described in <xref target="RFC7542" sectionFormat="comma" sectio
Where NAI realms are n="3"/>. Where NAI realms are
not used, packets will not be routable outside of the local not used, packets will not be routable outside of the local
organization.</t> organization.</t>
<t>
<t> The inner identity <bcp14>MUST NOT</bcp14> use an anonymous NAI realm. If an
The inner identity MUST NOT use an anonymous NAI realm. If anonymous onymous
network access is desired, EAP peers MUST use EAP-TLS without peer network access is desired, EAP peers <bcp14>MUST</bcp14> use EAP-TLS without
authentication, as per <xref target="RFC9190"/> section 2.1.5. EAP servers M peer
UST authentication, as per <xref target="RFC9190" sectionFormat="comma" section="
2.1.5"/>. EAP servers <bcp14>MUST</bcp14>
cause authentication to fail if an EAP peer uses an anonymous "inner" cause authentication to fail if an EAP peer uses an anonymous "inner"
identity for any TLS-based EAP method.</t> identity for any TLS-based EAP method.</t>
<t>
<t> Implementations <bcp14>SHOULD NOT</bcp14> use inner identities that contain a
Implementations SHOULD NOT use inner identities which contain an NAI n NAI
realm. Many organizations typically use only one realm for all user realm. Many organizations typically use only one realm for all user
accounts.</t> accounts.</t>
<t>
<t>
However, there are situations where it is useful for an inner However, there are situations where it is useful for an inner
identity to contain a realm. For example, an organization may have identity to contain a realm. For example, an organization may have
multiple independent sub-organizations, each with a different and multiple independent sub-organizations, each with a different and
unique realm. These realms may be independent of one another, or the unique realm. These realms may be independent of one another, or the
realms may be a subdomain (or subdomains) of the public outer realm.</t> realms may be a subdomain (or subdomains) of the public outer realm.</t>
<t>
<t>
In that case, an organization can configure one public "routing" In that case, an organization can configure one public "routing"
realm, and multiple separate "inner" realms. This separation of realm and multiple separate "inner" realms. This separation of
realms also allows an organization to split users into logical groups realms also allows an organization to split users into logical groups
by realm, where the "user" portion of the NAI may otherwise conflict. by realm, where the "user" portion of the NAI may otherwise conflict.
For example, "user@example.com" and "user@example.org" are different For example, "user@example.com" and "user@example.org" are different
NAIs which can both be used as inner identities.</t> NAIs that can both be used as inner identities.</t>
<t>
<t> Using only one public realm both keeps internal information private
Using only one public realm both keeps internal information private, and simplifies realm management for external entities by
and also simplifies realm management for external entities by minimizing the number of realms that have to be tracked by them.</t>
minimizing the number of realms which have to be tracked by them.</t> <t>
<t>
In most situations, routing identifiers should be associated with the In most situations, routing identifiers should be associated with the
authentication data that they are routing. For example, if a user authentication data that they are routing. For example, if a user
has an inner identity of "user@example.com", then it generally makes has an inner identity of "user@example.com", then it generally makes
little sense to have an outer identity of "@example.org". The little sense to have an outer identity of "@example.org". The
authentication request would then be routed to the "example.org" authentication request would then be routed to the "example.org"
domain, which may have no idea what to do with the credentials for domain, which may have no idea what to do with the credentials for
"user@example.com". At best, the authentication request would be "user@example.com". At best, the authentication request would be
discarded. At worst, the "example.org" domain could harvest user discarded. At worst, the "example.org" domain could harvest user
credentials for later use in attacks on "example.com".</t> credentials for later use in attacks on "example.com".</t>
<t>
<t> When an EAP server receives an inner identity for a realm which it
Where an EAP server receives an inner identity for a realm which it is not authoritative, it <bcp14>MUST</bcp14> reject the authentication.
is not authoritative, it MUST reject the authentication. There is no There is no
reason for one organization to authentication users from a different reason for one organization to authenticate users from a different
(and independent) organization.</t> (and independent) organization.</t>
<t>
<t>
In addition, associating inner/outer identities from different In addition, associating inner/outer identities from different
organizations in the same EAP authentication session means that organizations in the same EAP authentication session means that
otherwise unrelated realms are tied together, which can make networks otherwise unrelated realms are tied together, which can make networks
more fragile.</t> more fragile.</t>
<t>
<t> For example, an organization that uses a "hosted" AAA provider may
For example, an organization which uses a "hosted" AAA provider may
choose to use the realm of the AAA provider as the outer identity for choose to use the realm of the AAA provider as the outer identity for
user authentication. The inner identity can then be fully-qualified: user authentication. The inner identity can then be fully qualified:
user name plus realm of the organization. This practice may result username plus realm of the organization. This practice may result
in successful authentications, but it has practical difficulties.</t> in successful authentications, but it has practical difficulties.</t>
<t>
<t> Additionally, an organization may host their own AAA servers but use
For example, an organization may host their own AAA servers, but use
a "cloud" identity provider to hold user accounts. In that a "cloud" identity provider to hold user accounts. In that
situation, the organizations could see try to use their own realm as situation, the organizations could try to use their own realm as
the outer (routing) identity, then use an identity from the "cloud" the outer (routing) identity and then use an identity from the "cloud"
provider as the inner identity.</t> provider as the inner identity.</t>
<t>
<t> This practice is <bcp14>NOT RECOMMENDED</bcp14>. User accounts for an organi
This practice is NOT RECOMMENDED. User accounts for an organization zation
should be qualified as belonging to that organization, and not to an should be qualified as belonging to that organization and not to an
unrelated third party. There is no reason to tie the configuration unrelated third party.
of user systems to public realm routing, that configuration more There is no reason to tie the configuration
of user systems to public realm routing; that configuration more
properly belongs in the network.</t> properly belongs in the network.</t>
<t>
<t>
Both of these practices mean that changing "cloud" providers is Both of these practices mean that changing "cloud" providers is
difficult. When such a change happens, each individual EAP peer must difficult. When such a change happens, each individual EAP peer must
be updated with a different outer identity which points to the new be updated with a different outer identity that points to the new
"cloud" provider. This process can be expensive, and some EAP peers "cloud" provider. This process can be expensive, and some EAP peers
may not be online when this changeover happens. The result could be may not be online when this changeover happens. The result could be
devices or users who are unable to obtain network access, even if all devices or users who are unable to obtain network access, even if all
relevant network systems are online and functional.</t> relevant network systems are online and functional.</t>
<t>
<t> Further, standards such as <xref target="RFC7585" format="default"/> allow fo
Further, standards such as <xref target="RFC7585"/> allow for dynamic discove r dynamic discovery of
ry of home servers for authentication. This specification has been widely
home servers for authentication. That specification has been widely deployed and means that there is minimal cost to routing
deployed, and means that there is minimal cost to routing
authentication to a particular domain. The authentication can also authentication to a particular domain. The authentication can also
be routed to a particular identity provider, and changed at will, be routed to a particular identity provider and changed at will
with no loss of functionality. That specification is also scalable, with no loss of functionality. That specification is also scalable
in that it does not require changes to many systems when a domain since it does not require changes to many systems when a domain
updates its configuration. Instead, only one thing has to change: updates its configuration. Instead, only one thing has to change:
the configuration of that domain. Everything else is discovered the configuration of that domain. Everything else is discovered
dynamically.</t> dynamically.</t>
<t>
<t>
That is, changing the configuration for one domain is significantly That is, changing the configuration for one domain is significantly
simpler and more scalable than changing the configuration for simpler and more scalable than changing the configuration for
potentially millions of end-user devices.</t> potentially millions of end-user devices.</t>
<t>
<t> We recognize that there may be existing use cases where the inner and
We recognize that there may be existing use-cases where the inner and
outer identities use different realms. As such, we cannot forbid outer identities use different realms. As such, we cannot forbid
that practice. We hope that the discussion above shows not only why that practice. We hope that the discussion above shows not only why
such practices are problematic, but also that it shows how such practices are problematic, but how
alternative methods are more flexible, more scalable, and are easier alternative methods are more flexible, more scalable, and are easier
to manage.</t> to manage.</t>
</section>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
</section> <name>Resumption</name>
<t>
<section title="Resumption" anchor="sect-4"><t> <xref target="RFC9190" sectionFormat="comma" section="2.1.3"/> defines the pr
<xref target="RFC9190"/> Section 2.1.3 defines the process for resumption. T ocess for resumption. This
his process is the same for all TLS-based EAP Types. The only practical
process is the same for all TLS-based EAP types. The only practical difference is that the value of the Type field is different. The
difference is that the value of the Type field is different. The requirements on identities, use of TLS cipher suites, resumption, etc. remain
requirements on identities, etc. remain unchanged from that document.</t> unchanged from that document.</t>
<t>
<t> Note that if resumption is performed, then the EAP server <bcp14>MUST</bcp14>
Note that if resumption is performed, then the EAP server MUST send send
the protected success result indication (one octet of 0x00) inside the protected success result indication (one octet of 0x00) inside
the TLS tunnel as per <xref target="RFC9190"/>. The EAP peer MUST in turn ch the TLS tunnel, as per <xref target="RFC9190" format="default"/>.
eck for
the existence the protected success result indication (one octet of
0x00), and cause authentication to fail if that octet is not
received. If either peer or server instead initiates an inner tunnel
method, then that method MUST be followed, and inner authentication
MUST NOT be skipped.</t>
<t> The EAP peer <bcp14>MUST</bcp14> in turn check for
the existence of the protected success result indication (one octet of
0x00) and cause authentication to fail if that octet is not
received. If either the peer or the server initiates an inner tunnel
method instead, then that method <bcp14>MUST</bcp14> be followed, and inner a
uthentication
<bcp14>MUST NOT</bcp14> be skipped.</t>
<t>
All TLS-based EAP methods support resumption, as it is a property of All TLS-based EAP methods support resumption, as it is a property of
the underlying TLS protocol. All EAP servers and peers MUST support the underlying TLS protocol. All EAP servers and peers <bcp14>MUST</bcp14> s upport
resumption for all TLS-based EAP methods. We note that EAP servers resumption for all TLS-based EAP methods. We note that EAP servers
and peers can still choose to not resume any particular session. For and peers can still choose to not resume any particular session. For
example, EAP servers may forbid resumption for administrative, or example, EAP servers may forbid resumption for administrative or
other policy reasons.</t> other policy reasons.</t>
<t>
<t> It is <bcp14>RECOMMENDED</bcp14> that EAP servers and peers enable resumption
It is RECOMMENDED that EAP servers and peers enable resumption, and and
use it where possible. The use of resumption decreases the number of use it where possible. The use of resumption decreases the number of
round trips used for authentication. This decrease leads to lower round trips used for authentication. This decrease leads to lower
latency for authentications, and less load on the EAP server. latency for authentications and less load on the EAP server.
Resumption can also lower load on external systems, such as databases Resumption can also lower load on external systems, such as databases
which contain user credentials.</t> that contain user credentials.</t>
<t>
<t>
As the packet flows for resumption are essentially identical across As the packet flows for resumption are essentially identical across
all TLS-based EAP types, it is technically possible to authenticate all TLS-based EAP Types, it is technically possible to authenticate
using EAP-TLS (Type 13), and then perform resumption using another using EAP-TLS (Type 13) and then perform resumption using another
EAP type, such as with EAP-TTLS (Type 21). However, there is no EAP Type, such as with EAP-TTLS (Type 21). However, there is no
practical benefit to doing so. It is also not clear what this practical benefit to doing so. It is also not clear what this
behavior would mean, or what (if any) security issues there may be behavior would mean or what (if any) security issues there may be
with it. As a result, this behavior is forbidden.</t> with it. As a result, this behavior is forbidden.</t>
<t>
<t> EAP servers therefore <bcp14>MUST NOT</bcp14> resume sessions across differen
EAP servers therefore MUST NOT resume sessions across different EAP t EAP
Types, and EAP servers MUST reject resumptions in which the EAP Type Types, and EAP servers <bcp14>MUST</bcp14> reject resumptions in which the EA
P Type
value is different from the original authentication.</t> value is different from the original authentication.</t>
</section>
</section> <section anchor="sect-7" numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Implementation Status" anchor="sect-5"><t> <t>
RFC Editor: Please remove this section before publication.</t> <xref target="RFC9190" sectionFormat="comma" section="5"/> is included here b
y reference.</t>
<t> <t>
EAP-TTLS and PEAP are implemented and tested to be interoperable with
wpa_supplicant 2.10 and Windows 11 as EAP peers, and FreeRADIUS
3.0.26 and Radiator as RADIUS / EAP servers.</t>
<t>
The wpa_supplicant implementation requires that a configuration flag
be set "tls_disable_tlsv1_3=0", and describes the flag as "enable TLSv1.3 (ex
perimental - disabled by default)". However,
interoperability testing shows that PEAP and EAP-TTLS both work with
Radiator and FreeRADIUS.</t>
<t>
Implementors have demonstrated significant interest in getting PEAP
and EAP-TTLS working for TLS 1.3, but less interest in EAP-FAST and
TEAP. As such, there is no implementation experience with EAP-FAST
or TEAP. However, we believe that the definitions described above
are correct, and are workable.</t>
</section>
<section title="Security Considerations" anchor="sect-6"><t>
<xref target="RFC9190"/> <xref target="sect-5"/> is included here by referenc
e.</t>
<t>
Updating the above EAP methods to use TLS 1.3 is of high importance Updating the above EAP methods to use TLS 1.3 is of high importance
for the Internet Community. Using the most recent security protocols for the Internet community. Using the most recent security protocols
can significantly improve security and privacy of a network.</t> can significantly improve security and privacy of a network.</t>
<t>
<t> For PEAP, some derivations use HMAC-SHA1 <xref target="PEAP-MPPE" format="def
For PEAP, some derivations use HMAC-SHA1 <xref target="PEAP-MPPE"/>. In the ault"/>. In the
interests of interoperability and minimal changes, we do not change interests of interoperability and minimal changes, we do not change
that derivation, as there are no known security issues with HMAC- that derivation, as there are no known security issues with HMAC-
SHA1. Further, the data derived from the HMAC-SHA1 calculations is SHA1. Further, the data derived from the HMAC-SHA1 calculations is
exchanged inside of the TLS tunnel, and is visible only to users who exchanged inside of the TLS tunnel and is visible only to users who
have already successfully authenticated. As such, the security risks have already successfully authenticated. As such, the security risks
are minimal.</t> are minimal.</t>
<section anchor="sect-7.1" numbered="true" toc="default">
<section title="Handling of TLS NewSessionTicket Messages" anchor="sect-6 <name>Handling of TLS NewSessionTicket Messages</name>
.1"><t> <t>
In some cases, client certificates are not used for TLS-based EAP In some cases, client certificates are not used for TLS-based EAP
methods. In those cases, the user is authenticated only after methods. In those cases, the user is authenticated only after
successful completion of the inner tunnel authentication. However, successful completion of the inner tunnel authentication.
[RFC84346] Section 4.6.1 allows that "At any time after the server has receiv However, <xref target="RFC8446" sectionFormat="comma" section="4.6.1"/> states
ed the client Finished message, it MAY send a NewSessionTicket message." This m that "at any time after the server has received the client Finished message, it
essage is sent by the server before <bcp14>MAY</bcp14> send a NewSessionTicket message." This message is sent by th
the inner authentication method has been run, and therefore before e server before
the inner authentication method has been run and therefore before
the user has been authenticated.</t> the user has been authenticated.</t>
<t>
<t>
This separation of data allows for a "time of use, time of check" This separation of data allows for a "time of use, time of check"
security issue. Malicious clients can begin a session and receive a security issue. Malicious clients can begin a session and receive a
NewSessionTicket message. The malicious client can then abort the NewSessionTicket message. The malicious client can then abort the
authentication session, and use the obtained NewSessionTicket to authentication session and use the obtained NewSessionTicket to
"resume" the previous session. If the server allows the session to "resume" the previous session.
If the server allows the session to
resume without verifying that the user had first been authenticated, resume without verifying that the user had first been authenticated,
the malicious client can then obtain network access without ever the malicious client can then obtain network access without ever
being authenticated network access without ever being authenticated.</t> being authenticated.</t>
<t>
<t> As a result, EAP servers <bcp14>MUST NOT</bcp14> assume that a user has been
As a result, EAP servers MUST NOT assume that a user has been
authenticated simply because a TLS session is being resumed. Even if authenticated simply because a TLS session is being resumed. Even if
a session is being resumed, an EAP server MAY have policies which a session is being resumed, an EAP server <bcp14>MAY</bcp14> have policies th at
still force the inner authentication methods to be run. For example, still force the inner authentication methods to be run. For example,
the users password may have expired in the time interval between the user's password may have expired in the time interval between
first authenticaction, and session resumption.</t> first authentication and session resumption.</t>
<t>
<t> Therefore, the guidelines given here describe situations where an EAP
The guidelines given here therefore describe situations where an EAP server is permitted to allow session resumption rather than where an EAP serv
server is permitted to allow session resumption, not where it is er is
required to allow session resumption. An EAP server could simply required to allow session resumption. An EAP server could simply
refuse to issue session tickets, or could run the full inner refuse to issue session tickets or could run the full inner
authentication even if a session was resumed.</t> authentication, even if a session was resumed.</t>
<t>
<t> Where session tickets are used, the EAP server <bcp14>SHOULD</bcp14> track th
Where session tickets are used, the EAP server SHOULD track the e
successful completion of an inner authentication, and associate that successful completion of an inner authentication and associate that
status with any session tickets issued for that session. This status with any session tickets issued for that session. This
requirement can be met in a number of different ways.</t> requirement can be met in a number of different ways.</t>
<t>
<t>
One way is for the EAP server to simply not send any TLS One way is for the EAP server to simply not send any TLS
NewSessionTicket messages until the inner authentication has NewSessionTicket messages until the inner authentication has
completed successfully. The EAP server then knows that the existence completed successfully. The EAP server then knows that the existence
of a session ticket is proof that a user was authenticated, and the of a session ticket is proof that a user was authenticated, and the
session can be resumed.</t> session can be resumed.</t>
<t>
<t> Another way is for the EAP server to simply discard or invalidate any
Another way is for the EAP server to simple discard or invalidate any
session tickets until after the inner authentication has completed session tickets until after the inner authentication has completed
successfully. When the user is authenticated, a new TLS successfully. When the user is authenticated, a new TLS
NewSessionTicket message can be sent to the client, and the new NewSessionTicket message can be sent to the client, and the new
ticket cached and/or validated.</t> ticket can be cached and/or validated.</t>
<t>
<t>
Another way is for the EAP server to associate the inner Another way is for the EAP server to associate the inner
authentication status with each session ticket. When a session authentication status with each session ticket. When a session
ticket is used, the authentication status is checked. When a session ticket is used, the authentication status is checked. When a session
ticket shows that the inner authentication did not succeed, the EAP ticket shows that the inner authentication did not succeed, the EAP
server MUST run the inner authentication method(s) in the resumed server <bcp14>MUST</bcp14> run the inner authentication method(s) in the resu
tunnel, and grant only access based on the success or failure of med
those inner methods/</t> tunnel and only grant access based on the success or failure of
those inner methods.</t>
<t> <t>
However, the interaction between EAP implementations and any However, the interaction between EAP implementations and any
underlying TLS library may be complex, and the EAP server may not be underlying TLS library may be complex, and the EAP server may not be
able to make the above guarantees. Where the EAP server is unable to able to make the above guarantees. Where the EAP server is unable to
determine the users authentication status from the session ticket, it determine the user's authentication status from the session ticket, it
MUST assume that inner authentication has not completed, and it MUST <bcp14>MUST</bcp14> assume that inner authentication has not completed, and i
t <bcp14>MUST</bcp14>
run the inner authentication method(s) successfully in the resumed run the inner authentication method(s) successfully in the resumed
tunnel before granting access.</t> tunnel before granting access.</t>
<t>
<t>
This issue is not relevant for EAP-TLS, which only uses client This issue is not relevant for EAP-TLS, which only uses client
certificates for authentication in the TLS handshake. It is only certificates for authentication in the TLS handshake. It is only
relevant for TLS-based EAP methods which do not use the TLS layer to relevant for TLS-based EAP methods that do not use the TLS layer to
authenticate</t> authenticate.</t>
</section>
</section> <section anchor="sect-7.2" numbered="true" toc="default">
<name>Protected Success and Failure Indications</name>
<section title="Protected Success and Failure indications" anchor="sect-6 <t>
.2"><t> <xref target="RFC9190" format="default"/> provides for protected success and
<xref target="RFC9190"/> provides for protected success and failure indicatio failure indications as
ns as discussed in <xref target="RFC4137" sectionFormat="comma" section="4.1.1"/>.
discussed in Section 4.1.1 of <xref target="RFC4137"/>. These result indicat These result indications
ions are provided for both full authentication and resumption.</t>
are provided for both full authentication, and for resumption.</t> <t>
<t>
Other TLS-based EAP methods provide these result indications only for Other TLS-based EAP methods provide these result indications only for
resumption.</t> resumption.</t>
<t>
<t>
For full authentication, the other TLS-based EAP methods do not For full authentication, the other TLS-based EAP methods do not
provide for protected success and failure indications as part of the provide for protected success and failure indications as part of the
outer TLS exchange. That is, the protected result indication is not outer TLS exchange. That is, the protected result indication is not
used, and there is no TLS-layer alert sent when the inner used, and there is no TLS-layer alert sent when the inner
authentication fails. Instead, there is simply either an EAP-Success authentication fails. Instead, there is simply either an EAP-Success
or EAP-Failure sent. This behavior is the same as for previous TLS or an EAP-Failure sent. This behavior is the same as for previous TLS
versions, and therefore introduces no new security issues.</t> versions; therefore, it introduces no new security issues.</t>
<t>
<t>
We note that most TLS-based EAP methods provide for success and We note that most TLS-based EAP methods provide for success and
failure indications as part of the authentication exchange performed failure indications as part of the authentication exchange performed
inside of the TLS tunnel. These result indications are therefore inside of the TLS tunnel. These result indications are therefore
protected, as they cannot be modified or forged.</t> protected, as they cannot be modified or forged.</t>
<t>
<t>
However, some inner methods do not provide for success or failure However, some inner methods do not provide for success or failure
indications. For example, the use of EAP-TTLS with inner PAP, CHAP, indications. For example, the use of EAP-TTLS with inner PAP, CHAP,
or MS-CHAP. Those methods send authentication credentials to the EAP or MS-CHAP. Those methods send authentication credentials to the EAP
server via the inner tunnel, with no method to signal success or server via the inner tunnel with no method to signal success or
failure inside of the tunnel.</t> failure inside of the tunnel.</t>
<t>
<t> There are functionally equivalent authentication methods that can be
There are functionally equivalent authentication methods which can be
used to provide protected result indications. PAP can often be used to provide protected result indications. PAP can often be
replaced with EAP-GTC, CHAP with EAP-MD5, and MS-CHAPv1 with MS- replaced with EAP-Generic Token Card (EAP-GTC), CHAP with EAP-MD5, and MS-CHA
CHAPv2 or EAP-MSCHAPv2. All of the replacement methods provide for Pv1 with
similar functionality, and have protected success and failure MS-CHAPv2 or EAP-MSCHAPv2. All of the replacement methods provide for
similar functionality and have protected success and failure
indication. The main cost to this change is additional round trips.</t> indication. The main cost to this change is additional round trips.</t>
<t>
<t> It is <bcp14>RECOMMENDED</bcp14> that implementations deprecate inner tunnel
It is RECOMMENDED that implementations deprecate inner tunnel methods methods
which do not provide protected success and failure indications when that do not provide protected success and failure indications when
TLS session tickets cannot be used. Implementations SHOULD use EAP- TLS session tickets cannot be used. Implementations <bcp14>SHOULD</bcp14> us
GTC instead of PAP, and EAP-MD5 instead of CHAP. Implementations e EAP-
SHOULD use MS-CHAPv2 or EAP-MSCHAPv2 instead of MS-CHAPv1. New TLS- GTC instead of PAP and EAP-MD5 instead of CHAP. Implementations
based EAP methods MUST provide protected success and failure <bcp14>SHOULD</bcp14> use MS-CHAPv2 or EAP-MSCHAPv2 instead of MS-CHAPv1. Ne
w TLS-
based EAP methods <bcp14>MUST</bcp14> provide protected success and failure
indications inside of the TLS tunnel.</t> indications inside of the TLS tunnel.</t>
<t>
<t>
When the inner authentication protocol indicates that authentication When the inner authentication protocol indicates that authentication
has failed, then implementations MUST fail authentication for the has failed, then implementations <bcp14>MUST</bcp14> fail authentication for the
entire session. There may be additional protocol exchanges in order entire session. There may be additional protocol exchanges in order
to exchange more detailed failure indications, but the final result to exchange more detailed failure indications, but the final result
MUST be a failed authentication. As noted earlier, any session <bcp14>MUST</bcp14> be a failed authentication. As noted earlier, any sessio
tickets for this failed authentication MUST be either invalidated or n
tickets for this failed authentication <bcp14>MUST</bcp14> be either invalida
ted or
discarded.</t> discarded.</t>
<t>
<t>
Similarly, when the inner authentication protocol indicates that Similarly, when the inner authentication protocol indicates that
authentication has succeeded, then implementations SHOULD cause authentication has succeeded, implementations <bcp14>SHOULD</bcp14> cause
authentication to succeed for the entire session. There MAY be authentication to succeed for the entire session. There <bcp14>MAY</bcp14> b
additional protocol exchanges which could still cause failure, so we e
additional protocol exchanges that could still cause failure, so we
cannot mandate sending success on successful authentication.</t> cannot mandate sending success on successful authentication.</t>
<t>
<t> In both of these cases, the EAP server <bcp14>MUST</bcp14> send an EAP-Failur
In both of these cases, the EAP server MUST send an EAP-Failure or e or
EAP-Success message, as indicated by <xref target="sect-2"/>, item 4 of <xref EAP-Success message, as indicated by Step 4 in <xref target="RFC3748" section
target="RFC3748"/>. Format="of" section="2"/>.
Even though both parties have already determined the final Even though both parties have already determined the final
authentication status, the full EAP state machine must still be authentication status, the full EAP state machine must still be
followed.</t> followed.</t>
</section>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<t>
<section title="IANA Considerations" anchor="sect-7"><t>
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the TLS- Authority (IANA) regarding the registration of values related to the
based EAP methods for TLS 1.3 protocol in accordance with <xref target="RFC81 TLS-based EAP methods for the TLS 1.3 protocol in accordance w
26"/>.</t> ith <xref target="RFC8126"
format="default"/>.</t>
<t> <t>
This memo requires IANA to add the following labels to the TLS IANA has added the following labels to the "TLS
Exporter Label Registry defined by <xref target="RFC5705"/>. These labels ar Exporter Label" registry defined by <xref target="RFC5705" format="default"/>
e used . These labels are used
in the derivation of Key_Material and Method-Id as defined above in in the derivation of Key_Material and Method-Id as defined above in
<xref target="sect-2"/>.</t> <xref target="sect-2" format="default"/>, and they are used only for TEAP.</t
>
<t>
The labels below need to be added to the "TLS Exporter Labels"
registry as "Value", with this specification as "Reference". For all
of these labels the "DTLS-OK" field should be "N", and the
"Recommended" field should be "Y".</t>
<t> <table anchor="IANA_table">
These labels are used only for TEAP.</t> <name>TLS Exporter Labels Registry</name>
<thead>
<tr>
<th>Value</th>
<th>DTLS-OK</th>
<th>Recommended</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>EXPORTER: teap session key seed</td>
<td align="center">N</td>
<td align="center">Y</td>
<td align="center">RFC 9427</td>
</tr>
<tr>
<td>EXPORTER: Inner Methods Compound Keys</td>
<td align="center">N</td>
<td align="center">Y</td>
<td align="center">RFC 9427</td>
</tr>
<tr>
<td>EXPORTER: Session Key Generating Function</td>
<td align="center">N</td>
<td align="center">Y</td>
<td align="center">RFC 9427</td>
</tr>
<tr>
<td>EXPORTER: Extended Session Key Generating Function</td>
<td align="center">N</td>
<td align="center">Y</td>
<td align="center">RFC 9427</td>
</tr>
<tr>
<td>TEAPbindkey@ietf.org</td>
<td align="center">N</td>
<td align="center">Y</td>
<td align="center">RFC 9427</td>
</tr>
</tbody>
</table>
</section>
<figure><artwork><![CDATA[ </middle>
* EXPORTER: teap session key seed <back>
* EXPORTER: Inner Methods Compound Keys
* EXPORTER: Session Key Generating Function
* EXPORTER: Extended Session Key Generating Function
* TEAPbindkey@ietf.org
]]></artwork>
</figure>
</section>
</middle> <displayreference target="I-D.josefsson-pppext-eap-tls-eap" to="PEAP"/>
<back> <references>
<references title="Normative References"> <name>References</name>
&RFC2119; <references>
&RFC3748; <name>Normative References</name>
&RFC5216; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC5705; 119.xml"/>
&RFC7170; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
&RFC8126; 748.xml"/>
&RFC8174; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
&RFC8446; 216.xml"/>
&RFC9190; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<reference anchor="IANA" target="https://www.iana.org/assignments/eap-num 705.xml"/>
bers/eap-numbers.xhtml#eap-numbers-4"><front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<title>Method Types</title> 170.xml"/>
<author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</author> 126.xml"/>
<date/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</front> 174.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</references> 446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
190.xml"/>
<references title="Informative References"> <reference anchor="IANA" target="https://www.iana.org/assignments/eap-nu
<reference anchor="MSPEAP" target="https://msdn.microsoft.com/en-us/libra mbers/">
ry/cc238354.aspx"><front> <front>
<title>[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)</ti <title>Method Types</title>
tle> <author>
<author> <organization>IANA</organization>
</author> </author>
<date/> </front>
</front> </reference>
</reference> </references>
<references>
<name>Informative References</name>
&I-D.josefsson-pppext-eap-tls-eap; <reference anchor="MSPEAP" target="https://msdn.microsoft.com/en-us/libr
ary/cc238354.aspx">
<front>
<title>[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP
)</title>
<author>
<organization>Microsoft Corporation</organization>
</author>
<date month="June" year="2021"/>
</front>
<refcontent>Protocol Revision 31.0</refcontent>
</reference>
<reference anchor="PEAP-MPPE" target="https ://docs.microsoft.com/en-us/o <!-- [I-D.josefsson-pppext-eap-tls-eap] IESG state Expired. Changed to long way
penspecs/windows_protocols/MS-PEAP/e75b0385-915a-4fc3-a549-fd3d06b995b0"> to include 2 missing authors. -->
<reference anchor="I-D.josefsson-pppext-eap-tls-eap" target="https://datatracker
.ietf.org/doc/html/draft-josefsson-pppext-eap-tls-eap-10">
<front>
<title>Protected EAP Protocol (PEAP) Version 2</title>
<author initials="A." surname="Palekar" fullname="Ashwin Palekar">
<organization>Microsoft Corporation</organization>
</author>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization>Extundo</organization>
</author>
<author initials="D." surname="Simon" fullname="Daniel Simon">
<organization>Microsoft Corporation</organization>
</author>
<author initials="G." surname="Zorn" fullname="Glen Zorn">
<organization>Cisco Systems</organization>
</author>
<author initials="J." surname="Salowey" fullname="Joe Salowey">
<organization>Cisco Systems</organization>
</author>
<author initials="H." surname="Zhou" fullname="Hao Zhou">
<organization>Cisco Systems</organization>
</author>
<date month="October" day="15" year="2004"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-josefsson-pppext-eap-tls-eap-10"/
>
</reference>
<reference anchor="PEAP-MPPE" target="https://learn.microsoft.com/en-us/
openspecs/windows_protocols/ms-peap/e75b0385-915a-4fc3-a549-fd3d06b995b0">
<front> <front>
<title>PEAP Key Management</title> <title>Key Management</title>
<author></author> <author>
<date></date> <organization>Microsoft Corporation</organization>
</author>
<date month="October" year="2020"/>
</front> </front>
<refcontent>Section 3.1.5.7</refcontent>
</reference> </reference>
<reference anchor="PEAP-PRF" target="https://docs.microsoft.com/en-us/ope nspecs/windows_protocols/MS-PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df"> <reference anchor="PEAP-PRF" target="https://docs.microsoft.com/en-us/op enspecs/windows_protocols/MS-PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df">
<front> <front>
<title>PEAP Intermediate PEAP MAC Key (IPMK) and Compound MAC Key (C <title>Intermediate PEAP MAC Key (IPMK) and Compound MAC Key (CMK)</
MK)</title> title>
<author></author> <author>
<date></date> <organization>Microsoft Corporation</organization>
</author>
<date month="February" year="2019"/>
</front> </front>
<refcontent>Section 3.1.5.5.2.2</refcontent>
</reference> </reference>
<reference anchor="PEAP-TK" target="https://docs.microsoft.com/en-us/open specs/windows_protocols/MS-PEAP/41288c09-3d7d-482f-a57f-e83691d4d246"> <reference anchor="PEAP-TK" target="https://docs.microsoft.com/en-us/ope nspecs/windows_protocols/MS-PEAP/41288c09-3d7d-482f-a57f-e83691d4d246">
<front> <front>
<title>PEAP Tunnel Key (TK)</title> <title>PEAP Tunnel Key (TK)</title>
<author></author> <author>
<date></date> <organization>Microsoft Corporation</organization>
</author>
<date month="April" year="2021"/>
</front> </front>
<refcontent>Section 3.1.5.5.2.1</refcontent>
</reference> </reference>
&RFC1994; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
&RFC2433; 994.xml"/>
&RFC2759; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC4137; 433.xml"/>
&RFC4851; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC5281; 759.xml"/>
&RFC5422; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
&RFC7542; 137.xml"/>
&RFC7585; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</references> 851.xml"/>
<section title="Acknowledgments" numbered="no" anchor="acknowledgments">< <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
t> 281.xml"/>
Thanks to Jorge Vergara for a detailed review of the requirements for <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
various EAP types.</t> 422.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<t> 542.xml"/>
Thanks to Jorge Vergara, Bruno Periera Vidal, Alexander Clouter, <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
Karri Huhtanen, and Heikki Vatiainen for reviews of this document, 585.xml"/>
</references>
</references>
<section numbered="false" anchor="acknowledgments" toc="default">
<name>Acknowledgments</name>
<t>
Thanks to <contact fullname="Jorge Vergara"/> for a detailed review of the re
quirements for
various EAP Types.</t>
<t>
Thanks to <contact fullname="Jorge Vergara"/>, <contact fullname="Bruno Perie
ra Vidal"/>, <contact fullname="Alexander Clouter"/>,
<contact fullname="Karri Huhtanen"/>, and <contact fullname="Heikki Vatiainen
"/> for reviews of this document
and for assistance with interoperability testing.</t> and for assistance with interoperability testing.</t>
</section>
<t> </back>
Authors' Addresses</t> </rfc>
</section>
</back>
</rfc>
 End of changes. 190 change blocks. 
822 lines changed or deleted 833 lines changed or added

This html diff was produced by rfcdiff 1.48.