draft-ietf-emu-eap-tls13-06.txt   draft-ietf-emu-eap-tls13-07.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 August 2, 2019 Intended status: Standards Track September 20, 2019
Expires: February 3, 2020 Expires: March 23, 2020
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-06 draft-ietf-emu-eap-tls13-07
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 updates RFC 5216. of privacy and revocation checking. This document updates RFC 5216.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 February 3, 2020. This Internet-Draft will expire on March 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 36 skipping to change at page 2, line 36
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 18 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 18
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 18 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 18
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 18 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 18
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 19 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 19
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 19 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 19
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 19
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 20 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 20
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 21 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 21
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 22 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 23
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 23 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 23
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Normative References . . . . . . . . . . . . . . . . . . 23 6.1. Normative References . . . . . . . . . . . . . . . . . . 23
6.2. Informative references . . . . . . . . . . . . . . . . . 24 6.2. Informative references . . . . . . . . . . . . . . . . . 24
Appendix A. Updated references . . . . . . . . . . . . . . . . . 27 Appendix A. Updated references . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 and key derivation utilizing the TLS handshake authentication and key derivation utilizing the TLS handshake
protocol for cryptographic algorithms and protocol version protocol for cryptographic algorithms and protocol version
negotiation, mutual authentication, and establishment of shared negotiation, mutual authentication, and establishment of shared
skipping to change at page 3, line 22 skipping to change at page 3, line 22
and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2 and TLS 1.1 [RFC4346], but works perfectly also with TLS 1.2
[RFC5246]. TLS 1.0 and 1.1 are formally deprecated and prohibited to [RFC5246]. TLS 1.0 and 1.1 are formally deprecated and prohibited to
negotiate and use [I-D.ietf-tls-oldversions-deprecate]. negotiate and use [I-D.ietf-tls-oldversions-deprecate].
Weaknesses found in TLS 1.2, as well as new requirements for Weaknesses found in TLS 1.2, as well as new requirements for
security, privacy, and reduced latency has led to the specification security, privacy, and reduced latency has led to the specification
of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is
in large parts a complete remodeling of the TLS handshake protocol in large parts a complete remodeling of the TLS handshake protocol
including a different message flow, different handshake messages, including a different message flow, different handshake messages,
different key schedule, different cipher suites, different different key schedule, different cipher suites, different
resumption, and different privacy protection. This means that resumption, different privacy protection, and record padding. This
significant parts of the normative text in the previous EAP-TLS means that significant parts of the normative text in the previous
specification [RFC5216] are not applicable to EAP-TLS with TLS 1.3 EAP-TLS specification [RFC5216] are not applicable to EAP-TLS with
(or higher). Therefore, aspects such as resumption, privacy TLS 1.3 (or higher). 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 (or higher). EAP-TLS with TLS 1.3 (or higher).
This document defines how to use EAP-TLS with TLS 1.3 (or higher) and This document defines how to use EAP-TLS with TLS 1.3 (or higher) and
does not change how EAP-TLS is used with older versions of TLS. does not change how EAP-TLS is used with older versions of TLS.
While this document updates EAP-TLS [RFC5216], it remains backwards While this document updates EAP-TLS [RFC5216], it remains backwards
compatible with it and existing implementations of EAP-TLS. This compatible with it and existing implementations of EAP-TLS. This
document only describes differences compared to [RFC5216]. document only describes differences compared to [RFC5216].
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,
skipping to change at page 4, line 38 skipping to change at page 4, line 38
for resumption. SessionID is deprecated in TLS 1.3 and the EAP for resumption. SessionID is deprecated in TLS 1.3 and the EAP
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 server which receives an "early_data" extension
MUST ignore the extension or respond with a HelloRetryRequest as MUST ignore the extension or respond with a HelloRetryRequest as
described in Section 4.2.10 of [RFC8446]. Resumption is handled as described in Section 4.2.10 of [RFC8446]. Resumption is handled as
described in Section 2.1.6. After the TLS handshake has completed described in Section 2.1.6. After the TLS handshake has completed
and all Post-Handshake messages have been sent, the EAP server sends and all Post-Handshake messages have been sent, the EAP server sends
EAP-Success. 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)
the conversation will appear as shown in Figure 1. The EAP server the conversation will appear as shown in Figure 1. The EAP server
commits to not send any more handshake messages by sending a TLS commits to not send any more handshake messages by sending a
record with the application data 0x00, see Section 2.5. Commitment Message (a TLS record with the application data 0x00), see
Section 2.5.
EAP Peer EAP Server EAP Peer EAP 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 5, line 25 skipping to change at page 5, line 25
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- TLS Application Data) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
<-------- EAP-Success <-------- EAP-Success
Figure 1: EAP-TLS mutual authentication Figure 1: EAP-TLS mutual authentication
2.1.2. Termination 2.1.2. Termination
skipping to change at page 6, line 13 skipping to change at page 6, line 13
ends with the EAP server sending an EAP-Success message. ends with the EAP server sending an EAP-Success message.
Figures 2, 3, and 4 illustrate message flows in several cases where Figures 2, 3, and 4 illustrate message flows in several cases where
the EAP peer or EAP server sends a TLS fatal alert message. TLS the EAP peer or EAP server sends a TLS fatal alert message. TLS
warning alerts generally mean that the connection can continue 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, the In the case where the server rejects the ClientHello with a fatal
conversation will appear as shown in Figure 2. error, the conversation will appear as shown in Figure 2. The server
can also partly reject the ClientHello with a HelloRetryRequest, see
Section 2.1.4.
EAP Peer EAP Server EAP Peer EAP 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 25 skipping to change at page 7, line 25
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- TLS Application Data) <-------- 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 3: EAP-TLS unsuccessful server authentication Figure 3: EAP-TLS unsuccessful server authentication
In the case where the server authenticates to the peer successfully, In the case where the server authenticates to the peer successfully,
but the peer fails to authenticate to the server, the conversation but the peer fails to authenticate to the server, the conversation
skipping to change at page 8, line 26 skipping to change at page 8, line 26
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- TLS Application Data) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Fatal Alert) <-------- (TLS Fatal Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
skipping to change at page 9, line 24 skipping to change at page 9, line 24
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- TLS Application Data) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
<-------- EAP-Success <-------- EAP-Success
Figure 5: EAP-TLS without peer authentication Figure 5: EAP-TLS without peer authentication
2.1.4. Hello Retry Request 2.1.4. Hello Retry Request
TLS 1.3 [RFC8446] defines that TLS servers can send a TLS 1.3 [RFC8446] defines that TLS servers can send a
HelloRetryRequest message in response to a ClientHello if the server HelloRetryRequest message in response to a ClientHello if the server
finds an acceptable set of parameters but the initial ClientHello finds an acceptable set of parameters but the initial ClientHello
does not contain all the needed information to continue the does not contain all the needed information to continue the
handshake. handshake. One use case is if the server does not support the groups
in the "key_share" extension, but supports one of the groups in the
"supported_groups" extension. In this case the client should send a
new ClientHello with a "key_share" that the server supports.
An EAP-TLS peer and server SHOULD support the use of An EAP-TLS peer and server SHOULD support the use of
HelloRetryRequest message. As noted in Section 4.1.4 of [RFC8446], HelloRetryRequest message. As noted in Section 4.1.4 of [RFC8446],
the server MUST provide the supported_versions extensions and SHOULD the server MUST provide the supported_versions extensions and SHOULD
contain the minimal set of extensions necessary for the client to contain the minimal set of extensions necessary for the client to
generate a correct ClientHello pair. A HelloRetryRequest MUST NOT generate a correct ClientHello pair. A HelloRetryRequest MUST NOT
contain any extensions that were not first offered by the client in contain any extensions that were not first offered by the client in
its ClientHello, with the exception of optionally the cookie its ClientHello, with the exception of optionally the cookie
extension. extension.
skipping to change at page 10, line 29 skipping to change at page 10, line 33
(TLS HelloRetryRequest) (TLS HelloRetryRequest)
<-------- <--------
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS Finished, TLS Finished,
<-------- TLS Application Data) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
<-------- EAP-Success <-------- EAP-Success
Figure 6: EAP-TLS with Hello Retry Request Figure 6: EAP-TLS with Hello Retry Request
2.1.5. Ticket Establishment 2.1.5. Ticket Establishment
When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support To enable resumption when using EAP-TLS with TLS 1.3, the EAP server
of resumption in the initial authentication. To indicate support of MUST send a NewSessionTicket message (containing a PSK and other
resumption, the EAP server sends a NewSessionTicket message parameters) in the initial authentication. The NewSessionTicket is
(containing a PSK and other parameters) after it has received the sent after the EAP server has received the Finished message in the
Finished message. The NewSessionTicket message MUST NOT include an initial authentication. The NewSessionTicket message MUST NOT
"early_data" extension. 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 7. Figure 7.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
skipping to change at page 11, line 33 skipping to change at page 11, line 33
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished) <-------- TLS Finished)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS NewSessionTicket, (TLS NewSessionTicket,
<-------- TLS Application Data) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 7: EAP-TLS ticket establishment Figure 7: EAP-TLS ticket establishment
2.1.6. Resumption 2.1.6. Resumption
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
skipping to change at page 12, line 8 skipping to change at page 12, line 8
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 server,
the client can use the PSK identity received in the ticket to 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 server accepts it,
then the security context of the new connection is tied to the then the security context of the new connection is tied to the
original connection and the key derived from the initial handshake is original connection and the key derived from the initial handshake is
used to bootstrap the cryptographic state instead of a full used to bootstrap the cryptographic state instead of a full
handshake. It is left up to the EAP peer whether to use resumption, handshake. It is left up to the EAP peer whether to use resumption,
but it is RECOMMENDED that the EAP server accept resumption as long but it is RECOMMENDED that the EAP server accept resumption as long
as the ticket is valid. However, the server MAY choose to require a as the ticket is valid. However, the server MAY choose to require a
full authentication. full authentication. EAP peers and EAP servers SHOULD follow the
client tracking preventions in Appendix C.4 of [RFC8446].
A subsequent authentication using resumption, where both sides A subsequent authentication using resumption, where both sides
authenticate successfully is shown in Figure 8. authenticate successfully is shown in Figure 8.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
skipping to change at page 12, line 30 skipping to change at page 12, line 31
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS Finished, TLS Finished,
<-------- TLS Application Data) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Finished) --------> (TLS Finished) -------->
<-------- EAP-Success <-------- EAP-Success
Figure 8: EAP-TLS resumption Figure 8: 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 peer SHOULD supply
a "key_share" extension when offering resumption, which allows the a "key_share" extension when offering resumption, which allows the
EAP server to decline resumption and continue the handshake as a full EAP server to decline resumption and continue the handshake as a full
handshake. The message flow in case of mutual authentication is handshake. The message flow in case of mutual authentication
given by Figure 1. If the EAP peer did not supply a "key_share" (without the issuance of any resumption tickets) is given by
extension when offering resumption, the EAP server needs to reject Figure 1. If the EAP peer did not supply a "key_share" extension
the ClientHello and the EAP peer needs to restart a full handshake. when offering resumption, the EAP server needs to reject the
The message flow in this case is given by Figure 2 followed by ClientHello and the EAP peer needs to restart a full handshake. The
Figure 1. message flow in this case is given by Figure 2 followed by Figure 1.
Also during resumption, the server can respond with a Hello Retry Also during resumption, the server can respond with a Hello Retry
Request (see Section 2.1.4) and issue a new ticket (see Request (see Section 2.1.4) and issue a new ticket (see
Section 2.1.5) Section 2.1.5)
2.1.7. Privacy 2.1.7. Privacy
TLS 1.3 significantly improves privacy when compared to earlier TLS 1.3 significantly improves privacy when compared to earlier
versions of TLS by forbidding cipher suites without confidentiality versions of TLS by forbidding cipher suites without confidentiality
and encrypting large parts of the TLS handshake including the and encrypting large parts of the TLS handshake including the
skipping to change at page 14, line 22 skipping to change at page 14, line 22
certificates that the other endpoint is known to possess. When using certificates that the other endpoint is known to possess. When using
TLS 1.3, all certificates that specifies a trust anchor may be 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 omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2, only
the self-signed certificate that specifies the root certificate the self-signed certificate that specifies the root certificate
authority may be omitted (see Section 7.4.2 of [RFC5246]). EAP-TLS authority may be omitted (see Section 7.4.2 of [RFC5246]). EAP-TLS
peers and servers SHOULD support and use the Cached Information peers and servers SHOULD support and use the Cached Information
Extension as specified in [RFC7924]. EAP-TLS peers and servers MAY Extension as specified in [RFC7924]. EAP-TLS peers and servers MAY
use other extensions for reducing the sizes of Certificate messages, use other extensions for reducing the sizes of Certificate messages,
e.g. certificate compression [I-D.ietf-tls-certificate-compression]. 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
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 server MAY examine the identity presented
in EAP-Response/Identity for purposes such as routing and EAP method in EAP-Response/Identity for purposes such as routing and EAP method
selection. They MAY reject conversations if the identity does not selection. They MAY reject conversations if the identity does not
match their policy. Note that this also applies to resumption, see match their policy. Note that this also applies to resumption, see
Sections 2.1.6, 5.6, and 5.7. Sections 2.1.6, 5.6, and 5.7.
skipping to change at page 16, line 24 skipping to change at page 16, line 24
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 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 peer, the following procedure MUST be
followed: followed:
When an EAP server has sent its last handshake message (Finished or a When an EAP server has sent its last handshake message (Finished or a
Post-Handshake), it commits to not sending any more handshake Post-Handshake), it commits to not sending any more handshake
messages by sending a TLS record with application data 0x00 (i.e. a messages by sending a Commitment Message. The Commitment Message is
TLS record with TLSPlaintext.type = application_data, a TLS record with application data 0x00 (i.e. a TLS record with
TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00). EAP TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and
server implementations MUST set TLSPlaintext.fragment to 0x00, but TLSPlaintext.fragment = 0x00). Note that the length of the plaintext
EAP peer implementations MUST accept any application data as a commit is greater than the corresponding TLSPlaintext.length due to the
from the EAP server to not send any more handshake messages. The TLS inclusion of TLSInnerPlaintext.type and any padding supplied by the
record with application data may be sent in the same EAP-Request as sender. EAP server implementations MUST set TLSPlaintext.fragment to
the last handshake record or in a separate EAP-Request. Sending the 0x00, but EAP peer implementations MUST accept any application data
commit in a separate EAP-Request adds an additional round-trip, but as a Commitment Message from the EAP server to not send any more
may be necessary in TLS implementations that only implement a subset handshake messages. The Commitment Message may be sent in the same
of TLS 1.3. In the case where the server sends the commit in a EAP-Request as the last handshake record or in a separate EAP-
separate commit, the conversation will appear as shown in Figure 9. Request. Sending the Commitment Message in a separate EAP-Request
After sending the application data record, the EAP server may only adds an additional round-trip, but may be necessary in TLS
send an EAP-Success, an EAP-Failure, or an EAP-Request with a TLS implementations that only implement a subset of TLS 1.3. In the case
Alert Message. where the server sends the Commitment Message in a separate EAP-
Request, the conversation will appear as shown in Figure 9. After
sending the Commitment Message, the EAP server may only send an EAP-
Success, an EAP-Failure, or an EAP-Request with a TLS Alert Message.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Privacy-Friendly) --------> Identity (Privacy-Friendly) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
skipping to change at page 17, line 32 skipping to change at page 17, line 32
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
<-------- TLS Finished, <-------- TLS Finished,
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Certificate, (TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished) --------> TLS Finished) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- TLS Application Data) <-------- Commitment Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 9: Commit in separate EAP-Request Figure 9: Commit in separate EAP-Request
3. Detailed Description of the EAP-TLS Protocol 3. Detailed Description of the EAP-TLS Protocol
No updates to [RFC5216]. No updates to [RFC5216].
skipping to change at page 19, line 23 skipping to change at page 19, line 23
completes. completes.
EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate
Status Requests (OCSP stapling) as specified in [RFC6066] and Status Requests (OCSP stapling) as specified in [RFC6066] and
Section 4.4.2.1 of [RFC8446]. When EAP-TLS is used with TLS 1.3, the 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 peer and server MUST use Certificate Status Requests [RFC6066] for
the server's certificate chain and the EAP peer MUST treat a the server's certificate chain and the EAP peer MUST treat a
CertificateEntry (except the trust anchor) without a valid CertificateEntry (except the trust anchor) without a valid
CertificateStatus extension as invalid and abort the handshake with CertificateStatus extension as invalid and abort the handshake with
an appropriate alert. When EAP-TLS is used with TLS 1.3, the server an appropriate alert. When EAP-TLS is used with TLS 1.3, the server
MUST check the revocation status of the certificates in the MUST check the revocation status of the certificates in the client's
certificates in the client's certificate chain. certificate chain.
The OCSP status handling in TLS 1.3 is different from earlier 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 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 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.
5.5. Packet Modification Attacks 5.5. Packet Modification Attacks
skipping to change at page 20, line 23 skipping to change at page 20, line 23
5.7. Resumption 5.7. Resumption
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, revocation status, etc. from information such as certificate chains from the initial full
the initial full handshake. We use the term "cached data" to handshake. We use the term "cached data" to describe such
describe such information. Authorization during resumption MUST be information. Authorization during resumption MUST be based on such
based on such cached data. cached data. The EAP peer and sever MAY perform fresh revocation
checks on the cached certificate data. Any security policies for
authorization MUST be followed also for resumption. The certificates
may have been revoked since the initial full handshake and the
authorizations of the other party may have been reduced. If the
cached revocation information is not sufficiently current, the EAP
Peer or EAP Server MAY force a full TLS handshake.
There are two ways to retrieve the cached information from the There are two ways to retrieve the cached information from the
original full handshake. The first method is that the TLS server and original full handshake. The first method is that the TLS server and
client cache the information locally. The cached information is client cache the information locally. The cached information is
identified by an identifier. For TLS versions before 1.3, the identified by an identifier. For TLS versions before 1.3, the
identifier can be the session ID, for TLS 1.3, the identifier is the identifier can be the session ID, for TLS 1.3, the identifier is the
PSK identity. The second method for retrieving cached information is PSK identity. The second method for retrieving cached information is
via [RFC5077] or [RFC8446], where the TLS server encapsulates the via [RFC5077] or [RFC8446], where the TLS server encapsulates the
information into a ticket and sends it to the client. The client can information into a ticket and sends it to the client. The client can
subsequently do resumption using the obtained ticket. Note that the subsequently do resumption using the obtained ticket. Note that the
skipping to change at page 21, line 27 skipping to change at page 21, line 34
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 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 servers SHOULD reject the
resumption. resumption.
Any security policies for authorization MUST be followed also for Section 4.2.11, 8.1, and 8.2 of [RFC8446] provides security
resumption. The EAP-TLS client and server MAY need to recheck the consideration for resumption.
authorization and revocation status of the other party. The
certificates may have been revoked since the initial full handshake
and the authorizations of the other party may have been reduced. If
the cached revocation information is not sufficiently current, the
EAP Peer or EAP Server needs to force a full TLS handshake.
5.8. Privacy Considerations 5.8. Privacy Considerations
[RFC6973] suggests that the privacy considerations of IETF protocols [RFC6973] suggests that the privacy considerations of IETF protocols
be documented. be documented.
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.7. In this section, we only discuss the discussed in Section 2.1.7. 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].
skipping to change at page 22, line 19 skipping to change at page 22, line 19
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 peers have
the same domain, no additional information is leaked. If a domain the same domain, no additional information is leaked. If a domain
name is used by a small subset of the EAP peers, it may aid an name is used by a small subset of the EAP peers, it may aid an
attacker in tracking or identifying the user. attacker in tracking or identifying the user.
Without padding, information about the size of the client certificate
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
identify the user. If all client certificates have the same length,
no information is leaked. EAP peers SHOULD use record padding, see
Section 5.4 of [RFC8446] to reduce information leakage of 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 or pseudo-random usernames such as random byte strings or
ciphertexts. Note that the privacy-friendly usernames also MUST NOT ciphertexts. Note that the privacy-friendly usernames also MUST NOT
include substrings that can be used to relate the identity to a include substrings that can be used to relate the identity to a
specific user. Similarly, privacy-friendly username SHOULD NOT be specific user. Similarly, privacy-friendly username SHOULD NOT be
skipping to change at page 24, line 44 skipping to change at page 25, line 5
[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]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large
Certificates and Long Certificate Chains in TLS-based EAP
Methods", draft-ietf-emu-eaptlscert-00 (work in progress),
August 2019.
[I-D.ietf-tls-certificate-compression] [I-D.ietf-tls-certificate-compression]
Ghedini, A. and V. Vasiliev, "TLS Certificate Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", draft-ietf-tls-certificate-compression-05 Compression", draft-ietf-tls-certificate-compression-05
(work in progress), April 2019. (work in progress), April 2019.
[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-05 (work in TLSv1.1", draft-ietf-tls-oldversions-deprecate-05 (work in
progress), June 2019. progress), June 2019.
skipping to change at page 28, line 4 skipping to change at page 28, line 16
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, and Keraenen, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, and
Vesa Torvinen for comments and suggestions on the draft. Vesa Torvinen for comments and suggestions on the draft.
Contributors Contributors
Alan DeKok, FreeRADIUS Alan DeKok, FreeRADIUS
Authors' Addresses Authors' Addresses
John Mattsson
John Preuss Mattsson
Ericsson Ericsson
Stockholm 164 40 Stockholm 164 40
Sweden Sweden
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
 End of changes. 29 change blocks. 
68 lines changed or deleted 98 lines changed or added

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