draft-ietf-emu-eap-tls13-18.txt   draft-ietf-emu-eap-tls13-19.txt 
Network Working Group J. Preuss Mattsson Network Working Group J. Preuß Mattsson
Internet-Draft M. Sethi Internet-Draft M. Sethi
Updates: 5216 (if approved) Ericsson Updates: 5216 (if approved) Ericsson
Intended status: Standards Track July 9, 2021 Intended status: Standards Track 3 August 2021
Expires: January 10, 2022 Expires: 4 February 2022
Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)
draft-ietf-emu-eap-tls13-18 draft-ietf-emu-eap-tls13-19
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 (EAP-TLS
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 January 10, 2022. This Internet-Draft will expire on 4 February 2022.
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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 4 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 5
2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 6 2.1.1. Authentication . . . . . . . . . . . . . . . . . . . 6
2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 7 2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 7
2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 9 2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 11 2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 12
2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 14 2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 15
2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 15 2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 16
2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 16 2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 17
2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 17 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 18
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 18 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 19
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 19 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 20
2.4. Parameter Negotiation and Compliance Requirements . . . . 20 2.4. Parameter Negotiation and Compliance Requirements . . . . 21
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 21 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 22
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 22 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 23
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 22 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 23
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 23 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 24
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 23 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 24
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 23 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 24
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 24 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 25
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 24 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 26
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 25 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 26
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 27 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 28
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 30
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 30
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.11. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 30
6.1. Normative References . . . . . . . . . . . . . . . . . . 29 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Informative references . . . . . . . . . . . . . . . . . 31 6.1. Normative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Updated references . . . . . . . . . . . . . . . . . 34 6.2. Informative references . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Updated References . . . . . . . . . . . . . . . . . 36
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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 44 skipping to change at page 4, line 10
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 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]. All This document only describes differences compared to [RFC5216]. When
message flow are example message flows specific to TLS 1.3 and do not EAP-TLS is used with TLS 1.3, some references are updated as
apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state specified in Appendix A. All message flow are example message flows
machine with the EAP state machine it is possible that new versions specific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS
of TLS will cause incompatibilities that introduce failures or couples the TLS handshake state machine with the EAP state machine it
security issues if they are not carefully integrated into the EAP-TLS is possible that new versions of TLS will cause incompatibilities
protocol. Therefore, implementations MUST limit the maximum TLS that introduce failures or security issues if they are not carefully
version they use to 1.3, unless later versions are explicitly enabled integrated into the EAP-TLS protocol. Therefore, implementations
by the administrator. MUST limit the maximum TLS version they use to 1.3, unless later
versions are explicitly enabled by the administrator.
This document specifies EAP-TLS 1.3 and does not specify how other 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 no information about the
underlying peer identity is disclosed, is mandatory and achieved underlying peer identity is disclosed, is mandatory and achieved
skipping to change at page 5, line 22 skipping to change at page 5, line 38
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 document applies only when TLS 1.3 is negotiated. When TLS 5.7 this document 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:
o 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.
o 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.
o 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.
o 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.
o 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 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" 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 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. As a protected success indication [RFC3748] the EAP-
TLS server always sends TLS application data 0x00, see Section 2.5. TLS server always sends TLS application data 0x00, see Section 2.5.
Note that a TLS implementation MAY not allow the EAP-TLS layer to Note that a TLS implementation MAY not allow the EAP-TLS layer to
control in which order things are sent and the application data MAY control in which order things are sent and the application data MAY
therefore be sent before a NewSessionTicket. TLS application data therefore be sent before a NewSessionTicket. TLS application data
0x00 is therefore to be interpreted as success after the EAP-Request 0x00 is therefore to be interpreted as success after the EAP-Request
that contains TLS application data 0x00. After the EAP-TLS server that contains TLS application data 0x00. After the EAP-TLS server
has sent an EAP-Request containing the TLS application data 0x00 and has sent an EAP-Request containing the TLS application data 0x00 and
received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the
EAP-TLS server sends EAP-Success. 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)
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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 in ticket depends on the client Finished and cannot be pre-computed in
handshakes with client authentication. The NewSessionTicket message handshakes with client authentication. The NewSessionTicket message
skipping to change at page 8, line 51 skipping to change at page 8, line 51
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
skipping to change at page 10, line 41 skipping to change at page 11, line 33
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
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
skipping to change at page 11, line 18 skipping to change at page 12, line 12
deployment has a local requirement to allow configuration of other deployment has a local requirement to allow configuration of other
mechanisms. 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 replace 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
other paragraphs in Section 2.1.3 of [RFC5216] still apply with the other paragraphs in Section 2.1.3 of [RFC5216] still apply with the
exception that SessionID is deprecated. exception that SessionID is deprecated.
If the EAP-TLS peer authenticates successfully, the EAP-TLS server If the EAP-TLS peer authenticates successfully, the EAP-TLS server
MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing
TLS records conforming to the version of TLS used. The message TLS records conforming to the version of TLS used. The message
flow ends with the EAP-TLS server sending an EAP-Success message. flow ends with a protected success indication from the EAP-TLS
server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and
no data from the EAP-TLS peer, follwed by EAP-Success from the
server.
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
skipping to change at page 13, line 31 skipping to change at page 14, line 31
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 38 skipping to change at page 15, line 38
(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 16, line 44 skipping to change at page 17, line 44
(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
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-
skipping to change at page 17, line 27 skipping to change at page 18, line 27
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 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
Section 2.2 of [RFC7542]. Section 2.2 of [RFC7542].
As the certificate messages in TLS 1.3 are encrypted, there is no As the certificate messages in TLS 1.3 are encrypted, there is no
need to send an empty certificate_list and perform a second handshake need to send an empty certificate_list and perform a second handshake
for privacy (as needed by EAP-TLS with earlier versions of TLS). for privacy (as needed by EAP-TLS with earlier versions of TLS).
When EAP-TLS is used with TLS version 1.3 the EAP-TLS peer and EAP- When EAP-TLS is used with TLS version 1.3 the EAP-TLS peer and EAP-
TLS server SHALL follow the processing specified by version 1.3 of TLS server SHALL follow the processing specified by version 1.3 of
skipping to change at page 20, line 46 skipping to change at page 21, line 46
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.) defined in Section 9 of [RFC8446]. In
the compliance requirements are defined in Section 9 of [RFC8446]. EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL
In EAP-TLS with TLS 1.3, only cipher suites with confidentiality 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 TLS record with application data 0x00, the negotiated cipher suites
and algorithms MAY be used to secure data as done in other TLS-based and algorithms MAY 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 message), it sends an encrypted TLS record with application
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 a 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-Request and
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
skipping to change at page 22, line 22 skipping to change at page 23, line 25
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 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 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
skipping to change at page 26, line 4 skipping to change at page 27, line 14
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 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 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. This document uses the term "cached data" to describe
information. Authorization during resumption MUST be based on such such information. Authorization during resumption MUST be based on
cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh such cached data. The EAP-TLS peer and EAP-TLS server MAY perform
revocation checks on the cached certificate data. Any security fresh 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
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
skipping to change at page 29, line 37 skipping to change at page 30, line 45
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] provides recommendations for improving the security BCP 195 [RFC7525] provides recommendations for improving the security
of deployed services that use TLS. However, many of the attacks are of deployed services that use TLS. However, many of the attacks are
less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and
does not protect any application data. EAP-TLS implementations MUST does not protect any application data. EAP-TLS implementations MUST
mitigate known attacks. EAP-TLS implementations need to monitor and mitigate known attacks. EAP-TLS implementations need to monitor and
follow new EAP and TLS related security guidance and requirements follow new EAP and TLS related security guidance and requirements
such as [RFC8447], [RFC8996], [I-D.ietf-tls-md5-sha1-deprecate]. such as [RFC8447], [RFC8996], [I-D.ietf-tls-md5-sha1-deprecate].
5.11. Cross-Protocol Attacks
This is a new section when compared to [RFC5216].
Allowing the same certificate to be used in multiple protocols can
potentially allow an attacker to authenticate via one protocol, and
then "resume" that session in another protocol. Section 2.2 above
suggests that certificates typically have one or more FQDNs in the
SAN extension. However, those fields are for EAP validation only,
and do not indicate that the certificates are suitable for use on WWW
(or other) protocol server on the named host.
Section 2.1.3 above suggests that authorization rules should be re-
applied on resumption, but does not mandate this behavior. As a
result, this cross-protocol resumption could allow the attacker to
bypass authorization policies, and to obtain undesired access to
secured systems. Along with making sure that appropriate
authorization information is available and used during resumption,
using different certificates and resumption caches for different
protocols is RECOMMENDED to help keep different protocol usages
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>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
skipping to change at page 31, line 7 skipping to change at page 32, line 34
[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>.
[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>.
6.2. Informative references 6.2. Informative references
[I-D.ietf-emu-eaptlscert] [IEEE-802.1X]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large Institute of Electrical and Electronics Engineers, "IEEE
Certificates and Long Certificate Chains in TLS-based EAP Standard for Local and metropolitan area networks -- Port-
Methods", draft-ietf-emu-eaptlscert-08 (work in progress), Based Network Access Control", IEEE Standard 802.1X-2020 ,
November 2020. February 2020.
[I-D.ietf-emu-tls-eap-types]
DeKok, A., "TLS-based EAP types and TLS 1.3", draft-ietf-
emu-tls-eap-types-02 (work in progress), February 2021.
[I-D.ietf-tls-md5-sha1-deprecate]
Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf-
tls-md5-sha1-deprecate-06 (work in progress), March 2021.
[I-D.ietf-tls-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]
Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket
Requests", draft-ietf-tls-ticketrequests-07 (work in
progress), December 2020.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information technology--Telecommunications Standard for Information technology—Telecommunications and
and information exchange between systems Local 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 Standard 802.11-2020 ,
February 2021. February 2021.
[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] [TS.33.501]
Institute of Electrical and Electronics Engineers, "IEEE 3GPP, "Security architecture and procedures for 5G
Standard for Local and metropolitan area networks -- Port- System", 3GPP TS 33.501 17.2.1, July 2021.
Based Network Access Control", IEEE Standard 802.1X-2020 ,
February 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)", April 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>.
skipping to change at page 34, line 25 skipping to change at page 35, line 36
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam [RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
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] [I-D.ietf-tls-md5-sha1-deprecate]
3GPP, "Security architecture and procedures for 5G Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
System", 3GPP TS 33.501 17.1.0, April 2021. MD5 and SHA-1 signature hashes in TLS 1.2", Work in
Progress, Internet-Draft, draft-ietf-tls-md5-sha1-
deprecate-07, 17 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-md5-sha1-
deprecate-07.txt>.
Appendix A. Updated references [I-D.ietf-emu-eaptlscert]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large
Certificates and Long Certificate Chains in TLS-based EAP
Methods", Work in Progress, Internet-Draft, draft-ietf-
emu-eaptlscert-08, 20 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-emu-
eaptlscert-08.txt>.
[I-D.ietf-tls-ticketrequests]
Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket
Requests", Work in Progress, Internet-Draft, draft-ietf-
tls-ticketrequests-07, 3 December 2020,
<https://www.ietf.org/archive/id/draft-ietf-tls-
ticketrequests-07.txt>.
[I-D.ietf-emu-tls-eap-types]
DeKok, A., "TLS-based EAP types and TLS 1.3", Work in
Progress, Internet-Draft, draft-ietf-emu-tls-eap-types-03,
22 June 2021, <https://www.ietf.org/archive/id/draft-ietf-
emu-tls-eap-types-03.txt>.
[I-D.ietf-tls-rfc8446bis]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-01, 19 February 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-
rfc8446bis-01.txt>.
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].
skipping to change at page 35, line 10 skipping to change at page 37, line 4
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 shepard suggestions on the draft. Special thanks to the document shepard
Joseph Salowey. Joseph Salowey.
Contributors Contributors
Alan DeKok, FreeRADIUS Alan DeKok, FreeRADIUS
Authors' Addresses Authors' Addresses
John Preuß Mattsson
John Preuss Mattsson
Ericsson Ericsson
Stockholm 164 40 SE-164 40 Stockholm
Sweden Sweden
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Jorvas 02420 FI-02420 Jorvas
Finland Finland
Email: mohit@piuha.net Email: mohit@piuha.net
 End of changes. 42 change blocks. 
129 lines changed or deleted 165 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/