draft-ietf-emu-eap-tls13-02.txt   draft-ietf-emu-eap-tls13-03.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 16, 2018 Intended status: Standards Track November 14, 2018
Expires: April 19, 2019 Expires: May 18, 2019
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-02 draft-ietf-emu-eap-tls13-03
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. This reduced latency when compared to earlier versions of TLS. EAP-TLS
document updates RFC 5216. with TLS 1.3 provides significantly improved protection against
pervasive monitoring by mandating use of privacy. This document
updates RFC 5216.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2019. This Internet-Draft will expire on May 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 13 skipping to change at page 2, line 14
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements and Terminology . . . . . . . . . . . . . . 3 1.1. Requirements and Terminology . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 3 2.1. Overview of the EAP-TLS Conversation . . . . . . . . . . 3
2.1.1. Base Case . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Base Case . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Resumption . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Resumption . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Termination . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Termination . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 2.1.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 13
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 12 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 14
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Parameter Negotiation and Compliance Requirements . . . . 13 2.4. Parameter Negotiation and Compliance Requirements . . . . 14
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 13 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 15
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 14 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 15
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 14 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 16
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 15 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 16
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 15 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 16
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 15 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 16
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 15 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 17
5.6. Privacy Considerations . . . . . . . . . . . . . . . . . 15 5.6. Privacy Considerations . . . . . . . . . . . . . . . . . 17
5.7. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 16 5.7. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.2. Informative references . . . . . . . . . . . . . . . . . 18 6.2. Informative references . . . . . . . . . . . . . . . . . 19
Appendix A. Updated references . . . . . . . . . . . . . . . . . 19 Appendix A. Updated references . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 29 skipping to change at page 3, line 29
to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). to be appropriately addressed for 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,
there are other significant benefits of using EAP-TLS with TLS 1.3. there are other significant benefits of using EAP-TLS with TLS 1.3.
When EAP-TLS is used with support for privacy, TLS 1.3 requires two Privacy is achieved without any additional round-trips, and TLS 1.3
fewer round-trips. TLS 1.3 also introduces more possibilities to introduces more possibilities to reduce fragmentation when compared
reduce fragmentation when compared to earlier versions of TLS. to earlier versions of TLS.
1.1. Requirements and Terminology 1.1. Requirements and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts used Readers are expected to be familiar with the terms and concepts used
skipping to change at page 4, line 21 skipping to change at page 4, line 26
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].
The EAP server MUST authenticate with a certificate and SHOULD The EAP server MUST authenticate with a certificate and SHOULD
require the EAP peer to authenticate with a certificate. require the EAP 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
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. Resumption is handled as described in Section 2.1.2. negotiated. Resumption is handled as described in Section 2.1.2.
After the TLS handshake has completed, the EAP server sends EAP- After the TLS handshake has completed and all Post-Handshake messages
Success. have been sent, the EAP server sends EAP-Success.
As stated in [RFC5216], the TLS cipher suite shall not be used to As stated in [RFC5216], the TLS cipher suite shall not be used to
protect application data. This applies also for early application protect application data. This applies also for early application
data. When EAP-TLS is used with TLS 1.3, early application data data. When EAP-TLS is used with TLS 1.3, early application data
SHALL NOT be used. SHALL NOT be used.
In the case where EAP-TLS with mutual authentication is successful, In the case where EAP-TLS with mutual authentication is successful,
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 an empty commits to not send any more handshake messages by sending an empty
TLS record, see Section 2.5. TLS record, see Section 2.5.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (MyID) --------> Identity (Anonymous NAI) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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 Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (MyID) --------> Identity (Anonymous NAI) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
skipping to change at page 7, line 6 skipping to change at page 7, line 6
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 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 a EAP peer SHOULD use resumption as long as it has a valid ticket but an EAP peer SHOULD use resumption as long as it has a valid
cached. It is RECOMMENDED that the EAP server accept resumption as ticket cached. It is RECOMMENDED that the EAP server accept
long as the ticket is valid. However, the server MAY choose to resumption as long as the ticket is valid. However, the server MAY
require a full authentication. choose to require a full authentication.
A subsequent authentication using resumption, where both sides A subsequent authentication using resumption, where both sides
authenticate successfully is shown in Figure 3. authenticate successfully is shown in Figure 3.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (MyID) --------> Identity (Anonymous NAI) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
skipping to change at page 8, line 16 skipping to change at page 8, line 16
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 RFC 5216 [RFC5216] does not apply for TLS 1.3 or in Section 2.1.3 of RFC 5216 [RFC5216] does not apply for TLS 1.3 or
higher. The two paragraphs below replaces the corresponding higher. The two paragraphs below replaces the corresponding
paragraphs in Section 2.1.3 of RFC 5216 [RFC5216] when EAP-TLS is paragraphs in Section 2.1.3 of RFC 5216 [RFC5216] when EAP-TLS is
used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3
of RFC 5216 [RFC5216] still apply with the exception that SessionID of RFC 5216 [RFC5216] still apply with the exception that SessionID
is deprecated. is deprecated.
If the EAP server authenticates successfully the EAP peer MUST If the EAP server authenticates successfully, the EAP peer MUST
send an EAP-Response message with EAP-Type=EAP-TLS containing TLS send an EAP-Response message with EAP-Type=EAP-TLS containing TLS
records confirming the processing in the version of TLS used. records conforming to the version of TLS used.
If the EAP peer authenticates successfully the EAP server MUST If the EAP peer authenticates successfully, the EAP server MUST
send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS
records confirming to the processing in the version of TLS used. records conforming to the version of TLS used. The message flow
The message flow ends with the EAP server sending a EAP-Success ends with the EAP server sending an EAP-Success message.
message.
Figures 4, 5, 6, and 7 illustrate message flows in several cases
where the EAP peer or EAP server sends a TLS fatal alert message.
TLS warning alerts generally mean that the connection can continue
normally and does not change the message flow. Note that the party
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
[RFC8446].
In the case where the server rejects the ClientHello, the In the case where the server rejects the ClientHello, the
conversation will appear as shown in Figure 4. conversation will appear as shown in Figure 4.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (MyID) --------> Identity (Anonymous NAI) -------->
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 Alert Message) <-------- (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 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 Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (MyID) --------> Identity (Anonymous NAI) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- TLS empty record) <-------- TLS empty record)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS Alert Message) (TLS Fatal Alert)
--------> -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 5: EAP-TLS unsuccessful server authentication Figure 5: 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
will appear as shown in Figure 6. will appear as shown in Figure 6.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (MyID) --------> Identity (Anonymous NAI) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
skipping to change at page 10, line 33 skipping to change at page 11, line 33
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, TLS Finished,
<-------- TLS empty record) <-------- TLS empty record)
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 Alert Message) <-------- (TLS Fatal Alert)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 6: EAP-TLS unsuccessful client authentication Figure 6: EAP-TLS unsuccessful client authentication
2.1.4. Privacy In the case where the client rejects a NewSessionTicket, the
conversation will appear as shown in Figure 7.
TLS 1.3 significantly improves privacy when compared to earlier
versions of TLS by forbidding cipher suites without confidentiality
and encrypting large parts of the TLS handshake including the
certificate messages.
EAP-TLS peer and server implementations supporting TLS 1.3 or higher
MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4
in [RFC7542]) and the client MUST confidentiality protect its
identity (e.g. using Anonymous NAIs) when the EAP-TLS server is known
to support TLS 1.3 or higher.
As the certificate messages in TLS 1.3 are encrypted, there is no
need to send an empty certificate_list or perform a second handshake
(as needed by EAP-TLS with earlier versions of TLS). When EAP-TLS is
used with TLS version 1.3 or higher the EAP-TLS peer and EAP-TLS
server SHALL follow the processing specified by the used version of
TLS. For TLS 1.3 this means that the EAP-TLS peer only sends an
empty certificate_list if it does not have an appropriate certificate
to send, and the EAP-TLS server MAY treat an empty certificate_list
as a terminal condition.
When EAP-TLS is used with TLS 1.3 and privacy, no extra round-trips
are added and the message flow looks just like a normal message flow
with the only difference that an anonymous NAI is used. In the case
where EAP-TLS with mutual authentication and privacy is successful,
the conversation will appear as shown in Figure 7.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
Identity (Anonymous NAI) --------> Identity (Anonymous NAI) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
TLS CertificateRequest, TLS CertificateRequest,
TLS Certificate, TLS Certificate,
TLS CertificateVerify, TLS CertificateVerify,
TLS Finished, <-------- TLS Finished)
<-------- TLS empty record)
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-Request/
EAP-Type=EAP-TLS
(TLS NewSessionTicket,
<-------- TLS empty record)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Fatal Alert)
-------->
<-------- EAP-Failure
Figure 7: EAP-TLS privacy Figure 7: EAP-TLS client rejection of NewSessionTicket
2.1.4. Privacy
TLS 1.3 significantly improves privacy when compared to earlier
versions of TLS by forbidding cipher suites without confidentiality
and encrypting large parts of the TLS handshake including the
certificate messages.
EAP-TLS peer and server implementations supporting TLS 1.3 or higher
MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4
in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its
username in cleartext in the Identity Response. It is RECOMMENDED to
use anonymous NAIs, but other solutions where the username is
encrypted MAY be used.
As the certificate messages in TLS 1.3 are encrypted, there is no
need to send an empty certificate_list or perform a second handshake
(as needed by EAP-TLS with earlier versions of TLS). When EAP-TLS is
used with TLS version 1.3 or higher the EAP-TLS peer and EAP-TLS
server SHALL follow the processing specified by the used version of
TLS. For TLS 1.3 this means that the EAP-TLS peer only sends an
empty certificate_list if it does not have an appropriate certificate
to send, and the EAP-TLS server MAY treat an empty certificate_list
as a terminal condition.
EAP-TLS with TLS 1.3 is always used with privacy since this does not
add any extra round-trips and the message flow with privacy is just
the normal message flow as shown in Figure 1.
2.1.5. Fragmentation 2.1.5. Fragmentation
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. Some EAP implementations and access up to 16387 octets in length. Some EAP implementations and access
networks may limit the number of EAP packet exchanges that can be networks may limit the number of EAP packet exchanges that can be
handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes
of client, server, and trust anchor certificates small and the length of client, server, and trust anchor certificates small and the length
of the certificate chains short. It addition, it is RECOMMENDED to of the certificate chains short. In addition, it is RECOMMENDED to
use mechanisms that reduce the sizes of Certificate messages. use mechanisms that reduce the sizes of Certificate messages.
While Elliptic Curve Cryptography (ECC) was optional for earlier While Elliptic Curve Cryptography (ECC) was optional for earlier
version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of
[RFC8446]). To avoid fragmentation, the use of ECC in certificates, [RFC8446]). To avoid fragmentation, the use of ECC in certificates,
signature algorithms, and groups are RECOMMENDED when using EAP-TLS signature algorithms, and groups are RECOMMENDED when using EAP-TLS
with TLS 1.3 or higher. At a 128-bit security level, this reduces 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 bytes (ECDHE) and public key sizes from 384 bytes (RSA and DHE) to 32 bytes (ECDHE) and
signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA). An signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA). An
EAP-TLS deployment MAY further reduce the certificate sizes by EAP-TLS deployment MAY further reduce the certificate sizes by
skipping to change at page 13, line 37 skipping to change at page 15, line 10
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 requirements for the TLS peers and servers MUST comply with the requirements for the TLS
version used. For TLS 1.3 the compliance requirements are defined in version used. For TLS 1.3 the compliance requirements are defined in
Section 9 of [RFC8446]. Section 9 of [RFC8446].
2.5. EAP State Machines 2.5. EAP State Machines
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 NewSessopmTicket 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 appending an empty application data record (i.e. a TLS messages by appending an empty application data record (i.e. a TLS
record with TLSPlaintext.type = application_data and record with TLSPlaintext.type = application_data and
TLSPlaintext.length = 0) to the last handshake record. After sending TLSPlaintext.length = 0) to the last handshake record. After sending
skipping to change at page 14, line 44 skipping to change at page 16, line 18
Using EAP-TLS with TLS 1.3 does not change the security claims for Using EAP-TLS with TLS 1.3 does not change the security claims for
EAP-TLS as given in Section 4.1 of [RFC5216]. However, it EAP-TLS as given in Section 4.1 of [RFC5216]. However, it
strengthens several of the claims as described in the following strengthens several of the claims as described in the following
updates to the notes given in Section 4.1 of [RFC5216]. updates to the notes given in Section 4.1 of [RFC5216].
[2] Confidentiality: The TLS 1.3 handshake offers much better [2] Confidentiality: The TLS 1.3 handshake offers much better
confidentiality than earlier versions of TLS by mandating cipher confidentiality than earlier versions of TLS by mandating cipher
suites with confidentiality and encrypting certificates and some of suites with confidentiality and encrypting certificates and some of
the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the
use of privacy does not cause any additional round-trips. use of privacy is mandatory and does not cause any additional round-
trips.
[3] Key strength: TLS 1.3 forbids all algorithms with known [3] Key strength: TLS 1.3 forbids all algorithms with known
weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3 weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5. TLS 1.3
only supports cryptographic algorithms offering at least 112-bit only supports cryptographic algorithms offering at least 112-bit
security, see [RFC8446]. security, see [RFC8446].
[4] Cryptographic Negotiation: TLS 1.3 increases the number of [4] Cryptographic Negotiation: TLS 1.3 increases the number of
cryptographic parameters that are negotiated in the handshake. When cryptographic parameters that are negotiated in the handshake. When
EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic
negotiation of AEAD algorithm, HKDF hash algorithm, key exchange negotiation of AEAD algorithm, HKDF hash algorithm, key exchange
skipping to change at page 15, line 47 skipping to change at page 17, line 23
[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.4. In this section, we only discuss the discussed in Section 2.1.4. 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 peer sends an identity in the
first EAP-Response. The fields in the EAP-TLS Request and the EAP- first EAP-Response. The other fields in the EAP-TLS Request and the
TLS Response packets do not contain any cleartext privacy sensitive EAP-TLS Response packets do not contain any cleartext privacy
information. sensitive information.
It is strongly RECOMMENDED to confidentiality protect the identity When EAP-TLS is used with TLS 1.3, the username part of the identity
(e.g. using Anonymous NAIs), as the username part of the NAI may response is always confidentiality protected (e.g. using Anonymous
otherwise enable identification and tracking of the user. However, NAIs). However, as with other EAP methods, even when privacy-
as with other EAP methods, even when privacy-friendly identifiers or friendly identifiers or EAP tunneling is used, the domain name (i.e.
EAP tunneling is used, the domain name (i.e. the realm) in the NAI is the realm) in the NAI is still typically visible. How much privacy
still typically visible. How much privacy sensitive information the sensitive information the domain name leaks is highly dependent on
domain name leaks is highly dependent on how many other users are how many other users are using the same domain name in the particular
using the same domain name in the particular access network. If all access network. If all EAP peers have the same domain, no additional
EAP peers have the same domain, no additional information is leaked. information is leaked. If a domain name is used by a small subset of
If a domain name is used by a small subset of the EAP peers, it may the EAP peers, it may aid an attacker in tracking or identifying the
aid an attacker in tracking or identifying the user. user.
An EAP peer with a policy allowing communication with EAP servers An EAP peer with a policy allowing communication with EAP servers
supporting only TLS 1.2 (or lower) without privacy and with RSA key supporting only TLS 1.2 (or lower) without privacy and with RSA key
exchange is vulnerable to disclosure of the peer username. An active exchange is vulnerable to disclosure of the peer username. An active
attacker can in this case make the EAP peer believe that an EAP attacker can in this case make the EAP peer believe that an EAP
server supporting TLS 1.3 does not support privacy. The attacker can server supporting TLS 1.3 only supports TLS 1.2 (or lower) without
simply impersonate the EAP server and negotiate TLS 1.2 (or privacy. The attacker can simply impersonate the EAP server and
lower)with RSA key exchange and send an TLS alert message when the negotiate TLS 1.2 (or lower) with RSA key exchange and send an TLS
EAP peer tries to use privacy by sending an empty certificate alert message when the EAP peer tries to use privacy by sending an
message. Since the attacker (impersonating the EAP server) does not empty certificate message. Since the attacker (impersonating the EAP
provide a proof-of-possession of the private key until the Finished server) does not provide a proof-of-possession of the private key
message when RSA key exchange is used, an EAP peer may inadvertently until the Finished message when RSA key exchange is used, an EAP peer
disclose its identity (username) to an attacker. Therefore, it is may inadvertently disclose its identity (username) to an attacker.
RECOMMENDED for EAP peers to not use EAP-TLS with TLS 1.2 (or lower)
and RSA based ciphersuites without privacy. Therefore, it is RECOMMENDED for EAP peers to not use EAP-TLS with
TLS 1.2 (or lower) and RSA based cipher suites without privacy.
5.7. Pervasive Monitoring 5.7. Pervasive Monitoring
As required by [RFC7258], work on IETF protocols needs to consider As required by [RFC7258], work on IETF protocols needs to consider
the effects of pervasive monitoring and mitigate them when possible. the effects of pervasive monitoring and mitigate them when possible.
Pervasive Monitoring is widespread surveillance of users. By Pervasive Monitoring is widespread surveillance of users. By
encrypting more information, TLS 1.3 offers much better protection encrypting more information and by mandating the use of privacy, TLS
against pervasive monitoring. In addition to the privacy attacks 1.3 offers much better protection against pervasive monitoring. In
discussed above, surveillance on a large scale may enable tracking of addition to the privacy attacks discussed above, surveillance on a
a user over a wider geographical area and across different access large scale may enable tracking of a user over a wider geographical
networks. Using information from EAP-TLS together with information area and across different access networks. Using information from
gathered from other protocols increases the risk of identifying EAP-TLS together with information gathered from other protocols
individual users. increases the risk of identifying individual users.
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 19, line 42 skipping to change at page 21, line 22
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[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 0.7.1, February 2018. System", 3GPP TS 33.501 15.2.0, September 2018.
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].
 End of changes. 34 change blocks. 
120 lines changed or deleted 140 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/