RFC 8750

Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)

📅 published March 2020, from ietf

RFC 8750: Implicit IV for Counter-Based Ciphers in ESP 🦋

okay bestie, RFC 8750 is giving main character energy ✨ It's a Standards Track document from March 2020, so it's an actual Internet standard and not just a suggestion 💅 It was written by D. Migault (Ericsson), T. Guggemos (LMU Munich), and Y. Nir (Dell Technologies), and it's published under ISSN 2070-1721. It doesn't obsolete or update anything, so it stands alone 🌸

Abstract

okay so ESP (Encapsulating Security Payload) sends an initialization vector (IV) in every single packet 📦 The size depends on which transform you use, and for the transforms that existed when this was written it's usually 8 or 16 octets. When you're using IPsec, some algorithms, like AES-GCM, AES-CCM, and ChaCha20-Poly1305, use that IV to build a nonce, and the nonce is what goes into encrypting and decrypting. The IV has to be unique, but it's allowed to be predictable 🧚 That means you can use the ESP Sequence Number (SN) to build the nonce instead. Then you don't have to send the IV at all, which saves 8 octets per packet for AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document explains how to do it 💖

Status of This Memo

this part is the boring legal bit, but it's still part of the spec so it stays 🫶

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/rfc8750.

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
2.  Requirements Notation
3.  Terminology
4.  Implicit IV
5.  IKEv2 Initiator Behavior
6.  IKEv2 Responder Behavior
7.  Security Considerations
8.  IANA Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

okay so counter-based AES modes like AES-CCM [RFC4309] and AES-GCM [RFC4106] need a nonce for every ESP packet 🌈 ChaCha20-Poly1305 [RFC7634] needs one too. Right now that nonce gets made from the IV that rides along in each ESP packet [RFC4303]. This document calls that approach "explicit IV" 💜

in some situations, like the Internet of Things (IoT), it can be better to skip carrying those extra bytes and just have each peer generate the IV locally 🍓 Generating it locally is what this document calls "implicit IV" 🦋

The size of this IV depends on the specific algorithm, but every algorithm mentioned above takes an 8-octet IV 🎀

This document defines how to compute the IV locally when it's implicit. It also covers how peers use the Internet Key Exchange version 2 (IKEv2) [RFC7296] to agree on implicit IV versus explicit IV 🫶

The scope here is limited to the algorithms listed above. Other algorithms with similar properties may later be defined to use similar mechanisms 🔥

This document does not consider AES-CBC [RFC3602], because AES-CBC needs the IV to be unpredictable 🙈 Deriving the IV straight from the packet counter, like described below, is insecure, as mentioned in Section 6 of [RFC3602]. It has led to real-world chosen plaintext attacks such as BEAST [BEAST] 💀

This document also does not consider AES-CTR [RFC3686], since it focuses on the recommended Authenticated Encryption with Associated Data (AEAD) suites provided in [RFC8221] 💅

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. Terminology 🧚

  • IoT: Internet of Things
  • IV: Initialization Vector
  • IIV: Implicit Initialization Vector
  • Nonce: A fixed-size octet string used only once. In this document, the IV is used to generate the nonce input for the encryption/decryption.

4. Implicit IV 🌸

okay this is the core of the whole thing 😭 With the algorithms listed in Section 1, the 8-byte IV MUST NOT repeat for a given key 🔐 The binding between an ESP packet and its IV is provided using the Sequence Number or the Extended Sequence Number. Figures 1 and 2 show the IV with a regular 4-byte Sequence Number and an 8-byte Extended Sequence Number, respectively 👑

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Zero                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Implicit IV with a 4-Byte Sequence Number

  • Sequence Number: The 4-byte Sequence Number carried in the ESP packet.
  • Zero: A 4-byte array with all bits set to zero.
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Extended                              |
   |                      Sequence Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Implicit IV with an 8-Byte Extended Sequence Number

  • Extended Sequence Number: The 8-byte Extended Sequence Number of the Security Association. The four low-order bytes are carried in the ESP packet.

This document solely defines the IV generation of the algorithms defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM, and [RFC7634] for ChaCha20-Poly1305. All other aspects and parameters of those algorithms are unchanged and are used as defined in their respective specifications 🎀

5. IKEv2 Initiator Behavior 🦋

okay so an initiator that supports this feature SHOULD propose implicit IV (IIV) algorithms in the Transform Type 1 (Encryption Algorithm) Substructure of the Proposal Substructure inside the Security Association (SA) payload in the IKEv2 Exchange ✨ To keep things backward compatible with peers that don't support it, the initiator SHOULD also include those same algorithms with explicit IV as separate transforms 🫶

6. IKEv2 Responder Behavior 🧚

the SA payload processing rules require the responder to pick its algorithms from the proposal the initiator sent 💖 That's what guarantees the responder will never send an SA payload containing the IIV transform to an initiator that didn't propose it 🙌

part 2 picks up at Section 7 🌈

9.1. Normative References ✨

Okay bestie, these are the docs the spec leans on the hardest, so you need them in your back pocket 💅

9.2. Informative References 🦋

Acknowledgements 🫶

Huge thank-yous to Valery Smyslov, Éric Vyncke, Alexey Melnikov, Adam Roach, and Magnus Nyström (security directorate) 🌸 Also big love to the three Security ADs, Eric Rescorla, Benjamin Kaduk, and Roman Danyliw, for their super valuable comments ✨ Shoutout to David Schinazi for his implementation 💜 And thanks to Tero Kivinen and David Waltermire (the IPSECME Chairs) for moving this work forward 👑

Authors' Addresses 🎀

Daniel Migault
Ericsson
8275 Trans Canada Route
Saint Laurent QC H4S 0B6
Canada

Email: daniel.migault@ericsson.com


Tobias Guggemos
LMU Munich
Oettingenstr. 67
80538 Munich
Germany

Email: guggemos@nm.ifi.lmu.de
URI:   http://mnm-team.org/~guggemos


Yoav Nir
Dell Technologies
9 Andrei Sakharov St
Haifa 3190500
Israel

Email: ynir.ietf@gmail.com
📦 where this page comes from