RFC 9257 | Guidance for External PSK Usage in TLS | July 2022 |
Housley, et al. | Informational | [Page] |
This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used.¶
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the 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.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9257.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document provides guidance on the use of external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 [RFC8446]. This guidance also applies to Datagram TLS (DTLS) 1.3 [RFC9147] and Compact TLS 1.3 [CTLS]. For readability, this document uses the term "TLS" to refer to all such versions.¶
External PSKs are symmetric secret keys provided to the TLS protocol implementation as external inputs. External PSKs are provisioned out of band.¶
This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions. This document also provides advice for applications in various use cases to help meet these assumptions.¶
There are many resources that provide guidance for password generation and verification aimed towards improving security. However, there is no such equivalent for external PSKs in TLS. This document aims to reduce that gap.¶
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.¶
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.¶
The use of a previously established PSK allows TLS nodes to authenticate the endpoint identities. It also offers other benefits, including resistance to attacks in the presence of quantum computers; see Section 4.2 for related discussion. However, these keys do not provide privacy protection of endpoint identities, nor do they provide non-repudiation (one endpoint in a connection can deny the conversation); see Section 7 for related discussion.¶
PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server and they never switch roles. If this assumption is violated, then the security properties of TLS are severely weakened as discussed below.¶
Entropy properties of external PSKs may also affect TLS security properties. For example, if a high-entropy PSK is used, then PSK-only key establishment modes provide expected security properties for TLS, including establishment of the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection. See Appendix E.1 of [RFC8446] for an explanation of these properties. However, these modes lack forward security. Forward security may be achieved by using a PSK-DH mode or by using PSKs with short lifetimes.¶
In contrast, if a low-entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search 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 Password-Authenticated Key Exchange (PAKE) is used with TLS. At the time of writing, the Crypto Forum Research Group (CFRG) is working on specifying recommended PAKEs (see [CPACE] and [OPAQUE] for the symmetric and asymmetric cases, respectively).¶
PSK ciphersuites were first specified for TLS in 2005. PSKs are now an integral part of the TLS 1.3 specification [RFC8446]. TLS 1.3 also uses PSKs for session resumption. It distinguishes these resumption PSKs from external PSKs that have been provisioned out of band. This section describes known use cases and provisioning processes for external PSKs with TLS.¶
This section lists some example use cases where pairwise external 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 attempt to prioritize the examples in any particular order.¶
There are also use cases where PSKs are shared between more than two entities. Some examples below (as noted by Akhmetzyanova, et al. [AASS19]):¶
The exact provisioning process depends on the system requirements and threat model. Whenever possible, avoid sharing a PSK between nodes; however, sharing a PSK among several nodes is sometimes unavoidable. When PSK sharing happens, other accommodations SHOULD be used as discussed in Section 6.¶
Examples of PSK provisioning processes are included below.¶
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 pairwise 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].¶
Recommended requirements for applications using external PSKs are as follows:¶
Most major TLS implementations support external PSKs. Stacks supporting external PSKs provide interfaces that applications may use when configuring PSKs for individual connections. Details about some existing stacks at the time of writing are below.¶
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. When PSK identities are configured manually, it is important to be aware that visually identical strings may, in fact, differ due to encoding issues.¶
TLS 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) that thus is compared on a 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 [RFC8446] does not place strict requirements on the format of PSK identities, note that the format of PSK identities can vary depending on the deployment:¶
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 behavior 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's external PSK usage will typically take precedence over the internal session resumption path.¶
Because resumption PSK identities are assigned by the TLS stack implementation, it is RECOMMENDED that these identifiers be assigned in a manner that lets resumption PSKs be distinguished from external PSKs to avoid concerns with collisions altogether.¶
PSK privacy properties are orthogonal to security properties described in Section 4. 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 the identifier 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. Depending on the PSK identity, a passive attacker may also be able to identify the device, person, or enterprise running the TLS client or TLS server. An active attacker can also use the PSK identity to suppress handshakes or application data from a specific device by blocking, delaying, or rate-limiting traffic. Techniques for mitigating these risks require further analysis and are out of scope for this document.¶
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.¶
Security considerations are provided throughout this document. It bears repeating that there are concerns related to the use of external PSKs regarding proper identification of TLS 1.3 endpoints and additional risks when external PSKs are known to a group.¶
It is NOT RECOMMENDED to share the same PSK between more than one client and server. However, as discussed in Section 5.1, there are application scenarios that may rely on sharing the same PSK among multiple nodes. [RFC9258] 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 [RFC9258]. One solution would be for each endpoint to select one globally unique identifier to use in all PSK handshakes. The unique identifier can, for example, be one of its Media Access Control (MAC) addresses, a 32-byte random number, or its Universally Unique IDentifier (UUID) [RFC4122]. Note that such persistent, global identifiers have privacy implications; see Section 7.¶
Each endpoint SHOULD know the identifier of the other endpoint with which it wants to connect and SHOULD compare it with the other endpoint's identifier used in ImportedIdentity.context. However, it is important to remember that endpoints sharing the same group PSK can always impersonate each other.¶
Considerations for external PSK usage extend beyond proper identification. When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that contributes to key diversity between sessions. As a result, when an 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 data.¶
This document has no IANA actions.¶
This document is the output of the TLS External PSK Design Team, comprised of the following members: Benjamin Beurdouche, Björn Haase, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel, and Russ Housley.¶
This document was improved by high-quality reviews by Ben Kaduk and John Preuß Mattsson.¶