summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2405.txt
blob: d9109aba5929bca149cfb87b14cf9f8d50743783 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
Network Working Group                                          C. Madson
Request for Comments: 2405                           Cisco Systems, Inc.
Category: Standards Track                                   N. Doraswamy
                                                      Bay Networks, Inc.
                                                           November 1998


                    The ESP DES-CBC Cipher Algorithm
                            With Explicit IV

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document describes the use of the DES Cipher algorithm in Cipher
   Block Chaining Mode, with an explicit IV, as a confidentiality
   mechanism within the context of the IPSec Encapsulating Security
   Payload (ESP).

1. Introduction

   This document describes the use of the DES Cipher algorithm in Cipher
   Block Chaining Mode as a confidentiality mechanism within the context
   of the Encapsulating Security Payload.

   DES is a symmetric block cipher algorithm. The algorithm is described
   in [FIPS-46-2][FIPS-74][FIPS-81]. [Schneier96] provides a general
   description of Cipher Block Chaining Mode, a mode which is applicable
   to several encryption algorithms.

   As specified in this memo, DES-CBC is not an authentication
   mechanism. [Although DES-MAC, described in [Schneier96] amongst other
   places, does provide authentication, DES-MAC is not discussed here.]

   For further information on how the various pieces of ESP fit together
   to provide security services, refer to [ESP] and [road].





Madson & Doraswamy          Standards Track                     [Page 1]
^L
RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].

2. Algorithm and Mode

   DES-CBC is a symmetric secret-key block algorithm. It has a block
   size of 64 bits.

   [FIPS-46-2][FIPS-74] and [FIPS-81] describe the DES algorithm, while
   [Schneier96] provides a good description of CBC mode.

2.1 Performance

   Phil Karn has tuned DES-CBC software to achieve 10.45 Mbps with a 90
   MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium.  Other DES
   speed estimates may be found in [Schneier96].

3. ESP Payload

   DES-CBC requires an explicit Initialization Vector (IV) of 8 octets
   (64 bits).  This IV immediately precedes the protected (encrypted)
   payload. The IV MUST be a random value.

   Including the IV in each datagram ensures that decryption of each
   received datagram can be performed, even when some datagrams are
   dropped, or datagrams are re-ordered in transit.

   Implementation note:

      Common practice is to use random data for the first IV and the
      last 8 octets of encrypted data from an encryption process as the
      IV for the next encryption process; this logically extends the CBC
      across the packets. It also has the advantage of limiting the
      leakage of information from the random number genrator. No matter
      which mechnism is used, the receiver MUST NOT assume any meaning
      for this value, other than that it is an IV.

      To avoid ECB encryption of very similar plaintext blocks in
      different packets, implementations MUST NOT use a counter or other
      low-Hamming distance source for IVs.

   The payload field, as defined in [ESP], is broken down according to
   the following diagram:







Madson & Doraswamy          Standards Track                     [Page 2]
^L
RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998


      +---------------+---------------+---------------+---------------+
      |                                                               |
      +                   Initialization Vector (IV)                  +
      |                                                               |
      +---------------+---------------+---------------+---------------+
      |                                                               |
      ~              Encrypted Payload (variable length)              ~
      |                                                               |
      +---------------------------------------------------------------+
       1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

3.1 Block Size and Padding

   The DES-CBC algorithm described in this document MUST use a block
   size of 8 octets (64 bits).

   When padding is required, it MUST be done according to the
   conventions specified in [ESP].

4. Key Material

   DES-CBC is a symmetric secret key algorithm. The key size is 64-bits.
   [It is commonly known as a 56-bit key as the key has 56 significant
   bits; the least significant bit in every byte is the parity bit.]

   [arch] describes the general mechanism to derive keying material for
   the ESP transform. The derivation of the key from some amount of
   keying material does not differ between the manually- and
   automatically-keyed security associations.

   This mechanism MUST derive a 64-bit key value for use by this cipher.
   The mechanism will derive raw key values, the derivation process
   itself is not responsible for handling parity or weak key checks.

   Weak key checks SHOULD be performed. If such a key is found, the key
   SHOULD be rejected and a new SA requested.

   Implementation note:

      If an implementation chooses to do weak key checking, it should
      recognize that the known weak keys [FIPS74] have been adjusted for
      parity. Otherwise the handling of parity is a local issue.

   A strong pseudo-random function MUST be used to generate the required
   key. For a discussion on this topic, reference [RFC1750].






Madson & Doraswamy          Standards Track                     [Page 3]
^L
RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998


4.1 Weak Keys

   DES has 16 known weak keys, including so-called semi-weak keys.  The
   list of weak keys can be found in [FIPS74].

