idnits 2.17.1 draft-ietf-ipsec-esp-3des-md5-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-26) 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 Introduction section. ** 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 16 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([IBK93], [IB93]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 49: '... - MUST...' RFC 2119 keyword, line 54: '... - SHOULD...' RFC 2119 keyword, line 61: '... - MAY...' RFC 2119 keyword, line 120: '... This field is negotiated at key setup and MUST not be 0 [RFC-1825]...' RFC 2119 keyword, line 124: '...alization Vector MAY be negotiated. Th...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 45 has weird spacing: '...ine the signi...' == Line 46 has weird spacing: '... of each pa...' == Line 51 has weird spacing: '...hat the item ...' == Line 56 has weird spacing: '..." means that ...' == Line 57 has weird spacing: '... exist valid...' == (6 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This field is negotiated at key setup and MUST not be 0 [RFC-1825] -- 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 (November 1996) is 10024 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'Naganand96' is mentioned on line 466, but not defined -- Looks like a reference, but probably isn't: '512' on line 525 == Unused Reference: 'Maughan96' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'Orman96' is defined on line 435, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin96' -- 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. 'Krawczyk96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Maughan96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Orman96' ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Blaze96' -- Possible downref: Non-RFC (?) normative reference: ref. 'IB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBK93' Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Security Working Group IPsec Working Group 2 INTERNET DRAFT Naganand Doraswamy, Editor 3 November 1996 4 Expires in Six months 6 Combined 3DES-CBC, HMAC and Replay Prevention Security Transform 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 describes a combination of privacy, authentication, 36 integrity and replay prevention into a single packet format. 38 This document is the result of significant work by several major con- 39 tributors and the IPsec working group as a whole. These contributors, 40 cited later in this document, provided many of the key technical 41 details summarized in this document. [IB93] [IBK93] 43 Requirements Terminology 45 In this document, the words that are used to define the significance 46 of each particular requirement are usually capitalised. These words 47 are: 49 - MUST 51 This word or the adjective "REQUIRED" means that the item is an 52 absolute requirement of the specification. 54 - SHOULD 56 This word or the adjective "RECOMMENDED" means that there might 57 exist valid reasons in particular circumstances to ignore this 58 item, but the full implications should be understood and the case 59 carefully weighed before taking a different course. 61 - MAY 63 This word or the adjective "OPTIONAL" means that this item is tru- 64 ly optional. One vendor might choose to include the item because 65 a particular marketplace requires it or because it enhances the 66 product, for example; another vendor may omit the same item. 68 For the purpose of this RFC, the terms conformance and compliance are 69 synonymous. 71 1. Discussion 73 This draft allows a combination of MD5 and 3DES-CBC. In addition to 74 privacy, the goal of this transform is to ensure that the packet is 75 authentic, can not be modified in transit, or replayed. 77 The claims of privacy, integrity, authentication, and replay preven- 78 tion are made in this draft. A good general text describing the 79 methods and algorithm are in [Schneier95]. 81 Privacy is provided by 3DES-CBC [FIPS-46] [FIPS-46-1] [FIPS-74] 82 [FIPS-81]. 84 Integrity is provided by HMAC [Krawczyk96]. 86 Authentication is provided since only the source and destination know 87 the HMAC key. If the HMAC is correct, it proves that it must have 88 been added by the source. 90 Replay prevention is provided by the combination of a constantly 91 increasing count, the SPI and the HMAC key. The integrity of the 92 replay field is provided by the HMAC. 94 2. Packet Format 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 97 | Security Parameters Index (SPI) | ^ 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 99 | | | 100 + Initialization Vector (Optional) + | 101 | | | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --- 103 | Replay Prevention Field (count) | | ^ 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 105 | | | | 106 ~ Payload Data ~ | | 107 | |HMAC | 108 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3DES 109 | | Padding (0-7 bytes) | | CBC 110 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 111 | | Pad Length | Payload Type | v | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | 113 | | | 114 ~ HMAC digest ~ | 115 | | v 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 118 2.1. Security Parameters Index 120 This field is negotiated at key setup and MUST not be 0 [RFC-1825] 122 2.2. Initialization Vector 124 The use of an explicit Initialization Vector MAY be negotiated. The 125 purpose of this mode is to support devices that automatically gen- 126 erate IVs and can not operate using a constant IV_key_. 128 This field is optional and is only used when an explicit IV is nego- 129 tiated during key exchange. This field contains random data or 130 contains the last cyphertext block of a previous packet sent or 131 received. 133 For the packet which the explicit IV is received, the explicit IV is 134 used in place of the constant IV_key_ described later in this docu- 135 ment. 137 2.3. Replay Prevention 139 Replay Prevention is an unsigned 32 bit incrementing counter starting 140 at a mutual agreed upon value (see Key Material) and is enforced to 141 be within a mutually negotiated window size. 143 The key (K, as described in a later section) MUST be changed fre- 144 quently enough so that the counter is not allowed to return to the 145 initial value; in other words, the key MUST be changed before 2^32 146 packets are transmitted using this key. For a given SPI, counter 147 wrapping MUST be considered to be a replay attack. (While a wrap is a 148 replay attack, there is always the possibility that a packet can get 149 duplicated, so the presence of a single or small number of duplicate 150 packets is not an absolute indication of a replay attack.) 152 The receiver MUST verify that for a given SPI the packets received 153 have non-repeating (non-duplicate) counter values. This can be imple- 154 mented as a simple increasing count test or the receiver MAY choose 155 to accept out-of-order packets as long as it is guaranteed that pack- 156 ets can be received only once. For example, an implementation can use 157 a sliding receive window. If such a receive window is supported, the 158 receiver MUST ensure that it will accept packets within the current 159 window only once, and reject any packets it receives with a value 160 that is less than the lower bound of the window. 162 Negotiated window sizes of 1 and 32 are suggested and larger multi- 163 ples of 32 are allowed. 1 indicates that only constantly increasing 164 replay numbers are allowed and packets which have replay values less 165 than the highest received are always rejected. 32 indicates that are 166 within 32 of the highest received, and are guaranteed not to have 167 been received before, are allowed. 169 A window size of 1 MUST be supported. A value of 32 SHOULD be sup- 170 ported. 172 If a value of 32 is negotiated, then the most recent 32 packets are 173 allowed to arrive out of order. That is, these 32 packets can arrive 174 in any sequence relative to each other except that these packets are 175 guaranteed to arrive only once. Appendix A has actual code that 176 implement a 32 packet replay window and a test routine. The purpose 177 of this routine is to show how it could be implemented. 179 2.4. Payload 181 The payload contains data that is described by the payload type 182 field. This field is an integral number of bytes in length; the fol- 183 lowing padding and pad length fields will help provide alignment to a 184 four octet boundary. 186 2.5. Padding 188 The padding (pad bytes and pad length field) is used to align the 189 following "payload type" field to end on a four octet boundary (when 190 counting from the start of the replay field). 192 Padding bytes SHOULD be initialized with random data. 194 At a minimum, the number of pad bytes added MUST be enough to align 195 the payload type field on the next appropriate boundary. However, the 196 sender MAY choose to include additional padding, provided that the 197 alignment is maintained. In total, the sender can add 0-255 bytes of 198 padding. 200 2.6. Pad Length 202 The pad length field indicates the number of pad bytes immediately 203 preceding it. The range of valid values is 0-255, where a value of 204 zero indicates that the byte immediately preceding the pad length 205 field is the last byte of the payload. 207 2.7. Payload Type 209 Describes what the payload is. The values are described in: 211 ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers 213 2.8. HMAC Digest 215 The HMAC digest is a 128 bit residue described in [Krawczyk96]. This 216 covers the SPI, replay, payload, padding, pad length, payload type. 218 HMAC is a keyed algorithm, where both directions are keyed 219 separately. The implementation MUST use the HMAC_key_ as described 220 in the section on keys. 222 3. Encryption Transform Procedure 224 Triple encryption in Outer-CBC mode with a constant IV_key_ is used 225 (IV_key_I for the initiator -> responder direction and IV_key_R for the 226 responder -> initiator direction). The IV_key_ remains constant for all 227 packets send in this direction. 229 If an explicit IV is negotiated, 64 bits of random or the last 230 cyphertext block of a previous packet send or receive can be used. 232 IV or 233 IV_key_ count|x1 x2 x3 234 | | | | 235 |--------(+) ----------(+) ----------(+) 236 | | | | | 237 --------- | --------- | --------- 238 k1--| DES | | k1--| DES | | k1--| DES | 239 |encrypt| | |encrypt| | |encrypt| 240 --------- | --------- | --------- 241 | | | | | 242 --------- | --------- | --------- 243 k2--| DES | | k2--| DES | | k2--| DES | 244 |decrypt| | |decrypt| | |decrypt| 245 --------- | --------- | --------- 246 | | | | | 247 --------- | --------- | --------- 248 k3--| DES | | k3--| DES | | k3--| DES | 249 |encrypt| | |encrypt| | |encrypt| 250 --------- | --------- | --------- 251 |------| |------| |----... 252 | | | 253 y1 y2 y3 255 Where count is the Replay counter. x1, x2, x3 are the plaintext (x1 256 is 32 bits, all others are 64 bits). y1, y2, y3 are the ciphertext. 257 k1, k2, k3 corresponds to DES_KEY_[R|I]1, DES_KEY_[R|I]2, and 258 DES_KEY_[R|I]3. 260 This transformation is comprised of the following 3 steps. 262 1. Taking the data and encapsulating it with the SPI, IV (if 263 present), count, pad, pad length, and payload type. 265 2. Calculating the HMAC using the HMAC_key_ and creating the dig- 266 est from the SPI, IV (if present), count, data, pad, pad length, 267 and payload type and placing the result into the HMAC digest 268 field. 270 3. Encrypting the count, data, pad, pad length, payload type, and 271 HMAC digest using 3DES and the appropriate DES_key_ and IV_key_. 272 (Note that the first DES block is a combination of the count and 273 the first word of plaintext.) 275 4. Decryption Transform Procedure 277 Triple encryption in Outer-CBC with constant IV_key_ is used. If an IV is 278 present in the packet, then the IV_key_ is not used and is replaced by the 279 IV. 281 IV or 282 IV_key_ y1 y2 y3 283 | | | | 284 | |------- |------- |----... 285 | | | | | | 286 | --------- | --------- | --------- 287 | k3--| DES | | k3--| DES | | k3--| DES | 288 | |decrypt| | |decrypt| | |decrypt| 289 | --------- | --------- | --------- 290 | | | | | | 291 | --------- | --------- | --------- 292 | k2--| DES | | k2--| DES | | k2--| DES | 293 | |encrypt| | |encrypt| | |encrypt| 294 | --------- | --------- | --------- 295 | | | | | | 296 | --------- | --------- | --------- 297 | k1--| DES | | k1--| DES | | k1--| DES | 298 | |decrypt| | |decrypt| | |decrypt| 299 | --------- | --------- | --------- 300 | | | | | | 301 |---------(+) |---------(+) |---------(+) 302 | | | 303 (count|x1) x2 x3 305 Decryption is comprised of the following 4 steps. 307 1. (Optional step) Decrypt the first bock of data using the 308 appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san- 309 ity check" of the count. If the count has decreased below the win- 310 dow or has increased by more than 65k, then it is safe to discard 311 this packet as either a replay, non-authentic or too old. If the 312 count is within 65K, then the probability that the packet is 313 authentic is 65535/65536. (The following replay check and HMAC 314 check are both still required). 316 2. Decrypt the count (if not already done), data, pad, pad length, 317 and payload type using DES and the appropriate DES_key_ and 318 IV_key_ (or IV). 320 3. Calculate the HMAC using the HMAC_key_ and create the digest 321 from the SPI, IV (if present) count, data, pad, pad length, and 322 payload type and checking the result at digest at the end of the 323 packet. If the digest is incorrect, discard the packet. 325 4. Check the count using the window algorithm discussed above. If 326 the packet is duplicate or too old, discard the packet. 328 5. Key Material 330 The key K is provided by the key management layer. This key is used 331 to derive the symmetric keys, they are: 333 DES_Key_I1, DES_KEY_I2, and DES_KEY_I3 are the keys used for 334 3DES for traffic from the initiator -> responder. DES_KEY_I1 is the inner 335 most key and DES_KEY_I3 is the outermost key. 337 DES_Key_R1, DES_KEY_R2, and DES_KEY_R3 are the keys used for 338 3DES for traffic from the initiator -> responder. DES_KEY_R3 is the inner 339 most key and DES_KEY_R1 is the outermost key. 341 HMAC_Key_I is the key for the HMAC Algorithm for traffic from the 342 initiator -> responder. 344 HMAC_Key_R is the key for the HMAC Algorithm for traffic from the 345 responder -> initiator. 347 IV_key_I is used to stop code book attacks on the first block for 348 traffic from the initiator -> responder. 350 IV_key_R is used to stop code book attacks on the first block for 351 traffic from the responder -> initiator. 353 RP_key_I is the initial value and wrap point for the replay 354 prevention field for traffic from the initiator -> responder. 356 RP_key_R is the initial value and wrap point for the replay 357 prevention field for traffic from the responder -> initiator. 359 The vertical bar symbol "|" is used to denote concatenation of bit 360 strings. 362 MD5(x|y) denotes the result of applying the MD5 function to the con- 363 catenated bit strings x and y. 365 Truncate(x,n) denotes the result of truncating x to its first n bits. 367 DES_Key_I1 = Truncate(MD5( 0 | D_PAD_I | K ),64) 368 DES_Key_I2 = Truncate(MD5( 1 | D_PAD_I | K ),64) 369 DES_Key_I3 = Truncate(MD5( 2 | D_PAD_I | K ),64) 370 DES_Key_R1 = Truncate(MD5( 0 | D_PAD_R | K ),64) 371 DES_Key_R2 = Truncate(MD5( 1 | D_PAD_R | K ),64) 372 DES_Key_R3 = Truncate(MD5( 2 | D_PAD_R | K ),64) 373 IV_Key_I = Truncate(MD5( I_Pad_I | K ),64) 374 IV_Key_R = Truncate(MD5( I_Pad_R | K ),64) 375 HMAC_Key_I = MD5( H_Pad_I | K ) 376 HMAC_Key_R = MD5( H_Pad_R | K ) 377 RP_Key_I = Truncate(MD5( R_Pad_I | K ),32) 378 RP_Key_R = Truncate(MD5( R_Pad_R | K ),32) 380 where each _Pad_is 512 bit string. 382 D_Pad_I = 0x5C repeated 63 times. 383 D_Pad_R = 0x3A repeated 63 times. 384 I_Pad_I = 0xAC repeated 64 times. 385 I_Pad_R = 0x55 repeated 64 times. 386 H_Pad_I = 0x53 repeated 64 times. 387 H_Pad_R = 0x3C repeated 64 times. 388 R_Pad_I = 0x35 repeated 64 times. 389 R_Pad_R = 0xCC repeated 64 times. 391 (Implementation note, The 16 byte intermediate residuals can be pre- 392 calculated from these constants and stored to reduce processing over- 393 head). 395 6. Security Considerations 397 The ESP-3DES-HMAC-RP transform described in this draft is immune to 398 the [Bellovin96] attacks. (AH [RFC-1826], in some modes, can also 399 provide immunity to these attack.) 401 The implications of the size of K can be found in [Blaze96]. 403 7. References 405 [Bellovin96] Bellovin, S., "Problem Areas for the IP Security Proto- 406 cols", AT&T Research, ftp://ftp.research.att.com/dist/smb/badesp.ps, 407 July, 1996. 409 [FIPS-46] US National Bureau of Standards, "Data Encryption Stan- 410 dard", Federal Information Processing Standard (FIPS) Publication 46, 411 January 1977. 413 [FIPS-46-1] US National Bureau of Standards, "Data Encryption Stan- 414 dard", Federal Information Processing Standard (FIPS) Publication 415 46-1, January 1988. 417 [FIPS-74] US National Bureau of Standards, "Guidelines for Implement- 418 ing and Using the Data Encryption Standard", Federal Information Pro- 419 cessing Standard (FIPS) Publication 74, April 1981. 421 [FIPS-81] US National Bureau of Standards, "DES Modes of Operation" 422 Federal Information Processing Standard (FIPS) Publication 81, 423 December 1980. 425 [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5: 426 Keyed-MD5 for Message Authentication", work-in-progress, 427 http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- 428 hmac-md5-00.txt, March, 1996 430 [Maughan96] Maughan, D., Schertler, M. Internet Security Association 431 and Key Management Protocol (ISAKMP), work-in-progress, 432 http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec- 433 isakmp-04.txt, February, 1996 435 [Orman96] Orman, H., "The Oakley Key Determination Protocol", work- 436 in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft- 437 ietf-ipsec-oakley-00.txt, February, 1996. 439 [RFC-1825] Atkinson, R, "Security Architecture for the Internet Pro- 440 tocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. 442 [RFC-1826] Atkinson, R, "IP Authentication Header", 443 ftp://ds.internic.net/rfc/rfc1826.txt, August 1995. 445 [Schneier95] Schneier, B., "Applied Cryptography Second Edition", 446 John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 448 [Blaze96] Blaze M., Diffie, W., Rivest, R., Schneier, B., Shimomura, 449 T., Thompson, E., Wiener, M., "Minimal Key Lengths for Symmetric 450 Ciphers to Provide Adequate Commercial Security", 451 http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii, January, 452 1996 454 [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementa- 455 tion of Network-layer Security Under Unix", Proceedings of USENIX 456 Security Symposium, Santa Clara, CA, October 1993. 458 [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- 459 Layer Security for IP", presentation at the Spring 1993 IETF Meeting, 460 Columbus, Ohio. 462 8. Acknowledgements 464 This document is based on the document "Combined DES-CBC, HMAC, and 465 Replay Prevention Security Transform," by the IPsec Working Group, J. 466 Naganand, editor [Naganand96]. Much of the text of that document is 467 repeated here, with the details of DES replaced with 3DES. I would like to 468 thank Bob Baldwin, Steve Bellovin, Hugo Krawcyzk, Hilarie Orman, and Bill 469 Sommerfeld for their suggestions on key generation for 3DES. 471 The IPsec working group can be contacted through the chairs: 473 Ran Atkinson 474 475 Cisco Systems 477 Paul Lambert 478 479 Oracle Corporation 481 9. Editor's Address 483 Naganand Doraswamy 484 485 Ftp Software, Inc. 487 Appendix A 489 This is a routine that implements a 32 packet window. This is intend- 490 ed on being an implementation sample. 492 #include 493 #include 494 typedef unsigned long u_long; 496 enum { 497 ReplayWindowSize = 32 498 }; 500 u_long bitmap = 0; /* session state - must be 32 bits */ 501 u_long lastSeq = 0; /* session state */ 503 /* Returns 0 if packet disallowed, 1 if packet permitted */ 504 int ChkReplayWindow(u_long seq); 506 int ChkReplayWindow(u_long seq) { 507 u_long diff; 509 if (seq == 0) return 0; /* first == 0 or wrapped */ 510 if (seq > lastSeq) { /* new larger sequence number */ 511 diff = seq - lastSeq; 512 if (diff < ReplayWindowSize) { /* In window */ 513 bitmap = (bitmap << diff) | 1; /* set bit for this packet */ 514 } else bitmap = 1; /* This packet has a "way larger" */ 515 lastSeq = seq; 516 return 1; /* larger is good */ 517 } 518 diff = lastSeq - seq; 519 if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ 520 if (bitmap & (1l << diff)) return 0; /* this packet already seen */ 521 bitmap |= (1l << diff); /* mark as seen */ 522 return 1; /* out of order but good */ 523 } 525 char string_buffer[512]; 526 #define STRING_BUFFER_SIZE sizeof(string_buffer) 528 int main() { 529 int result; 530 u_long last, current, bits; 532 printf("Input initial state (bits in hex, last msgnum):\n"); 533 if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); 534 sscanf(string_buffer, "%lx %lu", &bits, &last); 535 if (last != 0) 536 bits |= 1; 537 bitmap = bits; 538 lastSeq = last; 539 printf("bits:%08lx last:%lu\n", bitmap, lastSeq); 540 printf("Input value to test (current):\n"); 542 while (1) { 543 if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; 544 sscanf(string_buffer, "%lu", ¤t); 545 result = ChkReplayWindow(current); 546 printf("%-3s", result ? "OK" : "BAD"); 547 printf(" bits:%08lx last:%lu\n", bitmap, lastSeq); 548 } 549 return 0; 550 }