RFC 2410

The NULL Encryption Algorithm and Its Use With IPsec

📅 published November 1998, from ietf

RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec 🎀

okay bestie, here's the deal with this one 💖

  • Network Working Group, Request for Comments: 2410 ✨
  • Authors: R. Glenn (NIST) and S. Kent (BBN Corp) 🫶
  • Category: Standards Track 🔥
  • Date: November 1998 📅
  • Its title block doesn't list any obsoletes or updates lines, so it isn't marked as replacing or changing another RFC 🦋

Status of This Memo

okay so this doc is a standards track protocol spec for the whole Internet community 🌈 it's literally asking for discussion and suggestions for improvements. if you want the current standardization state, check the "Internet Official Protocol Standards" (STD 1) list 📋. and yes, distribution is unlimited, so share away 💅

Copyright (C) The Internet Society (1998). All Rights Reserved. 🔒

Abstract

this memo defines the NULL encryption algorithm and how it's used with the IPsec Encapsulating Security Payload (ESP) 🧚 NULL does nothing to alter plaintext data. literally nothing 🙈 NULL, by itself, does nothing. the whole point is that NULL gives ESP a way to offer authentication and integrity without confidentiality, which is so iconic ✨

for more on the other pieces ESP implementations need, see [ESP] and [ROAD] 📚

1. Introduction

this memo defines the NULL encryption algorithm and how it's used with the IPsec Encapsulating Security Payload [ESP] to get authentication and integrity without confidentiality 💜

okay story time 📜 NULL is a block cipher, and its origins appear to be lost in antiquity 💀 there were rumors that the National Security Agency suppressed publication of this algorithm, but there's no evidence of that 🙅‍♀️ instead, recent archaeological evidence suggests NULL was developed in Roman times as an exportable alternative to Ceaser ciphers. the reason nobody knew about it? Roman numerals don't have a symbol for zero, so the written records got lost to historians for over two millennia. it's giving historical mystery 🏛️😭

[ESP] specifies an optional encryption algorithm for confidentiality and an optional authentication algorithm for authentication and integrity 🔐 the NULL encryption algorithm is a neat way to represent the choice of not applying encryption. [DOI] calls this ESP_NULL 🍓

the IPsec Authentication Header [AH] spec does something similar. it computes authentication data covering the data portion of a packet and the immutable in transit portions of the IP header 👑 ESP_NULL does not include the IP header in the authentication data calculation. this can be useful for providing IPsec services through non-IP network devices 🛠️ how ESP_NULL might be used with non-IP network devices is outside the scope of this document, so don't come for me on that one 🙈

in this memo, NULL is used within the context of ESP. for more on how all the ESP pieces fit together to provide security services, check [ESP] and [ROAD] 🦋

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 [RFC 2119]. 📖

2. Algorithm Definition

NULL is defined mathematically using the Identity function I applied to a block of data b, like this 🧮

  NULL(b) = I(b) = b

2.1 Keying Material

like other modern ciphers, e.g., RC5 [RFC-2040], the NULL encryption algorithm can use keys of varying lengths. however, no measurable increase in security comes from using longer key lengths 🔑 (so no need to go overboard, bestie 💅)

2.2 Cryptographic Synchronization

because NULL is stateless, there's no need to transmit an IV or similar cryptographic synchronization data on a per packet (or even a per SA) basis 🙌 NULL combines many of the best features of both block and stream ciphers, and it still doesn't require sending an IV or anything like it. main character energy 👑

2.3 Padding

NULL has a block size of 1 byte, so padding is not necessary 🎀

2.4. Performance

NULL is significantly faster than other commonly used symmetric encryption algorithms 🏎️💨 and implementations of the base algorithm are available for all commonly used hardware and OS platforms. it's everywhere, iykyk ✨

2.5 Test Vectors

here's a set of test vectors to help people build interoperable NULL implementations. check your work against these 📝

test_case =      1
data =           0x123456789abcdef
data_len =       8
NULL_data =      0x123456789abcdef

test_case =      2
data =           "Network Security People Have A Strange Sense Of Humor"
data_len =       53
NULL_data =      "Network Security People Have A Strange Sense Of Humor"

3. ESP_NULL Operational Requirements

ESP_NULL is defined by using NULL within the context of ESP. this section adds more detail by pointing out specific operational parameter requirements 🧁

for IKE [IKE] key extraction, the key size for this algorithm MUST be zero (0) bits. this is to facilitate interoperability and to avoid any potential export control problems 🛃✨

to facilitate interoperability, the IV size for this algorithm MUST be zero (0) bits 💖

padding MAY be included on outgoing packets as specified in [ESP] 🌸

4. Security Considerations

⚠️ okay this section is the serious one, so read it closely 🚨

NULL offers no confidentiality, and it doesn't offer any other security service either 😭 it's simply a convenient way to represent the optional use of encryption within ESP. ESP can then provide authentication and integrity without confidentiality. unlike AH, these services are not applied to any part of the IP header 🙅‍♀️ at the time of writing, there's no evidence that ESP_NULL is any less secure than AH when using the same authentication algorithm. in other words, a packet secured with ESP_NULL and some authentication algorithm is as cryptographically secure as a packet secured with AH and that same authentication algorithm 🔥

as [ESP] says, the use of encryption and authentication algorithms is optional in ESP. but it is imperative that an ESP SA specifies at least one cryptographically strong encryption algorithm, or one cryptographically strong authentication algorithm, or one of each 💪 no skipping this part, periodt 💅

at the time of writing, there are no known laws preventing the export of NULL with a zero (0) bit key length 🌍

5. Intellectual Property Rights

under the provisions of [RFC-2026], the authors state that they have disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to them. the authors do not state that they personally know of all potentially pertinent proprietary and intellectual property rights owned or claimed by the organizations they represent or by third parties 🧾

6. Acknowledgments

Steve Bellovin suggested and provided the text for the Intellectual Property Rights section 🫶

credit also goes to the participants of the Cisco/ICSA IPsec & IKE March 1998 Interoperability Workshop, since that's where the need for this document became apparent 🎉

7. References

  • [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
  • [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
  • [ROAD] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
  • [DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2408, November 1998.
  • [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
  • [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [RFC-2040] Baldwin, R., and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October 1996
  • [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

6. Editors' Addresses

Rob Glenn NIST

EMail: rob.glenn@nist.gov

Stephen Kent BBN Corporation

EMail: kent@bbn.com

the IPsec working group can be contacted through the chairs 📮

Robert Moskowitz ICSA

EMail: rgm@icsa.net

Ted T'so Massachusetts Institute of Technology

EMail: tytso@mit.edu

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 🌷

📦 where this page comes from