< draft-ietf-tls-external-psk-guidance-00.txt		draft-ietf-tls-external-psk-guidance-01.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: 20 December 2020 Cloudflare Ltd.		Expires: 6 May 2021 Cloudflare Ltd.
	M. Sethi		M. Sethi
	Ericsson		Ericsson
	C.A. Wood		C.A. Wood
	Cloudflare Ltd.		Cloudflare
	18 June 2020		2 November 2020
	Guidance for External PSK Usage in TLS		Guidance for External PSK Usage in TLS
	draft-ietf-tls-external-psk-guidance-00		draft-ietf-tls-external-psk-guidance-01
	Abstract		Abstract
	This document provides usage guidance for external Pre-Shared Keys		This document provides usage guidance for external Pre-Shared Keys
	(PSKs) in TLS. It lists TLS security properties provided by PSKs		(PSKs) in TLS. It lists TLS security properties provided by PSKs
	under certain assumptions and demonstrates how violations of these		under certain assumptions and demonstrates how violations of these
	assumptions lead to attacks. This document also discusses PSK use		assumptions lead to attacks. This document also discusses PSK use
	cases, provisioning processes, and TLS stack implementation support		cases, provisioning processes, and TLS stack implementation support
	in the context of these assumptions. It provides advice for		in the context of these assumptions. It provides advice for
	applications in various use cases to help meet these assumptions.		applications in various use cases to help meet these assumptions.
			Privacy and security properties not provided by PSKs are also
			included.
	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.
	(https://github.com/tlswg/external-psk-design-team).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
			This Internet-Draft will expire on 6 May 2021.
	This Internet-Draft will expire on 20 December 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 (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
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 28 ¶
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. PSK Security Properties . . . . . . . . . . . . . . . . . . . 3		4. PSK Security Properties . . . . . . . . . . . . . . . . . . . 3
	5. Privacy Properties . . . . . . . . . . . . . . . . . . . . . 5		5. Privacy Properties . . . . . . . . . . . . . . . . . . . . . 5
	6. External PSK Use Cases and Provisioning Processes . . . . . . 5		6. External PSK Use Cases and Provisioning Processes . . . . . . 5
	6.1. Provisioning Examples . . . . . . . . . . . . . . . . . . 6		6.1. Provisioning Examples . . . . . . . . . . . . . . . . . . 7
	6.2. Provisioning Constraints . . . . . . . . . . . . . . . . 7		6.2. Provisioning Constraints . . . . . . . . . . . . . . . . 7
	7. Recommendations for External PSK Usage . . . . . . . . . . . 7		7. Recommendations for External PSK Usage . . . . . . . . . . . 7
	7.1. Stack Interfaces . . . . . . . . . . . . . . . . . . . . 8		7.1. Stack Interfaces . . . . . . . . . . . . . . . . . . . . 8
	7.1.1. PSK Identity Encoding and Comparison . . . . . . . . 9		7.1.1. PSK Identity Encoding and Comparison . . . . . . . . 9
	7.1.2. PSK Identity Collisions . . . . . . . . . . . . . . . 9		7.1.2. PSK Identity Collisions . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	This document provides usage guidance for external Pre-Shared Keys		There are many resources that provide guidance for password
	(PSKs) in TLS. It lists TLS security properties provided by PSKs		generation and verification aimed towards improving security.
	under certain assumptions and demonstrates how violations of these		However, there is no such equivalent for external Pre-Shared Keys
	assumptions lead to attacks. This document also discusses PSK use		(PSKs) in TLS. This document aims to reduce that gap. It lists TLS
	cases, provisioning processes, and TLS stack implementation support		security properties provided by PSKs under certain assumptions and
	in the context of these assumptions. It provides advice for		demonstrates how violations of these assumptions lead to attacks.
	applications in various use cases to help meet these assumptions.		This document also discusses PSK use cases, provisioning processes,
			and TLS stack implementation support in the context of these
			assumptions. It provides advice for applications in various use
			cases to help meet these assumptions.
	The guidance provided in this document is applicable across TLS		The guidance provided in this document is applicable across TLS
	[RFC8446], DTLS [I-D.ietf-tls-dtls13], and Constrained TLS		[RFC8446], DTLS [I-D.ietf-tls-dtls13], and Constrained TLS
	[I-D.rescorla-tls-ctls].		[I-D.ietf-tls-ctls].
	2. Conventions and Definitions		2. Conventions and Definitions
	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.
	3. Notation		3. Notation
	For purposes of this document, a "logical node" is a computing		For purposes of this document, a "logical node" is a computing
	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 external PSK authentication mechanism in TLS implicitly assumes		External PSK authentication in TLS allows endpoints to authenticate
			connections using previously established keys. These keys do not
			provide protection of endpoint identities (see Section 5), nor do
			they provide non-repudiation (one endpoint in a connection can deny
			the conversation). PSK authentication security implicitly assumes
	one fundamental property: each PSK is known to exactly one client and		one fundamental property: each PSK is known to exactly one client and
	one server, and that these never switch roles. If this assumption is		one server, and that these never switch roles. If this assumption is
	violated, then the security properties of TLS are severely weakened.		violated, then the security properties of TLS are severely weakened.
	As discussed in Section 6, there are use cases where it is desirable		As discussed in Section 6, there are use cases where it is desirable
	for multiple clients or multiple servers to share a PSK. If this is		for multiple clients or multiple servers to share a PSK. If this is
	done naively by having all members share a common key, then TLS only		done naively by having all members share a common key, then TLS only
	authenticates the entire group, and the security of the overall		authenticates the entire group, and the security of the overall
	system is inherently rather brittle. There are a number of obvious		system is inherently rather brittle. There are a number of obvious
	weaknesses here:		weaknesses here:
	1. Any group member can impersonate any other group member.		1. Any group member can impersonate any other group member.
	2. If a group member is compromised, then the attacker can		2. If PSK with DH is used, then compromise of a group member that
	impersonate any group member (this follows from property (1)).		actively completes connections with other group members can read
			(and modify) traffic.
	3. If PSK without DH is used, then compromise of any group member		3. If PSK without DH is used, then compromise of any group member
	allows the attacker to passively read all traffic.		allows the attacker to passively read (and modify) all traffic.
	In addition to these, a malicious non-member can reroute handshakes		4. If a group member is compromised, then the attacker can perform
	between honest group members to connect them in unintended ways, as		all of the above attacks.
	detailed below.
	Let the group of peers who know the key be "A", "B", and "C". The		Additionally, a malicious non-member can reroute handshakes between
	attack proceeds as follows:		honest group members to connect them in unintended ways, as described
			below. (Note that this class of attack is not possible if each
			member uses the SNI extension [RFC6066] and terminates the connection
			on mismatch. See [Selfie] for details.) Let the group of peers who
			know the key be "A", "B", and "C". 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 "ServerHello" to "A".		3. "C" responds with a "ServerHello" to "A".
	4. "A" sends a "Finished" message to "B". "A" has completed the		4. "A" sends a "Finished" message to "B". "A" has completed the
	handshake, ostensibly with "B".		handshake, ostensibly with "B".
	5. The attacker redirects the "Finished" message to "C". "C" has		5. The attacker redirects the "Finished" message to "C". "C" has
	completed the handshake, ostensibly with "A".		completed the handshake with "A".
	This attack violates the peer authentication property, and if "C"		This attack violates the peer authentication property, and if "C"
	supports a weaker set of cipher suites than "B", this attack also		supports a weaker set of cipher suites than "B", this attack also
	violates the downgrade protection property. This rerouting is a type		violates the downgrade protection property. This rerouting is a type
	of identity misbinding attack [Krawczyk][Sethi]. Selfie attack		of identity misbinding attack [Krawczyk][Sethi]. Selfie attack
	[Selfie] is a special case of the rerouting attack against a group		[Selfie] is a special case of the rerouting attack against a group
	member that can act both as TLS server and client. In the Selfie		member that can act both as TLS server and client. In the Selfie
	attack, a malicious non-member reroutes a connection from the client		attack, a malicious non-member reroutes a connection from the client
	to the server on the same endpoint.		to the server on the same endpoint.
			Finally, in addition to these weaknesses, sharing a PSK across nodes
			may negatively affects deployments. For example, revocation of
			individual group members is not possible without changing the
			authentication key for all members.
	Entropy properties of external PSKs may also affect TLS security		Entropy properties of external PSKs may also affect TLS security
	properties. In particular, if a high entropy PSK is used, then PSK-		properties. In particular, if a high entropy PSK is used, then PSK-
	only key establishment modes are secure against both active and		only key establishment modes are secure against both active and
	passive attack. However, they lack forward security. Forward		passive attack. However, they lack forward security. Forward
	security may be achieved by using a PSK-DH mode.		security may be achieved by using a PSK-DH mode.
	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 passive		establishment modes are subject to passive exhaustive search passive
	attacks which will reveal the traffic keys. PSK-DH modes are subject		attacks which will reveal the traffic keys. PSK-DH modes are subject
	to active attacks in which the attacker impersonates one side. The		to 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
	a PAKE is used with TLS.		a PAKE is used with TLS. The Crypto Forum Research Group (CFRG) is
			currently working on specifying a standard PAKE (see
			[I-D.irtf-cfrg-cpace] and [I-D.irtf-cfrg-opaque]).
	5. Privacy Properties		5. Privacy Properties
	PSK privacy properties are orthogonal to security properties		PSK privacy properties are orthogonal to security properties
	described in Section 4. Traditionally, TLS does little to keep PSK		described in Section 4. Traditionally, TLS does little to keep PSK
	identity information private. For example, an adversary learns		identity information private. For example, an adversary learns
	information about the external PSK or its identifier by virtue of it		information about the external PSK or its identifier by virtue of it
	appearing in cleartext in a ClientHello. As a result, a passive		appearing in cleartext in a ClientHello. As a result, a passive
	adversary can link two or more connections together that use the same		adversary can link two or more connections together that use the same
	external PSK on the wire. Applications should take precautions when		external PSK on the wire. Depending on the PSK identity, a passive
	using external PSKs to mitigate these risks.		attacker may also be able to identify the device, person, or
			enterprise running the TLS client or TLS server. An active attacker
			can also use the PSK identity to oppress handshakes or application
			data from a specific device by blocking, delaying, or rate-limiting
			traffic. Techniques for mitigating these risks require analysis and
			are out of scope for this document.
	In addition to linkability in the network, external PSKs are		In addition to linkability in the network, external PSKs are
	intrinsically linkable by PSK receivers. Specifically, servers can		intrinsically linkable by PSK receivers. Specifically, servers can
	link successive connections that use the same external PSK together.		link successive connections that use the same external PSK together.
	Preventing this type of linkability is out of scope, as PSKs are		Preventing this type of linkability is out of scope.
	explicitly designed to support mutual authentication.
	6. External PSK Use Cases and Provisioning Processes		6. External PSK Use Cases and Provisioning Processes
	Pre-shared Key (PSK) ciphersuites were first specified for TLS in		PSK ciphersuites were first specified for TLS in 2005. Now, PSKs are
	2005. Now, PSK is an integral part of the TLS version 1.3		an integral part of the TLS version 1.3 specification [RFC8446]. TLS
	specification [RFC8446]. TLS 1.3 also uses PSKs for session		1.3 also uses PSKs for session resumption. It distinguishes these
	resumption. It distinguishes these resumption PSKs from external		resumption PSKs from external PSKs which have been provisioned out-
	PSKs which have been provisioned out-of-band (OOB). Below, we list		of-band (OOB). Below, we list some example use-cases where pair-wise
	some example use-cases where pair-wise external PSKs with TLS have		external PSKs (i.e., external PSKs that are shared between only one
	been used for authentication.		server and one client) have been used for authentication in TLS.
	* 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 PoP may use externally provisioned
	PSKs, primarily for the purposes of supporting TLS connections		PSKs, primarily for the purposes of supporting TLS connections
	with fast open (0-RTT data).		with early data.
	* 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 6, line 23 ¶		skipping to change at page 6, line 34 ¶
	[RFC2865] with TLS as specified in [RFC6614].		[RFC2865] with TLS as specified in [RFC6614].
	* The Generic Authentication Architecture (GAA) defined by 3GGP		* The Generic Authentication Architecture (GAA) defined by 3GGP
	mentions that TLS-PSK can be used between a server and user		mentions that TLS-PSK can be used between a server and user
	equipment for authentication [GAA].		equipment for authentication [GAA].
	* Smart Cards. The electronic German ID (eID) card supports		* Smart Cards. The electronic German ID (eID) card supports
	authentication of a card holder to online services with TLS-PSK		authentication of a card holder to online services with TLS-PSK
	[SmartCard].		[SmartCard].
			* Quantum resistance: Some deployments may use PSKs (or combine them
			with certificate-based authentication as described in [RFC8773])
			because of the protection they provide against quantum computers.
	There are also use cases where PSKs are shared between more than two		There are also use cases where PSKs are shared between more than two
	entities. Some examples below (as noted by Akhmetzyanova et		entities. Some examples below (as noted by Akhmetzyanova et
	al.[Akhmetzyanova]):		al.[Akhmetzyanova]):
	* Group chats. In this use-case, the membership of a group is		* Group chats. In this use-case, group participants may be
	confirmed by the possession of a PSK distributed out-of-band to		provisioned an external PSK out-of-band for establishing
	the group participants. Members can then establish peer-to-peer		authenticated connections with other members of the group.
	connections with each other using the external PSK. It is
	important to note that any node of the group can behave as a TLS
	client or server.
	* Internet of Things (IoT). In this use-case, resource-constrained		* Internet of Things (IoT) and devices with limited computational
	IoT devices act as TLS clients and share the same PSK. The		capabilities. Many PSK provisioning examples are possible in this
	devices use this PSK for quickly establishing connections with a		use-case. For example, in a given setting, IoT devices may all
	central server. Such a scheme ensures that the client IoT devices		share the same PSK and use it to communicate with a central server
	are legitimate members of the system. To perform rare system		(one key for n devices), have their own key for communicating with
	specific operations that require a higher security level, the		a central server (n keys for n devices), or have pairwise keys for
	central server can request resource-intensive client		communicating with each other (n^2 keys for n devices).
	authentication with the usage of a certificate after successfully
	establishing the connection with a PSK.		The exact provisioning process depends on the system requirements and
			threat model. Generally, use of a single PSK shared between more
			than one node is not recommended, even if other accommodations are
			made, such as client certificate authentication after PSK-based
			connection establishment. See Section 7.
	6.1. Provisioning Examples		6.1. Provisioning Examples
	* 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 via web server masks (using a Trust On		PSK into the devices, or via web server masks (using a Trust On
	First Use (TOFU) approach with a device completely unprotected		First Use (TOFU) approach with a device completely unprotected
	before the first login did take place). Many devices have very		before the first login did take place). Many devices have very
	limited UI. For example, they may only have a numeric keypad or		limited UI. For example, they may only have a numeric keypad or
	even less number of buttons. When the TOFU approach is not		even less number of buttons. When the TOFU approach is not
	suitable, entering the key would require typing it on a		suitable, entering the key would require typing it on a
	constrained UI. Moreover, PSK production lacks guidance unlike		constrained UI.
	user passwords.
	* 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 or 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.
	6.2. Provisioning Constraints		6.2. 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
	another example, some systems require the provisioning process to		another example, some systems require the provisioning process to
	embed application-specific information in either PSKs or their		embed application-specific information in either PSKs or their
	identities. Identities may sometimes need to be routable, as is		identities. Identities may sometimes need to be routable, as is
	currently under discussion for EAP-TLS-PSK.		currently under discussion for EAP-TLS-PSK
			[I-D.mattsson-emu-eap-tls-psk].
	7. Recommendations for External PSK Usage		7. Recommendations for External PSK Usage
	Applications MUST use external PSKs that adhere to the following		If an application uses external PSKs, the external PSKs MUST adhere
	requirements:		to the following requirements:
	1. Each PSK SHOULD be derived from at least 128 bits of entropy,		1. Each PSK SHOULD be derived from at least 128 bits of entropy,
	MUST be at least 128 bits long, and SHOULD be combined with a DH		MUST be at least 128 bits long, and SHOULD be combined with a DH
	exchange for forward secrecy. As discussed in Section 4, low		exchange, e.g., by using the "psk_dhe_ke" Pre-Shared Key Exchange
	entropy PSKs, i.e., those derived from less than 128 bits of		Mode in TLS 1.3, for forward secrecy. As discussed in Section 4,
			low entropy PSKs, i.e., those derived from less than 128 bits of
	entropy, are subject to attack and SHOULD be avoided. If only		entropy, are subject to attack and SHOULD be avoided. If only
	low-entropy keys are available, then key establishment mechanisms		low-entropy keys are available, then key establishment mechanisms
	such as Password Authenticated Key Exchange (PAKE) that mitigate		such as Password Authenticated Key Exchange (PAKE) that mitigate
	the risk of offline dictionary attacks SHOULD be employed. Note		the risk of offline dictionary attacks SHOULD be employed. Note
	that these mechanisms do not necessarily follow the same		that no such mechanisms have yet been standardised, and further
	architecture as the ordinary process for incorporating EPSKs		that these mechanisms will not necessarily follow the same
	described in this draft.		architecture as the process for incorporating EPSKs described in
			[I-D.ietf-tls-external-psk-importer].
	2. Unless other accommodations are made, each PSK MUST be restricted		2. Unless other accommodations are made, each PSK MUST be restricted
	in its use to at most two logical nodes: one logical node in a		in its use to at most two logical nodes: one logical node in a
	TLS client role and one logical node in a TLS server role. (The		TLS client role and one logical node in a TLS server role. (The
	two logical nodes MAY be the same, in different roles.) Two		two logical nodes MAY be the same, in different roles.) Two
	acceptable accommodations are described in		acceptable accommodations are described in
	[I-D.ietf-tls-external-psk-importer]: (1) exchanging client and		[I-D.ietf-tls-external-psk-importer]: (1) exchanging client and
	server identifiers over the TLS connection after the handshake,		server identifiers over the TLS connection after the handshake,
	and (2) incorporating identifiers for both the client and the		and (2) incorporating identifiers for both the client and the
	server into the context string for an EPSK importer.		server into the context string for an EPSK importer.
	3. Nodes SHOULD use external PSK importers		3. Nodes using TLS 1.3 SHOULD use external PSK importers
	[I-D.ietf-tls-external-psk-importer] when configuring PSKs for a		[I-D.ietf-tls-external-psk-importer] when configuring PSKs for a
	pair of TLS client and server.		client-server pair. Importers make provisioning external PSKs
			easier and less error prone by deriving a unique, imported PSK
			from the external PSK for each key derivation function a node
			supports. See the Security Considerations in
			[I-D.ietf-tls-external-psk-importer] for more information.
	4. Where possible the master PSK (that which is fed into the		4. Where possible the main PSK (that which is fed into the importer)
	importer) SHOULD be deleted after the imported keys have been		SHOULD be deleted after the imported keys have been generated.
	generated. This protects an attacker from bootstrapping a		This protects an attacker from bootstrapping a compromise of one
	compromise of one node into the ability to attack connections		node into the ability to attack connections between any node;
	between any node; otherwise the attacker can recover the master		otherwise the attacker can recover the main key and then re-run
	key and then re-run the importer itself.		the importer itself.
	7.1. Stack Interfaces		7.1. Stack Interfaces
	Most major TLS implementations support external PSKs. Stacks		Most major TLS implementations support external PSKs. Stacks
	supporting external PSKs provide interfaces that applications may use		supporting external PSKs provide interfaces that applications may use
	when supplying them for individual connections. Details about		when supplying them for individual connections. Details about
	existing stacks at the time of writing are below.		existing stacks at the time of writing are below.
	* OpenSSL and BoringSSL: Applications specify support for external		* OpenSSL and BoringSSL: Applications can specify support for
	PSKs via distinct ciphersuites. They also then configure		external PSKs via distinct ciphersuites in TLS 1.2 and below.
	callbacks that are invoked for PSK selection during the handshake.		They also then configure callbacks that are invoked for PSK
	These callbacks must provide a PSK identity and key. The exact		selection during the handshake. These callbacks must provide a
	format of the callback depends on the negotiated TLS protocol		PSK identity and key. The exact format of the callback depends on
	version with new callback functions added specifically to OpenSSL		the negotiated TLS protocol version, with new callback functions
	for TLS 1.3 [RFC8446] PSK support. The PSK length is validated to		added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support.
	be between [1, 256] bytes. The PSK identity may be up to 128		The PSK length is validated to be between [1, 256] bytes. The PSK
	bytes long.		identity may be up to 128 bytes long.
	* mbedTLS: Client applications configure PSKs before creating a		* mbedTLS: Client applications configure PSKs before creating a
	connection by providing the PSK identity and value inline.		connection by providing the PSK identity and value inline.
	Servers must implement callbacks similar to that of OpenSSL. Both		Servers must implement callbacks similar to that of OpenSSL. Both
	PSK identity and key lengths may be between [1, 16] bytes long.		PSK identity and key lengths may be between [1, 16] bytes long.
	* gnuTLS: Applications configure PSK values, either as raw byte		* gnuTLS: Applications configure PSK values, either as raw byte
	strings or hexadecimal strings. The PSK identity and key size are		strings or hexadecimal strings. The PSK identity and key size are
	not validated.		not validated.
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 35 ¶
	OpenSSL.		OpenSSL.
	7.1.1. PSK Identity Encoding and Comparison		7.1.1. PSK Identity Encoding and Comparison
	Section 5.1 of [RFC4279] mandates that the PSK identity should be		Section 5.1 of [RFC4279] mandates that the PSK identity should be
	first converted to a character string and then encoded to octets		first converted to a character string and then encoded to octets
	using UTF-8. This was done to avoid interoperability problems		using UTF-8. This was done to avoid interoperability problems
	(especially when the identity is configured by human users). On the		(especially when the identity is configured by human users). On the
	other hand, [RFC7925] advises implementations against assuming any		other hand, [RFC7925] advises implementations against assuming any
	structured format for PSK identities and recommends byte-by-byte		structured format for PSK identities and recommends byte-by-byte
	comparison for any operation. TLS version 1.3 [RFC8446] follows the		comparison for any operation. When PSK identites are configured
	same practice of specifying the PSK identity as a sequence of opaque		manually it is important to be aware that due to encoding issues
	bytes (shown as opaque identity<1..2^16-1> in the specification).		visually identical strings may, in fact, differ.
	[RFC8446] also requires that the PSK identities are at least 1 byte
	and at the most 65535 bytes in length. Although [RFC8446] does not		TLS version 1.3 [RFC8446] follows the same practice of specifying the
	place strict requirements on the format of PSK identities, we do		PSK identity as a sequence of opaque bytes (shown as opaque
	however note that the format of PSK identities can vary depending on		identity<1..2^16-1> in the specification). [RFC8446] also requires
	the deployment:		that the PSK identities are at least 1 byte and at the most 65535
			bytes in length. Although [RFC8446] does not place strict
			requirements on the format of PSK identities, we do however note that
			the format of PSK identities can vary depending on the deployment:
	* The PSK identity MAY be a user configured string when used in		* The PSK identity MAY be a user configured string when used in
	protocols like Extensible Authentication Protocol (EAP) [RFC3748].		protocols like Extensible Authentication Protocol (EAP) [RFC3748].
	gnuTLS for example treats PSK identities as usernames.		gnuTLS for example treats PSK identities as usernames.
	* PSK identities MAY have a domain name suffix for roaming and		* PSK identities MAY have a domain name suffix for roaming and
	federation.		federation.
	* Deployments should take care that the length of the PSK identity		* Deployments should take care that the length of the PSK identity
	is sufficient to avoid obvious collisions.		is sufficient to avoid collisions.
	7.1.2. PSK Identity Collisions		7.1.2. PSK Identity Collisions
	It is possible, though unlikely, that an external PSK identity may		It is possible, though unlikely, that an external PSK identity may
	clash with a resumption PSK identity. The TLS stack implementation		clash with a resumption PSK identity. The TLS stack implementation
	and sequencing of PSK callbacks influences the application's		and sequencing of PSK callbacks influences the application's
	behaviour when identity collisions occur. When a server receives a		behaviour when identity collisions occur. When a server receives a
	PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the		PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the
	application's registered callback function before checking the		application's registered callback function before checking the
	stack's internal session resumption cache. This means that if a PSK		stack's internal session resumption cache. This means that if a PSK
	skipping to change at page 10, line 47 ¶		skipping to change at page 11, line 19 ¶
	dtls13-38, 29 May 2020, <http://www.ietf.org/internet-		dtls13-38, 29 May 2020, <http://www.ietf.org/internet-
	drafts/draft-ietf-tls-dtls13-38.txt>.		drafts/draft-ietf-tls-dtls13-38.txt>.
	[I-D.ietf-tls-external-psk-importer]		[I-D.ietf-tls-external-psk-importer]
	Benjamin, D. and C. Wood, "Importing External PSKs for		Benjamin, D. and C. Wood, "Importing External PSKs for
	TLS", Work in Progress, Internet-Draft, draft-ietf-tls-		TLS", Work in Progress, Internet-Draft, draft-ietf-tls-
	external-psk-importer-05, 19 May 2020,		external-psk-importer-05, 19 May 2020,
	<http://www.ietf.org/internet-drafts/draft-ietf-tls-		<http://www.ietf.org/internet-drafts/draft-ietf-tls-
	external-psk-importer-05.txt>.		external-psk-importer-05.txt>.
	[I-D.rescorla-tls-ctls]
	Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
	1.3", Work in Progress, Internet-Draft, draft-rescorla-
	tls-ctls-04, 9 March 2020, <http://www.ietf.org/internet-
	drafts/draft-rescorla-tls-ctls-04.txt>.
	[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>.
			[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
			Extensions: Extension Definitions", RFC 6066,
			DOI 10.17487/RFC6066, January 2011,
			<https://www.rfc-editor.org/info/rfc6066>.
	[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>.
	10.2. Informative References		10.2. Informative References
	[Akhmetzyanova]		[Akhmetzyanova]
	Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A.		Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A.
	Sokolov, "Continuing to reflect on TLS 1.3 with external		Sokolov, "Continuing to reflect on TLS 1.3 with external
	PSK", 2019, <https://eprint.iacr.org/2019/421.pdf>.		PSK", 2019, <https://eprint.iacr.org/2019/421.pdf>.
	[GAA] "TR33.919 version 12.0.0 Release 12", n.d.,		[GAA] "TR33.919 version 12.0.0 Release 12", n.d.,
	<https://www.etsi.org/deliver/		<https://www.etsi.org/deliver/
	etsi_tr/133900_133999/133919/12.00.00_60/		etsi_tr/133900_133999/133919/12.00.00_60/
	tr_133919v120000p.pdf>.		tr_133919v120000p.pdf>.
	[Krawczyk] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to		[I-D.ietf-tls-ctls]
			Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
			1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
			ctls-01, 2 November 2020, <http://www.ietf.org/internet-
			drafts/draft-ietf-tls-ctls-01.txt>.
			[I-D.irtf-cfrg-cpace]
			Abdalla, M., Haase, B., and J. Hesse, "CPace, a balanced
			composable PAKE", Work in Progress, Internet-Draft, draft-
			irtf-cfrg-cpace-00, 28 July 2020, <http://www.ietf.org/
			internet-drafts/draft-irtf-cfrg-cpace-00.txt>.
			[I-D.irtf-cfrg-opaque]
			Krawczyk, H., Lewi, K., and C. Wood, "The OPAQUE
			Asymmetric PAKE Protocol", Work in Progress, Internet-
			Draft, draft-irtf-cfrg-opaque-00, 28 September 2020,
			<http://www.ietf.org/internet-drafts/draft-irtf-cfrg-
			opaque-00.txt>.
			[I-D.mattsson-emu-eap-tls-psk]
			Mattsson, J., Sethi, M., Aura, T., and O. Friel, "EAP-TLS
			with PSK Authentication (EAP-TLS-PSK)", Work in Progress,
			Internet-Draft, draft-mattsson-emu-eap-tls-psk-00, 9 March
			2020, <http://www.ietf.org/internet-drafts/draft-mattsson-
			emu-eap-tls-psk-00.txt>.
			[Krawczyk] Krawczyk, H., "SIGMA: The ‘SIGn-and-MAc’ Approach to
	Authenticated Diffie-Hellman and Its Use in the IKE		Authenticated Diffie-Hellman and Its Use in the IKE
	Protocols", Annual International Cryptology Conference.		Protocols", Annual International Cryptology Conference.
	Springer, Berlin, Heidelberg , 2003,		Springer, Berlin, Heidelberg , 2003,
	<https://link.springer.com/content/		<https://link.springer.com/content/
	pdf/10.1007/978-3-540-45146-4_24.pdf>.		pdf/10.1007/978-3-540-45146-4_24.pdf>.
	[LwM2M] "Lightweight Machine to Machine Technical Specification",		[LwM2M] "Lightweight Machine to Machine Technical Specification",
	n.d.,		n.d.,
	<http://www.openmobilealliance.org/release/LightweightM2M/		<http://www.openmobilealliance.org/release/LightweightM2M/
	V1_0-20170208-A/OMA-TS-LightweightM2M-		V1_0-20170208-A/OMA-TS-LightweightM2M-
	skipping to change at page 12, line 26 ¶		skipping to change at page 13, line 26 ¶
	"Transport Layer Security (TLS) Encryption for RADIUS",		"Transport Layer Security (TLS) Encryption for RADIUS",
	RFC 6614, DOI 10.17487/RFC6614, May 2012,		RFC 6614, DOI 10.17487/RFC6614, May 2012,
	<https://www.rfc-editor.org/info/rfc6614>.		<https://www.rfc-editor.org/info/rfc6614>.
	[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer		[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
	Security (TLS) / Datagram Transport Layer Security (DTLS)		Security (TLS) / Datagram Transport Layer Security (DTLS)
	Profiles for the Internet of Things", RFC 7925,		Profiles for the Internet of Things", RFC 7925,
	DOI 10.17487/RFC7925, July 2016,		DOI 10.17487/RFC7925, July 2016,
	<https://www.rfc-editor.org/info/rfc7925>.		<https://www.rfc-editor.org/info/rfc7925>.
			[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
			Authentication with an External Pre-Shared Key", RFC 8773,
			DOI 10.17487/RFC8773, March 2020,
			<https://www.rfc-editor.org/info/rfc8773>.
	[Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3		[Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3
	with PSK", 2019, <https://eprint.iacr.org/2019/347.pdf>.		with PSK", 2019, <https://eprint.iacr.org/2019/347.pdf>.
	[Sethi] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks		[Sethi] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks
	on Secure Device Pairing and Bootstrapping", Proceedings		on Secure Device Pairing and Bootstrapping", Proceedings
	of the 2019 ACM Asia Conference on Computer and		of the 2019 ACM Asia Conference on Computer and
	Communications Security , 2019,		Communications Security , 2019,
	<https://arxiv.org/pdf/1902.07550>.		<https://arxiv.org/pdf/1902.07550>.
	[SmartCard]		[SmartCard]
	"Technical Guideline TR-03112-7 eCard-API-Framework -		"Technical Guideline TR-03112-7 eCard-API-Framework –
	Protocols", 2015, <https://www.bsi.bund.de/SharedDocs/Down		Protocols", 2015, <https://www.bsi.bund.de/SharedDocs/Down
	loads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03112/		loads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03112/
	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, Bjoern		comprised of the following members: Benjamin Beurdouche, Bjoern
	Haase, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan		Haase, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan
	Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen		Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen
	skipping to change at page 13, line 4 ¶		skipping to change at page 14, line 6 ¶
	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, Bjoern		comprised of the following members: Benjamin Beurdouche, Bjoern
	Haase, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan		Haase, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan
	Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen		Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen
	Friel, and Russ Housley.		Friel, and Russ Housley.
	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.
	Email: jonathan.hoyland@gmail.com		Email: jonathan.hoyland@gmail.com
	Mohit Sethi		Mohit Sethi
	Ericsson		Ericsson
	Email: mohit@piuha.net		Email: mohit@piuha.net
	Christopher A. Wood		Christopher A. Wood
	Cloudflare Ltd.		Cloudflare
	Email: caw@heapingbits.net		Email: caw@heapingbits.net
End of changes. 44 change blocks.
	103 lines changed or deleted		170 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/