rfc9190.original   rfc9190.txt 
Network Working Group J. Preuß Mattsson Internet Engineering Task Force (IETF) J. Preuß Mattsson
Internet-Draft M. Sethi Request for Comments: 9190 M. Sethi
Updates: 5216 (if approved) Ericsson Updates: 5216 Ericsson
Intended status: Standards Track 20 October 2021 Category: Standards Track February 2022
Expires: 23 April 2022 ISSN: 2070-1721
Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3
draft-ietf-emu-eap-tls13-21
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in RFC 3748, The Extensible Authentication Protocol (EAP), defined in RFC 3748,
provides a standard mechanism for support of multiple authentication provides a standard mechanism for support of multiple authentication
methods. This document specifies the use of EAP-Transport Layer methods. This document specifies the use of EAP-TLS with TLS 1.3
Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible while remaining backwards compatible with existing implementations of
with existing implementations of EAP-TLS. TLS 1.3 provides EAP-TLS. TLS 1.3 provides significantly improved security and
significantly improved security and privacy, and reduced latency when privacy, and reduced latency when compared to earlier versions of
compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security
1.3) further improves security and privacy by always providing and privacy by always providing forward secrecy, never disclosing the
forward secrecy, never disclosing the peer identity, and by mandating peer identity, and by mandating use of revocation checking when
use of revocation checking, when compared to EAP-TLS with earlier compared to EAP-TLS with earlier versions of TLS. This document also
versions of TLS. This document also provides guidance on provides guidance on authentication, authorization, and resumption
authentication, authorization, and resumption for EAP-TLS in general for EAP-TLS in general (regardless of the underlying TLS version
(regardless of the underlying TLS version used). This document used). This document updates RFC 5216.
updates RFC 5216.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 23 April 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9190.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements and Terminology . . . . . . . . . . . . . . 4 1.1. Requirements and Terminology
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Overview
2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 5 2.1. Overview of the EAP-TLS Conversation
2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 6 2.1.1. Authentication
2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 7 2.1.2. Ticket Establishment
2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 9 2.1.3. Resumption
2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 11 2.1.4. Termination
2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 14 2.1.5. No Peer Authentication
2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 15 2.1.6. Hello Retry Request
2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 16 2.1.7. Identity
2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.8. Privacy
2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 18 2.1.9. Fragmentation
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 18 2.2. Identity Verification
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19 2.3. Key Hierarchy
2.4. Parameter Negotiation and Compliance Requirements . . . . 20 2.4. Parameter Negotiation and Compliance Requirements
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 21 2.5. EAP State Machines
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 22 3. Detailed Description of the EAP-TLS Protocol
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 4. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 22 5.1. Security Claims
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 23 5.2. Peer and Server Identities
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 23 5.3. Certificate Validation
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 23 5.4. Certificate Revocation
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 24 5.5. Packet Modification Attacks
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 25 5.6. Authorization
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 26 5.7. Resumption
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 28 5.8. Privacy Considerations
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29 5.9. Pervasive Monitoring
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29 5.10. Discovered Vulnerabilities
5.11. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 30 5.11. Cross-Protocol Attacks
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 6. References
6.1. Normative References . . . . . . . . . . . . . . . . . . 30 6.1. Normative References
6.2. Informative references . . . . . . . . . . . . . . . . . 31 6.2. Informative references
Appendix A. Updated References . . . . . . . . . . . . . . . . . 36 Appendix A. Updated References
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36 Acknowledgments
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses
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-TLS [RFC5216] specifies an EAP authentication method
an EAP authentication method with certificate-based mutual with certificate-based mutual authentication utilizing the TLS
authentication utilizing the TLS handshake protocol for cryptographic handshake protocol for cryptographic algorithms and protocol version
algorithms and protocol version negotiation and establishment of negotiation and establishment of shared secret keying material. EAP-
shared secret keying material. EAP-TLS is widely supported for TLS is widely supported for authentication and key establishment in
authentication and key establishment in IEEE 802.11 [IEEE-802.11] IEEE 802.11 [IEEE-802.11] (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE]
(Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE] (MACsec) networks using IEEE (MACsec) networks using IEEE 802.1X [IEEE-802.1X] and it's the
802.1X [IEEE-802.1X] and it's the default mechanism for certificate default mechanism for certificate-based authentication in 3GPP 5G
based authentication in 3GPP 5G [TS.33.501] and MulteFire [MulteFire] [TS.33.501] and MulteFire [MulteFire] networks. Many other EAP
networks. Many other EAP methods such as EAP-FAST [RFC4851], EAP- methods such as Flexible Authentication via Secure Tunneling (EAP-
TTLS [RFC5281], TEAP [RFC7170], and PEAP [PEAP] depend on TLS and FAST) [RFC4851], Tunneled Transport Layer Security (EAP-TTLS)
EAP-TLS. [RFC5281], the Tunnel Extensible Authentication Protocol (TEAP)
[RFC7170], as well as vendor-specific EAP methods such as the
Protected Extensible Authentication Protocol (PEAP) [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 [RFC8996]. formally deprecated and prohibited from being negotiated or used
Weaknesses found in TLS 1.2, as well as new requirements for [RFC8996]. Weaknesses found in TLS 1.2 as well as new requirements
security, privacy, and reduced latency have led to the specification for security, privacy, and reduced latency have led to the
of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is specification of TLS 1.3 [RFC8446], which obsoletes TLS 1.2
in large parts a complete remodeling of the TLS handshake protocol [RFC5246]. TLS 1.3 is in large part a complete remodeling of the TLS
including a different message flow, different handshake messages, handshake protocol including a different message flow, different
different key schedule, different cipher suites, different resumption handshake messages, different key schedule, different cipher suites,
mechanism, different privacy protection, and different record different resumption mechanism, different privacy protection, and
padding. This means that significant parts of the normative text in different record padding. This means that significant parts of the
the previous EAP-TLS specification [RFC5216] are not applicable to normative text in the previous EAP-TLS specification [RFC5216] are
EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy not applicable to EAP-TLS with TLS 1.3. Therefore, aspects such as
handling, and key derivation need to be appropriately addressed for resumption, privacy handling, and key derivation need to be
EAP-TLS with TLS 1.3. appropriately addressed for EAP-TLS with TLS 1.3.
This document updates [RFC5216] to define how to use EAP-TLS with TLS This document updates [RFC5216] to define how to use EAP-TLS with TLS
1.3. When older TLS versions are negotiated, RFC 5216 applies to 1.3. When older TLS versions are negotiated, RFC 5216 applies to
maintain backwards compatibility. However, this document does maintain backwards compatibility. However, this document does
provide additional guidance on authentication, authorization, and provide additional guidance on authentication, authorization, and
resumption for EAP-TLS regardless of the underlying TLS version used. resumption for EAP-TLS regardless of the underlying TLS version used.
This document only describes differences compared to [RFC5216]. When This document only describes differences compared to [RFC5216]. When
EAP-TLS is used with TLS 1.3, some references are updated as EAP-TLS is used with TLS 1.3, some references are updated as
specified in Appendix A. All message flow are example message flows specified in Appendix A. All message flows are example message flows
specific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS specific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS
couples the TLS handshake state machine with the EAP state machine it couples the TLS handshake state machine with the EAP state machine,
is possible that new versions of TLS will cause incompatibilities it is possible that new versions of TLS will cause incompatibilities
that introduce failures or security issues if they are not carefully that introduce failures or security issues if they are not carefully
integrated into the EAP-TLS protocol. Therefore, implementations integrated into the EAP-TLS protocol. Therefore, implementations
MUST limit the maximum TLS version they use to 1.3, unless later MUST limit the maximum TLS version they use to 1.3, unless later
versions are explicitly enabled by the administrator. versions are explicitly enabled by the administrator.
This document specifies EAP-TLS 1.3 and does not specify how other This document specifies EAP-TLS 1.3 and does not specify how other
TLS-based EAP methods use TLS 1.3. The specification for how other TLS-based EAP methods use TLS 1.3. The specification for how other
TLS-based EAP methods use TLS 1.3 is left to other documents such as TLS-based EAP methods use TLS 1.3 is left to other documents such as
[I-D.ietf-emu-tls-eap-types]. [TLS-EAP-TYPES].
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, which in EAP-TLS means that no information about the Privacy, which in EAP-TLS means that no information about the
underlying peer identity is disclosed, is mandatory and achieved underlying peer identity is disclosed, is mandatory and achieved
without any additional round-trips. Revocation checking is mandatory without any additional round trips. Revocation checking is mandatory
and simplified with OCSP stapling, and TLS 1.3 introduces more and simplified with Online Certificate Status Protocol (OCSP)
possibilities to reduce fragmentation when compared to earlier stapling, and TLS 1.3 introduces more possibilities to reduce
versions of TLS. 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
in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is
used for the entity acting as EAP peer and TLS client. The term EAP- used for the entity acting as EAP peer and TLS client. The term EAP-
TLS server is used for the entity acting as EAP server and TLS TLS server is used for the entity acting as EAP server and TLS
server. server.
This document follows the terminology from [I-D.ietf-tls-rfc8446bis] This document follows the terminology from [TLS-bis] where the master
where the master secret is renamed to the main secret and the secret is renamed to the main secret and the exporter_master_secret
exporter_master_secret is renamed to the exporter_secret. is renamed to the exporter_secret.
2. Protocol Overview 2. Protocol Overview
2.1. Overview of the EAP-TLS Conversation 2.1. Overview of the EAP-TLS Conversation
This section updates Section 2.1 of [RFC5216] by amending it in This section updates Section 2.1 of [RFC5216] by amending it in
accordance with the following discussion. accordance with the following discussion.
If the TLS implementation correctly implements TLS version If the TLS implementation correctly implements TLS version
negotiation, EAP-TLS will automatically leverage that capability. negotiation, EAP-TLS will automatically leverage that capability.
skipping to change at page 5, line 27 skipping to change at line 202
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, much of Section 2.1 compared to earlier versions of TLS. Therefore, much of Section 2.1
of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and
5.7, this update applies only when TLS 1.3 is negotiated. When TLS 5.7, this update applies only when TLS 1.3 is negotiated. When TLS
1.2 is negotiated, then [RFC5216] applies. 1.2 is negotiated, then [RFC5216] applies.
TLS 1.3 introduces several new handshake messages including TLS 1.3 introduces several new handshake messages including
HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general, HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general,
these messages will be handled by the underlying TLS libraries and these messages will be handled by the underlying TLS libraries and
are not visible to EAP-TLS, however, there are a few things to note: are not visible to EAP-TLS; however, there are a few things to note:
* The HelloRetryRequest is used by the server to reject the * The HelloRetryRequest is used by the server to reject the
parameters offered in the ClientHello and suggest new parameters. parameters offered in the ClientHello and suggest new parameters.
When this message is encountered it will increase the number of When this message is encountered, it will increase the number of
round trips used by the protocol. round trips used by the protocol.
* The NewSessionTicket message is used to convey resumption * The NewSessionTicket message is used to convey resumption
information and is covered in Sections 2.1.2 and 2.1.3. information and is covered in Sections 2.1.2 and 2.1.3.
* The KeyUpdate message is used to update the traffic keys used on a * The KeyUpdate message is used to update the traffic keys used on a
TLS connection. EAP-TLS does not encrypt significant amounts of TLS connection. EAP-TLS does not encrypt significant amounts of
data so this functionality is not needed. Implementations SHOULD data so this functionality is not needed. Implementations SHOULD
NOT send this message, however some TLS libraries may NOT send this message; however, some TLS libraries may
automatically generate and process this message. automatically generate and process this message.
* Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT * Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT
send an early_data extension and clients MUST NOT send an send an early_data extension and clients MUST NOT send an
EndOfEarlyData message. EndOfEarlyData message.
* Post-handshake authentication MUST NOT be used in EAP-TLS. * Post-handshake authentication MUST NOT be used in EAP-TLS.
Clients MUST NOT send a "post_handshake_auth" extension and Clients MUST NOT send a "post_handshake_auth" extension and
Servers MUST NOT request post-handshake client authentication. Servers MUST NOT request post-handshake client authentication.
After receiving an EAP-Request packet with EAP-Type=EAP-TLS as After receiving an EAP-Request packet with EAP-Type=EAP-TLS as
described in [RFC5216] the conversation will continue with the TLS described in [RFC5216], the conversation will continue with the TLS
handshake protocol encapsulated in the data fields of EAP-Response handshake protocol encapsulated in the data fields of EAP-Response
and EAP-Request packets. When EAP-TLS is used with TLS version 1.3, and EAP-Request packets. When EAP-TLS is used with TLS version 1.3,
the formatting and processing of the TLS handshake SHALL be done as the formatting and processing of the TLS handshake SHALL be done as
specified in version 1.3 of TLS. This update only lists additional specified in version 1.3 of TLS. This update only lists additional
and different requirements, restrictions, and processing compared to and different requirements, restrictions, and processing compared to
[RFC8446] and [RFC5216]. [RFC8446] and [RFC5216].
2.1.1. Authentication 2.1.1. Authentication
This section updates Section 2.1.1 of [RFC5216] by amending it in This section updates Section 2.1.1 of [RFC5216] by amending it in
accordance with the following discussion. accordance with the following discussion.
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. The full handshake in EAP-TLS with TLS 1.3 always for resumption. The full handshake in EAP-TLS with TLS 1.3 always
provides forward secrecy by exchange of ephemeral "key_share" provides forward secrecy by exchange of ephemeral "key_share"
extensions in the ClientHello and ServerHello (e.g., containing extensions in the ClientHello and ServerHello (e.g., containing
ephemeral ECDHE public keys). SessionID is deprecated in TLS 1.3, Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) public keys).
see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early SessionID is deprecated in TLS 1.3; see Sections 4.1.2 and 4.1.3 of
application data which like all application data (other than the [RFC8446]. TLS 1.3 introduced early application data that like all
protected success indication described below) is not used in EAP-TLS; application data (other than the protected success indication
see Section 4.2.10 of [RFC8446] for additional information on the described below) is not used in EAP-TLS; see Section 4.2.10 of
"early_data" extension. Resumption is handled as described in [RFC8446] for additional information on the "early_data" extension.
Section 2.1.3. As a protected success indication [RFC3748] the EAP- Resumption is handled as described in Section 2.1.3. As a protected
TLS server always sends TLS application data 0x00, see Section 2.5. success indication [RFC3748], the EAP-TLS server always sends TLS
Note that a TLS implementation MAY not allow the EAP-TLS layer to application data 0x00; see Section 2.5. Note that a TLS
control in which order things are sent and the application data MAY implementation MAY not allow the EAP-TLS layer to control in which
therefore be sent before a NewSessionTicket. TLS application data order things are sent and the application data MAY therefore be sent
0x00 is therefore to be interpreted as success after the EAP-Request before a NewSessionTicket. TLS application data 0x00 is therefore to
that contains TLS application data 0x00. After the EAP-TLS server be interpreted as success after the EAP-Request that contains TLS
has sent an EAP-Request containing the TLS application data 0x00 and application data 0x00. After the EAP-TLS server has sent an EAP-
received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the Request containing the TLS application data 0x00 and received an EAP-
EAP-TLS server sends EAP-Success. Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server
sends EAP-Success.
Figure 1 shows an example message flow for a successful EAP-TLS full Figure 1 shows an example message flow for a successful EAP-TLS full
handshake with mutual authentication (and neither HelloRetryRequest handshake with mutual authentication (and neither HelloRetryRequest
nor post-handshake messages are sent). nor post-handshake messages are sent).
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 7, line 37 skipping to change at line 301
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00) <-------- (TLS Application Data 0x00)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
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 one or more post-handshake NewSessionTicket messages server MUST send one or more post-handshake NewSessionTicket messages
(each associated with a PSK, a PSK identity, a ticket lifetime, and (each associated with a PSK, a PSK identity, a ticket lifetime, and
other parameters) in the initial authentication. Note that TLS 1.3 other parameters) in the initial authentication. Note that TLS 1.3
[RFC8446] limits the ticket lifetime to a maximum of 604800 seconds [RFC8446] limits the ticket lifetime to a maximum of 604800 seconds
(7 days) and EAP-TLS servers MUST respect this upper limit when (7 days) and EAP-TLS servers MUST respect this upper limit when
issuing tickets. The NewSessionTicket is sent after the EAP-TLS issuing tickets. The NewSessionTicket is sent after the EAP-TLS
server has received the client Finished message in the initial server has received the client Finished message in the initial
authentication. The NewSessionTicket can be sent in the same flight authentication. The NewSessionTicket can be sent in the same flight
as the TLS server Finished or later. The PSK associated with the as the TLS server Finished or later. The PSK associated with the
ticket depends on the client Finished and cannot be pre-computed (so ticket depends on the client Finished and cannot be pre-computed (so
as to be sent in the same flight as the TLS server Finished) in as to be sent in the same flight as the TLS server Finished) in
handshakes with client authentication. The NewSessionTicket message handshakes with client authentication. The NewSessionTicket message
MUST NOT include an "early_data" extension. If the "early_data" MUST NOT include an "early_data" extension. If the "early_data"
extension is received then it MUST be ignored. Servers should take extension is received, then it MUST be ignored. Servers should take
into account that fewer NewSessionTickets will likely be needed in into account that fewer NewSessionTickets will likely be needed in
EAP-TLS than in the usual HTTPS connection scenario. In most cases a EAP-TLS than in the usual HTTPS connection scenario. In most cases,
single NewSessionTicket will be sufficient. A mechanism by which a single NewSessionTicket will be sufficient. A mechanism by which
clients can specify the desired number of tickets needed for future clients can specify the desired number of tickets needed for future
connections is defined in [I-D.ietf-tls-ticketrequests]. connections is defined in [TICKET-REQUESTS].
Figure 2 shows an example message flow for a successful EAP-TLS full Figure 2 shows an example message flow for a successful EAP-TLS full
handshake with mutual authentication and ticket establishment of a handshake with mutual authentication and ticket establishment of a
single ticket. single ticket.
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 9, line 5 skipping to change at line 365
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS NewSessionTicket, (TLS NewSessionTicket,
<-------- (TLS Application Data 0x00) <-------- (TLS Application Data 0x00)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
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] by amending it in This section updates Section 2.1.2 of [RFC5216] by amending it in
accordance with the following discussion. accordance with the following discussion.
EAP-TLS is typically used with client authentication and typically EAP-TLS is typically used with client authentication and typically
fragments the TLS flights into a large number of EAP requests and EAP fragments the TLS flights into a large number of EAP-requests and
responses. Resumption significantly reduces the number of round- EAP-responses. Resumption significantly reduces the number of round
trips and enables the EAP-TLS server to omit database lookups needed trips and enables the EAP-TLS server to omit database lookups needed
during a full handshake with client authentication. TLS 1.3 replaces during a full handshake with client authentication. TLS 1.3 replaces
the session resumption mechanisms in earlier versions of TLS with a the session resumption mechanisms in earlier versions of TLS with a
new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP-TLS new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP-TLS
SHALL use a resumption mechanism compatible with version 1.3 of TLS. SHALL use a resumption mechanism compatible with version 1.3 of TLS.
For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If 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 associated with the server, the client can use the PSK identity associated with the
ticket to negotiate the use of the associated PSK. If the EAP-TLS ticket to negotiate the use of the associated PSK. If the EAP-TLS
server accepts it, then the resumed session has been deemed to be server accepts it, then the resumed session has been deemed to be
authenticated, and securely associated with the prior authentication authenticated and securely associated with the prior authentication
or resumption. It is up to the EAP-TLS peer to use resumption, but or resumption. It is up to the EAP-TLS peer to use resumption, but
it is RECOMMENDED that the EAP-TLS peer use resumption if it has a it is RECOMMENDED that the EAP-TLS peer use resumption if it has a
valid ticket that has not been used before. It is left to the EAP- valid ticket that has not been used before. It is left to the EAP-
TLS server whether to accept resumption, but it is RECOMMENDED that TLS server whether to accept resumption, but it is RECOMMENDED that
the EAP-TLS server accept resumption if the ticket which was issued the EAP-TLS server accept resumption if the ticket that was issued is
is still valid. However, the EAP-TLS server MAY choose to require a still valid. However, the EAP-TLS server MAY choose to require a
full handshake. In the case a full handshake is required, the full handshake. In the case a full handshake is required, the
negotiation proceeds as if the session was a new authentication, and negotiation proceeds as if the session was a new authentication, and
the resumption attempt is ignored. The requirements of Sections the resumption attempt is ignored. The requirements of Sections
2.1.1 and 2.1.2 then apply in their entirety. As described in 2.1.1 and 2.1.2 then apply in their entirety. As described in
Appendix C.4 of [RFC8446], reuse of a ticket allows passive observers Appendix C.4 of [RFC8446], reuse of a ticket allows passive observers
to correlate different connections. EAP-TLS peers and EAP-TLS to correlate different connections. EAP-TLS peers and EAP-TLS
servers SHOULD follow the client tracking preventions in Appendix C.4 servers SHOULD follow the client tracking preventions in Appendix C.4
of [RFC8446]. of [RFC8446].
It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the It is RECOMMENDED to use Network Access Identifiers (NAIs) with the
same realm during resumption and the original full handshake. This same realm during resumption and the original full handshake. This
requirement allows EAP packets to be routed to the same destination requirement allows EAP packets to be routed to the same destination
as the original full handshake. If this recommendation is not as the original full handshake. If this recommendation is not
followed, resumption is likely impossible. When NAI reuse can be followed, resumption is likely impossible. When NAI reuse can be
done without privacy implications, it is RECOMMENDED to use the same done without privacy implications, it is RECOMMENDED to use the same
NAI in the resumption, as was used in the original full handshake NAI in the resumption as was used in the original full handshake
[RFC7542]. For example, the NAI @realm can safely be reused since it [RFC7542]. For example, the NAI @realm can safely be reused since it
does not provide any specific information to associate a user's does not provide any specific information to associate a user's
resumption attempt with the original full handshake. However, resumption attempt with the original full handshake. However,
reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path
attacker to associate a resumption attempt with the original full attacker to associate a resumption attempt with the original full
handshake. The TLS PSK identity is typically derived by the TLS handshake. The TLS PSK identity is typically derived by the TLS
implementation and may be an opaque blob without a routable realm. implementation and may be an opaque blob without a routable realm.
The TLS PSK identity on its own is therefore unsuitable as a NAI in The TLS PSK identity on its own is therefore unsuitable as an NAI in
the Identity Response. the Identity Response.
Figure 3 shows an example message flow for a subsequent successful Figure 3 shows an example message flow for a subsequent successful
EAP-TLS resumption handshake where both sides authenticate via a PSK EAP-TLS resumption handshake where both sides authenticate via a PSK
provisioned via an earlier NewSessionTicket and where the server provisioned via an earlier NewSessionTicket and where the server
provisions a single new ticket. provisions a single new ticket.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
skipping to change at page 10, line 44 skipping to change at line 453
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00) <-------- (TLS Application Data 0x00)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 3: EAP-TLS resumption Figure 3: 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 send HelloRetryRequest to signal that additional information needs to send a HelloRetryRequest to signal that additional
is needed to complete the handshake, and the EAP-TLS peer needs to information is needed to complete the handshake, and the EAP-TLS peer
send a second ClientHello containing that information. Providing a needs to send a second ClientHello containing that information.
"key_share" and using the "psk_dhe_ke" pre-shared key exchange mode Providing a "key_share" and using the "psk_dhe_ke" pre-shared key
is also important in order to limit the impact of a key compromise. exchange mode is also important in order to limit the impact of a key
When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning compromise. When using "psk_dhe_ke", TLS 1.3 provides forward
that compromise of the PSK used for resumption does not compromise secrecy meaning that compromise of the PSK used for resumption does
any earlier connections. The "psk_dh_ke" key-exchange mode MUST be not compromise any earlier connections. The "psk_dh_ke" key exchange
used for resumption unless the deployment has a local requirement to mode MUST be used for resumption unless the deployment has a local
allow configuration of other mechanisms. requirement to allow configuration of other mechanisms.
2.1.4. Termination 2.1.4. Termination
This section updates Section 2.1.3 of [RFC5216] by amending it in This section updates Section 2.1.3 of [RFC5216] by amending it in
accordance with the following discussion. accordance with the following discussion.
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. The two in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3. The two
paragraphs below replace the corresponding paragraphs in paragraphs below replace the corresponding paragraphs in
skipping to change at page 11, line 44 skipping to change at line 501
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 4, 5, and 6 illustrate message flows in several cases where
the EAP-TLS peer or EAP-TLS server sends a TLS Error alert message. the EAP-TLS peer or EAP-TLS server sends a TLS Error alert message.
In earlier versions of TLS, error alerts could be warnings or fatal. In earlier versions of TLS, error alerts could be warnings or fatal.
In TLS 1.3, error alerts are always fatal and the only alerts sent at In TLS 1.3, error alerts are always fatal and the only alerts sent at
warning level are "close_notify" and "user_canceled", both of which warning level are "close_notify" and "user_canceled", both of which
indicate that the connection is not going to continue normally, see indicate that the connection is not going to continue normally; see
[RFC8446]. [RFC8446].
In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
fatal error condition. Failure to send TLS Error alerts means that fatal error condition. Failure to send TLS Error alerts means that
the peer or server would have no way of determining what went wrong. the peer or server would have no way of determining what went wrong.
EAP-TLS 1.3 strengthens this requirement. Whenever an implementation EAP-TLS 1.3 strengthens this requirement. Whenever an implementation
encounters a fatal error condition, it MUST send an appropriate TLS encounters a fatal error condition, it MUST send an appropriate TLS
Error alert. Error alert.
Figure 4 shows an example message flow where the EAP-TLS server Figure 4 shows an example message flow where the EAP-TLS server
rejects the ClientHello with an error alert. The EAP-TLS server can rejects the ClientHello with an error alert. The EAP-TLS server can
also partly reject the ClientHello with a HelloRetryRequest, see also partly reject the ClientHello with a HelloRetryRequest; see
Section 2.1.6. 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/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
skipping to change at page 12, line 36 skipping to change at line 535
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Error Alert) <-------- (TLS Error Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 4: EAP-TLS server rejection of ClientHello Figure 4: EAP-TLS Server Rejection of ClientHello
Figure 5 shows an example message flow where EAP-TLS server Figure 5 shows an example message flow where EAP-TLS server
authentication is unsuccessful and the EAP-TLS peer sends a TLS Error authentication is unsuccessful and the EAP-TLS peer sends a TLS Error
alert. alert.
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 13, line 31 skipping to change at line 567
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished) <-------- TLS Finished)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Error Alert) (TLS Error Alert)
--------> -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 5: EAP-TLS unsuccessful EAP-TLS server authentication Figure 5: EAP-TLS Unsuccessful EAP-TLS Server Authentication
Figure 6 shows an example message flow where the EAP-TLS server Figure 6 shows an example message flow where the EAP-TLS server
authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
fails to authenticate to the EAP-TLS server and the server sends a fails to authenticate to the EAP-TLS server and the server sends a
TLS Error alert. TLS Error alert.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
skipping to change at page 14, line 37 skipping to change at line 606
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Error Alert) <-------- (TLS Error Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 6: EAP-TLS unsuccessful client authentication Figure 6: 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].
Figure 7 shows an example message flow for a successful EAP-TLS full Figure 7 shows an example message flow for a successful EAP-TLS full
handshake without peer authentication (e.g., emergency services, as handshake without peer authentication (e.g., emergency services, as
described in [RFC7406]). described in [RFC7406]).
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
skipping to change at page 15, line 34 skipping to change at line 645
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00) <-------- (TLS Application Data 0x00)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 7: EAP-TLS without peer authentication Figure 7: 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 (or there is no support the groups in the "key_share" extension (or there is no
"key_share" extension), but supports one of the groups in the "key_share" extension) but supports one of the groups in the
"supported_groups" extension. In this case the client should send a "supported_groups" extension. In this case, the client should send a
new ClientHello with a "key_share" that the EAP-TLS server supports. new ClientHello with a "key_share" that the EAP-TLS server supports.
Figure 8 shows an example message flow for a successful EAP-TLS full Figure 8 shows an example message flow for a successful EAP-TLS full
handshake with mutual authentication and HelloRetryRequest. Note the handshake with mutual authentication and HelloRetryRequest. Note the
extra round-trip as a result of the HelloRetryRequest. 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
<-------- (TLS Start) <-------- (TLS Start)
skipping to change at page 17, line 8 skipping to change at line 717
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
contain an identity such as an email address, which is already in NAI contain an identity such as an email address, which is already in NAI
format. When the client certificate contains a NAI as subject name format. When the client certificate contains an NAI as subject name
or alternative subject name, an anonymous NAI SHOULD be derived from or alternative subject name, an anonymous NAI SHOULD be derived 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] by amending it in This section updates Section 2.1.4 of [RFC5216] by amending it in
accordance with the following discussion. accordance with the following discussion.
EAP-TLS 1.3 significantly improves privacy when compared to earlier EAP-TLS 1.3 significantly improves privacy when compared to earlier
versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites without versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites without
confidentiality which means that TLS 1.3 is always encrypting large confidentiality, which means that TLS 1.3 is always encrypting large
parts of the TLS handshake including the certificate messages. parts of the TLS handshake including the certificate messages.
EAP-TLS peer and server implementations supporting TLS 1.3 MUST EAP-TLS peer and server implementations supporting TLS 1.3 MUST
support anonymous Network Access Identifiers (NAIs) (Section 2.4 in support anonymous Network Access Identifiers (NAIs) (Section 2.4 of
[RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username [RFC7542]). A client supporting TLS 1.3 MUST NOT send its username
in cleartext in the Identity Response. Following [RFC7542], it is (or any other permanent identifiers) in cleartext in the Identity
RECOMMENDED to omit the username (i.e., the NAI is @realm), but other Response (or any message used instead of the Identity Response).
constructions such as a fixed username (e.g., anonymous@realm) or an Following [RFC7542], it is RECOMMENDED to omit the username (i.e.,
encrypted username (e.g., the NAI is @realm), but other constructions such as a fixed username
(e.g., anonymous@realm) or an encrypted username (e.g.,
xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed.
Note that the NAI MUST be a UTF-8 string as defined by the grammar in 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].
The HelloRequest message used for privacy in EAP-TLS 1.2 does not The HelloRequest message used for privacy in EAP-TLS 1.2 does not
exist in TLS 1.3 but as the certificate messages in TLS 1.3 are exist in TLS 1.3 but as the certificate messages in TLS 1.3 are
encrypted, there is no need to send an empty certificate_list and encrypted, there is no need to send an empty certificate_list and
perform a second handshake for privacy (as needed by EAP-TLS with perform a second handshake for privacy (as needed by EAP-TLS with
earlier versions of TLS). When EAP-TLS is used with TLS version 1.3 earlier versions of TLS). When EAP-TLS is used with TLS version 1.3,
the EAP-TLS peer and EAP-TLS server SHALL follow the processing the EAP-TLS peer and EAP-TLS server SHALL follow the processing
specified by version 1.3 of TLS. This means that the EAP-TLS peer specified by version 1.3 of TLS. This means that the EAP-TLS peer
only sends an empty certificate_list if it does not have an only sends an empty certificate_list if it does not have an
appropriate certificate to send, and the EAP-TLS server MAY treat an appropriate certificate to send, and the EAP-TLS server MAY treat an
empty certificate_list as a terminal condition. empty 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] by amending it in This section updates Section 2.1.5 of [RFC5216] by amending it in
accordance with the following discussion. accordance with the following discussion.
Including ContentType (1 byte), ProtocolVersion (2 bytes), and length Including ContentType (1 byte), ProtocolVersion (2 bytes), and length
(2 bytes) headers a single TLS record may be up to 16645 octets in (2 bytes) headers, a single TLS record may be up to 16645 octets in
length. EAP-TLS fragmentation support is provided through addition length. EAP-TLS fragmentation support is provided through addition
of a flags octet within the EAP-Response and EAP-Request packets, as of a flags octet within the EAP-Response and EAP-Request packets, as
well as a (conditional) TLS Message Length field of four octets. well as a (conditional) TLS Message Length field of four octets.
Implementations MUST NOT set the L bit in unfragmented messages, but Implementations MUST NOT set the L bit in unfragmented messages, but
MUST accept unfragmented messages with and without the L bit set. they MUST accept 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 [RFC9191].
[I-D.ietf-emu-eaptlscert].
2.2. Identity Verification 2.2. Identity Verification
This section updates Section 2.2 of [RFC5216] by amending it in This section replaces Section 2.2 of [RFC5216] with the following
accordance with the following discussion. The guidance in this discussion. The guidance in this section is relevant for EAP-TLS in
section is relevant for EAP-TLS in general (regardless of the general (regardless of the underlying TLS version used).
underlying TLS version used).
The EAP peer identity provided in the EAP-Response/Identity is not The EAP peer identity provided in the EAP-Response/Identity is not
authenticated by EAP-TLS. Unauthenticated information MUST NOT be authenticated by EAP-TLS. Unauthenticated information MUST NOT be
used for accounting purposes or to give authorization. The used for accounting purposes or to give authorization. The
authenticator and the EAP-TLS server MAY examine the identity authenticator and the EAP-TLS server MAY examine the identity
presented in EAP-Response/Identity for purposes such as routing and presented in EAP-Response/Identity for purposes such as routing and
EAP method selection. EAP-TLS servers MAY reject conversations if EAP method selection. EAP-TLS servers MAY reject conversations if
the identity does not match their policy. Note that this also the identity does not match their policy. Note that this also
applies to resumption, see Sections 2.1.3, 5.6, and 5.7. applies to resumption; see Sections 2.1.3, 5.6, and 5.7.
The EAP server identity in the TLS server certificate is typically a The EAP server identity in the TLS server certificate is typically a
fully qualified domain name (FQDN) in the SubjectAltName (SAN) fully qualified domain name (FQDN) in the SubjectAltName (SAN)
extension. Since EAP-TLS deployments may use more than one EAP extension. Since EAP-TLS deployments may use more than one EAP
server, each with a different certificate, EAP peer implementations server, each with a different certificate, EAP peer implementations
SHOULD allow for the configuration of one or more trusted root SHOULD allow for the configuration of one or more trusted root
certificates (CA certificate) to authenticate the server certificate certificates (CA certificate) to authenticate the server certificate
and one or more server names to match against the SubjectAltName and one or more server names to match against the SubjectAltName
(SAN) extension in the server certificate. If any of the configured (SAN) extension in the server certificate. If any of the configured
names match any of the names in the SAN extension then the name check names match any of the names in the SAN extension, then the name
passes. To simplify name matching, an EAP-TLS deployment can assign check passes. To simplify name matching, an EAP-TLS deployment can
a name to represent an authorized EAP server and EAP Server assign a name to represent an authorized EAP server and EAP Server
certificates can include this name in the list of SANs for each certificates can include this name in the list of SANs for each
certificate that represents an EAP-TLS server. If server name certificate that represents an EAP-TLS server. If server name
matching is not used, then it degrades the confidence that the EAP matching is not used, then it degrades the confidence that the EAP
server with which it is interacting is authoritative for the given server with which it is interacting is authoritative for the given
network. If name matching is not used with a public root CA, then network. If name matching is not used with a public root CA, then
effectively any server can obtain a certificate which will be trusted effectively any server can obtain a certificate that will be trusted
for EAP authentication by the Peer. While this guidance to verify for EAP authentication by the peer. While this guidance to verify
domain names is new, and was not mentioned in [RFC5216], it has been domain names is new, and was not mentioned in [RFC5216], it has been
widely implemented in EAP-TLS peers. As such, it is believed that widely implemented in EAP-TLS peers. As such, it is believed that
this section contains minimal new interoperability or implementation this section contains minimal new interoperability or implementation
requirements on EAP-TLS peers and can be applied to earlier versions requirements on EAP-TLS peers and can be applied to earlier versions
of TLS. of TLS.
The process of configuring a root CA certificate and a server name is The process of configuring a root CA certificate and a server name is
non-trivial and therefore automated methods of provisioning are non-trivial; therefore, automated methods of provisioning are
RECOMMENDED. For example, the eduroam federation [RFC7593] provides RECOMMENDED. For example, the eduroam federation [RFC7593] provides
a Configuration Assistant Tool (CAT) to automate the configuration a Configuration Assistant Tool (CAT) to automate the configuration
process. In the absence of a trusted root CA certificate (user process. In the absence of a trusted root CA certificate (user
configured or system-wide), EAP peers MAY implement a trust on first configured or system-wide), EAP peers MAY implement a trust on first
use (TOFU) mechanism where the peer trusts and stores the server use (TOFU) mechanism where the peer trusts and stores the server
certificate during the first connection attempt. The EAP peer certificate during the first connection attempt. The EAP peer
ensures that the server presents the same stored certificate on ensures that the server presents the same stored certificate on
subsequent interactions. Use of a TOFU mechanism does not allow for subsequent interactions. Use of a TOFU mechanism does not allow for
the server certificate to change without out-of-band validation of the server certificate to change without out-of-band validation of
the certificate and is therefore not suitable for many deployments the certificate and is therefore not suitable for many deployments
skipping to change at page 19, line 41 skipping to change at line 843
availability. TOFU mechanisms increase the susceptibility to traffic availability. TOFU mechanisms increase the susceptibility to traffic
interception attacks and should only be used if there are adequate interception attacks and should only be used if there are adequate
controls in place to mitigate this risk. controls in place to mitigate this risk.
2.3. Key Hierarchy 2.3. Key Hierarchy
This section updates Section 2.3 of [RFC5216] by replacing it in This section updates Section 2.3 of [RFC5216] by replacing it in
accordance with the following discussion. accordance with the following discussion.
TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier
versions of TLS with HKDF and completely changes the Key Schedule. versions of TLS with the HMAC-based Key Derivation Function (HKDF)
The key hierarchies shown in Section 2.3 of [RFC5216] are therefore and completely changes the key schedule. The key hierarchies shown
not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 in Section 2.3 of [RFC5216] are therefore not correct when EAP-TLS is
the key schedule is described in Section 7.1 of [RFC8446]. used with TLS version 1.3. For TLS 1.3 the key schedule is described
in Section 7.1 of [RFC8446].
When EAP-TLS is used with TLS version 1.3 the Key_Material and When EAP-TLS is used with TLS version 1.3, the Key_Material and
Method-Id SHALL be derived from the exporter_secret using the TLS Method-Id SHALL be derived from the exporter_secret using the TLS
exporter interface [RFC5705] (for TLS 1.3 this is defined in exporter interface [RFC5705] (for TLS 1.3, this is defined in
Section 7.5 of [RFC8446]). Type is the value of the EAP Type field Section 7.5 of [RFC8446]). Type is the value of the EAP Type field
defined in Section 2 of [RFC3748]. For EAP-TLS the Type field has defined in Section 2 of [RFC3748]. For EAP-TLS, the Type field has
value 0x0D. value 0x0D.
Type = 0x0D Type = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type, 128) Type, 128)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
Type, 64) Type, 64)
Session-Id = Type || Method-Id Session-Id = Type || Method-Id
The MSK and EMSK are derived from the Key_Material in the same manner The MSK and EMSK are derived from the Key_Material in the same manner
as with EAP-TLS [RFC5216], Section 2.3. The definitions are repeated as with EAP-TLS [RFC5216], Section 2.3. The definitions are repeated
below for simplicity: below for simplicity:
MSK = Key_Material(0, 63) MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127) EMSK = Key_Material(64, 127)
Other TLS based EAP methods can use the TLS exporter in a similar Other TLS-based EAP methods can use the TLS exporter in a similar
fashion, see [I-D.ietf-emu-tls-eap-types]. fashion; see [TLS-EAP-TYPES].
[RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are [RFC5247] deprecates the use of an Initialization Vector (IV). Thus,
not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower RECV-IV and SEND-IV are not exported in EAP-TLS with TLS 1.3. As
layers use the MSK in a lower-layer-dependent manner. EAP-TLS with noted in [RFC5247], lower layers use the MSK in a lower-layer-
TLS 1.3 exports the MSK and does not specify how it is used by lower dependent manner. EAP-TLS with TLS 1.3 exports the MSK and does not
layers. specify how it is 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.
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
which provides a public API for the exporter. Note that when TLS 1.2 that provides a public API for the exporter. Note that when TLS 1.2
is used with the EAP-TLS exporter [RFC5705] it generates the same key is used with the EAP-TLS exporter [RFC5705] it generates the same key
material as in EAP-TLS [RFC5216]. material as in EAP-TLS [RFC5216].
2.4. Parameter Negotiation and Compliance Requirements 2.4. Parameter Negotiation and Compliance Requirements
This section updates Section 2.4 of [RFC5216] by amending it in This section updates Section 2.4 of [RFC5216] by amending it in
accordance with the following discussion. accordance with the following discussion.
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 Appendix B.4 of [RFC8446]), and the cipher
discussed in Section 2.4 of [RFC5216] can therefore not be used when suites discussed in Section 2.4 of [RFC5216] can therefore not be
EAP-TLS is used with TLS version 1.3. used when EAP-TLS is used with TLS version 1.3.
When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-
TLS servers MUST comply with the compliance requirements (mandatory- TLS servers MUST comply with the compliance requirements (mandatory-
to-implement cipher suites, signature algorithms, key exchange to-implement cipher suites, signature algorithms, key exchange
algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. In algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. In
EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL
be supported. 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
0x00 byte that serves as protected success indication, the negotiated 0x00 byte that serves as protected success indication, the negotiated
skipping to change at page 21, line 40 skipping to change at line 938
To provide a protected success result indication and to decrease the To provide a protected success result indication and 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 successfully processed the TLS client When an EAP-TLS server has successfully processed the TLS client
Finished and sent its last handshake message (Finished or a post- Finished and sent its last handshake message (Finished or a post-
handshake message), it sends an encrypted TLS record with application handshake message), it sends an encrypted TLS record with application
data 0x00. The encrypted TLS record with application data 0x00 is a data 0x00. The encrypted TLS record with application data 0x00 is a
protected success result indication, as defined in [RFC3748]. After protected success result indication, as defined in [RFC3748]. After
sending an EAP-Request that contains the protected success result sending an EAP-Request that contains the protected success result
indication, the EAP-TLS server must not send any more EAP-Request and indication, the EAP-TLS server must not send any more EAP-Requests
may only send an EAP-Success. The EAP-TLS server MUST NOT send an and may only send an EAP-Success. The EAP-TLS server MUST NOT send
encrypted TLS record with application data 0x00 alert before it has an encrypted TLS record with application data 0x00 before it has
successfully processed the client finished and sent its last successfully processed the client Finished and sent its last
handshake message. handshake message.
TLS Error alerts SHOULD be considered a failure result indication, as TLS Error alerts SHOULD be considered a failure result indication, as
defined in [RFC3748]. Implementations following [RFC4137] set the defined in [RFC3748]. Implementations following [RFC4137] set the
alternate indication of failure variable altReject after sending or alternate indication of failure variable altReject after sending or
receiving an error alert. After sending or receiving a TLS Error receiving an error alert. After sending or receiving a TLS Error
alert, the EAP-TLS server may only send an EAP-Failure. Protected alert, the EAP-TLS server may only send an EAP-Failure. Protected
TLS Error alerts are protected failure result indications, TLS Error alerts are protected failure result indications, and
unprotected TLS Error alerts are not. unprotected TLS Error alerts are not.
The keying material can be derived after the TLS server Finished has The keying material can be derived after the TLS server Finished has
been sent or received. Implementations following [RFC4137] can then been sent or received. Implementations following [RFC4137] can then
set the eapKeyData and aaaEapKeyData variables. set the eapKeyData and aaaEapKeyData variables.
The keying material can be made available to lower layers and the The keying material can be made available to lower layers and the
authenticator after the authenticated success result indication has authenticator after the authenticated success result indication has
been sent or received. Implementations following [RFC4137] can set been sent or received. Implementations following [RFC4137] can set
the eapKeyAvailable and aaaEapKeyAvailable variables. the eapKeyAvailable and aaaEapKeyAvailable variables.
3. Detailed Description of the EAP-TLS Protocol 3. Detailed Description of the EAP-TLS Protocol
No updates to Section 3 of [RFC5216]. There are 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 EAP-TLS
TLS 1.3 protocol in accordance with [RFC8126]. 1.3 in accordance with [RFC8126].
This document requires IANA to add the following labels to the TLS Per this document, IANA has added the following labels to the "TLS
Exporter Label Registry defined by [RFC5705]. These labels are used Exporter Labels" registry defined by [RFC5705]. These labels are
in derivation of Key_Material and Method-Id as defined in used in derivation of Key_Material 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_Key_Material | 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 Labels
5. Security Considerations 5. Security Considerations
The security considerations of TLS 1.3 [RFC8446] apply to EAP-TLS 1.3 The security considerations of TLS 1.3 [RFC8446] apply to EAP-TLS
1.3.
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
as authentication with revoked certificates will always fail. stronger 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. EAP-TLS with TLS 1.3 confidentiality than earlier versions of TLS. EAP-TLS with TLS
mandates use of cipher suites that ensure confidentiality. TLS 1.3 1.3 mandates use of cipher suites that ensure confidentiality.
also encrypts certificates and some of the extensions. When using TLS 1.3 also encrypts certificates and some of the extensions.
EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not When using EAP-TLS with TLS 1.3, the use of privacy is mandatory
cause any additional round-trips. and does not cause any additional round trips.
[3] Cryptographic strength: TLS 1.3 only defines strong algorithms [3] Cryptographic strength: TLS 1.3 only defines strong algorithms
without major weaknesses and EAP-TLS with TLS 1.3 always provides without major weaknesses and EAP-TLS with TLS 1.3 always provides
forward secrecy, see [RFC8446]. Weak algorithms such as 3DES, CBC forward secrecy; see [RFC8446]. Weak algorithms such as 3DES,
mode, RC4, SHA-1, MD5, P-192, and RSA-1024 have not been registered CBC mode, RC4, SHA-1, MD5, P-192, and RSA-1024 have not been
for use in TLS 1.3. registered for use in TLS 1.3.
[4] Cryptographic Negotiation: The TLS layer handles the negotiation [4] Cryptographic negotiation: The TLS layer handles the negotiation
of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP- of cryptographic parameters. When EAP-TLS is used with TLS 1.3,
TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF EAP-TLS inherits the cryptographic negotiation of the AEAD
hash algorithm, key exchange groups, and signature algorithm, see algorithm, HKDF hash algorithm, key exchange groups, and
Section 4.1.1 of [RFC8446]. 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]. Note that Section 2.2 has No updates to Section 5.2 of [RFC5216]. Note that Section 2.2 has
additional discussion on identities. additional discussion on identities.
5.3. Certificate Validation 5.3. Certificate Validation
No updates to section 5.3 of [RFC5216]. In addition to section 5.3 No updates to Section 5.3 of [RFC5216]. In addition to Section 5.3
of [RFC5216], guidance on server certificate validation can be found of [RFC5216], guidance on server certificate validation can be found
in [RFC6125]. in [RFC6125].
5.4. Certificate Revocation 5.4. Certificate Revocation
This section updates Section 5.4 of [RFC5216] by amending it in This section updates Section 5.4 of [RFC5216] by amending it in
accordance with the following discussion. accordance with the following discussion.
There are a number of reasons (e.g., key compromise, CA compromise, There are a number of reasons (e.g., key compromise, CA compromise,
privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub- privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub-
CA certificates have to be revoked before their expiry date. CA certificates have to be revoked before their expiry date.
Revocation of the EAP-TLS server's certificate is complicated by the Revocation of the EAP-TLS server's certificate is complicated by the
fact that the EAP-TLS peer may not have Internet connectivity until fact that the EAP-TLS peer may not have Internet connectivity until
authentication completes. 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 (except the certificates in the certificate chains MUST be checked (except the
trust anchor). An implementation may use Certificate Revocation List trust anchor). An implementation may use the Certificate Revocation
(CRL), Online Certificate Status Protocol (OSCP), or other List (CRL), Online Certificate Status Protocol (OSCP), or other
standardized/proprietary methods for revocation checking. Examples standardized/proprietary methods for revocation checking. Examples
of proprietary methods are non-standard formats for distribution of of proprietary methods are non-standard formats for distribution of
revocation lists as well as certificates with very short lifetime. 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-TLS server'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 (but not the trust anchor) without a valid CertificateStatus
as invalid and abort the handshake with an appropriate alert. The extension as invalid and abort the handshake with an appropriate
OCSP status handling in TLS 1.3 is different from earlier versions of alert. The OCSP status handling in TLS 1.3 is different from earlier
TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP versions of TLS; see Section 4.4.2.1 of [RFC8446]. In TLS 1.3, the
information is carried in the CertificateEntry containing the OCSP 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 [RFC6066]. 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.
An EAP peer implementation SHOULD NOT trust the network (and any An EAP peer implementation SHOULD NOT trust the network (and any
skipping to change at page 24, line 50 skipping to change at line 1090
5.5. Packet Modification Attacks 5.5. Packet Modification Attacks
This section updates Section 5.5 of [RFC5216] by amending it in This section updates Section 5.5 of [RFC5216] by amending it in
accordance with the following discussion. accordance with the following discussion.
As described in [RFC3748] and Section 5.5 of [RFC5216], the only As described in [RFC3748] and Section 5.5 of [RFC5216], the only
information that is integrity and replay protected in EAP-TLS are the information that is integrity and replay protected in EAP-TLS are the
parts of the TLS Data that TLS protects. All other information in parts of the TLS Data that TLS protects. All other information in
the EAP-TLS message exchange including EAP-Request and EAP-Response the EAP-TLS message exchange including EAP-Request and EAP-Response
headers, the identity in the identity response, EAP-TLS packet header headers, the identity in the Identity Response, EAP-TLS packet header
fields, Type, and Flags, EAP-Success, and EAP-Failure can be fields, Type, Flags, EAP-Success, and EAP-Failure can be modified,
modified, spoofed, or replayed. spoofed, or replayed.
Protected TLS Error alerts are protected failure result indications Protected TLS Error alerts are protected failure result indications
and enables the EAP-TLS peer and EAP-TLS server to determine that the and enable the EAP-TLS peer and EAP-TLS server to determine that the
failure result was not spoofed by an attacker. Protected failure failure result was not spoofed by an attacker. Protected failure
result indications provide integrity and replay protection but MAY be result indications provide integrity and replay protection but MAY be
unauthenticated. Protected failure results do not significantly unauthenticated. Protected failure results do not significantly
improve availability as TLS 1.3 treats most malformed data as a fatal improve availability as TLS 1.3 treats most malformed data as a fatal
error. error.
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).
EAP servers will usually require the EAP peer to provide a valid EAP servers will usually require the EAP peer to provide a valid
certificate and will fail the connection if one is not provided. certificate and will fail the connection if one is not provided.
Some deployments may permit no peer authentication for some or all Some deployments may permit no peer authentication for some or all
connections. When peer authentication is not used, EAP-TLS server connections. When peer authentication is not used, EAP-TLS server
implementations MUST take care to limit network access appropriately implementations MUST take care to limit network access appropriately
for unauthenticated peers and implementations MUST use resumption for unauthenticated peers, and implementations MUST use resumption
with caution to ensure that a resumed session is not granted more with caution to ensure that a resumed session is not granted more
privilege than was intended for the original session. An example of privilege than was intended for the original session. An example of
limiting network access would be to invoke a vendor's walled garden limiting network access would be to invoke a vendor's walled garden
or quarantine network functionality. or quarantine network functionality.
EAP-TLS is typically encapsulated in other protocols, such as PPP EAP-TLS is typically encapsulated in other protocols such as PPP
[RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or PANA [RFC5191]. [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or the Protocol for
The encapsulating protocols can also provide additional, non-EAP Carrying Authentication for Network Access (PANA) [RFC5191]. The
encapsulating protocols can also provide additional, non-EAP
information to an EAP-TLS server. This information can include, but information to an EAP-TLS server. This information can include, but
is not limited to, information about the authenticator, information is not limited to, information about the authenticator, information
about the EAP-TLS peer, or information about the protocol layers about the EAP-TLS peer, or information about the protocol layers
above or below EAP (MAC addresses, IP addresses, port numbers, Wi-Fi above or below EAP (MAC addresses, IP addresses, port numbers, Wi-Fi
SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those Service Set Identifiers (SSIDs), etc.). EAP-TLS servers implementing
protocols can make policy decisions and enforce authorization based EAP-TLS inside those protocols can make policy decisions and enforce
on a combination of information from the EAP-TLS exchange and non-EAP authorization based on a combination of information from the EAP-TLS
information. exchange and non-EAP information.
As noted in Section 2.2, the identity presented in EAP-Response/ As noted in Section 2.2, the identity presented in EAP-Response/
Identity is not authenticated by EAP-TLS and is therefore trivial for Identity is not authenticated by EAP-TLS and is therefore trivial for
an attacker to forge, modify, or replay. Authorization and an attacker to forge, modify, or replay. Authorization and
accounting MUST be based on authenticated information such as accounting MUST be based on authenticated information such as
information in the certificate or the PSK identity and cached data information in the certificate or the PSK identity and cached data
provisioned for resumption as described in Section 5.7. Note that provisioned for resumption as described in Section 5.7. Note that
the requirements for Network Access Identifiers (NAIs) specified in the requirements for Network Access Identifiers (NAIs) specified in
Section 4 of [RFC7542] still apply and MUST be followed. Section 4 of [RFC7542] still apply and MUST be followed.
EAP-TLS servers MAY reject conversations based on non-EAP information EAP-TLS servers MAY reject conversations based on non-EAP information
provided by the encapsulating protocol, for example, if the MAC provided by the encapsulating protocol, for example if the MAC
address of the authenticator does not match the expected policy. address of the authenticator does not match the expected policy.
In addition to allowing configuration of one or more trusted root In addition to allowing configuration of one or more trusted root
certificates (CA certificate) to authenticate the server certificate certificates (CA certificate) to authenticate the server certificate
and one or more server names to match against the SubjectAltName and one or more server names to match against the SubjectAltName
(SAN) extension, EAP peer implementations MAY allow binding the (SAN) extension, EAP peer implementations MAY allow binding the
configured acceptable SAN to a specific CA (or CAs) that should have configured acceptable SAN to a specific CA (or CAs) that should have
issued the server certificate to prevent attacks from rogue or issued the server certificate to prevent attacks from rogue or
compromised CAs. compromised CAs.
5.7. Resumption 5.7. Resumption
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).
There are a number of security issues related to resumption that are There are a number of security issues related to resumption that are
not described in [RFC5216]. The problems, guidelines, and not described in [RFC5216]. The problems, guidelines, and
requirements in this section therefore applies to EAP-TLS when it is requirements in this section therefore apply to EAP-TLS when it is
used with any version of TLS. used with any version of TLS.
When resumption occurs, it is based on cached information at the TLS When resumption occurs, it is based on cached information at the TLS
layer. To perform resumption securely, the EAP-TLS peer and EAP-TLS layer. To perform resumption securely, the EAP-TLS peer and EAP-TLS
server need to be able to securely retrieve authorization information server need to be able to securely retrieve authorization information
such as certificate chains from the initial full handshake. This such as certificate chains from the initial full handshake. This
document uses the term "cached data" to describe such information. document uses the term "cached data" to describe such information.
Authorization during resumption MUST be based on such cached data. Authorization during resumption MUST be based on such cached data.
The EAP-TLS peer and EAP-TLS server MAY perform fresh revocation The EAP-TLS peer and EAP-TLS server MAY perform fresh revocation
checks on the cached certificate data. Any security policies for checks on the cached certificate data. Any security policies for
authorization MUST be followed also for resumption. The certificates authorization MUST be followed also for resumption. The certificates
may have been revoked since the initial full handshake and the may have been revoked since the initial full handshake and the
authorizations of the other party may have been reduced. If the authorizations of the other party may have been reduced. If the
cached revocation data is not sufficiently current, the EAP-TLS peer cached revocation data is not sufficiently current, the EAP-TLS peer
or EAP-TLS server MAY force a full TLS handshake. 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 which locally and instead encapsulates the information into a ticket that
is sent to the client for storage. This ticket is encrypted using a is sent to the client for storage. This ticket is encrypted using a
key that only the EAP-TLS server knows. Note that the client still key that only the EAP-TLS server knows. Note that the client still
needs to cache the original handshake information locally and will needs to cache the original handshake information locally and will
obtain it while determining the session ID or PSK identity to use for obtain it while determining the session ID or PSK identity to use for
resumption. However, the EAP-TLS server is able to decrypt the resumption. However, the EAP-TLS server is able to decrypt the
ticket or PSK to obtain the original handshake information. ticket or PSK to obtain the original handshake information.
The EAP-TLS server or EAP client MUST cache data during the initial The EAP-TLS server or EAP client MUST cache data during the initial
full handshake sufficient to allow authorization decisions to be made full handshake sufficient to allow authorization decisions to be made
during resumption. If cached data cannot be retrieved securely, during resumption. If cached data cannot be retrieved securely,
resumption MUST NOT be done. resumption MUST NOT 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 that expect to perform accounting for the
session SHOULD cache an identifier which can be used in subsequent session SHOULD cache an identifier that 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 604800 PSKs or tickets (and associated cached data) for longer than 604800
seconds (7 days), regardless of the PSK or ticket lifetime. The EAP- seconds (7 days) regardless of the PSK or ticket lifetime. The EAP-
TLS peer MAY delete them earlier based on local policy. The cached TLS peer MAY delete them earlier based on local policy. The cached
data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any
certificate in the certificate chain has been revoked or has expired. certificate in the certificate chain has been revoked or has expired.
In all such cases, an attempt at resumption results in a full TLS In all such cases, an attempt at resumption results in a full TLS
handshake instead. 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"
skipping to change at page 27, line 50 skipping to change at line 1235
information that has 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.
If a safe decision is not possible, EAP-TLS servers SHOULD reject the If a safe decision is not possible, EAP-TLS servers SHOULD reject the
resumption and continue with a full handshake. resumption and continue with a full handshake.
Section 2.2 and 4.2.11 of [RFC8446] provides security considerations Sections 2.2 and 4.2.11 of [RFC8446] provide security considerations
for TLS 1.3 resumption. for TLS 1.3 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 not revealed (e.g., using username part of the Identity Response is not revealed (e.g., using
anonymous NAIs). Note that even though all certificates are anonymous NAIs). Note that even though all certificates are
encrypted, the server's identity is only protected against passive encrypted, the server's identity is only protected against passive
attackers while the client's identity is protected against both attackers while the client's identity is protected against both
passive and active attackers. As with other EAP methods, even when passive and active attackers. As with other EAP methods, even when
privacy-friendly identifiers or EAP tunneling is used, the domain privacy-friendly identifiers or EAP tunneling is used, the domain
name (i.e., the realm) in the NAI is still typically visible. How name (i.e., the realm) in the NAI is still typically visible. How
much privacy-sensitive information the domain name leaks is highly much privacy-sensitive information the domain name leaks is highly
dependent on how many other users are using the same domain name in dependent on how many other users are using the same domain name in
the particular access network. If all EAP-TLS peers have the same the particular access network. If all EAP-TLS peers have the same
domain, no additional information is leaked. If a domain name is domain, no additional information is leaked. If a domain name is
used by a small subset of the EAP-TLS peers, it may aid an attacker used by a small subset of the EAP-TLS peers, it may aid an attacker
in tracking or identifying the user. 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
identify the user. If all client certificates have the same length, identify the user. If all client certificates have the same length,
no information is leaked. EAP-TLS peers SHOULD use record padding, no information is leaked. EAP-TLS peers SHOULD use record padding;
see Section 5.4 of [RFC8446] to reduce information leakage of see Section 5.4 of [RFC8446] to reduce information leakage of
certificate sizes. certificate sizes.
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 it is computationally infeasible cryptographically secure way so that it is computationally infeasible
for an attacker to differentiate two identities belonging to the same for an attacker to differentiate two identities belonging to the same
user from two identities belonging to different users in the same user from two identities belonging to different users in the same
realm. This can be achieved, for instance, by using random or realm. This can be achieved, for instance, by using random or
pseudo-random usernames such as random byte strings or ciphertexts 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 MUST NOT be formed by a fixed mapping that privacy-friendly usernames MUST NOT be formed by a fixed mapping 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 a
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 EAP authentication attempt if a EAP-TLS peer SHOULD NOT continue the EAP authentication attempt if a
TLS 1.2 EAP-TLS server sends an EAP-TLS/Request with a TLS alert TLS 1.2 EAP-TLS server sends an EAP-TLS/Request with a TLS alert
message in response to an empty certificate message from the peer. message in response 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 of EAP-TLS, pervasive monitoring attacks can target EAP- the context of EAP-TLS, pervasive monitoring attacks can target EAP-
TLS peer devices for tracking them (and their users) as and when they TLS peer devices for tracking them (and their users) when they join a
join a network. By encrypting more information, mandating the use of network. By encrypting more information, mandating the use of
privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3 privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3
offers much better protection against pervasive monitoring. In offers much better protection against pervasive monitoring. In
addition to the privacy attacks discussed above, surveillance on a addition to the privacy attacks discussed above, surveillance on a
large scale may enable tracking of a user over a wide geographical large scale may enable tracking of a user over a wide geographical
area and across different access networks. Using information from area and across different access networks. Using information from
EAP-TLS together with information gathered from other protocols EAP-TLS together with information gathered from other protocols
increases the risk of identifying individual users. increases the risk of identifying individual users.
In TLS 1.3, the post-handshake key update mechanism provides forward
secrecy for the traffic secrets. EAP-TLS 1.3 does not provide a
similar mechanism for MSK and EMSK. Implementation using the
exported MSK and EMSK can achieve forward secrecy by frequently
deriving new keys in a similar way as described in Section 7.2 of
[RFC8446].
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
BCP 195 [RFC7525] [RFC8996] provides recommendations and requirements BCP 195 [RFC7525] [RFC8996] provides recommendations and requirements
for improving the security of deployed services that use TLS. for improving the security of deployed services that use TLS.
However, many of the attacks are less serious for EAP-TLS as EAP-TLS However, many of the attacks are less serious for EAP-TLS as EAP-TLS
only uses the TLS handshake and does not protect any application only uses the TLS handshake and does not protect any application
data. EAP-TLS implementations MUST mitigate known attacks. EAP-TLS data. EAP-TLS implementations MUST mitigate known attacks. EAP-TLS
implementations need to monitor and follow new EAP and TLS related implementations need to monitor and follow new EAP- and TLS-related
security guidance and requirements such as [RFC8447] and security guidance and requirements such as [RFC8447] and [RFC9155].
[I-D.ietf-tls-md5-sha1-deprecate].
5.11. Cross-Protocol Attacks 5.11. Cross-Protocol Attacks
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
Allowing the same certificate to be used in multiple protocols can Allowing the same certificate to be used in multiple protocols can
potentially allow an attacker to authenticate via one protocol, and potentially allow an attacker to authenticate via one protocol and
then "resume" that session in another protocol. Section 2.2 above then "resume" that session in another protocol. Section 2.2 suggests
suggests that certificates typically have one or more FQDNs in the that certificates typically have one or more FQDNs in the SAN
SAN extension. However, those fields are for EAP validation only, extension. However, those fields are for EAP validation only and do
and do not indicate that the certificates are suitable for use on WWW not indicate that the certificates are suitable for use with HTTPS or
(or other) protocol server on the named host. other protocols on the named host.
Section 2.1.3 above suggests that authorization rules should be re- Section 2.1.3 suggests that authorization rules should be reapplied
applied on resumption, but does not mandate this behavior. As a on resumption but does not mandate this behavior. As a result, this
result, this cross-protocol resumption could allow the attacker to cross-protocol resumption could allow the attacker to bypass
bypass authorization policies, and to obtain undesired access to authorization policies and to obtain undesired access to secured
secured systems. Along with making sure that appropriate systems. Along with making sure that appropriate authorization
authorization information is available and used during resumption, information is available and used during resumption, using different
using different certificates and resumption caches for different certificates and resumption caches for different protocols is
protocols is RECOMMENDED to help keep different protocol usages RECOMMENDED to help keep different protocol usages separate.
separate.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 31, line 40 skipping to change at line 1423
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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
[IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Port-
Based Network Access Control", IEEE Standard 802.1X-2020 ,
February 2020.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, "IEEE IEEE, "IEEE Standard for Information technology-
Standard for Information technology—Telecommunications and Telecommunications and information exchange between
information exchange between systems Local and systems Local and metropolitan area networks-Specific
metropolitan area networks—Specific requirements - Part requirements - Part 11: Wireless LAN Medium Access Control
11: Wireless LAN Medium Access Control (MAC) and Physical (MAC) and Physical Layer (PHY) Specifications", IEEE
Layer (PHY) Specifications", IEEE Standard 802.11-2020 , Std. 802.11-2020, DOI 10.1109/IEEESTD.2016.7786995,
February 2021. February 2021,
<https://doi.org/10.1109/IEEESTD.2016.7786995>.
[IEEE-802.1AE] [IEEE-802.1AE]
Institute of Electrical and Electronics Engineers, "IEEE IEEE, "IEEE Standard for Local and metropolitan area
Standard for Local and metropolitan area networks -- Media networks -- Media Access Control (MAC) Security", IEEE
Access Control (MAC) Security", IEEE Standard Std. 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421,
802.1AE-2018 , December 2018. December 2018,
<https://doi.org/10.1109/IEEESTD.2018.8585421>.
[TS.33.501] [IEEE-802.1X]
3GPP, "Security architecture and procedures for 5G IEEE, "IEEE Standard for Local and Metropolitan Area
System", 3GPP TS 33.501 17.3.0, September 2021. Networks--Port-Based Network Access Control", IEEE Std.
802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February
2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>.
[MulteFire] [MulteFire]
MulteFire, "MulteFire Release 1.1 specification", 2019. MulteFire Alliance, "MulteFire Release 1.1 Specification",
2019.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", June 2021. Authentication Protocol (PEAP)", June 2021.
[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>.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, DOI 10.17487/RFC2246, January 1999, RFC 2246, DOI 10.17487/RFC2246, January 1999,
skipping to change at page 35, line 18 skipping to change at line 1578
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>. <https://www.rfc-editor.org/info/rfc8996>.
[I-D.ietf-tls-md5-sha1-deprecate] [RFC9155] 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 and DTLS 1.2",
MD5 and SHA-1 signature hashes in (D)TLS 1.2", Work in RFC 9155, DOI 10.17487/RFC9155, December 2021,
Progress, Internet-Draft, draft-ietf-tls-md5-sha1- <https://www.rfc-editor.org/info/rfc9155>.
deprecate-09, 20 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-md5-sha1-
deprecate-09.txt>.
[I-D.ietf-emu-eaptlscert] [RFC9191] Sethi, M., Preuß Mattsson, J., and S. Turner, "Handling
Sethi, M., Mattsson, J., and S. Turner, "Handling Large Large Certificates and Long Certificate Chains in TLS-
Certificates and Long Certificate Chains in TLS-based EAP Based EAP Methods", RFC 9191, DOI 10.17487/RFC9191,
Methods", Work in Progress, Internet-Draft, draft-ietf- February 2022, <https://www.rfc-editor.org/rfc/rfc9191>.
emu-eaptlscert-08, 20 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-emu-
eaptlscert-08.txt>.
[I-D.ietf-tls-ticketrequests] [TICKET-REQUESTS]
Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket
Requests", Work in Progress, Internet-Draft, draft-ietf- Requests", Work in Progress, Internet-Draft, draft-ietf-
tls-ticketrequests-07, 3 December 2020, tls-ticketrequests-07, 3 December 2020,
<https://www.ietf.org/archive/id/draft-ietf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
ticketrequests-07.txt>. ticketrequests-07>.
[I-D.ietf-emu-tls-eap-types] [TLS-bis] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-03, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-03>.
[TLS-EAP-TYPES]
DeKok, A., "TLS-based EAP types and TLS 1.3", Work in DeKok, A., "TLS-based EAP types and TLS 1.3", Work in
Progress, Internet-Draft, draft-ietf-emu-tls-eap-types-03, Progress, Internet-Draft, draft-ietf-emu-tls-eap-types-04,
22 June 2021, <https://www.ietf.org/archive/id/draft-ietf- 21 January 2022, <https://datatracker.ietf.org/doc/html/
emu-tls-eap-types-03.txt>. draft-ietf-emu-tls-eap-types-04>.
[I-D.ietf-tls-rfc8446bis] [TS.33.501]
Rescorla, E., "The Transport Layer Security (TLS) Protocol 3GPP, "Security architecture and procedures for 5G
Version 1.3", Work in Progress, Internet-Draft, draft- system", Release 17, TS 33.501, January 2022.
ietf-tls-rfc8446bis-02, 23 August 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-
rfc8446bis-02.txt>.
Appendix A. Updated References Appendix A. Updated References
All the following references in [RFC5216] are updated as specified The following references in [RFC5216] are updated as specified below
below when EAP-TLS is used with TLS 1.3. when EAP-TLS is used with TLS 1.3.
All references to [RFC2560] are updated to refer to [RFC6960]. * All references to [RFC2560] are updated to refer to [RFC6960].
All references to [RFC3280] are updated to refer to [RFC5280]. * All references to [RFC3280] are updated to refer to [RFC5280].
References to Section 4.2.1.13 of [RFC3280] are updated to refer to References to Section 4.2.1.13 of [RFC3280] are updated to refer
Section 4.2.1.12 of [RFC5280]. to Section 4.2.1.12 of [RFC5280].
All references to [RFC4282] are updated to refer to [RFC7542]. * All references to [RFC4282] are updated to refer to [RFC7542].
References to Section 2.1 of [RFC4282] are updated to refer to References to Section 2.1 of [RFC4282] are updated to refer to
Section 2.2 of [RFC7542]. Section 2.2 of [RFC7542].
Acknowledgments Acknowledgments
The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton,
Alan DeKok, Ari Keraenen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, Alan DeKok, Ari Keränen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar,
Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa
Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and
suggestions on the draft. Special thanks to the document shepherd suggestions on this document. Special thanks to the Document
Joseph Salowey. Shepherd Joseph Salowey.
Contributors Contributors
Alan DeKok, FreeRADIUS Alan DeKok, FreeRADIUS
Authors' Addresses Authors' Addresses
John Preuß Mattsson John Preuß Mattsson
Ericsson Ericsson
SE-164 40 Stockholm SE-164 40 Kista
Sweden Sweden
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Mohit Sethi Mohit Sethi
Ericsson Ericsson
FI-02420 Jorvas FI-02420 Jorvas
Finland Finland
Email: mohit@piuha.net Email: mohit@iki.fi
 End of changes. 127 change blocks. 
366 lines changed or deleted 370 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/