< draft-ietf-tls-external-psk-guidance-01.txt   draft-ietf-tls-external-psk-guidance-02.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: 6 May 2021 Cloudflare Ltd. Expires: 24 August 2021 Cloudflare Ltd.
M. Sethi M. Sethi
Ericsson Ericsson
C.A. Wood C.A. Wood
Cloudflare Cloudflare
2 November 2020 20 February 2021
Guidance for External PSK Usage in TLS Guidance for External PSK Usage in TLS
draft-ietf-tls-external-psk-guidance-01 draft-ietf-tls-external-psk-guidance-02
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 Transport Layer Security (TLS) version 1.3 as defined in
under certain assumptions and demonstrates how violations of these RFC 8446. It lists TLS security properties provided by PSKs under
assumptions lead to attacks. This document also discusses PSK use certain assumptions and demonstrates how violations of these
cases, provisioning processes, and TLS stack implementation support assumptions lead to attacks. It discusses PSK use cases,
in the context of these assumptions. It provides advice for provisioning processes, and TLS stack implementation support in the
applications in various use cases to help meet these assumptions. context of these assumptions. It provides advice for applications in
Privacy and security properties not provided by PSKs are also various use cases to help meet these assumptions. It also lists the
included. privacy and security properties that are not provided by TLS when
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 6 May 2021. This Internet-Draft will expire on 24 August 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the 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 4.1. Shared PSKs . . . . . . . . . . . . . . . . . . . . . . . 4
6. External PSK Use Cases and Provisioning Processes . . . . . . 5 4.2. PSK Entropy . . . . . . . . . . . . . . . . . . . . . . . 5
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
6. External PSK Use Cases and Provisioning Processes . . . . . . 6
6.1. Provisioning Examples . . . . . . . . . . . . . . . . . . 7 6.1. Provisioning Examples . . . . . . . . . . . . . . . . . . 7
6.2. Provisioning Constraints . . . . . . . . . . . . . . . . 7 6.2. Provisioning Constraints . . . . . . . . . . . . . . . . 8
7. Recommendations for External PSK Usage . . . . . . . . . . . 7 7. Recommendations for External PSK Usage . . . . . . . . . . . 8
7.1. Stack Interfaces . . . . . . . . . . . . . . . . . . . . 8 7.1. Stack Interfaces . . . . . . . . . . . . . . . . . . . . 9
7.1.1. PSK Identity Encoding and Comparison . . . . . . . . 9 7.1.1. PSK Identity Encoding and Comparison . . . . . . . . 10
7.1.2. PSK Identity Collisions . . . . . . . . . . . . . . . 10 7.1.2. PSK Identity Collisions . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 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
Keys (PSKs) in Transport Layer Security (TLS) version 1.3 [RFC8446].
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. It lists TLS (PSKs) in TLS. This document aims to reduce that gap.
security properties provided by PSKs under certain assumptions and
demonstrates how violations of these assumptions lead to attacks.
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.ietf-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
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 External PSK authentication in TLS allows endpoints to authenticate
connections using previously established keys. These keys do not connections using previously established keys. These keys do not
provide protection of endpoint identities (see Section 5), nor do provide protection of endpoint identities (see Section 5), nor do
they provide non-repudiation (one endpoint in a connection can deny they provide non-repudiation (one endpoint in a connection can deny
the conversation). PSK authentication security implicitly assumes the conversation). Protection of endpoint identities and protection
one fundamental property: each PSK is known to exactly one client and against an endpoint denying the conversation are possible when a
one server, and that these never switch roles. If this assumption is fresh TLS handshake is performed.
violated, then the security properties of TLS are severely weakened.
PSK authentication security implicitly assumes one fundamental
property: each PSK is known to exactly one client and one server, and
that these never switch roles. If this assumption is violated, then
the security properties of TLS are severely weakened as discussed
below.
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 only done naively by having all members share a common key, then TLS
authenticates the entire group, 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 with DH is used, then compromise of a group member that
actively completes connections with other group members can read actively completes connections with other group members can read
(and modify) traffic. (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 (and modify) all traffic. allows the attacker to passively read (and modify) all traffic.
4. If a group member is compromised, then the attacker can perform 4. If a group member is compromised, then the attacker can perform
all of the above attacks. all of the above attacks.
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 below. Note that this class of attack is not possible if each member
member uses the SNI extension [RFC6066] and terminates the connection uses the SNI extension [RFC6066] and terminates the connection on
on mismatch. See [Selfie] for details.) Let the group of peers who mismatch. See [Selfie] for details.
know the key be "A", "B", and "C". The attack proceeds as follows:
To illustrate the rerouting attack, consider the group of peers who
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 "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".
skipping to change at page 4, line 40 skipping to change at page 5, line 15
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 Finally, in addition to these weaknesses, sharing a PSK across nodes
may negatively affects deployments. For example, revocation of may negatively affect deployments. For example, revocation of
individual group members is not possible without changing the individual group members is not possible without changing
authentication key for all members. establishing a new PSK for all of the non-revoked members.
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 a standard PAKE (see
[I-D.irtf-cfrg-cpace] and [I-D.irtf-cfrg-opaque]). [I-D.irtf-cfrg-cpace] and [I-D.irtf-cfrg-opaque]).
5. Privacy Properties 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. 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. Depending on the PSK identity, a passive external PSK on the wire. Depending on the PSK identity, a passive
attacker may also be able to identify the device, person, or attacker may also be able to identify the device, person, or
enterprise running the TLS client or TLS server. An active attacker enterprise running the TLS client or TLS server. An active attacker
can also use the PSK identity to oppress handshakes or application can also use the PSK identity to suppress handshakes or application
data from a specific device by blocking, delaying, or rate-limiting data from a specific device by blocking, delaying, or rate-limiting
traffic. Techniques for mitigating these risks require analysis and traffic. Techniques for mitigating these risks require 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
skipping to change at page 7, line 6 skipping to change at page 7, line 30
* Internet of Things (IoT) and devices with limited computational * Internet of Things (IoT) and devices with limited computational
capabilities. Many PSK provisioning examples are possible in this capabilities. Many PSK provisioning examples are possible in this
use-case. For example, in a given setting, IoT devices may all use-case. For example, in a given setting, IoT devices may all
share the same PSK and use it to communicate with a central server share the same PSK and use it to communicate with a central server
(one key for n devices), have their own key for communicating with (one key for n devices), have their own key for communicating with
a central server (n keys for n devices), or have pairwise keys for a central server (n keys for n devices), or have pairwise keys for
communicating with each other (n^2 keys for n devices). communicating with each other (n^2 keys for n devices).
The exact provisioning process depends on the system requirements and The exact provisioning process depends on the system requirements and
threat model. Generally, use of a single PSK shared between more threat model. Whenever possible, avoid sharing a PSK between nodes;
than one node is not recommended, even if other accommodations are however, sharing a PSK among several node is sometimes unavoidable.
made, such as client certificate authentication after PSK-based When PSK sharing happens, other accommodations SHOULD be used as
connection establishment. See 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 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
skipping to change at page 8, line 33 skipping to change at page 9, line 15
3. Nodes using TLS 1.3 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
client-server pair. Importers make provisioning external PSKs client-server pair. Importers make provisioning external PSKs
easier and less error prone by deriving a unique, imported PSK easier and less error prone by deriving a unique, imported PSK
from the external PSK for each key derivation function a node from the external PSK for each key derivation function a node
supports. See the Security Considerations in 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 protects 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 supplying them for individual connections. Details about when configuring PSKs 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 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 9, line 35 skipping to change at page 10, line 13
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. When PSK identites 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). [RFC8446] also requires
that the PSK identities are at least 1 byte and at the most 65535 that the PSK identities are at least 1 byte and at the most 65535
bytes in length. Although [RFC8446] does not place strict bytes in length. Although [RFC8446] does not place strict
requirements on the format of PSK identities, we do however note that requirements on the format of PSK identities, we do however note that
the format of PSK identities can vary depending on the deployment: 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. In applications and settings where the domain name
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
is sufficient to avoid 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 behavior
behaviour when identity collisions occur. When a server receives a when identity collisions occur. When a server receives a PSK
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 will be given precedence
over how to handle the PSK. over how to handle the PSK.
8. Security Considerations 8. Security Considerations
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
skipping to change at page 11, line 9 skipping to change at page 11, line 37
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] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-38, 29 May 2020, <http://www.ietf.org/internet- dtls13-41, 7 February 2021, <https://www.ietf.org/
drafts/draft-ietf-tls-dtls13-38.txt>. 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. 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-05, 19 May 2020, external-psk-importer-06, 3 December 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-tls- <https://www.ietf.org/internet-drafts/draft-ietf-tls-
external-psk-importer-05.txt>. external-psk-importer-06.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) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
skipping to change at page 12, line 8 skipping to change at page 12, line 33
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, <http://www.ietf.org/internet- ctls-01, 2 November 2020, <https://www.ietf.org/internet-
drafts/draft-ietf-tls-ctls-01.txt>. drafts/draft-ietf-tls-ctls-01.txt>.
[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-00, 28 July 2020, <http://www.ietf.org/ irtf-cfrg-cpace-01, 24 January 2021,
internet-drafts/draft-irtf-cfrg-cpace-00.txt>. <https://www.ietf.org/internet-drafts/draft-irtf-cfrg-
cpace-01.txt>.
[I-D.irtf-cfrg-opaque] [I-D.irtf-cfrg-opaque]
Krawczyk, H., Lewi, K., and C. Wood, "The OPAQUE Krawczyk, H., Lewi, K., and C. A. Wood, "The OPAQUE
Asymmetric PAKE Protocol", Work in Progress, Internet- Asymmetric PAKE Protocol", Work in Progress, Internet-
Draft, draft-irtf-cfrg-opaque-00, 28 September 2020, Draft, draft-irtf-cfrg-opaque-02, 5 February 2021,
<http://www.ietf.org/internet-drafts/draft-irtf-cfrg- <https://www.ietf.org/internet-drafts/draft-irtf-cfrg-
opaque-00.txt>. opaque-02.txt>.
[I-D.mattsson-emu-eap-tls-psk] [I-D.mattsson-emu-eap-tls-psk]
Mattsson, J., Sethi, M., Aura, T., and O. Friel, "EAP-TLS Mattsson, J. P., Sethi, M., Aura, T., and O. Friel, "EAP-
with PSK Authentication (EAP-TLS-PSK)", Work in Progress, TLS with PSK Authentication (EAP-TLS-PSK)", Work in
Internet-Draft, draft-mattsson-emu-eap-tls-psk-00, 9 March Progress, Internet-Draft, draft-mattsson-emu-eap-tls-psk-
2020, <http://www.ietf.org/internet-drafts/draft-mattsson- 00, 9 March 2020, <https://www.ietf.org/internet-drafts/
emu-eap-tls-psk-00.txt>. draft-mattsson-emu-eap-tls-psk-00.txt>.
[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.,
 End of changes. 32 change blocks. 
78 lines changed or deleted 97 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/