RFC 4305

RFC 4305: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) 🎀

Okay bestie, this one is from the Network Working Group 🧚 and it was written by D. Eastlake 3rd at Motorola Laboratories 💅. It came out in December 2005 and it's on the Standards Track 🔥, which means it's an actual official spec and not just a vibe. It obsoletes RFC 2404 and RFC 2406, so those older docs got replaced by this one 🦋.

Status of This Memo ✨

This document is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions for improvements 💖. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright Notice ✨

Copyright (C) The Internet Society (2005).

Abstract 🦋

IPsec is a whole family of protocols that uses different cryptographic algorithms to deliver its security services 🔐. ESP and AH are two ways to protect data sent over an IPsec Security Association (SA) 💜. Here's the catch: different implementations need to actually work together, so there has to be a set of mandatory-to-implement algorithms, meaning at least one algorithm that every implementation is guaranteed to have 🫶. This doc lists the current mandatory-to-implement algorithms for ESP and AH, and it also lists algorithms that should be implemented, since they might get promoted to mandatory later 👑.

Table of Contents 🌸

1. Introduction ....................................................2
2. Requirements Terminology ........................................3
3. Algorithm Selection .............................................3
   3.1. Encapsulating Security Payload .............................3
        3.1.1. ESP Encryption and Authentication Algorithms ........4
        3.1.2. ESP Combined Mode Algorithms ........................4
   3.2. Authentication Header ......................................5
4. Security Considerations .........................................5
5. Acknowledgement .................................................5
6. Changes from RFC 2402 and 2406 ..................................6
7. Normative References ............................................6
8. Informative References ..........................................7

1. Introduction 🎀

ESP and AH are the two mechanisms for protecting data sent over an IPsec Security Association (SA) [IPsec, ESP, AH] 🔐. For implementations from different vendors to interoperate, we need a set of mandatory-to-implement algorithms, so that there's at least one algorithm all implementations will have available 🤝. This document defines the current set of mandatory-to-implement algorithms for ESP and AH, and it also specifies algorithms that should be implemented because they may be promoted to mandatory at some future time ✨.

Cryptography is a constantly moving target, bestie 😭. New algorithms keep popping up and existing ones keep getting attacked 💀. An algorithm that's strong today might be shown to be weak tomorrow. Because of that, the mandatory-to-implement choice should be conservative, so it's less likely to get compromised fast 🛡️. Performance matters too, since lots of IPsec deployments are in environments where performance is a real concern ⚡.

Also, the mandatory-to-implement algorithms might need to change over time as the world changes 🌍. That's why the choice of them isn't included in the main IPsec, ESP, or AH specs. It lives here instead, so when the algorithm choices change, only this document should need updating 🦋.

Ideally, tomorrow's mandatory-to-implement algorithm is already in most IPsec implementations by the time it becomes mandatory 🙌. To help with that, this document tries to identify such algorithms as they're known today. But there's no guarantee that the ones we think will become mandatory will actually end up that way 🙈. Every algorithm known today is subject to cryptographic attack and could get broken in the future 💔.

2. Requirements Terminology 💅

The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119] 📖.

We define a few extra terms here, babe:

• SHOULD+ means the same as SHOULD. The difference is that an algorithm marked SHOULD+ will probably get promoted to a MUST at some future time 🔥.
• SHOULD- means the same as SHOULD. The difference is that an algorithm marked SHOULD- will probably get deprecated to a MAY or worse in a future version of this document 📉.
• MUST- means the same as MUST. But we expect that at some point in the future, this algorithm will no longer be a MUST 🥀.

3. Algorithm Selection 🧚

For IPsec implementations to interoperate, they must support one or more security algorithms in common 🤝. This section specifies the security algorithm implementation requirements for standards-conformant ESP and AH implementations ✨. The security algorithms actually used for any particular ESP or AH security association are picked by a negotiation mechanism, like the Internet Key Exchange (IKE [RFC2409, IKEv2]) or pre-establishment 🗝️.

Of course, you can implement additional standard and proprietary algorithms beyond the ones listed below 🌈.

3.1. Encapsulating Security Payload 💜

The implementation conformance requirements for security algorithms for ESP are in the tables below. See Section 2 for definitions of the values in the "Requirement" column 📋.

3.1.1. ESP Encryption and Authentication Algorithms 🔐

