ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2
Extracted elements (12)
ECDHE_PSK cipher suites were created to fill a gap: RFC 4279 defined PSK cipher suites without elliptic curve cryptography, RFC 8422 introduced ECC for TLS without PSK, RFC 5487 combined AES-GCM with PSK but not ECDHE, and RFC 5489 combined PSK with ECDHE but not AES-GCM or AES-CCM. This document unifies all three capabilities.
PSK authentication is used in 3GPP networks (authenticating subscribers and networks) and IoT deployments where it is preferred for performance and energy efficiency. ECDHE is included to provide Perfect Forward Secrecy, which is mandatory in HTTP/2 and CoAP.
The assigned code points {0xD0,0x01}–{0xD0,0x05} can only be used for TLS 1.2 and DTLS 1.2. Equivalent functionality for TLS 1.3 is provided by TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256, and TLS_AES_128_CCM_SHA256.
A client MUST treat the selection of these cipher suites in combination with a (D)TLS version other than 1.2 as an error and generate a fatal 'illegal_parameter' TLS alert.
GCM and CCM MUST only be used with a system guaranteeing nonce uniqueness, as reusing a nonce with the same key undermines the security of GCM and CCM.
The cipher suites defined in this document MUST NOT be negotiated for any version of (D)TLS other than version 1.2. Servers MUST NOT select one of these cipher suites when selecting a (D)TLS version other than version 1.2.
The pre-shared keys used for authentication MUST have a security level equal to or higher than the cipher suite used — at least 128-bit security for AES-128 cipher suites and at least 192-bit security for AES-256 cipher suites.
Four new cipher suites are defined for TLS 1.2 and DTLS 1.2: TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 {0xD0,0x01}, TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 {0xD0,0x02}, TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 {0xD0,0x03}, and TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 {0xD0,0x05}. These combine ECDHE key exchange with PSK authentication and AEAD encryption.
Messages and premaster secret construction follow RFC 5489 (ECDHE_PSK). The ServerKeyExchange and ClientKeyExchange messages are used, and the premaster secret is computed as for the ECDHE_PSK key exchange. Elliptic curve parameters are negotiated using extensions from RFC 8422.
The AEAD algorithms used are AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, and AEAD_AES_128_CCM_8 as defined in RFC 5116 and RFC 6655.
Four new cipher suite values ({0xD0,0x01}, {0xD0,0x02}, {0xD0,0x03}, {0xD0,0x05}) are registered in the 'TLS Cipher Suites' registry defined by RFC 8446 and RFC 8447. TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 is marked not recommended; the other three are recommended.
All cipher suites defined provide confidentiality, mutual authentication, and forward secrecy. AES-128 suites provide 128-bit security and AES-256 suites provide at least 192-bit security, but AES_128_CCM_8 only provides 64-bit security against message forgery.