RFC 4835

Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

📅 published April 2007, from ietf

RFC 4835 🎀

Okay bestie, this one is RFC 4835, and it's called Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) 💖 It's from the Network Working Group, written by V. Manral at IP Infusion Inc., and it's a Standards Track doc dated April 2007 ✨ It obsoletes RFC 4305 💅 It doesn't update anything else.

Status of This Memo 📜

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For where this protocol stands in standardization and its status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The IETF Trust (2007).

Abstract 🦋

IPsec uses a bunch of cryptographic algorithms to give you security services 🔐 ESP and AH are the two mechanisms for protecting data sent over an IPsec Security Association (SA). To keep different implementations able to talk to each other, there has to be a set of mandatory-to-implement algorithms, so at least one algorithm is available everywhere. This doc defines the current set of mandatory-to-implement algorithms for ESP and AH. It also lists algorithms that should be implemented, because they might get promoted to mandatory later 👑

Table of Contents 📚

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

1. Introduction ✨

Okay so ESP and AH are the two ways to protect data sent over an IPsec Security Association (SA) [RFC4301], [RFC4302] 🔐 To keep different implementations compatible, we need a set of mandatory-to-implement algorithms, so there's always at least one algorithm that every implementation has available. This doc sets out today's mandatory-to-implement algorithms for ESP and AH, and it also covers algorithms that should be implemented because they may be promoted to mandatory down the road 💅

Crypto is a constantly moving target 🌪️ New algorithms keep showing up and existing ones keep getting attacked. Something that's strong today could be shown to be weak tomorrow. So the choice of mandatory-to-implement algorithm should be conservative, so it's less likely to get compromised fast. Performance matters too, because lots of IPsec deployments run in places where speed is a concern 🏎️

The mandatory-to-implement algorithm(s) might need to change over time, so the selection is not part of the main IPsec, ESP, or AH specs. It lives here instead. When the choice of algorithm changes, only this document should need an update 🦋

Ideally, tomorrow's mandatory-to-implement algorithm is already in most IPsec implementations by the time it becomes mandatory. So we'll try to name the algorithms we know about today. There's no guarantee that the ones we think may be mandatory in the future will actually become mandatory. Every algorithm we know today is subject to cryptographic attack and may be broken in the future 😭

2. Requirements Terminology 🎀

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].

We also define some extra terms here 💖

      SHOULD+  This term means the same as SHOULD.  However, it is
               likely that an algorithm marked as SHOULD+ will be
               promoted at some future time to be a MUST.

      SHOULD-  This term means the same as SHOULD.  However, it is
               likely that an algorithm marked as SHOULD- will be
               deprecated to a MAY or worse in a future version of
               this document.

      MUST-    This term means the same as MUST.  However, 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 lays out the security algorithm implementation requirements for standards-conformant ESP and AH implementations 🫶 The algorithms actually used for any particular ESP or AH security association get picked by a negotiation mechanism, such as the Internet Key Exchange (IKE [RFC2409], [RFC4306]) or pre-establishment.

Of course, additional standard and proprietary algorithms beyond those listed below can be implemented ✨

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 [RFC2410] (1)
     MUST           AES-CBC with 128-bit keys [RFC3602]
     MUST-          TripleDES-CBC [RFC2451]
     SHOULD         AES-CTR [RFC3686]
     SHOULD NOT     DES-CBC [RFC2405] (2)
     Requirement    Authentication Algorithm (notes)
     -----------    -----------------------------
     MUST           HMAC-SHA1-96 [RFC2404] (3)
     SHOULD+        AES-XCBC-MAC-96 [RFC3566]
     MAY            NULL (1)
     MAY            HMAC-MD5-96 [RFC2403] (4)

Notes:

(1) Since ESP encryption is optional, support for the "NULL" algorithm is required to keep things consistent with how services get negotiated. Heads up though: while authentication and encryption can each be "NULL", they MUST NOT both be "NULL" [RFC4301] 🚫

(2) DES has a small key size, and there's publicly demonstrated, open-design, special-purpose cracking hardware out there. So its security for general use is questionable 💀

(3) Weaknesses have become apparent in SHA-1 [SHA1-COLL]; however, these should not affect the use of SHA1 with HMAC 🙈

(4) Weaknesses have become apparent in MD5 [MD5-COLL]; however, these should not affect the use of MD5 with HMAC 🙈

3.1.2. ESP Combined Mode Algorithms 🌸

As specified in [RFC4303], combined mode algorithms are supported, and they give you both confidentiality and authentication services 🔥 Supporting them means ESP implementations need to be structured properly. In lots of situations, combined mode algorithms bring big efficiency and throughput wins ⭐ There aren't any suggested or required combined algorithms right now, but AES-CCM [RFC4309] and AES-GCM [RFC4106] are definitely of interest 👀 AES-CCM was adopted as the preferred mode in IEEE 802.11 [802.11i], and AES-GCM was adopted as the preferred mode in IEEE 802.1ae [802.1ae] 🍓

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] (1)
    SHOULD+        AES-XCBC-MAC-96 [RFC3566]
    MAY            HMAC-MD5-96 [RFC2403] (2)

Note:

(1) Weaknesses have become apparent in SHA-1 [SHA1-COLL]; however, these should not affect the use of SHA1 with HMAC 🙈

