Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-15
Network Working Group J. Mattsson
Internet-Draft M. Sethi
Updates: 5216 (if approved) Ericsson
Intended status: Standards Track May 4, 2021
Expires: November 5, 2021
Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-15
Abstract
The Extensible Authentication Protocol (EAP), defined in RFC 3748,
provides a standard mechanism for support of multiple authentication
methods. This document specifies the use of EAP-Transport Layer
Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
with existing implementations of EAP-TLS. TLS 1.3 provides
significantly improved security, privacy, and reduced latency when
compared to earlier versions of TLS. EAP-TLS with TLS 1.3 further
improves security and privacy by always providing forward secrecy,
never disclosing the peer identity, and by mandating use of
revocation checking. This document also provides guidance on
authorization and resumption for EAP-TLS in general (regardless of
the underlying TLS version used). This document updates RFC 5216.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 5, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Mattsson & Sethi Expires November 5, 2021 [Page 1]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements and Terminology . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4
2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 5
2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 6
2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 10
2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 13
2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 14
2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 15
2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 16
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 17
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18
2.4. Parameter Negotiation and Compliance Requirements . . . . 19
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 19
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 20
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 21
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 21
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 22
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 22
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 23
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 23
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 24
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 26
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 27
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Normative References . . . . . . . . . . . . . . . . . . 28
6.2. Informative references . . . . . . . . . . . . . . . . . 29
Appendix A. Updated references . . . . . . . . . . . . . . . . . 33
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Mattsson & Sethi Expires November 5, 2021 [Page 2]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748],
provides a standard mechanism for support of multiple authentication
methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies
an EAP authentication method with certificate-based mutual
authentication utilizing the TLS handshake protocol for cryptographic
algorithms and protocol version negotiation and establishment of
shared secret keying material. EAP-TLS is widely supported for
authentication and key establishment in IEEE 802.11 [IEEE-802.11]
(Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec) networks using IEEE
802.1X [IEEE-802.1X] and it's the default mechanism for certificate
based authentication in 3GPP 5G [TS.33.501] and MulteFire [MulteFire]
networks. Many other EAP methods such as EAP-FAST [RFC4851], EAP-
TTLS [RFC5281], TEAP [RFC7170], and PEAP [PEAP] depend on TLS and
EAP-TLS.
EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346],
but can also work with TLS 1.2 [RFC5246]. TLS 1.0 and 1.1 are
formally deprecated and prohibited to negotiate and use [RFC8996].
Weaknesses found in TLS 1.2, as well as new requirements for
security, privacy, and reduced latency have led to the specification
of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is
in large parts a complete remodeling of the TLS handshake protocol
including a different message flow, different handshake messages,
different key schedule, different cipher suites, different
resumption, different privacy protection, and different record
padding. This means that significant parts of the normative text in
the previous EAP-TLS specification [RFC5216] are not applicable to
EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy
handling, and key derivation need to be appropriately addressed for
EAP-TLS with TLS 1.3.
This document defines how to use EAP-TLS with TLS 1.3 and does not
change how EAP-TLS is used with older versions of TLS. It does
however provide additional guidance on authorization and resumption
for EAP-TLS in general (regardless of the underlying TLS version
used). While this document updates EAP-TLS [RFC5216], it remains
backwards compatible with it and existing implementations of EAP-TLS.
This document only describes differences compared to [RFC5216]. All
message flow are example message flows specific to TLS 1.3 and do not
apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state
machine with the EAP state machine it is possible that new versions
of TLS will cause incompatibilities that introduce failures or
security issues if they are not carefully integrated into the EAP-TLS
protocol. Therefore, implementations MUST limit the maximum TLS
Mattsson & Sethi Expires November 5, 2021 [Page 3]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
version they use to 1.3, unless later versions are explicitly enabled
by the administrator.
This document specifies EAP-TLS 1.3 and does not specify how other
TLS-based EAP methods use TLS 1.3. The specification for how other
TLS-based EAP methods use TLS 1.3 is left to other documents such as
[I-D.ietf-emu-tls-eap-types].
In addition to the improved security and privacy offered by TLS 1.3,
there are other significant benefits of using EAP-TLS with TLS 1.3.
Privacy, which in EAP-TLS means that the peer username is not
disclosed, is mandatory and achieved without any additional round-
trips. Revocation checking is mandatory and simplified with OCSP
stapling, and TLS 1.3 introduces more possibilities to reduce
fragmentation when compared to earlier versions of TLS.
1.1. Requirements and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers are expected to be familiar with the terms and concepts used
in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is
used for the entity acting as EAP peer and TLS client. The term EAP-
TLS server is used for the entity acting as EAP server and TLS
server.
2. Protocol Overview
2.1. Overview of the EAP-TLS Conversation
This section updates Section 2.1 of [RFC5216].
TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS. Therefore, much of Section 2.1
of [RFC5216] does not apply for TLS 1.3.
After receiving an EAP-Request packet with EAP-Type=EAP-TLS as
described in [RFC5216] the conversation will continue with the TLS
handshake protocol encapsulated in the data fields of EAP-Response
and EAP-Request packets. When EAP-TLS is used with TLS version 1.3,
the formatting and processing of the TLS handshake SHALL be done as
specified in version 1.3 of TLS. This document only lists additional
and different requirements, restrictions, and processing compared to
[RFC8446] and [RFC5216].
Mattsson & Sethi Expires November 5, 2021 [Page 4]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
2.1.1. Authentication
This section updates Section 2.1.1 of [RFC5216].
The EAP-TLS server MUST authenticate with a certificate and SHOULD
require the EAP-TLS peer to authenticate with a certificate.
Certificates can be of any type supported by TLS including raw public
keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except
for resumption. The full handshake in EAP-TLS with TLS 1.3 always
provide forward secrecy by exchange of ephemeral "key_share"
extensions in the ClientHello and ServerHello (e.g. containing
ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3,
see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early
application data which like all other application data is not used in
EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information
of the "early_data" extension. Resumption is handled as described in
Section 2.1.3. TLS 1.3 introduced the Post-Handshake KeyUpdate
message which is not useful and not expected in EAP-TLS. As a
protected success indication [RFC3748] the EAP-TLS server always
sends TLS application data 0x00, see Section 2.5. Note that a TLS
implementation MAY not allow the EAP-TLS layer to control in which
order things are sent and the application data MAY therefore be sent
before a NewSessionTicket. TLS application data 0x00 is therefore to
be interpreted as success after the EAP-Request that contains TLS
application data 0x00. After the EAP-TLS server has received an
empty EAP-Response to the EAP-Request containing the TLS application
data 0x00, the EAP-TLS server sends EAP-Success.
Figure 1 shows an example message flow for a successful EAP-TLS full
handshake with mutual authentication (and neither HelloRetryRequest
nor Post-Handshake messages are sent).
Mattsson & Sethi Expires November 5, 2021 [Page 5]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 1: EAP-TLS mutual authentication
2.1.2. Ticket Establishment
This is a new section when compared to [RFC5216].
To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS
server MUST send one or more Post-Handshake NewSessionTicket messages
(each associated with a PSK, a PSK identity, a ticket lifetime, and
other parameters) in the initial authentication. Note that TLS 1.3
[RFC8446] limits the ticket lifetime to a maximum of 604800 seconds
(7 days) and EAP-TLS servers MUST respect this upper limit when
issuing tickets. The NewSessionTicket is sent after the EAP-TLS
server has received the client Finished message in the initial
authentication. The NewSessionTicket can be sent in the same flight
as the TLS server Finished or later. The PSK associated with the
Mattsson & Sethi Expires November 5, 2021 [Page 6]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
ticket depends on the client Finished and cannot be pre-computed in
handshakes with client authentication. The NewSessionTicket message
MUST NOT include an "early_data" extension. If the "early_data"
extension is received then it MUST be ignored. Servers should take
into account that fewer NewSessionTickets will likely be needed in
EAP-TLS than in the usual HTTPS connection scenario. In most cases a
single NewSessionTicket will be sufficient. A mechanism by which
clients can specify the desired number of tickets needed for future
connections is defined in [I-D.ietf-tls-ticketrequests].
Figure 2 shows an example message flow for a successful EAP-TLS full
handshake with mutual authentication and ticket establishment of a
single ticket.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS NewSessionTicket,
<-------- TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 2: EAP-TLS ticket establishment
Mattsson & Sethi Expires November 5, 2021 [Page 7]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
2.1.3. Resumption
This section updates Section 2.1.2 of [RFC5216].
EAP-TLS is typically used with client authentication and typically
fragments the TLS flights into a large number of EAP requests and EAP
responses. Resumption significantly reduces the number of round-
trips and enables the EAP-TLS server to omit database lookups needed
during a full handshake with client authentication. TLS 1.3 replaces
the session resumption mechanisms in earlier versions of TLS with a
new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP-TLS
SHALL use a resumption mechanism compatible with version 1.3 of TLS.
For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If
the client has received a NewSessionTicket message from the EAP-TLS
server, the client can use the PSK identity associated with the
ticket to negotiate the use of the associated PSK. If the EAP-TLS
server accepts it, then the security context of the new connection is
tied to the original connection and the key derived from the initial
handshake is used to bootstrap the cryptographic state instead of a
full handshake. It is up to the EAP-TLS peer to use resumption, but
it is RECOMMENDED that the EAP-TLS peer use resumption if it has a
valid ticket that has not been used before. It is left to the EAP-
TLS server whether to accept resumption, but it is RECOMMENDED that
the EAP-TLS server accept resumption if the ticket which was issued
is still valid. However, the EAP-TLS server MAY choose to require a
full handshake. As in a full handshake, sending a NewSessionTicket
during resumption is optional. As described in Appendix C.4 of
[RFC8446], reuse of a ticket allows passive observers to correlate
different connections. EAP-TLS peers and EAP-TLS servers SHOULD
follow the client tracking preventions in Appendix C.4 of [RFC8446].
It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the
same realm during resumption and the original full handshake. This
requirement allows EAP packets to be routed to the same destination
as the original full handshake. If this recommendation is not
followed, resumption is likely impossible. When NAI reuse can be
done without privacy implications, it is RECOMMENDED to use the same
NAI in the resumption, as was used in the original full handshake
[RFC7542]. For example, the NAI @realm can safely be reused since it
does not provide any specific information to associate a user's
resumption attempt with the original full handshake. However,
reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path
attacker to associate a resumption attempt with the original full
handshake. The TLS PSK identity is typically derived by the TLS
implementation and may be an opaque blob without a routable realm.
The TLS PSK identity on its own is therefore unsuitable as a NAI in
the Identity Response.
Mattsson & Sethi Expires November 5, 2021 [Page 8]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
Figure 3 shows an example message flow for a subsequent successful
EAP-TLS resumption handshake where both sides authenticate via a PSK
provisioned via an earlier NewSessionTicket and where the server
provisions a single new ticket.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
<-------- TLS Finished,
TLS NewSessionTicket)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 3: EAP-TLS resumption
As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD
supply a "key_share" extension when attempting resumption, which
allows the EAP-TLS server to potentially decline resumption and fall
back to a full handshake. If the EAP-TLS peer did not supply a
"key_share" extension when attempting resumption, the EAP-TLS server
needs to send HelloRetryRequest to signal that additional information
is needed to complete the handshake, and the EAP-TLS peer needs to
send a second ClientHello containing that information. Providing a
"key_share" and using the "psk_dhe_ke" pre-shared key exchange mode
is also important in order to limit the impact of a key compromise.
When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning
that key leakage does not compromise any earlier connections. It is
RECOMMMENDED to use "psk_dhe_ke" for resumption.
Mattsson & Sethi Expires November 5, 2021 [Page 9]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
2.1.4. Termination
This section updates Section 2.1.3 of [RFC5216].
TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS. Therefore, some normative text
in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3. The two
paragraphs below replaces the corresponding paragraphs in
Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3. The
other paragraphs in Section 2.1.3 of [RFC5216] still apply with the
exception that SessionID is deprecated.
If the EAP-TLS peer authenticates successfully, the EAP-TLS server
MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing
TLS records conforming to the version of TLS used. The message
flow ends with the EAP-TLS server sending an EAP-Success message.
If the EAP-TLS server authenticates successfully, the EAP-TLS peer
MUST send an EAP-Response message with EAP-Type=EAP-TLS containing
TLS records conforming to the version of TLS used.
Figures 4, 5, and 6 illustrate message flows in several cases where
the EAP-TLS peer or EAP-TLS server sends a TLS Error alert message.
In earlier versions of TLS, error alerts could be warnings or fatal.
In TLS 1.3, error alerts are always fatal and the only alerts sent at
warning level are "close_notify" and "user_cancelled", both of which
indicate that the connection is not going to continue normally, see
[RFC8446].
In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
fatal error condition. Failure to send TLS Error alerts means that
the peer or server would have no way of determining what went wrong.
EAP-TLS 1.3 strengthen this requirement. Whenever an implementation
encounters a fatal error condition, it MUST send an appropriate TLS
Error alert.
Figure 4 shows an example message flow where the EAP-TLS server
rejects the ClientHello with an error alert. The EAP-TLS server can
also partly reject the ClientHello with a HelloRetryRequest, see
Section 2.1.6.
Mattsson & Sethi Expires November 5, 2021 [Page 10]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Error Alert)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Failure
Figure 4: EAP-TLS server rejection of ClientHello
Figure 5 shows an example message flow where EAP-TLS server
authentication is unsuccessful and the EAP-TLS peer sends a TLS Error
alert.
Mattsson & Sethi Expires November 5, 2021 [Page 11]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Error Alert)
-------->
<-------- EAP-Failure
Figure 5: EAP-TLS unsuccessful EAP-TLS server authentication
Figure 6 shows an example message flow where the EAP-TLS server
authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
fails to authenticate to the EAP-TLS server and sends a TLS Error
alert.
Mattsson & Sethi Expires November 5, 2021 [Page 12]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Error Alert)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Failure
Figure 6: EAP-TLS unsuccessful client authentication
2.1.5. No Peer Authentication
This is a new section when compared to [RFC5216].
Figure 7 shows an example message flow for a successful EAP-TLS full
handshake without peer authentication (e.g., emergency services, as
described in [RFC7406]).
Mattsson & Sethi Expires November 5, 2021 [Page 13]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 7: EAP-TLS without peer authentication
2.1.6. Hello Retry Request
This is a new section when compared to [RFC5216].
As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a
HelloRetryRequest message in response to a ClientHello if the EAP-TLS
server finds an acceptable set of parameters but the initial
ClientHello does not contain all the needed information to continue
the handshake. One use case is if the EAP-TLS server does not
support the groups in the "key_share" extension (or there is no
"key_share" extension), but supports one of the groups in the
"supported_groups" extension. In this case the client should send a
new ClientHello with a "key_share" that the EAP-TLS server supports.
Figure 8 shows an example message flow for a successful EAP-TLS full
handshake with mutual authentication and HelloRetryRequest. Note the
extra round-trip as a result of the HelloRetryRequest.
Mattsson & Sethi Expires November 5, 2021 [Page 14]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS HelloRetryRequest)
<--------
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 8: EAP-TLS with Hello Retry Request
2.1.7. Identity
This is a new section when compared to [RFC5216].
It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity
Response as such identities are routable and privacy-friendly. While
opaque blobs are allowed by [RFC3748], such identities are NOT
Mattsson & Sethi Expires November 5, 2021 [Page 15]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
RECOMMENDED as they are not routable and should only be considered in
local deployments where the EAP-TLS peer, EAP authenticator, and EAP-
TLS server all belong to the same network. Many client certificates
contain an identity such as an email address, which is already in NAI
format. When the client certificate contains a NAI as subject name
or alternative subject name, an anonymous NAI SHOULD be derived from
the NAI in the certificate, see Section 2.1.8. More details on
identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8.
2.1.8. Privacy
This section updates Section 2.1.4 of [RFC5216].
TLS 1.3 significantly improves privacy when compared to earlier
versions of TLS by forbidding cipher suites without confidentiality
and encrypting large parts of the TLS handshake including the
certificate messages.
EAP-TLS peer and server implementations supporting TLS 1.3 MUST
support anonymous Network Access Identifiers (NAIs) (Section 2.4 in
[RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username
in cleartext in the Identity Response. Following [RFC7542], it is
RECOMMENDED to omit the username (i.e., the NAI is @realm), but other
constructions such as a fixed username (e.g. anonymous@realm) or an
encrypted username (e.g.,
xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed.
Note that the NAI MUST be a UTF-8 string as defined by the grammar in
Section 2.2 of [RFC7542].
As the certificate messages in TLS 1.3 are encrypted, there is no
need to send an empty certificate_list and perform a second handshake
for privacy (as needed by EAP-TLS with earlier versions of TLS).
When EAP-TLS is used with TLS version 1.3 the EAP-TLS peer and EAP-
TLS server SHALL follow the processing specified by version 1.3 of
TLS. This means that the EAP-TLS peer only sends an empty
certificate_list if it does not have an appropriate certificate to
send, and the EAP-TLS server MAY treat an empty certificate_list as a
terminal condition.
EAP-TLS with TLS 1.3 is always used with privacy. This does not add
any extra round-trips and the message flow with privacy is just the
normal message flow as shown in Figure 1.
2.1.9. Fragmentation
This section updates Section 2.1.5 of [RFC5216].
Mattsson & Sethi Expires November 5, 2021 [Page 16]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
Including ContentType (1 byte), ProtocolVersion (2 bytes), and length
(2 bytes) headers a single TLS record may be up to 16645 octets in
length. EAP-TLS fragmentation support is provided through addition
of a flags octet within the EAP-Response and EAP-Request packets, as
well as a TLS Message Length field of four octets. Implementations
MUST NOT set the L bit in unfragmented messages, but MUST accept
unfragmented messages with and without the L bit set.
Some EAP implementations and access networks may limit the number of
EAP packet exchanges that can be handled. To avoid fragmentation, it
is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and
trust anchor certificates small and the length of the certificate
chains short. In addition, it is RECOMMENDED to use mechanisms that
reduce the sizes of Certificate messages. For a detailed discussion
on reducing message sizes to prevent fragmentation, see
[I-D.ietf-emu-eaptlscert].
2.2. Identity Verification
This section updates Section 2.2 of [RFC5216].
The EAP peer identity provided in the EAP-Response/Identity is not
authenticated by EAP-TLS. Unauthenticated information SHALL NOT be
used for accounting purposes or to give authorization. The
authenticator and the EAP-TLS server MAY examine the identity
presented in EAP-Response/Identity for purposes such as routing and
EAP method selection. EAP-TLS servers MAY reject conversations if
the identity does not match their policy. Note that this also
applies to resumption, see Sections 2.1.3, 5.6, and 5.7.
The EAP server identity in the TLS server certificate is typically a
fully qualified domain name (FQDN). EAP peer implementations SHOULD
allow users to configuring a unique trust root (CA certificate) and a
server name to authenticate the server certificate and match the
subjectAlternativeName (SAN) extension in the server certificate with
the configured server name. In the absence of a user-configured root
CA certificate, implementations MAY rely on system-wide root CA
certificate bundles for authenticating the server certificate. If
server name matching is not used, then peers may end up trusting
servers for EAP authentication that are not intended to be EAP
servers for the network. If name matching is not used with a public
CA bundle, then effectively any server can obtain a certificate which
will be trusted for EAP authentication by the Peer.
The process of configuring a root CA certificate and a server name is
non-trivial and therefore automated methods of provisioning are
RECOMMENDED. For example, the eduroam federation [RFC7593] provides
a Configuration Assistant Tool (CAT) to automate the configuration
Mattsson & Sethi Expires November 5, 2021 [Page 17]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
process. In the absence of a trusted root CA certificate (user
configured or system-wide), EAP peers MAY implement a trust on first
use (TOFU) mechanism where the peer trusts and stores the server
certificate during the first connection attempt. The EAP peer
ensures that the server presents the same stored certificate on
subsequent interactions. Use of TOFU mechanism does not allow for
the server certificate to change without out-of-band validation of
the certificate and is therefore not suitable for many deployments.
2.3. Key Hierarchy
This section updates Section 2.3 of [RFC5216].
TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier
versions of TLS with HKDF and completely changes the Key Schedule.
The key hierarchies shown in Section 2.3 of [RFC5216] are therefore
not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3
the key schedule is described in Section 7.1 of [RFC8446].
When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
Method-Id SHALL be derived from the exporter_secret using the TLS
exporter interface [RFC5705] (for TLS 1.3 this is defined in
Section 7.5 of [RFC8446]).
Type-Code = 0x0D
MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)
EMSK = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)
Session-Id = Type-Code || Method-Id
Other TLS based EAP methods can use the TLS exporter in a similar
fashion, see [I-D.ietf-emu-tls-eap-types].
[RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are
not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower
layers use the MSK in a lower-layer dependent manner. EAP-TLS with
TLS 1.3 exports the MSK and does not specify how it used by lower
layers.
Note that the key derivation MUST use the length values given above.
While in TLS 1.2 and earlier it was possible to truncate the output
by requesting less data from the TLS-Exporter function, this practice
is not possible with TLS 1.3. If an implementation intends to use
only a part of the output of the TLS-Exporter function, then it MUST
ask for the full output and then only use the desired part. Failure
to do so will result in incorrect values being calculated for the
above keying material.
Mattsson & Sethi Expires November 5, 2021 [Page 18]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
without having to extract the Main Secret, ClientHello.random, and
ServerHello.random in a non-standard way.
2.4. Parameter Negotiation and Compliance Requirements
This section updates Section 2.4 of [RFC5216].
TLS 1.3 cipher suites are defined differently than in earlier
versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites
discussed in Section 2.4 of [RFC5216] can therefore not be used when
EAP-TLS is used with TLS version 1.3.
When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-
TLS servers MUST comply with the compliance requirements (mandatory-
to-implement cipher suites, signature algorithms, key exchange
algorithms, extensions, etc.) for the TLS version used. For TLS 1.3
the compliance requirements are defined in Section 9 of [RFC8446].
In EAP-TLS with TLS 1.3, only cipher suites with confidentiality
SHALL be supported.
While EAP-TLS does not protect any application data except for the
Commitment Message, the negotiated cipher suites and algorithms MAY
be used to secure data as done in other TLS-based EAP methods.
2.5. EAP State Machines
This is a new section when compared to [RFC5216] and only applies to
TLS 1.3. [RFC4137] offers a proposed state machine for EAP.
TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post-
Handshake messages use the handshake content type and can be sent
after the main handshake. Examples of Post-Handshake messages are
NewSessionTicket, which is used for resumption and KeyUpdate, which
is not useful and not expected in EAP-TLS. After sending TLS
Finished, the EAP-TLS server may send any number of Post-Handshake
messages in separate EAP-Requests.
To provide a protected success result indication and to decrease the
uncertainty for the EAP-TLS peer, the following procedure MUST be
followed:
When an EAP-TLS server has successfully processed the TLS client
Finished and sent its last handshake message (Finished or a Post-
Handshake), it commits to not sending any more handshake messages by
sending an encrypted TLS record with application data 0x00. The
encrypted TLS record with application data 0x00 is a protected
success result indication, as defined in [RFC3748]. After sending an
Mattsson & Sethi Expires November 5, 2021 [Page 19]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
encrypted TLS record with application data 0x00, the EAP-TLS server
may only send an EAP-Success. The EAP-TLS server MUST NOT send an
encrypted TLS record with application data 0x00 alert before it has
successfully processed the client finished and sent its last
handshake message.
TLS Error alerts SHOULD be considered a failure result indication, as
defined in [RFC3748]. Implementations following [RFC4137] sets the
alternate indication of failure variable altReject after sending or
receiving an error alert. After sending or receiving a TLS Error
alert, the EAP-TLS server may only send an EAP-Failure. Protected
TLS Error alerts are protected failure result indications,
unprotected TLS Error alerts are not.
The keying material can be derived after the TLS server Finished has
been sent or received. Implementations following [RFC4137] can then
set the eapKeyData and aaaEapKeyData variables.
The keying material can be made available to lower layers and the
authenticator after the authenticated success result indication has
been sent or received. Implementations following [RFC4137] can set
the eapKeyAvailable and aaaEapKeyAvailable variables.
3. Detailed Description of the EAP-TLS Protocol
No updates to Section 3 of [RFC5216].
4. IANA considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the EAP-
TLS 1.3 protocol in accordance with [RFC8126].
This document requires IANA to add the following labels to the TLS
Exporter Label Registry defined by [RFC5705]. These labels are used
in derivation of Key_Material, IV and Method-Id as defined in
Section 2.3:
Mattsson & Sethi Expires November 5, 2021 [Page 20]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
+----------------------------+---------+-------------+------+
| Value | DTLS-OK | Recommended | Note |
+----------------------------+---------+-------------+------+
| EXPORTER_EAP_TLS_MSK | N | Y | |
| | | | |
| EXPORTER_EAP_TLS_EMSK | N | Y | |
| | | | |
| EXPORTER_EAP_TLS_Method-Id | N | Y | |
+----------------------------+---------+-------------+------+
Table 1: TLS Exporter Label Registry
5. Security Considerations
5.1. Security Claims
Using EAP-TLS with TLS 1.3 does not change the security claims for
EAP-TLS as given in Section 5.1 of [RFC5216]. However, it
strengthens several of the claims as described in the following
updates to the notes given in Section 5.1 of [RFC5216].
[1] Mutual authentication: By mandating revocation checking of
certificates, the authentication in EAP-TLS with TLS 1.3 is stronger
as authentication with revoked certificates will always fail.
[2] Confidentiality: The TLS 1.3 handshake offers much better
confidentiality than earlier versions of TLS. EAP-TLS with TLS 1.3
mandates use of cipher suites that ensure confidentiality. TLS 1.3
also encrypts certificates and some of the extensions. When using
EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not
cause any additional round-trips.
[3] Cryptographic strength: TLS 1.3 only defines strong algorithms
without major weaknesses and EAP-TLS with TLS 1.3 always provides
forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC
mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated.
[4] Cryptographic Negotiation: TLS 1.3 increases the number of
cryptographic parameters that are negotiated in the handshake. When
EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic
negotiation of AEAD algorithm, HKDF hash algorithm, key exchange
groups, and signature algorithm, see Section 4.1.1 of [RFC8446].
5.2. Peer and Server Identities
No updates to section 5.2 of [RFC5216].
Mattsson & Sethi Expires November 5, 2021 [Page 21]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
5.3. Certificate Validation
No updates to section 5.3 of [RFC5216].
5.4. Certificate Revocation
This section updates Section 5.4 of [RFC5216].
While certificates may have long validity periods, there are a number
of reasons (e.g., key compromise, CA compromise, privilege withdrawn,
etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have
to be revoked before their expiry date. Revocation of the EAP-TLS
server's certificate is complicated by the fact that the EAP-TLS peer
may not have Internet connectivity until authentication completes.
When EAP-TLS is used with TLS 1.3, the revocation status of all the
certificates in the certificate chains MUST be checked (except the
trust anchor). An implementation may use Certificate Revocation List
(CRL), Online Certificate Status Protocol (OSCP), or other
standardized/proprietary methods for revocation checking. Examples
of proprietary methods are non-standard formats for distribution of
revocation lists as well as certificates with very short lifetime.
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
Requests (OCSP stapling) as specified in [RFC6066] and
Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers
and EAP-TLS servers use OCSP stapling for verifying the status of the
EAP-TLS server's certificate chain. When an EAP-TLS peer uses
Certificate Status Requests to check the revocation status of the
EAP-TLS server's certificate chain it MUST treat a CertificateEntry
(except the trust anchor) without a valid CertificateStatus extension
as invalid and abort the handshake with an appropriate alert. The
OCSP status handling in TLS 1.3 is different from earlier versions of
TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP
information is carried in the CertificateEntry containing the
associated certificate instead of a separate CertificateStatus
message as in [RFC6066]. This enables sending OCSP information for
all certificates in the certificate chain (except the trust anchor).
To enable revocation checking in situations where EAP-TLS peers do
not implement or use OCSP stapling, and where network connectivity is
not available prior to authentication completion, EAP-TLS peer
implementations MUST also support checking for certificate revocation
after authentication completes and network connectivity is available.
An EAP peer implementation SHOULD NOT trust the network (and any
services) until it has verified the revocation status of the server
certificate after receiving network connectivity. An EAP peer MUST
use a secure transport to verify the revocation status of the server
Mattsson & Sethi Expires November 5, 2021 [Page 22]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
certificate. An EAP peer SHOULD NOT send any other traffic before
revocation checking for the server certificate is complete.
5.5. Packet Modification Attacks
This section updates Section 5.5 of [RFC5216].
As described in [RFC3748] and Section 5.5 of [RFC5216], the only
information that is integrity and replay protected in EAP-TLS are the
parts of the TLS Data that TLS protects. All other information in
the EAP-TLS message exchange including EAP-Request and EAP-Response
headers, the identity in the identity response, EAP-TLS packet header
fields, Type, and Flags, EAP-Success, and EAP-Failure can be
modified, spoofed, or replayed.
Protected TLS Error alerts are protected failure result indications
and enables the EAP-TLS peer and EAP-TLS server to determine that the
failure result was not spoofed by an attacker. Protected failure
result indications provide integrity and replay protection but MAY be
unauthenticated. Protected failure results do not significantly
improve availability as TLS 1.3 treats most malformed data as a fatal
error.
5.6. Authorization
This is a new section when compared to [RFC5216]. The guidance in
this section is relevant for EAP-TLS in general (regardless of the
underlying TLS version used).
EAP servers will usually require the EAP peer to provide a valid
certificate and will fail the connection if one is not provided.
Some deployments may permit no peer authentication for some or all
connections. When peer authentication is not used, implementations
MUST take care to limit network access appropriately for
unauthenticated peers and implementations MUST use resumption with
caution to ensure that a resumed session is not granted more
privilege than was intended for the original session.
EAP-TLS is typically encapsulated in other protocols, such as PPP
[RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191].
The encapsulating protocols can also provide additional, non-EAP
information to an EAP-TLS server. This information can include, but
is not limited to, information about the authenticator, information
about the EAP-TLS peer, or information about the protocol layers
above or below EAP (MAC addresses, IP addresses, port numbers, WiFi
SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those
protocols can make policy decisions and enforce authorization based
Mattsson & Sethi Expires November 5, 2021 [Page 23]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
on a combination of information from the EAP-TLS exchange and non-EAP
information.
As noted in Section 2.2, the identity presented in EAP-Response/
Identity is not authenticated by EAP-TLS and is therefore trivial for
an attacker to forge, modify, or replay. Authorization and
accounting MUST be based on authenticated information such as
information in the certificate or the PSK identity and cached data
provisioned for resumption as described in Section 5.7. Note that
the requirements for Network Access Identifiers (NAIs) specified in
Section 4 of [RFC7542] still apply and MUST be followed.
EAP-TLS servers MAY reject conversations based on non-EAP information
provided by the encapsulating protocol, for example, if the MAC
address of the authenticator does not match the expected policy.
5.7. Resumption
This is a new section when compared to [RFC5216]. The guidance in
this section is relevant for EAP-TLS in general (regardless of the
underlying TLS version used).
There are a number of security issues related to resumption that are
not described in [RFC5216]. The problems, guidelines, and
requirements in this section therefore applies to all version of TLS.
When resumption occurs, it is based on cached information at the TLS
layer. To perform resumption in a secure way, the EAP-TLS peer and
EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full
handshake. We use the term "cached data" to describe such
information. Authorization during resumption MUST be based on such
cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh
revocation checks on the cached certificate data. Any security
policies for authorization MUST be followed also for resumption. The
certificates may have been revoked since the initial full handshake
and the authorizations of the other party may have reduced. If the
cached revocation data is not sufficiently current, the EAP-TLS peer
or EAP-TLS server MAY force a full TLS handshake.
There are two ways to retrieve the cached data from the original full
handshake. The first method is that the EAP-TLS server and client
cache the information locally. The cached information is identified
by an identifier. For TLS versions before 1.3, the identifier can be
the session ID, for TLS 1.3, the identifier is the PSK identity. The
second method for retrieving cached information is via [RFC5077] or
[RFC8446], where the EAP-TLS server avoids storing information
locally and instead encapsulates the information into a ticket or PSK
Mattsson & Sethi Expires November 5, 2021 [Page 24]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
which is sent to the client for storage. This ticket or PSK is
encrypted using a key that only the EAP-TLS server knows. Note that
the client still needs to cache the original handshake information
locally and will use the session ID or PSK identity to lookup this
information during resumption. However, the EAP-TLS server is able
to decrypt the ticket or PSK to obtain the original handshake
information.
If the EAP-TLS server or EAP client do not apply any authorization
policies, they MAY allow resumption where no cached data is
available. In all other cases, they MUST cache data during the
initial full handshake to enable resumption. The cached data MUST be
sufficient to make authorization decisions during resumption. If
cached data cannot be retrieved in a secure way, resumption MUST NOT
be done.
The above requirements also apply if the EAP-TLS server expects some
system to perform accounting for the session. Since accounting must
be tied to an authenticated identity, and resumption does not supply
such an identity, accounting is impossible without access to cached
data. Therefore systems which expect to perform accounting for the
session SHOULD cache an identifier which can be used in subsequent
accounting.
As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption
PSKs or tickets (and associated cached data) for longer than 7 days,
regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY
delete them earlier based on local policy. The cached data MAY also
be removed on the EAP-TLS server or EAP-TLS peer if any certificate
in the certificate chain has been revoked or has expired. In all
such cases, an attempt at resumption results in a full TLS handshake
instead.
Information from the EAP-TLS exchange (e.g., the identity provided in
EAP-Response/Identity) as well as non-EAP information (e.g., IP
addresses) may change between the initial full handshake and
resumption. This change creates a "time-of-check time-of-use"
(TOCTOU) security vulnerability. A malicious or compromised user
could supply one set of data during the initial authentication, and a
different set of data during resumption, potentially allowing them to
obtain access that they should not have.
If any authorization, accounting, or policy decisions were made with
information that has changed between the initial full handshake and
resumption, and if change may lead to a different decision, such
decisions MUST be reevaluated. It is RECOMMENDED that authorization,
accounting, and policy decisions are reevaluated based on the
information given in the resumption. EAP-TLS servers MAY reject
Mattsson & Sethi Expires November 5, 2021 [Page 25]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
resumption where the information supplied during resumption does not
match the information supplied during the original authentication.
If a safe decision is not possible, EAP-TLS servers SHOULD reject the
resumption and continue with a full handshake.
Section 2.2 and 4.2.11 of [RFC8446] provides security considerations
for TLS 1.3 resumption.
5.8. Privacy Considerations
This is a new section when compared to [RFC5216].
TLS 1.3 offers much better privacy than earlier versions of TLS as
discussed in Section 2.1.8. In this section, we only discuss the
privacy properties of EAP-TLS with TLS 1.3. For privacy properties
of TLS 1.3 itself, see [RFC8446].
EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in
EAP packets. Additionally, the EAP-TLS peer sends an identity in the
first EAP-Response. The other fields in the EAP-TLS Request and the
EAP-TLS Response packets do not contain any cleartext privacy
sensitive information.
Tracking of users by eavesdropping on identity responses or
certificates is a well-known problem in many EAP methods. When EAP-
TLS is used with TLS 1.3, all certificates are encrypted, and the
username part of the identity response is not revealed (e.g., using
anonymous NAIs). Note that even though all certificates are
encrypted, the server's identity is only protected against passive
attackers while client's identity is protected against both passive
and active attackers. As with other EAP methods, even when privacy-
friendly identifiers or EAP tunneling is used, the domain name (i.e.,
the realm) in the NAI is still typically visible. How much privacy
sensitive information the domain name leaks is highly dependent on
how many other users are using the same domain name in the particular
access network. If all EAP-TLS peers have the same domain, no
additional information is leaked. If a domain name is used by a
small subset of the EAP-TLS peers, it may aid an attacker in tracking
or identifying the user.
Without padding, information about the size of the client certificate
is leaked from the size of the EAP-TLS packets. The EAP-TLS packets
sizes may therefore leak information that can be used to track or
identify the user. If all client certificates have the same length,
no information is leaked. EAP-TLS peers SHOULD use record padding,
see Section 5.4 of [RFC8446] to reduce information leakage of
certificate sizes.
Mattsson & Sethi Expires November 5, 2021 [Page 26]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
If anonymous NAIs are not used, the privacy-friendly identifiers need
to be generated with care. The identities MUST be generated in a
cryptographically secure way so that that it is computationally
infeasible for an attacker to differentiate two identities belonging
to the same user from two identities belonging to different users in
the same realm. This can be achieved, for instance, by using random
or pseudo-random usernames such as random byte strings or ciphertexts
and only using the pseudo-random usernames a single time. Note that
the privacy-friendly usernames also MUST NOT include substrings that
can be used to relate the identity to a specific user. Similarly,
privacy-friendly username MUST NOT be formed by a fixed mapping that
stays the same across multiple different authentications.
An EAP-TLS peer with a policy allowing communication with EAP-TLS
servers supporting only TLS 1.2 without privacy and with a static RSA
key exchange is vulnerable to disclosure of the EAP-TLS peer
username. An active attacker can in this case make the EAP-TLS peer
believe that an EAP-TLS server supporting TLS 1.3 only supports TLS
1.2 without privacy. The attacker can simply impersonate the EAP-TLS
server and negotiate TLS 1.2 with static RSA key exchange and send an
TLS alert message when the EAP-TLS peer tries to use privacy by
sending an empty certificate message. Since the attacker
(impersonating the EAP-TLS server) does not provide a proof-of-
possession of the private key until the Finished message when a
static RSA key exchange is used, an EAP-TLS peer may inadvertently
disclose its identity (username) to an attacker. Therefore, it is
RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and
static RSA based cipher suites without privacy. This implies that an
EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
server sends an EAP-TLS/Request with a TLS alert message in response
to an empty certificate message from the peer.
5.9. Pervasive Monitoring
This is a new section when compared to [RFC5216].
Pervasive monitoring refers to widespread surveillance of users. In
the context of EAP-TLS, pervasive monitoring attacks can target EAP-
TLS peer devices for tracking them (and their users) as and when they
join a network. By encrypting more information, mandating the use of
privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3
offers much better protection against pervasive monitoring. In
addition to the privacy attacks discussed above, surveillance on a
large scale may enable tracking of a user over a wide geographical
area and across different access networks. Using information from
EAP-TLS together with information gathered from other protocols
increases the risk of identifying individual users.
Mattsson & Sethi Expires November 5, 2021 [Page 27]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
5.10. Discovered Vulnerabilities
This is a new section when compared to [RFC5216].
Over the years, there have been several serious attacks on earlier
versions of Transport Layer Security (TLS), including attacks on its
most commonly used ciphers and modes of operation. [RFC7457]
summarizes the attacks that were known at the time of publishing and
BCP 195 [RFC7525] provides recommendations for improving the security
of deployed services that use TLS. However, many of the attacks are
less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and
does not protect any application data. EAP-TLS implementations MUST
mitigate known attacks. EAP-TLS implementations need to monitor and
follow new EAP and TLS related security guidance and requirements
such as [RFC8447], [RFC8996], [I-D.ietf-tls-md5-sha1-deprecate].
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
Mattsson & Sethi Expires November 5, 2021 [Page 28]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
6.2. Informative references
[I-D.ietf-emu-eaptlscert]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large
Certificates and Long Certificate Chains in TLS-based EAP
Methods", draft-ietf-emu-eaptlscert-08 (work in progress),
November 2020.
[I-D.ietf-emu-tls-eap-types]
DeKok, A., "TLS-based EAP types and TLS 1.3", draft-ietf-
emu-tls-eap-types-02 (work in progress), February 2021.
[I-D.ietf-tls-md5-sha1-deprecate]
Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf-
tls-md5-sha1-deprecate-06 (work in progress), March 2021.
[I-D.ietf-tls-ticketrequests]
Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket
Requests", draft-ietf-tls-ticketrequests-07 (work in
progress), December 2020.
Mattsson & Sethi Expires November 5, 2021 [Page 29]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
[IEEE-802.11]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information technology--Telecommunications
and information exchange between systems Local and
metropolitan area networks--Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Std 802.11-2016
(Revision of IEEE Std 802.11-2012) , December 2016.
[IEEE-802.1AE]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Media
Access Control (MAC) Security", IEEE Standard
802.1AE-2018 , December 2018.
[IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Port-
Based Network Access Control", IEEE Standard 802.1X-2020 ,
January 2020.
[MulteFire]
MulteFire, "MulteFire Release 1.1 specification", 2019.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", 2018.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<https://www.rfc-editor.org/info/rfc1661>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999,
<https://www.rfc-editor.org/info/rfc2246>.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560,
DOI 10.17487/RFC2560, June 1999,
<https://www.rfc-editor.org/info/rfc2560>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
Mattsson & Sethi Expires November 5, 2021 [Page 30]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
DOI 10.17487/RFC3280, April 2002,
<https://www.rfc-editor.org/info/rfc3280>.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137,
DOI 10.17487/RFC4137, August 2005,
<https://www.rfc-editor.org/info/rfc4137>.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282,
DOI 10.17487/RFC4282, December 2005,
<https://www.rfc-editor.org/info/rfc4282>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006,
<https://www.rfc-editor.org/info/rfc4346>.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
DOI 10.17487/RFC4851, May 2007,
<https://www.rfc-editor.org/info/rfc4851>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>.
Mattsson & Sethi Expires November 5, 2021 [Page 31]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
DOI 10.17487/RFC5281, August 2008,
<https://www.rfc-editor.org/info/rfc5281>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>.
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.
[RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H.,
and D. Kroeselberg, "Extensions to the Emergency Services
Architecture for Dealing With Unauthenticated and
Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406,
December 2014, <https://www.rfc-editor.org/info/rfc7406>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Architecture for Network Roaming", RFC 7593,
DOI 10.17487/RFC7593, September 2015,
<https://www.rfc-editor.org/info/rfc7593>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>.
[TS.33.501]
3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501 17.0.0, December 2020.
Mattsson & Sethi Expires November 5, 2021 [Page 32]
Internet-Draft EAP-TLS with TLS 1.3 May 2021
Appendix A. Updated references
All the following references in [RFC5216] are updated as specified
below when EAP-TLS is used with TLS 1.3.
All references to [RFC2560] are updated with [RFC6960].
All references to [RFC3280] are updated with [RFC5280].
All references to [RFC4282] are updated with [RFC7542].
Acknowledgments
The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton,
Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar,
Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa
Torvinen, and Hannes Tschofenig for comments and suggestions on the
draft.
Contributors
Alan DeKok, FreeRADIUS
Authors' Addresses
John Preuss Mattsson
Ericsson
Stockholm 164 40
Sweden
Email: john.mattsson@ericsson.com
Mohit Sethi
Ericsson
Jorvas 02420
Finland
Email: mohit@piuha.net
Mattsson & Sethi Expires November 5, 2021 [Page 33]