Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (21)
PSK identities are encoded as UTF-8 strings rather than in type-specific binary formats (e.g., 4-byte integers for IPv4, DNS wire format for names) to avoid identity-type-specific parsing code in implementations where identities are configured by humans, and to reduce interoperability problems from implementations supporting different identity types.
These ciphersuites are intended for limited environments (few clients/servers, constrained CPU, or existing shared-secret infrastructure) where PKI is impractical or unnecessary. The document notes that self-signed certificates with public key fingerprints or SRP may be more appropriate in many cases.
Using zeroes for 'other_secret' in the plain PSK premaster secret means only the HMAC-SHA1 part of the TLS PRF is used when constructing the master secret. This was chosen over using the same key for both HMAC-MD5 and HMAC-SHA1 parts because it was considered more analytically elegant; see Krawczyk's analysis.
RSA_PSK ciphersuites can be used with unvalidated self-signed certificates, providing similar dictionary-attack protection to DHE_PSK without requiring a PKI. The ciphersuites themselves do not specify certificate contents or validation procedure.
In the absence of an application profile specifying otherwise, servers SHOULD NOT provide an identity hint and clients MUST ignore the identity hint field. Applications using the field MUST specify its contents, how the server chooses the value, and what the client does with it.
It is RECOMMENDED that before looking up the key, the server processes the PSK identity with a stringprep profile appropriate for the identity type (e.g., Nameprep for domain name components, SASLprep for usernames).
It is RECOMMENDED that implementations allowing manual PSK configuration also provide functionality for generating a new random PSK, following the randomness requirements of RFC 4086.
Management interfaces MUST support entering PSK identities of up to 128 printable Unicode characters and entering PSKs up to 64 octets in length as ASCII strings and in hexadecimal encoding.
The PSK identity MUST be first converted to a character string and then encoded to octets using UTF-8. IPv4 addresses are sent as dotted-decimal strings, domain names in their usual text form, and X.500 Distinguished Names in their string representation.
TLS implementations supporting these ciphersuites MUST support arbitrary PSK identities up to 128 octets in length and arbitrary PSKs up to 64 octets in length. Supporting longer identities and keys is RECOMMENDED.
If the server does not recognize the PSK identity, it MAY respond with an 'unknown_psk_identity' alert (value 115), or MAY continue as if the identity existed but the key was incorrect (responding with 'decrypt_error') to hide that the identity was unknown.
Three PSK key exchange algorithms are defined: PSK (symmetric-only), DHE_PSK (PSK-authenticated Diffie-Hellman), and RSA_PSK (RSA server authentication plus PSK client authentication). These yield 12 new ciphersuites combining the three key exchange algorithms with RC4_128, 3DES_EDE_CBC, AES_128_CBC, and AES_256_CBC.
This document defines 12 new TLS ciphersuite values (0x00,0x8A through 0x00,0x95) and one new TLS alert value, unknown_psk_identity(115). At time of publication, IANA had no registry for TLS ciphersuite or alert numbers, so there were no formal IANA actions.
Low-entropy PSKs are vulnerable to brute-force or dictionary attacks. For PSK ciphersuites an off-line attack is possible via passive eavesdropping; for DHE_PSK an active man-in-the-middle is required; for RSA_PSK only an authenticated server can mount an off-line attack.
The PSK and RSA_PSK ciphersuites do not provide Perfect Forward Secrecy: compromise of the shared secret (and RSA private key for RSA_PSK) allows decryption of old sessions. DHE_PSK provides PFS only if a fresh DH private key is generated per handshake.
The PSK identity is transmitted in cleartext, allowing an eavesdropper to identify communicating parties. Reusing the same identity over time can enable traffic analysis even when the identity itself reveals no information. This is noted to be no worse than client certificates, which are also sent in cleartext.
For DHE_PSK, ServerKeyExchange carries psk_identity_hint<0..2^16-1> plus ServerDHParams; ClientKeyExchange carries psk_identity<0..2^16-1> plus ClientDiffieHellmanPublic. The ServerKeyExchange is always sent even when no hint is provided.
For RSA_PSK, ClientKeyExchange carries psk_identity<0..2^16-1> followed by EncryptedPreMasterSecret (2-byte version + 46-byte random, RSA-encrypted). The premaster secret prepends uint16(48) and the 48-byte RSA value before uint16(len(PSK)) and PSK; it is thus 52 octets longer than the PSK.
For the PSK key exchange, ServerKeyExchange carries an opaque psk_identity_hint<0..2^16-1> and ClientKeyExchange carries an opaque psk_identity<0..2^16-1>. Both fields are variable-length with a 2-byte length prefix.
The DHE_PSK premaster secret concatenates: uint16(len(Z)), Z (DH result with leading zeros stripped), uint16(len(PSK)), and the PSK itself. Z fills the 'other_secret' slot of the general premaster secret structure.
The PSK premaster secret is constructed by concatenating: uint16(N), N zero octets, uint16(N), and the PSK itself (where N is the PSK length in octets). This follows the general structure {other_secret<0..2^16-1>, psk<0..2^16-1>} where other_secret is zeroes for plain PSK.