RFC 5282

Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol

📅 published August 2008, from ietf

RFC 5282: Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol 🎀

Okay, title block tea first ☕✨

Series: Network Working Group
Number: RFC 5282
Authors: D. Black (EMC) and D. McGrew
Category: Standards Track
Date: August 2008
Updates: RFC 4306 (IKEv2) 🫶
Obsoletes: nothing listed

Status of This Memo

Okay so this is an Internet standards track protocol for the Internet community 🌐 It's asking for discussion and suggestions for improvements, so bring your takes 💅 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share it with everyone 💖

Abstract

Authenticated encryption is when encryption and integrity happen in one single operation 🔐 These algorithms may also be called combined modes of an encryption cipher, or combined mode algorithms. This document explains how to use authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol 🦋

It also covers two specific authenticated encryption algorithms used with the IKEv2 Encrypted Payload: the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM), and AES in Counter with CBC-MAC Mode (AES CCM) ✨ Other documents may describe other authenticated encryption algorithms for the IKEv2 Encrypted Payload later on 🌈

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Structure of this Document ......................................4
   3. IKEv2 Encrypted Payload Data ....................................4
      3.1. AES GCM and AES CCM Initialization Vector (IV) .............6
      3.2. AES GCM and AES CCM Ciphertext (C) Construction ............6
   4. AES GCM and AES CCM Nonce (N) Format ............................7
   5. IKEv2 Associated Data (A) .......................................8
      5.1. Associated Data (A) Construction ...........................8
      5.2. Data Integrity Coverage ....................................8
   6. AES GCM and AES CCM Encrypted Payload Expansion .................9
   7. IKEv2 Conventions for AES GCM and AES CCM .......................9
      7.1. Keying Material and Salt Values ............................9
      7.2. IKEv2 Identifiers .........................................10
      7.3. Key Length ................................................10
   8. IKEv2 Algorithm Selection ......................................11
   9. Test Vectors ...................................................11
   10. RFC 5116 AEAD_* Algorithms ....................................11
      10.1. AES GCM Algorithms with 8- and 12-octet ICVs .............12
           10.1.1. AEAD_AES_128_GCM_8 ................................12
           10.1.2. AEAD_AES_256_GCM_8 ................................12
           10.1.3. AEAD_AES_128_GCM_12 ...............................12
           10.1.4. AEAD_AES_256_GCM_12 ...............................12
      10.2. AES CCM Algorithms with an 11-octet Nonce ................13
           10.2.1. AEAD_AES_128_CCM_SHORT ............................13
           10.2.2. AEAD_AES_256_CCM_SHORT ............................14
           10.2.3. AEAD_AES_128_CCM_SHORT_8 ..........................14
           10.2.4. AEAD_AES_256_CCM_SHORT_8 ..........................14
           10.2.5. AEAD_AES_128_CCM_SHORT_12 .........................14
           10.2.6. AEAD_AES_256_CCM_SHORT_12 .........................14
      10.3. AEAD_* Algorithms and IKEv2 ..............................15
   11. Security Considerations .......................................15
   12. IANA Considerations ...........................................16
   13. Acknowledgments ...............................................16
   14. References ....................................................17
      14.1. Normative References .....................................17
      14.2. Informative References ...................................17

1. Introduction 🌸

Authenticated encryption takes plaintext data and does encryption and integrity together in one operation, so you get ciphertext that comes with an integrity check [RFC5116] 🔐 That integrity check can be an Integrity Check Value (ICV) that's logically separate from the encrypted data, or it can be baked right into the encrypted data that gets produced. Same vibe as the combined modes of a block cipher, just with a different name 💅

Then there's Authenticated Encryption with Associated Data (AEAD). This one also protects extra data that goes along with the plaintext, but that extra data stays unencrypted 👀 This document shows how to use AEAD algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol. Two specific AEAD algorithms are covered: AES in Galois/Counter Mode (AES GCM) [GCM], and AES in Counter with CBC-MAC Mode (AES CCM) [CCM] 🦋