(2) Weaknesses have become apparent in MD5 [MD5-COLL]; however, these should not affect the use of MD5 with HMAC 🙈

4. Security Considerations 🔒

This one is serious, bestie 🫣 The security of a cryptography-based system depends on both how strong the chosen cryptographic algorithms are and how strong the keys used with them are. Security also depends on the engineering and administration of the protocol the system uses, so there are no non-cryptographic ways to get around the security of the overall system.

This doc is about choosing cryptographic algorithms for ESP and AH, specifically the mandatory-to-implement ones. The algorithms marked "MUST implement" or "SHOULD implement" here are not known to be broken right now. Cryptographic research so far suggests they'll likely stay secure into the foreseeable future. But that's not forever, so new revisions of this document are expected from time to time, reflecting the current best practice in this area 🛡️

5. Acknowledgements 🫶

Much of the wording in here was adapted from RFC 4305, which is the parent document of this one. RFC 4305 itself borrows text from [RFC4307], "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2", by Jeffrey I. Schiller 🌈

Huge thanks to the people who reported errors in RFC 4305, or responded to reports of them: Paul Hoffman, Stephen Kent, Paul Koning, and Lars Volker 💜 Helpful Last-Call comments came from Russ Housley, Elwyn Davies, Nicolas Williams, and Alfred Hoenes 👑

6. Changes from RFC 2402 and RFC 2406 to RFC 4305 💅

Okay so [RFC2402] and [RFC2406] were the originals. They defined the IPsec Authentication Header and IPsec Encapsulating Security Payload, and each one spelled out the crypto algorithm implementation requirements for its own protocol. Now they've been replaced by [RFC4302] and [RFC4303], which don't specify any crypto algorithm implementation requirements, plus this document, which specifies those requirements for both [RFC4302] and [RFC4303]. 🫶

The implementation requirements are compared below 👀

   Old    Old             New
   Req.   RFC(s)       Requirement     Algorithm (notes)
   ----   ------       -----------     -----------------
   MUST   2406         SHOULD NOT      DES-CBC [RFC2405] (1)
   MUST   2402 2406    MAY             HMAC-MD5-96 [RFC2403]
   MUST   2402 2406    MUST            HMAC-SHA1-96 [RFC2404]

Note:

(1) The IETF deprecated single DES years ago and hasn't included it in any new standard for a while (see IESG note on the first page of [RFC2407]). [RFC4305] was the first standards-track recognition of that deprecation, specifying that implementations SHOULD NOT provide single DES. The US Government National Institute of Standards and Technology (NIST) has formally recognized single DES's weakness through a notice published [DES-WDRAW] proposing to withdraw it as a US Government Standard. Triple DES is still approved by both the IETF and NIST. 🌸

7. Changes from RFC 4305 🦋

This document obsoletes [RFC4305], and it's giving consistency! 💜 It changes support for the NULL Authentication Algorithm from a MUST to a MAY, which makes this document line up with [RFC4301]. It also adds text on SHA-1 collision attacks, plus notes on the future use of AES-GCM and AES-CCM. ✨

The changed implementation requirements that come from these changes are listed below:

   Old      Old         New
   Req.     RFC(s)      Requirement  Algorithm (notes)
   ----     ------      -----------  -----------------
   MUST     2406        MAY          NULL Authentication
   MUST     2406        MUST         NULL Encryption
   SHOULD+  4305        MUST         AES-CBC Encryption

8. References 📚

8.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP14, RFC2119, 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.
  • [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
  • [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, 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.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
  • [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
  • [RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.

8.2. Informative References

  • [802.11i] "LAN/MAN Specific Requirements Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications", IEEE Standard Medium Access Control (MAC) Security, IEEE Std 802.11i, June 2004.
  • [802.1ae] "Media Access Control (MAC) Security", IEEE Standard Medium Access Control (MAC) Security, IEEE Std 802.1ae, June 2006.
  • [DES-WDRAW] "Announcing Proposed Withdrawal of Federal Information Processing Standard (FIPS) for the Data Encryption Standard (DES) and Request for Comments", FIPS Notice Docket No. 040602169-4169-01, July 2004.
  • [MD5-COLL] Klima, V., "Finding MD5 Collisions - a Toy For a Notebook", Cryptology ePrint Archive Medium Report 2005/075, March 2005.
  • [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.
  • [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
  • [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.
  • [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
  • [SHA1-COLL] Rijmen, V. and E. Oswald, "Update on SHA-1", Cryptology ePrint Archive Report 2005/010, January 2005.

Author's Address 🎀

   Vishwas Manral
   IP Infusion Inc.
   Bamankhola, Bansgali,
   Almora, Uttarakhand  263601
   India

   Phone: +91-98456-61911
   EMail: vishwas@ipinfusion.com

Copyright (C) The IETF Trust (2007).

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 🔥

Okay, legal bit, but it matters! The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document. It also doesn't say whether any license under those rights might or might not be available, and it doesn't claim to have made any independent effort to find such rights. Info on how rights work for RFC documents lives in BCP 78 and BCP 79. 📖

Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights, can be found in 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 needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💖

Acknowledgement 🫶

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌸

📦 where this page comes from