These tables list the encryption and authentication algorithms for the IPsec Encapsulating Security Payload protocol 🦋.

   Requirement    Encryption Algorithm (notes)
   -----------    --------------------
   MUST           NULL (1)
   MUST-          TripleDES-CBC [RFC2451]
   SHOULD+        AES-CBC with 128-bit keys [RFC3602]
   SHOULD         AES-CTR [RFC3686]
   SHOULD NOT     DES-CBC [RFC2405] (3)

   Requirement    Authentication Algorithm (notes)
   -----------    ------------------------
   MUST           HMAC-SHA1-96 [RFC2404]
   MUST           NULL (1)
   SHOULD+        AES-XCBC-MAC-96 [RFC3566]
   MAY            HMAC-MD5-96 [RFC2403] (2)

Notes:

(1) Since ESP encryption and authentication are optional, support for the two "NULL" algorithms is required to keep things consistent with how these services get negotiated 🤓. Heads up: while authentication and encryption can each be "NULL", they MUST NOT both be "NULL" 🚫.

(2) Weaknesses have become apparent in MD5 😬. However, these should not affect the use of MD5 with HMAC 💅.

(3) DES has a small key size and publicly demonstrated, open-design, special-purpose cracking hardware. That makes it of questionable security for general use 💀.

3.1.2. ESP Combined Mode Algorithms ✨

As specified in [ESP], combined mode algorithms are supported. These provide both confidentiality and authentication services 🔐. Supporting them means ESP implementations need to be structured properly for it 🛠️. In many situations, combined mode algorithms give significant efficiency and throughput advantages 🚀. There are no suggested or required combined algorithms at this time. But AES-CCM [CCM], which has been adopted as the preferred mode for security in IEEE 802.11 [802.11i], is expected to be of interest in the near future 👀.

3.2. Authentication Header 🦋

The implementation conformance requirements for security algorithms for AH are given below. See Section 2 for definitions of the values in the "Requirement" column 📋. As you'd expect, all of these algorithms are authentication algorithms 💅.

   Requirement    Algorithm (notes)
   -----------    ---------
   MUST           HMAC-SHA1-96 [RFC2404]
   SHOULD+        AES-XCBC-MAC-96 [RFC3566]
   MAY            HMAC-MD5-96 [RFC2403] (1)

Note:

(1) Weaknesses have become apparent in MD5 😬. However, these should not affect the use of MD5 with HMAC 🫶.

Part 1 of 2 🎀: Section 4 (Security Considerations) and everything after it show up in part 2, so stay tuned 🦋.

7. Normative References 📚

okay bestie, these are the docs this spec leans on for real 🫶 (a good chunk of the rest of the RFC is basically built on top of them)

• [AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
• [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
• [IPsec] Kent, S., "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
• [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
• [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
• [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 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.

8. Informative References 🧚

these ones are the extra-credit reading 🌸 nice to know, not the core homework

• [802.11i] LAN/MAN Specific Requirements Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Medium Access Control (MAC) Security Enhancements, IEEE Std 802.11i, June 2004.
• [JIS] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
• [CCM] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
• [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
• [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
• [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
• [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
• [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
• [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

Author's Address 💌

meet the author! 🎀

Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA

Phone:   +1-508-786-7554 (w)
            +1-508-634-2066 (h)
EMail:   Donald.Eastlake@Motorola.com

Full Copyright Statement ⚖️

the legal bit, but make it cute 🦋 the copyright is The Internet Society, 2005 💜 this document is covered by the rights, licenses and restrictions in BCP 78, and apart from what BCP 78 says, the authors keep all their rights.

the document and the info in it are given to you on an "AS IS" basis, and the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all turn down every warranty, express or implied. that covers not infringing any rights, and also merchantability and fitness for a particular purpose. the exact wording is:

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 doesn't take a side on whether any IP rights claimed for the tech in here are valid or how far they reach, and it also doesn't say whether licenses for them are available. it hasn't independently tried to find any such rights either 🫣 if you want the procedures for rights in RFC docs, check out BCP 78 and BCP 79.

copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that will be offered, or the outcome of anyone trying to get a general license or permission to use those proprietary rights for implementing or using this spec, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

the IETF also invites anyone to tell it about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement 🌈

funding for the RFC Editor function is currently provided by the Internet Society 🫶