Now the history tea ☕ Version 1 of the Internet Key Exchange protocol (IKEv1) [RFC2409] is built on the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. In the ISAKMP header, the E (Encryption) bit says that every payload after the header is encrypted. But any data integrity checking for those payloads is done by a separate Hash Payload or Signature Payload (see Sections 3.1, 3.11, and 3.12 of [RFC2408]) 😤 That split between encryption and integrity is exactly why IKEv1 can't do authenticated encryption. So the first AES combined mode specs for IPsec were limited to the Encapsulating Security Payload (ESP) [RFC2406]. The current version of ESP is version 3, ESPv3 [RFC4303] 🧚

Version 2 of the Internet Key Exchange Protocol (IKEv2) [RFC4306] is the glow-up 💖 Its Encrypted Payload is based on the design of ESP, and it ties encryption and data integrity protection together in a way that makes AEAD algorithms possible to use ✨

1.1. Conventions Used in This Document

Here's the key words situation 📜 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] 🫶

The symbols or variables that stand for authenticated encryption and decryption inputs and outputs (K, N, P, A, and C) are defined in [RFC5116]. The SK_* symbols or variables that stand for specific IKEv2 keys are defined in [RFC4306] 🔑

2. Structure of this Document 🧩

This document is based on the RFCs that describe using AES GCM [RFC4106] and AES CCM [RFC4309] with ESP. So the intro stuff and the mode specs from those documents aren't repeated here, no copy-paste drama 🙈 This document follows the same structure as those two, and lots of its sections point out which sections of those documents they match up with. It also calls out any big differences implementers should know about. A lot of the text here was adapted from those two documents 💜

This document is built on the authenticated encryption interfaces, notation, and terminology from [RFC5116]. The big departure from [RFC4106] and [RFC4309] is this: those two RFCs describe separate ciphertext and integrity check outputs from the encryption operation, but [RFC5116] specifies a single ciphertext (C) output that includes the integrity check. That more general approach covers algorithms that produce one expanded ciphertext output with the integrity check built in, instead of separate ciphertext and integrity check outputs 🌈

For AES GCM and AES CCM, the [RFC5116] ciphertext (C) output of authenticated encryption is the [RFC4106] or [RFC4309] ciphertext output concatenated with the [RFC4106] or [RFC4309] Integrity Check Value (ICV) output. This document does not modify the AES GCM or AES CCM authenticated encryption algorithms specified in [RFC4106] and [RFC4309] 🎀

Part 1 of 4 done! Next up is Section 3 🦋

3. IKEv2 Encrypted Payload Data ✨

Okay bestie, this section is based on [RFC5116] and Section 3.14 of [RFC4306] 💅 For authenticated encryption algorithms used with the IKEv2 Encrypted Payload, this section updates Section 3.14 of [RFC4306] by replacing Figure 21 and the text that follows it (through the end of that section) with the contents of this section. 🦋 Section 3.14 of [RFC4306] also gets updated so it can allow a single authenticated encryption algorithm instead of a block cipher and a separate integrity check algorithm. Sections 3.1 and 3.2 of this document are specific to the AES GCM and AES CCM algorithms, so they do not update [RFC4306]. The updates to [RFC4306] made by this document have no effect when authenticated encryption algorithms are neither proposed nor used. 💖

The IKEv2 Encrypted Payload Data structure applies to all authenticated encryption algorithms, and it's the exact same structure used with ESP. 😭 When an authenticated encryption algorithm is used, the IKEv2 Encrypted Payload is made of the payload header fields, then an Initialization Vector (IV) field, then a Ciphertext (C) field that includes an integrity check, as shown in Figure 1. 🎀

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  !C!  RESERVED   !         Payload Length        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                     Initialization Vector                     !
   !  (length is specified by authenticated encryption algorithm)  !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        Ciphertext                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Figure 1. IKEv2 Encrypted Payload Data for Authenticated Encryption

The Next Payload, C bit, and Payload Length fields are unchanged from [RFC4306]. 🌸

