< draft-ietf-emu-eaptlscert-00.txt		draft-ietf-emu-eaptlscert-01.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: February 14, 2020 S. Turner		Expires: September 6, 2020 S. Turner
	sn3rd		sn3rd
	August 13, 2019		March 5, 2020
	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-ietf-emu-eaptlscert-00		draft-ietf-emu-eaptlscert-01
	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 round-trips 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.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 February 14, 2020.		This Internet-Draft will expire on September 6, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	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 . . . . . . . . . . . . . . . . . 4		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 . . . . . . 5
	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 . . . . . . . . . . . . . . . . 7
	4.2.3. Compressing Certificates . . . . . . . . . . . . . . 7		4.2.3. Compressing Certificates . . . . . . . . . . . . . . 7
	4.2.4. Suppressing Intermediate Certificates . . . . . . . . 7		4.2.4. Suppressing Intermediate Certificates . . . . . . . . 8
	4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 7		4.2.5. Using Fewer Intermediate Certificates . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . 9
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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. There are		deployed and often used for network access authentication. There are
	also many other TLS-based EAP methods, such as FAST [RFC4851], TTLS		also many other TLS-based EAP methods, such as FAST [RFC4851], TTLS
	[RFC5281], TEAP [RFC7170], and possibly many vendor specific EAP		[RFC5281], TEAP [RFC7170], and possibly many vendor specific EAP
	methods.		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. This is because EAP peers often
	usually involve significantly more bytes than when TLS is used as		follow organizational hierarchies and tend to have many intermediate
	part of HTTPS.		certificates. Thus, EAP-TLS authentication usually involve
			significantly more octets than when TLS is used as part of HTTPS.
	As the EAP fragment size in typical deployments are just 1000 - 1500		Section 3.1 of [RFC3748] states that EAP implementations can assume a
	bytes, the EAP-TLS authentication needs to be fragmented into many		MTU of at least 1020 octets from lower layers. The EAP fragment size
	smaller packets for transportation over the lower layers. Such		in typical deployments is just 1020 - 1500 octets. Thus, EAP-TLS
	fragmentation can not only negatively affect the latency, but also		authentication needs to be fragmented into many smaller packets for
	results in other challenges. For example, many EAP authenticator		transportation over the lower layers. Such fragmentation can not
	(access point) implementations will drop an EAP session if it hasn't		only negatively affect the latency, but also results in other
	finished after 40 - 50 round-trips. This is a major problem and		challenges. For example, many EAP authenticator (access point)
	means that in many situations, the EAP peer cannot perform network		implementations will drop an EAP session if it has not finished after
	access authentication even though both the sides have valid		40 - 50 round-trips. This is a major problem and means that in many
	credentials for successful authentication and key derivation.		situations, the EAP peer cannot perform network access authentication
			even though both the sides have valid credentials for successful
			authentication and key derivation.
			Not all EAP deployments are constrained by the MTU of the lower
			layer. For example, some implementations support EAP over Ethernet
			"Jumbo" frames that can easily allow very large EAP packets. Larger
			packets will naturally help lower the number of round trips required
			for successful EAP-TLS authentication. However, deployment
			experience has shown that these jumbo frames are not always
			implemented correctly. Additionally, EAP fragment size is also
			restricted by protocols such as RADIUS [RFC2865] which are
			responsible for transporting EAP messages between an authenticator
			and an EAP server. RADIUS can generally transport only about 4000
			octets of EAP in a single message.
	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
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Readers are expected to be familiar with the terms and concepts used		Readers are expected to be familiar with the terms and concepts used
	in EAP-TLS [RFC5216] and TLS [RFC8446]. In particular, this document		in EAP [RFC3748], EAP-TLS [RFC5216], and TLS [RFC8446]. In
	frequently uses the following terms as they have been defined in		particular, this document frequently uses the following terms as they
	[RFC5216]:		have been defined in [RFC5216]:
	Authenticator The entity initiating EAP authentication. Typically		Authenticator The entity initiating EAP authentication. Typically
	implemented as part of a network switch or a wireless access		implemented as part of a network switch or a wireless access
	point.		point.
	EAP peer The entity that responds to the authenticator. In		EAP peer The entity that responds to the authenticator. In
	[IEEE-802.1X], this entity is known as the supplicant. In EAP-		[IEEE-802.1X], this entity is known as the supplicant. In EAP-
	TLS, the EAP peer implements the TLS client role.		TLS, the EAP peer implements the TLS client role.
	EAP server The entity that terminates the EAP authentication method		EAP server The entity that terminates the EAP authentication method
	with the peer. In the case where no backend authentication		with the peer. In the case where no backend authentication
	server is used, the EAP server is part of the authenticator.		server is used, the EAP server is part of the authenticator.
	In the case where the authenticator operates in pass-through		In the case where the authenticator operates in pass-through
	mode, the EAP server is located on the backend authentication		mode, the EAP server is located on the backend authentication
	server. In EAP-TLS, the EAP server implements the TLS server		server. In EAP-TLS, the EAP server implements the TLS server
	role.		role.
	3. Experience with Deployments		3. Experience with Deployments
	The EAP fragment size in typical deployments can be 1000 - 1500		As stated earlier, the EAP fragment size in typical deployments is
	bytes. Certificate sizes can be large for a number of reasons:		just 1020 - 1500 octets. Certificate sizes can however be large for
			a number of reasons:
	o Long Subject Alternative Name field.		o Long Subject Alternative Name field.
	o Long Public Key and Signature fields.		o Long Public Key and Signature fields.
	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 as noted in Section 5.3 of
	certain OID's in the certificates for EAP-TLS to work.		[RFC5216]. Most implementations verify the presence of these OIDs
			for successful authentication.
	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 do
	complete within 50 round-trips. This means that if the chain is		not 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 certificate chains that are
	used for EAP-TLS authentication without requiring changes to the		used for EAP-TLS authentication without requiring changes to the
	existing EAP-TLS code base. We also provide some guidelines when		existing EAP-TLS code base. We also provide some guidelines when
	issuing certificates for use with EAP-TLS. In Section 4.2 we look at		issuing certificates for use with EAP-TLS. In Section 4.2 we look at
	recommendations that rely on updates to the EAP-TLS implementations		recommendations that rely on updates to the EAP-TLS implementations
	which can be deployed with existing certificates. In Section 4.3 we		which can be deployed with existing certificates. In Section 4.3 we
	shortly discuss the solution to update or reconfigure authenticator		shortly discuss the solution to update or reconfigure authenticator
	which can be deployed without changes to existing certificates or		which can be deployed without changes to existing certificates or
	EAP-TLS code.		EAP-TLS code.
	4.1. Updating Certificates and Certificate Chains		4.1. Updating Certificates and Certificate Chains
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 39 ¶
	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:
	o Object Identifiers (OIDs) is ASN.1 data type that defines unique		o Object Identifiers (OIDs) is ASN.1 data type that defines unique
	identifiers for objects. The OID's ASN.1 value, which is a string		identifiers for objects. The OID's ASN.1 value, which is a string
	of integers, is then used to name objects to which they relate.		of integers, is then used to name objects to which they relate.
	The DER length for the 1st two integers is always one byte and		The DER length for the 1st two integers is always one octet and
	subsequent integers are base 128-encoded in the fewest possible		subsequent integers are base 128-encoded in the fewest possible
	bytes. OIDs are used lavishly in X.509 certificates and while not		octets. OIDs are used lavishly in X.509 certificates and while
	all can be avoided, e.g., OIDs for extensions or algorithms and		not all can be avoided, e.g., OIDs for extensions or algorithms
	their associate parameters, some are well within the certificate		and their associate parameters, some are well within the
	issuer's control:		certificate issuer's control:
	* Each naming attribute in a DN (Directory Name) has one. DNs		* Each naming attribute in a DN (Directory Name) has one. DNs
	used in the issuer and subject fields as well as numerous		used in the issuer and subject fields as well as numerous
	extensions. A shallower naming will be smaller, e.g., C=FI,		extensions. A shallower naming will be smaller, e.g., C=FI,
	O=Example, SN=B0A123499EFC vs C=FI, O=Example, OU=Division 1,		O=Example, SN=B0A123499EFC vs C=FI, O=Example, OU=Division 1,
	SOPN=Southern Finland, CN=Coolest IoT Gadget Ever,		SOPN=Southern Finland, CN=Coolest IoT Gadget Ever,
	SN=B0A123499EFC.		SN=B0A123499EFC.
	* Every certificate policy (and qualifier) and any mappings to		* Every certificate policy (and qualifier) and any mappings to
	another policy uses identifiers. Consider carefully what		another policy uses identifiers. Consider carefully what
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 26 ¶
	non-ASCII character strings in the DN, characters can be multi-		non-ASCII character strings in the DN, characters can be multi-
	byte. Obviously, the names need to be unique, but there is more		byte. Obviously, the names need to be unique, but there is more
	than one way to accomplish this without long strings. This is		than one way to accomplish this without long strings. This is
	especially true if the names are not meant to be meaningful to		especially true if the names are not meant to be meaningful to
	users.		users.
	o Extensions are necessary to comply with [RFC5280], but the vast		o Extensions are necessary to comply with [RFC5280], but the vast
	majority are optional. Include only those that are necessary to		majority are optional. Include only those that are necessary to
	operate.		operate.
			o As stated earlier, certificate chains of the EAP peer often follow
			organizational hierarchies. In such cases, information in
			intermediate certificates (such as postal addresses) do not
			provide any additional value and they can be shortened (for
			example: only including the department name instead of the full
			postal address).
	4.2. Updating TLS and EAP-TLS Code		4.2. Updating TLS and EAP-TLS Code
	4.2.1. Pre-distributing and Omitting CA Certificates		4.2.1. Pre-distributing and Omitting CA Certificates
	The TLS Certificate message conveys the sending endpoint's		The TLS Certificate message conveys the sending endpoint's
	certificate chain. TLS allows endpoints to reduce the sizes of the		certificate chain. TLS allows endpoints to reduce the sizes of the
	Certificate messages by omitting certificates that the other endpoint		Certificate messages by omitting certificates that the other endpoint
	is known to possess. When using TLS 1.3, all certificates that		is known to possess. When using TLS 1.3, all certificates that
	specify a trust anchor known by the other endpoint may be omitted		specify a trust anchor known by the other endpoint may be omitted
	(see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier,		(see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier,
	skipping to change at page 7, line 34 ¶		skipping to change at page 8, line 17 ¶
	For a client that has all intermediates, having the server send		For a client that has all intermediates, having the server send
	intermediates in the TLS handshake increases the size of the		intermediates in the TLS handshake increases the size of the
	handshake unnecessarily. The TLS working group is working on an		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		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		that has access to the complete set of published intermediate
	certificates to inform servers of this fact so that the server can		certificates to inform servers of this fact so that the server can
	avoid sending intermediates, reducing the size of the TLS handshake.		avoid sending intermediates, reducing the size of the TLS handshake.
	The mechanism is intended to be complementary with certificate		The mechanism is intended to be complementary with certificate
	compression.		compression.
			4.2.5. Using Fewer Intermediate Certificates
			The EAP peer certificate chain does not have to mirror the
			organizational hierarchy. For successful EAP-TLS authentication,
			certificate chains should not contain more than 2-4 intermediate
			certificates.
			Administrators responsible for deployments using TLS-based EAP
			methods can examine the certificate chains and make rough
			calculations about the number of round trips required for successful
			authentication. For example, dividing the total size of all the
			certificates in the peer and server certificate chain by 1020 will
			indicate the minimum number of round trips required. If this number
			exceeds 50, then, administrators can expect failures with many common
			authenticator implementations.
	4.3. Updating Authenticators		4.3. Updating Authenticators
	There are several legitimate reasons that Authenticators may want to		There are several legitimate reasons that authenticators may want to
	limit the number of round-trips/packets/bytes that can be sent. The		limit the number of round-trips/packets/octets that can be sent. The
	main reason has been to work around issues where the EAP peer and EAP		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		server end up in an infinite loop ACKing their messages. Another
	second reason is that unlimited communication from an unauthenticated		second reason is that unlimited communication from an unauthenticated
	device as EAP could otherwise be use for bulk data transfer. A third		device as EAP could otherwise be use for bulk data transfer. A third
	reason is to prevent denial-of-service attacks.		reason is to prevent denial-of-service attacks.
	Updating the millions of already deployed access points and switches		Updating the millions of already deployed access points and switches
	is in many cases not realistic. Vendors may be out of business or do		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		no longer support the products and administrators may have lost the
	information to the devices. For practical purposes the EAP		login information to the devices. For practical purposes the EAP
	infrastructure is ossified for the time being.		infrastructure is ossified for the time being.
	Vendors making new authenticators should consider increasing the		Vendors making new authenticators should consider increasing the
	number of round-trips allowed before denying the EAP authentication		number of round-trips allowed to 100 before denying the EAP
	to complete.		authentication to complete. At the same time, administrators
			responsible for EAP deployments should ensure that this 100 roundtrip
			limit is not exceeded in practice.
	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		Updating implementations to TLS version 1.3 allows omitting all
			certificates with a trust anchor known by the other endpoint. TLS
			1.3 additionally provides improved security, privacy, and reduced
			latency for EAP-TLS [I-D.ietf-emu-eap-tls13].
			When compressing certificates, the underlying compression algorithm
			MUST output the same data that was provided as input by. After
			decompression, the Certificate message MUST be processed as if it
			were encoded without being compressed. Additional security
			considerations when compressing certificates are specified in
			[I-D.ietf-tls-certificate-compression]
			As noted in [I-D.thomson-tls-sic], suppressing intermediate
			certificates creates an unencrypted signal that might be used to
			identify which clients believe that they have all intermediates.
			This might also allow more effective fingerprinting and tracking of
			client.
	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-06 (work in progress), August		draft-ietf-emu-eap-tls13-08 (work in progress), December
	2019.		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,
	skipping to change at page 9, line 24 ¶		skipping to change at page 10, line 40 ¶
	<https://www.rfc-editor.org/info/rfc7170>.		<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-05		Compression", draft-ietf-tls-certificate-compression-10
	(work in progress), April 2019.		(work in progress), January 2020.
	[I-D.thomson-tls-sic]		[I-D.thomson-tls-sic]
	Thomson, M., "Suppressing Intermediate Certificates in		Thomson, M., "Suppressing Intermediate Certificates in
	TLS", draft-thomson-tls-sic-00 (work in progress), March		TLS", draft-thomson-tls-sic-00 (work in progress), March
	2019.		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.
			[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
			"Remote Authentication Dial In User Service (RADIUS)",
			RFC 2865, DOI 10.17487/RFC2865, June 2000,
			<https://www.rfc-editor.org/info/rfc2865>.
	[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>.
	[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-		[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
	256/384 and AES Galois Counter Mode (GCM)", RFC 5289,		256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
	DOI 10.17487/RFC5289, August 2008,		DOI 10.17487/RFC5289, August 2008,
	<https://www.rfc-editor.org/info/rfc5289>.		<https://www.rfc-editor.org/info/rfc5289>.
End of changes. 26 change blocks.
	54 lines changed or deleted		118 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/