rfc9257.original   rfc9257.txt 
tls R. Housley Internet Engineering Task Force (IETF) R. Housley
Internet-Draft Vigil Security Request for Comments: 9257 Vigil Security
Intended status: Informational J. Hoyland Category: Informational J. Hoyland
Expires: 8 August 2022 Cloudflare Ltd. ISSN: 2070-1721 Cloudflare Ltd.
M. Sethi M. Sethi
Ericsson Aalto University
C.A. Wood C. A. Wood
Cloudflare Cloudflare
4 February 2022 July 2022
Guidance for External PSK Usage in TLS Guidance for External Pre-Shared Key (PSK) Usage in TLS
draft-ietf-tls-external-psk-guidance-06
Abstract Abstract
This document provides usage guidance for external Pre-Shared Keys This document provides usage guidance for external Pre-Shared Keys
(PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
It lists TLS security properties provided by PSKs under certain It lists TLS security properties provided by PSKs under certain
assumptions, and then demonstrates how violations of these assumptions, then it demonstrates how violations of these assumptions
assumptions lead to attacks. Advice for applications to help meet lead to attacks. Advice for applications to help meet these
these assumptions is provided. This document also discusses PSK use assumptions is provided. This document also discusses PSK use cases
cases and provisioning processes. Finally, it lists the privacy and and provisioning processes. Finally, it lists the privacy and
security properties that are not provided by TLS 1.3 when external security properties that are not provided by TLS 1.3 when external
PSKs are used. PSKs are used.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
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 document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9257.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions
3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Notation
4. PSK Security Properties . . . . . . . . . . . . . . . . . . . 4 4. PSK Security Properties
4.1. Shared PSKs . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Shared PSKs
4.2. PSK Entropy . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. PSK Entropy
5. External PSKs in Practice . . . . . . . . . . . . . . . . . . 6 5. External PSKs in Practice
5.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Use Cases
5.2. Provisioning Examples . . . . . . . . . . . . . . . . . . 7 5.2. Provisioning Examples
5.3. Provisioning Constraints . . . . . . . . . . . . . . . . 8 5.3. Provisioning Constraints
6. Recommendations for External PSK Usage . . . . . . . . . . . 8 6. Recommendations for External PSK Usage
6.1. Stack Interfaces . . . . . . . . . . . . . . . . . . . . 9 6.1. Stack Interfaces
6.1.1. PSK Identity Encoding and Comparison . . . . . . . . 10 6.1.1. PSK Identity Encoding and Comparison
6.1.2. PSK Identity Collisions . . . . . . . . . . . . . . . 10 6.1.2. PSK Identity Collisions
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 7. Privacy Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses
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) 1.3 [RFC8446]. This Keys (PSKs) in Transport Layer Security (TLS) 1.3 [RFC8446]. This
guidance also applies to Datagram TLS (DTLS) 1.3 guidance also applies to Datagram TLS (DTLS) 1.3 [RFC9147] and
[I-D.ietf-tls-dtls13] and Compact TLS 1.3 [I-D.ietf-tls-ctls]. For Compact TLS 1.3 [CTLS]. For readability, this document uses the term
readability, this document uses the term TLS to refer to all such "TLS" to refer to all such versions.
versions.
External PSKs are symmetric secret keys provided to the TLS protocol External PSKs are symmetric secret keys provided to the TLS protocol
implementation as external inputs. External PSKs are provisioned implementation as external inputs. External PSKs are provisioned out
out-of-band. of band.
This document 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 demonstrates how violations of these
assumptions lead to attacks. This document discusses PSK use cases, assumptions lead to attacks. This document discusses PSK use cases,
provisioning processes, and TLS stack implementation support in the provisioning processes, and TLS stack implementation support in the
context of these assumptions. This document also provides advice for context of these assumptions. This document also provides advice for
applications in various use cases to help meet these assumptions. 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 PSKs in TLS. This
(PSKs) in TLS. This document aims to reduce that gap. document aims to reduce that gap.
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
skipping to change at page 4, line 9 skipping to change at line 127
presence that other parties can interact with via the TLS protocol. presence that other parties can interact with via the TLS protocol.
A logical node could potentially be realized with multiple physical A logical node could potentially be realized with multiple physical
instances operating under common administrative control, e.g., a instances operating under common administrative control, e.g., a
server farm. An "endpoint" is a client or server participating in a server farm. An "endpoint" is a client or server participating in a
connection. connection.
4. PSK Security Properties 4. PSK Security Properties
The use of a previously established PSK allows TLS nodes to The use of a previously established PSK allows TLS nodes to
authenticate the endpoint identities. It also offers other benefits, authenticate the endpoint identities. It also offers other benefits,
including resistance to attacks in presence of quantum computers; see including resistance to attacks in the presence of quantum computers;
Section 4.2 for related discussion. However, these keys do not see Section 4.2 for related discussion. However, these keys do not
provide privacy protection of endpoint identities, nor do they provide privacy protection of endpoint identities, nor do they
provide non-repudiation (one endpoint in a connection can deny the provide non-repudiation (one endpoint in a connection can deny the
conversation); see Section 7 for related discussion. conversation); see Section 7 for related discussion.
PSK authentication security implicitly assumes one fundamental PSK authentication security implicitly assumes one fundamental
property: each PSK is known to exactly one client and one server, and property: each PSK is known to exactly one client and one server and
that these never switch roles. If this assumption is violated, then they never switch roles. If this assumption is violated, then the
the security properties of TLS are severely weakened as discussed security properties of TLS are severely weakened as discussed below.
below.
4.1. Shared PSKs 4.1. Shared PSKs
As discussed in Section 5.1, to demonstrate their attack, [AASS19] As discussed in Section 5.1, to demonstrate their attack, [AASS19]
describes scenarios where multiple clients or multiple servers share describes scenarios where multiple clients or multiple servers share
a PSK. If this is done naively by having all members share a common a PSK. If this is done naively by having all members share a common
key, then TLS authenticates only group membership, and the security key, then TLS authenticates only group membership, and the security
of the overall system is inherently rather brittle. There are a of the overall system is inherently rather brittle. There are a
number of obvious weaknesses here: number of obvious 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 is combined with a fresh ephemeral key exchange, then 2. If a PSK is combined with the result of a fresh ephemeral key
compromise of a group member that knows the resulting shared exchange, then compromise of a group member that knows the
secret will enable the attacker to passively read (and actively resulting shared secret will enable the attacker to passively
modify) traffic. read traffic (and actively modify it).
3. If PSK is not combined with fresh ephemeral key exchange, then 3. If a PSK is not combined with the result of a fresh ephemeral key
compromise of any group member allows the attacker to passively exchange, then compromise of any group member allows the attacker
read (and actively modify) all traffic, including reading past to passively read all traffic (and actively modify it), including
traffic. past traffic.
Additionally, a malicious non-member can reroute handshakes between Additionally, a malicious non-member can reroute handshakes between
honest group members to connect them in unintended ways, as described honest group members to connect them in unintended ways, as described
below. Note that a partial mitigation against this class of attack below. Note that a partial mitigation for this class of attack is
is available: each group member includes the SNI extension [RFC6066] available: each group member includes the Server Name Indication
and terminates the connection on mismatch between the presented SNI (SNI) extension [RFC6066] and terminates the connection on mismatch
value and the receiving member's known identity. See [Selfie] for between the presented SNI value and the receiving member's known
details. identity. See [Selfie] for details.
To illustrate the rerouting attack, consider three peers, A, B, and To illustrate the rerouting attack, consider three peers, A, B, and
C, who all know the PSK. The attack proceeds as follows: C, who all know the PSK. The attack proceeds as follows:
1. A sends a ClientHello to B. 1. A sends a ClientHello to B.
2. The attacker intercepts the message and redirects it to C. 2. The attacker intercepts the message and redirects it to C.
3. C responds with a second flight (ServerHello, ...) to A. 3. C responds with a second flight (ServerHello, ...) to A.
4. A sends a Finished message to B. A has completed the handshake, 4. A sends a Finished message to B. A has completed the handshake,
ostensibly with B. ostensibly with B.
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.
In this attack, peer authentication is not provided. Also, if C In this attack, peer authentication is not provided. Also, if C
supports a weaker set of cipher suites than B, cryptographic supports a weaker set of ciphersuites than B, cryptographic algorithm
algorithm downgrade attacks might be possible. This rerouting is a downgrade attacks might be possible. This rerouting is a type of
type of identity misbinding attack [Krawczyk][Sethi]. Selfie attack 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 as both a TLS server and a 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 establishing a new individual group members is not possible without establishing a new
PSK for all of the non-revoked members. PSK for all of the members that have not been revoked.
4.2. PSK Entropy 4.2. PSK Entropy
Entropy properties of external PSKs may also affect TLS security Entropy properties of external PSKs may also affect TLS security
properties. For example, if a high entropy PSK is used, then PSK- properties. For example, if a high-entropy PSK is used, then PSK-
only key establishment modes provide expected security properties for only key establishment modes provide expected security properties for
TLS, including establishing the same session keys between peers, TLS, including establishment of the same session keys between peers,
secrecy of session keys, peer authentication, and downgrade secrecy of session keys, peer authentication, and downgrade
protection. See [RFC8446], Appendix E.1 for an explanation of these protection. See Appendix E.1 of [RFC8446] for an explanation of
properties. However, these modes lack forward security. Forward these properties. However, these modes lack forward security.
security may be achieved by using a PSK-DH mode, or, alternatively, Forward security may be achieved by using a PSK-DH mode or by using
by using PSKs with short lifetimes. PSKs with short lifetimes.
In contrast, if a low entropy PSK is used, then PSK-only key In contrast, if a low-entropy PSK is used, then PSK-only key
establishment modes are subject to passive exhaustive search attacks establishment modes are subject to passive exhaustive search attacks,
which will reveal the traffic keys. PSK-DH modes are subject to which will reveal the traffic keys. PSK-DH modes are subject to
active attacks in which the attacker impersonates one side. The active attacks in which the attacker impersonates one side. The
exhaustive search phase of these attacks can be mounted offline if exhaustive search phase of these attacks can be mounted offline if
the attacker captures a single handshake using the PSK, but those the attacker captures a single handshake using the PSK, but those
attacks will not lead to compromise of the traffic keys for that attacks will not lead to compromise of the traffic keys for that
connection because those also depend on the Diffie-Hellman (DH) connection because those also depend on the Diffie-Hellman (DH)
exchange. Low entropy keys are only secure against active attack if exchange. Low-entropy keys are only secure against active attack if
a password-authenticated key exchange (PAKE) is used with TLS. The a Password-Authenticated Key Exchange (PAKE) is used with TLS. At
Crypto Forum Research Group (CFRG) is currently working on specifying the time of writing, the Crypto Forum Research Group (CFRG) is
recommended PAKEs (see [I-D.irtf-cfrg-cpace] and working on specifying recommended PAKEs (see [CPACE] and [OPAQUE] for
[I-D.irtf-cfrg-opaque], for the symmetric and asymmetric cases, the symmetric and asymmetric cases, respectively).
respectively).
5. External PSKs in Practice 5. External PSKs in Practice
PSK ciphersuites were first specified for TLS in 2005. PSKs are now PSK ciphersuites were first specified for TLS in 2005. PSKs are now
an integral part of the TLS version 1.3 specification [RFC8446]. TLS an integral part of the TLS 1.3 specification [RFC8446]. TLS 1.3
1.3 also uses PSKs for session resumption. It distinguishes these also uses PSKs for session resumption. It distinguishes these
resumption PSKs from external PSKs which have been provisioned out- resumption PSKs from external PSKs that have been provisioned out of
of-band. This section describes known use cases and provisioning band. This section describes known use cases and provisioning
processes for external PSKs with TLS. processes for external PSKs with TLS.
5.1. Use Cases 5.1. Use Cases
This section lists some example use-cases where pair-wise external This section lists some example use cases where pairwise external
PSKs, i.e., external PSKs that are shared between only one server and PSKs (i.e., external PSKs that are shared between only one server and
one client, have been used for authentication in TLS. There was no one client) have been used for authentication in TLS. There was no
attempt to prioritize the examples in any particular order. attempt to prioritize the examples in any particular order.
* Device-to-device communication with out-of-band synchronized keys. * Device-to-device communication with out-of-band synchronized keys.
PSKs provisioned out-of-band for communicating with known PSKs provisioned out of band for communicating with known
identities, wherein the identity to use is discovered via a identities, wherein the identity to use is discovered via a
different online protocol. different online protocol.
* Intra-data-center communication. Machine-to-machine communication * Intra-data-center communication. Machine-to-machine communication
within a single data center or point-of-presence (PoP) may use within a single data center or Point of Presence (PoP) may use
externally provisioned PSKs, primarily for the purposes of externally provisioned PSKs; this is primarily for the purpose of
supporting TLS connections with early data; see Section 8 for supporting TLS connections with early data. See Section 8 for
considerations when using early data with external PSKs. considerations when using early data with external PSKs.
* Certificateless server-to-server communication. Machine-to- * Certificateless server-to-server communication. Machine-to-
machine communication may use externally provisioned PSKs, machine communication may use externally provisioned PSKs; this is
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
ciphersuites for compliant devices. The Open Mobile Alliance ciphersuites for compliant devices. The Open Mobile Alliance
Lightweight Machine to Machine Technical Specification [LwM2M] Lightweight Machine-to-Machine (LwM2M) Technical Specification
states that LwM2M servers MUST support the PSK mode of DTLS. [LwM2M] states that LwM2M servers MUST support the PSK mode of
DTLS.
* Securing RADIUS [RFC2865] with TLS. PSK ciphersuites are optional * Securing RADIUS [RFC2865] with TLS. PSK ciphersuites are optional
for this use case, as specified in [RFC6614]. for this use case, as specified in [RFC6614].
* 3GPP server to user equipment authentication. The Generic * 3GPP server-to-user equipment authentication. The Generic
Authentication Architecture (GAA) defined by 3GGP mentions that Authentication Architecture (GAA) defined by 3GPP mentions that
TLS-PSK ciphersuites can be used between server and user equipment TLS PSK ciphersuites can be used between server and user equipment
for authentication [GAA]. for authentication [GAA].
* Smart Cards. The electronic German ID (eID) card supports * Smart Cards. The German electronic Identity (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 * Quantum resistance. Some deployments may use PSKs (or combine
them with certificate-based authentication as described in them with certificate-based authentication as described in
[RFC8773]) because of the protection they provide against quantum [RFC8773]) because of the protection they provide against quantum
computers. 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 al. entities. Some examples below (as noted by Akhmetzyanova, et al.
[AASS19]): [AASS19]):
* Group chats. In this use-case, group participants may be * Group chats. In this use case, group participants may be
provisioned an external PSK out-of-band for establishing provisioned an external PSK out of band for establishing
authenticated connections with other members of the group. authenticated connections with other members of the group.
* Internet of Things (IoT) and devices with limited computational * IoT and devices with limited computational capabilities. Many PSK
capabilities. Many PSK provisioning examples are possible in this provisioning examples are possible in this use case. For example,
use-case. For example, in a given setting, IoT devices may all in a given setting, IoT devices may all share the same PSK and use
share the same PSK and use it to communicate with a central server it to communicate with a central server (one key for n devices),
(one key for n devices), have their own key for communicating with have their own key for communicating with a central server (n keys
a central server (n keys for n devices), or have pairwise keys for for n devices), or have pairwise keys for communicating with each
communicating with each other (n^2 keys for n devices). other (n^2 keys for n devices).
5.2. Provisioning Examples 5.2. Provisioning Examples
The exact provisioning process depends on the system requirements and The exact provisioning process depends on the system requirements and
threat model. Whenever possible, avoid sharing a PSK between nodes; threat model. Whenever possible, avoid sharing a PSK between nodes;
however, sharing a PSK among several nodes is sometimes unavoidable. however, sharing a PSK among several nodes is sometimes unavoidable.
When PSK sharing happens, other accommodations SHOULD be used as When PSK sharing happens, other accommodations SHOULD be used as
discussed in Section 6. discussed in Section 6.
Examples of PSK provisioning processes are included below. Examples of PSK provisioning processes are included below.
* Many industrial protocols assume that PSKs are distributed and * Many industrial protocols assume that PSKs are distributed and
assigned manually via one of the following approaches: typing the assigned manually via one of the following approaches: (1) typing
PSK into the devices, or using a Trust On First Use (TOFU) the PSK into the devices or (2) using a trust-on-first-use (TOFU)
approach with a device completely unprotected before the first approach with a device completely unprotected before the first
login did take place. Many devices have very limited UI. For login took place. Many devices have a very limited UI. For
example, they may only have a numeric keypad or even fewer example, they may only have a numeric keypad or even fewer
buttons. When the TOFU approach is not suitable, entering the key buttons. When the TOFU approach is not suitable, entering the key
would require typing it on a constrained UI. would require typing it on a constrained UI.
* Some devices provision PSKs via an out-of-band, cloud-based * Some devices provision PSKs via an out-of-band, cloud-based
syncing protocol. syncing protocol.
* Some secrets may be baked into hardware or software device * Some secrets may be baked into hardware or software device
components. Moreover, when this is done at manufacturing time, components. Moreover, when this is done at manufacturing time,
secrets may be printed on labels or included in a Bill of secrets may be printed on labels or included in a Bill of
Materials for ease of scanning or import. Materials for ease of scanning or import.
5.3. Provisioning Constraints 5.3. Provisioning Constraints
PSK provisioning systems are often constrained in application- PSK provisioning systems are often constrained in application-
specific ways. For example, although one goal of provisioning is to specific ways. For example, although one goal of provisioning is to
ensure that each pair of nodes has a unique key pair, some systems do ensure that each pair of nodes has a unique key pair, some systems do
not want to distribute pair-wise shared keys to achieve this. As not want to distribute pairwise 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].
6. Recommendations for External PSK Usage 6. Recommendations for External PSK Usage
Recommended requirements for applications using external PSKs are as Recommended requirements for applications using external PSKs are as
follows: follows:
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 an MUST be at least 128 bits long, and SHOULD be combined with an
ephemeral key exchange, e.g., by using the "psk_dhe_ke" Pre- ephemeral key exchange, e.g., by using the "psk_dhe_ke" Pre-
Shared Key Exchange Mode in TLS 1.3, for forward secrecy. As Shared Key Exchange Mode in TLS 1.3 for forward secrecy. As
discussed in Section 4, low entropy PSKs, i.e., those derived discussed in Section 4, low-entropy PSKs (i.e., those derived
from less than 128 bits of entropy, are subject to attack and from less than 128 bits of entropy) are subject to attack and
SHOULD be avoided. If only low-entropy keys are available, then SHOULD be avoided. If only low-entropy keys are available, then
key establishment mechanisms such as Password Authenticated Key key establishment mechanisms such as PAKE that mitigate the risk
Exchange (PAKE) that mitigate the risk of offline dictionary of offline dictionary attacks SHOULD be employed. Note that no
attacks SHOULD be employed. Note that no such mechanisms have such mechanisms have yet been standardized, and further that
yet been standardised, and further that these mechanisms will not these mechanisms will not necessarily follow the same
necessarily follow the same architecture as the process for architecture as the process for incorporating external PSKs
incorporating external PSKs described in described in [RFC9258].
[I-D.ietf-tls-external-psk-importer].
2. Unless other accommodations are made to mitigate the risks of 2. Unless other accommodations are made to mitigate the risks of
PSKs known to a group, each PSK MUST be restricted in its use to PSKs known to a group, each PSK MUST be restricted in its use to
at most two logical nodes: one logical node in a TLS client role at most two logical nodes: one logical node in a TLS client role
and one logical node in a TLS server role. (The two logical and one logical node in a TLS server role. (The two logical
nodes MAY be the same, in different roles.) Two acceptable nodes MAY be the same, in different roles.) Two acceptable
accommodations are described in accommodations are described in [RFC9258]: (1) exchanging client
[I-D.ietf-tls-external-psk-importer]: (1) exchanging client and and server identifiers over the TLS connection after the
server identifiers over the TLS connection after the handshake, handshake and (2) incorporating identifiers for both the client
and (2) incorporating identifiers for both the client and the and the server into the context string for an external PSK
server into the context string for an external PSK importer. importer.
3. Nodes SHOULD use external PSK importers 3. Nodes SHOULD use external PSK importers [RFC9258] when
[I-D.ietf-tls-external-psk-importer] when configuring PSKs for a configuring PSKs for a client-server pair when applicable.
client-server pair when applicable. Importers make provisioning Importers make provisioning external PSKs easier and less error-
external PSKs easier and less error prone by deriving a unique, prone by deriving a unique, imported PSK from the external PSK
imported PSK from the external PSK for each key derivation for each key derivation function a node supports. See the
function a node supports. See the Security Considerations in Security Considerations of [RFC9258] 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
SHOULD be deleted after the imported keys have been generated. importer) SHOULD be deleted after the imported keys have been
This prevents an attacker from bootstrapping a compromise of one generated. This prevents an attacker from bootstrapping a
node into the ability to attack connections between any node; compromise of one node into the ability to attack connections
otherwise the attacker can recover the main key and then re-run between any node; otherwise, the attacker can recover the main
the importer itself. key and then re-run the importer itself.
6.1. Stack Interfaces 6.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 some 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 Also, they can 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 (inclusive).
identity may be up to 128 bytes long. The PSK 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
(inclusive).
* gnuTLS: Applications configure PSK values, either as raw byte * gnuTLS: Applications configure PSK values as either 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.
* wolfSSL: Applications configure PSKs with callbacks similar to * wolfSSL: Applications configure PSKs with callbacks similar to
OpenSSL. OpenSSL.
6.1.1. PSK Identity Encoding and Comparison 6.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 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 visually identical strings
visually identical strings may, in fact, differ. may, in fact, differ due to encoding issues.
TLS version 1.3 [RFC8446] follows the same practice of specifying the TLS 1.3 [RFC8446] follows the same practice of specifying the PSK
PSK identity as a sequence of opaque bytes (shown as opaque identity as a sequence of opaque bytes (shown as opaque
identity<1..2^16-1> in the specification) that thus is compared on a identity<1..2^16-1> in the specification) that thus is compared on a
byte-by-byte basis. [RFC8446] also requires that the PSK identities byte-by-byte basis. [RFC8446] also requires that the PSK identities
are at least 1 byte and at the most 65535 bytes in length. Although 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 [RFC8446] does not place strict requirements on the format of PSK
identities, we do however note that the format of PSK identities can identities, note that the format of PSK identities can vary depending
vary depending on the deployment: 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. For example, gnuTLS 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
is sufficient to avoid collisions. is sufficient to avoid collisions.
6.1.2. PSK Identity Collisions 6.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's external PSK usage will identity collision occurs, the application's external PSK usage will
typically take precedence over the internal session resumption path. typically take precedence over the internal session resumption path.
Since resumption PSK identities are assigned by the TLS stack Because resumption PSK identities are assigned by the TLS stack
implementation, it is RECOMMENDED that these identifiers be assigned implementation, it is RECOMMENDED that these identifiers be assigned
in a manner that lets resumption PSKs be distinguished from external in a manner that lets resumption PSKs be distinguished from external
PSKs to avoid concerns with collisions altogether. PSKs to avoid concerns with collisions altogether.
7. Privacy Considerations 7. Privacy Considerations
PSK privacy properties are orthogonal to security properties PSK privacy properties are orthogonal to security properties
described in Section 4. TLS does little to keep PSK identity described in Section 4. TLS does little to keep PSK identity
information private. For example, an adversary learns information information private. For example, an adversary learns information
about the external PSK or its identifier by virtue of the identifier about the external PSK or its identifier by virtue of the identifier
skipping to change at page 12, line 8 skipping to change at line 488
8. Security Considerations 8. Security Considerations
Security considerations are provided throughout this document. It Security considerations are provided throughout this document. It
bears repeating that there are concerns related to the use of bears repeating that there are concerns related to the use of
external PSKs regarding proper identification of TLS 1.3 endpoints external PSKs regarding proper identification of TLS 1.3 endpoints
and additional risks when external PSKs are known to a group. 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 5.1, there are client and server. However, as discussed in Section 5.1, 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. [RFC9258] helps in mitigating rerouting and Selfie-
mitigating rerouting and Selfie style reflection attacks when the PSK style reflection attacks when the PSK is shared among multiple nodes.
is shared among multiple nodes. This is achieved by correctly using This is achieved by correctly using the node identifiers in the
the node identifiers in the ImportedIdentity.context construct ImportedIdentity.context construct specified in [RFC9258]. One
specified in [I-D.ietf-tls-external-psk-importer]. One solution solution would be for each endpoint to select one globally unique
would be for each endpoint to select one globally unique identifier identifier to use in all PSK handshakes. The unique identifier can,
and use it in all PSK handshakes. The unique identifier can, for for example, be one of its Media Access Control (MAC) addresses, a
example, be one of its MAC addresses, a 32-byte random number, or its 32-byte random number, or its Universally Unique IDentifier (UUID)
Universally Unique IDentifier (UUID) [RFC4122]. Note that such [RFC4122]. Note that such persistent, global identifiers have
persistent, global identifiers have privacy implications; see privacy implications; see Section 7.
Section 7.
Each endpoint SHOULD know the identifier of the other endpoint with Each endpoint SHOULD know the identifier of the other endpoint with
which it wants to connect and SHOULD compare it with the other which it wants to connect and SHOULD compare it with the other
endpoint's identifier used in ImportedIdentity.context. It is endpoint's identifier used in ImportedIdentity.context. However, it
however important to remember that endpoints sharing the same group is important to remember that endpoints sharing the same group PSK
PSK can always impersonate each other. can always impersonate each other.
Considerations for external PSK usage extend beyond proper Considerations for external PSK usage extend beyond proper
identification. When early data is used with an external PSK, the identification. When early data is used with an external PSK, the
random value in the ClientHello is the only source of entropy that random value in the ClientHello is the only source of entropy that
contributes to key diversity between sessions. As a result, when an contributes to key diversity between sessions. As a result, when an
external PSK is used more than one time, the random number source on external PSK is used more than one time, the random number source on
the client has a significant role in the protection of the early the client has a significant role in the protection of the early
data. data.
9. IANA Considerations 9. IANA Considerations
This document makes no IANA requests. This document has no IANA actions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-tls-external-psk-importer]
Benjamin, D. and C. A. Wood, "Importing External PSKs for
TLS", Work in Progress, Internet-Draft, draft-ietf-tls-
external-psk-importer-06, 3 December 2020,
<https://www.ietf.org/archive/id/draft-ietf-tls-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>.
[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>.
[RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre-
Shared Keys (PSKs) for TLS 1.3", RFC 9258,
DOI 10.17487/RFC9258, July 2022,
<https://www.rfc-editor.org/info/rfc9258>.
10.2. Informative References 10.2. Informative References
[AASS19] Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A. [AASS19] 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", April 2019, <https://eprint.iacr.org/2019/421.pdf>.
[GAA] "TR33.919 version 12.0.0 Release 12", n.d.,
<https://www.etsi.org/deliver/
etsi_tr/133900_133999/133919/12.00.00_60/
tr_133919v120000p.pdf>.
[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-04, 25 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-ctls-
04.txt>.
[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://www.ietf.org/archive/id/draft-ietf-tls-
dtls13-43.txt>.
[I-D.irtf-cfrg-cpace] [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-05, 14 January 2022, irtf-cfrg-cpace-06, 24 July 2022,
<https://www.ietf.org/archive/id/draft-irtf-cfrg-cpace- <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
05.txt>. cpace-06>.
[I-D.irtf-cfrg-opaque] [CTLS] Rescorla, E., Barnes, R., Tschofenig, H., and B. M.
Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The Schwartz, "Compact TLS 1.3", Work in Progress, Internet-
OPAQUE Asymmetric PAKE Protocol", Work in Progress, Draft, draft-ietf-tls-ctls-06, 9 July 2022,
Internet-Draft, draft-irtf-cfrg-opaque-07, 25 October <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
2021, <https://www.ietf.org/archive/id/draft-irtf-cfrg- ctls-06>.
opaque-07.txt>.
[I-D.mattsson-emu-eap-tls-psk] [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/archive/id/draft- 00, 9 March 2020, <https://datatracker.ietf.org/doc/html/
mattsson-emu-eap-tls-psk-00.txt>. draft-mattsson-emu-eap-tls-psk-00>.
[GAA] ETSI, "Digital cellular telecommunications system (Phase
2+); Universal Mobile Telecommunications System (UMTS);
LTE; 3G Security; Generic Authentication Architecture
(GAA); System description", version 12.0.0, ETSI TR 133
919, October 2014, <https://www.etsi.org/deliver/
etsi_tr/133900_133999/133919/12.00.00_60/
tr_133919v120000p.pdf>.
[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", DOI 10.1007/978-3-540-45146-4_24, 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] Open Mobile Alliance, "Lightweight Machine to Machine
n.d., Technical Specification", version 1.0, February 2017,
<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>.
[OPAQUE] Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The
OPAQUE Asymmetric PAKE Protocol", Work in Progress,
Internet-Draft, draft-irtf-cfrg-opaque-09, 6 July 2022,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
opaque-09>.
[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/info/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/info/rfc3748>.
skipping to change at page 15, line 21 skipping to change at line 631
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 [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/info/rfc8773>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[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", DOI 10.1007/s00145-021-09387-y, May 2021,
<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",
of the 2019 ACM Asia Conference on Computer and DOI 10.1145/3321705.3329813, May 2019,
Communications Security , 2019,
<https://arxiv.org/pdf/1902.07550>. <https://arxiv.org/pdf/1902.07550>.
[SmartCard] [SmartCard]
Bundesamt für Sicherheit in der Informationstechnik,
"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", version 1.1.5, April 2015, <https://www.bsi.bu
loads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03112/ nd.de/SharedDocs/Downloads/DE/BSI/Publikationen/
TR-03112-api_teil7.pdf?__blob=publicationFile&v=1>. TechnischeRichtlinien/TR03112/TR-
03112-api_teil7.pdf?__blob=publicationFile&v=1>.
Appendix A. Acknowledgements Acknowledgements
This document is the output of the TLS External PSK Design Team, This document is the output of the TLS External PSK Design Team,
comprised of the following members: Benjamin Beurdouche, Björn Haase, comprised of the following members: Benjamin Beurdouche, Björn Haase,
Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland,
Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel,
and Russ Housley. and Russ Housley.
This document was improved by a high quality reviews by Ben Kaduk and This document was improved by high-quality reviews by Ben Kaduk and
John Mattsson. John Preuß Mattsson.
Authors' Addresses Authors' Addresses
Russ Housley Russ Housley
Vigil Security Vigil Security, LLC
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 Aalto University
Email: mohit@iki.fi
Email: mohit@piuha.net
Christopher A. Wood Christopher A. Wood
Cloudflare Cloudflare
Email: caw@heapingbits.net Email: caw@heapingbits.net
 End of changes. 83 change blocks. 
261 lines changed or deleted 242 lines changed or added

This html diff was produced by rfcdiff 1.48.