The contents of the Initialization Vector (IV) field are specified by the authenticated encryption algorithm. See Sections 3.1 and 4 (below) for AES GCM and AES CCM. 🧚

The Ciphertext field is the output of an authenticated encryption operation (see Section 2.1 of [RFC5116]) on the following inputs:

The secret key (K) is the cipher key obtained from the SK_ei or SK_er key, whichever is appropriate, see [RFC4306]. The authenticated encryption algorithm describes how to get the cipher key from SK_ei or SK_er. For AES GCM and AES CCM, see Section 7.1 (below). 🔑
The nonce (N) is specified by the authenticated encryption algorithm. For AES GCM and AES CCM, see Section 4 (below). When decrypting an Encrypted Payload, a receiver builds the nonce from the IV in the Encrypted Payload, using rules specific to the authenticated encryption algorithm. See Sections 3.1 and 4 (below) for AES GCM and AES CCM. 💜
The plaintext (P) is the concatenation of the IKE Payloads to be encrypted, plus the Padding (if any) and the Pad Length, as shown in Figure 2 (below). The plaintext structure in Figure 2 applies to all encryption algorithms used with the IKEv2 Encrypted Payload, and it's unchanged from [RFC4306]. ✨
The associated data (A) is described in Section 5 (below). 🌈

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                 IKE Payloads to be Encrypted                  ~
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !               !             Padding (0-255 octets)            !
   +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
   !                                               !  Pad Length   !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 2. IKEv2 Encrypted Payload Plaintext (P)

The IKE Payloads are as specified in [RFC4306]. 📦

Padding MAY contain any value chosen by the sender. 🎀

Pad Length is the number of octets in the Padding field. There are no alignment requirements on the length of the Padding field, so the recipient MUST accept any amount of Padding up to 255 octets. 💅

The ciphertext output of authenticated encryption algorithms, as defined by [RFC5116], includes data that lets you check the integrity and authenticity of the ciphertext and associated data. 🫶 So there's no need for a separate Integrity Check Value (ICV) field in the IKEv2 Encrypted Payload Data structure. 💀

3.1. AES GCM and AES CCM Initialization Vector (IV) 🌸

This section is based on Section 3.1 of [RFC4106] and Section 3.1 of [RFC4309]. The Initialization Vector requirements are shared by AES GCM and AES CCM, and they're the same as the requirements for ESP. 🦋

The Initialization Vector (IV) MUST be eight octets. The IV MUST be chosen by the encryptor in a way that makes sure the same IV value is used only once for a given key. The encryptor MAY generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). 🔥

3.2. AES GCM and AES CCM Ciphertext (C) Construction 🧚

This section is based on Section 6 of [RFC4106] and Section 3.1 of [RFC4309], with generalizations to match the interfaces specified in [RFC5116]. The constructions for AES GCM and AES CCM are different, but in each case the construction is the same as for ESP. 👑

For AES GCM and AES CCM, the Ciphertext field consists of the output of the authenticated encryption algorithm. (Note that this field incorporates integrity check data.) ✨

The AES GCM ICV consists solely of the AES GCM Authentication Tag. Implementations MUST support a full-length 16 octet ICV, MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths. 💖

AES CCM provides an encrypted ICV. Implementations MUST support ICV sizes of 8 octets and 16 octets. Implementations MAY also support 12 octet ICVs and MUST NOT support other ICV lengths. 🍓

4. AES GCM and AES CCM Nonce (N) Format 🌈

Specific authenticated encryption algorithms MAY use different nonce formats, but they SHOULD use the default nonce format specified in this section. 🎀

The default nonce format uses partially implicit nonces (see Section 3.2.1 of [RFC5116]) as follows:

The implicit portion of the nonce is the salt that is part of the IKEv2 Keying Material shared by the encryptor and decryptor (see Section 7.1). The salt is not included in the IKEv2 Encrypted Payload. 🧂
The explicit portion of the nonce is the IV that is included in the IKEv2 Encrypted Payload. 🦋

