draft-ietf-emu-eap-tls13-11.txt   draft-ietf-emu-eap-tls13-12.txt 
Network Working Group J. Mattsson Network Working Group J. Mattsson
Internet-Draft M. Sethi Internet-Draft M. Sethi
Updates: 5216 (if approved) Ericsson Updates: 5216 (if approved) Ericsson
Intended status: Standards Track October 14, 2020 Intended status: Standards Track November 2, 2020
Expires: April 17, 2021 Expires: May 6, 2021
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-11 draft-ietf-emu-eap-tls13-12
Abstract Abstract
This document specifies the use of EAP-TLS with TLS 1.3 while This document specifies the use of EAP-TLS with TLS 1.3 while
remaining backwards compatible with existing implementations of EAP- remaining backwards compatible with existing implementations of EAP-
TLS. TLS 1.3 provides significantly improved security, privacy, and TLS. TLS 1.3 provides significantly improved security, privacy, and
reduced latency when compared to earlier versions of TLS. EAP-TLS reduced latency when compared to earlier versions of TLS. EAP-TLS
with TLS 1.3 further improves security and privacy by mandating use with TLS 1.3 further improves security and privacy by mandating use
of privacy and revocation checking. This document also provides of privacy and revocation checking. This document also provides
guidance on authorization and resumption for EAP-TLS in general guidance on authorization and resumption for EAP-TLS in general
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 April 17, 2021. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 26 skipping to change at page 2, line 26
2.1.1. Mutual Authentication . . . . . . . . . . . . . . . . 4 2.1.1. Mutual Authentication . . . . . . . . . . . . . . . . 4
2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 5 2.1.2. Ticket Establishment . . . . . . . . . . . . . . . . 5
2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 6 2.1.3. Resumption . . . . . . . . . . . . . . . . . . . . . 6
2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 8 2.1.4. Termination . . . . . . . . . . . . . . . . . . . . . 8
2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 11 2.1.5. No Peer Authentication . . . . . . . . . . . . . . . 11
2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 12 2.1.6. Hello Retry Request . . . . . . . . . . . . . . . . . 12
2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 13 2.1.7. Identity . . . . . . . . . . . . . . . . . . . . . . 13
2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.8. Privacy . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 14 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 14
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 15 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 15
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 16 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 15
2.4. Parameter Negotiation and Compliance Requirements . . . . 17 2.4. Parameter Negotiation and Compliance Requirements . . . . 16
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 17 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 17
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 19 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 18
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 19 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 19
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 20 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 19
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 20 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 19
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 20 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 20
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 20 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 20
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 21 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 20
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 21 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 21
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 23 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 23
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 24 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 24
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 25 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 25
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Normative References . . . . . . . . . . . . . . . . . . 25 6.1. Normative References . . . . . . . . . . . . . . . . . . 25
6.2. Informative references . . . . . . . . . . . . . . . . . 26 6.2. Informative references . . . . . . . . . . . . . . . . . 26
Appendix A. Updated references . . . . . . . . . . . . . . . . . 30 Appendix A. Updated references . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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
skipping to change at page 4, line 14 skipping to change at page 4, line 14
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]. in EAP-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is
used for the entity acting as EAP peer and TLS client. The term EAP-
TLS server is used for the entity acting as EAP server and TLS
server.
2. Protocol Overview 2. 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].
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 (or higher). of [RFC5216] does not apply for TLS 1.3 (or higher).
skipping to change at page 4, line 39 skipping to change at page 4, line 42
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
or higher, the formatting and processing of the TLS handshake SHALL or higher, the formatting and processing of the TLS handshake SHALL
be done as specified in that version of TLS. This document only be done as specified in that version of TLS. This document only
lists additional and different requirements, restrictions, and lists additional and different requirements, restrictions, and
processing compared to [RFC8446] and [RFC5216]. processing compared to [RFC8446] and [RFC5216].
2.1.1. Mutual Authentication 2.1.1. Mutual Authentication
This section updates Section 2.1.1 of [RFC5216]. This section updates Section 2.1.1 of [RFC5216].
The EAP server MUST authenticate with a certificate and SHOULD The EAP-TLS server MUST authenticate with a certificate and SHOULD
require the EAP peer to authenticate with a certificate. require the EAP-TLS peer to authenticate with a certificate.
Certificates can be of any type supported by TLS including raw public Certificates can be of any type supported by TLS including raw public
keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except
for resumption. SessionID is deprecated in TLS 1.3 and the EAP for resumption. SessionID is deprecated in TLS 1.3 and the EAP-TLS
server SHALL ignore the legacy_session_id field if TLS 1.3 is server SHALL ignore the legacy_session_id field if TLS 1.3 is
negotiated. TLS 1.3 introduced early application data which is not negotiated. TLS 1.3 introduced early application data which is not
used in EAP-TLS. A server which receives an "early_data" extension used in EAP-TLS. A EAP-TLS server which receives an "early_data"
MUST ignore the extension or respond with a HelloRetryRequest as extension MUST ignore the extension or respond with a
described in Section 4.2.10 of [RFC8446]. Resumption is handled as HelloRetryRequest as described in Section 4.2.10 of [RFC8446].
described in Section 2.1.3. After the TLS handshake has completed Resumption is handled as described in Section 2.1.3. The EAP-TLS
and all Post-Handshake messages have been sent, the EAP server sends server commits to not send any more handshake messages by sending a
EAP-Success. Commitment Message (an encrypted TLS record with the application data
0x00), see Section 2.5. After the EAP-TLS server has recieved a EAP-
Response to the EAP-Request containing the Commitment Message, the
EAP-TLS server sends EAP-Success.
In the case where EAP-TLS with mutual authentication is successful In the case where EAP-TLS with mutual authentication is successful
(and neither HelloRetryRequest nor Post-Handshake messages are sent) (and neither HelloRetryRequest nor Post-Handshake messages are sent)
the conversation will appear as shown in Figure 1. The EAP server the conversation will appear as shown in Figure 1.
commits to not send any more handshake messages by sending a
Commitment Message (a TLS record with the application data 0x00), see
Section 2.5.
EAP Peer EAP 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
skipping to change at page 5, line 46 skipping to change at page 5, line 48
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
<-------- 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 server To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS
MUST send a NewSessionTicket message (containing a PSK and other server MUST send a NewSessionTicket message (containing a PSK and
parameters) in the initial authentication. The NewSessionTicket is other parameters) in the initial authentication. The
sent after the EAP server has received the Finished message in the NewSessionTicket is sent after the EAP-TLS server has received the
initial authentication. The NewSessionTicket message MUST NOT Finished message in the initial authentication. The NewSessionTicket
include an "early_data" extension. message MUST NOT include an "early_data" extension.
In the case where EAP-TLS with mutual authentication and ticket In the case where EAP-TLS with mutual authentication and ticket
establishment is successful, the conversation will appear as shown in establishment is successful, the conversation will appear as shown in
Figure 2. Figure 2.
EAP Peer EAP 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
skipping to change at page 7, line 6 skipping to change at page 7, line 8
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].
TLS 1.3 replaces the session resumption mechanisms in earlier TLS 1.3 replaces the session resumption mechanisms in earlier
versions of TLS with a new PSK exchange. When EAP-TLS is used with versions of TLS with a new PSK exchange. When EAP-TLS is used with
TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism
compatible with that version of TLS. compatible with that version of TLS.
For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If
the client has received a NewSessionTicket message from the server, the client has received a NewSessionTicket message from the EAP-TLS
the client can use the PSK identity received in the ticket to server, the client can use the PSK identity received in the ticket to
negotiate the use of the associated PSK. If the server accepts it, negotiate the use of the associated PSK. If the EAP-TLS server
then the security context of the new connection is tied to the accepts it, then the security context of the new connection is tied
original connection and the key derived from the initial handshake is to the original connection and the key derived from the initial
used to bootstrap the cryptographic state instead of a full handshake is used to bootstrap the cryptographic state instead of a
handshake. It is left up to the EAP peer whether to use resumption, full handshake. It is left up to the EAP-TLS peer whether to use
but it is RECOMMENDED that the EAP server accept resumption as long resumption, but it is RECOMMENDED that the EAP-TLS server accept
as the ticket is valid. However, the server MAY choose to require a resumption as long as the ticket is valid. However, the EAP-TLS
full authentication. EAP peers and EAP servers SHOULD follow the server MAY choose to require a full authentication. EAP-TLS peers
client tracking preventions in Appendix C.4 of [RFC8446]. and EAP-TLS servers SHOULD follow the client tracking preventions in
Appendix C.4 of [RFC8446].
It is RECOMMENDED to use a NAIs with the same realm in the resumption It is RECOMMENDED to use a NAIs with the same realm in the resumption
and the original full authentication. This requirement allows EAP and the original full authentication. This requirement allows EAP
packets to be routable to the same destination as the original full packets to be routable to the same destination as the original full
authentication. If this recommendation is not followed, resumption authentication. If this recommendation is not followed, resumption
is likely to be impossible. When NAI reuse can be done without is likely to be impossible. When NAI reuse can be done without
privacy implications, it is RECOMMENDED to use the same anonymous NAI privacy implications, it is RECOMMENDED to use the same anonymous NAI
in the resumption, as was used in the original full authentication. in the resumption, as was used in the original full authentication.
E.g. the NAI @realm can safely be reused, while the NAI E.g. the NAI @realm can safely be reused, while the NAI
ZmxleG8=@realm cannot. The TLS PSK identity is typically derived by ZmxleG8=@realm cannot. The TLS PSK identity is typically derived by
the TLS implementation and may be an opaque blob without a routable the TLS implementation and may be an opaque blob without a routable
realm. The TLS PSK identity is therefore in general unsuitable for realm. The TLS PSK identity is therefore in general unsuitable for
deriving a NAI to use in the Identity Response. deriving a NAI to use in the Identity Response.
A subsequent authentication using resumption, where both sides A subsequent authentication using resumption, where both sides
authenticate successfully (without the issuance of more resumption authenticate successfully (without the issuance of more resumption
tickets) is shown in Figure 3. tickets) is shown in Figure 3.
EAP Peer EAP 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
skipping to change at page 8, line 30 skipping to change at page 8, line 30
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS Finished, TLS Finished,
<-------- Commitment Message) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
<-------- EAP-Success <-------- EAP-Success
Figure 3: EAP-TLS resumption Figure 3: EAP-TLS resumption
As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD supply As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD
a "key_share" extension when attempting resumption, which allows the supply a "key_share" extension when attempting resumption, which
EAP server to potentially decline resumption and fall back to a full allows the EAP-TLS server to potentially decline resumption and fall
handshake. If the EAP peer did not supply a "key_share" extension back to a full handshake. If the EAP-TLS peer did not supply a
when attempting resumption, the EAP server needs to reject the "key_share" extension when attempting resumption, the EAP-TLS server
ClientHello and the EAP peer needs to restart a full handshake. The needs to reject the ClientHello and the EAP-TLS peer needs to restart
message flow in this case is given by Figure 4 followed by Figure 1. a full handshake. The message flow in this case is given by Figure 4
followed by Figure 1.
Also during resumption, the server can respond with a Hello Retry Also during resumption, the EAP-TLS server can respond with a Hello
Request (see Section 2.1.6) or issue a new ticket (see Section 2.1.2) Retry Request (see Section 2.1.6) or issue a new ticket (see
Section 2.1.2)
2.1.4. Termination 2.1.4. Termination
This section updates Section 2.1.3 of [RFC5216]. This section updates Section 2.1.3 of [RFC5216].
TLS 1.3 changes both the message flow and the handshake messages TLS 1.3 changes both the message flow and the handshake messages
compared to earlier versions of TLS. Therefore, some normative text compared to earlier versions of TLS. Therefore, some normative text
in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3 or higher. in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3 or higher.
The two paragraphs below replaces the corresponding paragraphs in The two paragraphs below replaces the corresponding paragraphs in
Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3 or
higher. The other paragraphs in Section 2.1.3 of [RFC5216] still higher. The other paragraphs in Section 2.1.3 of [RFC5216] still
apply with the exception that SessionID is deprecated. apply with the exception that SessionID is deprecated.
If the EAP peer authenticates successfully, the EAP server MUST If the EAP-TLS peer authenticates successfully, the EAP-TLS server
send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing
records conforming to the version of TLS used. The message flow TLS records conforming to the version of TLS used. The message
ends with the EAP server sending an EAP-Success message. flow ends with the EAP-TLS server sending an EAP-Success message.
If the EAP server authenticates successfully, the EAP peer MUST If the EAP-TLS server authenticates successfully, the EAP-TLS peer
send an EAP-Response message with EAP-Type=EAP-TLS containing TLS MUST send an EAP-Response message with EAP-Type=EAP-TLS containing
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 peer or EAP server sends a TLS fatal alert message. TLS the EAP-TLS peer or EAP-TLS server sends a TLS fatal alert message.
warning alerts generally mean that the connection can continue TLS warning alerts generally mean that the connection can continue
normally and does not change the message flow. Note that the party normally and does not change the message flow. Note that the party
receiving a TLS warning alert may choose to terminate the connection receiving a TLS warning alert may choose to terminate the connection
by sending a TLS fatal alert, which may add an extra round-trip, see by sending a TLS fatal alert, which may add an extra round-trip, see
[RFC8446]. [RFC8446].
In the case where the server rejects the ClientHello with a fatal In the case where the EAP-TLS server rejects the ClientHello with a
error, the conversation will appear as shown in Figure 4. The server fatal error, the conversation will appear as shown in Figure 4. The
can also partly reject the ClientHello with a HelloRetryRequest, see EAP-TLS server can also partly reject the ClientHello with a
Section 2.1.6. HelloRetryRequest, see Section 2.1.6.
EAP Peer EAP 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 Fatal Alert) <-------- (TLS Fatal Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 4: EAP-TLS server rejection of ClientHello Figure 4: EAP-TLS server rejection of ClientHello
In the case where server authentication is unsuccessful, the In the case where EAP-TLS server authentication is unsuccessful, the
conversation will appear as shown in Figure 5. conversation will appear as shown in Figure 5.
EAP Peer EAP 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
skipping to change at page 10, line 32 skipping to change at page 10, line 32
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- Commitment Message) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Fatal Alert) (TLS Fatal Alert)
--------> -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 5: EAP-TLS unsuccessful server authentication Figure 5: EAP-TLS unsuccessful EAP-TLS server authentication
In the case where the server authenticates to the peer successfully, In the case where the EAP-TLS server authenticates to the EAP-TLS
but the peer fails to authenticate to the server, the conversation peer successfully, but the EAP-TLS peer fails to authenticate to the
will appear as shown in Figure 6. EAP-TLS server, the conversation will appear as shown in Figure 6.
EAP Peer EAP 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/
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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].
In the case where EAP-TLS is used without peer authentication (e.g., In the case where EAP-TLS is used without peer authentication (e.g.,
emergency services, as described in [RFC7406]) the conversation will emergency services, as described in [RFC7406]) the conversation will
appear as shown in Figure 7. appear as shown in Figure 7.
EAP Peer EAP 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
skipping to change at page 12, line 36 skipping to change at page 12, line 36
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
<-------- 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].
TLS 1.3 [RFC8446] defines that 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 server HelloRetryRequest message in response to a ClientHello if the EAP-TLS
finds an acceptable set of parameters but the initial ClientHello server finds an acceptable set of parameters but the initial
does not contain all the needed information to continue the ClientHello does not contain all the needed information to continue
handshake. One use case is if the server does not support the groups the handshake. One use case is if the EAP-TLS server does not
in the "key_share" extension, but supports one of the groups in the support the groups in the "key_share" extension, but supports one of
"supported_groups" extension. In this case the client should send a the groups in the "supported_groups" extension. In this case the
new ClientHello with a "key_share" that the server supports. client should send a new ClientHello with a "key_share" that the EAP-
TLS server supports.
An EAP-TLS peer and server SHOULD support the use of
HelloRetryRequest message. As noted in Section 4.1.4 of [RFC8446],
the server MUST provide the supported_versions extensions and SHOULD
contain the minimal set of extensions necessary for the client to
generate a correct ClientHello pair. A HelloRetryRequest MUST NOT
contain any extensions that were not first offered by the client in
its ClientHello, with the exception of optionally including the
cookie extension.
The case of a successful EAP-TLS mutual authentication after the The case of a successful EAP-TLS mutual authentication after the EAP-
server has sent a HelloRetryRequest message is shown in Figure 8. TLS server has sent a HelloRetryRequest message is shown in Figure 8.
Note the extra round-trip as a result of the HelloRetryRequest. Note the extra round-trip as a result of the HelloRetryRequest.
EAP Peer EAP 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
skipping to change at page 14, line 4 skipping to change at page 13, line 49
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 peer, EAP authenticator, and EAP local deployments where the EAP-TLS peer, EAP authenticator, and EAP-
server all belong to the same network. Many client certificates TLS server all belong to the same network. Many client certificates
contains an identity such as an email address, which is already in contains an identity such as an email address, which is already in
NAI format. When the client certificate contains a NAI as subject NAI format. When the client certificate contains a NAI as subject
name or alternative subject name, an anonymous NAI SHOULD be derived name or alternative subject name, an anonymous NAI SHOULD be derived
from the NAI in the certificate, see Section 2.1.8. More details on from the NAI in the certificate, see Section 2.1.8. More details on
identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8. 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].
skipping to change at page 15, line 11 skipping to change at page 15, line 7
Including ContentType and ProtocolVersion a single TLS record may be Including ContentType and ProtocolVersion a single TLS record may be
up to 16387 octets in length. EAP-TLS fragmentation support is up to 16387 octets in length. EAP-TLS fragmentation support is
provided through addition of a flags octet within the EAP-Response provided through addition of a flags octet within the EAP-Response
and EAP-Request packets, as well as a TLS Message Length field of and EAP-Request packets, as well as a TLS Message Length field of
four octets. Implementations MUST NOT set the L bit in unfragmented four octets. Implementations MUST NOT set the L bit in unfragmented
messages, but MUST accept unfragmented messages with and without the messages, but MUST accept unfragmented messages with and without the
L bit set. L bit set.
Some EAP implementations and access networks may limit the number of Some EAP implementations and access networks may limit the number of
EAP packet exchanges that can be handled. To avoid fragmentation, it EAP packet exchanges that can be handled. To avoid fragmentation, it
is RECOMMENDED to keep the sizes of client, server, and trust anchor is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and
certificates small and the length of the certificate chains short. trust anchor certificates small and the length of the certificate
In addition, it is RECOMMENDED to use mechanisms that reduce the chains short. In addition, it is RECOMMENDED to use mechanisms that
sizes of Certificate messages. reduce the sizes of Certificate messages. For a detailed discussion
on reducing message sizes to prevent fragmentation, see
While Elliptic Curve Cryptography (ECC) was optional for earlier [I-D.ietf-emu-eaptlscert].
version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of
[RFC8446]). To avoid fragmentation, the use of ECC in certificates,
signature algorithms, and groups are RECOMMENDED when using EAP-TLS
with TLS 1.3 or higher. At a 128-bit security level, this reduces
public key sizes from 384 bytes (RSA and DHE) to 32-64 bytes (ECDHE)
and signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA).
An EAP-TLS deployment MAY further reduce the certificate sizes by
limiting the number of Subject Alternative Names.
Endpoints SHOULD reduce the sizes of Certificate messages by omitting
certificates that the other endpoint is known to possess. When using
TLS 1.3, all certificates that specifies a trust anchor may be
omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2, only
the self-signed certificate that specifies the root certificate
authority may be omitted (see Section 7.4.2 of [RFC5246]). EAP-TLS
peers and servers SHOULD support and use the Cached Information
Extension as specified in [RFC7924]. EAP-TLS peers and servers MAY
use other extensions for reducing the sizes of Certificate messages,
e.g. certificate compression [I-D.ietf-tls-certificate-compression].
For a detailed discussion on reducing message sizes to prevent
fragmentation, see [I-D.ietf-emu-eaptlscert].
2.2. Identity Verification 2.2. Identity Verification
This section updates Section 2.2 of [RFC5216]. This section updates Section 2.2 of [RFC5216].
The identity provided in the EAP-Response/Identity is not The identity provided in the EAP-Response/Identity is not
authenticated by EAP-TLS. Unauthenticated information SHALL 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 server MAY examine the identity presented authenticator and the EAP-TLS server MAY examine the identity
in EAP-Response/Identity for purposes such as routing and EAP method presented in EAP-Response/Identity for purposes such as routing and
selection. Servers MAY reject conversations if the identity does not EAP method selection. EAP-TLS servers MAY reject conversations if
match their policy. Note that this also applies to resumption, see the identity does not match their policy. Note that this also
Sections 2.1.3, 5.6, and 5.7. applies to resumption, see Sections 2.1.3, 5.6, and 5.7.
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 or higher. For not correct when EAP-TLS is used with TLS version 1.3 or higher. For
TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446]. TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446].
skipping to change at page 17, line 19 skipping to change at page 16, line 41
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 or higher. EAP-TLS is used with TLS version 1.3 or higher.
When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS When EAP-TLS is used with TLS version 1.3 or higher, the EAP-TLS
peers and servers MUST comply with the compliance requirements peers and EAP-TLS servers MUST comply with the compliance
(mandatory-to-implement cipher suites, signature algorithms, key requirements (mandatory-to-implement cipher suites, signature
exchange algorithms, extensions, etc.) for the TLS version used. For algorithms, key exchange algorithms, extensions, etc.) for the TLS
TLS 1.3 the compliance requirements are defined in Section 9 of version used. For TLS 1.3 the compliance requirements are defined in
[RFC8446]. Section 9 of [RFC8446].
While EAP-TLS does not protect any application data, the negotiated While EAP-TLS does not protect any application data except for the
cipher suites and algorithms MAY be used to secure data as done in Commitment Message, the negotiated cipher suites and algorithms MAY
other TLS-based EAP methods. be used to secure data as done in other TLS-based EAP methods.
2.5. EAP State Machines 2.5. EAP State Machines
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post- TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post-
Handshake messages use the handshake content type and can be sent Handshake messages use the handshake content type and can be sent
after the main handshake. One such Post-Handshake message is after the main handshake. One such Post-Handshake message is
NewSessionTicket. The NewSessionTicket can be used for resumption. NewSessionTicket. The NewSessionTicket can be used for resumption.
After sending TLS Finished, the EAP server may send any number of After sending TLS Finished, the EAP-TLS server may send any number of
Post-Handshake messages in separate EAP-Requests. To decrease the Post-Handshake messages in separate EAP-Requests. To decrease the
uncertainty for the EAP peer, the following procedure MUST be uncertainty for the EAP-TLS peer, the following procedure MUST be
followed: followed:
When an EAP server has sent its last handshake message (Finished or a When an EAP-TLS server has sent its last handshake message (Finished
Post-Handshake), it commits to not sending any more handshake or a Post-Handshake), it commits to not sending any more handshake
messages by sending a Commitment Message. The Commitment Message is messages by sending a Commitment Message. The Commitment Message is
an encrypted TLS record with application data 0x00 (i.e. a TLS record an encrypted TLS record with application data 0x00 (i.e. a TLS record
with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, with TLSPlaintext.type = application_data, TLSPlaintext.length = 1,
and TLSPlaintext.fragment = 0x00). Note that the length of the and TLSPlaintext.fragment = 0x00). Note that the length of the
plaintext is greater than the corresponding TLSPlaintext.length due plaintext is greater than the corresponding TLSPlaintext.length due
to the inclusion of TLSInnerPlaintext.type and any padding supplied to the inclusion of TLSInnerPlaintext.type and any padding supplied
by the sender. EAP server implementations MUST set by the sender. EAP-TLS server implementations MUST set
TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST TLSPlaintext.fragment to 0x00, but EAP-TLS peer implementations MUST
accept any application data as a Commitment Message from the EAP accept any application data as a Commitment Message from the EAP-TLS
server to not send any more handshake messages. The Commitment server to not send any more handshake messages. The Commitment
Message may be sent in the same EAP-Request as the last handshake Message may be sent in the same EAP-Request as the last handshake
record or in a separate EAP-Request. Sending the Commitment Message record or in a separate EAP-Request. Sending the Commitment Message
in a separate EAP-Request adds an additional round-trip, but may be in a separate EAP-Request adds an additional round-trip, but may be
necessary in TLS implementations that only implement a subset of TLS necessary in TLS implementations that only implement a subset of TLS
1.3. In the case where the server sends the Commitment Message in a 1.3. In the case where the EAP-TLS server sends the Commitment
separate EAP-Request, the conversation will appear as shown in Message in a separate EAP-Request, the conversation will appear as
Figure 9. After sending the Commitment Message, the EAP server may shown in Figure 9. After sending the Commitment Message, the EAP-TLS
only send an EAP-Success, an EAP-Failure, or an EAP-Request with a server may only send an EAP-Success, an EAP-Failure, or an EAP-
TLS Alert Message. Request with a TLS Alert Message.
EAP Peer EAP 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) -------->
skipping to change at page 20, line 22 skipping to change at page 20, line 11
5.3. Certificate Validation 5.3. Certificate Validation
No updates to section 5.3 of [RFC5216]. No updates to section 5.3 of [RFC5216].
5.4. Certificate Revocation 5.4. Certificate Revocation
This section updates Section 5.4 of [RFC5216]. This section updates Section 5.4 of [RFC5216].
While certificates may have long validity periods, there are a number While certificates may have long validity periods, there are a number
of reasons (e.g. key compromise, CA compromise, privilege withdrawn, of reasons (e.g. key compromise, CA compromise, privilege withdrawn,
etc.) why client, server, or sub-CA certificates have to be revoked etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have
before their expiry date. Revocation of the EAP server's certificate to be revoked before their expiry date. Revocation of the EAP-TLS
is complicated by the fact that the EAP peer may not have Internet server's certificate is complicated by the fact that the EAP-TLS peer
connectivity until authentication completes. may not have Internet connectivity until authentication completes.
EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate When EAP-TLS is used with TLS 1.3, the revocation status of all the
Status Requests (OCSP stapling) as specified in [RFC6066] and certificates in the certificate chains MUST be checked.
Section 4.4.2.1 of [RFC8446]. When EAP-TLS is used with TLS 1.3, the
peer and server MUST use Certificate Status Requests [RFC6066] for
the server's certificate chain and the EAP peer MUST treat a
CertificateEntry (except the trust anchor) without a valid
CertificateStatus extension as invalid and abort the handshake with
an appropriate alert. When EAP-TLS is used with TLS 1.3, the server
MUST check the revocation status of the certificates in the client's
certificate chain.
The OCSP status handling in TLS 1.3 is different from earlier EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the Requests (OCSP stapling) as specified in [RFC6066] and
OCSP information is carried in the CertificateEntry containing the Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers
and EAP-TLS servers use OCSP stapling for verifying the status of the
EAP-TLS server's certificate chain. When an EAP-TLS peer uses
Certificate Status Requests to check the revocation status of the
EAP-TLSserver's certificate chain it MUST treat a CertificateEntry
(except the trust anchor) without a valid CertificateStatus extension
as invalid and abort the handshake with an appropriate alert. The
OCSP status handling in TLS 1.3 is different from earlier versions of
TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP
information is carried in the CertificateEntry containing the
associated certificate instead of a separate CertificateStatus associated certificate instead of a separate CertificateStatus
message as in [RFC4366]. This enables sending OCSP information for message as in [RFC4366]. This enables sending OCSP information for
all certificates in the certificate chain. all certificates in the certificate chain.
To enable revocation checking in situations where EAP-TLS peers do
not implement or use OCSP stapling, and where network connectivity is
not available prior to authentication completion, EAP--TLS peer
implementations MUST also support checking for certificate revocation
after authentication completes and network connectivity is available,
and they SHOULD utilize this capability by default.
5.5. Packet Modification Attacks 5.5. Packet Modification Attacks
No updates to Section 5.5 of [RFC5216]. No updates to Section 5.5 of [RFC5216].
5.6. Authorization 5.6. Authorization
This is a new section when compared to [RFC5216]. The guidance in This is a new section when compared to [RFC5216]. The guidance in
this section is relevant for EAP-TLS in general (regardless of the this section is relevant for EAP-TLS in general (regardless of the
underlying TLS version used). underlying TLS version used).
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 server. This information can include, but is information to an EAP-TLS server. This information can include, but
not limited to, information about the authenticator, information is not limited to, information about the authenticator, information
about the EAP peer, or information about the protocol layers above or about the EAP-TLS peer, or information about the protocol layers
below EAP (MAC addresses, IP addresses, port numbers, WiFi SSID, above or below EAP (MAC addresses, IP addresses, port numbers, WiFi
etc.). Servers implementing EAP-TLS inside those protocols can make SSID, etc.). EAP-TLS Servers implementing EAP-TLS inside those
policy decisions and enforce authorization based on a combination of protocols can make policy decisions and enforce authorization based
information from the EAP-TLS exchange and non-EAP information. on a combination of information from the EAP-TLS exchange and non-EAP
information.
As noted in Section 2.2, the identity presented in EAP-Response/ As noted in Section 2.2, the identity presented in EAP-Response/
Identity is not authenticated by EAP-TLS and is therefore trivial for Identity is not authenticated by EAP-TLS and is therefore trivial for
an attacker to forge, modify, or replay. Authorization and an attacker to forge, modify, or replay. Authorization and
accounting MUST be based on authenticated information such as accounting MUST be based on authenticated information such as
information in the certificate or the PSK identity and cached data information in the certificate or the PSK identity and cached data
provisioned for resumption as described in Section 5.7. Note that provisioned for resumption as described in Section 5.7. Note that
the requirements for Network Access Identifiers (NAIs) specified in the requirements for Network Access Identifiers (NAIs) specified in
Section 4 of [RFC7542] still apply and MUST be followed. Section 4 of [RFC7542] still apply and MUST be followed.
skipping to change at page 21, line 51 skipping to change at page 21, line 46
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 all version of TLS. requirements in this section therefore applies to all 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. We use the term "cached data" to describe such handshake. We use the term "cached data" to describe such
information. Authorization during resumption MUST be based on such information. Authorization during resumption MUST be based on such
cached data. The EAP peer and server MAY perform fresh revocation cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh
checks on the cached certificate data. Any security policies for revocation checks on the cached certificate data. Any security
authorization MUST be followed also for resumption. The certificates policies for authorization MUST be followed also for resumption. The
may have been revoked since the initial full handshake and the certificates may have been revoked since the initial full handshake
authorizations of the other party may have been reduced. If the and the authorizations of the other party may have been reduced. If
cached revocation is not sufficiently current, the EAP Peer or EAP the cached revocation is not sufficiently current, the EAP-TLS peer
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 TLS server and client cache handshake. The first method is that the EAP-TLS server and client
the information locally. The cached information is identified by an cache the information locally. The cached information is identified
identifier. For TLS versions before 1.3, the identifier can be the by an identifier. For TLS versions before 1.3, the identifier can be
session ID, for TLS 1.3, the identifier is the PSK identity. The the session ID, for TLS 1.3, the identifier is the PSK identity. The
second method for retrieving cached information is via [RFC5077] or second method for retrieving cached information is via [RFC5077] or
[RFC8446], where the TLS server avoids storing information locally [RFC8446], where the EAP-TLS server avoids storing information
and instead encapsulates the information into a ticket or PSK which locally and instead encapsulates the information into a ticket or PSK
is sent to the client for storage. This ticket or PSK is encrypted which is sent to the client for storage. This ticket or PSK is
using a key that only the server knows. Note that the client still encrypted using a key that only the EAP-TLS server knows. Note that
needs to cache the original handshake information locally and will the client still needs to cache the original handshake information
use the session ID or PSK identity to lookup this information during locally and will use the session ID or PSK identity to lookup this
resumption. However, the server is able to decrypt the ticket or PSK information during resumption. However, the EAP-TLS server is able
to obtain the original handshake information. to decrypt the ticket or PSK to obtain the original handshake
information.
If the EAP server or EAP client do not apply any authorization If the EAP-TLS server or EAP client do not apply any authorization
policies, they MAY allow resumption where no cached data is policies, they MAY allow resumption where no cached data is
available. In all other cases, they MUST cache data during the available. In all other cases, they MUST cache data during the
initial full authentication to enable resumption. The cached data initial full authentication to enable resumption. The cached data
MUST be sufficient to make authorization decisions during resumption. MUST be sufficient to make authorization decisions during resumption.
If cached data cannot be retrieved in a secure way, resumption MUST If cached data cannot be retrieved in a secure way, resumption MUST
NOT be done. NOT be done.
The above requirements also apply if the EAP 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], peers MUST NOT store resumption PSKs or As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption
tickets (and associated cached data) for longer than 7 days, PSKs or tickets (and associated cached data) for longer than 7 days,
regardless of the PSK or ticket lifetime. The peer MAY delete them regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY
earlier based on local policy. The cached data MAY also be removed delete them earlier based on local policy. The cached data MAY also
on the server or peer if any certificate in the certificate chain has be removed on the EAP-TLS server or EAP-TLS peer if any certificate
been revoked or has expired. In all such cases, resumption results in the certificate chain has been revoked or has expired. In all
in a full TLS handshake instead. such cases, resumption results in a full TLS handshake instead.
Information from the EAP-TLS exchange (e.g. the identity provided in Information from the EAP-TLS exchange (e.g. the identity provided in
EAP-Response/Identity) as well as non-EAP information (e.g. IP EAP-Response/Identity) as well as non-EAP information (e.g. IP
addresses) may change between the initial full handshake and addresses) may change between the initial full handshake and
resumption. This change creates a "time-of-check time-of-use" resumption. This change creates a "time-of-check time-of-use"
(TOCTOU) security vulnerability. A malicious or compromised user (TOCTOU) security vulnerability. A malicious or compromised user
could supply one set of data during the initial authentication, and a could supply one set of data during the initial authentication, and a
different set of data during resumption, potentially allowing them to different set of data during resumption, potentially allowing them to
obtain access that they should not have. obtain access that they should not have.
If any authorization, accounting, or policy decisions were made with If any authorization, accounting, or policy decisions were made with
information that have changed between the initial full handshake and information that have changed between the initial full handshake and
resumption, and if change may lead to a different decision, such resumption, and if change may lead to a different decision, such
decisions MUST be reevaluated. It is RECOMMENDED that authorization, decisions MUST be reevaluated. It is RECOMMENDED that authorization,
accounting, and policy decisions are reevaluated based on the accounting, and policy decisions are reevaluated based on the
information given in the resumption. EAP servers MAY reject information given in the resumption. EAP-TLS servers MAY reject
resumption where the information supplied during resumption does not resumption where the information supplied during resumption does not
match the information supplied during the original authentication. match the information supplied during the original authentication.
Where a good decision is unclear, EAP servers SHOULD reject the Where a good decision is unclear, EAP-TLS servers SHOULD reject the
resumption. resumption.
Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security
considerations for resumption. considerations for resumption.
5.8. Privacy Considerations 5.8. Privacy Considerations
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
TLS 1.3 offers much better privacy than earlier versions of TLS as TLS 1.3 offers much better privacy than earlier versions of TLS as
discussed in Section 2.1.8. In this section, we only discuss the discussed in Section 2.1.8. In this section, we only discuss the
privacy properties of EAP-TLS with TLS 1.3. For privacy properties privacy properties of EAP-TLS with TLS 1.3. For privacy properties
of TLS 1.3 itself, see [RFC8446]. of TLS 1.3 itself, see [RFC8446].
EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in
EAP packets. Additionally, the EAP peer sends an identity in the EAP packets. Additionally, the EAP-TLS peer sends an identity in the
first EAP-Response. The other fields in the EAP-TLS Request and the first EAP-Response. The other fields in the EAP-TLS Request and the
EAP-TLS Response packets do not contain any cleartext privacy EAP-TLS Response packets do not contain any cleartext privacy
sensitive information. sensitive information.
Tracking of users by eavesdropping on identity responses or Tracking of users by eavesdropping on identity responses or
certificates is a well-known problem in many EAP methods. When EAP- certificates is a well-known problem in many EAP methods. When EAP-
TLS is used with TLS 1.3, all certificates are encrypted, and the TLS is used with TLS 1.3, all certificates are encrypted, and the
username part of the identity response is always confidentiality username part of the identity response is always confidentiality
protected (e.g. using anonymous NAIs). However, as with other EAP protected (e.g. using anonymous NAIs). However, as with other EAP
methods, even when privacy-friendly identifiers or EAP tunneling is methods, even when privacy-friendly identifiers or EAP tunneling is
used, the domain name (i.e. the realm) in the NAI is still typically used, the domain name (i.e. the realm) in the NAI is still typically
visible. How much privacy sensitive information the domain name visible. How much privacy sensitive information the domain name
leaks is highly dependent on how many other users are using the same leaks is highly dependent on how many other users are using the same
domain name in the particular access network. If all EAP peers have domain name in the particular access network. If all EAP-TLS peers
the same domain, no additional information is leaked. If a domain have the same domain, no additional information is leaked. If a
name is used by a small subset of the EAP peers, it may aid an domain name is used by a small subset of the EAP-TLS peers, it may
attacker in tracking or identifying the user. aid an attacker in tracking or identifying the user.
Without padding, information about the size of the client certificate Without padding, information about the size of the client certificate
is leaked from the size of the EAP-TLS packets. The EAP-TLS packets is leaked from the size of the EAP-TLS packets. The EAP-TLS packets
sizes may therefore leak information that can be used to track or sizes may therefore leak information that can be used to track or
identify the user. If all client certificates have the same length, identify the user. If all client certificates have the same length,
no information is leaked. EAP peers SHOULD use record padding, see no information is leaked. EAP-TLS peers SHOULD use record padding,
Section 5.4 of [RFC8446] to reduce information leakage of certificate see Section 5.4 of [RFC8446] to reduce information leakage of
sizes. certificate sizes.
If anonymous NAIs are not used, the privacy-friendly identifiers need If anonymous NAIs are not used, the privacy-friendly identifiers need
to be generated with care. The identities MUST be generated in a to be generated with care. The identities MUST be generated in a
cryptographically secure way so that that it is computationally cryptographically secure way so that that it is computationally
infeasible for an attacker to differentiate two identities belonging infeasible for an attacker to differentiate two identities belonging
to the same user from two identities belonging to different users in to the same user from two identities belonging to different users in
the same realm. This can be achieved, for instance, by using random the same realm. This can be achieved, for instance, by using random
or pseudo-random usernames such as random byte strings or ciphertexts or pseudo-random usernames such as random byte strings or ciphertexts
and only using the pseudo-random usernames a single time. Note that and only using the pseudo-random usernames a single time. Note that
the privacy-friendly usernames also MUST NOT include substrings that the privacy-friendly usernames also MUST NOT include substrings that
can be used to relate the identity to a specific user. Similarly, can be used to relate the identity to a specific user. Similarly,
privacy-friendly username SHOULD NOT be formed by a fixed mapping privacy-friendly username SHOULD NOT be formed by a fixed mapping
that stays the same across multiple different authentications. that stays the same across multiple different authentications.
An EAP peer with a policy allowing communication with EAP servers An EAP-TLS peer with a policy allowing communication with EAP-TLS
supporting only TLS 1.2 without privacy and with a static RSA key servers supporting only TLS 1.2 without privacy and with a static RSA
exchange is vulnerable to disclosure of the peer username. An active key exchange is vulnerable to disclosure of the EAP-TLS peer
attacker can in this case make the EAP peer believe that an EAP username. An active attacker can in this case make the EAP-TLS peer
server supporting TLS 1.3 only supports TLS 1.2 without privacy. The believe that an EAP-TLS server supporting TLS 1.3 only supports TLS
attacker can simply impersonate the EAP server and negotiate TLS 1.2 1.2 without privacy. The attacker can simply impersonate the EAP-TLS
with static RSA key exchange and send an TLS alert message when the server and negotiate TLS 1.2 with static RSA key exchange and send an
EAP peer tries to use privacy by sending an empty certificate TLS alert message when the EAP-TLS peer tries to use privacy by
message. Since the attacker (impersonating the EAP server) does not sending an empty certificate message. Since the attacker
provide a proof-of-possession of the private key until the Finished (impersonating the EAP-TLS server) does not provide a proof-of-
message when a static RSA key exchange is used, an EAP peer may possession of the private key until the Finished message when a
inadvertently disclose its identity (username) to an attacker. static RSA key exchange is used, an EAP-TLS peer may inadvertently
Therefore, it is RECOMMENDED for EAP peers to not use EAP-TLS with disclose its identity (username) to an attacker. Therefore, it is
TLS 1.2 and static RSA based cipher suites without privacy. This RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and
implies that an EAP peer SHOULD NOT continue the handshake if a TLS static RSA based cipher suites without privacy. This implies that an
1.2 EAP server responds to an empty certificate message with a TLS EAP-TLS peer SHOULD NOT continue the handshake if a TLS 1.2 EAP-TLS
alert message. server responds to an empty certificate message with a TLS alert
message.
5.9. Pervasive Monitoring 5.9. Pervasive Monitoring
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
Pervasive monitoring refers to widespread surveillance of users. In Pervasive monitoring refers to widespread surveillance of users. In
the context EAP-TLS, pervasive monitoring attacks can target peer the context EAP-TLS, pervasive monitoring attacks can target EAP-TLS
devices for tracking them (and their users) as and when they join a peer devices for tracking them (and their users) as and when they
network. By encrypting more information and by mandating the use of join a network. By encrypting more information and by mandating the
privacy, TLS 1.3 offers much better protection against pervasive use of privacy, TLS 1.3 offers much better protection against
monitoring. In addition to the privacy attacks discussed above, pervasive monitoring. In addition to the privacy attacks discussed
surveillance on a large scale may enable tracking of a user over a above, surveillance on a large scale may enable tracking of a user
wider geographical area and across different access networks. Using over a wider geographical area and across different access networks.
information from EAP-TLS together with information gathered from Using information from EAP-TLS together with information gathered
other protocols increases the risk of identifying individual users. from other protocols increases the risk of identifying individual
users.
5.10. Discovered Vulnerabilities 5.10. Discovered Vulnerabilities
This is a new section when compared to [RFC5216]. This is a new section when compared to [RFC5216].
Over the years, there have been several serious attacks on earlier Over the years, there have been several serious attacks on earlier
versions of Transport Layer Security (TLS), including attacks on its versions of Transport Layer Security (TLS), including attacks on its
most commonly used ciphers and modes of operation. [RFC7457] most commonly used ciphers and modes of operation. [RFC7457]
summarizes the attacks that were known at the time of publishing and summarizes the attacks that were known at the time of publishing and
[RFC7525] provides recommendations for improving the security of [RFC7525] provides recommendations for improving the security of
deployed services that use TLS. However, many of the attacks are 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 does not protect any application data. EAP-TLS implementations MUST
SHOULD mitigate known attacks and follow the recommendations in mitigate known attacks. EAP-TLS implementations need to monitor and
[RFC7525] and [I-D.ietf-tls-oldversions-deprecate]. The use of TLS follow new EAP and TLS related security guidance and requirements
1.3 mitigates most of the known attacks. such as [RFC8447], [I-D.ietf-tls-oldversions-deprecate],
[I-D.ietf-tls-md5-sha1-deprecate].
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 26, line 24 skipping to change at page 26, line 20
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015, DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>. <https://www.rfc-editor.org/info/rfc7542>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
6.2. Informative references 6.2. Informative references
[I-D.ietf-emu-eaptlscert] [I-D.ietf-emu-eaptlscert]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large Sethi, M., Mattsson, J., and S. Turner, "Handling Large
Certificates and Long Certificate Chains in TLS-based EAP Certificates and Long Certificate Chains in TLS-based EAP
Methods", draft-ietf-emu-eaptlscert-05 (work in progress), Methods", draft-ietf-emu-eaptlscert-06 (work in progress),
June 2020. October 2020.
[I-D.ietf-tls-certificate-compression] [I-D.ietf-tls-md5-sha1-deprecate]
Ghedini, A. and V. Vasiliev, "TLS Certificate Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
Compression", draft-ietf-tls-certificate-compression-10 MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf-
(work in progress), January 2020. tls-md5-sha1-deprecate-04 (work in progress), October
2020.
[I-D.ietf-tls-oldversions-deprecate] [I-D.ietf-tls-oldversions-deprecate]
Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and
TLSv1.1", draft-ietf-tls-oldversions-deprecate-07 (work in TLSv1.1", draft-ietf-tls-oldversions-deprecate-08 (work in
progress), October 2020. progress), October 2020.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information technology--Telecommunications Standard for Information technology--Telecommunications
and information exchange between systems Local and and information exchange between systems Local and
metropolitan area networks--Specific requirements - Part metropolitan area networks--Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Std 802.11-2016 Layer (PHY) Specifications", IEEE Std 802.11-2016
(Revision of IEEE Std 802.11-2012) , December 2016. (Revision of IEEE Std 802.11-2012) , December 2016.
skipping to change at page 27, line 40 skipping to change at page 27, line 30
[IEEE-802.1X] [IEEE-802.1X]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks -- Port- Standard for Local and metropolitan area networks -- Port-
Based Network Access Control", IEEE Standard 802.1X-2010 , Based Network Access Control", IEEE Standard 802.1X-2010 ,
February 2010. February 2010.
[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)", 2019. 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 29, line 48 skipping to change at page 29, line 38
Known Attacks on Transport Layer Security (TLS) and Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>.
[TS.33.501] [TS.33.501]
3GPP, "Security architecture and procedures for 5G 3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501 16.3.0, July 2020. System", 3GPP TS 33.501 16.4.0, September 2020.
Appendix A. Updated references Appendix A. Updated references
All the following references in [RFC5216] are updated as specified All the following references in [RFC5216] are updated as specified
below when EAP-TLS is used with TLS 1.3 or higher. below when EAP-TLS is used with TLS 1.3 or higher.
All references to [RFC2560] are updated with [RFC6960]. All references to [RFC2560] are updated with [RFC6960].
All references to [RFC3280] are updated with [RFC5280]. All references to [RFC3280] are updated with [RFC5280].
All references to [RFC4282] are updated with [RFC7542]. All references to [RFC4282] are updated with [RFC7542].
Acknowledgments Acknowledgments
The authors want to thank Bernard Aboba, Jari Arkko, Alan DeKok, Ari The authors want to thank Bernard Aboba, Jari Arkko, Alan DeKok, Ari
Keraenen, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, Terry Keraenen, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, Terry
Burton, and Vesa Torvinen for comments and suggestions on the draft. Burton, Vesa Torvinen, and Hannes Tschofenig for comments and
suggestions on the draft.
Contributors Contributors
Alan DeKok, FreeRADIUS Alan DeKok, FreeRADIUS
Authors' Addresses Authors' Addresses
John Preuss Mattsson John Preuss Mattsson
Ericsson Ericsson
Stockholm 164 40 Stockholm 164 40
 End of changes. 72 change blocks. 
260 lines changed or deleted 250 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/