< draft-ietf-kitten-tls-channel-bindings-for-tls13-12.txt		draft-ietf-kitten-tls-channel-bindings-for-tls13-13.txt >
	Transport Layer Security S. Whited		Transport Layer Security S. Whited
	Internet-Draft 25 October 2021		Internet-Draft 10 February 2022
	Updates: 5801, 5802, 5929, 7677, 8446 (if		Updates: 5801, 5802, 5929, 7677 (if approved)
	approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 28 April 2022		Expires: 14 August 2022
	Channel Bindings for TLS 1.3		Channel Bindings for TLS 1.3
	draft-ietf-kitten-tls-channel-bindings-for-tls13-12		draft-ietf-kitten-tls-channel-bindings-for-tls13-13
	Abstract		Abstract
	This document defines a channel binding type, tls-exporter, that is		This document defines a channel binding type, tls-exporter, that is
	compatible with TLS 1.3 in accordance with RFC 5056, On Channel		compatible with TLS 1.3 in accordance with RFC 5056, On Channel
	Binding. Furthermore it updates the "default" channel binding to the		Binding. Furthermore it updates the "default" channel binding to the
	new binding for versions of TLS greater than 1.2. This document		new binding for versions of TLS greater than 1.2. This document
	updates RFC5801, RFC5802, RFC5929, RFC7677, and RFC8446.		updates RFC5801, RFC5802, RFC5929, RFC7677, and RFC8446.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 35 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 28 April 2022.		This Internet-Draft will expire on 14 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2		1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
	2. The 'tls-exporter' Channel Binding Type . . . . . . . . . . . 3		2. The 'tls-exporter' Channel Binding Type . . . . . . . . . . . 3
	3. TLS 1.3 with SCRAM or GSS-API over SASL . . . . . . . . . . . 3		3. TLS 1.3 with SCRAM or GSS-API over SASL . . . . . . . . . . . 3
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 3		4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
	4.1. Use with Legacy TLS . . . . . . . . . . . . . . . . . . . 4		4.1. Uniqueness of Channel Bindings . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		4.2. Use with Legacy TLS . . . . . . . . . . . . . . . . . . . 5
	5.1. Registration of Channel Binding Type . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	5.2. Registration of Channel Binding TLS Exporter Label . . . 5		5.1. Registration of Channel Binding Type . . . . . . . . . . 5
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		5.2. Registration of Channel Binding TLS Exporter Label . . . 6
	6.1. Normative References . . . . . . . . . . . . . . . . . . 5		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.2. Informative References . . . . . . . . . . . . . . . . . 6		6.1. Normative References . . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6		6.2. Informative References . . . . . . . . . . . . . . . . . 7
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The "tls-unique" channel binding type defined in [RFC5929] was found		The "tls-unique" channel binding type defined in [RFC5929] was found
	to be vulnerable to the "triple handshake vulnerability"		to be vulnerable to the "triple handshake vulnerability"
	[TRIPLE-HANDSHAKE] without the extended master secret extension		[TRIPLE-HANDSHAKE] without the extended master secret extension
	defined in [RFC7627]. While TLS 1.3 uses a complete transcript hash		defined in [RFC7627]. While TLS 1.3 uses a complete transcript hash
	akin to the extended master secret procedures, the safety of channel		akin to the extended master secret procedures, the safety of channel
	bindings with TLS 1.3 was not analyzed as part of the core protocol		bindings with TLS 1.3 was not analyzed as part of the core protocol
	work, and so the specification of channel bindings for TLS 1.3 was		work, and so the specification of channel bindings for TLS 1.3 was
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 21 ¶
	exporters for TLS as defined in [RFC5705] and [RFC8446] section 7.5		exporters for TLS as defined in [RFC5705] and [RFC8446] section 7.5
	by supplying the following inputs:		by supplying the following inputs:
	Label: The ASCII string "EXPORTER-Channel-Binding" with no		Label: The ASCII string "EXPORTER-Channel-Binding" with no
	terminating NUL.		terminating NUL.
	Context value: Zero-length string.		Context value: Zero-length string.
	Length: 32 bytes.		Length: 32 bytes.
	This channel binding mechanism is defined only when TLS cipher		This channel binding mechanism is defined only when the TLS handshake
	negotiation results in unique master secrets, which is true of TLS		results in unique master secrets. This is true of TLS versions prior
	1.3 which always behaves as if it were using the extended master		to 1.3 when the extended master secret extension of [RFC7627] is in
	secret fix required by previous versions of TLS (see [RFC8446]		use, and is always true for TLS 1.3 (see [RFC8446] appendix D).
	appendix D).
	3. TLS 1.3 with SCRAM or GSS-API over SASL		3. TLS 1.3 with SCRAM or GSS-API over SASL
	SCRAM ([RFC5802], and [RFC7677]) and GSS-API over SASL [RFC5801]		SCRAM ([RFC5802], and [RFC7677]) and GSS-API over SASL [RFC5801]
	define "tls-unique" as the default channel binding to use over TLS.		define "tls-unique" as the default channel binding to use over TLS.
	As "tls-unique" is not defined for TLS 1.3 (and greater), this		As "tls-unique" is not defined for TLS 1.3 (and greater), this
	document updates [RFC5801], [RFC5802], and [RFC7677] to use "tls-		document updates [RFC5801], [RFC5802], and [RFC7677] to use "tls-
	exporter" as the default channel binding over TLS 1.3 (and greater).		exporter" as the default channel binding over TLS 1.3 (and greater).
	Note that this document does not change the default channel binding		Note that this document does not change the default channel binding
	for SCRAM mechanisms over TLS 1.2 [RFC5246], which is still "tls-		for SCRAM mechanisms over TLS 1.2 [RFC5246], which is still "tls-
	unique".		unique".
	4. Security Considerations		4. Security Considerations
	The channel binding type defined in this document is constructed so		The channel binding type defined in this document is constructed so
	that disclosure of the channel binding data does not leak secret		that disclosure of the channel binding data does not leak secret
	information about the TLS channel and does not affect the security of		information about the TLS channel and does not affect the security of
	the TLS channel.		the TLS channel.
			The derived data MUST NOT be used for any purpose other than channel
			bindings as described in [RFC5056]. In particular, implementations
			MUST NOT use channel binding as a secret key to protect privileged
			information.
	The Security Considerations sections of [RFC5056], [RFC5705], and		The Security Considerations sections of [RFC5056], [RFC5705], and
	[RFC8446] apply to this document.		[RFC8446] apply to this document.
	4.1. Use with Legacy TLS		4.1. Uniqueness of Channel Bindings
			The definition of channel bindings in [RFC5056] defines the concept
			of a "unique" channel binding as being one that is unique to the
			channel endpoints and unique over time, that is, a value that is
			unique to a specific instance of the lower layer security protocol.
			When TLS is the lower layer security protocol, as for the channel
			binding type defined in this document, this concept of uniqueness
			corresponds to uniquely identifying the specific TLS connection.
			However, a stronger form of uniqueness is possible, which would
			entail uniquely identifying not just the lower layer protocol but
			also the upper layer application or authenticaiton protocol that is
			consuming the channel binding. The distinction is relevant only when
			there are multiple instances of an authentication protocol, or
			multiple distinct authentication protocols, that run atop the same
			lower layer protocol. Such a situation is rare -- most consumers of
			channel bindings establish an instance of the lower layer secure
			protocol, run a single application or authentication protocol as the
			upper layer protocol, then terminate both upper and lower layer
			protocols. In this situation the stronger form of uniqueness is
			trivially achieved, given that the channel binding value is unique in
			the sense of [RFC5056].
			The channel binding type defined by this document provides only the
			weaker type of uniqueness, as per [RFC5056]; it does not achieve the
			stronger uniqueness per upper layer protocol instance described
			above. This stronger form of uniqueness would be useful in that it
			provides protection against cross-protocol attacks for the multiple
			authentication protocols running over the same lower layer protocol,
			and it provides protection against replay attacks that seek to replay
			a message from one instance of an authentication protocol in a
			different instance of the same authentication protocol, again running
			over the same lower layer protocol. Both of these properties are
			highly desirable when performing formal analysis of upper layer
			protocols; if these properties are not provided, such formal analysis
			is essentially impossible. In some cases one or both of these
			properties may already be provided by specific upper layer protocols,
			but that is dependent on the mechanism(s) in question, and formal
			analysis requires that the property is provided in a generic manner,
			across all potential upper layer protocols that exist or might exist
			in the future.
			Accordingly, applications that make use of the channel binding type
			defined in this document MUST NOT use the channel binding for more
			than one authentication mechanism instasnce on a given TLS
			connection. Such applications MUST immediately close the TLS
			connection after the conclusion of the upper layer protocol.
			4.2. Use with Legacy TLS
	While it is possible to use this channel binding mechanism with TLS		While it is possible to use this channel binding mechanism with TLS
	versions below 1.3, extra precaution must be taken to ensure that the		versions below 1.3, extra precaution must be taken to ensure that the
	chosen cipher suites always result in unique master secrets. For		chosen cipher suites always result in unique master secrets. For
	more information see [RFC7627] and the Security Considerations		more information see [RFC7627] and the Security Considerations
	section of [RFC5705].		section of [RFC5705] (TLS 1.3 always provides unique master secrets,
			as discussed in Appendix D of [RFC8446].)
	When TLS renegotiation is enabled on a connection the "tls-exporter"		When TLS renegotiation is enabled on a connection the "tls-exporter"
	channel binding type is not defined for that connection and		channel binding type is not defined for that connection and
	implementations MUST NOT support it.		implementations MUST NOT support it.
	In general, users wishing to take advantage of channel binding should		In general, users wishing to take advantage of channel binding should
	upgrade to TLS 1.3 or later.		upgrade to TLS 1.3 or later.
	The derived data MUST NOT be used for any purpose other than channel
	bindings as described in [RFC5056]. In particular, implementations
	MUST NOT use channel binding as a secret key to protect privileged
	information.
	5. IANA Considerations		5. IANA Considerations
	5.1. Registration of Channel Binding Type		5.1. Registration of Channel Binding Type
	This document adds the following registration in the "Channel-Binding		This document adds the following registration in the "Channel-Binding
	Types" registry:		Types" registry:
	Subject: Registration of channel binding tls-exporter		Subject: Registration of channel binding tls-exporter
	Channel binding unique prefix: tls-exporter		Channel binding unique prefix: tls-exporter
	Channel binding type: unique		Channel binding type: unique
	Channel type: TLS [RFC8446]		Channel type: TLS [RFC8446]
	Published specification: draft-ietf-kitten-tls-channel-bindings-for-		Published specification: draft-ietf-kitten-tls-channel-bindings-for-
	tls13-12		tls13-13
	Channel binding is secret: no		Channel binding is secret: no
	Description: The EKM value obtained from the current TLS connection.		Description: The EKM value obtained from the current TLS connection.
	Intended usage: COMMON		Intended usage: COMMON
	Person and email address to contact for further information: Sam		Person and email address to contact for further information: Sam
	Whited <sam@samwhited.com>.		Whited <sam@samwhited.com>.
	skipping to change at page 5, line 41 ¶		skipping to change at page 6, line 38 ¶
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure		[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
	Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,		Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
	<https://www.rfc-editor.org/info/rfc5056>.		<https://www.rfc-editor.org/info/rfc5056>.
	[RFC5705] Rescorla, E., "Keying Material Exporters for Transport		[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,		Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
	March 2010, <https://www.rfc-editor.org/info/rfc5705>.		March 2010, <https://www.rfc-editor.org/info/rfc5705>.
			[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
			Service Application Program Interface (GSS-API) Mechanisms
			in Simple Authentication and Security Layer (SASL): The
			GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801,
			July 2010, <https://www.rfc-editor.org/info/rfc5801>.
			[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
			"Salted Challenge Response Authentication Mechanism
			(SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
			DOI 10.17487/RFC5802, July 2010,
			<https://www.rfc-editor.org/info/rfc5802>.
			[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
			for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
			<https://www.rfc-editor.org/info/rfc5929>.
	[RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple		[RFC7677] Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
	Authentication and Security Layer (SASL) Mechanisms",		Authentication and Security Layer (SASL) Mechanisms",
	RFC 7677, DOI 10.17487/RFC7677, November 2015,		RFC 7677, DOI 10.17487/RFC7677, November 2015,
	<https://www.rfc-editor.org/info/rfc7677>.		<https://www.rfc-editor.org/info/rfc7677>.
	[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>.
	[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
	[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>.
	[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
	Service Application Program Interface (GSS-API) Mechanisms
	in Simple Authentication and Security Layer (SASL): The
	GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801,
	July 2010, <https://www.rfc-editor.org/info/rfc5801>.
	[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
	"Salted Challenge Response Authentication Mechanism
	(SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
	DOI 10.17487/RFC5802, July 2010,
	<https://www.rfc-editor.org/info/rfc5802>.
	[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
	for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
	<https://www.rfc-editor.org/info/rfc5929>.
	[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,		[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
	Langley, A., and M. Ray, "Transport Layer Security (TLS)		Langley, A., and M. Ray, "Transport Layer Security (TLS)
	Session Hash and Extended Master Secret Extension",		Session Hash and Extended Master Secret Extension",
	RFC 7627, DOI 10.17487/RFC7627, September 2015,		RFC 7627, DOI 10.17487/RFC7627, September 2015,
	<https://www.rfc-editor.org/info/rfc7627>.		<https://www.rfc-editor.org/info/rfc7627>.
	[TRIPLE-HANDSHAKE]		[TRIPLE-HANDSHAKE]
	Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,		Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
	A., and P. Strub, "Password Storage", March 2014,		A., and P. Strub, "Password Storage", March 2014,
	<https://www.mitls.org/pages/attacks/3SHAKE>.		<https://www.mitls.org/pages/attacks/3SHAKE>.
End of changes. 15 change blocks.
	47 lines changed or deleted		96 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/