4.2 Key Lifetime

   [Blaze96] discusses the costs and key recovery time for brute force
   attacks. It presents various combinations of total cost/time to
   recover a key/cost per key recovered for 40-bit and 56-bit DES keys,
   based on late 1995 estimates.

   While a brute force search of a 56-bit DES keyspace can be considered
   infeasable for the so-called casual hacker, who is simply using spare
   CPU cycles or other low-cost resources, it is within reach of someone
   willing to spend a bit more money.

   For example, for a cost of $300,000, a 56-bit DES key can be
   recovered in an average of 19 days using off-the-shelf technology and
   in only 3 hours using a custom developed chip.

   It should be noted that there are other attacks which can recover the
   key faster, that brute force attacks are considered the "worst case",
   although the easiest to implement.

   [Wiener94] also discusses a $1M machine which can break a DES key in
   3.5 hours (1993 estimates), using a known-plaintext attack. As
   discussed in the Security Considerations section, a known plaintext
   attack is reasonably likely.

   It should also be noted that over time, the total and average search
   costs as well as the average key recovery time will continue to drop.

   While the above does not provide specific recommendations for key
   lifetime, it does reinforce the point that for a given application
   the desired key lifetime is dependent upon the perceived threat (an
   educated guess as to the amount of resources available to the
   attacker) relative to the worth of the data to be protected.

   While there are no recommendations for volume-based lifetimes made
   here, it shoud be noted that given sufficient volume there is an
   increased probabilty that known plaintext can be accumulated.

5. Interaction with Authentication Algorithms

   As of this writing, there are no known issues which preclude the use
   of the DES-CBC algorithm with any specific authentication algorithm.




Madson & Doraswamy          Standards Track                     [Page 4]
^L
RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998


6. Security Considerations

   [Much of this section was originally written by William Allen Simpson
   and Perry Metzger.]

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of the DES
   algorithm, the correctness of that algorithm's implementation, the
   security of the Security Association management mechanism and its
   implementation, the strength of the key [CN94], and upon the
   correctness of the implementations in all of the participating nodes.

   [Bell95] and [Bell96] describe a cut and paste splicing attack which
   applies to all Cipher Block Chaining algorithms. This attack can be
   addressed with the use of an authentication mechanism.

   The use of the cipher mechanism without any corresponding
   authentication mechanism is strongly discouraged. This cipher can be
   used in an ESP transform that also includes authentication; it can
   also be used in an ESP transform that doesn't include authentication
   provided there is an companion AH header. Refer to [ESP], [AH],
   [arch], and [road] for more details.

   When the default ESP padding is used, the padding bytes have a
   predictable value.  They provide a small measure of tamper detection
   on their own block and the previous block in CBC mode.  This makes it
   somewhat harder to perform splicing attacks, and avoids a possible
   covert channel.  This small amount of known plaintext does not create
   any problems for modern ciphers.

   At the time of writing of this document, [BS93] demonstrated a
   differential cryptanalysis based chosen-plaintext attack requiring
   2^47 plaintext-ciphertext pairs, where the size of a pair is the size
   of a DES block (64 bits). [Matsui94] demonstrated a linear
   cryptanalysis based known-plaintext attack requiring only 2^43
   plaintext-ciphertext pairs.  Although these attacks are not
   considered practical, they must be taken into account.

   More disturbingly, [Wiener94] has shown the design of a DES cracking
   machine costing $1 Million that can crack one key every 3.5 hours.
   This is an extremely practical attack.

   One or two blocks of known plaintext suffice to recover a DES key.
   Because IP datagrams typically begin with a block of known and/or
   guessable header text, frequent key changes will not protect against
   this attack.





Madson & Doraswamy          Standards Track                     [Page 5]
^L
RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998


   It is suggested that DES is not a good encryption algorithm for the
   protection of even moderate value information in the face of such
   equipment.  Triple DES is probably a better choice for such purposes.

   However, despite these potential risks, the level of privacy provided
   by use of ESP DES-CBC in the Internet environment is far greater than
   sending the datagram as cleartext.

   The case for using random values for IVs has been refined with the
   following summary provided by Steve Bellovin. Refer to [Bell97] for
   further information.

      "The problem arises if you use a counter as an IV, or some other
      source with a low Hamming distance between successive IVs, for
      encryption in CBC mode.  In CBC mode, the "effective plaintext"
      for an encryption is the XOR of the actual plaintext and the
      ciphertext of the preceeding block.  Normally, that's a random
      value, which means that the effective plaintext is quite random.
      That's good, because many blocks of actual plaintext don't change
      very much from packet to packet, either.

      For the first block of plaintext, though, the IV takes the place
      of the previous block of ciphertext.  If the IV doesn't differ
      much from the previous IV, and the actual plaintext block doesn't
      differ much from the previous packet's, then the effective
      plaintext won't differ much, either.  This means that you have
      pairs of ciphertext blocks combined with plaintext blocks that
      differ in just a few bit positions.  This can be a wedge for
      assorted cryptanalytic attacks."

   The discussion on IVs has been updated to require that an
   implementation not use a low-Hamming distance source for IVs.

7. References

   [Bell95]     Bellovin, S., "An Issue With DES-CBC When Used Without
                Strong Integrity", Presentation at the 32nd Internet
                Engineering Task Force, Danvers Massachusetts, April
                1995.

   [Bell96]     Bellovin, S., "Problem Areas for the IP Security
                Protocols", Proceedings of the Sixth Usenix Security
                Symposium, July 1996.








