4.1.Shared PSKs

As discussed inSection 5.1, to demonstrate their attack,[AASS19] describesscenarios where multiple clients or multiple servers share a PSK. Ifthis is done naively by having all members share a common key, thenTLS authenticates only group membership, and the security of theoverall system is inherently rather brittle. There are a number ofobvious weaknesses here:¶

1. Any group member can impersonate any other group member.¶
2. If a PSK is combined with the result of a fresh ephemeral key exchange, then compromise of a group member that knowsthe resulting shared secret will enable the attacker to passively read traffic (and actively modify it).¶
3. If a PSK is not combined with the result of a fresh ephemeral key exchange, then compromise of any group member allows theattacker to passively read all traffic (and actively modify it), including past traffic.¶

Additionally, a malicious non-member can reroute handshakes between honest group membersto connect them in unintended ways, as described below. Note that a partial mitigation forthis class of attack is available: each group member includes the Server Name Indication (SNI) extension[RFC6066]and terminates the connection on mismatch between the presented SNI value and the receiving member's known identity. See[Selfie] for details.¶

To illustrate the rerouting attack, consider three peers,A,B, andC,who all know the PSK. The attack proceeds as follows:¶

1. A sends aClientHello toB.¶
2. The attacker intercepts the message and redirects it toC.¶
3. C responds with a second flight (ServerHello, ...) toA.¶
4. A sends aFinished message toB.A has completed the handshake, ostensibly withB.¶
5. The attacker redirects theFinished message toC.C has completed the handshake withA.¶

In this attack, peer authentication is not provided. Also, ifC supports aweaker set of ciphersuites thanB, cryptographic algorithm downgrade attacksmight be possible. This rerouting is a type of identity misbinding attack[Krawczyk][Sethi]. Selfie attack[Selfie] is a special case of the reroutingattack against a group member that can act as both a TLS server and a client. In theSelfie attack, a malicious non-member reroutes a connection from the client tothe server on the same endpoint.¶

Finally, in addition to these weaknesses, sharing a PSK across nodes may negativelyaffect deployments. For example, revocation of individual group members is notpossible without establishing a new PSK for all of the members that have not been revoked.¶

4.2.PSK Entropy

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 expectedsecurity properties for TLS, including establishment of the samesession keys between peers, secrecy of session keys, peer authentication, and downgradeprotection. SeeAppendix E.1 of [RFC8446] for an explanation of these properties.However, these modes lack forward security. Forward security may be achieved by using aPSK-DH mode or by using PSKs with short lifetimes.¶

In contrast, if a low-entropy PSK is used, then PSK-only key establishment modesare subject to passive exhaustive search attacks, which will reveal thetraffic keys. PSK-DH modes are subject to active attacks in which the attackerimpersonates one side. The exhaustive search phase of these attacks can be mountedoffline if the attacker captures a single handshake using the PSK, but thoseattacks will not lead to compromise of the traffic keys for that connection becausethose also depend on the Diffie-Hellman (DH) exchange. Low-entropy keys are onlysecure against active attack if a Password-Authenticated Key Exchange (PAKE) is usedwith TLS. At the time of writing, the Crypto Forum Research Group (CFRG) is working on specifyingrecommended PAKEs (see[CPACE] and[OPAQUE] forthe symmetric and asymmetric cases, respectively).¶

5.1.Use Cases

This section lists some example use cases where pairwise external PSKs (i.e., externalPSKs that are shared between only one server and one client) have been used for authenticationin TLS. There was no attempt to prioritize the examples in any particular order.¶

• Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out of bandfor communicating with known identities, wherein the identity to use is discovered via a differentonline protocol.¶
• Intra-data-center communication. Machine-to-machine communication within a single data centeror Point of Presence (PoP) may use externally provisioned PSKs; this is primarily for the purpose of supporting TLSconnections with early data. SeeSection 8 for considerations when using early datawith external PSKs.¶
• Certificateless server-to-server communication. Machine-to-machine communicationmay use externally provisioned PSKs; this is primarily for the purposes of establishing TLSconnections 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 suggeststhe use of PSK ciphersuites for compliant devices. The Open Mobile Alliance Lightweight Machine-to-Machine (LwM2M) Technical Specification[LwM2M] states that LwM2M serversMUST support thePSK mode of DTLS.¶
• Securing RADIUS[RFC2865] with TLS. PSK ciphersuites are optional for this use case, as specified in[RFC6614].¶
• 3GPP server-to-user equipment authentication. The Generic Authentication Architecture (GAA) defined by 3GPP mentions that TLS PSK ciphersuites can be used between server and user equipment for authentication[GAA].¶
• Smart Cards. The German electronic Identity (eID) card supports authentication of a card holder toonline services with TLS PSK[SmartCard].¶
• Quantum resistance. Some deployments may use PSKs (or combine them with certificate-basedauthentication as described in[RFC8773]) because of the protection they provide againstquantum computers.¶

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

• Group chats. In this use case, group participants may be provisioned an external PSK out of band for establishingauthenticated connections with other members of the group.¶
• IoT and devices with limited computational capabilities. Many PSK provisioning examples arepossible in this use case. For example, in a given setting, IoT devices may all share the same PSK and use it tocommunicate with a central server (one key for n devices), have their own key for communicating with a central server (nkeys for n devices), or have pairwise keys for communicating with each other (n² keys for n devices).¶

5.2.Provisioning Examples

The exact provisioning process depends on the system requirements and threatmodel. Whenever possible, avoid sharing a PSK between nodes; however, sharinga PSK among several nodes is sometimes unavoidable. When PSK sharing happens,other accommodationsSHOULD be used as discussed inSection 6.¶

Examples of PSK provisioning processes are included below.¶

• Many industrial protocols assume that PSKs are distributed and assigned manually via one of the followingapproaches: (1) typing the PSK into the devices or (2) using a trust-on-first-use (TOFU) approach with a devicecompletely unprotected before the first login took place. Many devices have a very limited UI. For example,they may only have a numeric keypad or even fewer buttons. When the TOFU approach is not suitable,entering the key would require typing it on a constrained UI.¶
• Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.¶
• Some secrets may be baked into hardware or software device components. Moreover, when this is doneat manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease ofscanning or import.¶

5.3.Provisioning Constraints

PSK provisioning systems are often constrained in application-specific ways. For example, although one goal ofprovisioning is to ensure that each pair of nodes has a unique key pair, some systems do not want to distributepairwise shared keys to achieve this. As another example, some systems require the provisioning process to embedapplication-specific information in either PSKs or their identities. Identities may sometimes need to be routable,as is currently under discussion for[EAP-TLS-PSK].¶

6.1.Stack Interfaces

Most major TLS implementations support external PSKs. Stacks supporting external PSKsprovide interfaces that applications may use when configuring PSKs for individualconnections. Details about some existing stacks at the time of writing are below.¶

• OpenSSL and BoringSSL: Applications can specify support for external PSKs viadistinct ciphersuites in TLS 1.2 and below. Also, they can then configure callbacks that are invoked forPSK selection during the handshake. These callbacks must provide a PSK identity and key. Theexact format of the callback depends on the negotiated TLS protocol version, with new callbackfunctions added specifically to OpenSSL for TLS 1.3[RFC8446] PSK support. The PSK length is validated to be between 1-256 bytes (inclusive). The PSK identity may be up to 128 bytes long.¶
• mbedTLS: Client applications configure PSKs before creating a connection by providing the PSKidentity and value inline. Servers must implement callbacks similar to that of OpenSSL. Both PSKidentity and key lengths may be between 1-16 bytes long (inclusive).¶
• gnuTLS: Applications configure PSK values as either raw byte strings orhexadecimal strings. The PSK identity and key size are not validated.¶
• wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL.¶