When this default nonce format is used, both the encryptor and decryptor build the nonce by concatenating the salt with the IV, in that order. 💅

For the use of AES GCM with the IKEv2 Encrypted Payload, this default nonce format MUST be used and a 12 octet nonce MUST be used. This format matches the one specified in Section 4 of [RFC4106], which gives compatibility between AES GCM in IKEv2 and in ESP. All of the requirements of Section 4 of [RFC4106] apply to the use of AES GCM with the IKEv2 Encrypted Payload. 🔥

For the use of AES CCM with the IKEv2 Encrypted Payload, this default nonce format MUST be used and an 11 octet nonce MUST be used. This format matches the one specified in Section 4 of [RFC4309], which gives compatibility between AES CCM in IKEv2 and in ESP. All of the requirements of Section 4 of [RFC4309] apply to the use of AES CCM with the IKEv2 Encrypted Payload. 👑

5. IKEv2 Associated Data (A) 💜

This section is based on Section 5 of [RFC4106] and Section 5 of [RFC4309], and both of them call associated data Additional Authenticated Data (AAD). The associated data construction described here applies to all authenticated encryption algorithms, but it differs from the construction used with ESP because IKEv2 requires different data integrity coverage. 🫶

5.1. Associated Data (A) Construction 🌸

The associated data (A) MUST consist of the partial contents of the IKEv2 message, starting from the first octet of the Fixed IKE Header through the last octet of the Payload Header of the Encrypted Payload (i.e., the fourth octet of the Encrypted Payload), as shown in Figure 3. This includes any payloads that sit between the Fixed IKE Header and the Encrypted Payload. 🧚

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                         IKEv2 Header                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                   Unencrypted IKE Payloads                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ! Next Payload  !C!  RESERVED   !         Payload Length        !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 3. IKEv2 Encrypted Payload Associated Data (A) for
                      Authenticated Encryption

The Initialization Vector and Ciphertext fields shown in Figure 1 (above) MUST NOT be included in the associated data. 🙈

5.2. Data Integrity Coverage 🔥

The data integrity coverage of the IKEv2 Encrypted Payload covers the entire IKEv2 message that contains the Encrypted Payload. When an authenticated encryption algorithm is used with the Encrypted Payload, this coverage works like this:

The associated data (A) covers the portion of the IKEv2 message starting from the first octet of the Fixed IKE Header through the last octet of the Payload Header of the Encrypted Payload (fourth octet of the Encrypted Payload). This includes any Payloads between the Fixed IKE Header and the Encrypted Payload. The Encrypted Payload is always the last payload in an IKEv2 message [RFC4306]. 💅
The IV is an input to the authenticated encryption algorithm's integrity check. A successful integrity check at the receiver verifies that the correct IV was used, which gives data integrity coverage for the IV. 🦋
The plaintext (IKE Payloads, Padding and Pad Length) is covered by the authenticated encryption algorithm's integrity check. 💖

6. AES GCM and AES CCM Encrypted Payload Expansion 🌈

The expansion described in Section 7 of [RFC4106] and Section 6 of [RFC4309] applies to the use of the AES GCM and AES CCM combined modes with the IKEv2 Encrypted Payload. See Section 7 of [RFC4106] and Section 6 of [RFC4309]. 🍓

7. IKEv2 Conventions for AES GCM and AES CCM 👑

This section describes the conventions used to generate keying material and salt values for use with AES GCM and AES CCM using the IKEv2 [RFC4306] protocol. The identifiers and attributes needed to use AES GCM and AES CCM with the IKEv2 Encrypted Payload are also specified. 🧚

7.1. Keying Material and Salt Values 🔑

okay so this section is based on Section 8.1 of [RFC4106] and Section 7.1 of [RFC4309] 📚. AES GCM and AES CCM have different Keying Material and Salt Values, but they're shaped the same way as the ones ESP uses ✨.

