draft-ietf-emu-eap-tls13-13.txt   draft-ietf-emu-eap-tls13-14.txt 
Network Working Group J. Mattsson Network Working Group J. Mattsson
Internet-Draft M. Sethi Internet-Draft M. Sethi
Updates: 5216 (if approved) Ericsson Updates: 5216 (if approved) Ericsson
Intended status: Standards Track November 19, 2020 Intended status: Standards Track February 2, 2021
Expires: May 23, 2021 Expires: August 6, 2021
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-13 draft-ietf-emu-eap-tls13-14
Abstract Abstract
This document specifies the use of EAP-TLS with TLS 1.3 while The Extensible Authentication Protocol (EAP), defined in RFC 3748,
remaining backwards compatible with existing implementations of EAP- provides a standard mechanism for support of multiple authentication
TLS. TLS 1.3 provides significantly improved security, privacy, and methods. This document specifies the use of EAP-Transport Layer
reduced latency when compared to earlier versions of TLS. EAP-TLS Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
with TLS 1.3 further improves security and privacy by mandating use with existing implementations of EAP-TLS. TLS 1.3 provides
of privacy and revocation checking. This document also provides significantly improved security, privacy, and reduced latency when
guidance on authorization and resumption for EAP-TLS in general compared to earlier versions of TLS. EAP-TLS with TLS 1.3 further
(regardless of the underlying TLS version used). This document improves security and privacy by always providing forward secrecy,
updates RFC 5216. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 23, 2021. This Internet-Draft will expire on August 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements and Terminology . . . . . . . . . . . . . . 4 1.1. Requirements and Terminology . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4
2.1.1. Mutual Authentication . . . . . . . . . . . . . . . . 4 2.1.1. Mutual Authentication . . . . . . . . . . . . . . . . 4
2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 5 2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 6
2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 6 2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 8 2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 10
2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 11 2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 14
2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 12 2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 15
2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 13 2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 16
2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 14 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 17
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 15 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 18
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18
2.4. Parameter Negotiation and Compliance Requirements . . . . 16 2.4. Parameter Negotiation and Compliance Requirements . . . . 19
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 17 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 20
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 18 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 20
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 19 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 21
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 19 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 22
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 20 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 22
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 20 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 22
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 20 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 23
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 21 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 23
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 21 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 23
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 23 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 25
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 25 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 27
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 25 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 27
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Normative References . . . . . . . . . . . . . . . . . . 25 6.1. Normative References . . . . . . . . . . . . . . . . . . 27
6.2. Informative references . . . . . . . . . . . . . . . . . 26 6.2. Informative references . . . . . . . . . . . . . . . . . 29
Appendix A. Updated references . . . . . . . . . . . . . . . . . 30 Appendix A. Updated references . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
provides a standard mechanism for support of multiple authentication provides a standard mechanism for support of multiple authentication
methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies
an EAP authentication method with certificate-based mutual an EAP authentication method with certificate-based mutual
authentication utilizing the TLS handshake protocol for cryptographic authentication utilizing the TLS handshake protocol for cryptographic
algorithms and protocol version negotiation, mutual authentication, algorithms and protocol version negotiation, mutual authentication,
and establishment of shared secret keying material. EAP-TLS is and establishment of shared secret keying material. EAP-TLS is
widely supported for authentication and and key establishment in IEEE widely supported for authentication and key establishment in IEEE
802.11 [IEEE-802.11] (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec) 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 networks using IEEE 802.1X [IEEE-802.1X] and it's the default
mechanism for certificate based authentication in 3GPP 5G [TS.33.501] mechanism for certificate based authentication in 3GPP 5G [TS.33.501]
and MulteFire [MulteFire] networks. Many other EAP methods such as and MulteFire [MulteFire] networks. Many other EAP methods such as
EAP-FAST [RFC4851], EAP-TTLS [RFC5281], TEAP [RFC7170], and PEAP EAP-FAST [RFC4851], EAP-TTLS [RFC5281], TEAP [RFC7170], and PEAP
[PEAP] depend on TLS and EAP-TLS. [PEAP] depend on TLS and EAP-TLS.
EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346], 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 but can also work with TLS 1.2 [RFC5246]. TLS 1.0 and 1.1 are
formally deprecated and prohibited to negotiate and use formally deprecated and prohibited to negotiate and use
skipping to change at page 3, line 39 skipping to change at page 3, line 40
remodeling of the TLS handshake protocol including a different remodeling of the TLS handshake protocol including a different
message flow, different handshake messages, different key schedule, message flow, different handshake messages, different key schedule,
different cipher suites, different resumption, different privacy different cipher suites, different resumption, different privacy
protection, and record padding. This means that significant parts of protection, and record padding. This means that significant parts of
the normative text in the previous EAP-TLS specification [RFC5216] the normative text in the previous EAP-TLS specification [RFC5216]
are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore,
aspects such as resumption, privacy handling, and key derivation need aspects such as resumption, privacy handling, and key derivation need
to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher).
This document defines how to use EAP-TLS with TLS 1.3 (or higher) and This document defines how to use EAP-TLS with TLS 1.3 (or higher) and
does not change how EAP-TLS is used with older versions of TLS. We does not change how EAP-TLS is used with older versions of TLS. It
do however provide additional guidance on authorization and does however provide additional guidance on authorization and
resumption for EAP-TLS in general (regardless of the underlying TLS resumption for EAP-TLS in general (regardless of the underlying TLS
version used). While this document updates EAP-TLS [RFC5216], it version used). While this document updates EAP-TLS [RFC5216], it
remains backwards compatible with it and existing implementations of remains backwards compatible with it and existing implementations of
EAP-TLS. This document only describes differences compared to EAP-TLS. This document only describes differences compared to
[RFC5216]. [RFC5216]. All message flow are specific to TLS 1.3 and do not apply
to TLS 1.2.
In addition to the improved security and privacy offered by TLS 1.3, 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. there are other significant benefits of using EAP-TLS with TLS 1.3.
Privacy is mandatory and achieved without any additional round-trips, Privacy, which in EAP-TLS means that the peer username is not
revocation checking is mandatory and simplified with OCSP stapling, disclosed, is mandatory and achieved without any additional round-
and TLS 1.3 introduces more possibilities to reduce fragmentation trips. Revocation checking is mandatory and simplified with OCSP
when compared to earlier versions of TLS. stapling, and TLS 1.3 introduces more possibilities to reduce
fragmentation when compared to earlier versions of TLS.
1.1. Requirements and Terminology 1.1. Requirements and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts used Readers are expected to be familiar with the terms and concepts used
skipping to change at page 4, line 46 skipping to change at page 4, line 50
processing compared to [RFC8446] and [RFC5216]. processing compared to [RFC8446] and [RFC5216].
2.1.1. Mutual Authentication 2.1.1. Mutual Authentication
This section updates Section 2.1.1 of [RFC5216]. This section updates Section 2.1.1 of [RFC5216].
The EAP-TLS server MUST authenticate with a certificate and SHOULD The EAP-TLS server MUST authenticate with a certificate and SHOULD
require the EAP-TLS peer to authenticate with a certificate. require the EAP-TLS peer to authenticate with a certificate.
Certificates can be of any type supported by TLS including raw public Certificates can be of any type supported by TLS including raw public
keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except
for resumption. SessionID is deprecated in TLS 1.3 and the EAP-TLS for resumption. The full handshake in EAP-TLS with TLS 1.3 always
server SHALL ignore the legacy_session_id field if TLS 1.3 is provide forward secrecy by exchange of ephemeral "key_share"
negotiated. TLS 1.3 introduced early application data which is not extentions in the ClientHello and ServerHello (e.g. containing
used in EAP-TLS. A EAP-TLS server which receives an "early_data" ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3,
extension MUST ignore the extension or respond with a see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early
HelloRetryRequest as described in Section 4.2.10 of [RFC8446]. application data which like all other application data is not used in
Resumption is handled as described in Section 2.1.3. The EAP-TLS EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information
server commits to not send any more handshake messages by sending a of the "early_data" extension. Resumption is handled as described in
Commitment Message (an encrypted TLS record with the application data Section 2.1.3. TLS 1.3 introduced the Post-Handshake KeyUpdate
0x00), see Section 2.5. After the EAP-TLS server has recieved a EAP- message which is not useful and not expected in EAP-TLS. The EAP-TLS
Response to the EAP-Request containing the Commitment Message, the server always commits to not send any more handshake messages by
EAP-TLS server sends EAP-Success. sending a TLS close_notify alert. After the EAP-TLS server has
received an empty EAP-Response to the EAP-Request containing the TLS
close_notify alert, the EAP-TLS server sends EAP-Success.
In the case where EAP-TLS with mutual authentication is successful In the case where EAP-TLS with mutual authentication is successful
(and neither HelloRetryRequest nor Post-Handshake messages are sent) (and neither HelloRetryRequest nor Post-Handshake messages are sent)
the conversation will appear as shown in Figure 1. the conversation will appear as shown in Figure 1.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
skipping to change at page 5, line 33 skipping to change at page 6, line 24
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, <-------- TLS Finished)
<-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS close_notify)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 1: EAP-TLS mutual authentication Figure 1: EAP-TLS mutual authentication
2.1.2. Ticket Establishment 2.1.2. Ticket Establishment
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS
server MUST send a NewSessionTicket message (containing a PSK and server MUST send one or more NewSessionTicket messages (each
other parameters) in the initial authentication. The containing a PSK, a PSK identity, a ticket lifetime, and other
NewSessionTicket is sent after the EAP-TLS server has received the parameters) in the initial authentication. Note that TLS 1.3
Finished message in the initial authentication. The NewSessionTicket [RFC8446] limits the ticket lifetime to a maximum of 604800 seconds
message MUST NOT include an "early_data" extension. (7 days) and EAP-TLS servers MUST respect this upper limit when
issuing tickets. The NewSessionTicket is sent after the EAP-TLS
server has received the client Finished message in the initial
authentication. The PSK associated with the ticket depends on the
client Finished and cannot be pre-computed in handshakes with client
authentication. The NewSessionTicket message MUST NOT include an
"early_data" extension. A mechanism by which clients can specify the
desired number of tickets needed for future connections is defined in
[I-D.ietf-tls-ticketrequests].
In the case where EAP-TLS with mutual authentication and ticket In the case where EAP-TLS with mutual authentication and ticket
establishment is successful, the conversation will appear as shown in establishment with two tickets is successful, the conversation will
Figure 2. appear as shown in Figure 2.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
skipping to change at page 6, line 39 skipping to change at page 7, line 41
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished) <-------- TLS Finished)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS NewSessionTicket, (TLS NewSessionTicket,
<-------- Commitment Message) TLS NewSessionTicket,
<-------- TLS close_notify)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 2: EAP-TLS ticket establishment Figure 2: EAP-TLS ticket establishment
2.1.3. Resumption 2.1.3. Resumption
This section updates Section 2.1.2 of [RFC5216]. This section updates Section 2.1.2 of [RFC5216].
skipping to change at page 7, line 14 skipping to change at page 8, line 21
TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism
compatible with that version of TLS. compatible with that version of TLS.
For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 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 the client has received a NewSessionTicket message from the EAP-TLS
server, the client can use the PSK identity received in the ticket to server, the client can use the PSK identity received in the ticket to
negotiate the use of the associated PSK. If the EAP-TLS server negotiate the use of the associated PSK. If the EAP-TLS server
accepts it, then the security context of the new connection is tied accepts it, then the security context of the new connection is tied
to the original connection and the key derived from the initial to the original connection and the key derived from the initial
handshake is used to bootstrap the cryptographic state instead of a handshake is used to bootstrap the cryptographic state instead of a
full handshake. It is left up to the EAP-TLS peer whether to use full handshake. It is up to the EAP-TLS peer whether to offer
resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption, ut it is RECOMMENDED that the EAP-TLS peer offer
resumption as long as the ticket is valid. However, the EAP-TLS resumption if it has a valid ticket that has not been used before.
server MAY choose to require a full authentication. EAP-TLS peers It is left to the EAP-TLS server whether to accept resumption, but it
and EAP-TLS servers SHOULD follow the client tracking preventions in is RECOMMENDED that the EAP-TLS server accept resumption if the
Appendix C.4 of [RFC8446]. ticket that it issued is still valid. However, the EAP-TLS server
MAY choose to require a full handshake. As in a full handshake,
sending a NewSessionTicket is optional. As described in Appendix C.4
of [RFC8446], reuse of a ticket allows passive observers to correlate
different connections. EAP-TLS peers and EAP-TLS servers SHOULD
follow the client tracking preventions in Appendix C.4 of [RFC8446].
It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the
same realm in the resumption and the original full authentication. same realm in the resumption and the original full handshake. This
This requirement allows EAP packets to be routable to the same requirement allows EAP packets to be routable to the same destination
destination as the original full authentication. If this as the original full handshake. If this recommendation is not
recommendation is not followed, resumption is likely to be followed, resumption is likely to be impossible. When NAI reuse can
impossible. When NAI reuse can be done without privacy implications, be done without privacy implications, it is RECOMMENDED to use the
it is RECOMMENDED to use the same anonymous NAI in the resumption, as same anonymous NAI in the resumption, as was used in the original
was used in the original full authentication. E.g. the NAI @realm full handshake [RFC7542]. For example, the NAI @realm can safely be
can safely be reused, while the NAI ZmxleG8=@realm cannot. The TLS reused since it does not provide any specific information to
PSK identity is typically derived by the TLS implementation and may associate a user's resumption attempt with the original full
be an opaque blob without a routable realm. The TLS PSK identity is handshake. However, reusing the NAI
therefore in general unsuitable for deriving a NAI to use in the P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path attacker to
associate a resumption attempt with the original full handshake. The
TLS PSK identity is typically derived by the TLS implementation and
may be an opaque blob without a routable realm. The TLS PSK identity
is therefore in general unsuitable for deriving a NAI to use in the
Identity Response. Identity Response.
A subsequent authentication using resumption, where both sides A subsequent successful resumption handshake where both sides
authenticate successfully (without the issuance of more resumption authenticate via a PSK provisioned via an earlier NewSessionTicket
tickets) is shown in Figure 3. and where the server provisions a single new ticket is shown in
Figure 3.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS Finished, <-------- TLS Finished)
<-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS NewSessionTicket,
<-------- TLS close_notify)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 3: EAP-TLS resumption Figure 3: EAP-TLS resumption
A subsequent successful resumption handshake where both sides
authenticate via a PSK provisioned via an earlier NewSessionTicket
and where the server does not provision any new tickets is shown in
Figure 4.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS close_notify)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 4: EAP-TLS resumption
As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD
supply a "key_share" extension when attempting resumption, which supply a "key_share" extension when attempting resumption, which
allows the EAP-TLS server to potentially decline resumption and fall 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 back to a full handshake. If the EAP-TLS peer did not supply a
"key_share" extension when attempting resumption, the EAP-TLS server "key_share" extension when attempting resumption, the EAP-TLS server
needs to reject the ClientHello and the EAP-TLS peer needs to restart needs to send HelloRetryRequest to signal that additional information
a full handshake. The message flow in this case is given by Figure 4 is needed to complete the handshake, and the EAP-TLS peer needs to
followed by Figure 1. send a second ClientHello containing that information. Providing a
"key_share" and using the "psk_dhe_ke" pre-shared key exchange mode
Also during resumption, the EAP-TLS server can respond with a Hello is also important in order to limit the impact of a key compromise.
Retry Request (see Section 2.1.6) or issue a new ticket (see When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning
Section 2.1.2) that key leakage does not compromise any earlier connections. It is
RECOMMMENDED to use "psk_dhe_ke" for resumption.
2.1.4. Termination 2.1.4. Termination
This section updates Section 2.1.3 of [RFC5216]. This section updates Section 2.1.3 of [RFC5216].
TLS 1.3 changes both the message flow and the handshake messages TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS. Therefore, some normative text compared to earlier versions of TLS. Therefore, some normative text
in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3 or higher. in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3 or higher.
The two paragraphs below replaces the corresponding paragraphs in The two paragraphs below replaces the corresponding paragraphs in
Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or
skipping to change at page 9, line 16 skipping to change at page 11, line 22
If the EAP-TLS peer authenticates successfully, the EAP-TLS server If the EAP-TLS peer authenticates successfully, the EAP-TLS server
MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing
TLS records conforming to the version of TLS used. The message TLS records conforming to the version of TLS used. The message
flow ends with the EAP-TLS server sending an EAP-Success message. flow ends with the EAP-TLS server sending an EAP-Success message.
If the EAP-TLS server authenticates successfully, the EAP-TLS peer If the EAP-TLS server authenticates successfully, the EAP-TLS peer
MUST send an EAP-Response message with EAP-Type=EAP-TLS containing MUST send an EAP-Response message with EAP-Type=EAP-TLS containing
TLS records conforming to the version of TLS used. TLS records conforming to the version of TLS used.
Figures 4, 5, and 6 illustrate message flows in several cases where Figures 5, 6, and 7 illustrate message flows in several cases where
the EAP-TLS peer or EAP-TLS server sends a TLS fatal alert message. the EAP-TLS peer or EAP-TLS server sends a TLS fatal alert message.
TLS warning alerts generally mean that the connection can continue In earlier versions of TLS, error alerts could be warnings or fatal.
normally and does not change the message flow. Note that the party In TLS 1.3, error alerts are always fatal and the only alerts sent at
receiving a TLS warning alert may choose to terminate the connection warning level are "close_notify" and "user_cancelled", both of which
by sending a TLS fatal alert, which may add an extra round-trip, see indicate that the connection is not going to continue normally, see
[RFC8446]. [RFC8446].
In the case where the EAP-TLS server rejects the ClientHello with a In the case where the EAP-TLS server rejects the ClientHello with a
fatal error, the conversation will appear as shown in Figure 4. The fatal error, the conversation will appear as shown in Figure 5. The
EAP-TLS server can also partly reject the ClientHello with a EAP-TLS server can also partly reject the ClientHello with a
HelloRetryRequest, see Section 2.1.6. HelloRetryRequest, see Section 2.1.6.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
skipping to change at page 9, line 48 skipping to change at page 12, line 24
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Fatal Alert) <-------- (TLS Fatal Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 4: EAP-TLS server rejection of ClientHello Figure 5: EAP-TLS server rejection of ClientHello
In the case where EAP-TLS server authentication is unsuccessful, the In the case where EAP-TLS server authentication is unsuccessful, the
conversation will appear as shown in Figure 5. conversation will appear as shown in Figure 6.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, <-------- TLS Finished)
<-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Fatal Alert) (TLS Fatal Alert)
--------> -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 5: EAP-TLS unsuccessful EAP-TLS server authentication Figure 6: EAP-TLS unsuccessful EAP-TLS server authentication
In the case where the EAP-TLS server authenticates to the EAP-TLS In the case where the EAP-TLS server authenticates to the EAP-TLS
peer successfully, but the EAP-TLS peer fails to authenticate to the peer successfully, but the EAP-TLS peer fails to authenticate to the
EAP-TLS server, the conversation will appear as shown in Figure 6. EAP-TLS server, the conversation will appear as shown in Figure 7.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
skipping to change at page 11, line 25 skipping to change at page 14, line 25
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, <-------- TLS Finished)
<-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Fatal Alert) <-------- (TLS Fatal Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 6: EAP-TLS unsuccessful client authentication Figure 7: EAP-TLS unsuccessful client authentication
2.1.5. No Peer Authentication 2.1.5. No Peer Authentication
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
In the case where EAP-TLS is used without peer authentication (e.g., In the case where EAP-TLS is used without peer authentication (e.g.,
emergency services, as described in [RFC7406]) the conversation will emergency services, as described in [RFC7406]) the conversation will
appear as shown in Figure 7. appear as shown in Figure 8.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, <-------- TLS Finished)
<-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS close_notify)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 7: EAP-TLS without peer authentication Figure 8: EAP-TLS without peer authentication
2.1.6. Hello Retry Request 2.1.6. Hello Retry Request
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a
HelloRetryRequest message in response to a ClientHello if the EAP-TLS HelloRetryRequest message in response to a ClientHello if the EAP-TLS
server finds an acceptable set of parameters but the initial server finds an acceptable set of parameters but the initial
ClientHello does not contain all the needed information to continue ClientHello does not contain all the needed information to continue
the handshake. One use case is if the EAP-TLS server does not the handshake. One use case is if the EAP-TLS server does not
support the groups in the "key_share" extension, but supports one of support the groups in the "key_share" extension (or there is no
the groups in the "supported_groups" extension. In this case the "key_share" extension), but supports one of the groups in the
client should send a new ClientHello with a "key_share" that the EAP- "supported_groups" extension. In this case the client should send a
TLS server supports. new ClientHello with a "key_share" that the EAP-TLS server supports.
The case of a successful EAP-TLS mutual authentication after the EAP- The case of a successful EAP-TLS mutual authentication after the EAP-
TLS server has sent a HelloRetryRequest message is shown in Figure 8. TLS server has sent a HelloRetryRequest message is shown in Figure 9.
Note the extra round-trip as a result of the HelloRetryRequest. Note the extra round-trip as a result of the HelloRetryRequest.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
skipping to change at page 13, line 28 skipping to change at page 16, line 28
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS HelloRetryRequest) (TLS HelloRetryRequest)
<-------- <--------
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished)
<-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS close_notify)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 8: EAP-TLS with Hello Retry Request Figure 9: EAP-TLS with Hello Retry Request
2.1.7. Identity 2.1.7. Identity
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity
Response as such identities are routable and privacy-friendly. While Response as such identities are routable and privacy-friendly. While
opaque blobs are allowed by [RFC3748], such identities are NOT opaque blobs are allowed by [RFC3748], such identities are NOT
RECOMMENDED as they are not routable and should only be considered in RECOMMENDED as they are not routable and should only be considered in
local deployments where the EAP-TLS peer, EAP authenticator, and EAP- local deployments where the EAP-TLS peer, EAP authenticator, and EAP-
TLS server all belong to the same network. Many client certificates TLS server all belong to the same network. Many client certificates
contains an identity such as an email address, which is already in contain an identity such as an email address, which is already in NAI
NAI format. When the client certificate contains a NAI as subject format. When the client certificate contains a NAI as subject name
name or alternative subject name, an anonymous NAI SHOULD be derived or alternative subject name, an anonymous NAI SHOULD be derived from
from the NAI in the certificate, see Section 2.1.8. More details on 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. identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8.
2.1.8. Privacy 2.1.8. Privacy
This section updates Section 2.1.4 of [RFC5216]. This section updates Section 2.1.4 of [RFC5216].
TLS 1.3 significantly improves privacy when compared to earlier TLS 1.3 significantly improves privacy when compared to earlier
versions of TLS by forbidding cipher suites without confidentiality versions of TLS by forbidding cipher suites without confidentiality
and encrypting large parts of the TLS handshake including the and encrypting large parts of the TLS handshake including the
certificate messages. certificate messages.
EAP-TLS peer and server implementations supporting TLS 1.3 or higher EAP-TLS peer and server implementations supporting TLS 1.3 or higher
MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4
in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its
username in cleartext in the Identity Response. Following [RFC7542], username in cleartext in the Identity Response. Following [RFC7542],
it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but 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) other constructions such as a fixed username (e.g. anonymous@realm)
or an encrypted username (e.g. YmVuZGVy@realm) are allowed. Note or an encrypted username (e.g.,
that the NAI MUST be a UTF-8 string as defined by the grammar in 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]. Section 2.2 of [RFC7542].
As the certificate messages in TLS 1.3 are encrypted, there is no 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 need to send an empty certificate_list and perform a second handshake
for privacy (as needed by EAP-TLS with earlier versions of TLS). for privacy (as needed by EAP-TLS with earlier versions of TLS).
When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer
and EAP-TLS server SHALL follow the processing specified by the used and EAP-TLS server SHALL follow the processing specified by the used
version of TLS. For TLS 1.3 this means that the EAP-TLS peer only version of TLS. For TLS 1.3 this means that the EAP-TLS peer only
sends an empty certificate_list if it does not have an appropriate 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 to send, and the EAP-TLS server MAY treat an empty
certificate_list as a terminal condition. certificate_list as a terminal condition.
EAP-TLS with TLS 1.3 is always used with privacy. This does not add 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 any extra round-trips and the message flow with privacy is just the
normal message flow as shown in Figure 1. normal message flow as shown in Figure 1.
2.1.9. Fragmentation 2.1.9. Fragmentation
This section updates Section 2.1.5 of [RFC5216]. This section updates Section 2.1.5 of [RFC5216].
Including ContentType and ProtocolVersion a single TLS record may be Including ContentType (1 byte), ProtocolVersion (2 bytes), and length
up to 16387 octets in length. EAP-TLS fragmentation support is (2 bytes) headers a single TLS record may be up to 16645 octets in
provided through addition of a flags octet within the EAP-Response length. EAP-TLS fragmentation support is provided through addition
and EAP-Request packets, as well as a TLS Message Length field of of a flags octet within the EAP-Response and EAP-Request packets, as
four octets. Implementations MUST NOT set the L bit in unfragmented well as a TLS Message Length field of four octets. Implementations
messages, but MUST accept unfragmented messages with and without the MUST NOT set the L bit in unfragmented messages, but MUST accept
L bit set. unfragmented messages with and without the L bit set.
Some EAP implementations and access networks may limit the number of Some EAP implementations and access networks may limit the number of
EAP packet exchanges that can be handled. To avoid fragmentation, it 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 is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and
trust anchor certificates small and the length of the certificate trust anchor certificates small and the length of the certificate
chains short. In addition, it is RECOMMENDED to use mechanisms that chains short. In addition, it is RECOMMENDED to use mechanisms that
reduce the sizes of Certificate messages. For a detailed discussion reduce the sizes of Certificate messages. For a detailed discussion
on reducing message sizes to prevent fragmentation, see on reducing message sizes to prevent fragmentation, see
[I-D.ietf-emu-eaptlscert]. [I-D.ietf-emu-eaptlscert].
skipping to change at page 15, line 42 skipping to change at page 19, line 5
versions of TLS with HKDF and completely changes the Key Schedule. versions of TLS with HKDF and completely changes the Key Schedule.
The key hierarchies shown in Section 2.3 of [RFC5216] are therefore The key hierarchies shown in Section 2.3 of [RFC5216] are therefore
not correct when EAP-TLS is used with TLS version 1.3 or higher. For not correct when EAP-TLS is used with TLS version 1.3 or higher. For
TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446].
When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, When EAP-TLS is used with TLS version 1.3 or higher the Key_Material,
IV, and Method-Id SHALL be derived from the exporter_master_secret IV, and Method-Id SHALL be derived from the exporter_master_secret
using the TLS exporter interface [RFC5705] (for TLS 1.3 this is using the TLS exporter interface [RFC5705] (for TLS 1.3 this is
defined in Section 7.5 of [RFC8446]). defined in Section 7.5 of [RFC8446]).
Type-Code = 0x0D Type-Code = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK_"+Type-Code,
Type-Code, 128) "",64)
IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", EMSK = TLS-Exporter("EXPORTER_EAP_TLS_EMSK_"+Type-Code,
Type-Code, 64) "",64)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id_"+Type-Code,
Type-Code, 64) "",64)
Session-Id = Type-Code || Method-Id Session-Id = Type-Code || Method-Id
All other parameters such as MSK and EMSK are derived in the same
manner as with EAP-TLS [RFC5216], Section 2.3. The definitions are
repeated below for simplicity:
MSK = Key_Material(0, 63) A zero-length context (indicated by "") is used in the TLS exporter
EMSK = Key_Material(64, 127) interface. The EAP-TLS Type-Code of '0D' (in hexadecimal) is
Enc-RECV-Key = MSK(0, 31) appended to the label strings. Other TLS based EAP methods can use
Enc-SEND-Key = MSK(32, 63) exporters in a similar fashion by replacing the EAP-TLS Type-Code
RECV-IV = IV(0, 31) with their own Type-Code (encoded as a hexadecimal string).
SEND-IV = IV(32, 63)
The use of these keys is specific to the lower layer, as described [RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are
[RFC5247]. 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. 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 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 by requesting less data from the TLS-Exporter function, this practice
is not possible with TLS 1.3. If an implementation intends to use 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 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 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 to do so will result in incorrect values being calculated for the
above keying material. above keying material.
skipping to change at page 16, line 45 skipping to change at page 20, line 4
TLS 1.3 cipher suites are defined differently than in earlier TLS 1.3 cipher suites are defined differently than in earlier
versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites 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 discussed in Section 2.4 of [RFC5216] can therefore not be used when
EAP-TLS is used with TLS version 1.3 or higher. EAP-TLS is used with TLS version 1.3 or higher.
When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS
peers and EAP-TLS servers MUST comply with the compliance peers and EAP-TLS servers MUST comply with the compliance
requirements (mandatory-to-implement cipher suites, signature requirements (mandatory-to-implement cipher suites, signature
algorithms, key exchange algorithms, extensions, etc.) for the TLS algorithms, key exchange algorithms, extensions, etc.) for the TLS
version used. For TLS 1.3 the compliance requirements are defined in version used. For TLS 1.3 the compliance requirements are defined in
Section 9 of [RFC8446]. 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 While EAP-TLS does not protect any application data except for the
Commitment Message, the negotiated cipher suites and algorithms MAY Commitment Message, the negotiated cipher suites and algorithms MAY
be used to secure data as done in other TLS-based EAP methods. be used to secure data as done in other TLS-based EAP methods.
2.5. EAP State Machines 2.5. EAP State Machines
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post-
Handshake messages use the handshake content type and can be sent Handshake messages use the handshake content type and can be sent
after the main handshake. One such Post-Handshake message is after the main handshake. One such Post-Handshake message is
NewSessionTicket. The NewSessionTicket can be used for resumption. NewSessionTicket. The NewSessionTicket can be used for resumption.
After sending TLS Finished, the EAP-TLS server may send any number of After sending TLS Finished, the EAP-TLS server may send any number of
Post-Handshake messages in separate EAP-Requests. To decrease the Post-Handshake messages in separate EAP-Requests. To decrease the
uncertainty for the EAP-TLS peer, the following procedure MUST be uncertainty for the EAP-TLS peer, the following procedure MUST be
followed: followed:
When an EAP-TLS server has sent its last handshake message (Finished When an EAP-TLS server has sent its last handshake message (Finished
or a Post-Handshake), it commits to not sending any more handshake or a Post-Handshake), it commits to not sending any more handshake
messages by sending a Commitment Message. The Commitment Message is messages by sending a TLS close_notify alert. After sending the
an encrypted TLS record with application data 0x00 (i.e. a TLS record alert, the EAP-TLS server may only send an EAP-Success or an EAP-
with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, Failure. Using the TLS close_notify however results in an extra EAP-
and TLSPlaintext.fragment = 0x00). Note that the length of the Request and EAP-Response exchange between the peer and the server.
plaintext is greater than the corresponding TLSPlaintext.length due
to the inclusion of TLSInnerPlaintext.type and any padding supplied
by the sender. EAP-TLS server implementations MUST set
TLSPlaintext.fragment to 0x00, but EAP-TLS peer implementations MUST
accept any application data as a Commitment Message from the EAP-TLS
server to not send any more handshake messages. The Commitment
Message may be sent in the same EAP-Request as the last handshake
record or in a separate EAP-Request. Sending the Commitment Message
in a separate EAP-Request adds an additional round-trip, but may be
necessary in TLS implementations that only implement a subset of TLS
1.3. In the case where the EAP-TLS server sends the Commitment
Message in a separate EAP-Request, the conversation will appear as
shown in Figure 9. After sending the Commitment Message, the EAP-TLS
server may only send an EAP-Success, an EAP-Failure, or an EAP-
Request with a TLS Alert Message.
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
<-------- Commitment Message)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 9: Commit in separate EAP-Request
3. Detailed Description of the EAP-TLS Protocol 3. Detailed Description of the EAP-TLS Protocol
No updates to Section 3 of [RFC5216]. No updates to Section 3 of [RFC5216].
4. IANA considerations 4. IANA considerations
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 EAP- Authority (IANA) regarding registration of values related to the EAP-
TLS 1.3 protocol in accordance with [RFC8126]. TLS 1.3 protocol in accordance with [RFC8126].
This memo requires IANA to add the following labels to the TLS This memo requires IANA to add the following labels to the TLS
Exporter Label Registry defined by [RFC5705]. These labels are used Exporter Label Registry defined by [RFC5705]. These labels are used
in derivation of Key_Material, IV and Method-Id as defined in in derivation of Key_Material, IV and Method-Id as defined in
Section 2.3: Section 2.3:
+-------------------------------+---------+-------------+------+ +-----------------------------+---------+-------------+------+
| Value | DTLS-OK | Recommended | Note | | Value | DTLS-OK | Recommended | Note |
+-------------------------------+---------+-------------+------+ +-----------------------------+---------+-------------+------+
| EXPORTER_EAP_TLS_Key_Material | N | Y | | | EXPORTER_EAP_TLS_MSK_ | N | Y | |
| | | | | | | | | |
| EXPORTER_EAP_TLS_IV | N | Y | | | EXPORTER_EAP_TLS_EMSK_ | N | Y | |
| | | | | | | | | |
| EXPORTER_EAP_TLS_Method-Id | N | Y | | | EXPORTER_EAP_TLS_Method-Id_ | N | Y | |
+-------------------------------+---------+-------------+------+ +-----------------------------+---------+-------------+------+
Table 1: TLS Exporter Label Registry Table 1: TLS Exporter Label Registry
5. Security Considerations 5. Security Considerations
5.1. Security Claims 5.1. Security Claims
Using EAP-TLS with TLS 1.3 does not change the security claims for 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 EAP-TLS as given in Section 5.1 of [RFC5216]. However, it
strengthens several of the claims as described in the following strengthens several of the claims as described in the following
updates to the notes given in Section 5.1 of [RFC5216]. updates to the notes given in Section 5.1 of [RFC5216].
[1] Mutual authentication: By mandating revocation checking of [1] Mutual authentication: By mandating revocation checking of
certificates, the authentication in EAP-TLS with TLS 1.3 is stronger certificates, the authentication in EAP-TLS with TLS 1.3 is stronger
as authentication with revoked certificates will always fail. as authentication with revoked certificates will always fail.
[2] Confidentiality: The TLS 1.3 handshake offers much better [2] Confidentiality: The TLS 1.3 handshake offers much better
confidentiality than earlier versions of TLS by mandating cipher confidentiality than earlier versions of TLS. EAP-TLS with TLS 1.3
suites with confidentiality and encrypting certificates and some of mandates use of cipher suites that ensure confidentiality. TLS 1.3
the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the also encrypts certificates and some of the extensions. When using
use of privacy is mandatory and does not cause any additional round- EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not
trips. cause any additional round-trips.
[3] Key strength: TLS 1.3 forbids all algorithms with known [3] Cryptographic strength: TLS 1.3 only define strong algorithms
weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 without major weaknesses and EAP-TLS with TLS 1.3 always provide
only supports cryptographic algorithms offering at least 112-bit forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC
security, see [RFC8446]. mode, RC4, SHA-1, MD5, P-192, and RSA-1024 can therefore not be
negotiated.
[4] Cryptographic Negotiation: TLS 1.3 increases the number of [4] Cryptographic Negotiation: TLS 1.3 increases the number of
cryptographic parameters that are negotiated in the handshake. When cryptographic parameters that are negotiated in the handshake. When
EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic
negotiation of AEAD algorithm, HKDF hash algorithm, key exchange negotiation of AEAD algorithm, HKDF hash algorithm, key exchange
groups, and signature algorithm, see Section 4.1.1 of [RFC8446]. groups, and signature algorithm, see Section 4.1.1 of [RFC8446].
5.2. Peer and Server Identities 5.2. Peer and Server Identities
No updates to section 5.2 of [RFC5216]. No updates to section 5.2 of [RFC5216].
5.3. Certificate Validation 5.3. Certificate Validation
No updates to section 5.3 of [RFC5216]. No updates to section 5.3 of [RFC5216].
5.4. Certificate Revocation 5.4. Certificate Revocation
This section updates Section 5.4 of [RFC5216]. This section updates Section 5.4 of [RFC5216].
While certificates may have long validity periods, there are a number While certificates may have long validity periods, there are a number
of reasons (e.g. key compromise, CA compromise, privilege withdrawn, of reasons (e.g., key compromise, CA compromise, privilege withdrawn,
etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have 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 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 server's certificate is complicated by the fact that the EAP-TLS peer
may not have Internet connectivity until authentication completes. may not have Internet connectivity until authentication completes.
When EAP-TLS is used with TLS 1.3, the revocation status of all the When EAP-TLS is used with TLS 1.3, the revocation status of all the
certificates in the certificate chains MUST be checked. certificates in the certificate chains MUST be checked (except the
trust anchor). An implementation may use Certificate Revocation List
(CRL) Online Certificate Status Protocol (OSCP) or other standardized
or proprietary methods for revocation checking. Examples of
proprietary methods are non-standard formats and distribution of
revocation lists as well as certificates with very short lifetime.
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
Requests (OCSP stapling) as specified in [RFC6066] and Requests (OCSP stapling) as specified in [RFC6066] and
Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers 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 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 EAP-TLS server's certificate chain. When an EAP-TLS peer uses
Certificate Status Requests to check the revocation status of the Certificate Status Requests to check the revocation status of the
EAP-TLSserver's certificate chain it MUST treat a CertificateEntry EAP-TLS server's certificate chain it MUST treat a CertificateEntry
(except the trust anchor) without a valid CertificateStatus extension (except the trust anchor) without a valid CertificateStatus extension
as invalid and abort the handshake with an appropriate alert. The as invalid and abort the handshake with an appropriate alert. The
OCSP status handling in TLS 1.3 is different from earlier versions of 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 TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP
information is carried in the CertificateEntry containing the information is carried in the CertificateEntry containing the
associated certificate instead of a separate CertificateStatus associated certificate instead of a separate CertificateStatus
message as in [RFC4366]. This enables sending OCSP information for message as in [RFC6066]. This enables sending OCSP information for
all certificates in the certificate chain (except the trust anchor). all certificates in the certificate chain (except the trust anchor).
To enable revocation checking in situations where EAP-TLS peers do To enable revocation checking in situations where EAP-TLS peers do
not implement or use OCSP stapling, and where network connectivity is not implement or use OCSP stapling, and where network connectivity is
not available prior to authentication completion, EAP--TLS peer not available prior to authentication completion, EAP-TLS peer
implementations MUST also support checking for certificate revocation implementations MUST also support checking for certificate revocation
after authentication completes and network connectivity is available, after authentication completes and network connectivity is available.
and they SHOULD utilize this capability by default.
An implementation MAY enforce limited authorization before revocation
checking has been done.
5.5. Packet Modification Attacks 5.5. Packet Modification Attacks
No updates to Section 5.5 of [RFC5216]. No updates to Section 5.5 of [RFC5216].
5.6. Authorization 5.6. Authorization
This is a new section when compared to [RFC5216]. The guidance in This is a new section when compared to [RFC5216]. The guidance in
this section is relevant for EAP-TLS in general (regardless of the this section is relevant for EAP-TLS in general (regardless of the
underlying TLS version used). underlying TLS version used).
skipping to change at page 22, line 8 skipping to change at page 24, line 16
layer. To perform resumption in a secure way, the EAP-TLS peer and layer. To perform resumption in a secure way, the EAP-TLS peer and
EAP-TLS server need to be able to securely retrieve authorization EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full information such as certificate chains from the initial full
handshake. We use the term "cached data" to describe such handshake. We use the term "cached data" to describe such
information. Authorization during resumption MUST be based on such information. Authorization during resumption MUST be based on such
cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh
revocation checks on the cached certificate data. Any security revocation checks on the cached certificate data. Any security
policies for authorization MUST be followed also for resumption. The policies for authorization MUST be followed also for resumption. The
certificates may have been revoked since the initial full handshake certificates may have been revoked since the initial full handshake
and the authorizations of the other party may have been reduced. If and the authorizations of the other party may have been reduced. If
the cached revocation is not sufficiently current, the EAP-TLS peer the cached revocation data is not sufficiently current, the EAP-TLS
or EAP-TLS server MAY force a full TLS handshake. peer or EAP-TLS server MAY force a full TLS handshake.
There are two ways to retrieve the cached data from the original full 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 handshake. The first method is that the EAP-TLS server and client
cache the information locally. The cached information is identified cache the information locally. The cached information is identified
by an identifier. For TLS versions before 1.3, the identifier can be 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 the session ID, for TLS 1.3, the identifier is the PSK identity. The
second method for retrieving cached information is via [RFC5077] or second method for retrieving cached information is via [RFC5077] or
[RFC8446], where the EAP-TLS server avoids storing information [RFC8446], where the EAP-TLS server avoids storing information
locally and instead encapsulates the information into a ticket or PSK locally and instead encapsulates the information into a ticket or PSK
which is sent to the client for storage. This ticket or PSK is 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 encrypted using a key that only the EAP-TLS server knows. Note that
the client still needs to cache the original handshake information the client still needs to cache the original handshake information
locally and will use the session ID or PSK identity to lookup this locally and will use the session ID or PSK identity to lookup this
information during resumption. However, the EAP-TLS server is able information during resumption. However, the EAP-TLS server is able
to decrypt the ticket or PSK to obtain the original handshake to decrypt the ticket or PSK to obtain the original handshake
information. information.
If the EAP-TLS server or EAP client do not apply any authorization If the EAP-TLS server or EAP client do not apply any authorization
policies, they MAY allow resumption where no cached data is policies, they MAY allow resumption where no cached data is
available. In all other cases, they MUST cache data during the available. In all other cases, they MUST cache data during the
initial full authentication to enable resumption. The cached data initial full handshake to enable resumption. The cached data MUST be
MUST be sufficient to make authorization decisions during resumption. sufficient to make authorization decisions during resumption. If
If cached data cannot be retrieved in a secure way, resumption MUST cached data cannot be retrieved in a secure way, resumption MUST NOT
NOT be done. be done.
The above requirements also apply if the EAP-TLS server expects some The above requirements also apply if the EAP-TLS server expects some
system to perform accounting for the session. Since accounting must system to perform accounting for the session. Since accounting must
be tied to an authenticated identity, and resumption does not supply be tied to an authenticated identity, and resumption does not supply
such an identity, accounting is impossible without access to cached such an identity, accounting is impossible without access to cached
data. Therefore systems which expect to perform accounting for the data. Therefore systems which expect to perform accounting for the
session SHOULD cache an identifier which can be used in subsequent session SHOULD cache an identifier which can be used in subsequent
accounting. accounting.
As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption
PSKs or tickets (and associated cached data) for longer than 7 days, PSKs or tickets (and associated cached data) for longer than 7 days,
regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY
delete them earlier based on local policy. The cached data MAY also 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 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 in the certificate chain has been revoked or has expired. In all
such cases, resumption results in a full TLS handshake instead. 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 Information from the EAP-TLS exchange (e.g., the identity provided in
EAP-Response/Identity) as well as non-EAP information (e.g. IP EAP-Response/Identity) as well as non-EAP information (e.g., IP
addresses) may change between the initial full handshake and addresses) may change between the initial full handshake and
resumption. This change creates a "time-of-check time-of-use" resumption. This change creates a "time-of-check time-of-use"
(TOCTOU) security vulnerability. A malicious or compromised user (TOCTOU) security vulnerability. A malicious or compromised user
could supply one set of data during the initial authentication, and a could supply one set of data during the initial authentication, and a
different set of data during resumption, potentially allowing them to different set of data during resumption, potentially allowing them to
obtain access that they should not have. obtain access that they should not have.
If any authorization, accounting, or policy decisions were made with If any authorization, accounting, or policy decisions were made with
information that have changed between the initial full handshake and information that has changed between the initial full handshake and
resumption, and if change may lead to a different decision, such resumption, and if change may lead to a different decision, such
decisions MUST be reevaluated. It is RECOMMENDED that authorization, decisions MUST be reevaluated. It is RECOMMENDED that authorization,
accounting, and policy decisions are reevaluated based on the accounting, and policy decisions are reevaluated based on the
information given in the resumption. EAP-TLS servers MAY reject information given in the resumption. EAP-TLS servers MAY reject
resumption where the information supplied during resumption does not resumption where the information supplied during resumption does not
match the information supplied during the original authentication. match the information supplied during the original authentication.
Where a good decision is unclear, EAP-TLS servers SHOULD reject the If a safe decision is not possible, EAP-TLS servers SHOULD reject the
resumption. resumption and continue with a full handshake.
Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security Section 2.2 and 4.2.11,[RFC8446] provides security considerations for
considerations for resumption. resumption.
5.8. Privacy Considerations 5.8. Privacy Considerations
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
TLS 1.3 offers much better privacy than earlier versions of TLS as 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 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 privacy properties of EAP-TLS with TLS 1.3. For privacy properties
of TLS 1.3 itself, see [RFC8446]. of TLS 1.3 itself, see [RFC8446].
EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in
EAP packets. Additionally, the EAP-TLS peer sends an identity in the 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 first EAP-Response. The other fields in the EAP-TLS Request and the
EAP-TLS Response packets do not contain any cleartext privacy EAP-TLS Response packets do not contain any cleartext privacy
sensitive information. sensitive information.
Tracking of users by eavesdropping on identity responses or Tracking of users by eavesdropping on identity responses or
certificates is a well-known problem in many EAP methods. When EAP- 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 TLS is used with TLS 1.3, all certificates are encrypted, and the
username part of the identity response is always confidentiality username part of the identity response is always confidentiality
protected (e.g. using anonymous NAIs). However, as with other EAP protected (e.g., using anonymous NAIs). Note that even though all
certificates are encrypted, the server's identity is only protected
against passive attackers while client's identity is protected
against both passive and active attackers. As with other EAP
methods, even when privacy-friendly identifiers or EAP tunneling is methods, even when privacy-friendly identifiers or EAP tunneling is
used, the domain name (i.e. the realm) in the NAI is still typically used, the domain name (i.e., the realm) in the NAI is still typically
visible. How much privacy sensitive information the domain name visible. How much privacy sensitive information the domain name
leaks is highly dependent on how many other users are using the same 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 domain name in the particular access network. If all EAP-TLS peers
have the same domain, no additional information is leaked. If a 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 domain name is used by a small subset of the EAP-TLS peers, it may
aid an attacker in tracking or identifying the user. aid an attacker in tracking or identifying the user.
Without padding, information about the size of the client certificate Without padding, information about the size of the client certificate
is leaked from the size of the EAP-TLS packets. The EAP-TLS packets 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 sizes may therefore leak information that can be used to track or
skipping to change at page 24, line 26 skipping to change at page 26, line 36
If anonymous NAIs are not used, the privacy-friendly identifiers need If anonymous NAIs are not used, the privacy-friendly identifiers need
to be generated with care. The identities MUST be generated in a to be generated with care. The identities MUST be generated in a
cryptographically secure way so that that it is computationally cryptographically secure way so that that it is computationally
infeasible for an attacker to differentiate two identities belonging infeasible for an attacker to differentiate two identities belonging
to the same user from two identities belonging to different users in to the same user from two identities belonging to different users in
the same realm. This can be achieved, for instance, by using random the same realm. This can be achieved, for instance, by using random
or pseudo-random usernames such as random byte strings or ciphertexts or pseudo-random usernames such as random byte strings or ciphertexts
and only using the pseudo-random usernames a single time. Note that and only using the pseudo-random usernames a single time. Note that
the privacy-friendly usernames also MUST NOT include substrings that the privacy-friendly usernames also MUST NOT include substrings that
can be used to relate the identity to a specific user. Similarly, can be used to relate the identity to a specific user. Similarly,
privacy-friendly username SHOULD NOT be formed by a fixed mapping privacy-friendly username MUST NOT be formed by a fixed mapping that
that stays the same across multiple different authentications. stays the same across multiple different authentications.
An EAP-TLS peer with a policy allowing communication with EAP-TLS 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 servers supporting only TLS 1.2 without privacy and with a static RSA
key exchange is vulnerable to disclosure of the EAP-TLS peer key exchange is vulnerable to disclosure of the EAP-TLS peer
username. An active attacker can in this case make 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 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 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 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 TLS alert message when the EAP-TLS peer tries to use privacy by
sending an empty certificate message. Since the attacker sending an empty certificate message. Since the attacker
(impersonating the EAP-TLS server) does not provide a proof-of- (impersonating the EAP-TLS server) does not provide a proof-of-
possession of the private key until the Finished message when a possession of the private key until the Finished message when a
static RSA key exchange is used, an EAP-TLS peer may inadvertently static RSA key exchange is used, an EAP-TLS peer may inadvertently
disclose its identity (username) to an attacker. Therefore, it is 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 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 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 EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
server responds to an empty certificate message with a TLS alert server sends an EAP-TLS/Request with a TLS alert message in response
message. to an empty certificate message from the peer.
5.9. Pervasive Monitoring 5.9. Pervasive Monitoring
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
Pervasive monitoring refers to widespread surveillance of users. In Pervasive monitoring refers to widespread surveillance of users. In
the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS the context of EAP-TLS, pervasive monitoring attacks can target EAP-
peer devices for tracking them (and their users) as and when they TLS peer devices for tracking them (and their users) as and when they
join a network. By encrypting more information and by mandating the join a network. By encrypting more information, mandating the use of
use of privacy, TLS 1.3 offers much better protection against privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3
pervasive monitoring. In addition to the privacy attacks discussed offers much better protection against pervasive monitoring. In
above, surveillance on a large scale may enable tracking of a user addition to the privacy attacks discussed above, surveillance on a
over a wider geographical area and across different access networks. large scale may enable tracking of a user over a wider geographical
Using information from EAP-TLS together with information gathered area and across different access networks. Using information from
from other protocols increases the risk of identifying individual EAP-TLS together with information gathered from other protocols
users. increases the risk of identifying individual users.
5.10. Discovered Vulnerabilities 5.10. Discovered Vulnerabilities
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
Over the years, there have been several serious attacks on earlier Over the years, there have been several serious attacks on earlier
versions of Transport Layer Security (TLS), including attacks on its versions of Transport Layer Security (TLS), including attacks on its
most commonly used ciphers and modes of operation. [RFC7457] most commonly used ciphers and modes of operation. [RFC7457]
summarizes the attacks that were known at the time of publishing and summarizes the attacks that were known at the time of publishing and
[RFC7525] provides recommendations for improving the security of BCP 195 [RFC7525] provides recommendations for improving the security
deployed services that use TLS. However, many of the attacks are 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 less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and
does not protect any application data. EAP-TLS implementations MUST does not protect any application data. EAP-TLS implementations MUST
mitigate known attacks. EAP-TLS implementations need to monitor and mitigate known attacks. EAP-TLS implementations need to monitor and
follow new EAP and TLS related security guidance and requirements follow new EAP and TLS related security guidance and requirements
such as [RFC8447], [I-D.ietf-tls-oldversions-deprecate], such as [RFC8447], [I-D.ietf-tls-oldversions-deprecate],
[I-D.ietf-tls-md5-sha1-deprecate]. [I-D.ietf-tls-md5-sha1-deprecate].
6. References 6. References
6.1. Normative References 6.1. Normative References
skipping to change at page 27, line 8 skipping to change at page 29, line 10
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
6.2. Informative references 6.2. Informative references
[I-D.ietf-emu-eaptlscert] [I-D.ietf-emu-eaptlscert]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large Sethi, M., Mattsson, J., and S. Turner, "Handling Large
Certificates and Long Certificate Chains in TLS-based EAP Certificates and Long Certificate Chains in TLS-based EAP
Methods", draft-ietf-emu-eaptlscert-07 (work in progress), Methods", draft-ietf-emu-eaptlscert-08 (work in progress),
November 2020. November 2020.
[I-D.ietf-tls-md5-sha1-deprecate] [I-D.ietf-tls-md5-sha1-deprecate]
Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf- MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf-
tls-md5-sha1-deprecate-04 (work in progress), October tls-md5-sha1-deprecate-04 (work in progress), October
2020. 2020.
[I-D.ietf-tls-oldversions-deprecate] [I-D.ietf-tls-oldversions-deprecate]
Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and
TLSv1.1", draft-ietf-tls-oldversions-deprecate-09 (work in TLSv1.1", draft-ietf-tls-oldversions-deprecate-12 (work in
progress), November 2020. progress), January 2021.
[I-D.ietf-tls-ticketrequests]
Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket
Requests", draft-ietf-tls-ticketrequests-07 (work in
progress), December 2020.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information technology--Telecommunications Standard for Information technology--Telecommunications
and information exchange between systems Local and and information exchange between systems Local and
metropolitan area networks--Specific requirements - Part metropolitan area networks--Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Std 802.11-2016 Layer (PHY) Specifications", IEEE Std 802.11-2016
(Revision of IEEE Std 802.11-2012) , December 2016. (Revision of IEEE Std 802.11-2012) , December 2016.
[IEEE-802.1AE] [IEEE-802.1AE]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Media Standard for Local and metropolitan area networks -- Media
Access Control (MAC) Security", IEEE Standard Access Control (MAC) Security", IEEE Standard
802.1AE-2018 , December 2018. 802.1AE-2018 , December 2018.
[IEEE-802.1X] [IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Port- Standard for Local and metropolitan area networks -- Port-
Based Network Access Control", IEEE Standard 802.1X-2010 , Based Network Access Control", IEEE Standard 802.1X-2020 ,
February 2010. January 2020.
[MulteFire] [MulteFire]
MulteFire, "MulteFire Release 1.1 specification", 2019. MulteFire, "MulteFire Release 1.1 specification", 2019.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", 2018. Authentication Protocol (PEAP)", 2018.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<https://www.rfc-editor.org/info/rfc1661>. <https://www.rfc-editor.org/info/rfc1661>.
skipping to change at page 28, line 36 skipping to change at page 30, line 43
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, Network Access Identifier", RFC 4282,
DOI 10.17487/RFC4282, December 2005, DOI 10.17487/RFC4282, December 2005,
<https://www.rfc-editor.org/info/rfc4282>. <https://www.rfc-editor.org/info/rfc4282>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, (TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006, DOI 10.17487/RFC4346, April 2006,
<https://www.rfc-editor.org/info/rfc4346>. <https://www.rfc-editor.org/info/rfc4346>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006,
<https://www.rfc-editor.org/info/rfc4366>.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851, Authentication Protocol Method (EAP-FAST)", RFC 4851,
DOI 10.17487/RFC4851, May 2007, DOI 10.17487/RFC4851, May 2007,
<https://www.rfc-editor.org/info/rfc4851>. <https://www.rfc-editor.org/info/rfc4851>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, DOI 10.17487/RFC5077, Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <https://www.rfc-editor.org/info/rfc5077>. January 2008, <https://www.rfc-editor.org/info/rfc5077>.
skipping to change at page 30, line 11 skipping to change at page 32, line 11
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
[TS.33.501] [TS.33.501]
3GPP, "Security architecture and procedures for 5G 3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501 16.4.0, September 2020. System", 3GPP TS 33.501 17.0.0, December 2020.
Appendix A. Updated references Appendix A. Updated references
All the following references in [RFC5216] are updated as specified All the following references in [RFC5216] are updated as specified
below when EAP-TLS is used with TLS 1.3 or higher. below when EAP-TLS is used with TLS 1.3 or higher.
All references to [RFC2560] are updated with [RFC6960]. All references to [RFC2560] are updated with [RFC6960].
All references to [RFC3280] are updated with [RFC5280]. All references to [RFC3280] are updated with [RFC5280].
All references to [RFC4282] are updated with [RFC7542]. All references to [RFC4282] are updated with [RFC7542].
Acknowledgments Acknowledgments
The authors want to thank Bernard Aboba, Jari Arkko, Alan DeKok, Ari The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton,
Keraenen, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, Terry Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar,
Burton, Vesa Torvinen, and Hannes Tschofenig for comments and Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa
suggestions on the draft. Torvinen, and Hannes Tschofenig for comments and suggestions on the
draft.
Contributors Contributors
Alan DeKok, FreeRADIUS Alan DeKok, FreeRADIUS
Authors' Addresses Authors' Addresses
John Preuss Mattsson John Preuss Mattsson
Ericsson Ericsson
Stockholm 164 40 Stockholm 164 40
 End of changes. 80 change blocks. 
290 lines changed or deleted 333 lines changed or added

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