draft-ietf-emu-eap-tls13-17.txt   draft-ietf-emu-eap-tls13-15.txt 
Network Working Group J. Preuss Mattsson Network Working Group J. Mattsson
Internet-Draft M. Sethi Internet-Draft M. Sethi
Updates: 5216 (if approved) Ericsson Updates: 5216 (if approved) Ericsson
Intended status: Standards Track June 26, 2021 Intended status: Standards Track May 4, 2021
Expires: December 28, 2021 Expires: November 5, 2021
Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-17 draft-ietf-emu-eap-tls13-15
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-Transport Layer
Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
with existing implementations of EAP-TLS. TLS 1.3 provides with existing implementations of EAP-TLS. TLS 1.3 provides
significantly improved security, privacy, and reduced latency when significantly improved security, privacy, and reduced latency when
compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS compared to earlier versions of TLS. EAP-TLS with TLS 1.3 further
1.3) further improves security and privacy by always providing improves security and privacy by always providing forward secrecy,
forward secrecy, never disclosing the peer identity, and by mandating never disclosing the peer identity, and by mandating use of
use of revocation checking. This document also provides guidance on revocation checking. This document also provides guidance on
authentication, authorization, and resumption for EAP-TLS in general authorization and resumption for EAP-TLS in general (regardless of
(regardless of the underlying TLS version used). This document the underlying TLS version 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 28, 2021. This Internet-Draft will expire on November 5, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements and Terminology . . . . . . . . . . . . . . 4 1.1. Requirements and Terminology . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4
2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 6 2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 5
2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 7 2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 6
2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 9 2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 11 2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 10
2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 14 2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 13
2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 15 2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 14
2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 16 2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 15
2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 17 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 16
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 18 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 17
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18
2.4. Parameter Negotiation and Compliance Requirements . . . . 20 2.4. Parameter Negotiation and Compliance Requirements . . . . 19
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 21 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 19
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 22 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 20
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 22 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 21
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 23 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 21
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 23 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 22
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 23 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 22
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 24 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 23
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 24 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 23
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 25 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 24
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 27 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 26
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 27
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Normative References . . . . . . . . . . . . . . . . . . 29 6.1. Normative References . . . . . . . . . . . . . . . . . . 28
6.2. Informative references . . . . . . . . . . . . . . . . . 31 6.2. Informative references . . . . . . . . . . . . . . . . . 29
Appendix A. Updated references . . . . . . . . . . . . . . . . . 34 Appendix A. Updated references . . . . . . . . . . . . . . . . . 33
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
provides a standard mechanism for support of multiple authentication provides a standard mechanism for support of multiple authentication
methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies
an EAP authentication method with certificate-based mutual an EAP authentication method with certificate-based mutual
authentication utilizing the TLS handshake protocol for cryptographic authentication utilizing the TLS handshake protocol for cryptographic
algorithms and protocol version negotiation and establishment of algorithms and protocol version negotiation and establishment of
shared secret keying material. EAP-TLS is widely supported for shared secret keying material. EAP-TLS is widely supported for
skipping to change at page 3, line 39 skipping to change at page 3, line 39
in large parts a complete remodeling of the TLS handshake protocol in large parts a complete remodeling of the TLS handshake protocol
including a different message flow, different handshake messages, including a different message flow, different handshake messages,
different key schedule, different cipher suites, different different key schedule, different cipher suites, different
resumption, different privacy protection, and different record resumption, different privacy protection, and different record
padding. This means that significant parts of the normative text in padding. This means that significant parts of the normative text in
the previous EAP-TLS specification [RFC5216] are not applicable to the previous EAP-TLS specification [RFC5216] are not applicable to
EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy
handling, and key derivation need to be appropriately addressed for handling, and key derivation need to be appropriately addressed for
EAP-TLS with TLS 1.3. EAP-TLS with TLS 1.3.
This document updates [RFC5216] to define how to use EAP-TLS with TLS This document defines how to use EAP-TLS with TLS 1.3 and does not
1.3. When older TLS versions are negotiated, RFC 5216 applies to change how EAP-TLS is used with older versions of TLS. It does
maintain backwards compatibility. However, this document does however provide additional guidance on authorization and resumption
provide additional guidance on authentication, authorization, and for EAP-TLS in general (regardless of the underlying TLS version
resumption for EAP-TLS regardless of the underlying TLS version used. used). While this document updates EAP-TLS [RFC5216], it remains
backwards compatible with it and existing implementations of EAP-TLS.
This document only describes differences compared to [RFC5216]. All This document only describes differences compared to [RFC5216]. All
message flow are example message flows specific to TLS 1.3 and do not message flow are example message flows specific to TLS 1.3 and do not
apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state
machine with the EAP state machine it is possible that new versions machine with the EAP state machine it is possible that new versions
of TLS will cause incompatibilities that introduce failures or of TLS will cause incompatibilities that introduce failures or
security issues if they are not carefully integrated into the EAP-TLS security issues if they are not carefully integrated into the EAP-TLS
protocol. Therefore, implementations MUST limit the maximum TLS protocol. Therefore, implementations MUST limit the maximum TLS
version they use to 1.3, unless later versions are explicitly enabled version they use to 1.3, unless later versions are explicitly enabled
by the administrator. 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]. [I-D.ietf-emu-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 the peer username is not
underlying peer identity is disclosed, is mandatory and achieved disclosed, is mandatory and achieved without any additional round-
without any additional round-trips. Revocation checking is mandatory trips. Revocation checking is mandatory and simplified with OCSP
and simplified with OCSP stapling, and TLS 1.3 introduces more stapling, and TLS 1.3 introduces more possibilities to reduce
possibilities to reduce fragmentation when compared to earlier fragmentation when compared to earlier versions of TLS.
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.
Readers are expected to be familiar with the terms and concepts used
in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is
used for the entity acting as EAP peer and TLS client. The term EAP-
TLS server is used for the entity acting as EAP server and TLS
server.
This document follows the terminology from [I-D.ietf-tls-rfc8446bis]
where the master secret is renamed to the main secret and the
exporter_master_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]. This section updates Section 2.1 of [RFC5216].
If the TLS implementation correctly implements TLS version
negotiation, EAP-TLS will automatically leverage that capability.
The EAP-TLS implementation needs to know which version of TLS was
negotiated to correctly support EAP-TLS 1.3 as well as to maintain
backward compatibility with EAP-TLS 1.2.
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.
5.7 this document applies only when TLS 1.3 is negotiated. When TLS
1.2 is negotiated, then [RFC5216] applies.
TLS 1.3 introduces several new handshake messages including
HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general,
these messages will be handled by the underlying TLS libraries and
are not visible to EAP-TLS, however there are a few things to note:
o The HelloRetryRequest is used by the server to reject the
parameters offered in the ClientHello and suggest new parameters.
When this message is encountered it will increase the number of
round trips used by the protocol.
o The NewSessionTicket message is used to convey resumption
information and is covered in Sections 2.1.2 and 2.1.3.
o The KeyUpdate message is used to update the traffic keys used on a
TLS connection. EAP-TLS does not encrypt significant amounts of
data so this functionality is not needed. Implementations SHOULD
NOT send this message, however some TLS libraries may
automatically generate and process this message.
o 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
EndOfEarlyData message.
o 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 document only lists additional specified in version 1.3 of TLS. This document 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]. This section updates Section 2.1.1 of [RFC5216].
The EAP-TLS server MUST authenticate with a certificate and SHOULD The EAP-TLS server MUST authenticate with a certificate and SHOULD
require the EAP-TLS peer to authenticate with a certificate. require the EAP-TLS peer to authenticate with a certificate.
Certificates can be of any type supported by TLS including raw public Certificates can be of any type supported by TLS including raw public
keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except
for resumption. 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" provide 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 ECDHE public keys). SessionID is deprecated in TLS 1.3,
see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early
application data which like all other application data is not used in application data which like all other application data is not used in
EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information EAP-TLS, see Section 4.2.10 of [RFC8446] for additional information
of the "early_data" extension. Resumption is handled as described in of the "early_data" extension. Resumption is handled as described in
Section 2.1.3. As a protected success indication [RFC3748] the EAP- Section 2.1.3. TLS 1.3 introduced the Post-Handshake KeyUpdate
TLS server always sends TLS application data 0x00, see Section 2.5. message which is not useful and not expected in EAP-TLS. As a
Note that a TLS implementation MAY not allow the EAP-TLS layer to protected success indication [RFC3748] the EAP-TLS server always
control in which order things are sent and the application data MAY sends TLS application data 0x00, see Section 2.5. Note that a TLS
therefore be sent before a NewSessionTicket. TLS application data implementation MAY not allow the EAP-TLS layer to control in which
0x00 is therefore to be interpreted as success after the EAP-Request order things are sent and the application data MAY therefore be sent
that contains TLS application data 0x00. After the EAP-TLS server before a NewSessionTicket. TLS application data 0x00 is therefore to
has sent an EAP-Request containing the TLS application data 0x00 and be interpreted as success after the EAP-Request that contains TLS
received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the application data 0x00. After the EAP-TLS server has received an
EAP-TLS server sends EAP-Success. empty EAP-Response to the EAP-Request containing the TLS application
data 0x00, the EAP-TLS server sends EAP-Success.
Figure 1 shows an example message flow for a successful EAP-TLS full 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/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished) <-------- TLS Finished)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS 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
skipping to change at page 8, line 21 skipping to change at page 7, line 21
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 [I-D.ietf-tls-ticketrequests].
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/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished) <-------- TLS Finished)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS NewSessionTicket, (TLS NewSessionTicket,
<-------- (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]. This section updates Section 2.1.2 of [RFC5216].
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 EAP
responses. Resumption significantly reduces the number of round- 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 security context of the new connection is
authenticated, and securely tied to the associated with the prior tied to the original connection and the key derived from the initial
authentication or resumption. It is up to the EAP-TLS peer to use handshake is used to bootstrap the cryptographic state instead of a
resumption, but it is RECOMMENDED that the EAP-TLS peer use full handshake. It is up to the EAP-TLS peer to use resumption, but
resumption if it has a valid ticket that has not been used before. it is RECOMMENDED that the EAP-TLS peer use resumption if it has a
It is left to the EAP-TLS server whether to accept resumption, but it valid ticket that has not been used before. It is left to the EAP-
is RECOMMENDED that the EAP-TLS server accept resumption if the TLS server whether to accept resumption, but it is RECOMMENDED that
ticket which was issued is still valid. However, the EAP-TLS server the EAP-TLS server accept resumption if the ticket which was issued
MAY choose to require a full handshake. In the case a full handshake is still valid. However, the EAP-TLS server MAY choose to require a
is required, the negotiation proceeds as if the session was a new full handshake. As in a full handshake, sending a NewSessionTicket
authentication, and resumption had never been requested. The during resumption is optional. As described in Appendix C.4 of
requirements of Sections 2.1.1 and 2.1.2 then apply in their [RFC8446], reuse of a ticket allows passive observers to correlate
entirety. As described in Appendix C.4 of [RFC8446], reuse of a different connections. EAP-TLS peers and EAP-TLS servers SHOULD
ticket allows passive observers to correlate different connections. follow the client tracking preventions in Appendix C.4 of [RFC8446].
EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking
preventions in Appendix C.4 of [RFC8446].
It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the
same realm 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
skipping to change at page 10, line 4 skipping to change at page 8, line 51
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 a 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/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
<-------- TLS Finished, <-------- TLS Finished,
TLS NewSessionTicket) TLS NewSessionTicket)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00) <-------- TLS Application Data 0x00)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
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 HelloRetryRequest to signal that additional information
is needed to complete the handshake, and the EAP-TLS peer needs to is needed to complete the handshake, and the EAP-TLS peer needs to
skipping to change at page 11, line 4 skipping to change at page 9, line 50
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 HelloRetryRequest to signal that additional information
is needed to complete the handshake, and the EAP-TLS peer needs to is needed to complete the handshake, and the EAP-TLS peer needs to
send a second ClientHello containing that information. Providing a send a second ClientHello containing that information. Providing a
"key_share" and using the "psk_dhe_ke" pre-shared key exchange mode "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode
is also important in order to limit the impact of a key compromise. is also important in order to limit the impact of a key compromise.
When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning
that key leakage does not compromise any earlier connections. The that key leakage does not compromise any earlier connections. It is
"psk_dh_ke" mechanism MUST be used for resumption unless the RECOMMMENDED to use "psk_dhe_ke" for resumption.
deployment has a local requirement to allow configuration of other
mechanisms.
2.1.4. Termination 2.1.4. Termination
This section updates Section 2.1.3 of [RFC5216]. This section updates Section 2.1.3 of [RFC5216].
TLS 1.3 changes both the message flow and the handshake messages TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS. Therefore, some normative text compared to earlier versions of TLS. Therefore, some normative text
in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3. The two in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3. The two
paragraphs below replaces the corresponding paragraphs in paragraphs below replaces the corresponding paragraphs in
Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3. The Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3. The
skipping to change at page 11, line 36 skipping to change at page 10, line 30
flow ends with the EAP-TLS server sending an EAP-Success message. flow ends with the EAP-TLS server sending an EAP-Success message.
If the EAP-TLS server authenticates successfully, the EAP-TLS peer If the EAP-TLS server authenticates successfully, the EAP-TLS peer
MUST send an EAP-Response message with EAP-Type=EAP-TLS containing MUST send an EAP-Response message with EAP-Type=EAP-TLS containing
TLS records conforming to the version of TLS used. TLS records conforming to the version of TLS used.
Figures 4, 5, and 6 illustrate message flows in several cases where Figures 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_cancelled", 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 strengthen 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
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Error Alert) <-------- (TLS Error Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Failure <-------- EAP-Failure
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/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished) <-------- TLS Finished)
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 sends a TLS Error
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/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished) <-------- TLS Finished)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS 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
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished) <-------- TLS Finished)
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
skipping to change at page 16, line 8 skipping to change at page 15, line 8
"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)
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 HelloRetryRequest) (TLS HelloRetryRequest)
<-------- <--------
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS 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 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 8: EAP-TLS with Hello Retry Request Figure 8: EAP-TLS with Hello Retry Request
2.1.7. Identity 2.1.7. Identity
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity
Response as such identities are routable and privacy-friendly. While Response as such identities are routable and privacy-friendly. While
opaque blobs are allowed by [RFC3748], such identities are NOT opaque blobs are allowed by [RFC3748], such identities are NOT
skipping to change at page 17, line 17 skipping to change at page 16, line 17
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 a 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]. This section updates Section 2.1.4 of [RFC5216].
EAP-TLS 1.3 significantly improves privacy when compared to earlier TLS 1.3 significantly improves privacy when compared to earlier
versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites without versions of TLS by forbidding cipher suites without confidentiality
confidentiality which means that TLS 1.3 is always encrypting large and encrypting large parts of the TLS handshake including the
parts of the TLS handshake including the certificate messages. 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 in
[RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its username
in cleartext in the Identity Response. Following [RFC7542], it is in cleartext in the Identity Response. Following [RFC7542], it is
RECOMMENDED to omit the username (i.e., the NAI is @realm), but other RECOMMENDED to omit the username (i.e., the NAI is @realm), but other
constructions such as a fixed username (e.g. anonymous@realm) or an constructions such as a fixed username (e.g. anonymous@realm) or an
encrypted username (e.g., 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
skipping to change at page 18, line 24 skipping to change at page 17, line 24
EAP packet exchanges that can be handled. To avoid fragmentation, it EAP packet exchanges that can be handled. To avoid fragmentation, it
is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and
trust anchor certificates small and the length of the certificate trust anchor certificates small and the length of the certificate
chains short. In addition, it is RECOMMENDED to use mechanisms that chains short. In addition, it is RECOMMENDED to use mechanisms that
reduce the sizes of Certificate messages. For a detailed discussion reduce the sizes of Certificate messages. For a detailed discussion
on reducing message sizes to prevent fragmentation, see on reducing message sizes to prevent fragmentation, see
[I-D.ietf-emu-eaptlscert]. [I-D.ietf-emu-eaptlscert].
2.2. Identity Verification 2.2. Identity Verification
This section updates Section 2.2 of [RFC5216]. The guidance in this This section updates Section 2.2 of [RFC5216].
section is relevant for EAP-TLS in general (regardless of the
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 SHALL 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). EAP peer implementations SHOULD
extension. Since EAP-TLS deployments may use more than one EAP allow users to configuring a unique trust root (CA certificate) and a
server, each with a different certificate, EAP peer implementations server name to authenticate the server certificate and match the
SHOULD allow for the configuration of a unique trusted root (CA subjectAlternativeName (SAN) extension in the server certificate with
certificate) to authenticate the server certificate and one or more the configured server name. In the absence of a user-configured root
server names to match against the SubjectAltName (SAN) extension in CA certificate, implementations MAY rely on system-wide root CA
the server certificate. To simplify name matching, an EAP-TLS certificate bundles for authenticating the server certificate. If
deployment can assign a name to represent an authorized EAP server server name matching is not used, then peers may end up trusting
and EAP Server certificates can include this name in the list of SANs servers for EAP authentication that are not intended to be EAP
for each certificate that represents an EAP-TLS server. If server servers for the network. If name matching is not used with a public
name matching is not used, then peers may end up trusting servers for CA bundle, then effectively any server can obtain a certificate which
EAP authentication that are not intended to be EAP servers for the will be trusted for EAP authentication by the Peer.
network. If name matching is not used with a public root CA, then
effectively any server can obtain a certificate which will be trusted
for EAP authentication by the Peer. While this requirement to verify
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
this section contains minimal new interoperability or implementation
requirements on EAP-TLS peers and can be applied to earlier versions
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 and 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 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.
including ones where multiple EAP servers are deployed for high
availability. TOFU mechanisms increase the susceptibility to traffic
interception attacks and should only be used if there are adequate
controls in place to mitigate this risk.
2.3. Key Hierarchy 2.3. Key Hierarchy
This section updates Section 2.3 of [RFC5216]. This section updates Section 2.3 of [RFC5216].
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 HKDF and completely changes the Key Schedule.
The key hierarchies shown in Section 2.3 of [RFC5216] are therefore The key hierarchies shown in Section 2.3 of [RFC5216] are therefore
not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3
the key schedule is described in Section 7.1 of [RFC8446]. 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, IV, 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]).
defined in Section 2 of [RFC3748]. For EAP-TLS the Type field has
value 0x0D.
Type = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type, 128)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
Type, 64)
Session-Id = Type || Method-Id
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
below for simplicity:
MSK = Key_Material(0, 63) Type-Code = 0x0D
EMSK = Key_Material(64, 127) MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)
EMSK = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)
Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)
Session-Id = Type-Code || Method-Id
Other TLS based EAP methods can use the TLS exporter in a similar Other TLS based EAP methods can use the TLS exporter in a similar
fashion, see [I-D.ietf-emu-tls-eap-types]. fashion, see [I-D.ietf-emu-tls-eap-types].
[RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are [RFC5247] deprecates the use of IV. Thus, RECV-IV and SEND-IV are
not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower
layers use the MSK in a lower-layer dependent manner. EAP-TLS with layers use the MSK in a lower-layer dependent manner. EAP-TLS with
TLS 1.3 exports the MSK and does not specify how it is used by lower TLS 1.3 exports the MSK and does not specify how it used by lower
layers. 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 EAP-TLS with without having to extract the Main Secret, ClientHello.random, and
TLS 1.2 [RFC5216] can be used with the TLS exporter since the public ServerHello.random in a non-standard way.
exporter was defined in [RFC5705].
2.4. Parameter Negotiation and Compliance Requirements 2.4. Parameter Negotiation and Compliance Requirements
This section updates Section 2.4 of [RFC5216]. This section updates Section 2.4 of [RFC5216].
TLS 1.3 cipher suites are defined differently than in earlier TLS 1.3 cipher suites are defined differently than in earlier
versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites
discussed in Section 2.4 of [RFC5216] can therefore not be used when discussed in Section 2.4 of [RFC5216] can therefore not be used when
EAP-TLS is used with TLS version 1.3. 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.) for the TLS version used. For TLS 1.3 algorithms, extensions, etc.) for the TLS version used. For TLS 1.3
the compliance requirements are defined in Section 9 of [RFC8446]. the compliance requirements are defined in Section 9 of [RFC8446].
In EAP-TLS with TLS 1.3, only cipher suites with confidentiality In EAP-TLS with TLS 1.3, only cipher suites with confidentiality
SHALL be supported. SHALL be supported.
While EAP-TLS does not protect any application data except for the While EAP-TLS does not protect any application data except for the
TLS record with application data 0x00, the negotiated cipher suites Commitment Message, the negotiated cipher suites and algorithms MAY
and algorithms MAY be used to secure data as done in other TLS-based be used to secure data as done in other TLS-based EAP methods.
EAP methods.
2.5. EAP State Machines 2.5. EAP State Machines
This is a new section when compared to [RFC5216] and only applies to This is a new section when compared to [RFC5216] and only applies to
TLS 1.3. [RFC4137] offers a proposed state machine for EAP. TLS 1.3. [RFC4137] offers a proposed state machine for EAP.
TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post-
Handshake messages use the handshake content type and can be sent Handshake messages use the handshake content type and can be sent
after the main handshake. Examples of Post-Handshake messages are after the main handshake. Examples of Post-Handshake messages are
NewSessionTicket, which is used for resumption and KeyUpdate, which NewSessionTicket, which is used for resumption and KeyUpdate, which
is not useful and not expected in EAP-TLS. After sending TLS is not useful and not expected in EAP-TLS. After sending TLS
Finished, the EAP-TLS server may send any number of Post-Handshake Finished, the EAP-TLS server may send any number of Post-Handshake
messages in separate EAP-Requests. messages in separate EAP-Requests.
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), it sends an encrypted TLS record with application data Handshake), it commits to not sending any more handshake messages by
0x00. The encrypted TLS record with application data 0x00 is a sending an encrypted TLS record with application data 0x00. The
protected success result indication, as defined in [RFC3748]. After encrypted TLS record with application data 0x00 is a protected
sending a EAP-Request that contains the protected success result success result indication, as defined in [RFC3748]. After sending an
indication, the EAP-TLS server must not send any more EAP-Request and encrypted TLS record with application data 0x00, the EAP-TLS server
may only send an EAP-Success. The EAP-TLS server MUST NOT send an may only send an EAP-Success. The EAP-TLS server MUST NOT send an
encrypted TLS record with application data 0x00 alert before it has encrypted TLS record with application data 0x00 alert 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] sets the defined in [RFC3748]. Implementations following [RFC4137] sets 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
skipping to change at page 22, line 19 skipping to change at page 20, line 39
No updates to Section 3 of [RFC5216]. No updates to Section 3 of [RFC5216].
4. IANA considerations 4. IANA considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the EAP- Authority (IANA) regarding registration of values related to the EAP-
TLS 1.3 protocol in accordance with [RFC8126]. TLS 1.3 protocol in accordance with [RFC8126].
This document requires IANA to add the following labels to the TLS This document requires IANA to add the following labels to the TLS
Exporter Label Registry defined by [RFC5705]. These labels are used Exporter Label Registry defined by [RFC5705]. These labels are used
in derivation of Key_Material and Method-Id as defined in in derivation of Key_Material, IV and Method-Id as defined in
Section 2.3: Section 2.3:
+-------------------------------+---------+-------------+------+ +----------------------------+---------+-------------+------+
| Value | DTLS-OK | Recommended | Note | | Value | DTLS-OK | Recommended | Note |
+-------------------------------+---------+-------------+------+ +----------------------------+---------+-------------+------+
| EXPORTER_EAP_TLS_Key_Material | N | Y | | | EXPORTER_EAP_TLS_MSK | N | Y | |
| | | | | | | | | |
| EXPORTER_EAP_TLS_Method-Id | N | Y | | | EXPORTER_EAP_TLS_EMSK | N | Y | |
+-------------------------------+---------+-------------+------+ | | | | |
| EXPORTER_EAP_TLS_Method-Id | N | Y | |
+----------------------------+---------+-------------+------+
Table 1: TLS Exporter Label Registry Table 1: TLS Exporter Label Registry
5. Security Considerations 5. Security Considerations
5.1. Security Claims 5.1. Security Claims
Using EAP-TLS with TLS 1.3 does not change the security claims for Using EAP-TLS with TLS 1.3 does not change the security claims for
EAP-TLS as given in Section 5.1 of [RFC5216]. However, it EAP-TLS as given in Section 5.1 of [RFC5216]. However, it
strengthens several of the claims as described in the following strengthens several of the claims as described in the following
skipping to change at page 23, line 10 skipping to change at page 21, line 42
mandates use of cipher suites that ensure confidentiality. TLS 1.3 mandates use of cipher suites that ensure confidentiality. TLS 1.3
also encrypts certificates and some of the extensions. When using also encrypts certificates and some of the extensions. When using
EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not
cause any additional round-trips. 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, CBC
mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated. mode, RC4, SHA-1, MD5, P-192, and RSA-1024 cannot be negotiated.
[4] Cryptographic Negotiation: The TLS layer handles the negotiation [4] Cryptographic Negotiation: TLS 1.3 increases the number of
of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP- cryptographic parameters that are negotiated in the handshake. When
TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic
hash algorithm, key exchange groups, and signature algorithm, see negotiation of AEAD algorithm, HKDF hash algorithm, key exchange
Section 4.1.1 of [RFC8446]. groups, and signature algorithm, see Section 4.1.1 of [RFC8446].
5.2. Peer and Server Identities 5.2. Peer and Server Identities
No updates to section 5.2 of [RFC5216]. Note that Section 2.2 has No updates to section 5.2 of [RFC5216].
additional discussion on identities.
5.3. Certificate Validation 5.3. Certificate Validation
No updates to section 5.3 of [RFC5216]. No updates to section 5.3 of [RFC5216].
5.4. Certificate Revocation 5.4. Certificate Revocation
This section updates Section 5.4 of [RFC5216]. This section updates Section 5.4 of [RFC5216].
There are a number of reasons (e.g., key compromise, CA compromise, While certificates may have long validity periods, there are a number
privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub- of reasons (e.g., key compromise, CA compromise, privilege withdrawn,
CA certificates have to be revoked before their expiry date. etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have
Revocation of the EAP-TLS server's certificate is complicated by the to be revoked before their expiry date. Revocation of the EAP-TLS
fact that the EAP-TLS peer may not have Internet connectivity until server's certificate is complicated by the fact that the EAP-TLS peer
authentication completes. may not have Internet connectivity until authentication completes.
When EAP-TLS is used with TLS 1.3, the revocation status of all the When EAP-TLS is used with TLS 1.3, the revocation status of all the
certificates in the certificate chains MUST be checked (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 Certificate Revocation List
(CRL), Online Certificate Status Protocol (OSCP), or other (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
skipping to change at page 25, line 4 skipping to change at page 23, line 36
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, implementations
implementations MUST take care to limit network access appropriately MUST take care to limit network access appropriately for
for unauthenticated peers and implementations MUST use resumption unauthenticated peers and implementations MUST use resumption with
with caution to ensure that a resumed session is not granted more 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.
limiting network access would be to invoke a vendor's walled garden
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 PANA [RFC5191].
The encapsulating protocols can also provide additional, non-EAP 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, WiFi above or below EAP (MAC addresses, IP addresses, port numbers, WiFi
SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those SSID, etc.). EAP-TLS servers implementing EAP-TLS inside those
protocols can make policy decisions and enforce authorization based protocols can make policy decisions and enforce authorization based
skipping to change at page 25, line 45 skipping to change at page 24, line 28
address of the authenticator does not match the expected policy. address of the authenticator does not match the expected policy.
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 applies to all 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 in a secure way, the EAP-TLS peer and layer. To perform resumption in a secure way, the EAP-TLS peer and
EAP-TLS server need to be able to securely retrieve authorization EAP-TLS server need to be able to securely retrieve authorization
information such as certificate chains from the initial full information such as certificate chains from the initial full
handshake. This document use the term "cached data" to describe such handshake. We use the term "cached data" to describe such
information. Authorization during resumption MUST be based on such information. Authorization during resumption MUST be based on such
cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh
revocation checks on the cached certificate data. Any security revocation checks on the cached certificate data. Any security
policies for authorization MUST be followed also for resumption. The policies for authorization MUST be followed also for resumption. The
certificates may have been revoked since the initial full handshake certificates may have been revoked since the initial full handshake
and the authorizations of the other party may have reduced. If the and the authorizations of the other party may have 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
skipping to change at page 26, line 30 skipping to change at page 25, line 12
[RFC8446], where the EAP-TLS server avoids storing information [RFC8446], where the EAP-TLS server avoids storing information
locally and instead encapsulates the information into a ticket or PSK locally and instead encapsulates the information into a ticket or PSK
which is sent to the client for storage. This ticket or PSK is which is sent to the client for storage. This ticket or PSK is
encrypted using a key that only the EAP-TLS server knows. Note that encrypted using a key that only the EAP-TLS server knows. Note that
the client still needs to cache the original handshake information the client still needs to cache the original handshake information
locally and will use the session ID or PSK identity to lookup this locally and will use the session ID or PSK identity to lookup this
information during resumption. However, the EAP-TLS server is able information during resumption. However, the EAP-TLS server is able
to decrypt the ticket or PSK to obtain the original handshake to decrypt the ticket or PSK to obtain the original handshake
information. information.
The EAP-TLS server or EAP client MUST cache data during the initial If the EAP-TLS server or EAP client do not apply any authorization
full handshake sufficient to allow authorization decisions to be made policies, they MAY allow resumption where no cached data is
during resumption. If cached data cannot be retrieved in a secure available. In all other cases, they MUST cache data during the
way, resumption MUST NOT be done. initial full handshake to enable resumption. The cached data MUST be
sufficient to make authorization decisions during resumption. If
cached data cannot be retrieved in a secure way, resumption MUST NOT
be done.
The above requirements also apply if the EAP-TLS server expects some The above requirements also apply if the EAP-TLS server expects some
system to perform accounting for the session. Since accounting must system to perform accounting for the session. Since accounting must
be tied to an authenticated identity, and resumption does not supply be tied to an authenticated identity, and resumption does not supply
such an identity, accounting is impossible without access to cached such an identity, accounting is impossible without access to cached
data. Therefore systems which expect to perform accounting for the data. Therefore systems which expect to perform accounting for the
session SHOULD cache an identifier which can be used in subsequent session SHOULD cache an identifier which can be used in subsequent
accounting. accounting.
As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption
PSKs or tickets (and associated cached data) for longer than 604800 PSKs or tickets (and associated cached data) for longer than 7 days,
seconds (7 days), regardless of the PSK or ticket lifetime. The EAP- regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY
TLS peer MAY delete them earlier based on local policy. The cached delete them earlier based on local policy. The cached data MAY also
data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any be removed on the EAP-TLS server or EAP-TLS peer if any certificate
certificate in the certificate chain has been revoked or has expired. in the certificate chain has been revoked or has expired. In all
In all such cases, an attempt at resumption results in a full TLS such cases, an attempt at resumption results in a full TLS handshake
handshake instead. instead.
Information from the EAP-TLS exchange (e.g., the identity provided in Information from the EAP-TLS exchange (e.g., the identity provided in
EAP-Response/Identity) as well as non-EAP information (e.g., IP EAP-Response/Identity) as well as non-EAP information (e.g., IP
addresses) may change between the initial full handshake and addresses) may change between the initial full handshake and
resumption. This change creates a "time-of-check time-of-use" resumption. This change creates a "time-of-check time-of-use"
(TOCTOU) security vulnerability. A malicious or compromised user (TOCTOU) security vulnerability. A malicious or compromised user
could supply one set of data during the initial authentication, and a could supply one set of data during the initial authentication, and a
different set of data during resumption, potentially allowing them to different set of data during resumption, potentially allowing them to
obtain access that they should not have. obtain access that they should not have.
skipping to change at page 31, line 22 skipping to change at page 29, line 49
[I-D.ietf-emu-tls-eap-types] [I-D.ietf-emu-tls-eap-types]
DeKok, A., "TLS-based EAP types and TLS 1.3", draft-ietf- DeKok, A., "TLS-based EAP types and TLS 1.3", draft-ietf-
emu-tls-eap-types-02 (work in progress), February 2021. emu-tls-eap-types-02 (work in progress), February 2021.
[I-D.ietf-tls-md5-sha1-deprecate] [I-D.ietf-tls-md5-sha1-deprecate]
Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf- MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf-
tls-md5-sha1-deprecate-06 (work in progress), March 2021. tls-md5-sha1-deprecate-06 (work in progress), March 2021.
[I-D.ietf-tls-rfc8446bis]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-rfc8446bis-01 (work in
progress), February 2021.
[I-D.ietf-tls-ticketrequests] [I-D.ietf-tls-ticketrequests]
Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket
Requests", draft-ietf-tls-ticketrequests-07 (work in Requests", draft-ietf-tls-ticketrequests-07 (work in
progress), December 2020. progress), December 2020.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information technology--Telecommunications Standard for Information technology--Telecommunications
and information exchange between systems Local and and information exchange between systems Local and
metropolitan area networks--Specific requirements - Part metropolitan area networks--Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11-2020 , Layer (PHY) Specifications", IEEE Std 802.11-2016
February 2021. (Revision of IEEE Std 802.11-2012) , December 2016.
[IEEE-802.1AE] [IEEE-802.1AE]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Media Standard for Local and metropolitan area networks -- Media
Access Control (MAC) Security", IEEE Standard Access Control (MAC) Security", IEEE Standard
802.1AE-2018 , December 2018. 802.1AE-2018 , December 2018.
[IEEE-802.1X] [IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Port- Standard for Local and metropolitan area networks -- Port-
Based Network Access Control", IEEE Standard 802.1X-2020 , Based Network Access Control", IEEE Standard 802.1X-2020 ,
February 2020. January 2020.
[MulteFire] [MulteFire]
MulteFire, "MulteFire Release 1.1 specification", 2019. MulteFire, "MulteFire Release 1.1 specification", 2019.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible [PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", April 2021. Authentication Protocol (PEAP)", 2018.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<https://www.rfc-editor.org/info/rfc1661>. <https://www.rfc-editor.org/info/rfc1661>.
[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,
<https://www.rfc-editor.org/info/rfc2246>. <https://www.rfc-editor.org/info/rfc2246>.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
skipping to change at page 34, line 27 skipping to change at page 32, line 49
Architecture for Network Roaming", RFC 7593, Architecture for Network Roaming", RFC 7593,
DOI 10.17487/RFC7593, September 2015, DOI 10.17487/RFC7593, September 2015,
<https://www.rfc-editor.org/info/rfc7593>. <https://www.rfc-editor.org/info/rfc7593>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
[TS.33.501] [TS.33.501]
3GPP, "Security architecture and procedures for 5G 3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501 17.1.0, April 2021. System", 3GPP TS 33.501 17.0.0, December 2020.
Appendix A. Updated references Appendix A. Updated references
All the following references in [RFC5216] are updated as specified All the following references in [RFC5216] are updated as specified
below when EAP-TLS is used with TLS 1.3. below when EAP-TLS is used with TLS 1.3.
All references to [RFC2560] are updated with [RFC6960]. All references to [RFC2560] are updated with [RFC6960].
All references to [RFC3280] are updated with [RFC5280]. All references to [RFC3280] are updated with [RFC5280].
All references to [RFC4282] are updated with [RFC7542]. All references to [RFC4282] are updated with [RFC7542].
Acknowledgments Acknowledgments
The authors want to thank Bernard Aboba, Jari Arkko, 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 Keraenen, 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, and Hannes Tschofenig for comments and suggestions on the
suggestions on the draft. Special thanks to the document shepard draft.
Joseph Salowey.
Contributors Contributors
Alan DeKok, FreeRADIUS Alan DeKok, FreeRADIUS
Authors' Addresses Authors' Addresses
John Preuss Mattsson John Preuss Mattsson
Ericsson Ericsson
Stockholm 164 40 Stockholm 164 40
 End of changes. 110 change blocks. 
324 lines changed or deleted 245 lines changed or added

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