IKEv2 uses a Pseudo-Random Function (PRF) to derive keying material 💖. It runs the PRF over and over to make as much keying material as needed, and then grabs the pieces for each purpose without caring where one PRF output ends and the next begins. See Section 2.14 of [RFC4306] if you want the full scoop 🧚.

This subsection explains how the key derivation from Section 2.14 of [RFC4306] gets used to make keying material for AES GCM and AES CCM 🦋. When AES GCM or AES CCM is used with the IKEv2 Encrypted Payload, the SK_ai and SK_ar integrity protection keys aren't used at all, so each of them MUST be treated as having a size of zero (0) octets 🙈. The SK_ei and SK_er encryption keys do carry extra salt bytes, and their size and format MUST be:

For AES GCM, each encryption key has the size and format of the "KEYMAT requested" material specified in Section 8.1 of [RFC4106] for the AES key size being used. For example, if the AES key size is 128 bits, each encryption key is 20 octets, consisting of a 16-octet AES cipher key followed by 4 octets of salt. 🌸
For AES CCM, each key has the size and format of the "KEYMAT requested" material specified in Section 7.1 of [RFC4309] for the AES key size being used. For example, if the AES key size is 128 bits, each encryption key is 19 octets, consisting of a 16-octet AES cipher key followed by 3 octets of salt. 💜

7.2. IKEv2 Identifiers 🪪

this section is unique to the IKEv2 Encrypted Payload usage of AES GCM and AES CCM 💅. It reuses the identifiers that were already used to negotiate ESP usage of AES GCM and AES CCM, so nothing brand new here, just a glow-up ✨.

These identifiers were allocated by IANA ages ago, and they're used to negotiate AES GCM and AES CCM as the Encryption (ENCR) Transform for IKEv2 (aka for use with the IKEv2 Encrypted Payload) 🎀:

      14 for AES CCM with an 8-octet ICV;
      15 for AES CCM with a 12-octet ICV;
      16 for AES CCM with a 16-octet ICV;

      18 for AES GCM with an 8-octet ICV;
      19 for AES GCM with a 12-octet ICV; and
      20 for AES GCM with a 16-octet ICV.

A 16-octet ICV size SHOULD be used with IKEv2 🫶. The higher level of security it gives, compared to the smaller ICV sizes, fits IKEv2's key exchange and related functionality really well 👑.

Generally speaking, the use of 12-octet ICVs (values 15 and 19) is NOT RECOMMENDED 🙅‍♀️. The point is to cut down on the number of ICV size options. If an ICV size larger than 8 octets is appropriate, 16-octet ICVs SHOULD be used 🔥.

7.3. Key Length 📏

This section is based on Section 8.4 of [RFC4106] and Section 7.4 of [RFC4309] 📖. The Key Length requirements are the same for AES GCM and AES CCM, and they're identical to the key length requirements for ESP 💖.

AES supports three key lengths, so the Key Length attribute MUST be specified whenever any of the identifiers for AES GCM or AES CCM from Section 7.2 of this document is used 🧚. The Key Length attribute MUST have a value of 128, 192, or 256 ✨. The use of the value 192 is NOT RECOMMENDED 💀. If an AES key larger than 128 bits is appropriate, a 256-bit AES key SHOULD be used, which also trims down the number of AES key length options 🦋.

8. IKEv2 Algorithm Selection 🧩

this section applies to the use of any authenticated encryption algorithm with the IKEv2 Encrypted Payload, and it's unique to that usage 💜.

IKEv2 (Section 3.3.3 of [RFC4306]) says that both an encryption algorithm and an integrity checking algorithm are required for an IKE SA (Security Association) 🤓. This document updates [RFC4306] so that when an authenticated encryption algorithm is selected as the encryption algorithm for any SA (IKE or ESP), an integrity algorithm MUST NOT be selected for that SA 🚫. It also updates [RFC4306] so that if all of the encryption algorithms in any proposal are authenticated encryption algorithms, then the proposal MUST NOT propose any integrity transforms 🙈.

9. Test Vectors 🧪

