Internet-Draft Guidance for External PSK Usage in TLS June 2020
Housley, et al. Expires 20 December 2020 [Page]
Intended Status:
R. Housley
Vigil Security
J. Hoyland
Cloudflare Ltd.
M. Sethi
C.A. Wood
Cloudflare Ltd.

Guidance for External PSK Usage in TLS


This document provides usage guidance for external Pre-Shared Keys (PSKs) in TLS. It lists TLS 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.

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

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 December 2020.

Table of Contents

1. Introduction

This document provides usage guidance for external Pre-Shared Keys (PSKs) in TLS. It lists TLS 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 [RFC8446], DTLS [I-D.ietf-tls-dtls13], and Constrained TLS [I-D.rescorla-tls-ctls].

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Notation

For purposes of this document, a "logical node" is a computing presence that other parties can interact with via the TLS protocol. A logical node could potentially be realized with multiple physical instances operating under common administrative control, e.g., a server farm. An "endpoint" is a client or server participating in a connection.

4. PSK Security Properties

The external PSK authentication mechanism in TLS 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 in Section 6, there are use cases where it is desirable 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 authenticates the entire group, and the security of the overall system is inherently rather brittle. There are a number of obvious weaknesses here:

  1. Any group member can impersonate any other group member.
  2. If a group member is compromised, then the attacker can impersonate any group member (this follows from property (1)).
  3. If PSK without DH is used, then compromise of any group member allows the attacker to passively read all traffic.

In addition to these, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as detailed below.

Let the group of peers who know the key be A, B, and C. The attack proceeds as follows:

  1. A sends a ClientHello to B.
  2. The attacker intercepts the message and redirects it to C.
  3. C responds with a ServerHello to A.
  4. A sends a Finished message to B. A has completed the handshake, ostensibly with B.
  5. The attacker redirects the Finished message to C. C has completed the handshake, ostensibly with A.

