< draft-ietf-tls-external-psk-guidance-04.txt		draft-ietf-tls-external-psk-guidance-05.txt >
	tls R. Housley		tls R. Housley
	Internet-Draft Vigil Security		Internet-Draft Vigil Security
	Intended status: Informational J. Hoyland		Intended status: Informational J. Hoyland
	Expires: 12 June 2022 Cloudflare Ltd.		Expires: 15 July 2022 Cloudflare Ltd.
	M. Sethi		M. Sethi
	Ericsson		Ericsson
	C.A. Wood		C.A. Wood
	Cloudflare		Cloudflare
	9 December 2021		11 January 2022
	Guidance for External PSK Usage in TLS		Guidance for External PSK Usage in TLS
	draft-ietf-tls-external-psk-guidance-04		draft-ietf-tls-external-psk-guidance-05
	Abstract		Abstract
	This document provides usage guidance for external Pre-Shared Keys		This document provides usage guidance for external Pre-Shared Keys
	(PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.		(PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
	This document lists TLS security properties provided by PSKs under		It lists TLS security properties provided by PSKs under certain
	certain assumptions, and then demonstrates how violations of these		assumptions, and then demonstrates how violations of these
	assumptions lead to attacks. This document discusses PSK use cases		assumptions lead to attacks. Advice for applications to help meet
	and provisioning processes. This document provides advice for		these assumptions is provided. It also discusses PSK use cases and
	applications to help meet these assumptions. This document also		provisioning processes. Finally, it lists the privacy and security
	lists the privacy and security properties that are not provided by		properties that are not provided by TLS 1.3 when external PSKs are
	TLS 1.3 when external PSKs are used.		used.
	Discussion Venues		Discussion Venues
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Source for this draft and an issue tracker can be found at		Source for this draft and an issue tracker can be found at
	https://github.com/tlswg/external-psk-design-team.		https://github.com/tlswg/external-psk-design-team.
	Status of This Memo		Status of This Memo
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 12 June 2022.		This Internet-Draft will expire on 15 July 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 Revised BSD License text as		extracted from this document must include Revised BSD License text 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 Revised BSD License.		provided without warranty as described in the Revised BSD License.
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 9 ¶
	presence that other parties can interact with via the TLS protocol.		presence that other parties can interact with via the TLS protocol.
	A logical node could potentially be realized with multiple physical		A logical node could potentially be realized with multiple physical
	instances operating under common administrative control, e.g., a		instances operating under common administrative control, e.g., a
	server farm. An "endpoint" is a client or server participating in a		server farm. An "endpoint" is a client or server participating in a
	connection.		connection.
	4. PSK Security Properties		4. PSK Security Properties
	The use of a previously established PSK allows TLS nodes to		The use of a previously established PSK allows TLS nodes to
	authenticate the endpoint identities. It also offers other benefits,		authenticate the endpoint identities. It also offers other benefits,
	including resistance to attacks in presence of quantum computes; see		including resistance to attacks in presence of quantum computers; see
	Section 4.2 for related discussion. However, these keys do not		Section 4.2 for related discussion. However, these keys do not
	provide privacy protection of endpoint identities, nor do they		provide privacy protection of endpoint identities, nor do they
	provide non-repudiation (one endpoint in a connection can deny the		provide non-repudiation (one endpoint in a connection can deny the
	conversation); see Section 7 for related discussion.		conversation); see Section 7 for related discussion.
	PSK authentication security implicitly assumes one fundamental		PSK authentication security implicitly assumes one fundamental
	property: each PSK is known to exactly one client and one server, and		property: each PSK is known to exactly one client and one server, and
	that these never switch roles. If this assumption is violated, then		that these never switch roles. If this assumption is violated, then
	the security properties of TLS are severely weakened as discussed		the security properties of TLS are severely weakened as discussed
	below.		below.
	skipping to change at page 4, line 39 ¶		skipping to change at page 4, line 39 ¶
	1. Any group member can impersonate any other group member.		1. Any group member can impersonate any other group member.
	2. If PSK is combined with a fresh ephemeral key exchange, then		2. If PSK is combined with a fresh ephemeral key exchange, then
	compromise of a group member that knows the resulting shared		compromise of a group member that knows the resulting shared
	secret will enable the attacker to passively read (and actively		secret will enable the attacker to passively read (and actively
	modify) traffic.		modify) traffic.
	3. If PSK is not combined with fresh ephemeral key exchange, then		3. If PSK is not combined with fresh ephemeral key exchange, then
	compromise of any group member allows the attacker to passively		compromise of any group member allows the attacker to passively
	read (and actively modify) all traffic.		read (and actively modify) all traffic, including past traffic.
	Additionally, a malicious non-member can reroute handshakes between		Additionally, a malicious non-member can reroute handshakes between
	honest group members to connect them in unintended ways, as described		honest group members to connect them in unintended ways, as described
	below. Note that a partial mitigiation against this class of attack		below. Note that a partial mitigiation against this class of attack
	is available: each group member includes the SNI extension [RFC6066]		is available: each group member includes the SNI extension [RFC6066]
	and terminates the connection on mismatch between the presented SNI		and terminates the connection on mismatch between the presented SNI
	value and the receiving member's known identity. See [Selfie] for		value and the receiving member's known identity. See [Selfie] for
	details.		details.
	To illustrate the rerouting attack, consider the group of peers who		To illustrate the rerouting attack, consider three peers, A, B, and
	know the PSK be A, B, and C. The attack proceeds as follows:		C, who all know the PSK. The attack proceeds as follows:
	1. A sends a ClientHello to B.		1. A sends a ClientHello to B.
	2. The attacker intercepts the message and redirects it to C.		2. The attacker intercepts the message and redirects it to C.
	3. C responds with a second flight (ServerHello, ...) to A.		3. C responds with a second flight (ServerHello, ...) to A.
	4. A sends a Finished message to B. A has completed the handshake,		4. A sends a Finished message to B. A has completed the handshake,
	ostensibly with B.		ostensibly with B.
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 34 ¶
	Finally, in addition to these weaknesses, sharing a PSK across nodes		Finally, in addition to these weaknesses, sharing a PSK across nodes
	may negatively affect deployments. For example, revocation of		may negatively affect deployments. For example, revocation of
	individual group members is not possible without establishing a new		individual group members is not possible without establishing a new
	PSK for all of the non-revoked members.		PSK for all of the non-revoked members.
	4.2. PSK Entropy		4.2. PSK Entropy
	Entropy properties of external PSKs may also affect TLS security		Entropy properties of external PSKs may also affect TLS security
	properties. For example, if a high entropy PSK is used, then PSK-		properties. For example, if a high entropy PSK is used, then PSK-
	only key establishment modes provide expected security properties for		only key establishment modes provide expected security properties for
	TLS, including, for example, including establishing the same session		TLS, including establishing the same session keys between peers,
	keys between peers, secrecy of session keys, peer authentication, and		secrecy of session keys, peer authentication, and downgrade
	downgrade protection. See [RFC8446], Appendix E.1 for an explanation		protection. See [RFC8446], Appendix E.1 for an explanation of these
	of these properties. However, these modes lack forward security.		properties. However, these modes lack forward security. Forward
	Forward security may be achieved by using a PSK-DH mode, or,		security may be achieved by using a PSK-DH mode, or, alternatively,
	alternatively, by using PSKs with short lifetimes.		by using PSKs with short lifetimes.
	In contrast, if a low entropy PSK is used, then PSK-only key		In contrast, if a low entropy PSK is used, then PSK-only key
	establishment modes are subject to passive exhaustive search attacks		establishment modes are subject to passive exhaustive search attacks
	which will reveal the traffic keys. PSK-DH modes are subject to		which will reveal the traffic keys. PSK-DH modes are subject to
	active attacks in which the attacker impersonates one side. The		active attacks in which the attacker impersonates one side. The
	exhaustive search phase of these attacks can be mounted offline if		exhaustive search phase of these attacks can be mounted offline if
	the attacker captures a single handshake using the PSK, but those		the attacker captures a single handshake using the PSK, but those
	attacks will not lead to compromise of the traffic keys for that		attacks will not lead to compromise of the traffic keys for that
	connection because those also depend on the Diffie-Hellman (DH)		connection because those also depend on the Diffie-Hellman (DH)
	exchange. Low entropy keys are only secure against active attack if		exchange. Low entropy keys are only secure against active attack if
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 33 ¶
	an integral part of the TLS version 1.3 specification [RFC8446]. TLS		an integral part of the TLS version 1.3 specification [RFC8446]. TLS
	1.3 also uses PSKs for session resumption. It distinguishes these		1.3 also uses PSKs for session resumption. It distinguishes these
	resumption PSKs from external PSKs which have been provisioned out-		resumption PSKs from external PSKs which have been provisioned out-
	of-band. This section describes known use cases and provisioning		of-band. This section describes known use cases and provisioning
	processes for external PSKs with TLS.		processes for external PSKs with TLS.
	5.1. Use Cases		5.1. Use Cases
	This section lists some example use-cases where pair-wise external		This section lists some example use-cases where pair-wise external
	PSKs, i.e., external PSKs that are shared between only one server and		PSKs, i.e., external PSKs that are shared between only one server and
	one client, have been used for authentication in TLS.		one client, have been used for authentication in TLS. There was no
			attempt to prioritize the examples in any particular order.
	* Device-to-device communication with out-of-band synchronized keys.		* Device-to-device communication with out-of-band synchronized keys.
	PSKs provisioned out-of-band for communicating with known		PSKs provisioned out-of-band for communicating with known
	identities, wherein the identity to use is discovered via a		identities, wherein the identity to use is discovered via a
	different online protocol.		different online protocol.
	* Intra-data-center communication. Machine-to-machine communication		* Intra-data-center communication. Machine-to-machine communication
	within a single data center or PoP may use externally provisioned		within a single data center or point-of-presence (PoP) may use
	PSKs, primarily for the purposes of supporting TLS connections		externally provisioned PSKs, primarily for the purposes of
	with early data; see Section 8 for considerations when using early		supporting TLS connections with early data; see Section 8 for
	data with external PSKs.		considerations when using early data with external PSKs.
	* Certificateless server-to-server communication. Machine-to-		* Certificateless server-to-server communication. Machine-to-
	machine communication may use externally provisioned PSKs,		machine communication may use externally provisioned PSKs,
	primarily for the purposes of establishing TLS connections without		primarily for the purposes of establishing TLS connections without
	requiring the overhead of provisioning and managing PKI		requiring the overhead of provisioning and managing PKI
	certificates.		certificates.
	* Internet of Things (IoT) and devices with limited computational		* Internet of Things (IoT) and devices with limited computational
	capabilities. [RFC7925] defines TLS and DTLS profiles for		capabilities. [RFC7925] defines TLS and DTLS profiles for
	resource-constrained devices and suggests the use of PSK		resource-constrained devices and suggests the use of PSK
	skipping to change at page 7, line 49 ¶		skipping to change at page 7, line 49 ¶
	use-case. For example, in a given setting, IoT devices may all		use-case. For example, in a given setting, IoT devices may all
	share the same PSK and use it to communicate with a central server		share the same PSK and use it to communicate with a central server
	(one key for n devices), have their own key for communicating with		(one key for n devices), have their own key for communicating with
	a central server (n keys for n devices), or have pairwise keys for		a central server (n keys for n devices), or have pairwise keys for
	communicating with each other (n^2 keys for n devices).		communicating with each other (n^2 keys for n devices).
	5.2. Provisioning Examples		5.2. Provisioning Examples
	The exact provisioning process depends on the system requirements and		The exact provisioning process depends on the system requirements and
	threat model. Whenever possible, avoid sharing a PSK between nodes;		threat model. Whenever possible, avoid sharing a PSK between nodes;
	however, sharing a PSK among several node is sometimes unavoidable.		however, sharing a PSK among several nodes is sometimes unavoidable.
	When PSK sharing happens, other accommodations SHOULD be used as		When PSK sharing happens, other accommodations SHOULD be used as
	discussed in Section 6.		discussed in Section 6.
	Examples of PSK provisioning processes are included below.		Examples of PSK provisioning processes are included below.
	* Many industrial protocols assume that PSKs are distributed and		* Many industrial protocols assume that PSKs are distributed and
	assigned manually via one of the following approaches: typing the		assigned manually via one of the following approaches: typing the
	PSK into the devices, or using a Trust On First Use (TOFU)		PSK into the devices, or using a Trust On First Use (TOFU)
	approach with a device completely unprotected before the first		approach with a device completely unprotected before the first
	login did take place. Many devices have very limited UI. For		login did take place. Many devices have very limited UI. For
	example, they may only have a numeric keypad or even less number		example, they may only have a numeric keypad or even fewer
	of buttons. When the TOFU approach is not suitable, entering the		buttons. When the TOFU approach is not suitable, entering the key
	key would require typing it on a constrained UI.		would require typing it on a constrained UI.
	* Some devices provision PSKs via an out-of-band, cloud-based		* Some devices provision PSKs via an out-of-band, cloud-based
	syncing protocol.		syncing protocol.
	* Some secrets may be baked into or hardware or software device		* Some secrets may be baked into hardware or software device
	components. Moreover, when this is done at manufacturing time,		components. Moreover, when this is done at manufacturing time,
	secrets may be printed on labels or included in a Bill of		secrets may be printed on labels or included in a Bill of
	Materials for ease of scanning or import.		Materials for ease of scanning or import.
	5.3. Provisioning Constraints		5.3. Provisioning Constraints
	PSK provisioning systems are often constrained in application-		PSK provisioning systems are often constrained in application-
	specific ways. For example, although one goal of provisioning is to		specific ways. For example, although one goal of provisioning is to
	ensure that each pair of nodes has a unique key pair, some systems do		ensure that each pair of nodes has a unique key pair, some systems do
	not want to distribute pair-wise shared keys to achieve this. As		not want to distribute pair-wise shared keys to achieve this. As
	skipping to change at page 12, line 28 ¶		skipping to change at page 12, line 28 ¶
	the node identifiers in the ImportedIdentity.context construct		the node identifiers in the ImportedIdentity.context construct
	specified in [I-D.ietf-tls-external-psk-importer]. One solution		specified in [I-D.ietf-tls-external-psk-importer]. One solution
	would be for each endpoint to select one globally unique identifier		would be for each endpoint to select one globally unique identifier
	and use it in all PSK handshakes. The unique identifier can, for		and use it in all PSK handshakes. The unique identifier can, for
	example, be one of its MAC addresses, a 32-byte random number, or its		example, be one of its MAC addresses, a 32-byte random number, or its
	Universally Unique IDentifier (UUID) [RFC4122]. Note that such		Universally Unique IDentifier (UUID) [RFC4122]. Note that such
	persistent, global identifiers have privacy implications; see		persistent, global identifiers have privacy implications; see
	Section 7.		Section 7.
	Each endpoint SHOULD know the identifier of the other endpoint with		Each endpoint SHOULD know the identifier of the other endpoint with
	which its wants to connect and SHOULD compare it with the other		which it wants to connect and SHOULD compare it with the other
	endpoint's identifier used in ImportedIdentity.context. It is		endpoint's identifier used in ImportedIdentity.context. It is
	however important to remember that endpoints sharing the same group		however important to remember that endpoints sharing the same group
	PSK can always impersonate each other.		PSK can always impersonate each other.
	Considerations for external PSK usage extend beynond proper		Considerations for external PSK usage extend beyond proper
	identification. When early data is used with an external PSK, the		identification. When early data is used with an external PSK, the
	random value in the ClientHello is the only source of entropy that		random value in the ClientHello is the only source of entropy that
	contributes to key diversity between sessions. As a result, when an		contributes to key diversity between sessions. As a result, when an
	external PSK is used more than one time, the random number source on		external PSK is used more than one time, the random number source on
	the client has a significant role in the protection of the early		the client has a significant role in the protection of the early
	data.		data.
	9. IANA Considerations		9. IANA Considerations
	This document makes no IANA requests.		This document makes no IANA requests.
	skipping to change at page 14, line 8 ¶		skipping to change at page 14, line 8 ¶
	Rescorla, E., Tschofenig, H., and N. Modadugu, "The		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
	Datagram Transport Layer Security (DTLS) Protocol Version		Datagram Transport Layer Security (DTLS) Protocol Version
	1.3", Work in Progress, Internet-Draft, draft-ietf-tls-		1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
	dtls13-43, 30 April 2021,		dtls13-43, 30 April 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-tls-		<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
	dtls13-43>.		dtls13-43>.
	[I-D.irtf-cfrg-cpace]		[I-D.irtf-cfrg-cpace]
	Abdalla, M., Haase, B., and J. Hesse, "CPace, a balanced		Abdalla, M., Haase, B., and J. Hesse, "CPace, a balanced
	composable PAKE", Work in Progress, Internet-Draft, draft-		composable PAKE", Work in Progress, Internet-Draft, draft-
	irtf-cfrg-cpace-03, 15 November 2021,		irtf-cfrg-cpace-04, 10 December 2021,
	<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-		<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
	cpace-03>.		cpace-04>.
	[I-D.irtf-cfrg-opaque]		[I-D.irtf-cfrg-opaque]
	Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The		Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The
	OPAQUE Asymmetric PAKE Protocol", Work in Progress,		OPAQUE Asymmetric PAKE Protocol", Work in Progress,
	Internet-Draft, draft-irtf-cfrg-opaque-07, 25 October		Internet-Draft, draft-irtf-cfrg-opaque-07, 25 October
	2021, <https://datatracker.ietf.org/doc/html/draft-irtf-		2021, <https://datatracker.ietf.org/doc/html/draft-irtf-
	cfrg-opaque-07>.		cfrg-opaque-07>.
	[I-D.mattsson-emu-eap-tls-psk]		[I-D.mattsson-emu-eap-tls-psk]
	Mattsson, J. P., Sethi, M., Aura, T., and O. Friel, "EAP-		Mattsson, J. P., Sethi, M., Aura, T., and O. Friel, "EAP-
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	TR-03112-api_teil7.pdf?__blob=publicationFile&v=1>.		TR-03112-api_teil7.pdf?__blob=publicationFile&v=1>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This document is the output of the TLS External PSK Design Team,		This document is the output of the TLS External PSK Design Team,
	comprised of the following members: Benjamin Beurdouche, Björn Haase,		comprised of the following members: Benjamin Beurdouche, Björn Haase,
	Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland,		Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland,
	Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel,		Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel,
	and Russ Housley.		and Russ Housley.
	This document was improved by a high quality review by Ben Kaduk.		This document was improved by a high quality reviews by Ben Kaduk and
			John Mattsson.
	Authors' Addresses		Authors' Addresses
	Russ Housley		Russ Housley
	Vigil Security		Vigil Security
	Email: housley@vigilsec.com		Email: housley@vigilsec.com
	Jonathan Hoyland		Jonathan Hoyland
	Cloudflare Ltd.		Cloudflare Ltd.
End of changes. 20 change blocks.
	37 lines changed or deleted		39 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/