Madson & Doraswamy          Standards Track                     [Page 6]
^L
RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998


   [Bell97]     Bellovin, S., "Probable Plaintext Cryptanalysis of the
                IP Security Protocols", Proceedings of the Symposium on
                Network and Distributed System Security, San Diego, CA,
                pp. 155-160, February 1997 (also
                http://www.research.att.com/~smb/papers/probtxt.{ps,
                pdf}).

   [BS93]       Biham, E., and A. Shamir, "Differential Cryptanalysis of
                the Data Encryption Standard", Berlin: Springer-Verlag,
                1993.

   [Blaze96]    Blaze, M., Diffie, W., Rivest, R., Schneier, B.,
                Shimomura, T., Thompson, E., and M. Wiener, "Minimal Key
                Lengths for Symmetric Ciphers to Provide Adequate
                Commercial Security", currently available at
                http://www.bsa.org/policy/encryption/cryptographers.html.

   [CN94]       Carroll, J.M., and S. Nudiati, "On Weak Keys and Weak
                Data:  Foiling the Two Nemeses", Cryptologia, Vol. 18
                No. 23 pp.  253-280, July 1994.

   [FIPS-46-2]  US National Bureau of Standards, "Data Encryption
                Standard", Federal Information Processing Standard
                (FIPS) Publication 46-2, December 1993,
                http://www.itl.nist.gov/div897/pubs/fip46-2.htm
                (supercedes FIPS-46-1).

   [FIPS-74]    US National Bureau of Standards, "Guidelines for
                Implementing and Using the Data Encryption Standard",
                Federal Information Processing Standard (FIPS)
                Publication 74, April 1981,
                http://www.itl.nist.gov/div897/pubs/fip74.htm.

   [FIPS-81]    US National Bureau of Standards, "DES Modes of
                Operation", Federal Information Processing Standard
                (FIPS) Publication 81, December 1980,
                http://www.itl.nist.gov/div897/pubs/fip81.htm.

   [Matsui94]   Matsui, M., "Linear Cryptanalysis method for DES
                Cipher", Advances in Cryptology -- Eurocrypt '93
                Proceedings, Berlin:  Springer-Verlag, 1994.

   [RFC-1750]   Eastlake, D., Crocker, S., and J. Schiller, "Randomness
                Recommendations for Security", RFC 1750, December 1994.

   [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.




Madson & Doraswamy          Standards Track                     [Page 7]
^L
RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998


   [Schneier96] Schneier, B., "Applied Cryptography Second Edition",
                John Wiley & Sons, New York, NY, 1996.  ISBN 0-471-
                12845-7.

   [Wiener94]   Wiener, M.J., "Efficient DES Key Search", School of
                Computer Science, Carleton University, Ottawa, Canada,
                TR-244, May 1994.  Presented at the Rump Session of
                Crypto '93. [Reprinted in "Practical Cryptography for
                Data Internetworks", W.Stallings, editor, IEEE Computer
                Society Press, pp.31-79 (1996).  Currently available at
                ftp://ripem.msu.edu/pub/crypt/docs/des-key-search.ps.]

   [ESP]        Kent, S., and R. Atkinson, "IP Encapsulating Security
                Payload (ESP)", RFC 2406, November 1998.

   [AH]         Kent, S., and R. Atkinson, "IP Authentication Header
                (AH)", RFC 2402, November 1998.

   [arch]       Kent, S., and R. Atkinson, "Security Architecture for
                the Internet Protocol", RFC 2401, November 1998.

   [road]       Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
                Document Roadmap", RFC 2411, November 1998.

8. Acknowledgments

   Much of the information provided here originated with various ESP-DES
   documents authored by Perry Metzger and William Allen Simpson,
   especially the Security Considerations section.

   This document is also derived in part from previous works by Jim
   Hughes, those people that worked with Jim on the combined DES-
   CBC+HMAC-MD5 ESP transforms, the ANX bakeoff participants, and the
   members of the IPsec working group.

   Thanks to Rob Glenn for assisting with the nroff formatting.















Madson & Doraswamy          Standards Track                     [Page 8]
^L
RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998


   The IPSec working group can be contacted via the IPSec working
   group's mailing list (ipsec@tis.com) or through its chairs:

     Robert Moskowitz
     International Computer Security Association

     EMail: rgm@icsa.net


     Theodore Y. Ts'o
     Massachusetts Institute of Technology

     EMail: tytso@MIT.EDU


9. Editors' Addresses

   Cheryl Madson
   Cisco Systems, Inc.

   EMail: cmadson@cisco.com


   Naganand Doraswamy
   Bay Networks, Inc.

   EMail: naganand@baynetworks.com
























Madson & Doraswamy          Standards Track                     [Page 9]
^L
RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998


10.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Madson & Doraswamy          Standards Track                    [Page 10]
^L