RFC 5930

Using AES-CTR with IKEv2 💖

okay bestie, the header tea first 🎀

• This is RFC 5930, published in July 2010 🌸
• The authors are Sean Shen (Huawei), Yu Mao (Hangzhou H3C Tech. Co., Ltd.), and N S Srinivasa Murthy (Freescale Semiconductor) 👑
• It's Informational (so it's for info, not a Standards Track thing) and the ISSN is 2070-1721 ✨
• The header doesn't list anything it obsoletes or updates 🦋

---

Abstract ✨

okay so this doc explains how IKEv2 (the protocol that sets up and maintains IPsec security associations) can use AES-CTR (Counter Mode) with an explicit Initialization Vector 🔐 It's for encrypting the IKEv2 exchanges that come after the IKE_SA_INIT exchange. Iconic, honestly 💅

Status of This Memo 🌈

so, this doc is not an Internet Standards Track spec. It's just published for info 🫶

It's a product of the IETF, it represents the consensus of the IETF community, and it got public review and was approved for publication by the IESG. Not every IESG-approved doc is a candidate for any level of Internet Standard, though. You can check Section 2 of RFC 5741 for that 🤓

If you want the current status, errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc5930 💜

Copyright Notice 💖

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the publication date. Read them carefully, because they explain your rights and restrictions for this doc 📜 Any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 💅

Table of Contents 🧚

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. IKEv2 Encrypted Payload .........................................3
   3. IKEv2 Conventions ...............................................4
   4. Security Considerations .........................................4
   5. IANA Considerations .............................................4
   6. Acknowledgments .................................................4
   7. References ......................................................5
      7.1. Normative References .......................................5
      7.2. Informative References .....................................5

1. Introduction ✨

okay so the Internet Key Exchange version 2 (IKEv2) protocol [RFC4306] is part of IPsec. It does mutual authentication and sets up and maintains security associations (SAs) 🔐

[RFC4307] is the one that lists which algorithms IKEv2 implementations have to support, plus the ones they SHOULD support since they might get promoted to mandatory later 👀 It says an implementation "SHOULD" support Advanced Encryption Standard [AES] Counter Mode [MODES] (AES-CTR) as a Transform Type 1 algorithm (encryption) 🦋

ngl, here's the gap: even though [RFC4307] says AES-CTR SHOULD be supported by IKEv2, no existing doc actually explains how IKEv2 supports it. That's where this doc comes in, giving the spec and usage of AES-CTR Counter Mode for IKEv2 💖

Also, implementers need to think hard before picking AES-CTR over the mandatory algorithms in [RFC4307]. The performance gains are minimal in the IKEv2 context, and those gains might get wiped out by the Counter Mode risk of a small, hard-to-spot implementation bug that causes total security failure 😭 yikes

1.1. Conventions Used in This Document 🎀

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. IKEv2 Encrypted Payload 🌸

Section 3.14 of IKEv2 [RFC4306] explains the IKEv2 Encrypted Payload 💅 It's denoted SK{...} and it holds other IKEv2 payloads in encrypted form 🔐

The payload has an Initialization Vector (IV) whose length is set by the negotiated encryption algorithm. It also has Integrity Checksum data. Neither of these two fields is encrypted, so no hiding there 👀

The IV field MUST be 8 octets when AES-CTR is used for IKEv2 encryption. The rules for this IV are the same as what Section 3.1 of [RFC3686] specifies for the Encapsulating Security Payload (ESP) 🫶

IKEv2 needs Integrity Check Data for the Encrypted Payload, as described in Section 3.14 of [RFC4306]. The integrity algorithm choices are defined in [RFC4307] or in any docs that update it later 🔥

When AES-CTR is used in IKEv2, no padding is needed. The Padding field of the Encrypted Payload SHOULD be empty, and the Pad Length field SHOULD be zero 🧚 But according to [RFC4306], the recipient MUST accept any length that results in proper alignment, so be chill about it ✨ Also worth noting: the ESP [RFC4303] Encrypted Payload needs alignment on a 4-byte boundary, while the IKEv2 [RFC4306] Encrypted Payload doesn't have that requirement 🦋

The Encrypted Payload is the XOR of the plaintext and the key stream. The key stream comes from feeding counter blocks into the AES algorithm 💜 The AES counter block is 128 bits: a 4-octet Nonce, then an 8-octet Initialization Vector, then a 4-octet Block Counter, in that order. The Block Counter starts at one and goes up by one to generate each next chunk of key stream 🌈 The detailed counter block rules are the same as the ones in Section 4 of [RFC3686] 💖

