< draft-ietf-tls-external-psk-guidance-02.txt   draft-ietf-tls-external-psk-guidance-03.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: 24 August 2021 Cloudflare Ltd. Expires: 16 April 2022 Cloudflare Ltd.
M. Sethi M. Sethi
Ericsson Ericsson
C.A. Wood C.A. Wood
Cloudflare Cloudflare
20 February 2021 13 October 2021
Guidance for External PSK Usage in TLS Guidance for External PSK Usage in TLS
draft-ietf-tls-external-psk-guidance-02 draft-ietf-tls-external-psk-guidance-03
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) version 1.3 as defined in (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
RFC 8446. It lists TLS security properties provided by PSKs under This document lists TLS security properties provided by PSKs under
certain assumptions and demonstrates how violations of these certain assumptions, and then demonstrates how violations of these
assumptions lead to attacks. It discusses PSK use cases, assumptions lead to attacks. This document discusses PSK use cases
provisioning processes, and TLS stack implementation support in the and provisioning processes. This document provides advice for
context of these assumptions. It provides advice for applications in applications to help meet these assumptions. This document also
various use cases to help meet these assumptions. It also lists the lists the privacy and security properties that are not provided by
privacy and security properties that are not provided by TLS when TLS 1.3 when external PSKs are used.
external PSKs are 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 24 August 2021. This Internet-Draft will expire on 16 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 47 skipping to change at page 2, line 47
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document provides guidance on the use of external Pre-Shared This document provides guidance on the use of external Pre-Shared
Keys (PSKs) in Transport Layer Security (TLS) version 1.3 [RFC8446]. Keys (PSKs) in Transport Layer Security (TLS) 1.3 [RFC8446]. This
This document lists TLS security properties provided by PSKs under guidance also applies to Datagram TLS (DTLS) 1.3
certain assumptions and demonstrates how violations of these [I-D.ietf-tls-dtls13] and Compact TLS 1.3 [I-D.ietf-tls-ctls]. For
assumptions lead to attacks. This document discusses PSK use cases, readability, this document uses the term TLS to refer to all such
provisioning processes, and TLS stack implementation support in the versions. External PSKs are symmetric secret keys provided to the
context of these assumptions. This document also provides advice for TLS protocol implementation as external inputs. External PSKs are
applications in various use cases to help meet these assumptions. provisioned out-of-band. This document lists TLS security properties
provided by PSKs under certain assumptions and demonstrates how
violations of these assumptions lead to attacks. This document
discusses PSK use cases, provisioning processes, and TLS stack
implementation support in the context of these assumptions. This
document also provides advice for applications in various use cases
to help meet these assumptions.
There are many resources that provide guidance for password There are many resources that provide guidance for password
generation and verification aimed towards improving security. generation and verification aimed towards improving security.
However, there is no such equivalent for external Pre-Shared Keys However, there is no such equivalent for external Pre-Shared Keys
(PSKs) in TLS. This document aims to reduce that gap. (PSKs) in TLS. This document aims to reduce that gap.
The guidance provided in this document is applicable across TLS
[RFC8446], DTLS [I-D.ietf-tls-dtls13], and Constrained TLS
[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 "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 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
External PSK authentication in TLS allows endpoints to authenticate When using external PSK authentication, the use of previously
connections using previously established keys. These keys do not established PSKs allows TLS endpoints to authenticate the endpoint
provide protection of endpoint identities (see Section 5), nor do identities. However, these keys do not provide privacy protection of
they provide non-repudiation (one endpoint in a connection can deny endpoint identities (see Section 5), nor do they provide non-
the conversation). Protection of endpoint identities and protection repudiation (one endpoint in a connection can deny the conversation).
against an endpoint denying the conversation are possible when a
fresh TLS handshake is performed.
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.
4.1. Shared PSKs 4.1. Shared PSKs
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 done naively by having all members share a common key, then TLS
authenticates only group membership, and the security of the overall authenticates only group membership, 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 PSK with DH is used, then compromise of a group member that 2. If PSK is combined with DH, then compromise of a group member
actively completes connections with other group members can read that knows the resulting DH shared secret will enable the
(and modify) traffic. attacker to read (and modify) traffic.
3. If PSK without DH is used, then compromise of any group member
allows the attacker to passively read (and modify) all traffic.
4. If a group member is compromised, then the attacker can perform 3. If PSK is not combined with DH, then compromise of any group
all of the above attacks. member allows the attacker to passively read (and actively
modify) all 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 this class of attack is not possible if each member below. Note that a partial mitigiation against this class of attack
uses the SNI extension [RFC6066] and terminates the connection on is available: each group member includes the SNI extension [RFC6066]
mismatch. See [Selfie] for details. and terminates the connection on mismatch between the presented SNI
value and the receiving member's known identity. See [Selfie] for
details.
To illustrate the rerouting attack, consider the group of peers who To illustrate the rerouting attack, consider the group of peers who
know the PSK be "A", "B", and "C". The attack proceeds as follows: know the PSK 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 second flight (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,
handshake, ostensibly with "B". 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 with "A". completed the handshake with A.
This attack violates the peer authentication property, and if "C" In this attack, peer authentication is not provided. Also, if C
supports a weaker set of cipher suites than "B", this attack also supports a weaker set of cipher suites than B, cryptographic
violates the downgrade protection property. This rerouting is a type algorithm downgrade attacks might be possible. This rerouting is a
of identity misbinding attack [Krawczyk][Sethi]. Selfie attack type 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 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 changing individual group members is not possible without establishing a new
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. 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. The Crypto Forum Research Group (CFRG) is a PAKE is used with TLS. The Crypto Forum Research Group (CFRG) is
currently working on specifying a standard PAKE (see currently working on specifying recommended PAKEs (see
[I-D.irtf-cfrg-cpace] and [I-D.irtf-cfrg-opaque]). [I-D.irtf-cfrg-cpace] and [I-D.irtf-cfrg-opaque], for the symmetric
and asymmetric cases, respectively).
5. Privacy Considerations 5. Privacy Considerations
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. TLS does little to keep PSK identity
identity information private. For example, an adversary learns information private. For example, an adversary learns information
information about the external PSK or its identifier by virtue of it about the external PSK or its identifier by virtue of it appearing in
appearing in cleartext in a ClientHello. As a result, a passive cleartext in a ClientHello. As a result, a passive adversary can
adversary can link two or more connections together that use the same link two or more connections together that use the same external PSK
external PSK on the wire. Depending on the PSK identity, a passive on the wire. Depending on the PSK identity, a passive attacker may
attacker may also be able to identify the device, person, or also be able to identify the device, person, or enterprise running
enterprise running the TLS client or TLS server. An active attacker the TLS client or TLS server. An active attacker can also use the
can also use the PSK identity to suppress handshakes or application PSK identity to suppress handshakes or application data from a
data from a specific device by blocking, delaying, or rate-limiting specific device by blocking, delaying, or rate-limiting traffic.
traffic. Techniques for mitigating these risks require analysis and Techniques for mitigating these risks require further analysis and
are out of scope for this document. 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. Preventing this type of linkability is out of scope.
6. External PSK Use Cases and Provisioning Processes 6. External PSK Use Cases and Provisioning Processes
PSK ciphersuites were first specified for TLS in 2005. Now, PSKs are PSK ciphersuites were first specified for TLS in 2005. Now, PSKs are
skipping to change at page 7, line 39 skipping to change at page 7, line 39
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 node 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 7. discussed in 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 using a Trust On First Use (TOFU)
First Use (TOFU) approach with a device completely unprotected approach with a device completely unprotected before the first
before the first login did take place). Many devices have very login did take place. Many devices have very limited UI. For
limited UI. For example, they may only have a numeric keypad or example, they may only have a numeric keypad or even less number
even less number of buttons. When the TOFU approach is not of buttons. When the TOFU approach is not suitable, entering the
suitable, entering the key would require typing it on a key would require typing it on a constrained UI.
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 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
skipping to change at page 8, line 41 skipping to change at page 8, line 36
low entropy PSKs, i.e., those derived from less than 128 bits of 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 no such mechanisms have yet been standardised, and further that no such mechanisms have yet been standardised, and further
that these mechanisms will not necessarily follow the same that these mechanisms will not necessarily follow the same
architecture as the process for incorporating EPSKs described in architecture as the process for incorporating EPSKs described in
[I-D.ietf-tls-external-psk-importer]. [I-D.ietf-tls-external-psk-importer].
2. Unless other accommodations are made, each PSK MUST be restricted 2. Unless other accommodations are made to mitigate the risks of
in its use to at most two logical nodes: one logical node in a PSKs know to a group, each PSK MUST be restricted in its use to
TLS client role and one logical node in a TLS server role. (The at most two logical nodes: one logical node in a TLS client role
two logical nodes MAY be the same, in different roles.) Two and one logical node in a TLS server role. (The two logical
acceptable accommodations are described in nodes MAY be the same, in different roles.) Two 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 using TLS 1.3 SHOULD use external PSK importers 3. Nodes 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
client-server pair. Importers make provisioning external PSKs client-server pair when applicable. Importers make provisioning
easier and less error prone by deriving a unique, imported PSK external PSKs easier and less error prone by deriving a unique,
from the external PSK for each key derivation function a node imported PSK from the external PSK for each key derivation
supports. See the Security Considerations in function a node supports. See the Security Considerations in
[I-D.ietf-tls-external-psk-importer] for more information. [I-D.ietf-tls-external-psk-importer] for more information.
4. Where possible the main PSK (that which is fed into the importer) 4. Where possible the main PSK (that which is fed into the importer)
SHOULD be deleted after the imported keys have been generated. SHOULD be deleted after the imported keys have been generated.
This prevents an attacker from bootstrapping a compromise of one This prevents an attacker from bootstrapping a compromise of one
node into the ability to attack connections between any node; node into the ability to attack connections between any node;
otherwise the attacker can recover the main key and then re-run otherwise the attacker can recover the main 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 configuring PSKs for individual connections. Details about when configuring PSKs for individual connections. Details about some
existing stacks at the time of writing are below. existing stacks at the time of writing are below.
* OpenSSL and BoringSSL: Applications can specify support for * OpenSSL and BoringSSL: Applications can specify support for
external PSKs via distinct ciphersuites in TLS 1.2 and below. external PSKs via distinct ciphersuites in TLS 1.2 and below.
They also then configure callbacks that are invoked for PSK They also then configure callbacks that are invoked for PSK
selection during the handshake. These callbacks must provide a selection during the handshake. These callbacks must provide a
PSK identity and key. The exact format of the callback depends on PSK identity and key. The exact format of the callback depends on
the negotiated TLS protocol version, with new callback functions the negotiated TLS protocol version, with new callback functions
added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support. added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support.
The PSK length is validated to be between [1, 256] bytes. The PSK The PSK length is validated to be between [1, 256] bytes. The PSK
skipping to change at page 10, line 19 skipping to change at page 10, line 19
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. When PSK identities are configured comparison for any operation. When PSK identities are configured
manually it is important to be aware that due to encoding issues manually it is important to be aware that due to encoding issues
visually identical strings may, in fact, differ. visually identical strings may, in fact, differ.
TLS version 1.3 [RFC8446] follows the same practice of specifying the TLS version 1.3 [RFC8446] follows the same practice of specifying the
PSK identity as a sequence of opaque bytes (shown as opaque PSK identity as a sequence of opaque bytes (shown as opaque
identity<1..2^16-1> in the specification). [RFC8446] also requires identity<1..2^16-1> in the specification) that thus is compared on a
that the PSK identities are at least 1 byte and at the most 65535 byte-by-byte basis. [RFC8446] also requires that the PSK identities
bytes in length. Although [RFC8446] does not place strict are at least 1 byte and at the most 65535 bytes in length. Although
requirements on the format of PSK identities, we do however note that [RFC8446] does not place strict requirements on the format of PSK
the format of PSK identities can vary depending on the deployment: 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. In applications and settings where the domain name federation. In applications and settings where the domain name
suffix is privacy sensitive, this practice is NOT RECOMMENDED. suffix is privacy sensitive, this practice is NOT RECOMMENDED.
* Deployments should take care that the length of the PSK identity * Deployments should take care that the length of the PSK identity
skipping to change at page 10, line 45 skipping to change at page 10, line 46
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 behavior and sequencing of PSK callbacks influences the application's behavior
when identity collisions occur. When a server receives a PSK when identity collisions occur. When a server receives a PSK
identity in a TLS 1.3 ClientHello, some TLS stacks execute the 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
identity collision occurs, the application will be given precedence identity collision occurs, the application's external PSK usage will
over how to handle the PSK. typically take precedence over the internal session resumption path.
8. Security Considerations 8. Security Considerations
Security considerations are provided throughout this document. It
bears repeating that there are concerns related to the use of
external PSKs regarding proper identification of TLS 1.3 endpoints
and additional risks when external PSKs are known to a group.
It is NOT RECOMMENDED to share the same PSK between more than one It is NOT RECOMMENDED to share the same PSK between more than one
client and server. However, as discussed in Section 6, there are client and server. However, as discussed in Section 6, there are
application scenarios that may rely on sharing the same PSK among application scenarios that may rely on sharing the same PSK among
multiple nodes. [I-D.ietf-tls-external-psk-importer] helps in multiple nodes. [I-D.ietf-tls-external-psk-importer] helps in
mitigating rerouting and Selfie style reflection attacks when the PSK mitigating rerouting and Selfie style reflection attacks when the PSK
is shared among multiple nodes. This is achieved by correctly using is shared among multiple nodes. This is achieved by correctly using
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]. It is RECOMMENDED specified in [I-D.ietf-tls-external-psk-importer]. One solution
that each endpoint selects one globally unique identifier and uses it would be for each endpoint to select one globally unique identifier
in all PSK handshakes. The unique identifier can, for example, be and uses it in all PSK handshakes. The unique identifier can, for
one of its MAC addresses, a 32-byte random number, or its Universally example, be one of its MAC addresses, a 32-byte random number, or its
Unique IDentifier (UUID) [RFC4122]. Each endpoint SHOULD know the Universally Unique IDentifier (UUID) [RFC4122].
identifier of the other endpoint with which its wants to connect and
SHOULD compare it with the other endpoint's identifier used in Each endpoint SHOULD know the identifier of the other endpoint with
ImportedIdentity.context. It is however important to remember that which its wants to connect and SHOULD compare it with the other
endpoints sharing the same group PSK can always impersonate each endpoint's identifier used in ImportedIdentity.context. It is
other. however important to remember that endpoints sharing the same group
PSK can always impersonate each other.
9. IANA Considerations 9. IANA Considerations
This document makes no IANA requests. This document makes no IANA requests.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-41, 7 February 2021, <https://www.ietf.org/
internet-drafts/draft-ietf-tls-dtls13-41.txt>.
[I-D.ietf-tls-external-psk-importer] [I-D.ietf-tls-external-psk-importer]
Benjamin, D. and C. A. Wood, "Importing External PSKs for Benjamin, D. and C. A. 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-06, 3 December 2020, external-psk-importer-06, 3 December 2020,
<https://www.ietf.org/internet-drafts/draft-ietf-tls- <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
external-psk-importer-06.txt>. external-psk-importer-06>.
[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/rfc/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/rfc/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/rfc/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>.
[I-D.ietf-tls-ctls] [I-D.ietf-tls-ctls]
Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
ctls-01, 2 November 2020, <https://www.ietf.org/internet- ctls-03, 12 July 2021,
drafts/draft-ietf-tls-ctls-01.txt>. <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
ctls-03>.
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
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-01, 24 January 2021, irtf-cfrg-cpace-02, 25 July 2021,
<https://www.ietf.org/internet-drafts/draft-irtf-cfrg- <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
cpace-01.txt>. cpace-02>.
[I-D.irtf-cfrg-opaque] [I-D.irtf-cfrg-opaque]
Krawczyk, H., Lewi, K., and C. A. Wood, "The OPAQUE Krawczyk, H., Bourdrez, D., Lewi, K., and C. A. Wood, "The
Asymmetric PAKE Protocol", Work in Progress, Internet- OPAQUE Asymmetric PAKE Protocol", Work in Progress,
Draft, draft-irtf-cfrg-opaque-02, 5 February 2021, Internet-Draft, draft-irtf-cfrg-opaque-06, 12 July 2021,
<https://www.ietf.org/internet-drafts/draft-irtf-cfrg- <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
opaque-02.txt>. opaque-06>.
[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-
TLS with PSK Authentication (EAP-TLS-PSK)", Work in TLS with PSK Authentication (EAP-TLS-PSK)", Work in
Progress, Internet-Draft, draft-mattsson-emu-eap-tls-psk- Progress, Internet-Draft, draft-mattsson-emu-eap-tls-psk-
00, 9 March 2020, <https://www.ietf.org/internet-drafts/ 00, 9 March 2020, <https://datatracker.ietf.org/doc/html/
draft-mattsson-emu-eap-tls-psk-00.txt>. draft-mattsson-emu-eap-tls-psk-00>.
[Krawczyk] Krawczyk, H., "SIGMA: The ‘SIGn-and-MAc’ Approach to [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-
V1_0-20170208-A.pdf>. V1_0-20170208-A.pdf>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>. <https://www.rfc-editor.org/rfc/rfc2865>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/rfc/rfc3748>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/rfc/rfc4122>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005, RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>. <https://www.rfc-editor.org/rfc/rfc4279>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/rfc/rfc6066>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"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/rfc/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/rfc/rfc7925>.
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based [RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773, Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020, DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/info/rfc8773>. <https://www.rfc-editor.org/rfc/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>.
skipping to change at page 14, line 33 skipping to change at page 14, line 44
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
Friel, and Russ Housley. Friel, and Russ Housley.
This document was improved by a high quality review by Ben Kaduk.
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 Cloudflare
Email: caw@heapingbits.net Email: caw@heapingbits.net
 End of changes. 49 change blocks. 
141 lines changed or deleted 152 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/