See Section 9 of [RFC4106] and Section 8 of [RFC4309] for references that provide AES GCM and AES CCM test vectors 📚✨.

10. RFC 5116 AEAD_* Algorithms 🌈

this section adds new algorithms to the AEAD_* algorithm framework defined in [RFC5116] so it can cover AES GCM and AES CCM with IKEv2 🎀. An AEAD_* algorithm doesn't have any attributes or parameters. Each AEAD_* algorithm identifier defined in this document completely specifies the AES key size and the ICV size it uses. For example, AEAD_AES_128_GCM uses a 128-bit AES key and a 16-octet ICV 💅.

Covering the AES GCM and AES CCM authenticated encryption algorithms used with IKEv2 needs eight additional AEAD_* algorithms, on top of the four already in [RFC5116] 🫧:

Four AEAD_* algorithms are specified to allow 8- and 12-octet ICVs to be used with the AES GCM algorithms in [RFC5116] 💖.
The version of AES CCM used with IPsec (see [RFC4309]) uses an 11-octet nonce instead of the 12-octet nonce used by the version of AES CCM specified in [RFC5116]. Six AEAD_* algorithms are specified for this short nonce version of AES CCM 🦋.

This document recommends against the use of 192-bit AES keys, so it does not specify AEAD_* algorithms for 192-bit AES keys 🙅‍♀️.

10.1. AES GCM Algorithms with 8- and 12-octet ICVs 🍓

The following four AEAD_* algorithms are identical to the AEAD_* algorithms specified in [RFC5116], except that they use an 8-octet ICV instead of a 16-octet ICV 🌸.

10.1.1. AEAD_AES_128_GCM_8

This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used 💜.

An AEAD_AES_128_GCM_8 ciphertext is exactly 8 octets longer than its corresponding plaintext ✨.

10.1.2. AEAD_AES_256_GCM_8

This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116]), except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used 🔥.

An AEAD_AES_256_GCM_8 ciphertext is exactly 8 octets longer than its corresponding plaintext 🫶.

10.1.3. AEAD_AES_128_GCM_12

This algorithm is identical to AEAD_AES_128_GCM (see Section 5.1 of [RFC5116]), except that the tag length, t, is 12, and an authentication tag with a length of 12 octets (64 bits) is used 🎀.

An AEAD_AES_128_GCM_12 ciphertext is exactly 12 octets longer than its corresponding plaintext 🦋.

10.1.4. AEAD_AES_256_GCM_12

This algorithm is identical to AEAD_AES_256_GCM (see Section 5.2 of [RFC5116]), except that the tag length, t, is 12 and an authentication tag with a length of 12 octets (64 bits) is used 💅.

An AEAD_AES_256_GCM_12 ciphertext is exactly 12 octets longer than its corresponding plaintext 👑.

10.2. AES CCM Algorithms with an 11-octet Nonce 🌙

The following four AEAD algorithms use the AES CCM algorithms with an 11 octet nonce as specified in [RFC4309] ✨.

10.2.1. AEAD_AES_128_CCM_SHORT

The AEAD_AES_128_CCM_SHORT authenticated encryption algorithm is identical to the AEAD_AES_128_CCM algorithm (see Section 5.3 of [RFC5116]), except that it uses a nonce that is one octet shorter 🧚. AEAD_AES_128_CCM_SHORT works as specified in [CCM]. It uses AES-128 as the block cipher, by providing the key, nonce, associated data, and plaintext to that mode of operation 🔑. The formatting and counter generation function are as specified in Appendix A of [CCM], and the values of the parameters identified in that appendix are as follows:

      the nonce length n is 11,

      the tag length t is 16, and

      the value of q is 3.

An authentication tag with a length of 16 octets (128 bits) is used. The AEAD_AES_128_CCM_SHORT ciphertext consists of the ciphertext output of the CCM encryption operation concatenated with the authentication tag output of the CCM encryption operation. Test cases are provided in [CCM]. The input and output lengths are as follows 🌈:

      K_LEN is 16 octets,

      P_MAX is 2^24 - 1 octets,

      A_MAX is 2^64 - 1 octets,

      N_MIN and N_MAX are both 11 octets, and

      C_MAX is 2^24 + 15 octets.