3. IKEv2 Conventions 🎀

AES-CTR for the IKE SA gets negotiated the same way as AES-CTR for ESP, no surprises 💅 The Transform ID (ENCR_AES_CTR) is the same, the key length transform attribute gets used the same way, and the keying material (the actual key plus the nonce) gets derived the same way too 🔑 See Section 5 of [RFC3686] for the detailed descriptions 📜

4. Security Considerations 🔐

Okay, this section is serious, so listen up 🚨 The security considerations in Section 7 of [RFC3686] are entirely relevant to this doc too. The ones about fresh keys and integrity protection in Section 7 of [RFC3686] totally apply to using AES-CTR in IKEv2, so check [RFC3686] for the details 💀

Since static keys are never used in IKEv2 for the IKE_SA, and integrity protection is mandatory for the IKE_SA, these issues don't apply to AES-CTR in IKEv2 when it's protecting the IKE_SA 🛡️

Also, AES has a 128-bit block size no matter which mode you use. That means the ciphertext from AES encryption becomes distinguishable from random values after 2^64 blocks get encrypted with a single key. An IKEv2 SA can't carry that much data, though, because of the size limit on the message ID of the IKEv2 message and the message ID requirements in Section 4 of [RFC4306]. So this issue isn't a concern here 🙌

For generic attacks on AES, like brute force or precalculations, the key-size requirements give reasonable security [Recommendations] 🔐

5. IANA Considerations 🌸

IANA [IANA-Para] has assigned an Encryption Algorithm Transform ID for AES-CTR encryption with an explicit IV for IKEv2: the number is 13 and the name is ENCR_AES_CTR 🦋 IANA also added a reference to this RFC in that entry ✨

6. Acknowledgments 💜

The authors thank Yaron Sheffer, Paul Hoffman, Tero Kivinen, and Alfred Hoenes for their direction and comments on this doc 🫶

This doc specifies how to use AES-CTR with IKEv2, which is similar to how AES-CTR gets used with ESP as specified in [RFC3686]. For the same descriptions and definitions, the reader is referred to [RFC3686] 📜 The authors also thank Russ Housley for providing the document 🎀

During the production and modification of this doc, both Huawei and CNNIC supported one of the authors, Sean Shen. Both are appreciated as affiliations of the author 🌈

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.

[RFC3686]         Housley, R., "Using Advanced Encryption Standard
                  (AES) Counter Mode With IPsec Encapsulating
                  Security Payload (ESP)", RFC 3686, January 2004.

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

[RFC4307]         Schiller, J., "Cryptographic Algorithms for Use in
                  the Internet Key Exchange Version 2 (IKEv2)",
                  RFC 4307, December 2005.

[AES]             National Institute of Standards and Technology,
                  "Advanced Encryption Standard (AES)", FIPS PUB 197,
                  November 2001, <http://csrc.nist.gov/
                  publications/fips/fips197/fips-197.pdf>.

[IANA-Para]       Internet Assigned Numbers Authority, "Internet Key
                  Exchange Version 2 (IKEv2) Parameters",
                  <http://www.iana.org>.

[MODES]           Dworkin, M., "Recommendation for Block Cipher Modes
                  of Operation -- Methods and Techniques", NIST
                  Special Publication 800-38A, December 2001,
                  <http://csrc.nist.gov/publications/nistpubs/
                  800-38a/sp800-38a.pdf>.

7.2. Informative References 🧚

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

[Recommendations] Barker, E., Barker, W., Burr, W., Polk, W., and M.
                  Smid, "Recommendation for Key Management - Part 1:
                  General (Revised)", NIST Special
                  Publication 800-57, March 2007, <http://
                  csrc.nist.gov/publications/nistpubs/800-57/
                  sp800-57-Part1-revised2_Mar08-2007.pdf>.

Authors' Addresses 🦋

Sean Shen
Huawei
4, South 4th Street, Zhongguancun
Beijing  100190
China

EMail: shenshuo@cnnic.cn


Yu Mao
Hangzhou H3C Tech. Co., Ltd.
Oriental Electronic Bld., No. 2
Chuangye Road
Shang-Di Information Industry
Hai-Dian District
Beijing  100085
China

EMail: yumao9@gmail.com


N S Srinivasa Murthy
Freescale Semiconductor
UMA PLAZA, NAGARJUNA CIRCLE, PUNJAGUTTA
HYDERABAD  500082
INDIA

EMail: ssmurthy.nittala@freescale.com