idnits 2.17.1 draft-sabin-esp-des3-lzs-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-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 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 8 longer pages, the longest (page 2) being 59 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 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([Hughes96], [RFC-1974]), 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 265: '... and MUST NOT be 0....' RFC 2119 keyword, line 269: '...icit initialization vector (IV) MAY be...' RFC 2119 keyword, line 294: '...ly, the receiver MAY choose to operate...' RFC 2119 keyword, line 324: '...vely, a receiver MAY elect to use a wi...' RFC 2119 keyword, line 349: '.... Padding bytes SHOULD contain random...' (8 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'Bellovin96' is mentioned on line 699, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Blaze96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Calgary' -- 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. 'Hughes96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Krawczyk96' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1974 ** Downref: Normative reference to an Experimental RFC: RFC 1851 Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft October 1996 (Expires April 1997) 3 M. Sabin, Consultant 4 R. Monsour, Hi/fn Inc. 6 Combined 3DES-CBC, LZS Compression, HMAC, and Replay Prevention 7 ESP Transform 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This document proposes the "3DES-CBC-LZS-HMAC-Replay" security 31 transform for the IP Encapsulating Security Payload (ESP). The 32 proposed transform combines triple-DES encryption, LZS compression, 33 HMAC authentication, and replay prevention into a single packet 34 format. The transform is compatible with implementations that do not 35 support compression and with implementations that support only 36 single-DES encryption. Compression is performed prior to encryption, 37 which has the side benefit of reducing the amount of data that must 38 be encrypted. 40 This document is based on the IPsec Working Group's proposed 41 "Combined DES-CBC, HMAC, and Replay Prevention Security Transform," 42 cited later in this document. 44 Acknowledgments 46 This memo is based on the document "Combined DES-CBC, HMAC, and 47 Replay Prevention Security Transform," by the IPsec Working Group, J. 49 Sabin, et al [Page 1] 50 Hughes, editor [Hughes96]. Much of the text of that document is 51 repeated here, with details specific to LZS and triple-DES added. 52 The LZS details are similar to those in "PPP Stac LZS Compression 53 Protocol," by R. Friend and W. A. Simpson [RFC-1974]. 55 Table of Contents 57 1. Introduction 58 2. Packet Format 59 3. Encode Procedure 60 4. Decode Procedure 61 5. Generating Key Material 62 6. Security Considerations 63 7. References 64 8. Author's Addresses 65 9. Appendix: Guidelines for Resetting Compression History 67 1. Introduction 69 Encrypted data is random in nature and not compressible. When an IP 70 packet is encrypted, the usual techniques for compressing it -- e.g., 71 PPP compression -- do not work. If both compression and encryption 72 are desired, compression must be performed first. 74 1.1 Compression with ESP 76 ESP is well suited to combining compression with encryption, for a 77 variety of reasons: 79 - ESP is the place were encryption is applied to an IP packet. 80 It is straightforward to precede the encryption step by a 81 compression step. A side benefit of compressing the data first 82 is that the amount of data which must be encrypted is reduced. 83 In some implementations, compression is done in hardware and 84 encryption in software, and this represents a significant 85 reduction in software processing. 87 - ESP supports routing of opaque data. When a packet is 88 encrypted, intermediate nodes along a route are not able to 89 decrypt it. Nevertheless, the encrypted packet can be routed, 90 because ESP has been designed with this in mind. When a packet 91 is compressed within ESP, the situation is similar: 92 intermediate nodes are not able to decompress it (at least 93 without additional expense), but ESP ensures that the 94 compressed packet can be routed. 96 - ESP provides a security parameters index (SPI) that links a 97 packet to security parameters negotiated elsewhere. A 99 Sabin, et al [Page 2] 100 destination node uses the SPI to look up the ESP transform 101 needed to decode an incoming packet. If compression details 102 are included in ESP transform specifications, a destination 103 node can also use the SPI to determine if a packet needs to be 104 decompressed, and if so, by what algorithm. Source and 105 destination nodes can maintain multiple compression histories 106 (described in a later section), one history for each SPI. 108 1.2 Background of LZS Compression 110 The LZS algorithm is a lossless compression method that uses a 111 sliding window of 2,048 bytes. During compression, redundant 112 sequences of data are replaced with tokens that represent those 113 sequences. During decompression, the original sequences are 114 substituted for the tokens, in such a way that the original data 115 is exactly recovered. LZS differs from lossy schemes, such as 116 those often used for video compression, that do not exactly 117 reproduce the original data. 119 Details of LZS formatting can be found in [ANSI94]. 121 The efficiency of the LZS algorithm depends on the degree of 122 redundancy in the original data. A typical compression ratio for 123 disk files is 2:1. LZS achieves a compression ratio of 2.34:1 on 124 the University of Calgary Text Compression Corpus [Calgary]. 126 The LZS algorithm is stateful. It maintains a "history" in which 127 compression information is stored. The compression operation 128 requires a "compression history" and the decompression operation a 129 "decompression history." Each of these histories is initialized to 130 a start state before any data is processed. Thereafter, as data 131 is compressed and decompressed, the two histories remain 132 synchronized, provided that the decompressor processes all the 133 data generated by the compressor, in the order in which it is 134 generated. 136 An LZS compression/decompression history pair can be reset to the 137 start state at any time. This can be used to restore 138 synchronization between compressor and decompressor when data 139 received by the decompressor has been lost or corrupted. This is 140 particularly important in IP, where the delivery of individual 141 packets is not guaranteed. 143 When LZS compression is applied to a block of data, it sometimes 144 happens that the "compressed" block is actually larger than the 145 original, uncompressed block. In IP, it would be undesirable to 146 transmit a block that has expanded in this way. Accordingly, when 147 LZS results in expansion, this specification calls for the 148 transmitter to send the uncompressed data instead of the 149 compressed data. The packet format includes a bit to signal the 151 Sabin, et al [Page 3] 152 receiver that the packet contents are not compressed. 154 When the transmitter sends uncompressed data, it still updates its 155 compression history as if it had actually compressed the data. 156 This enhances its ability to compress future data. When the 157 receiver receives uncompressed data, it updates its decompression 158 history using the uncompressed data. This keeps the decompression 159 history in sync with the compression history. 161 An application can maintain multiple compression and/or 162 decompression processes by maintaining multiple histories, one 163 history for each process. Each process operates independently of 164 the others. This is useful in IPsec, since it allows each 165 security association (as indexed by the SPI) to have its own 166 history. 168 1.3 Licensing 170 Source and object licenses for LZS are available on a 171 non-discriminatory basis. Hardware implementations are also 172 available. For more information, contact Hi/fn at the address 173 listed with the authors' addresses. 175 1.4 3DES-CBC-LZS-HMAC-Replay ESP Transform 177 The transform proposed in this memo combines triple-DES in CBC 178 mode (3DES-CBC), LZS compression, HMAC authentication, and replay 179 prevention. The proposed transform is based heavily on the 180 transform presented in [Hughes96]. Much of the text from that 181 document has been repeated here. 183 The goals of the transform are: privacy; compression; 184 authenticity; integrity; and defense against replay. 186 - Privacy is provided by 3DES-CBC [RFC-1851], which is a 187 variant of conventional DES-CBC [FIPS-46] [FIPS-46-1] [FIPS-74] 188 [FIPS-81]. 190 - Compression is provided by the LZS algorithm [ANSI94]. 192 - Integrity is provided by HMAC [Krawczyk96]. 194 - Authentication is provided since only the source and 195 destination know the HMAC key. If the HMAC is correct, it 196 proves that it must have been added by the source. 198 - Replay prevention is provided by the combination of a 199 constantly increasing count, the SPI and the HMAC key. 200 Integrity of the count is provided by the HMAC. 202 Sabin, et al [Page 4] 203 3DES-CBC encryption uses a double-length key (112 bits) or a 204 triple-length key (168 bits). Triple-length is usually preferred for 205 security reasons, but some hardware devices only support 206 double-length. Accordingly, this transform supports both 207 double-length and triple-length keys as a negotiated parameter. 209 The transform also supports single-length keys (56 bits) as a 210 negotiated parameter. This makes it compatible with implementations 211 that only support conventional (i.e., single) DES-CBC. 213 1.5 Requirements Terminology 215 In this document, the words that are used to define the 216 significance of each particular requirement are usually 217 capitalized. These words are: 219 - MUST: This word, or the adjective "REQUIRED," means that the 220 item is an absolute requirement of the specification. 222 - SHOULD: This word, or the adjective "RECOMMENDED," means 223 that there might exist valid reasons in particular 224 circumstances to ignore this item, but the full implications 225 should be understood and the case carefully weighed before 226 taking a different course. 228 - MAY: This word, or the adjective "OPTIONAL," means that the 229 item is truly optional. One vendor might choose to include the 230 item because of a particular marketplace requirement or because 231 it enhances the product, while another vendor might omit the 232 item. 234 Sabin, et al [Page 5] 235 2. Packet Format 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 238 | Security Parameters Index (SPI) | ^ 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 240 | | | 241 | Initialization Vector (optional) | | 242 | | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --- 244 | Replay Prevention Field (count) | | ^ 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 246 | |HMAC | 247 | Payload Data (compressed or uncompressed) | | | 248 | | | | 249 | +-+-+-+-+-+-+-+-| | | 250 | | | | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 3DES 252 | Padding (0-7 bytes) | | CBC 253 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 254 | | Pad Length | CC | Payload Type | v | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | 256 | | | 257 | HMAC digest | | 258 | | v 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 261 2.1 Security Parameters Index 263 This field contains a 32-bit value identifying the security 264 association for this packet. The value is negotiated at key setup 265 and MUST NOT be 0. 267 2.2 Initialization Vector 269 The use of an explicit initialization vector (IV) MAY be 270 negotiated. The purpose of this mode is to support devices that 271 automatically generate IV's and cannot operate using a constant 272 IV_key_. 274 This field is optional and is only used when an explicit IV is 275 negotiated during key exchange. This field contains random data 276 or the last ciphertext block of the previous packet. 278 2.3 Replay Prevention 280 This field contains an unsigned, 32-bit, incrementing counter. 281 The counter is initialized to a mutually agreed upon value (see 283 Sabin, et al [Page 6] 284 the section on Generating Key Material). 286 2.3.1 Security Issues 288 To defend against replay attacks, the receiver verifies that 289 received packets have non-repeating counter values. The 290 simplest approach is for the receiver to reject any packet 291 whose counter has a value less than or equal to that of any 292 previously received packet. A consequence of this simple 293 approach is that out-of-order packets will be rejected. 294 Alternatively, the receiver MAY choose to operate with a window 295 of acceptable counter values: a packet will not be rejected if 296 its counter value is within some value M of the highest counter 297 value received so far, provided that the counter value has not 298 been seen before. For an example implementation of such a 299 strategy, see [Hughes96]. 301 The counter is not allowed to cycle back to its starting value. 302 This requires that the key be changed before 2^32 packets have 303 been transmitted. The receiver rejects any packet whose 304 counter value indicates cycling back through the starting 305 value. 307 2.3.2 Compression Issues 309 In addition to defending against replay attacks, the counter 310 plays a role in the decompression of packets. When a packet is 311 received out of order, the receiver detects the misordering 312 because of the counter value. Because LZS is stateful, the 313 receiver may or may not be able to decompress the out-of-order 314 packet. If the history was reset by the transmitter 315 immediately prior to compressing the packet, the receiver can 316 decompress it, because decompression does not depend on any 317 previous packets. (The packet includes a flag in the CC field 318 that indicates whether or not the history was reset.) But if 319 the history was not reset by the transmitter immediately prior 320 to compressing the packet, the receiver cannot decompress it. 322 When a receiver is unable to decompress an out-of-order packet, 323 the simplest strategy for the receiver is to discard it. 324 Alternatively, a receiver MAY elect to use a windowing scheme 325 similar to that described in Section 2.3.1, in order to 326 accommodate a reasonable spread of out-of-order packets. Note 327 that if the windowing scheme is used, the receiver must queue 328 all packets that fall within the window but are not yet 329 decompressible. This makes it more expensive than the scheme 330 previously described, which only had to queue counter values. 332 Decompressing out-of-order packets is only an issue for the 334 Sabin, et al [Page 7] 335 final destination of a packet. Intermediate nodes along a 336 route do not decompress packets and thus can handle packets in 337 any order. 339 2.4 Payload Data 341 The payload data is either compressed or uncompressed. The value 342 of the COMPRESSED bit of the CC field is set accordingly. The 343 payload field is an integral number of bytes in length. 345 2.5 Padding 347 The padding is used to align the subsequent "payload type" field 348 to end on a double-word boundary, counting from the start of the 349 replay field. Padding bytes SHOULD contain random data. 351 At a minimum, the number of padding bytes added must be enough to 352 align the payload type field on the next appropriate boundary. 353 However, the sender may choose to include additional padding, in 354 order to hide the actual length of the data. In general, the 355 sender can use any number of padding bytes in the range of 0-255, 356 provided that the required alignment is achieved. 358 2.6 Pad Length 360 This field indicates the number of padding bytes immediately 361 preceding it. The range of valid values is 0-255, where a value 362 of zero indicates the byte immediately preceding the pad length 363 field is the last byte of payload. 365 2.7 Compression Control 367 The Compression Control (CC) field is a single, bit-mapped byte. 368 The bits are numbered 7 (most significant) to 0 (least 369 significant). The following bits are defined: 371 2.7.1 COMPRESSED (bit 7) 373 This bit is set to 1 to indicate the payload is compressed. It 374 is cleared to 0 to indicate the payload is not compressed. 376 In implementations that do not support compression, this bit 377 is always cleard to 0. 379 Sabin, et al [Page 8] 380 2.7.2 HIST_RESET (bit 6) 382 This bit is set to 1 to indicate that the compression history 383 associated with this packet's SPI was reset prior to processing 384 this packet's payload. In such a case, the receiver must reset 385 the corresponding decompression history prior to processing the 386 payload. If the payload is compressed, it can always be 387 decompressed, because compression is not based on any previous 388 history. 390 This bit is cleared to 0 to indicate that the compression 391 history associated with this packet's SPI was not reset prior 392 to transmitting the payload. If the payload is compressed, it 393 can only be decompressed if there have been no missed packets 394 since the last packet that had the bit set to 1. A packet that 395 cannot be decompressed because of missing packets is either 396 rejected or, if the implementation supports it, queued in the 397 hope that it can be decompressed when the missing packets 398 arrive. 400 The transmitter SHOULD adopt a policy of periodically resetting 401 the compression history and setting the HIST_RESET bit. This 402 allows a receiver that has missed packets to resynchronize its 403 decompressor. The details of such a policy are up to the 404 transmitter implementation. An attached appendix gives 405 guidelines. 407 The transmitter MUST flush the compressor each time it 408 transmits a compressed packet, regardless of whether or not it 409 resets the compression history. Flushing means that all data 410 going into the compressor is included in the output, i.e., no 411 data is held back in the hope of achieving better compression. 412 Flushing is necessary to prevent a packet's data from spilling 413 over into a later packet. 415 2.8 Payload Type 417 This field indicates the type of payload, using the IP 418 Protocol/Payload value. Values are described in [RFC-1700]. 420 2.9 HMAC Digest 422 The HMAC digest is a 128-bit residue, calculated over the SPI, 423 replay, payload, padding, pad length, CC, and payload type. 424 Details of the calculation can be found in [Krawczyk96]. 426 HMAC is a keyed algorithm based on MD5. It uses the HMAC key 427 described in the section on keys. 429 Sabin, et al [Page 9] 430 3. Encode Procedure 432 For compression, the LZS algorithm is used. 434 For encryption, CBC chaining is used. The initialization vector is 435 either the contents of the IV field or the IV_key_: 437 IV or 438 IV_key_ count|x1 x2 x3 439 | | | | 440 |--------(+) ----------(+) ----------(+) 441 | | | | | 442 --------- | --------- | --------- 443 k1--| DES | | k1--| DES | | k1--| DES | 444 |encrypt| | |encrypt| | |encrypt| 445 --------- | --------- | --------- 446 | | | | | 447 --------- | --------- | --------- 448 k2--| DES | | k2--| DES | | k2--| DES | 449 |decrypt| | |decrypt| | |decrypt| 450 --------- | --------- | --------- 451 | | | | | 452 --------- | --------- | --------- 453 k3--| DES | | k3--| DES | | k3--| DES | 454 |encrypt| | |encrypt| | |encrypt| 455 --------- | --------- | --------- 456 |------| |------| |----... 457 | | | 458 y1 y2 y3 460 In the figure: count is the value in the replay prevention field; 461 x1, x2, x3 are the plaintext (x1 is 32 bits, all others are 64 bits); 462 y1, y2, y3 are the ciphertext; k1, k2, k3 are the 56-bit portions of 463 the triple-length key. (When a double-length key is used, k3 = k1. 464 When a single-length key is used, k3 = k2 = k1.) 466 The transform is carried out in the following steps: 468 i) If the transmitter chooses to reset the compression history, 469 it does so, and it sets the HIST_RESET bit of the CC field to 1. 470 Otherwise, it clears the HIST_RESET bit to 0. 472 ii) The transmitter decides whether or not to compress the 473 payload. 475 - If the transmitter chooses to compress the payload, the LZS 476 algorithm is applied. The resulting compressed data is 477 formatted according to [ANSI94]. The COMPRESSED bit of the CC 478 field is set to 1. 480 - If the transmitter chooses not to compress the payload, the 481 COMPRESSED bit of the CC field is set to 0. The compression 482 history is updated with the uncompressed payload. 484 iii) The payload is encapsulated with the SPI, IV (if used), 485 replay, padding, pad length, CC, and payload type. The padding 486 and pad length are appropriately adjusted. The replay is 487 incremented by one from its previous value. 489 iv) The HMAC is calculated. The calculation uses the HMAC_key_ 490 and spans the SPI, IV (if used), replay, payload, padding, pad 491 length, CC, and payload type. The result is placed in the HMAC 492 digest field. 494 v) The replay, payload, padding, pad length, CC, payload type, 495 and HMAC digest are encrypted using 3DES-CBC with the appropriate 496 DES_key_. The initialization vector is the IV field, if used, or 497 the appropriate IV_key_. 499 An implementation SHOULD monitor the results of the payload 500 compression operation and reject the operation if it results in 501 expansion. In such a case, the uncompressed payload SHOULD be 502 transmitted. 504 4. Decode Procedure 506 For decryption, CBC chaining is used: 508 IV or 509 IV_key_ y1 y2 y3 510 | | | | 511 | |------- |------- |----... 512 | | | | | | 513 | --------- | --------- | --------- 514 | k3--| DES | | k3--| DES | | k3--| DES | 515 | |decrypt| | |decrypt| | |decrypt| 516 | --------- | --------- | --------- 517 | | | | | | 518 | --------- | --------- | --------- 519 | k2--| DES | | k2--| DES | | k2--| DES | 520 | |encrypt| | |encrypt| | |encrypt| 521 | --------- | --------- | --------- 522 | | | | | | 523 | --------- | --------- | --------- 524 | k1--| DES | | k1--| DES | | k1--| DES | 525 | |decrypt| | |decrypt| | |decrypt| 526 | --------- | --------- | --------- 527 | | | | | | 528 |---------(+) |---------(+) |---------(+) 529 | | | 530 (count|x1) x2 x3 532 For decompression, the LZS algorithm is used. The decompression 533 maintains a state variable "expected_count," which tracks the value 534 of count expected in the next packet. Expected_count is initialized 535 to the starting value of the replay count; this value was mutually 536 agreed upon, as described in the section on Generating Key Material. 538 In the procedure described here, it is assumed that out-of-order 539 packets are not queued for the purposes of decompression. Compressed 540 packets that cannot be immediately decompressed are discarded. 541 Implementations MAY choose a scheme that queues packets, allowing 542 some spread of out-of-order packets to be decompressed; this was 543 discussed in Section 2.3.2. 545 The transform is carried out in the following steps: 547 i) The replay, payload, padding, pad length, CC, payload type, 548 and HMAC digest are decrypted using 3DES-CBC and the appropriate 549 DES_key_. The initialization vector is the IV field, if used, or 550 the appropriate IV_key_. 552 ii) The count is checked for replay attack using the window 553 algorithm discussed in Section 2.3.1. If the packet is duplicate 554 or too old, the packet is discarded. 556 iii) The HMAC is calculated. The calculation uses the HMAC_key_ 557 and spans the SPI, IV (if used), replay, payload, padding, pad 558 length, CC, and payload type. The calculated digest is compared 559 against the decrypted digest at the end of the packet. If the two 560 do not match, the packet is discarded. 562 iv) The HIST_RESET bit of the CC is checked. 564 - If HIST_RESET = 1, the decompression history is reset, and 565 expected_count is set to (count + 1). 567 - If HIST_RESET = 0, the value of count is compared to 568 expected_count. If the two match, expected_count is set to 569 (count + 1). If the two do not match, expected_count is 570 unchanged; and if COMPRESSED = 1, the packet is discarded. 571 (Queuing out-of-order packets is not considered here, but an 572 implementation MAY choose to implement queuing instead of 573 immediate discard, as discussed in Section 2.3.2.) 575 v) The COMPRESSED bit of the CC is checked. If COMPRESSED = 1, 576 decompression is applied to the payload data. If COMPRESSED = 0, 577 decompression is not applied, and the decompression history is 578 updated with the uncompressed data. 580 An implementation MAY choose to perform a "sanity check" prior to the 581 above procedure. In the sanity check, the first block of data is 582 decrypted using the appropriate DES_key_ and IV_key_, and the 583 decrypted value of the replay count is checked. If the count is way 584 out of range -- e.g., more than 2^16 away from the expected value -- 585 the packet is discarded as non-authentic. This helps defend against 586 clogging attacks, in which an attacker tries to tie up the receiver's 587 resources by having it decrypt meaningless packets. Note that if the 588 sanity check passes, the above procedure MUST still be performed. 590 5. Generating Key Material 592 The key management layer provides several negotiated parameters: 594 - The master secret K. 596 - The length of the DES symmetric keys: triple length (168 bits), 597 double length (112 bits), or single length (56 bits). 599 - Compression support: yes or no. 601 The master secret K is used to derive the following symmetric keys: 603 DES_Key_I1, DES_Key_I2, and DES_Key_I3 are the three parts of the 604 triple-length DES key for traffic from the initiator -> responder. 605 When a double-length key is used, DES_Key_I3 = DES_Key_I1. 606 When a single-length key is used, DES_Key_I3 = DES_KEY_I2 = 607 DES_Key_I1. 609 DES_Key_R1, DES_Key_R2, and DES_Key_R3 are the three parts of the 610 triple-length DES key for traffic from the responder -> initiator. 611 When a double-length key is used, DES_Key_R3 = DES_Key_R1. 612 When a single-length key is used, DES_Key_R3 = DES_KEY_R2 = 613 DES_Key_R1. 615 HMAC_Key_I is the key for the HMAC Algorithm for traffic from the 616 initiator -> responder. 618 HMAC_Key_R is the key for the HMAC Algorithm for traffic from the 619 responder -> initiator. 621 IV_key_I is used to stop code book attacks on the first block for 622 traffic from the initiator -> responder. 624 IV_key_R is used to stop code book attacks on the first block for 625 traffic from the responder -> initiator. 627 RP_key_I is the initial value and wrap point for the replay 628 prevention field for traffic from the initiator -> responder. 630 RP_key_R is the initial value and wrap point for the replay 631 prevention field for traffic from the responder -> initiator. 633 The vertical bar symbol "|" is used to denote concatenation of bit 634 strings. 636 MD5(x|y) denotes the result of applying the MD5 function to the 637 concatenated bit strings x and y. 639 Truncate(x,n) denotes the result of truncating x to its first n bits. 641 IV_Key_I = Truncate(MD5( I_Pad_I | K ),64) 642 IV_Key_R = Truncate(MD5( I_Pad_R | K ),64) 643 HMAC_Key_I = MD5( H_Pad_I | K ) 644 HMAC_Key_R = MD5( H_Pad_R | K ) 645 RP_Key_I = Truncate(MD5( R_Pad_I | K ),32) 646 RP_Key_R = Truncate(MD5( R_Pad_R | K ),32) 648 For triple-length DES keys: 650 DES_Key_I1 = Truncate(MD5( D_Pad_I1 | K ),64) 651 DES_Key_I2 = Truncate(MD5( D_Pad_I2 | K ),64) 652 DES_Key_I3 = Truncate(MD5( D_Pad_I3 | K ),64) 653 DES_Key_R1 = Truncate(MD5( D_Pad_R1 | K ),64) 654 DES_Key_R2 = Truncate(MD5( D_Pad_R2 | K ),64) 655 DES_Key_R3 = Truncate(MD5( D_Pad_R3 | K ),64) 657 For double-length DES keys: 659 DES_Key_I1 = Truncate(MD5( D_Pad_I1 | K ),64) 660 DES_Key_I2 = Truncate(MD5( D_Pad_I2 | K ),64) 661 DES_Key_I3 = DES_Key_I1 662 DES_Key_R1 = Truncate(MD5( D_Pad_R1 | K ),64) 663 DES_Key_R2 = Truncate(MD5( D_Pad_R2 | K ),64) 664 DES_Key_R3 = DES_Key_R1 666 For single-length DES keys: 668 DES_Key_I1 = Truncate(MD5( D_Pad_I1 | K ),64) 669 DES_Key_I3 = DES_Key_I2 = DES_Key_I1 670 DES_Key_R1 = Truncate(MD5( D_Pad_R1 | K ),64) 671 DES_Key_R3 = DES_Key_R2 = DES_Key_R1 673 Note: Each DES_Key_ is in the usual "7 bits plus parity" format, 674 which is why the above procedure generates 64 bits instead of 56 675 bits. The values of the parity bits in each DES_Key_ should either 676 be corrected or ignored. 678 Each _Pad_is a 512 bit string, as follows: 680 D_Pad_I1 = 0x5C repeated 64 times 681 D_Pad_I2 = 0xA3 repeated 64 times 682 D_Pad_I3 = 0xCA repeated 64 times 683 D_Pad_R1 = 0x3A repeated 64 times 684 D_Pad_R2 = 0xA5 repeated 64 times 685 D_Pad_R3 = 0xC3 repeated 64 times 686 I_Pad_I = 0xAC repeated 64 times 687 I_Pad_R = 0x55 repeated 64 times 688 H_Pad_I = 0x53 repeated 64 times 689 H_Pad_R = 0x3C repeated 64 times 690 R_Pad_I = 0x35 repeated 64 times 691 R_Pad_R = 0xCC repeated 64 times 693 (Implementation note: The 16 byte intermediate residuals can be 694 precalculated from these constants and stored to reduce processing 695 overhead.) 697 6. Security Considerations 699 The transform described in this draft is immune to the [Bellovin96] 700 attacks. 702 The implications of the size of K can be found in [Blaze96]. 704 7. References 706 [ANSI94] American National Standards Institute, Inc., "Data 707 Compression Method for Information Systems," ANSI X3.241-1994, 708 August 1994. 710 [Blaze96] Blaze, M., Diffie, W., Rivest, R., Schneir, B., Shimomura, 711 T., Thompson, E., Wiener, M., "Minimal Key Lengths for Symmetric 712 Ciphers to Provide Adequate Commercial Security," 713 http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii, January 714 1996. 716 [Calgary] Text Compression Corpus, University of Calgary, available 717 at 718 ftp://ftp.cpsc.ucalgary.ca/pub/projects/text.compression.corpus. 720 [FIPS-46] US National Bureau of Standards, "Data Encryption 721 Standard," Federal Information Processing Standard (FIPS) 722 Publication 46, January 1977. 724 [FIPS-46-1] US National Bureau of Standards, "Data Encryption 725 Standard," Federal Information Processing Standard (FIPS) 726 Publication 46-1, January 1988. 728 [FIPS-74] US National Bureau of Standards, "Guidelines for 729 Implementing and Using the Data Encryption Standard," Federal 730 Information Processing Standard (FIPS) Publication 74, April 1981. 732 [FIPS-81] US National Bureau of Standards, "DES Modes of Operation," 733 Federal Information Processing Standard (FIPS) Publication 81, 734 December 1980. 736 [Hughes96] Hughes, J. editor, "Combined DES-CBC, HMAC, and Replay 737 Prevention Security Transform," work-in-progress, available from 738 ftp://ds.internic.net/internet-drafts 739 /draft-ietf-ipsec-esp-des-md5-03.txt. 741 [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5: 742 Keyed-MD5 for Message Authentication," work-in-progress, available 743 from 744 ftp://ds.internic.net/internet-drafts 745 /draft-ietf-ipsec-hmac-md5-00.txt. 747 [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers," STD 2, 748 RFC-1700, UCS/Information Sciences Institute, October 1994. 750 [RFC-1974] Friend, R., and Simpson, W.A., "PPP Stac LZS Compression 751 Protocol," RFC-1974, Stac Electronics, August 1996. 753 [RFC-1851] Karn, P., Metzger, P., and Simpson, W., "The ESP Triple 754 DES Transform," RFC-1851, Qualcomm, September 1995. 756 8. Authors' Addresses 758 Michael Sabin 759 883 Mango Avenue 760 Sunnyvale, CA 94087 761 Email: mike.sabin@worldnet.att.net 763 Robert Monsour 764 Hi/fn Inc. 765 12636 High Bluff Drive 766 San Diego, CA 92130 767 Email: rmonsour@hifn.com 769 9. Appendix: Guidelines for Resetting Compression Histories 771 The following table offers some guidance on how frequently an LZS 772 compression history can be reset. The table considers two 773 parameters: "payload_bytes," the number of bytes in each payload; and 774 "reset_bytes," the number of bytes between history resets. 775 Reset_bytes is a multiple of payload_bytes, since an integer number 776 of payloads is processed between resets. Each entry in the table 777 shows the compression ratio that was achieved when compressing a test 778 file with the corresponding values of payload_bytes and reset_bytes. 780 The test file was the University of Calgary Text Compression Corpus 781 [Calgary]. The length of the file prior to compression was 3,278,000 782 bytes. When the entire file was compressed as a single payload, a 783 compression ratio of 2.34 resulted. 785 | reset_bytes 786 | 64 128 256 512 1024 2048 4096 8192 16384 787 ------------+----------------------------------------------------- 788 packet_bytes| 789 64 | 1.18 1.26 1.37 1.48 1.61 1.74 1.84 1.89 1.92 790 128 | 1.28 1.40 1.53 1.67 1.82 1.93 1.99 2.03 791 256 | 1.43 1.56 1.71 1.86 1.98 2.05 2.08 792 512 | 1.58 1.73 1.89 2.01 2.08 2.11 793 1024 | 1.74 1.90 2.02 2.09 2.13 794 2048 | 1.91 2.03 2.10 2.14 795 4096 | 2.04 2.10 2.14 796 8192 | 2.11 2.14 797 16384 | 2.14 799 The table suggests that not there is not much degradation in 800 compression ratio if the compression history is reset after several 801 thousand bytes have been processed. Resetting after less than 1,000 802 bytes is probably too soon -- the compression ratio degrades 803 significantly. But waiting longer than about 8,000 bytes gains 804 little -- the compression ratio does not increase much.