idnits 2.17.1 draft-simpson-esp-des1md5-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-27) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 8 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 76: '...en the communicating parties SHOULD be...' RFC 2119 keyword, line 81: '...f up to 128-bits MUST be supported by ...' RFC 2119 keyword, line 85: '... The two keys MUST appear to be unre...' RFC 2119 keyword, line 86: '... key SHOULD NOT give an adversary an...' RFC 2119 keyword, line 100: '...ary, implementors MUST reveal only DES...' (6 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 (February 1996) is 10299 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 177, but not defined == Missing Reference: 'L' is mentioned on line 170, but not defined == Unused Reference: 'RFC-1800' is defined on line 613, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BS93' -- Possible downref: Non-RFC (?) normative reference: ref. 'CN94' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-74' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-81' -- Possible downref: Non-RFC (?) normative reference: ref. 'KR95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Matsui94' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Historic RFC: RFC 1446 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1800 (Obsoleted by RFC 1880) ** Downref: Normative reference to an Informational RFC: RFC 1810 ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** 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. 'Weiner94' Summary: 19 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P Metzger 2 Internet Draft Piermont 3 W A Simpson 4 Daydreamer 5 D A Wagner 6 Berkeley 7 expires in six months February 1996 9 The ESP DES-CBC plus MD5 Transform 10 draft-simpson-esp-des1md5-01.txt 12 Status of this Memo 14 This document is a submission to the IP Security Working Group of the 15 Internet Engineering Task Force (IETF). Comments should be submitted 16 to the ipsec@ans.net mailing list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft. Internet Drafts are working doc- 21 uments of the Internet Engineering Task Force (IETF), its Areas, and 22 its Working Groups. Note that other groups may also distribute work- 23 ing documents as Internet Drafts. 25 Internet Drafts are draft documents valid for a maximum of six 26 months, and may be updated, replaced, or obsoleted by other documents 27 at any time. It is not appropriate to use Internet Drafts as refer- 28 ence material, or to cite them other than as a ``working draft'' or 29 ``work in progress.'' 31 To learn the current status of any Internet-Draft, please check the 32 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 33 Directories on: 35 ftp.is.co.za (Africa) 36 nic.nordu.net (Europe) 37 ds.internic.net (US East Coast) 38 ftp.isi.edu (US West Coast) 39 munnari.oz.au (Pacific Rim) 41 Abstract 43 This document describes use of DES-CBC for privacy, plus MD5 for 44 integrity, in the IP Encapsulating Security Payload (ESP). 46 1. Introduction 48 The Encapsulating Security Payload (ESP) [RFC-1827] provides confi- 49 dentiality for IP datagrams by encrypting the payload data to be pro- 50 tected. Some transforms may also provide integrity. 52 This specification describes the ESP use of the Cipher Block Chaining 53 (CBC) mode of the US Data Encryption Standard (DES) algorithm 54 [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81], together with Message Digest 55 5 (MD5) [RFC-1321]. 57 The usual combination of ESP and AH [RFC-1826] can do this task just 58 as well. The primary benefit of this transform is that it saves 4 59 octets. 61 This document assumes that the reader is familiar with the related 62 document "Security Architecture for the Internet Protocol" 63 [RFC-1825], that defines the overall security plan for IP, and pro- 64 vides important background for this specification. 66 1.1. Keys 68 There are two keys used by this transform. 70 The secret DES key shared between the communicating parties is eight 71 octets (64-bits) in length. This key consists of a 56-bit quantity 72 used by the DES algorithm. The 56-bit key is stored as a 64-bit 73 quantity, with the least significant bit of each octet used as a par- 74 ity bit. 76 The secret MD5 key shared between the communicating parties SHOULD be 77 a cryptographically strong random number, not a guessable string of 78 any sort. 80 The MD5 key is not constrained by this transform to any particular 81 size. Lengths of up to 128-bits MUST be supported by the implementa- 82 tion, although any particular key may be shorter. Longer keys are 83 encouraged. 85 The two keys MUST appear to be unrelated. Knowing the value of one 86 key SHOULD NOT give an adversary an opportunity to calculate the 87 other key. 89 Implementation Notes: 91 Using the same key(s) (or overlapping portion of the same overall 92 key) allows an attack exploiting mathematical relationships 93 between the different algorithms that might reveal some portion of 94 the session-key(s). Never-the-less, there is no known interaction 95 between the MD5 and DES-CBC algorithms. 97 Some implementors might adopt a strategy of systematically reveal- 98 ing some bits of the transform keys (to satisfy US export require- 99 ments for at most 40-bit secrecy algorithms). This is not recom- 100 mended; but if it is necessary, implementors MUST reveal only DES 101 key bits and not MD5 key bits. The independence of the two keys 102 is necessary for security. 104 1.2. Replay Protection 106 This transform provides replay protection: cryptographically secure 107 at-most-once best-effort datagram delivery. In other words, when an 108 adversary resends an earlier intercepted IP datagram, the recipient 109 will detect the attempt. 111 Each implementation maintains a counter. This counter serves both to 112 generate a per-message unique IV for DES, and also as a sequence num- 113 ber to provide replay protection. 115 When sending, the counter MUST be initialized to 0 for the first 116 datagram, and MUST be incremented (as a 32-bit unsigned integer) 117 after each datagram is sent. 119 On receipt, the sequence number is checked against a list of previ- 120 ously accepted numbers. There is no requirement that datagrams 121 arrive in order. As each datagram arrives, the sequence number is 122 stored so that it won't be accepted again. 124 Implementation Notes: 126 The exact algorithm is implementation dependent, but it MUST 127 reject datagrams with duplicate sequence numbers, and should make 128 a best effort to accept as many valid (non-duplicate) datagrams as 129 possible. 131 A full 2**32 element array storing the status of each sequence 132 number received is probably impractical. The following simple 133 algorithm is one possible improvement. 135 A low-water mark L is maintained; sequence numbers less than 136 (earlier than) the low-water mark are automatically rejected. 138 A fixed window size W is chosen, according to storage constraints. 140 An array A[L..L+W-1] of size W is maintained, where each element 141 maintains the state (stale or fresh) of the corresponding sequence 142 number. 144 The following steps are applied to each incoming sequence number 145 S: 147 1. If S < L 148 drop the datagram. 150 2. If S < L+W and A[S] == stale 151 drop the datagram. 153 3. If S < L+W and A[S] == fresh 154 set A[S] = stale and accept the datagram. 156 (note: S > L+W-1) 158 4. If A[L] == stale 159 Let x = L; 160 While A[x] == stale 161 Do set x = x + 1. 163 Let y = L; 164 Let L = x. 165 (shift the array A[] down by y-L elements in memory if necessary, 166 so now A[] has the new bounds L..L+W-1) 167 Set A[j] = fresh for y+W-1 < j < L+W. 168 Goto Step 1. 170 (note: S > L+W-1 and A[L] == fresh) 172 5. Let y = L; 173 Let L = S-W+1. 174 (shift the array A[] down by y-L elements in memory if necessary, 175 so now A[] has the new bounds L..L+W-1 i.e. L..S) 176 Set A[j] = fresh for y+W-1 < j < L+W. 177 Set A[S] = stale and accept the datagram. 179 Two invariants are maintained in this algorithm. First, all 180 sequence numbers S < L are stale. Second, all sequence numbers S 181 > L+W-1 are fresh. 183 Note that step 5 forgets some state information, and may cause 184 out-of-order datagrams which were sent earlier but received later 185 to be (incorrectly) judged stale and dropped. Though this algo- 186 rithm may inadvertenly reject a fresh datagram as stale, the 187 important point is that it will never accept a replayed datagram. 189 An implementation may wish to go through with step 5 only for 190 packets that pass the authentication verification. 192 This is only one possible algorithm; implementators may choose 193 another, so long as it rejects replayed datagrams with duplicate 194 sequence numbers. 196 1.3. Initialization Vector 198 This mode of DES requires an Initialization Vector (IV) that is eight 199 octets (64-bits) in length. 201 Each datagram contains its own IV. Including the IV in each datagram 202 ensures that decryption of each received datagram can be performed, 203 even when other datagrams are dropped, or datagrams are re-ordered in 204 transit. 206 The IV is generated from the SPI and Sequence fields. An MD5 hash is 207 calculated over the following concatenated values: 209 + the DES key (8 octets including parity bits), 210 + the SPI (4 octets), 211 + the Sequence (4 octets), 212 + the MD5 key (variable length). 214 The most significant 64-bits of the generated hash are used for the 215 final IV. 217 1.4. Data Size 219 The DES algorithm operates on blocks of eight octets (64-bits). This 220 often requires padding after the end of the unencrypted payload data. 222 Both input and output result in the same number of octets. This 223 facilitates in-place encryption and decryption. 225 MD5's 128-bit output is naturally 64-bit aligned. There is no fur- 226 ther padding of the Authentication Data field. 228 On receipt, if the length of the data to be decrypted is not an inte- 229 gral multiple of eight octets, then an error is indicated, as 230 described in [RFC-1825]. 232 1.5. Performance 234 In general, DES software speeds are considerably slower than MD5 235 software, while DES hardware is considerably faster than MD5 hard- 236 ware. 238 MD5 software speeds are adequate for commonly deployed LAN and WAN 239 links, but reportedly are too slow for newer link technologies 240 [RFC-1810]. 242 Phil Karn has tuned DES software to achieve 10.45 Mbps with a 90 MHz 243 Pentium. Other DES speed estimates may be found at [Schneier95, p 244 279]. 246 2. Payload Format 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Security Parameters Index (SPI) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Sequence | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 ~ Payload Data ~ 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 ... Padding | Pad Length | Payload Type | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 ~ Authentication Data ~ 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Security Parameters Index (SPI) 265 4 octets. Identifies the Security Parameters for 266 this datagram. The value MUST NOT be zero. 268 Sequence 4 octets. Provides replay prevention, and a seed 269 for calculating the final IV, as described earlier. 271 Payload Data variable. 273 Prior to encryption and after decryption, this field 274 begins with the IP Protocol/Payload header specified 275 in the Payload Type field. Note that in the case of 276 IP-in-IP encapsulation (Payload Type 4), this will 277 be another IP header. 279 Padding variable. 281 Prior to encryption, it is filled with unspecified 282 implementation dependent (preferably random) values, 283 to align the Pad Length and Payload Type fields at 284 an eight octet boundary. 286 After decryption, it MUST be ignored. 288 Pad Length 1 octet. Indicates the size of the Padding field. 289 It does not include the Pad Length and Payload Type 290 fields. The value typically ranges from 0 to 7, but 291 may be up to 255 to permit hiding of the actual data 292 length. 294 This field is opaque. That is, the value is set 295 prior to encryption, and is examined only after 296 decryption. 298 Payload Type 1 octet. Indicates the contents of the Payload Data 299 field, using the IP Protocol/Payload value. Up-to- 300 date values of the IP Protocol/Payload are specified 301 in the most recent "Assigned Numbers" [RFC-1700]. 303 This field is opaque. That is, the value is set 304 prior to encryption, and is examined only after 305 decryption. 307 For example, when encrypting an entire IP datagram 308 (Tunnel-Mode), this field will contain the value 4, 309 indicating IP-in-IP encapsulation. 311 Authentication Data 312 16 octets. Filled with the result of the MD5 calcu- 313 lation. 315 3. Algorithm 317 In DES-CBC, each plaintext block is XOR'd with the previous cipher- 318 text block, and the DES encryption function is applied to yield the 319 ciphertext for the current block. This provides for re- 320 synchronization when datagrams are lost. 322 For more explanation and implementation information for DES, see 323 [Schneier95]. 325 3.1. Encryption 327 Append zero or more octets of (preferably random) padding to the 328 plaintext, to make its modulo 8 length equal to 6. For example, if 329 the plaintext length is 41, 5 octets of padding are added. 331 Append a Pad Length octet containing the number of padding octets 332 just added. 334 Append a Payload Type octet containing the IP Protocol/Payload value 335 identifying the protocol header that begins the payload. 337 Provide an appropriate Initialization Vector (IV), as described ear- 338 lier. 340 Encrypt the payload with DES in CBC mode, producing a ciphertext of 341 the same length. 343 Octets are mapped to DES blocks in network order (most significant 344 octet first) [RFC-1700]. Octet 0 (modulo 8) of the payload corre- 345 sponds to bits 1-8 of the 64-bit DES input block, while octet 7 (mod- 346 ulo 8) corresponds to bits 57-64 of the DES input block. 348 Add the indicated SPI and Sequence in front of the Payload Data. 350 Append the Authentication Data, calculated over the SPI, Sequence, 351 Payload Data, padding, Pad Length, and Payload Type. 353 Construct an appropriate IP datagram for the target Destination. The 354 Total/Payload Length in the encapsulating IP Header reflects the 355 length of the encrypted data, plus the SPI, Sequence, padding, Pad 356 Length, Payload Type, and Authentication Data. 358 3.2. Decryption 360 First, the SPI field is examined. This is used as an index into the 361 local Security Parameter table to find the negotiated parameters and 362 decryption key. 364 The Authentication Data is verified and removed. 366 The SPI and Sequence fields are removed, and an appropriate 64-bit IV 367 value is constructed. 369 The encrypted part of the payload is decrypted using DES in the CBC 370 mode. 372 The Payload Type is removed and examined. If it is unrecognized, the 373 payload is discarded with an appropriate ICMP message. 375 The Pad Length is removed and examined. The specified number of pad 376 octets are removed from the end of the decrypted payload, and the IP 377 Total/Payload Length is adjusted accordingly. 379 The IP Header(s) and the remaining portion of the decrypted payload 380 are passed to the protocol receive routine specified by the Payload 381 Type field. 383 3.3. Authentication 385 The 128-bit digest is calculated as described in [RFC-1321]. The 386 specification of MD5 includes a portable 'C' programming language 387 description of the MD5 algorithm. 389 The form of the authenticated message is 391 MD5( key, keyfill, MD5( key, keyfill, data, MD5fill), MD5fill ) 393 First, the variable length secret authentication key is filled to the 394 next 512-bit boundary, using the same pad with length technique 395 defined for MD5. 397 Second, the filled key is concatenated with (immediately followed by) 398 the SPI, Sequence, Payload Data, padding, Pad Length, and Payload 399 Type. 401 A trailing pad with length to the next 512-bit boundary for the 402 entire message is added by MD5 itself. The 128-bit MD5 digest is 403 calculated. 405 Third, the filled key is again concatenated with (immediately fol- 406 lowed by) the previous digest. 408 A trailing pad with length to the next 512-bit boundary for the 409 entire message is added by MD5 itself. The 128-bit MD5 digest is 410 calculated, and the result is inserted into the Authentication Data 411 field. 413 Discussion: 414 The leading copy of the key is padded in order to facilitate copy- 415 ing of the key at machine boundaries without requiring re- 416 alignment of the following datagram. The padding technique 417 includes a length that protects arbitrary length keys. Filling to 418 the MD5 block size also allows the key to be prehashed to avoid 419 the physical copy in some implementations. It is further sug- 420 gested that this might protect against some forms of cryptanaly- 421 sis, although no such weakness is yet known in keyed MD5 [KR95]. 423 When the implementation adds the keys and padding in place before 424 and after the IP datagram, care must be taken that the keys and/or 425 padding are not sent over the link by the link driver. 427 A. Deriving Independent Keys 429 This algorithm is suggested for those implementors that desire to 430 configure only one master key, and derive two apparently indepen- 431 dent keys. 433 The master key shall be considered the key of this transform. The 434 master key length MUST be between 56 and 128 bits; larger values 435 are recommended. 437 DES key: PK = most significant 64-bits of MD5("DES", master key). 439 The 3-byte ASCII string "DES" is followed by (concatenated with) 440 the master key. That is hashed with the MD5 cryptographic hash, 441 and PK is the first 8 bytes (64-bits) of the hash output. The 442 least significant bits of DK are discarded, and replaced by the 443 appropriate DES parity check bits. The result is the DES privacy 444 key. 446 MKL = length of the master key in bits. 447 MD5 key: AK = most significant MKL bits of MD5("MD5", master key). 449 The 3-byte ASCII string "MD5" is followed by (concatenated with) 450 the master key. That is hashed with the MD5 cryptographic hash, 451 and AK is the first MKL bits of the hash output. This ensures 452 that the length of the authentication key accurately reflects its 453 entropy. The result is the MD5 authentication key. 455 Design Notes: 457 Any appropriate pair of strings may be used in place of "DES" 458 and "MD5". 460 This transform does not provide more than 56 bits of confiden- 461 tiality, regardless of the size of the master key. This 462 derivation provides only as many bits of message authentication 463 as the minimum of {master key length, 128-bits}. 465 This simple key scheduling algorithm will not work with a hard- 466 ware token that must generate the DES key itself (a la Clip- 467 per). 469 Security Considerations 471 Users need to understand that the quality of the security provided 472 by this specification depends completely on the strength of the 473 DES and MD5 algorithms, the correctness of the algorithm's imple- 474 mentation, the security of the key management mechanism and its 475 implementation, the strength of the key [CN94], and upon the cor- 476 rectness of the implementations in all of the participating nodes. 478 MD5 480 At the time of writing of this document, it is known to be pos- 481 sible to produce collisions in the compression function of MD5 482 [dBB93]. There is not yet a known method to exploit these col- 483 lisions to attack MD5 in practice, but this fact is disturbing 484 to some authors [Schneier95]. 486 It has also recently been determined [vOW94] that it is possi- 487 ble to build a machine for $10 Million that could find two cho- 488 sen text variants with a common MD5 hash value. However, it is 489 unclear whether this attack is applicable to a keyed MD5 trans- 490 form. 492 This attack requires approximately 24 days. The same form of 493 attack is useful on any iterated n-bit hash function, and the 494 time is entirely due to the 128-bit length of the MD5 hash. 496 Although there is no substantial weakness for most IP security 497 applications, it should be recognized that current technology 498 is catching up to the 128-bit hash length used by MD5. Appli- 499 cations requiring extremely high levels of security may wish to 500 move in the near future to algorithms with longer hash lengths. 502 DES 504 Among other considerations, applications may wish to take care 505 not to select weak keys, although the odds of picking one at 506 random are low [Schneier95, p 280]. 508 At the time of writing of this document, [BS93] demonstrated a 509 differential cryptanalysis based chosen-plaintext attack 510 requiring 2**47 plaintext-ciphertext pairs, and [Matsui94] 511 demonstrated a linear cryptanalysis based known-plaintext 512 attack requiring only 2**43 plaintext-ciphertext pairs. 513 Although these attacks are not considered practical, they must 514 be taken into account. 516 More disturbingly, [Weiner94] has shown the design of a DES 517 cracking machine costing $1 Million that can crack one key 518 every 3.5 hours. This is an extremely practical attack. 520 One or two blocks of known plaintext suffice to recover a DES 521 key. Because IP datagrams typically begin with a block of 522 known and/or guessable header text, frequent key changes will 523 not protect against this attack. 525 It is suggested that DES is not a good encryption algorithm for 526 the protection of even moderate value information in the face 527 of such equipment. Triple DES is probably a better choice for 528 such purposes. 530 However, despite these potential risks, the level of privacy 531 provided by use of ESP DES-CBC in the Internet environment is 532 far greater than sending the datagram as cleartext. 534 Acknowledgements 536 Some of the text of this specification was derived from work by 537 Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups. 539 This basic concept and use of DES and MD5 were derived in large 540 part from the work done for SNMPv2 [RFC-1446]. 542 Much of the implementation details were derived from work by Phil 543 Karn. 545 Bart Preneel suggested the hash protection of the IV, to render it 546 impossible to correlate with subsequent IVs. 548 David Wagner was responsible for the description of replay preven- 549 tion. 551 The message authentication mechanism is based on one of the vari- 552 ants discussed in [KR95]. 554 References 556 [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of 557 the Data Encryption Standard", Berlin: Springer-Verlag, 558 1993. 560 [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak 561 Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 562 23 pp. 253-280, July 1994. 564 [dBB93] den Boer, B., and Bosselaers, A., "Collisions for the 565 Compression function of MD5", Advances in Cryptology -- 566 Eurocrypt '93 Proceedings, Berlin: Springer-Verlag 1994 568 [FIPS-46] 569 US National Bureau of Standards, "Data Encryption Stan- 570 dard", Federal Information Processing Standard (FIPS) 571 Publication 46, January 1977. 573 [FIPS-46-1] 574 US National Bureau of Standards, "Data Encryption Stan- 575 dard", Federal Information Processing Standard (FIPS) 576 Publication 46-1, January 1988. 578 [FIPS-74] 579 US National Bureau of Standards, "Guidelines for Imple- 580 menting and Using the Data Encryption Standard", Federal 581 Information Processing Standard (FIPS) Publication 74, 582 April 1981. 584 [FIPS-81] 585 US National Bureau of Standards, "DES Modes of Operation" 586 Federal Information Processing Standard (FIPS) Publica- 587 tion 81, December 1980. 589 [KR95] Kaliski, B., and Robshaw, M., "Message authentication 590 with MD5", CryptoBytes (RSA Labs Technical Newsletter), 591 vol.1 no.1, Spring 1995. 593 [Matsui94] 594 Matsui, M., "Linear Cryptanalysis method dor DES Cipher," 595 Advances in Cryptology -- Eurocrypt '93 Proceedings, 596 Berlin: Springer-Verlag, 1994. 598 [RFC-1321] 599 Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, 600 DDN Network Information Center, April 1992. 602 [RFC-1446] 603 Galvin, J., and McCloghrie, K., "Security Protocols for 604 Version 2 of the Simple Network Management Protocol 605 (SNMPv2)", RFC-1446, DDN Network Information Center, 606 April 1993. 608 [RFC-1700] 609 Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, 610 RFC-1700, USC/Information Sciences Institute, October 611 1994. 613 [RFC-1800] 614 Postel, J., "Internet Official Protocol Standards", STD 615 1, RFC-1800, USC/Information Sciences Institute, July 616 1995. 618 [RFC-1810] 619 Touch, J., "Report on MD5 Performance", USC/Information 620 Sciences Institute, June 1995. 622 [RFC-1825] 623 Atkinson, R., "Security Architecture for the Internet 624 Protocol", RFC-1825, Naval Research Laboratory, July 625 1995. 627 [RFC-1826] 628 Atkinson, R., "IP Authentication Header", RFC-1826, Naval 629 Research Laboratory, July 1995. 631 [RFC-1827] 632 Atkinson, R., "IP Encapsulating Security Protocol (ESP)", 633 RFC-1827, Naval Research Laboratory, July 1995. 635 [Schneier95] 636 Schneier, B., "Applied Cryptography Second Edition", John 637 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 639 [Weiner94] 640 Wiener, M.J., "Efficient DES Key Search", School of Com- 641 puter Science, Carleton University, Ottawa, Canada, 642 TR-244, May 1994. Presented at the Rump Session of 643 Crypto '93. 645 [vOW94] van Oorschot, P. C., and Wiener, M. J., "Parallel Colli- 646 sion Search with Applications to Hash Functions and Dis- 647 crete Logarithms", Proceedings of the 2nd ACM Conf. Com- 648 puter and Communications Security, Fairfax, VA, November 649 1994. 651 Author's Address 653 Questions about this memo can also be directed to: 655 Perry Metzger 656 Piermont Information Systems Inc. 657 160 Cabrini Blvd., Suite #2 658 New York, NY 10033 660 perry@piermont.com 662 William Allen Simpson 663 Daydreamer 664 Computer Systems Consulting Services 665 1384 Fontaine 666 Madison Heights, Michigan 48071 668 Bill.Simpson@um.cc.umich.edu 669 bsimpson@MorningStar.com (prefered)