< draft-ms-emu-eaptlscert-02.txt		draft-ms-emu-eaptlscert-03.txt >
	Network Working Group M. Sethi		Network Working Group M. Sethi
	Internet-Draft J. Mattsson		Internet-Draft J. Mattsson
	Intended status: Informational Ericsson		Intended status: Informational Ericsson
	Expires: September 7, 2019 S. Turner		Expires: November 27, 2019 S. Turner
	sn3rd		sn3rd
	March 6, 2019		May 26, 2019
	Handling Large Certificates and Long Certificate Chains		Handling Large Certificates and Long Certificate Chains
	in TLS-based EAP Methods		in TLS-based EAP Methods
	draft-ms-emu-eaptlscert-02		draft-ms-emu-eaptlscert-03
	Abstract		Abstract
	EAP-TLS and other TLS-based EAP methods are widely deployed and used		EAP-TLS and other TLS-based EAP methods are widely deployed and used
	for network access authentication. Large certificates and long		for network access authentication. Large certificates and long
	certificate chains combined with authenticators that drop an EAP		certificate chains combined with authenticators that drop an EAP
	session after only 40 - 50 packets is a major deployment problem.		session after only 40 - 50 round-trips is a major deployment problem.
	This memo looks at the this problem in detail and describes the		This memo looks at the this problem in detail and describes the
	potential solutions available.		potential solutions available.
	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 September 7, 2019.		This Internet-Draft will expire on November 27, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Experience with Deployments . . . . . . . . . . . . . . . . . 3		3. Experience with Deployments . . . . . . . . . . . . . . . . . 4
	4. Handling of Large Certificates and Long Certificate Chains . 4		4. Handling of Large Certificates and Long Certificate Chains . 4
	4.1. Updating Certificates and Certificate Chains . . . . . . 4		4.1. Updating Certificates and Certificate Chains . . . . . . 4
	4.1.1. Guidelines for certificates . . . . . . . . . . . . . 5		4.1.1. Guidelines for certificates . . . . . . . . . . . . . 5
	4.2. Updating TLS and EAP-TLS Code . . . . . . . . . . . . . . 6		4.2. Updating TLS and EAP-TLS Code . . . . . . . . . . . . . . 6
	4.2.1. Pre-distributing and Omitting CA Certificates . . . . 6		4.2.1. Pre-distributing and Omitting CA Certificates . . . . 6
	4.2.2. Caching Certificates . . . . . . . . . . . . . . . . 6		4.2.2. Caching Certificates . . . . . . . . . . . . . . . . 6
	4.2.3. Compressing Certificates . . . . . . . . . . . . . . 7		4.2.3. Compressing Certificates . . . . . . . . . . . . . . 7
	4.3. Updating Authenticators (Access Points) . . . . . . . . . 7		4.2.4. Suppressing Intermediate Certificates . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.2. Informative References . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9		7.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	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]		methods. EAP-Transport Layer Security (EAP-TLS) [RFC5216]
	[I-D.ietf-emu-eap-tls13] relies on TLS [RFC8446] to provide strong		[I-D.ietf-emu-eap-tls13] relies on TLS [RFC8446] to provide strong
	mutual authentication with certificates [RFC5280] and is widely		mutual authentication with certificates [RFC5280] and is widely
	deployed and often used for network access authentication.		deployed and often used for network access authentication. There are
			also many other TLS-based EAP methods, such as FAST [RFC4851], TTLS
			[RFC5281], TEAP [RFC7170], and possibly many vendor specific EAP
			methods.
	TLS certificates are often relatively large, and the certificate		TLS certificates are often relatively large, and the certificate
	chains are often long. Unlike the use of TLS on the web, where		chains are often long. Unlike the use of TLS on the web, where
	typically only the TLS server is authenticated; EAP-TLS deployments		typically only the TLS server is authenticated; EAP-TLS deployments
	typically authenticates both the EAP peer and the EAP server. Also,		typically authenticates both the EAP peer and the EAP server. Also,
	from deployment experience, EAP peers typically have longer		from deployment experience, EAP peers typically have longer
	certificate chains than servers. Therefore, EAP-TLS authentication		certificate chains than servers. Therefore, EAP-TLS authentication
	usually involve significantly more bytes than when TLS is used as		usually involve significantly more bytes than when TLS is used as
	part of HTTPS.		part of HTTPS.
	As the EAP fragment size in typical deployments are just 1000 - 1500		As the EAP fragment size in typical deployments are just 1000 - 1500
	bytes, the EAP-TLS authentication needs to be fragmented into many		bytes, the EAP-TLS authentication needs to be fragmented into many
	smaller packets for transportation over the lower layers. Such		smaller packets for transportation over the lower layers. Such
	fragmentation can not only negatively affect the latency, but also		fragmentation can not only negatively affect the latency, but also
	results in other challenges. For example, many EAP authenticator		results in other challenges. For example, many EAP authenticator
	(access point) implementations will drop an EAP session if it hasn't		(access point) implementations will drop an EAP session if it hasn't
	finished after 40 - 50 packets. This is a major problem and means		finished after 40 - 50 round-trips. This is a major problem and
	that in many situations, the EAP peer cannot perform network access		means that in many situations, the EAP peer cannot perform network
	authentication even though both the sides have valid credentials for		access authentication even though both the sides have valid
	successful authentication and key derivation.		credentials for successful authentication and key derivation.
	This memo looks at related work and potential tools available for		This memo looks at related work and potential tools available for
	overcoming the deployment challenges induced by large certificates		overcoming the deployment challenges induced by large certificates
	and long certificate chains. It then discusses the solutions		and long certificate chains. It then discusses the solutions
	available to overcome these challenges.		available to overcome these challenges.
	2. Terminology		2. 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
	skipping to change at page 4, line 17 ¶		skipping to change at page 4, line 24 ¶
	o Can contain multiple object identifiers (OID) that indicate the		o Can contain multiple object identifiers (OID) that indicate the
	permitted uses of the certificate. For example, Windows requires		permitted uses of the certificate. For example, Windows requires
	certain OID's in the certificates for EAP-TLS to work.		certain OID's in the certificates for EAP-TLS to work.
	o Multiple user groups in the certificate.		o Multiple user groups in the certificate.
	The certificate chain can typically include 2 - 6 certificates to the		The certificate chain can typically include 2 - 6 certificates to the
	root-of-trust.		root-of-trust.
	Most common access point implementations drop EAP sessions that don't		Most common access point implementations drop EAP sessions that don't
	complete within 50 round trips. This means that if the chain is		complete within 50 round-trips. This means that if the chain is
	larger than ~ 60 kB, EAP-TLS authentication cannot complete		larger than ~ 60 kB, EAP-TLS authentication cannot complete
	successfully in most deployments.		successfully in most deployments.
	4. Handling of Large Certificates and Long Certificate Chains		4. Handling of Large Certificates and Long Certificate Chains
	This section discusses some possible alternatives for overcoming the		This section discusses some possible alternatives for overcoming the
	challenge of large certificates and long certificate chains in EAP-		challenge of large certificates and long certificate chains in EAP-
	TLS authentication. In Section 4.1 we look at recommendations that		TLS authentication. In Section 4.1 we look at recommendations that
	require an update of the certificates or certifcate chains that are		require an update of the certificates or certifcate chains that are
	used for EAP-TLS authentication without requiring changes to the		used for EAP-TLS authentication without requiring changes to the
	skipping to change at page 4, line 49 ¶		skipping to change at page 5, line 7 ¶
	[RFC6090] for the underlying cryptographic operations. The use of		[RFC6090] for the underlying cryptographic operations. The use of
	ECC can reduce the size of certificates and signatures. For example,		ECC can reduce the size of certificates and signatures. For example,
	at a 128-bit security level, the size of public keys with traditional		at a 128-bit security level, the size of public keys with traditional
	RSA is about 384 bytes, while the size of public keys with ECC is		RSA is about 384 bytes, while the size of public keys with ECC is
	only 32-64 bytes. Similarly, the size of digital signatures with		only 32-64 bytes. Similarly, the size of digital signatures with
	traditional RSA is 384 bytes, while the size is only 64 bytes with		traditional RSA is 384 bytes, while the size is only 64 bytes with
	elliptic curve digital signature algorithm (ECDSA) and Edwards-curve		elliptic curve digital signature algorithm (ECDSA) and Edwards-curve
	digital signature algorithm (EdDSA) [RFC8032]. Using certificates		digital signature algorithm (EdDSA) [RFC8032]. Using certificates
	that use ECC can reduce the number of messages in EAP-TLS		that use ECC can reduce the number of messages in EAP-TLS
	authentication which can alleviate the problem of authenticators		authentication which can alleviate the problem of authenticators
	dropping an EAP session because of too many packets. TLS 1.3		dropping an EAP session because of too many round-trips. TLS 1.3
	[RFC8446] requires implementations to support ECC. New cipher suites		[RFC8446] requires implementations to support ECC. New cipher suites
	that use ECC are also specified for TLS 1.2 [RFC5289]. Using ECC		that use ECC are also specified for TLS 1.2 [RFC5289]. Using ECC
	based cipher suites with existing code can significantly reduce the		based cipher suites with existing code can significantly reduce the
	number of messages in a single EAP session.		number of messages in a single EAP session.
	4.1.1. Guidelines for certificates		4.1.1. Guidelines for certificates
	This section provides some recommendations for certificates used for		This section provides some recommendations for certificates used for
	EAP-TLS authentication:		EAP-TLS authentication:
	skipping to change at page 7, line 19 ¶		skipping to change at page 7, line 22 ¶
	certificates and certificate chains during full handshakes. The		certificates and certificate chains during full handshakes. The
	client can indicate support for compressed server certificates by		client can indicate support for compressed server certificates by
	including this extension in the ClientHello message. Similarly, the		including this extension in the ClientHello message. Similarly, the
	server can indicate support for compression of client certificates by		server can indicate support for compression of client certificates by
	including this extension in the CertificateRequest message. While		including this extension in the CertificateRequest message. While
	such an extension can alleviate the problem of excessive		such an extension can alleviate the problem of excessive
	fragmentation in EAP-TLS, it can only be used with TLS version 1.3		fragmentation in EAP-TLS, it can only be used with TLS version 1.3
	and higher. Deployments that rely on older versions of TLS cannot		and higher. Deployments that rely on older versions of TLS cannot
	benefit from this extension.		benefit from this extension.
	4.3. Updating Authenticators (Access Points)		4.2.4. Suppressing Intermediate Certificates
	TODO: Shortly describe why this is hard.		For a client that has all intermediates, having the server send
			intermediates in the TLS handshake increases the size of the
			handshake unnecessarily. The TLS working group is working on an
			extension for TLS 1.3 [I-D.thomson-tls-sic] that allows a TLS client
			that has access to the complete set of published intermediate
			certificates to inform servers of this fact so that the server can
			avoid sending intermediates, reducing the size of the TLS handshake.
			The mechanism is intended to be complementary with certificate
			compression.
			4.3. Updating Authenticators
			There are several legitimate reasons that Authenticators may want to
			limit the number of round-trips/packets/bytes that can be sent. The
			main reason has been to work around issues where the EAP peer and EAP
			server end up in an infinite loop ACKing their messages. Another
			second reason is that unlimited communication from an unauthenticated
			device as EAP could otherwise be use for bulk data transfer. A third
			reason is to prevent denial-of-service attacks.
			Updating the millions of already deployed access points and switches
			is in many cases not realistic. Vendors may be out of business or do
			no longer support the products and admins may have lost the login
			information to the devices. For practical purposes the EAP
			infrastructure is ossified for the time being.
			Vendors making new authenticators should consider increasing the
			number of round-trips allowed before denying the EAP authentication
			to complete.
	5. IANA Considerations		5. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	6. Security Considerations		6. Security Considerations
	TBD		TBD
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-emu-eap-tls13]		[I-D.ietf-emu-eap-tls13]
	Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",		Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3",
	draft-ietf-emu-eap-tls13-03 (work in progress), November		draft-ietf-emu-eap-tls13-04 (work in progress), March
	2018.		2019.
	[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>.
			[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
			Flexible Authentication via Secure Tunneling Extensible
			Authentication Protocol Method (EAP-FAST)", RFC 4851,
			DOI 10.17487/RFC4851, May 2007,
			<https://www.rfc-editor.org/info/rfc4851>.
	[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS		[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
	Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,		Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
	March 2008, <https://www.rfc-editor.org/info/rfc5216>.		March 2008, <https://www.rfc-editor.org/info/rfc5216>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
			[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
			Protocol Tunneled Transport Layer Security Authenticated
			Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
			DOI 10.17487/RFC5281, August 2008,
			<https://www.rfc-editor.org/info/rfc5281>.
			[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
			"Tunnel Extensible Authentication Protocol (TEAP) Version
			1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
			<https://www.rfc-editor.org/info/rfc7170>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-tls-certificate-compression]		[I-D.ietf-tls-certificate-compression]
	Ghedini, A. and V. Vasiliev, "TLS Certificate		Ghedini, A. and V. Vasiliev, "TLS Certificate
	Compression", draft-ietf-tls-certificate-compression-04		Compression", draft-ietf-tls-certificate-compression-05
	(work in progress), October 2018.		(work in progress), April 2019.
			[I-D.thomson-tls-sic]
			Thomson, M., "Suppressing Intermediate Certificates in
			TLS", draft-thomson-tls-sic-00 (work in progress), March
			2019.
	[IEEE-802.1X]		[IEEE-802.1X]
	Institute of Electrical and Electronics Engineers, "IEEE		Institute of Electrical and Electronics Engineers, "IEEE
	Standard for Local and metropolitan area networks -- Port-		Standard for Local and metropolitan area networks -- Port-
	Based Network Access Control", IEEE Standard 802.1X-2010 ,		Based Network Access Control", IEEE Standard 802.1X-2010 ,
	February 2010.		February 2010.
	[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,
End of changes. 17 change blocks.
	27 lines changed or deleted		81 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/