RFC 6054

Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic

📅 published November 2010, from ietf

RFC 6054 🎀

Okay bestie, here's the deets on this one ✨ It's RFC 6054, a Standards Track doc, which means it's an actual Internet standard and not just vibes 💅 Written by D. McGrew and B. Weis from Cisco Systems, dated November 2010, ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's a fresh one 🦋

Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic 💖

Abstract 🌸

Counter modes were made for block ciphers like the Advanced Encryption Standard (AES) 🔐 They work with a counter that's usually assumed to get incremented by one single sender. This memo is about using counter modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) when there are multiple senders in a group app, which is a whole different energy 🫶

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, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Want more on Internet Standards? Check out Section 2 of RFC 5741 📚

Info about the current status of this document, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6054 ⭐

Copyright (c) 2010 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, which you can find at http://trustee.ietf.org/license-info, as they stand on the publication date. Please actually read these, bestie, because they explain your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💅

Table of Contents 🍓

1. Introduction ....................................................2
   1.1. Requirements Notation ......................................2
2. Problem Statement ...............................................2
3. IV Formation for Counter Modes with Group Keys ..................3
4. Group Key Management Conventions ................................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................6
7. References ......................................................6
   7.1. Normative References .......................................6
   7.2. Informative References .....................................6
Appendix A. Rationale for the IV Formation for Counter Modes
            with Group Keys ........................................9
Appendix B. Example ................................................9

1. Introduction ✨

Okay so the IP Encapsulating Security Payload (ESP) spec [RFC4303] and Authentication Header (AH) [RFC4302] are the security protocols for IPsec [RFC4301] 🔒 A bunch of new AES encryption modes have been defined for ESP, and they're giving main character 👑

  • Counter Mode (CTR) [RFC3686]
  • Galois/Counter Mode (GCM) [RFC4106]
  • Counter with Cipher Block Chaining-Message Authentication Code (CBC-MAC) Mode (CCM) [RFC4309]
  • The Galois Message Authentication Code (GMAC) [RFC4543], which works for both ESP and AH 🦋