This attack violates the peer authentication property, and if C supports a weaker set of cipher suites than B, this attack also violates the downgrade protection property. This rerouting is a type of identity misbinding attack [Krawczyk][Sethi]. Selfie attack [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 attack, a malicious non-member reroutes a connection from the client to the server on the same endpoint.

Entropy properties of external PSKs may also affect TLS security properties. In particular, if a high entropy PSK is used, then PSK-only key establishment modes are secure against both active and passive attack. However, they lack forward security. Forward security may be achieved by using a PSK-DH mode.

In contrast, if a low entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search passive attacks which will reveal the traffic keys. PSK-DH modes are subject to active attacks in which the attacker impersonates one side. The exhaustive search phase of these attacks can be mounted offline if the attacker captures a single handshake using the PSK, but those attacks will not lead to compromise of the traffic keys for that connection because those also depend on the Diffie-Hellman (DH) exchange. Low entropy keys are only secure against active attack if a PAKE is used with TLS.

5. Privacy Properties

PSK privacy properties are orthogonal to security properties described in Section 4. Traditionally, TLS does little to keep PSK identity information private. For example, an adversary learns information about the external PSK or its identifier by virtue of it appearing in cleartext in a ClientHello. As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire. Applications should take precautions when using external PSKs to mitigate these risks.

In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers. Specifically, servers can link successive connections that use the same external PSK together. Preventing this type of linkability is out of scope, as PSKs are explicitly designed to support mutual authentication.

6. External PSK Use Cases and Provisioning Processes

Pre-shared Key (PSK) ciphersuites were first specified for TLS in 2005. Now, PSK is an integral part of the TLS version 1.3 specification [RFC8446]. TLS 1.3 also uses PSKs for session resumption. It distinguishes these resumption PSKs from external PSKs which have been provisioned out-of-band (OOB). Below, we list some example use-cases where pair-wise external PSKs with TLS have been used for authentication.

There are also use cases where PSKs are shared between more than two entities. Some examples below (as noted by Akhmetzyanova et al.[Akhmetzyanova]):

6.1. Provisioning Examples

  • Many industrial protocols assume that PSKs are distributed and assigned manually via one of the following approaches: typing the PSK into the devices, or via web server masks (using a Trust On First Use (TOFU) approach with a device completely unprotected before the first login did take place). Many devices have very limited UI. For example, they may only have a numeric keypad or even less number of buttons. When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. Moreover, PSK production lacks guidance unlike user passwords.
  • Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.
  • Some secrets may be baked into or hardware or software device components. Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.

6.2. Provisioning Constraints

PSK provisioning systems are often constrained in application-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 not want to distribute pair-wise shared keys to achieve this. As another example, some systems require the provisioning process to embed application-specific information in either PSKs or their identities. Identities may sometimes need to be routable, as is currently under discussion for EAP-TLS-PSK.

7. Recommendations for External PSK Usage

Applications MUST use external PSKs that adhere to the following requirements:

  1. Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be at least 128 bits long, and SHOULD be combined with a DH exchange for forward secrecy. As discussed in Section 4, low entropy PSKs, i.e., those derived from less than 128 bits of entropy, are subject to attack and SHOULD be avoided. If only low-entropy keys are available, then key establishment mechanisms such as Password Authenticated Key Exchange (PAKE) that mitigate the risk of offline dictionary attacks SHOULD be employed. Note that these mechanisms do not necessarily follow the same architecture as the ordinary process for incorporating EPSKs described in this draft.
  2. Unless other accommodations are made, each PSK MUST be restricted in its use to at most two logical nodes: one logical node in a TLS client role and one logical node in a TLS server role. (The two logical nodes MAY be the same, in different roles.) Two acceptable accommodations are described in [I-D.ietf-tls-external-psk-importer]: (1) exchanging client and server identifiers over the TLS connection after the handshake, and (2) incorporating identifiers for both the client and the server into the context string for an EPSK importer.
  3. Nodes SHOULD use external PSK importers [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a pair of TLS client and server.
  4. Where possible the master PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated. This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the master key and then re-run the importer itself.

7.1. Stack Interfaces

Most major TLS implementations support external PSKs. Stacks supporting external PSKs provide interfaces that applications may use when supplying them for individual connections. Details about existing stacks at the time of writing are below.

  • OpenSSL and BoringSSL: Applications specify support for external PSKs via distinct ciphersuites. They also then configure callbacks that are invoked for PSK selection during the handshake. These callbacks must provide a PSK identity and key. The exact format of the callback depends on the negotiated TLS protocol version with new callback functions added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support. The PSK length is validated to be between [1, 256] bytes. The PSK identity may be up to 128 bytes long.
  • mbedTLS: Client applications configure PSKs before creating a connection by providing the PSK identity and value inline. Servers must implement callbacks similar to that of OpenSSL. Both PSK identity and key lengths may be between [1, 16] bytes long.
  • gnuTLS: Applications configure PSK values, either as raw byte strings or hexadecimal strings. The PSK identity and key size are not validated.
  • wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.

7.1.1. PSK Identity Encoding and Comparison

Section 5.1 of [RFC4279] mandates that the PSK identity should be first converted to a character string and then encoded to octets using UTF-8. This was done to avoid interoperability problems (especially when the identity is configured by human users). On the other hand, [RFC7925] advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for any operation. TLS version 1.3 [RFC8446] follows the same practice of specifying the PSK identity as a sequence of opaque bytes (shown as opaque 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 bytes in length. Although [RFC8446] does not place strict requirements on the format of PSK identities, we do however note that the format of PSK identities can vary depending on the deployment:

  • The PSK identity MAY be a user configured string when used in protocols like Extensible Authentication Protocol (EAP) [RFC3748]. gnuTLS for example treats PSK identities as usernames.
  • PSK identities MAY have a domain name suffix for roaming and federation.
  • Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions.

7.1.2. PSK Identity Collisions

It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity. The TLS stack implementation and sequencing of PSK callbacks influences the application's behaviour when identity collisions occur. When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the application's registered callback function before checking the stack's internal session resumption cache. This means that if a PSK identity collision occurs, the application will be given precedence over how to handle the PSK.

8. Security Considerations

It is NOT RECOMMENDED to share the same PSK between more than one client and server. However, as discussed in Section 6, there are application scenarios that may rely on sharing the same PSK among multiple nodes. [I-D.ietf-tls-external-psk-importer] helps in mitigating rerouting and Selfie style reflection attacks when the PSK is shared among multiple nodes. This is achieved by correctly using the node identifiers in the ImportedIdentity.context construct specified in [I-D.ietf-tls-external-psk-importer]. It is RECOMMENDED that each endpoint selects one globally unique identifier and uses it in all PSK handshakes. The unique identifier can, for example, be one of its MAC addresses, a 32-byte random number, or its Universally Unique IDentifier (UUID) [RFC4122]. Each endpoint SHOULD know the identifier of the other endpoint with which its wants to connect and SHOULD compare it with the other endpoint's identifier used in ImportedIdentity.context. It is however important to remember that endpoints sharing the same group PSK can always impersonate each other.

9. IANA Considerations

This document makes no IANA requests.

10. References

10.1. Normative References

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-38, , <>.
Benjamin, D. and C. Wood, "Importing External PSKs for TLS", Work in Progress, Internet-Draft, draft-ietf-tls-external-psk-importer-05, , <>.
Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 1.3", Work in Progress, Internet-Draft, draft-rescorla-tls-ctls-04, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <>.

10.2. Informative References

Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A. Sokolov, "Continuing to reflect on TLS 1.3 with external PSK", , <>.
"TR33.919 version 12.0.0 Release 12", , <>.
Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols", Annual International Cryptology Conference. Springer, Berlin, Heidelberg , , <>.
"Lightweight Machine to Machine Technical Specification", , <>.
Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, , <>.
Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, , <>.
Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, , <>.
Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, , <>.
Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, , <>.
Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, , <>.
Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 with PSK", , <>.
Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks on Secure Device Pairing and Bootstrapping", Proceedings of the 2019 ACM Asia Conference on Computer and Communications Security , , <>.
"Technical Guideline TR-03112-7 eCard-API-Framework - Protocols", , <>.

Appendix A. Acknowledgements

This document is the output of the TLS External PSK Design Team, comprised of the following members: Benjamin Beurdouche, Bjoern Haase, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel, and Russ Housley.

Authors' Addresses

Russ Housley
Vigil Security
Jonathan Hoyland
Cloudflare Ltd.
Mohit Sethi
Christopher A. Wood
Cloudflare Ltd.