draft-ietf-emu-eap-tls13-12.txt   draft-ietf-emu-eap-tls13-13.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 November 2, 2020 Intended status: Standards Track November 19, 2020
Expires: May 6, 2021 Expires: May 23, 2021
Using EAP-TLS with TLS 1.3 Using EAP-TLS with TLS 1.3
draft-ietf-emu-eap-tls13-12 draft-ietf-emu-eap-tls13-13
Abstract Abstract
This document specifies the use of EAP-TLS with TLS 1.3 while This document specifies the use of EAP-TLS with TLS 1.3 while
remaining backwards compatible with existing implementations of EAP- remaining backwards compatible with existing implementations of EAP-
TLS. TLS 1.3 provides significantly improved security, privacy, and TLS. TLS 1.3 provides significantly improved security, privacy, and
reduced latency when compared to earlier versions of TLS. EAP-TLS reduced latency when compared to earlier versions of TLS. EAP-TLS
with TLS 1.3 further improves security and privacy by mandating use with TLS 1.3 further improves security and privacy by mandating use
of privacy and revocation checking. This document also provides of privacy and revocation checking. This document also provides
guidance on authorization and resumption for EAP-TLS in general guidance on authorization and resumption for EAP-TLS in general
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2021. This Internet-Draft will expire on May 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 14 2.1.9. Fragmentation . . . . . . . . . . . . . . . . . . . . 14
2.2. Identity Verification . . . . . . . . . . . . . . . . . . 15 2.2. Identity Verification . . . . . . . . . . . . . . . . . . 15
2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . 15
2.4. Parameter Negotiation and Compliance Requirements . . . . 16 2.4. Parameter Negotiation and Compliance Requirements . . . . 16
2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 17 2.5. EAP State Machines . . . . . . . . . . . . . . . . . . . 17
3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 18 3. Detailed Description of the EAP-TLS Protocol . . . . . . . . 18
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 19 5.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 19
5.2. Peer and Server Identities . . . . . . . . . . . . . . . 19 5.2. Peer and Server Identities . . . . . . . . . . . . . . . 19
5.3. Certificate Validation . . . . . . . . . . . . . . . . . 19 5.3. Certificate Validation . . . . . . . . . . . . . . . . . 20
5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 20 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 20
5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 20 5.5. Packet Modification Attacks . . . . . . . . . . . . . . . 20
5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 20 5.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 21
5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 21 5.7. Resumption . . . . . . . . . . . . . . . . . . . . . . . 21
5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 23 5.8. Privacy Considerations . . . . . . . . . . . . . . . . . 23
5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 24 5.9. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 25
5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 25 5.10. Discovered Vulnerabilities . . . . . . . . . . . . . . . 25
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Normative References . . . . . . . . . . . . . . . . . . 25 6.1. Normative References . . . . . . . . . . . . . . . . . . 25
6.2. Informative references . . . . . . . . . . . . . . . . . 26 6.2. Informative references . . . . . . . . . . . . . . . . . 26
Appendix A. Updated references . . . . . . . . . . . . . . . . . 29 Appendix A. Updated references . . . . . . . . . . . . . . . . . 30
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
provides a standard mechanism for support of multiple authentication provides a standard mechanism for support of multiple authentication
methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216] specifies
an EAP authentication method with certificate-based mutual an EAP authentication method with certificate-based mutual
skipping to change at page 7, line 21 skipping to change at page 7, line 21
accepts it, then the security context of the new connection is tied accepts it, then the security context of the new connection is tied
to the original connection and the key derived from the initial to the original connection and the key derived from the initial
handshake is used to bootstrap the cryptographic state instead of a handshake is used to bootstrap the cryptographic state instead of a
full handshake. It is left up to the EAP-TLS peer whether to use full handshake. It is left up to the EAP-TLS peer whether to use
resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption, but it is RECOMMENDED that the EAP-TLS server accept
resumption as long as the ticket is valid. However, the EAP-TLS resumption as long as the ticket is valid. However, the EAP-TLS
server MAY choose to require a full authentication. EAP-TLS peers server MAY choose to require a full authentication. EAP-TLS peers
and EAP-TLS servers SHOULD follow the client tracking preventions in and EAP-TLS servers SHOULD follow the client tracking preventions in
Appendix C.4 of [RFC8446]. Appendix C.4 of [RFC8446].
It is RECOMMENDED to use a NAIs with the same realm in the resumption It is RECOMMENDED to use a Network Access Identifiers (NAIs) with the
and the original full authentication. This requirement allows EAP same realm in the resumption and the original full authentication.
packets to be routable to the same destination as the original full This requirement allows EAP packets to be routable to the same
authentication. If this recommendation is not followed, resumption destination as the original full authentication. If this
is likely to be impossible. When NAI reuse can be done without recommendation is not followed, resumption is likely to be
privacy implications, it is RECOMMENDED to use the same anonymous NAI impossible. When NAI reuse can be done without privacy implications,
in the resumption, as was used in the original full authentication. it is RECOMMENDED to use the same anonymous NAI in the resumption, as
E.g. the NAI @realm can safely be reused, while the NAI was used in the original full authentication. E.g. the NAI @realm
ZmxleG8=@realm cannot. The TLS PSK identity is typically derived by can safely be reused, while the NAI ZmxleG8=@realm cannot. The TLS
the TLS implementation and may be an opaque blob without a routable PSK identity is typically derived by the TLS implementation and may
realm. The TLS PSK identity is therefore in general unsuitable for be an opaque blob without a routable realm. The TLS PSK identity is
deriving a NAI to use in the Identity Response. therefore in general unsuitable for deriving a NAI to use in the
Identity Response.
A subsequent authentication using resumption, where both sides A subsequent authentication using resumption, where both sides
authenticate successfully (without the issuance of more resumption authenticate successfully (without the issuance of more resumption
tickets) is shown in Figure 3. tickets) is shown in Figure 3.
EAP-TLS Peer EAP-TLS Server EAP-TLS Peer EAP-TLS Server
EAP-Request/ EAP-Request/
<-------- Identity <-------- Identity
EAP-Response/ EAP-Response/
skipping to change at page 19, line 5 skipping to change at page 19, line 5
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 Method-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" +-------------------------------+---------+-------------+------+
| Value | DTLS-OK | Recommended | Note |
o "EXPORTER_EAP_TLS_IV" +-------------------------------+---------+-------------+------+
| EXPORTER_EAP_TLS_Key_Material | N | Y | |
| | | | |
| EXPORTER_EAP_TLS_IV | N | Y | |
| | | | |
| EXPORTER_EAP_TLS_Method-Id | N | Y | |
+-------------------------------+---------+-------------+------+
o "EXPORTER_EAP_TLS_Method-Id" Table 1: TLS Exporter Label Registry
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 5.1 of [RFC5216]. However, it EAP-TLS as given in Section 5.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 5.1 of [RFC5216]. updates to the notes given in Section 5.1 of [RFC5216].
skipping to change at page 20, line 33 skipping to change at page 20, line 37
EAP-TLS server's certificate chain. When an EAP-TLS peer uses EAP-TLS server's certificate chain. When an EAP-TLS peer uses
Certificate Status Requests to check the revocation status of the Certificate Status Requests to check the revocation status of the
EAP-TLSserver's certificate chain it MUST treat a CertificateEntry EAP-TLSserver's certificate chain it MUST treat a CertificateEntry
(except the trust anchor) without a valid CertificateStatus extension (except the trust anchor) without a valid CertificateStatus extension
as invalid and abort the handshake with an appropriate alert. The as invalid and abort the handshake with an appropriate alert. The
OCSP status handling in TLS 1.3 is different from earlier versions of OCSP status handling in TLS 1.3 is different from earlier versions of
TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the OCSP
information is carried in the CertificateEntry containing the information is carried in the CertificateEntry containing the
associated certificate instead of a separate CertificateStatus associated certificate instead of a separate CertificateStatus
message as in [RFC4366]. This enables sending OCSP information for message as in [RFC4366]. This enables sending OCSP information for
all certificates in the certificate chain. all certificates in the certificate chain (except the trust anchor).
To enable revocation checking in situations where EAP-TLS peers do To enable revocation checking in situations where EAP-TLS peers do
not implement or use OCSP stapling, and where network connectivity is not implement or use OCSP stapling, and where network connectivity is
not available prior to authentication completion, EAP--TLS peer not available prior to authentication completion, EAP--TLS peer
implementations MUST also support checking for certificate revocation implementations MUST also support checking for certificate revocation
after authentication completes and network connectivity is available, after authentication completes and network connectivity is available,
and they SHOULD utilize this capability by default. and they SHOULD utilize this capability by default.
5.5. Packet Modification Attacks 5.5. Packet Modification Attacks
skipping to change at page 26, line 38 skipping to change at page 27, line 8
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
6.2. Informative references 6.2. Informative references
[I-D.ietf-emu-eaptlscert] [I-D.ietf-emu-eaptlscert]
Sethi, M., Mattsson, J., and S. Turner, "Handling Large Sethi, M., Mattsson, J., and S. Turner, "Handling Large
Certificates and Long Certificate Chains in TLS-based EAP Certificates and Long Certificate Chains in TLS-based EAP
Methods", draft-ietf-emu-eaptlscert-06 (work in progress), Methods", draft-ietf-emu-eaptlscert-07 (work in progress),
October 2020. November 2020.
[I-D.ietf-tls-md5-sha1-deprecate] [I-D.ietf-tls-md5-sha1-deprecate]
Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating
MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf- MD5 and SHA-1 signature hashes in TLS 1.2", draft-ietf-
tls-md5-sha1-deprecate-04 (work in progress), October tls-md5-sha1-deprecate-04 (work in progress), October
2020. 2020.
[I-D.ietf-tls-oldversions-deprecate] [I-D.ietf-tls-oldversions-deprecate]
Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and
TLSv1.1", draft-ietf-tls-oldversions-deprecate-08 (work in TLSv1.1", draft-ietf-tls-oldversions-deprecate-09 (work in
progress), October 2020. progress), November 2020.
[IEEE-802.11] [IEEE-802.11]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standard for Information technology--Telecommunications Standard for Information technology--Telecommunications
and information exchange between systems Local and and information exchange between systems Local and
metropolitan area networks--Specific requirements - Part metropolitan area networks--Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Std 802.11-2016 Layer (PHY) Specifications", IEEE Std 802.11-2016
(Revision of IEEE Std 802.11-2012) , December 2016. (Revision of IEEE Std 802.11-2012) , December 2016.
 End of changes. 13 change blocks. 
29 lines changed or deleted 36 lines changed or added

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