< draft-ietf-emu-eaptlscert-03.txt		draft-ietf-emu-eaptlscert-04.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: November 10, 2020 S. Turner		Expires: December 10, 2020 S. Turner
	sn3rd		sn3rd
	May 9, 2020		June 8, 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-03		draft-ietf-emu-eaptlscert-04
	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 document looks at the this problem in detail and describes the		This document 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 November 10, 2020.		This Internet-Draft will expire on December 10, 2020.
	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 16 ¶		skipping to change at page 2, line 16 ¶
	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 . 5		4. Handling of Large Certificates and Long Certificate Chains . 5
	4.1. Updating Certificates and Certificate Chains . . . . . . 5		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.1.2. New Certificate Types and Compression Algorithms . . 6
	4.2.1. Pre-distributing and Omitting CA Certificates . . . . 6		4.2. Updating TLS and EAP-TLS Code . . . . . . . . . . . . . . 7
			4.2.1. Pre-distributing and Omitting CA certificates . . . . 7
	4.2.2. URLs for Client Certificates . . . . . . . . . . . . 7		4.2.2. URLs for Client Certificates . . . . . . . . . . . . 7
	4.2.3. Compact TLS 1.3 . . . . . . . . . . . . . . . . . . . 7		4.2.3. Compact TLS 1.3 . . . . . . . . . . . . . . . . . . . 7
	4.2.4. Caching Certificates . . . . . . . . . . . . . . . . 7		4.2.4. Caching Certificates . . . . . . . . . . . . . . . . 8
	4.2.5. Compressing Certificates . . . . . . . . . . . . . . 8		4.2.5. Compressing Certificates . . . . . . . . . . . . . . 8
	4.2.6. Suppressing Intermediate Certificates . . . . . . . . 8		4.2.6. Suppressing Intermediate Certificates . . . . . . . . 9
	4.2.7. Using Fewer Intermediate Certificates . . . . . . . . 8		4.2.7. Using Fewer Intermediate Certificates . . . . . . . . 9
	4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 9		4.3. Updating Authenticators . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . 11		7.2. Informative References . . . . . . . . . . . . . . . . . 11
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	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 Flexible		also many other TLS-based EAP methods, such as Flexible
	Authentication via Secure Tunneling (EAP-FAST) [RFC4851], Tunneled		Authentication via Secure Tunneling (EAP-FAST) [RFC4851], Tunneled
	Transport Layer Security (EAP-TTLS) [RFC5281], Tunnel Extensible		Transport Layer Security (EAP-TTLS) [RFC5281], Tunnel Extensible
	Authentication Protocol (EAP-TEAP) [RFC7170], and possibly many		Authentication Protocol (EAP-TEAP) [RFC7170], and possibly many
	vendor specific EAP methods.		vendor specific EAP methods.
	TLS certificates in EAP deployments can be relatively large, and the		Certificates in EAP deployments can be relatively large, and the
	certificate chains can be long. Unlike the use of TLS on the web,		certificate chains can be long. Unlike the use of TLS on the web,
	where typically only the TLS server is authenticated; EAP-TLS		where typically only the TLS server is authenticated; EAP-TLS
	deployments typically authenticates both the EAP peer and the EAP		deployments typically authenticates both the EAP peer and the EAP
	server. Also, from deployment experience, EAP peers typically have		server. Also, from deployment experience, EAP peers typically have
	longer certificate chains than servers. This is because EAP peers		longer certificate chains than servers. This is because EAP peers
	often follow organizational hierarchies and tend to have many		often follow organizational hierarchies and tend to have many
	intermediate certificates. Thus, EAP-TLS authentication usually		intermediate certificates. Thus, EAP-TLS authentication usually
	involve significantly more octets than when TLS is used as part of		involves significantly more octets than when TLS is used as part of
	HTTPS.		HTTPS.
	Section 3.1 of [RFC3748] states that EAP implementations can assume a		Section 3.1 of [RFC3748] states that EAP implementations can assume a
	MTU of at least 1020 octets from lower layers. The EAP fragment size		MTU of at least 1020 octets from lower layers. The EAP fragment size
	in typical deployments is just 1020 - 1500 octets (since the maximum		in typical deployments is just 1020 - 1500 octets (since the maximum
	Ethernet frame size is ~ 1500 bytes). Thus, EAP-TLS authentication		Ethernet frame size is ~ 1500 bytes). Thus, EAP-TLS authentication
	needs to be fragmented into many smaller packets for transportation		needs to be fragmented into many smaller packets for transportation
	over the lower layers. Such fragmentation can not only negatively		over the lower layers. Such fragmentation can not only negatively
	affect the latency, but also results in other challenges. For		affect the latency, but also results in other challenges. For
	example, some EAP authenticator (access point) implementations will		example, some EAP authenticator (access point) implementations will
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 41 ¶
	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 round-trips. 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		The general guideline of keeping the certificate size small by not
	EAP-TLS authentication:		populating fields with excessive information can help avert the
			problems of failed EAP-TLS authentication. More specific
			recommendations for certificates used with EAP-TLS is as follows:
	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 octet 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
	octets. OIDs are used lavishly in X.509 certificates and while		octets. OIDs are used lavishly in X.509 certificates and while
	not all can be avoided, e.g., OIDs for extensions or algorithms		not all can be avoided, e.g., OIDs for extensions or algorithms
	and their associate parameters, some are well within the		and their associate parameters, some are well within the
	certificate issuer's control:		certificate issuer's control:
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 45 ¶
	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		o As stated earlier, certificate chains of the EAP peer often follow
	organizational hierarchies. In such cases, information in		organizational hierarchies. In such cases, information in
	intermediate certificates (such as postal addresses) do not		intermediate certificates (such as postal addresses) do not
	provide any additional value and they can be shortened (for		provide any additional value and they can be shortened (for
	example: only including the department name instead of the full		example: only including the department name instead of the full
	postal address).		postal address).
			4.1.2. New Certificate Types and Compression Algorithms
			There is ongoing work to specify new certificate types and
			compression algorithms. For example,
			[I-D.mattsson-tls-cbor-cert-compress] defines a compression algorithm
			for certificates that relies on Concise Binary Object Representation
			(CBOR) [RFC7049]. [I-D.tschofenig-tls-cwt] registers a new TLS
			Certificate type which would enable TLS implementations to use CBOR
			Web Tokens (CWTs) [RFC8392] as certificates. While these are early
			initiatives, future EAP-TLS deployments can consider the use of these
			new certificate types and compression algorithms to avoid large
			message sizes.
	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 size of the		certificate chain. TLS allows endpoints to reduce the size of the
	Certificate message by omitting certificates that the other endpoint		Certificate message 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,
	only the self-signed certificate that specifies the root certificate		only the self-signed certificate that specifies the root certificate
	authority may be omitted (see Section 7.4.2 of [RFC5246] Therefore,		authority may be omitted (see Section 7.4.2 of [RFC5246] Therefore,
	updating TLS implementations to version 1.3 can help to significantly		updating TLS implementations to version 1.3 can help to significantly
	skipping to change at page 8, line 45 ¶		skipping to change at page 9, line 21 ¶
	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.7. Using Fewer Intermediate Certificates		4.2.7. Using Fewer Intermediate Certificates
	The EAP peer certificate chain does not have to mirror the		The EAP peer certificate chain does not have to mirror the
	organizational hierarchy. For successful EAP-TLS authentication,		organizational hierarchy. For successful EAP-TLS authentication,
	certificate chains should not contain more than 2-4 intermediate		certificate chains SHOULD NOT contain more than 2-4 intermediate
	certificates.		certificates.
	Administrators responsible for deployments using TLS-based EAP		Administrators responsible for deployments using TLS-based EAP
	methods can examine the certificate chains and make rough		methods can examine the certificate chains and make rough
	calculations about the number of round trips required for successful		calculations about the number of round trips required for successful
	authentication. For example, dividing the total size of all the		authentication. For example, dividing the total size of all the
	certificates in the peer and server certificate chain by 1020 will		certificates in the peer and server certificate chain by 1020 will
	indicate the minimum number of round trips required. If this number		indicate the minimum number of round trips required. If this number
	exceeds 50, then, administrators can expect failures with many common		exceeds 50, then, administrators can expect failures with many common
	authenticator implementations.		authenticator implementations.
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 28 ¶
	When compressing certificates, the underlying compression algorithm		When compressing certificates, the underlying compression algorithm
	MUST output the same data that was provided as input by. After		MUST output the same data that was provided as input by. After
	decompression, the Certificate message MUST be processed as if it		decompression, the Certificate message MUST be processed as if it
	were encoded without being compressed. Additional security		were encoded without being compressed. Additional security
	considerations when compressing certificates are specified in		considerations when compressing certificates are specified in
	[I-D.ietf-tls-certificate-compression]		[I-D.ietf-tls-certificate-compression]
	As noted in [I-D.thomson-tls-sic], suppressing intermediate		As noted in [I-D.thomson-tls-sic], suppressing intermediate
	certificates creates an unencrypted signal that might be used to		certificates creates an unencrypted signal that might be used to
	identify which clients believe that they have all intermediates.		identify which clients believe that they have all intermediates.
	This might also allow more effective fingerprinting and tracking of		This might also allow more effective fingerprinting and tracking of
	clients.		clients.
	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-09 (work in progress), March		draft-ietf-emu-eap-tls13-10 (work in progress), June 2020.
	2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, Ed., "Extensible Authentication Protocol		Levkowetz, Ed., "Extensible Authentication Protocol
	(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,		(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
	<https://www.rfc-editor.org/info/rfc3748>.		<https://www.rfc-editor.org/info/rfc3748>.
	skipping to change at page 11, line 21 ¶		skipping to change at page 11, line 48 ¶
	[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-10		Compression", draft-ietf-tls-certificate-compression-10
	(work in progress), January 2020.		(work in progress), January 2020.
	[I-D.ietf-tls-ctls]		[I-D.ietf-tls-ctls]
	Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS		Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
	1.3", draft-ietf-tls-ctls-00 (work in progress), April		1.3", draft-ietf-tls-ctls-00 (work in progress), April
	2020.		2020.
			[I-D.mattsson-tls-cbor-cert-compress]
			Mattsson, J., Selander, G., Raza, S., Hoglund, J., and M.
			Furuhed, "CBOR Certificate Algorithm for TLS Certificate
			Compression", draft-mattsson-tls-cbor-cert-compress-00
			(work in progress), March 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.
			[I-D.tschofenig-tls-cwt]
			Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
			(CWTs) in Transport Layer Security (TLS) and Datagram
			Transport Layer Security (DTLS)", draft-tschofenig-tls-
			cwt-01 (work in progress), November 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,		[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
	"Remote Authentication Dial In User Service (RADIUS)",		"Remote Authentication Dial In User Service (RADIUS)",
	RFC 2865, DOI 10.17487/RFC2865, June 2000,		RFC 2865, DOI 10.17487/RFC2865, June 2000,
	<https://www.rfc-editor.org/info/rfc2865>.		<https://www.rfc-editor.org/info/rfc2865>.
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 47 ¶
	[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)		[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
	Extensions: Extension Definitions", RFC 6066,		Extensions: Extension Definitions", RFC 6066,
	DOI 10.17487/RFC6066, January 2011,		DOI 10.17487/RFC6066, January 2011,
	<https://www.rfc-editor.org/info/rfc6066>.		<https://www.rfc-editor.org/info/rfc6066>.
	[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic		[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
	Curve Cryptography Algorithms", RFC 6090,		Curve Cryptography Algorithms", RFC 6090,
	DOI 10.17487/RFC6090, February 2011,		DOI 10.17487/RFC6090, February 2011,
	<https://www.rfc-editor.org/info/rfc6090>.		<https://www.rfc-editor.org/info/rfc6090>.
			[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
			Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
			October 2013, <https://www.rfc-editor.org/info/rfc7049>.
	[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>.
	[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital		[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
	Signature Algorithm (EdDSA)", RFC 8032,		Signature Algorithm (EdDSA)", RFC 8032,
	DOI 10.17487/RFC8032, January 2017,		DOI 10.17487/RFC8032, January 2017,
	<https://www.rfc-editor.org/info/rfc8032>.		<https://www.rfc-editor.org/info/rfc8032>.
			[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
			"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
			May 2018, <https://www.rfc-editor.org/info/rfc8392>.
	[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>.
	Acknowledgements		Acknowledgements
	This draft is a result of several useful discussions with Alan DeKok,		This draft is a result of several useful discussions with Alan DeKok,
	Bernard Aboba, Jari Arkko, Jouni Malinen, Darshak Thakore, and Hannes		Bernard Aboba, Jari Arkko, Jouni Malinen, Darshak Thakore, and Hannes
	Tschofening.		Tschofening.
End of changes. 22 change blocks.
	24 lines changed or deleted		58 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/