A Camellia counter mode [RFC5528] and a GOST counter mode [RFC4357] have also been specified 🌈 These modes are honestly iconic and have real advantages over the traditional modes. BUT (and it's a big but 😭) they all have restrictions when multiple senders are protecting traffic with the same key. This document deals with that restriction and shows how these modes can be used with group key management protocols like the Group Domain of Interpretation (GDOI) protocol [RFC3547] and the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] 💖

1.1. Requirements Notation 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖

2. Problem Statement 🧠

The Counter Mode (CTR) of operation [FIPS.800-38A.2001] has blown up because of its performance and implementation advantages 🚀 It's the basis for several modes that combine authentication with encryption, including CCM and GCM. All of the counter-based modes require that, if a single key is shared by multiple encryption engines, those engines must coordinate to make sure that every Initialization Vector (IV) used with that key is distinct. So for each key, no IV value can be used more than once 😭 This restriction on IV usage is imposed on ESP CTR, ESP GCM, and ESP CCM. In cryptographic terms, the IV is a nonce. (Side note: CBC mode [RFC3602] requires IVs that are unpredictable. CTR, GCM, GMAC, and CCM do not have this restriction.) 🙈

Every ESP and AH transform using a block cipher counter mode has a restriction that an application must not use the same key, IV, and Salt values to protect two different data payloads. Notwithstanding this security condition, block cipher counter mode transforms are still often preferred because they perform really well compared to other modes ✨

Each of the block cipher counter mode transforms specifies how to construct keying material for point-to-point applications that are keyed by the Internet Key Exchange version 2 (IKEv2) [RFC5996] 💅 Those constructions guarantee that the security condition is not violated by a single sender. Group applications of IPsec [RFC5374] may also find counter mode transforms super valuable. Some group apps can create an IPsec Security Association (SA) per sender, which meets the security condition, and no further specification is needed. BUT IPsec can also be used to protect group applications known as Many-to-Many Applications [RFC3170], where a single IPsec SA protects network traffic between members of a multiple-sender IP multicast application 🦋 Some Many-to-Many Applications have a large number of senders, and in that case defining an individual IPsec SA for each sender is unmanageable 💀

3. IV Formation for Counter Modes with Group Keys 🌸

This section specifies a particular construction of the IV that lets a group of senders safely share a single IPsec SA 🫶 This construction conforms to the recommendations of [RFC5116]. The rationale for this method is in Appendix A. In the construction defined here, each IV is formed by concatenating a Sender Identifier (SID) field with a Sender-Specific IV (SSIV) field 🧚 The value of the SID MUST be unique for each sender, across all of the senders sharing a particular Security Association. The value of the SSIV field MUST be unique for each IV constructed by a particular sender for use with a particular SA. The SSIV MAY be chosen in any manner convenient to the sender, for example, successive values of a counter 💜 The leftmost bits of the IV contain the SID, and the remaining bits contain the SSIV. For example, Figure 1 shows the correct placement of an 8-bit SID within an Initialization Vector 🎀

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      !      SID      !                                               !
      +-+-+-+-+-+-+-+-+                  SSIV                         !
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

                      Figure 1.  IV with an 8-bit SID

The number of bits used by the SID may vary depending on group policy, though for each particular Security Association, each SID used with that SA MUST have the same length 🌈 To keep things interoperable, a conforming implementation MUST support SID lengths of 8, 12, and 16 bits 🍓 Also worth knowing: the size of the SID for an SA is a trade-off between how many possible senders you can have and how many packets each sending station can send using that SA 🤓

4. Group Key Management Conventions 👑

Group apps use a Group Key Management System (GKMS) made up of one or more Group Controller and Key Server (GCKS) entities [RFC3740] ✨ The GKMS hands out IPsec transform policy and the associated keying material to authorized group members. This document RECOMMENDS that the GKMS both allocate unique SIDs to group members and distribute them to those members using a GKM protocol like GDOI or GSAKMP 💖 The strategy the GKMS uses doesn't need to be mandated to get interoperability, since the GKMS is solely responsible for allocating SIDs for the group. Allocating SIDs sequentially is acceptable as long as the allocation method follows the requirements in this section 🦋

The following requirements apply to a GKMS that manages SIDs. One example of such a GKMS is [GDOI-UPDATE] 🔥

  • For each SA for which sender identifiers are used, the GKMS MUST NOT give the same sender identifier to more than one active group member. If the GKMS is uncertain as to the SID associated with a group member, it MUST allocate it a new one. If more than one entity within the GKMS is distributing sender identifiers, then the sets of identifiers distributed by each entity MUST NOT overlap 🙅‍♀️
  • If the entire set of sender identifiers has been exhausted, the GKMS MUST refuse to allow new group members to join. Alternatively, the GKMS could distribute replacement ESP or AH Security Associations to all group members. When replacement SAs are distributed, the GKMS could also distribute larger SID values so that more senders can be accommodated 🌸
  • The GKMS SHOULD allocate a single sender identifier for each group member, and issue this value to the sender for all group SAs for which that member is a sender. This strategy lets both the GKMS and the senders avoid managing SIDs on a per-SA basis 💅 It also simplifies the rekeying process, since SIDs don't need to be changed or re-issued along with replacement SAs during a rekey event ✨
  • When a GKMS determines that a particular group member is no longer a part of the group, then it MAY re-allocate any sender identifier associated with that group member for use with a new group member. In this case, the GKMS MUST first delete and replace any active AH or ESP SAs with which the SID may have been used. This is necessary to avoid re-use of an IV with the cipher key associated with the SA 🫶

5. Security Considerations 🔐

okay bestie, this is the section where the authors get super serious, so let's gooo 💅✨

This spec gives you a way to safely use crypto algorithms that need a unique IV (like a counter-mode block cipher) when there are several crypto devices that each make their own IVs 🦋. The trick is to split up the whole IV space so that each device gets its very own set of IV values, and nobody else touches them 🫶. If you follow the recommendations here, the security is the same as the regular single-sender case, which is so iconic 👑. And unlike CBC mode, CTR, GCM, GMAC, and CCM don't need IVs to be unpredictable 🌸. Main character energy for real.

The security of the whole group depends on every group member behaving correctly 🙈. Any member that uses an SID that wasn't given to it can make the whole system less secure 😭. Not okay!!

Same deal as a single sender 💖: a crypto device that keeps keying material across a reboot has to store a counter so that, once it's back up, it never reuses a counter 🧚. For this spec, that means it needs to store both the SID and the SSIV values used with a particular IPsec SA, plus the policy tied to that IPsec SA 📝.

A group member that reaches the end of its IV space MUST stop sending data traffic on that SA. 🛑 No exceptions, bestie!

This can happen if the member doesn't tell the GKMS in time for it to fix things (like giving the member a new SID or a new SA) 🍓, or if the GKMS just ignores the notification for some reason 💀. In that case, the member should re-register with the GCKS and expect to get the SAs it needs to keep participating in the group 🌈.

This spec doesn't deal with virtual machine rollbacks that could make the crypto device reuse nonce values 🙈. Not covered here!

Other security stuff for IPsec SAs with multiple senders is described in [RFC5374] 📚.

6. Acknowledgements 🎀

The authors wanna thank David Black, Sheela Rowles, and Alfred Hoenes for their super helpful comments and suggestions 🫶💜.

7. References 📚

7.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
  • [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

7.2. Informative References

  • [FIPS.800-38A.2001] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation", Special Publication FIPS PUB 800-38A, December 2001, <http://csrc.nist.gov/publications/>.
  • [GDOI-UPDATE] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", Work in Progress, October 2010.
  • [H52] Huffman, D., "A Method for the Construction of Minimum-Redundancy Codes", Proceedings of the IRE, Volume:40, Issue:9, On page(s): 1098-1101, ISSN: 0096-8390, September 1952, <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4051119>.
  • [RFC3170] Quinn, B. and K. Almeroth, "IP Multicast Applications: Challenges and Solutions", RFC 3170, September 2001.
  • [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
  • [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
  • [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
  • [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
  • [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
  • [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
  • [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms", RFC 4357, January 2006.
  • [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
  • [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
  • [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
  • [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
  • [RFC5528] Kato, A., Kanda, M., and S. Kanno, "Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms", RFC 5528, April 2009.
  • [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.

Appendix A. Rationale for the IV Formation for Counter Modes with Group Keys 🦋

okay so the two main ways to make sure IVs are unique when there are multiple senders are: give each sender a Sender Identifier (SID) in either the Salt or the explicit IV field 💅 (remember, the IV used by the crypto algorithm is the Salt and the explicit IV glued together 🧩).

The explicit IV field got picked for the SID because it's already right there in the packet 📦. If the SID lived in the Salt, a receiver would have to figure out which sender sent each AH or ESP packet 🕵️‍♀️. That could be done with the IP source address if AH or ESP goes straight over IP. But if something like UDP is used [RFC3948] (say, for NAT traversal 🌐), the method for inferring the sender has to account for that too 😩. Simpler to use the explicit IV field and skip inferring the sender from the packet entirely ✨.

The normative requirement that all SID values used with a particular Security Association have the same length isn't strictly necessary 🤷‍♀️, but it was added to keep implementation simple 🧸. Alternatively, the SID values could be codewords of a variable-length prefix-free code 🌈. That's still secure because the IVs stay distinct: no SID is a prefix of another, so any pair of IVs has some bits that differ 💜. If a Huffman code [H52] is used to form the SIDs, you can find an optimal set of SIDs, meaning the number of SIDs is maximized for a given distribution of SID lengths 📊. There are also simple ways to generate efficient prefix-free codes whose codewords are octet strings 🍓. Still, these methods were disallowed, because the authors chose simplicity over generality 💅🎀.

Appendix B. Example 🌸

okay bestie, here's a worked example of SID allocation and IV generation, exactly as defined in this document 🧁. A GCKS administrator decides the group has one SA shared by all senders 👑. The algorithm for the SA is AES-GCM with an 8-bit SID 💖.

When the first sender registers with the GCKS, it gets SID 1 🦋. It then sends AES-GCM encrypted packets with these IVs (shown in network byte order) ✨:

0x0100000000000001
0x0100000000000002
0x0100000000000003
...
0x01FFFFFFFFFFFFFF (final value)

The second sender registers with the GCKS, gets SID 2, and starts sending packets with these IVs 🌷:

0x0200000000000001
0x0200000000000002
0x0200000000000003
...
0x02FFFFFFFFFFFFFF (final value)

According to group policy, the GCKS might later hand out policy and keying material for a replacement SA 🔄. When senders start sending AES-GCM packets on the new SA, each sender keeps using the SID it was already given 🫶. For example, the sender with SID 2 would be sending on the new SA with IVs 0x0200000000000001, 0x0200000000000002, 0x0200000000000003, ... with a final value of 0x02FFFFFFFFFFFFFF 🎉.

Authors' Addresses 💌

David A. McGrew Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA

Phone: +1-408-525-8651 EMail: mcgrew@cisco.com

Brian Weis Cisco Systems 170 W. Tasman Drive San Jose, California 95134-1706 USA

Phone: +1-408-526-4796 EMail: bew@cisco.com

📦 where this page comes from