An AEAD_AES_128_CCM_SHORT ciphertext is exactly 16 octets longer than its corresponding plaintext 💖.

10.2.2. AEAD_AES_256_CCM_SHORT

This algorithm is identical to AEAD_AES_128_CCM_SHORT, but with the following differences 🌸:

      K_LEN is 32 octets, instead of 16, and

      AES-256 CCM is used instead of AES-128 CCM.

An AEAD_AES_256_CCM_SHORT ciphertext is exactly 16 octets longer than its corresponding plaintext 🫶.

10.2.3. AEAD_AES_128_CCM_SHORT_8

This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used 🦋.

An AEAD_AES_128_CCM_SHORT_8 ciphertext is exactly 8 octets longer than its corresponding plaintext 🎀.

10.2.4. AEAD_AES_256_CCM_SHORT_8

This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that the tag length, t, is 8, and an authentication tag with a length of 8 octets (64 bits) is used 💜.

An AEAD_AES_256_CCM_SHORT_8 ciphertext is exactly 8 octets longer than its corresponding plaintext 🔥.

10.2.5. AEAD_AES_128_CCM_SHORT_12

This algorithm is identical to AEAD_AES_128_CCM_SHORT, except that the tag length, t, is 12, and an authentication tag with a length of 12 octets (64 bits) is used 🧚.

An AEAD_AES_128_CCM_SHORT_12 ciphertext is exactly 12 octets longer than its corresponding plaintext ✨.

10.2.6. AEAD_AES_256_CCM_SHORT_12

This algorithm is identical to AEAD_AES_256_CCM_SHORT, except that the tag length, t, is 12, and an authentication tag with a length of 8 octets (64 bits) is used 🌙.

An AEAD_AES_256_CCM_SHORT_12 ciphertext is exactly 12 octets longer than its corresponding plaintext 💅.

10.3. AEAD_* Algorithms and IKEv2 🎀

okay so this table is the full list of AES CCM and AES GCM AEAD_* algorithms that IKEv2 can negotiate 💅 It also shows the ENCR Identifier and Key Length Attribute combo you use to negotiate each one ✨

+--------------------------+------------------+-------------+
| AEAD algorithm           | ENCR Identifier  | Key Length  |
+--------------------------+------------------+-------------+
| AEAD_AES_128_GCM         |        20        |     128     |
| AEAD_AES_256_GCM         |        20        |     256     |
| AEAD_AES_128_GCM_8       |        18        |     128     |
| AEAD_AES_256_GCM_8       |        18        |     256     |
| AEAD_AES_128_GCM_12      |        19        |     128     |
| AEAD_AES_256_GCM_12      |        19        |     256     |
| AEAD_AES_128_CCM_SHORT   |        16        |     128     |
| AEAD_AES_256_CCM_SHORT   |        16        |     256     |
| AEAD_AES_128_CCM_SHORT_8 |        14        |     128     |
| AEAD_AES_256_CCM_SHORT_8 |        14        |     256     |
| AEAD_AES_128_CCM_SHORT_12|        15        |     128     |
| AEAD_AES_256_CCM_SHORT_12|        15        |     256     |
+--------------------------+------------------+-------------+

each of the AEAD_* algorithms above is identical to the algorithm you get from the ENCR Identifier and Key Length Attribute pair on the same line of the table 🦋 same vibe, same math, different name 🫶

11. Security Considerations 💀

okay this one is SERIOUS bestie 😭 for authenticated encryption security considerations, you need to read the ENTIRE [RFC5116], not just its security considerations section 🙈 there are important security considerations hiding outside that section, so do not skip them 🔥

the security considerations for using AES GCM and AES CCM with ESP also apply when you use these algorithms with the IKEv2 Encrypted Payload 🔐 check out Section 10 of [RFC4106] and Section 9 of [RFC4309] ✨ using AES GCM and AES CCM with IKEv2 does not add any new security considerations beyond the ones you already get with ESP, so that part is giving consistency 💜

