idnits 2.17.1 draft-simpson-ipsec-enhancement-01.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-24) 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 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 75: '... sequence number MUST be initialized t...' RFC 2119 keyword, line 76: '...st datagram, and MUST be incremented (...' RFC 2119 keyword, line 85: '... MUST reject datagrams with duplicat...' RFC 2119 keyword, line 90: '... sequence number MAY be sent in the pr...' RFC 2119 keyword, line 92: '...nder, the value zero MUST NOT be sent....' (2 more instances...) 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 (April 1997) is 9871 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: 'S' is mentioned on line 176, but not defined == Missing Reference: 'L' is mentioned on line 169, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'KR96' ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' -- Possible downref: Non-RFC (?) normative reference: ref. 'VK83' Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W A Simpson (DayDreamer) 2 Internet Draft D A Wagner (Berkeley) 3 expires in six months April 1997 5 Internet Security Transform Enhancements - 6 draft-simpson-ipsec-enhancement-01.txt | 8 Status of this Memo 10 This document is an Internet-Draft. Internet Drafts are working doc- 11 uments of the Internet Engineering Task Force (IETF), its Areas, and 12 its Working Groups. Note that other groups may also distribute work- 13 ing documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months, and may be updated, replaced, or obsoleted by other documents 17 at any time. It is not appropriate to use Internet Drafts as refer- 18 ence material, or to cite them other than as a ``working draft'' or 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 23 Directories on: 25 ftp.is.co.za (Africa) 26 nic.nordu.net (Europe) 27 ds.internic.net (US East Coast) 28 ftp.isi.edu (US West Coast) 29 munnari.oz.au (Pacific Rim) 31 Distribution of this memo is unlimited. 33 Abstract 35 This document describes several generic security transform enhance- 36 ments for the IP Security Protocols (AH and ESP). 38 1. Introduction 40 The implementation of automated key management provides the opportu- 41 nity for enhancement of the basic Internet Protocol Security trans- 42 forms. Rapid key updates are available for better replay protection. 43 Larger quantities of key material are available to improve the qual- 44 ity of the security transforms. 46 These features are not always fundamental to operation of Internet | 47 Security, when they duplicate features already available through 48 other protocol mechanisms or more powerful transforms. However, 49 automated key management makes these features cheaply available. 51 Selection of these enhancements are the domain of particular key man- 52 agement mechanisms. Operational policy considerations are outside 53 the scope of this document. 55 2. Replay Protection 57 When an adversary resends an earlier intercepted IP datagram, the 58 target would like to detect and discard that datagram. It is desir- 59 able that detection occur before computationally intensive opera- 60 tions, such as decryption. 62 Replay protection provides cryptographically secure at-most-once 63 datagram delivery. This is distinguished from the ordinary trans- 64 port-layer delivery mechanisms that would be exercised later in the 65 protocol processing. 67 To provide replay protection, each implementation maintains one (or | 68 more) sequence numbers for each security association. A sequence | 69 number is unique for each IP Destination and SPI. Replay protection | 70 is accomplished by authenticating the sequence numbers. Secure 71 replay protection requires that the key used for authentication be 72 changed before the sequence number repeats. This is made practical 73 through automated key management. 75 When sending, each sequence number MUST be initialized to 1 for the | 76 first datagram, and MUST be incremented (as an unsigned integer) 77 after each datagram is sent. 79 On receipt, the sequence number is checked against a list of previ- | 80 ously accepted numbers. There is no requirement that datagrams 81 arrive in order. As each datagram arrives, the sequence number is 82 stored so that it won't be accepted again. 84 The exact algorithm is implementation dependent. The implementation | 85 MUST reject datagrams with duplicate sequence numbers, and SHOULD | 86 make an effort to accept non-duplicate out-of-order datagrams. 88 2.1. AH Sequencing 90 A 16-bit sequence number MAY be sent in the previously Reserved field | 91 of the Authentication Header (AH) [RFC-1826]. When this feature is | 92 implemented by the sender, the value zero MUST NOT be sent. 94 The receiver validates this number within an implementation dependent 95 range of expected values. Any AH protected datagram that fails this 96 test is silently discarded. 98 Receipt of the value zero indicates that the range has been 99 exhausted, or that the sender has not correctly implemented replay 100 protection. 102 2.2. ESP Sequencing 104 A 32-bit sequence number MAY be sent immediately following the SPI in | 105 the Encapsulating Security Payload (ESP) [RFC-1827]. When this fea- + 106 ture is implemented by the sender, the value zero MUST NOT be sent. + 108 The receiver validates this number within an implementation dependent + 109 range of expected values. Any ESP protected datagram that fails this + 110 test is silently discarded. + 112 Receipt of the value zero indicates that the range has been + 113 exhausted, or that the sender has not correctly implemented replay + 114 protection. + 116 When an Initialization Vector (IV) is required by the transform (as 117 in [RFC-1829]), this sequence number can be used in formulating the | 118 IV. 120 2.3. Combination 122 When both AH and ESP Sequencing are present, or multiple AH or ESP | 123 headers are present, the sequence numbers are unique to each header | 124 and likely to be different for each SPI. Each sequence number is | 125 checked independently. 127 2.4. Implementation 129 A full-size (2**16 or 2**32 bit) array for storing the status of each 130 sequence number received is probably impractical. The following sim- 131 ple algorithm is one possible improvement for single IP Source traf- 132 fic. 134 A low-water mark L is maintained; arriving sequence numbers less than 135 (earlier than) the low-water mark are automatically rejected. 137 A fixed window size W is chosen, depending on storage constraints. 139 An array A[L..L+W-1] of size W is maintained, where each element 140 maintains the state (stale or fresh) of the corresponding sequence 141 number. 143 The following steps are applied to each incoming sequence number S: 145 1. If S < L 146 discard the datagram. 148 2. If S < L+W 149 2a. If A[S] == stale 150 discard the datagram. 151 2b. Else 152 set A[S] = stale, 153 accept the datagram. 155 (note: S > L+W-1) 157 3. If A[L] == stale 158 Let x = L; 159 While A[x] == stale 160 Do set x = x + 1. 162 Let y = L; 163 Let L = x. 164 (shift the array A[] down by y-L elements in memory if necessary, 165 so now A[] has the new bounds L..L+W-1) 166 Set A[j] = fresh for y+W-1 < j < L+W. 167 Goto Step 1. 169 (note: S > L+W-1 and A[L] == fresh) 171 4. Let y = L; 172 Let L = S-W+1. 173 Shift the array A[] down by y-L elements in memory if necessary, 174 so now A[] has the new bounds L..L+W-1 (or L..S). 175 Set A[j] = fresh for y+W-1 < j < L+W. 176 Set A[S] = stale and accept the datagram. 178 Two invariants are maintained in this algorithm. First, all sequence 179 numbers S < L are stale. Second, all sequence numbers S > L+W-1 are 180 fresh. 182 Note that step 4 forgets some state information, and may cause out- 183 of-order datagrams that were sent earlier but received later to be 184 (incorrectly) judged stale and discarded. Though this algorithm may 185 inadvertenly reject a fresh datagram as stale, the important point is 186 that it will never accept a replayed datagram. 188 An implementation may wish to go through with step 4 only for packets 189 that pass the authentication verification. 191 This is only one possible algorithm; implementators may choose 192 another, so long as it rejects replayed datagrams with duplicate 193 sequence numbers. 195 3. Secret Initialization Vector 197 When an Initialization Vector (IV) is specified by the transform (as 198 in [RFC-1829]), this IV may be enhanced by combination with a secret 199 value. Provision of a secret IV for each security association is 200 made practical through automated key management. 202 In most cases, a secret IV is not a requirement, as the [VK83] speci- 203 fied attacks are impractical for the current Internet Security trans- 204 forms. The existing transforms already provide that the IV is dif- 205 ferent for each datagram in the same security association. Choosing 206 a secret IV during session establishment may ensure that the result- 207 ing IV is more likely to be different for every security association 208 when there are a large number of security associations between the 209 same parties. 211 3.1. XOR 213 The most simple technique is to generate a secret IV of the appropri- 214 ate size, and XOR the secret value with the IV carried in the ESP 215 header. 217 3.2. Hash 219 A more robust technique is to regenerate a new IV using a one-way 220 hash function of a (variable length) secret key and the IV carried in 221 each ESP header, extracting an appropriate size IV from the result. 222 This provides a stronger IV that does not appear related to previous 223 IVs. 225 4. Whitening 227 A simple method for strengthening common block cipher transforms (as 228 in [RFC-1829]) involves XOR of additional secret values with each 229 block. Provision of these additional secret values for each security 230 association is made practical through automated key management. 232 Indeed, so-called "whitening" is merely an application of repeated 233 key XOR, the most common cheap method of hiding data. It is insecure 234 without combination with a robust cipher. 236 4.1. Ciphertext 238 The ciphertext may be XOR'd with a secret value before output to the 239 datagram. This requires a secret the same size as the block. When 240 Cipher Block Chaining (CBC) is used, this hides the chaining values 241 used as an IV for the next block. 243 4.2. Plaintext 245 The plaintext may be XOR'd with a secret value before input to the 246 block cipher. This requires a secret the same size as the block. 247 The effect is similar to a secret IV applied to all the blocks. 249 4.3. With Pseudo-random Sequence 251 Another variant is to generate a pseudo-random sequence of secrets to 252 XOR with either the ciphertext or plaintext. This requires a (vari- 253 able length) secret to be used as a seed to the sequence generator. 255 4.4. With Hash Sequence 257 A more robust variant is to generate a sequence of secrets using a 258 one-way hash function of a (variable length) secret key and each 259 block chaining vector (CV), extracting an appropriate size block from 260 the result. This effect is similar to a secret hash IV applied to 261 all the blocks. 263 4.5. Combinations 265 These variants can be easily combined. For example, an XOR of a 266 secret with both the ciphertext and plaintext when used as a sandwich 267 around DES is called DES-XEX2 (DES key plus one XOR key) or DES-XEX3 268 (DES key plus two separate XOR keys) [KR96]. 270 Security Considerations 272 Analyses of these simple techniques are readily available in the lit- 273 erature. Further details may be found in [Schneier95]. 275 The IV or CV hashing techniques are particularly useful in conjunc- 276 tion with replay protection, as they prevent undetectable modifica- 277 tion of the predictable Sequence numbers. 279 Acknowledgements 281 Much of the text and implementation details of Replay Protection were 282 provided by David Wagner. Additional suggestions were provided by 283 Steve Kent. 285 Special thanks to John Ioannidis for inspiration and experimentation 286 which began this most recent round of IP Mobility and IP Security 287 development. Some of the text on Replay Protection was derived from 288 [swIPe]. 290 Robert Baldwin suggested the XOR protection of the IV. 292 Bart Preneel suggested the hash protection of the IV. 294 The use of "whitening" is further described in [Schneier95]. + 296 Angelos Keromytis, and Bill Sommerfeld provided useful critiques of + 297 earlier versions of this document. 299 This specification has been awaiting RFC publication since April 1996. + 301 References 303 [KR96] Kaliski, B., and Robshaw, M., "Multiple Encryption: Weighing 304 Security and Performance", Dr. Dobbs Journal, January 1996. 306 [RFC-1826] 307 Atkinson, R., "IP Authentication Header", RFC-1826, Naval 308 Research Laboratory, July 1995. 310 [RFC-1827] 311 Atkinson, R., "IP Encapsulating Security Protocol (ESP)", 312 RFC-1827, Naval Research Laboratory, July 1995. 314 [RFC-1829] 315 Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Trans- 316 form", July 1995. 318 [Schneier95] 319 Schneier, B., "Applied Cryptography Second Edition", John 320 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 322 [swIPe] Ioannidis, J., and Blaze, M., "The Architecture and Imple- 323 mentation of Network-Layer Security Under Unix", Fourth 324 Usenix Security Symposium Proceedings, October 1993. 326 [VK83] Voydock, V.L., and Kent, S.T., "Security Mechanisms in High- 327 level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 328 1983. 330 Contacts 332 Comments about this document should be discussed on the | 333 ipsec-dev@terisa.com mailing list. 335 Questions about this document can also be directed to: | 337 William Allen Simpson 338 DayDreamer | 339 Computer Systems Consulting Services 340 1384 Fontaine 341 Madison Heights, Michigan 48071 343 wsimpson@UMich.edu 344 wsimpson@GreenDragon.com (preferred) 345 bsimpson@MorningStar.com 347 David A Wagner 348 Computer Science Department 349 University of California 350 Berkeley, California 94720 352 daw@cs.berkeley.edu