draft-ietf-emu-eap-tls13-00.txt   draft-ietf-emu-eap-tls13-01.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 May 29, 2018 Intended status: Standards Track September 18, 2018
Expires: November 30, 2018 Expires: March 22, 2019
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-00 draft-ietf-emu-eap-tls13-01
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. This
document updates RFC 5216. document updates RFC 5216.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 November 30, 2018. This Internet-Draft will expire on March 22, 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 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. Resumption . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Resumption . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Termination . . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Termination . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 2.1.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 12 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 12
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Parameter Negotiation and Compliance Requirements . . . . 13 2.4. Parameter Negotiation and Compliance Requirements . . . . 13
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 13 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 13
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 14
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 14 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 14
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 14 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 15
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 14 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 15
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 14 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 15
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 15 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15 5.7. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 15
6.2. Informative references . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Updated references . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . 16
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18 6.2. Informative references . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Updated references . . . . . . . . . . . . . . . . . 19
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 2, line 49 skipping to change at page 3, line 4
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
secret keying material. EAP-TLS is widely supported for secret keying material. EAP-TLS is widely supported for
authentication in IEEE 802.11 [IEEE-802.11] networks (Wi-Fi) using authentication in IEEE 802.11 [IEEE-802.11] networks (Wi-Fi) using
IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for IEEE 802.1X [IEEE-802.1X] and it's the default mechanism for
certificate based authentication in MulteFire [MulteFire] and 3GPP 5G certificate based authentication in MulteFire [MulteFire] and 3GPP 5G
[TS.33.501] networks. EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] [TS.33.501] networks. EAP-TLS [RFC5216] references TLS 1.0 [RFC2246]
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]. [RFC5246].
Weaknesses found in previous versions of TLS, as well as new Weaknesses found in previous versions of TLS, as well as new
requirements for security, privacy, and reduced latency has led to requirements for security, privacy, and reduced latency has led to
the development of TLS 1.3 [I-D.ietf-tls-tls13], which in large parts the development of TLS 1.3 [RFC8446], which in large parts is a
is a complete remodeling of the TLS handshake protocol including a complete remodeling of the TLS handshake protocol including a
different message flow, different handshake messages, different key different message flow, different handshake messages, different key
schedule, different cipher suites, different resumption, and schedule, different cipher suites, different resumption, and
different privacy protection. This means that significant parts of different privacy protection. This means that significant parts of
the normative text in the previous EAP-TLS specification [RFC5216] the normative text in the previous EAP-TLS specification [RFC5216]
are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore, are not applicable to EAP-TLS with TLS 1.3 (or higher). Therefore,
aspects such as resumption, privacy handling, and key derivation need aspects such as resumption, privacy handling, and key derivation need
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.
skipping to change at page 3, line 35 skipping to change at page 3, line 39
When EAP-TLS is used with support for privacy, TLS 1.3 requires two When EAP-TLS is used with support for privacy, TLS 1.3 requires two
fewer round-trips. TLS 1.3 also introduces more possibilities to fewer round-trips. TLS 1.3 also introduces more possibilities to
reduce fragmentation when compared to earlier versions of TLS. reduce fragmentation when compared 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. Readers document are to be interpreted as described in [RFC2119]. Readers
are expected to be familiar with the terms and concepts used in EAP- are expected to be familiar with the terms and concepts used in EAP-
TLS [RFC5216] and TLS 1.3 [I-D.ietf-tls-tls13]. TLS [RFC5216] and TLS 1.3 [RFC8446].
2. Protocol Overview 2. Protocol Overview
2.1. Overview of the EAP-TLS Conversation 2.1. Overview of the EAP-TLS Conversation
2.1.1. Base Case 2.1.1. Base Case
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 [RFC5216] does not apply for TLS 1.3 (or higher). of RFC5216 [RFC5216] does not apply for TLS 1.3 (or higher).
After receiving an EAP-Request packet with EAP-Type=EAP-TLS as After receiving an EAP-Request packet with EAP-Type=EAP-TLS as
described in [RFC5216] the conversation will continue with the TLS described in [RFC5216] the conversation will continue with the TLS
handshake protocol encapsulated in the data fields of EAP-Response handshake protocol encapsulated in the data fields of EAP-Response
and EAP-Request packets. When EAP-TLS is used with TLS version 1.3 and EAP-Request packets. When EAP-TLS is used with TLS version 1.3
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 [I-D.ietf-tls-tls13] 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, the EAP server sends EAP-
Success. 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 conversation will appear as shown in Figure 1. The EAP server
commits to not send any more handshake messages by sending an empty
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 (MyID) -------->
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-Success
Figure 1: EAP-TLS mutual authentication Figure 1: EAP-TLS mutual authentication
When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support When using EAP-TLS with TLS 1.3, the EAP server MUST indicate support
skipping to change at page 6, line 32 skipping to change at page 6, 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 NewSessionTicket) (TLS NewSessionTicket,
<-------- TLS empty record)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
<-------- EAP-Success <-------- EAP-Success
Figure 2: EAP-TLS ticket establishment Figure 2: EAP-TLS ticket establishment
2.1.2. Resumption 2.1.2. 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
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 For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If
[I-D.ietf-tls-tls13]. If the client has received a NewSessionTicket the client has received a NewSessionTicket message from the server,
message from the server, the client can use the PSK identity received the client can use the PSK identity received in the ticket to
in the ticket to negotiate the use of the associated PSK. If the negotiate the use of the associated PSK. If the server accepts it,
server accepts it, then the security context of the new connection is then the security context of the new connection is tied to the
tied to the original connection and the key derived from the initial original connection and the key derived from the initial handshake is
handshake is used to bootstrap the cryptographic state instead of a used to bootstrap the cryptographic state instead of a full
full handshake. It is left up to the EAP peer whether to use handshake. It is left up to the EAP peer whether to use resumption,
resumption, but a EAP peer SHOULD use resumption as long as it has a but a EAP peer SHOULD use resumption as long as it has a valid ticket
valid ticket cached. It is RECOMMENDED that the EAP server accept cached. It is RECOMMENDED that the EAP server accept resumption as
resumption as long as the ticket is valid. However, the server MAY long as the ticket is valid. However, the server MAY choose to
choose to require a full authentication. 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 (MyID) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Start) <-------- (TLS Start)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ClientHello) --------> (TLS ClientHello) -------->
EAP-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
(TLS ServerHello, (TLS ServerHello,
TLS EncryptedExtensions, TLS EncryptedExtensions,
<-------- TLS Finished) TLS Finished,
<-------- TLS empty record)
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 [I-D.ietf-tls-tls13], the EAP peer As specified in Section 2.2 of [RFC8446], the EAP peer SHOULD supply
SHOULD supply a "key_share" extension when offering resumption, which a "key_share" extension when offering resumption, which allows the
allows the EAP server to decline resumption and continue the EAP server to decline resumption and continue the handshake as a full
handshake as a full handshake. The message flow in this case is handshake. The message flow in this case is given by Figure 1 or
given by Figure 1 or Figure 2. If the EAP peer did not supply a Figure 2. If the EAP peer did not supply a "key_share" extension
"key_share" extension when offering resumption, the EAP server needs when offering resumption, the EAP server needs to reject the
to reject the ClientHello and the EAP peer needs to restart a full ClientHello and the EAP peer needs to restart a full handshake. The
handshake. The message flow in this case is given by Figure 4 message flow in this case is given by Figure 4 followed by Figure 1
followed by Figure 1 or Figure 2. or Figure 2.
2.1.3. Termination 2.1.3. Termination
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 RC5216 [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 RC5216 [RFC5216] when EAP-TLS is used paragraphs in Section 2.1.3 of RFC 5216 [RFC5216] when EAP-TLS is
with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3
RC5216 [RFC5216] still apply with the exception that SessionID is of RFC 5216 [RFC5216] still apply with the exception that SessionID
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 confirming the processing in 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 confirming to the processing in the version of TLS used.
The message flow ends with the EAP Server sending a EAP-Success The message flow ends with the EAP Server sending a EAP-Success
message. message.
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 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 Alert Message) (TLS Alert Message)
--------> -------->
<-------- 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
skipping to change at page 10, line 24 skipping to change at page 10, 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 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-Request/ EAP-Request/
EAP-Type=EAP-TLS EAP-Type=EAP-TLS
<-------- (TLS Alert Message) <-------- (TLS Alert Message)
EAP-Response/ EAP-Response/
EAP-Type=EAP-TLS --------> EAP-Type=EAP-TLS -------->
skipping to change at page 11, line 40 skipping to change at page 11, line 40
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-Success
Figure 7: EAP-TLS privacy Figure 7: EAP-TLS privacy
2.1.5. Fragmentation 2.1.5. Fragmentation
skipping to change at page 12, line 17 skipping to change at page 12, line 17
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. It 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
[I-D.ietf-tls-tls13]). To avoid fragmentation, the use of ECC in [RFC8446]). To avoid fragmentation, the use of ECC in certificates,
certificates, signature algorithms, and groups are RECOMMENDED when signature algorithms, and groups are RECOMMENDED when using EAP-TLS
using EAP-TLS with TLS 1.3 or higher. At a 128-bit security level, with TLS 1.3 or higher. At a 128-bit security level, this reduces
this reduces public key sizes from 384 bytes (RSA and DHE) to 32 public key sizes from 384 bytes (RSA and DHE) to 32 bytes (ECDHE) and
bytes (ECDHE) and signatures from 384 bytes (RSA) to 64 bytes (ECDSA signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA). An
and EdDSA). An EAP-TLS deployment MAY further reduce the certificate EAP-TLS deployment MAY further reduce the certificate sizes by
sizes by limiting the number of Subject Alternative Names. limiting the number of Subject Alternative Names.
Endpoints SHOULD reduce the sizes of Certificate messages by omitting Endpoints SHOULD reduce the sizes of Certificate messages by omitting
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 [I-D.ietf-tls-tls13]). When using TLS omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or
1.2 or earlier, only the self-signed certificate that specifies the earlier, only the self-signed certificate that specifies the root
root certificate authority may be omitted (see Section 7.4.2 of certificate authority may be omitted (see Section 7.4.2 of
[RFC5246]). EAP-TLS peers and servers SHOULD support and use the [RFC5246]). EAP-TLS peers and servers SHOULD support and use the
Cached Information Extension as specified in [RFC7924]. EAP-TLS Cached Information Extension as specified in [RFC7924]. EAP-TLS
peers and servers MAY use other extensions for reducing the sizes of peers and servers MAY use other extensions for reducing the sizes of
Certificate messages, e.g. certificate compression Certificate messages, e.g. certificate compression
[I-D.ietf-tls-certificate-compression]. [I-D.ietf-tls-certificate-compression].
2.2. Identity Verification 2.2. Identity Verification
No updates to [RFC5216]. No updates to [RFC5216].
2.3. Key Hierarchy 2.3. Key Hierarchy
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 TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446].
[I-D.ietf-tls-tls13].
When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, When EAP-TLS is used with TLS version 1.3 or higher the Key_Material,
IV, and Session-Id SHALL be derived from the exporter_master_secret IV, and Method-Id SHALL be derived from the exporter_master_secret
using the TLS exporter interface [RFC5705] (for TLS 1.3 this is using the TLS exporter interface [RFC5705] (for TLS 1.3 this is
defined in Section 7.5 of [I-D.ietf-tls-tls13]). defined in Section 7.5 of [RFC8446]).
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128) Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128)
IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", "", 64) IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", "", 64)
Session-Id = TLS-Exporter("EXPORTER_EAP_TLS_Session-Id", "", 64) Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", "", 64)
Session-Id = 0x0D || Method-Id
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
without having to extract the Master Secret, ClientHello.random, and without having to extract the Master Secret, ClientHello.random, and
ServerHello.random in a non-standard way. ServerHello.random in a non-standard way.
All other parameters such as MSK and EMSK are derived as specified in All other parameters such as MSK and EMSK are derived as specified in
EAP-TLS [RFC5216], Section 2.3. The use of these keys is specific to EAP-TLS [RFC5216], Section 2.3. The use of these keys is specific to
the lower layer, as described [RFC5247]. the lower layer, as described [RFC5247].
2.4. Parameter Negotiation and Compliance Requirements 2.4. Parameter Negotiation and Compliance Requirements
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 [I-D.ietf-tls-tls13]), and the versions of TLS (see Section B.4 of [RFC8446]), and the cipher suites
cipher suites discussed in Section 2.4 of [RFC5216] can therefore not discussed in Section 2.4 of [RFC5216] can therefore not be used when
be used when EAP-TLS is used with TLS version 1.3 or higher. The EAP-TLS is used with TLS version 1.3 or higher. The requirements on
requirements on protocol version and compression given in Section 2.4 protocol version and compression given in Section 2.4 of [RFC5216]
of [RFC5216] still apply. still apply.
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 [I-D.ietf-tls-tls13]. Section 9 of [RFC8446].
2.5. EAP State Machines
TLS 1.3 [RFC8446] introduces Post-Handshake messages. These Post-
Handshake messages use the handshake content type and can be sent
after the main handshake. One such Post-Handshake message is
NewSessionTicket. The NewSessopmTicket can be used for resumption.
After sending TLS Finished, the EAP server may send any number of
Post-Handshake messages in separate EAP-Requests. To decrease the
uncertainty for the EAP Peer, the following procedure MUST be
followed:
When an EAP Server has sent its last handshake message (Finished or a
Post-Handshake), it commits to not sending any more handshake
messages by appending an empty application data record (i.e. a TLS
record with TLSPlaintext.type = application_data and
TLSPlaintext.length = 0) to the last handshake record. After sending
an empty application data record, the EAP Server may only send an
EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
Message.
Note that the use of an empty application data record does not
violate the requirement that the TLS cipher suite shall not be used
to protect application data, as the application data is the empty
string, no application data is protected.
3. Detailed Description of the EAP-TLS Protocol 3. Detailed Description of the EAP-TLS Protocol
No updates to [RFC5216]. No updates to [RFC5216].
4. IANA considerations 4. IANA considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the EAP- Authority (IANA) regarding registration of values related to the EAP-
TLS 1.3 protocol in accordance with [RFC8126]. TLS 1.3 protocol in accordance with [RFC8126].
This memo requires IANA to add the following labels to the TLS This memo requires IANA to add the following labels to the TLS
Exporter Label Registry defined by [RFC5705]. These labels are used Exporter Label Registry defined by [RFC5705]. These labels are used
in derivation of Key_Material, IV and Session-Id as defined in in derivation of Key_Material, IV and Method-Id as defined in
Section 2.3: Section 2.3:
o "EXPORTER_EAP_TLS_Key_Material" o "EXPORTER_EAP_TLS_Key_Material"
o "EXPORTER_EAP_TLS_IV" o "EXPORTER_EAP_TLS_IV"
o "EXPORTER_EAP_TLS_Session-Id"
o "EXPORTER_EAP_TLS_Method-Id"
5. Security Considerations 5. Security Considerations
5.1. Security Claims 5.1. Security Claims
Using EAP-TLS with TLS 1.3 does not change the security claims for Using EAP-TLS with TLS 1.3 does not change the security claims for
EAP-TLS as given in Section 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 [I-D.ietf-tls-tls13]. When using EAP-TLS with the extensions, see [RFC8446]. When using EAP-TLS with TLS 1.3, the
TLS 1.3, the use of privacy does not cause any additional round- use of privacy does not cause any additional round-trips.
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 [I-D.ietf-tls-tls13]. 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
groups, and signature algorithm, see Section 4.1.1 of groups, and signature algorithm, see Section 4.1.1 of [RFC8446].
[I-D.ietf-tls-tls13].
5.2. Peer and Server Identities 5.2. Peer and Server Identities
No updates to [RFC5216]. No updates to [RFC5216].
5.3. Certificate Validation 5.3. Certificate Validation
No updates to [RFC5216]. No updates to [RFC5216].
5.4. Certificate Revocation 5.4. Certificate Revocation
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 [I-D.ietf-tls-tls13]. In TLS versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the
1.3 the OCSP information is carried in the CertificateEntry OCSP information is carried in the CertificateEntry containing the
containing the associated certificate instead of a separate associated certificate instead of a separate CertificateStatus
CertificateStatus message as in [RFC4366]. This enables sending OCSP message as in [RFC4366]. This enables sending OCSP information for
information for all certificates in the certificate chain. all certificates in the certificate chain.
EAP-TLS peers and servers supporting TLS 1.3 SHOULD support EAP-TLS peers and servers supporting TLS 1.3 SHOULD support
Certificate Status Requests (OCSP stapling) as specified in [RFC6066] Certificate Status Requests (OCSP stapling) as specified in [RFC6066]
and Section 4.4.2.1 of [I-D.ietf-tls-tls13]. The use of Certificate and Section 4.4.2.1 of [RFC8446]. The use of Certificate Status
Status Requests to determine the current status of the EAP server's Requests to determine the current status of the EAP server's
certificate is RECOMMENDED. certificate is RECOMMENDED.
5.5. Packet Modification Attacks 5.5. Packet Modification Attacks
No updates to [RFC5216]. No updates to [RFC5216].
5.6. Privacy
[RFC6973] suggests that the privacy considerations of IETF protocols
be documented.
TODO
5.7. Pervasive Monitoring
As required by [RFC7258], work on IETF protocols needs to consider
the effects of pervasive monitoring and mitigate them when possible.
TODO
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
skipping to change at page 16, line 25 skipping to change at page 17, line 10
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924, (TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016, DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>. <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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
6.2. Informative references 6.2. Informative references
[I-D.ietf-tls-certificate-compression] [I-D.ietf-tls-certificate-compression]
Ghedini, A. and V. Vasiliev, "Transport Layer Security Ghedini, A. and V. Vasiliev, "Transport Layer Security
(TLS) Certificate Compression", draft-ietf-tls- (TLS) Certificate Compression", draft-ietf-tls-
certificate-compression-03 (work in progress), April 2018. certificate-compression-03 (work in progress), April 2018.
[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
skipping to change at page 17, line 42 skipping to change at page 18, line 36
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008, RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>. <https://www.rfc-editor.org/info/rfc5247>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
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 0.7.1, February 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].
All references to [RFC4282] are updated with [RFC7542]. All references to [RFC4282] are updated with [RFC7542].
Appendix B. Acknowledgments Appendix B. Acknowledgments
The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba, The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba,
Jari Arkko, and Vesa Torvinen for comments and suggestions on the Eric Rescorla, Jari Arkko, Jim Schaad, Jouni Malinen, and Vesa
draft. Torvinen for comments and suggestions on the draft.
Authors' Addresses Authors' Addresses
John Mattsson John Mattsson
Ericsson Ericsson
164 40 Stockholm 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
Email: mohit@piuha.net Email: mohit@piuha.net
 End of changes. 43 change blocks. 
97 lines changed or deleted 156 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/