draft-ietf-emu-eap-tls13-01.txt   draft-ietf-emu-eap-tls13-02.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 September 18, 2018 Intended status: Standards Track October 16, 2018
Expires: March 22, 2019 Expires: April 19, 2019
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-01 draft-ietf-emu-eap-tls13-02
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 March 22, 2019. This Internet-Draft will expire on April 19, 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 30 skipping to change at page 2, line 30
2.4. Parameter Negotiation and Compliance Requirements . . . . 13 2.4. Parameter Negotiation and Compliance Requirements . . . . 13
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 13 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 13
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 14 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 14
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 15 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 15
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 15 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 15
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 15 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 15
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 15 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 15
5.6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6. Privacy Considerations . . . . . . . . . . . . . . . . . 15
5.7. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 15 5.7. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . 16
6.2. Informative references . . . . . . . . . . . . . . . . . 17 6.2. Informative references . . . . . . . . . . . . . . . . . 18
Appendix A. Updated references . . . . . . . . . . . . . . . . . 19 Appendix A. Updated references . . . . . . . . . . . . . . . . . 19
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 36 skipping to change at page 3, line 36
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 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", "NOT RECOMMENDED","MAY", and
document are to be interpreted as described in [RFC2119]. Readers "OPTIONAL" in this document are to be interpreted as described in BCP
are expected to be familiar with the terms and concepts used in EAP- 14 [RFC2119] [RFC8174] when, and only when, they appear in all
TLS [RFC5216] and TLS 1.3 [RFC8446]. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts used
in EAP-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).
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 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.
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/
skipping to change at page 10, line 42 skipping to change at page 10, line 42
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 -------->
<-------- EAP-Failure <-------- EAP-Failure
Figure 6: EAP-TLS unsuccessful client authentication Figure 6: EAP-TLS unsuccessful client authentication
2.1.4. Privacy 2.1.4. Privacy
TLS 1.3 significantly increases privacy when compared to earlier TLS 1.3 significantly improves privacy when compared to earlier
version 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
certificate messages. certificate messages.
EAP-TLS peer and server implementations supporting TLS 1.3 or higher EAP-TLS peer and server implementations supporting TLS 1.3 or higher
MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4
in [RFC7542]) and the client MUST confidentiality protect its in [RFC7542]) and the client MUST confidentiality protect its
identity (e.g. using Anonymous NAIs) when the EAP-TLS server is known identity (e.g. using Anonymous NAIs) when the EAP-TLS server is known
to support TLS 1.3 or higher. to support TLS 1.3 or higher.
As the certificate messages in TLS 1.3 are encrypted, there is no As the certificate messages in TLS 1.3 are encrypted, there is no
need to send an empty certificate_list or perform a second handshake need to send an empty certificate_list or perform a second handshake
(as needed by EAP-TLS when with earlier versions of TLS). When EAP- (as needed by EAP-TLS with earlier versions of TLS). When EAP-TLS is
TLS is used with TLS version 1.3 or higher the EAP-TLS peer and EAP- used with TLS version 1.3 or higher the EAP-TLS peer and EAP-TLS
TLS server SHALL follow the processing specified by the used version server SHALL follow the processing specified by the used version of
of TLS. For TLS 1.3 this means that the EAP-TLS peer only sends an 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 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 to send, and the EAP-TLS server MAY treat an empty certificate_list
a terminal condition. as a terminal condition.
When EAP-TLS is used with TLS 1.3 and privacy, no extra round-trips 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 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 with the only difference that an anonymous NAI is used. In the case
where EAP-TLS with mutual authentication and privacy is successful, where EAP-TLS with mutual authentication and privacy is successful,
the conversation will appear as shown in Figure 7. the conversation will appear as shown in Figure 7.
EAP Peer EAP Server EAP Peer EAP Server
EAP-Request/ EAP-Request/
skipping to change at page 13, line 40 skipping to change at page 13, line 40
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 NewSessopmTicket 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
an empty application data record, the EAP Server may only send an 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 EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
Message. Message.
Note that the use of an empty application data record does not Note that the use of an empty application data record does not
violate the requirement that the TLS cipher suite shall not be used violate the requirement that the TLS cipher suite shall not be used
to protect application data, as the application data is the empty to protect application data, as the application data is the empty
string, no application data is protected. string, no application data is protected.
3. Detailed Description of the EAP-TLS Protocol 3. Detailed Description of the EAP-TLS Protocol
skipping to change at page 15, line 35 skipping to change at page 15, line 35
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 [RFC8446]. The use of Certificate Status and Section 4.4.2.1 of [RFC8446]. The use of Certificate 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 5.6. Privacy Considerations
[RFC6973] suggests that the privacy considerations of IETF protocols [RFC6973] suggests that the privacy considerations of IETF protocols
be documented. be documented.
TODO 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
privacy properties of EAP-TLS with TLS 1.3. For privacy properties
of TLS 1.3 itself, see [RFC8446].
EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in
EAP packets. Additionally, the EAP peer sends an identity in the
first EAP-Response. The fields in the EAP-TLS Request and the EAP-
TLS Response packets do not contain any cleartext privacy sensitive
information.
It is strongly RECOMMENDED to confidentiality protect the identity
(e.g. using Anonymous NAIs), as the username part of the NAI may
otherwise enable identification and tracking of the user. However,
as with other EAP methods, even when privacy-friendly identifiers or
EAP tunneling is used, the domain name (i.e. the realm) in the NAI is
still typically visible. How much privacy sensitive information the
domain name 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 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 attacker in tracking or identifying the user.
An EAP peer with a policy allowing communication with EAP servers
supporting only TLS 1.2 (or lower) without privacy and with RSA key
exchange is vulnerable to disclosure of the peer username. An active
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
simply impersonate the EAP server and negotiate TLS 1.2 (or
lower)with RSA key exchange and send an TLS alert message when the
EAP peer tries to use privacy by sending an empty certificate
message. Since the attacker (impersonating the EAP server) does not
provide a proof-of-possession of the private key until the Finished
message when RSA key exchange is used, an EAP peer may inadvertently
disclose its identity (username) to an attacker. Therefore, it is
RECOMMENDED for EAP peers to not use EAP-TLS with TLS 1.2 (or lower)
and RSA based ciphersuites 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.
TODO Pervasive Monitoring is widespread surveillance of users. By
encrypting more information, TLS 1.3 offers much better protection
against pervasive monitoring. In addition to the privacy attacks
discussed above, surveillance on a large scale may enable tracking of
a user over a wider geographical area and across different access
networks. Using information from EAP-TLS together with information
gathered from other protocols 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 17, line 10 skipping to change at page 18, line 5
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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-tls-certificate-compression] [I-D.ietf-tls-certificate-compression]
Ghedini, A. and V. Vasiliev, "Transport Layer Security Ghedini, A. and V. Vasiliev, "TLS Certificate
(TLS) Certificate Compression", draft-ietf-tls- Compression", draft-ietf-tls-certificate-compression-04
certificate-compression-03 (work in progress), April 2018. (work in progress), October 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
and information exchange between systems Local and and information exchange between systems Local and
metropolitan area networks--Specific requirements - Part metropolitan area networks--Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Std 802.11-2016 Layer (PHY) Specifications", IEEE Std 802.11-2016
(Revision of IEEE Std 802.11-2012) , December 2016. (Revision of IEEE Std 802.11-2012) , December 2016.
skipping to change at page 19, line 16 skipping to change at page 20, line 7
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 Acknowledgments
The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba, The authors want to thank Alan DeKok, Ari Keraenen, Bernard Aboba,
Eric Rescorla, Jari Arkko, Jim Schaad, Jouni Malinen, and Vesa Eric Rescorla, Jari Arkko, Jim Schaad, Jouni Malinen, and Vesa
Torvinen for comments and suggestions on the draft. Torvinen for comments and suggestions on the draft.
Authors' Addresses Authors' Addresses
John Mattsson John Mattsson
Ericsson Ericsson
Stockholm 164 40 Stockholm 164 40
 End of changes. 22 change blocks. 
34 lines changed or deleted 84 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/