idnits 2.17.1 draft-ietf-ipsec-ciph-null-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([ROAD], [ESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9538 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 82, but not defined == Unused Reference: 'RFC-2119' is defined on line 219, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-03 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-04 -- Unexpected draft version: The latest known version of draft-ietf-ipsec-doc-roadmap is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-doc-roadmap (ref. 'ROAD') == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-ipsec-doi-07 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-ipsec-doi (ref. 'DOI') == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-06 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'IKE') ** Downref: Normative reference to an Informational RFC: RFC 2040 Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group IPsec Working Group 2 INTERNET DRAFT R. Glenn, NIST 3 Expire in six months S. Kent, BBN Corp 4 March 1998 6 The NULL Encryption Algorithm and Its Use With IPsec 7 9 Status of this Memo 11 This document is a submission to the IETF Internet Protocol Security 12 (IPSEC) Working Group. Comments are solicited and should be addressed 13 to the working group mailing list (ipsec@tis.com) or to the editor. 15 This document is an Internet-Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet-Drafts draft documents are valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Distribution of this memo is unlimited. 33 Abstract 35 This draft defines the NULL encryption algorithm and its use with the 36 IPsec Encapsulating Security Payload (ESP). NULL does nothing to 37 alter plaintext data. In fact, NULL, by itself, does nothing. NULL 38 provides the means for ESP to provide authentication and integrity 39 without confidentiality. 41 Further information on the other components necessary for ESP 42 implementations is provided by [ESP] and [ROAD]. 44 1. Introduction 46 This draft defines the NULL encryption algorithm and its use with the 47 IPsec Encapsulating Security Payload [ESP] to provide authentication 48 and integrity without confidentiality. 50 NULL is a block cipher the origins of which appear to be lost in 51 antiquity. Despite rumors that the National Security Agency 52 suppressed publication of this algorithm, there is no evidence of 53 such action on their part. Rather, recent archaeological evidence 54 suggests that the NULL algorithm was developed in Roman times, as an 55 exportable alternative to Ceaser ciphers. However, because Roman 56 numerals lack a symbol for zero, written records of the algorithm's 57 development were lost to historians for over two millennia. 59 [ESP] specifies the use of an optional encryption algorithm to 60 provide confidentiality and the use of an optional authentication 61 algorithm to provide authentication and integrity. The NULL 62 encryption algorithm is a convenient way to represent the option of 63 not applying encryption. This is referred to as ESP_NULL in [DOI]. 65 The IPsec Authentication Header [AH] specification provides a similar 66 service, by computing authentication data which covers the data 67 portion of a packet as well as the immutable in transit portions of 68 the IP header. ESP_NULL does not include the IP header in 69 calculating the authentication data. This can be useful in providing 70 IPsec services through Network Address Translation (NAT) devices and 71 non-IP network devices. The discussion on how ESP_NULL might be 72 used with NAT and non-IP network devices is outside the scope of this 73 document. 75 In this draft, NULL is used within the context of ESP. For further 76 information on how the various pieces of ESP fit together to provide 77 security services, refer to [ESP] and [ROAD]. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC 2119]. 83 2. Algorithm Definition 85 NULL is defined mathematically by the use of the Identity function I 86 applied to a block of data b such that: 88 NULL(b) = I(b) = b 90 2.1 Keying Material 92 Like other modern ciphers, e.g., RC5 [RFC-2040], the NULL encryption 93 algorithm can make use of keys of varying lengths. However, no 94 measurable increase in security is afforded by the use of longer key 95 lengths. 97 2.2 Cryptographic Synchronization 99 Because of the stateless nature of the NULL encryption algorithm, it 100 is not necessary to transmit an IV or similar cryptographic 101 synchronization data on a per packet (or even a per SA) basis. The 102 NULL encryption algorithm combines many of the best features of both 103 block and stream ciphers, while still not requiring the transmission 104 of an IV or analogous cryptographic synchronization data. 106 2.3 Padding 108 NULL has a block size of 1 byte, thus padding is not necessary. 110 2.4. Performance 112 The NULL encryption algorithm is significantly faster than other 113 commonly used symmetric encryption algorithms and implementations of 114 the base algorithm are available for all commonly used hardware and 115 OS platforms. 117 2.5 Test Vectors 119 The following is a set of test vectors to facilitate in the 120 development of interoperable NULL implementations. 122 test_case = 1 123 data = 0x123456789abcdef 124 data_len = 8 125 NULL_data = 0x123456789abcdef 127 test_case = 2 128 data = "Network Security People Have A Strange Sense Of Humor" 129 data_len = 53 130 NULL_data = "Network Security People Have A Strange Sense Of Humor" 132 3. ESP_NULL Operational Requirements 134 ESP_NULL is defined by using NULL within the context of ESP. This 135 section further defines ESP_NULL by pointing out particular 136 operational parameter requirements. 138 For purposes of IKE [IKE] key extraction, the key size for this 139 algorithm MUST be zero (0) bits, to facilitate interoperability and 140 to avoid any potential export control problems. 142 To facilitate interoperability, the IV size for this algorithm MUST 143 be zero (0) bits. 145 Padding MAY be included on outgoing packets as specified in [ESP]. 147 4. Security Considerations 149 The NULL encryption algorithm offers no confidentiality nor does it 150 offer any other security service. It is simply a convenient way to 151 represent the optional use of applying encryption within ESP. ESP 152 can then be used to provide authentication and integrity without 153 confidentiality. Unlike AH these services are not applied to any 154 part of the IP header. At the time of this writing there is no 155 evidence to support that ESP_NULL is any less secure than AH when 156 using the same authentication algorithm (i.e. a packet secured using 157 ESP_NULL with some authentication algorithm is as cryptographically 158 secure as a packet secured using AH with the same authentication 159 algorithm). 161 As stated in [ESP], while the use of encryption algorithms and 162 authentication algorithms are optional in ESP, it is imperative that 163 an ESP SA specifies the use of at least one cryptographically strong 164 encryption algorithm or one cryptographically strong authentication 165 algorithm or one of each. 167 At the time of this writing there are no known laws preventing the 168 exportation of NULL with a zero (0) bit key length. 170 5. Intellectual Property Rights 172 Pursuant to the provisions of [RFC-2026], the authors represent that 173 they have disclosed the existence of any proprietary or intellectual 174 property rights in the contribution that are reasonably and 175 personally known to the authors. The authors do not represent that 176 they personally know of all potentially pertinent proprietary and 177 intellectual property rights owned or claimed by the organizations 178 they represent or third parties. 180 6. Acknowledgments 182 Steve Bellovin suggested and provided the text for the Intellectual 183 Property Rights section. 185 Credit also needs to be given to the participants of the Cisco/ICSA 186 IPsec & IKE March 1998 Interoperability Workshop since it was there 187 that the need for this document became apparent. 189 7. References 191 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security 192 Payload", draft-ietf-ipsec-esp-v2-03.txt, work in progress, 193 February 1998. 195 [AH] Kent, S., Atkinson, R., "IP Authentication Header", 196 draft-ietf-ipsec-auth-header-04.txt, work in progress, 197 February 1998. 199 [ROAD] Thayer, R., Doraswamy, N., Glenn, R., "IP Security 200 Document Roadmap", 201 draft-ietf-ipsec-doc-roadmap-02.txt, work in progress, 202 November 1997. 204 [DOI] Piper, D., "The Internet IP Security Domain of 205 Interpretation for ISAKMP", 206 draft-ietf-ipsec-ipsec-doi-07.txt, work in progress, 207 February 1998. 209 [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange 210 (IKE)", draft-ietf-ipsec-isakmp-oakley-06.txt, work in 211 progress, February 1998. 213 [RFC-2026] Bradner, S., "The Internet Standards Process -- 214 Revision 3", RFC2026, October 1996. 216 [RFC-2040] Baldwin, R.W., Rivest, R., "The RC5, RC5-CBC, RC5-CBC- 217 Pad, and RC5-CTS Algorithms", RFC2040, October 1996 219 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", RFC-2119, March 1997. 222 6. Editors' Address 224 Rob Glenn 225 NIST 226 e-mail: rob.glenn@nist.gov 228 Stephen Kent 229 BBN Corporation 230 e-mail: kent@bbn.com 232 The IPsec working group can be contacted through the chairs: 234 Robert Moskowitz 235 ICSA 236 e-mail: rgm@icsa.net 238 Ted T'so 239 Massachusetts Institute of Technology 240 e-mail: tytso@mit.edu