RFC 8442

ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2

📅 published September 2018, from ietf

RFC 8442: ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2 💖

  • Authors: J. Mattsson and D. Migault, both from Ericsson ✨
  • Category: Standards Track 🎀
  • ISSN: 2070-1721 🌸
  • Date: September 2018 📅
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates, so there's nothing else to chase up there 🫶

Abstract ✨

okay so this doc adds a few brand-new cipher suites for TLS 1.2 and DTLS 1.2 💅 They're built on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange, paired with the AEAD algorithms AES-GCM and AES-CCM. The vibe: PSK gives light and efficient authentication, ECDHE gives forward secrecy, and AES-GCM and AES-CCM handle encryption and integrity protection. A whole power team 👑

Status of This Memo 📜

This is an Internet Standards Track document.

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). Further information on Internet Standards is available in 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/rfc8442.

Copyright (c) 2018 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 ....................................................2
2. Requirements Notation ...........................................3
3. ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites ................3
4. IANA Considerations .............................................4
5. Security Considerations .........................................4
6. References ......................................................5
   6.1. Normative References .......................................5
   6.2. Informative References .....................................6
Acknowledgements ...................................................7
Authors' Addresses .................................................7

1. Introduction 🦋

okay bestie, so this doc defines new cipher suites that bring together Pre-Shared Key (PSK) authentication, Perfect Forward Secrecy (PFS), and Authenticated Encryption with Associated Data (AEAD) 🔥. These suites are for version 1.2 of the Transport Layer Security (TLS) protocol [RFC5246] and version 1.2 of the Datagram Transport Layer Security (DTLS) protocol [RFC6347].

PSK authentication shows up everywhere 🌈. One big example is 3GPP networks, where pre-shared keys authenticate both the subscriber and the network. Another is the Internet of Things, where PSK is often picked for performance and energy efficiency reasons 🔋. In both situations, the endpoints are owned and/or controlled by a party that provisions the pre-shared keys and makes sure they have a high level of entropy 🔐.

Perfect Forward Secrecy (PFS) is strongly recommended in security protocol design 🧚, and you can get it with an ephemeral Diffie-Hellman key exchange. Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) gives you PFS with excellent performance and small key sizes ✨. ECDHE is mandatory to implement in both HTTP/2 [RFC7540] and the Constrained Application Protocol (CoAP) [RFC7252] 💅.

AEAD algorithms, which combine encryption and integrity protection, are strongly recommended for (D)TLS [RFC7525], and TLS 1.3 [RFC8446] forbids the use of non-AEAD algorithms 🙈. The AEAD algorithms this document looks at are AES-GCM and AES-CCM 💜. AES-GCM in TLS is defined in [RFC5288], and AES-CCM is defined in [RFC6655].

Here's the gap analysis, and it's kind of messy 😭. [RFC4279] defines PSK cipher suites for TLS but doesn't consider elliptic curve cryptography. [RFC8422] brings elliptic curve cryptography to TLS but doesn't consider PSK authentication. [RFC5487] describes AES-GCM combined with PSK authentication but doesn't consider ECDHE. [RFC5489] describes PSK combined with ECDHE but doesn't consider AES-GCM or AES-CCM. So this doc fills in the missing combo 🧩.

2. Requirements Notation 📝

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. ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites 🍓

The cipher suites in this doc are based on these AES-GCM and AES-CCM AEAD algorithms: AEAD_AES_128_GCM [RFC5116], AEAD_AES_256_GCM [RFC5116], AEAD_AES_128_CCM [RFC5116], and AEAD_AES_128_CCM_8 [RFC6655] 💖.

The messages and premaster secret construction are defined in [RFC5489], so you're not reinventing the wheel 🛞. The ServerKeyExchange and ClientKeyExchange messages get used, and the premaster secret is computed just like it is for the ECDHE_PSK key exchange ✨. The elliptic curve parameters for the Diffie-Hellman parameters get negotiated using the extensions from [RFC8422] 🌸.

For TLS 1.2 and DTLS 1.2, these are the cipher suites that get defined 👑:

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}
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xD0,0x05}

<rose>The assigned code points can only be used for TLS 1.2 and DTLS 1.2.</rose> 🙅‍♀️

Here's the big rule 🚨: 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. A client MUST treat the selection of these cipher suites in combination with a different version of (D)TLS as an error and generate a fatal 'illegal_parameter' TLS alert. Not me saying "illegal" like that 💀.

Also, the cipher suites TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_AES_128_CCM_8_SHA256, and TLS_AES_128_CCM_SHA256 are used to support equivalent functionality in TLS 1.3 [RFC8446] 🦋. So they're the TLS 1.3 cousins, iykyk 🌈.

Part 2 is coming up next with the IANA Considerations, Security Considerations, and References 🧚💜

6.2. Informative References

okay so these are the ones that are good to know but aren't strictly required reading 📚 bestie, they're the vibes-check sources 💅

Acknowledgements

okay the authors gave a huge shoutout to everyone who helped out 🫶 the people listed are Ilari Liusvaara, Eric Rescorla, Dan Harkins, Russ Housley, Dan Harkins, Martin Thomson, Nikos Mavrogiannopoulos, Peter Dettman, Xiaoyin Liu, Joseph Salowey, Sean Turner, Dave Garrett, Martin Rex, and Kathleen Moriarty. Their comments and feedback were super valuable 😭✨ (yes, Dan Harkins shows up twice in the original list, and we're keeping it exactly like that 🙈)

Authors' Addresses

the authors' contact info, copied exactly so you can reach them 💌

John Mattsson
Ericsson AB
SE-164 80 Stockholm
Sweden

Phone: +46 76 115 35 01
Email: john.mattsson@ericsson.com


Daniel Migault
Ericsson
8400 Boulevard Decarie
Montreal, QC  H4P 2N2
Canada

Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com
📦 where this page comes from