for IKEv2 security considerations, go read Section 5 of [RFC4306] 📖💅

12. IANA Considerations 🌸

the Encryption Transform identifiers from Section 7.2 were already assigned by IANA for ESP 🦋 this document just extends their use to IKEv2 for the Encrypted Payload 💖 this usage extension needs no IANA actions, so it's giving easy mode 🍓

IANA added the following entries to the Authenticated Encryption with Associated Data (AEAD) Parameters Registry 👑

+--------------------------+----------------+--------------------+
| Name                     |  Reference     | Numeric Identifier |
+--------------------------+----------------+--------------------+
| AEAD_AES_128_GCM_8       | Section 10.1.1 |          5         |
| AEAD_AES_256_GCM_8       | Section 10.1.2 |          6         |
| AEAD_AES_128_GCM_12      | Section 10.1.3 |          7         |
| AEAD_AES_256_GCM_12      | Section 10.1.4 |          8         |
| AEAD_AES_128_CCM_SHORT   | Section 10.2.1 |          9         |
| AEAD_AES_256_CCM_SHORT   | Section 10.2.2 |         10         |
| AEAD_AES_128_CCM_SHORT_8 | Section 10.2.3 |         11         |
| AEAD_AES_256_CCM_SHORT_8 | Section 10.2.4 |         12         |
| AEAD_AES_128_CCM_SHORT_12| Section 10.2.5 |         13         |
| AEAD_AES_256_CCM_SHORT_12| Section 10.2.6 |         14         |
+--------------------------+----------------+--------------------+

an IANA registration of an AEAD algorithm does NOT mean IANA is endorsing that algorithm or its security 🙅‍♀️ being in the registry is not a stamp of approval, periodt 💅

13. Acknowledgments 🫶

for AES GCM and AES CCM acknowledgments, see Section 13 of [RFC4106] and Section 12 of [RFC4309] 🎀

also, big thank yous to Charlie Kaufman, Pasi Eronen, Tero Kivinen, Steve Kent, and Alfred Hoenes for their comprehensive reviews of this document 👑✨ they absolutely ate this review process 🍓

this document was originally prepared using 2-Word-v2.0.template.dot, created by Joe Touch 🧚

14. References 📚

14.1. Normative References

[CCM]     Dworkin, M., "NIST Special Publication 800-38C: The CCM
          Mode for Authentication and Confidentiality", U.S. National
          Institute of Standards and Technology,
          <http://csrc.nist.gov/publications/nistpubs/800-38C/
          SP800-38C.pdf>, updated July 2007.

[GCM]     Dworkin, M., "NIST Special Publication 800-38D:
          Recommendation for Block Cipher Modes of Operation:
          Galois/Counter Mode (GCM) and GMAC.", U.S. National
          Institute of Standards and Technology, November 2007,
          <http://csrc.nist.gov/publications/nistpubs/800-38D/
          SP-800-38D.pdf>, November 2007.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
          (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
          4106, June 2005.

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
          4303, December 2005.

[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
          RFC 4306, December 2005.

[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
          Mode with IPsec Encapsulating Security Payload (ESP)", RFC
          4309, December 2005.

[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
          Encryption", RFC 5116, January 2008.

14.2. Informative References

[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
          Payload (ESP)", RFC 2406, November 1998.

[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
          "Internet Security Association and Key Management Protocol
          (ISAKMP)", RFC 2408, November 1998.

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
          (IKE)", RFC 2409, November 1998.

Author's Addresses 🧚

David L. Black
EMC Corporation
176 South Street
Hopkinton, MA 10748

Phone: +1 (508) 293-7953
EMail: black_david@emc.com

David A. McGrew
Cisco Systems, Inc.
510 McCarthy Blvd.
Milpitas, CA 95035

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

Full Copyright Statement 💜

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌈

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

📦 where this page comes from

ietf: rfc5282 2008-08
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms