Guidance for External PSK Usage in TLS

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 https://datatracker.ietf.org/drafts/current/.¶

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 6 May 2021.¶

Copyright Notice

Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

There are many resources that provide guidance for password generation and verification aimed towards improving security. However, there is no such equivalent for external Pre-Shared Keys (PSKs) in TLS. This document aims to reduce that gap. 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.ietf-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

External PSK authentication in TLS allows endpoints to authenticate connections using previously established keys. These keys do not provide protection of endpoint identities (see Section 5), nor do they provide non-repudiation (one endpoint in a connection can deny the conversation). 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 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 PSK with DH is used, then compromise of a group member that actively completes connections with other group members can read (and modify) traffic.¶
3. If PSK without DH is used, then compromise of any group member allows the attacker to passively read (and modify) all traffic.¶
4. If a group member is compromised, then the attacker can perform all of the above attacks.¶

Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described below. (Note that this class of attack is not possible if each member uses the SNI extension [RFC6066] and terminates the connection on mismatch. See [Selfie] for details.) 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 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.¶

Finally, in addition to these weaknesses, sharing a PSK across nodes may negatively affects deployments. For example, revocation of individual group members is not possible without changing the authentication key for all members.¶

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. The Crypto Forum Research Group (CFRG) is currently working on specifying a standard PAKE (see [I-D.irtf-cfrg-cpace] and [I-D.irtf-cfrg-opaque]).¶

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. 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 oppress handshakes or application data from a specific device by blocking, delaying, or rate-limiting traffic. Techniques for mitigating these risks require 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.¶

6. External PSK Use Cases and Provisioning Processes

PSK ciphersuites were first specified for TLS in 2005. Now, PSKs are 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 (i.e., external PSKs that are shared between only one server and one client) have been used for authentication in TLS.¶

• Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known identities, wherein the identity to use is discovered via a different online protocol.¶
• Intra-data-center communication. Machine-to-machine communication within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections with early data.¶
• Certificateless server-to-server communication. Machine-to-machine communication may use externally provisioned PSKs, primarily for the purposes of establishing TLS connections without requiring the overhead of provisioning and managing PKI certificates.¶
• Internet of Things (IoT) and devices with limited computational capabilities. [RFC7925] defines TLS and DTLS profiles for resource-constrained devices and suggests the use of PSK ciphersuites for compliant devices. The Open Mobile Alliance Lightweight Machine to Machine Technical Specification [LwM2M] states that LwM2M servers MUST support the PSK mode of DTLS.¶
• Use of PSK ciphersuites are optional when securing RADIUS [RFC2865] with TLS as specified in [RFC6614].¶
• The Generic Authentication Architecture (GAA) defined by 3GGP mentions that TLS-PSK can be used between a server and user equipment for authentication [GAA].¶
• Smart Cards. The electronic German ID (eID) card supports authentication of a card holder to online services with TLS-PSK [SmartCard].¶
• Quantum resistance: Some deployments may use PSKs (or combine them with certificate-based authentication as described in [RFC8773]) because of the protection they provide against quantum computers.¶

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

• Group chats. In this use-case, group participants may be provisioned an external PSK out-of-band for establishing authenticated connections with other members of the group.¶
• Internet of Things (IoT) and devices with limited computational capabilities. Many PSK provisioning examples are possible in this 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 (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 communicating with each other (n^2 keys for n devices).¶

The exact provisioning process depends on the system requirements and threat model. Generally, use of a single PSK shared between more than one node is not recommended, even if other accommodations are made, such as client certificate authentication after PSK-based connection establishment. See Section 7.¶

7. Recommendations for External PSK Usage

If an application uses external PSKs, the external PSKs MUST 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, e.g., by using the "psk_dhe_ke" Pre-Shared Key Exchange Mode in TLS 1.3, 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 no such mechanisms have yet been standardised, and further that these mechanisms will not necessarily follow the same architecture as the process for incorporating EPSKs described in [I-D.ietf-tls-external-psk-importer].¶
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 using TLS 1.3 SHOULD use external PSK importers [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a client-server pair. Importers make provisioning external PSKs easier and less error prone by deriving a unique, imported PSK from the external PSK for each key derivation function a node supports. See the Security Considerations in [I-D.ietf-tls-external-psk-importer] for more information.¶
4. Where possible the main 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 main key and then re-run the importer itself.¶

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.¶

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