File: rfc1851.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (619 lines) | stat: -rw-r--r-- 20,000 bytes parent folder | download | duplicates (5)
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
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619






Network Working Group                                            P. Karn
Request for Comments: 1851                                      Qualcomm
Category: Experimental                                        P. Metzger
                                                                Piermont
                                                              W. Simpson
                                                              Daydreamer
                                                          September 1995


                      The ESP Triple DES Transform


Status of this Memo

   This document defines an Experimental Protocol for the Internet
   community.  This does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.


Abstract

   This document describes the Triple DES-CBC security transform for the
   IP Encapsulating Security Payload (ESP).


Table of Contents

     1.     Introduction ..........................................    2
        1.1       Keys ............................................    2
        1.2       Initialization Vector ...........................    2
        1.3       Data Size .......................................    3
        1.4       Performance .....................................    3

     2.     Payload Format ........................................    4

     3.     Algorithm .............................................    6
        3.1       Encryption ......................................    6
        3.2       Decryption ......................................    7

     SECURITY CONSIDERATIONS ......................................    7
     ACKNOWLEDGEMENTS .............................................    8
     REFERENCES ...................................................    9
     AUTHOR'S ADDRESS .............................................   11







Karn, et al                   Experimental                      [Page 1]

RFC 1851                        ESP 3DES                  September 1995


1.  Introduction

   The Encapsulating Security Payload (ESP) [RFC-1827] provides
   confidentiality for IP datagrams by encrypting the payload data to be
   protected.  This specification describes the ESP use of a variant of
   of the Cipher Block Chaining (CBC) mode of the US Data Encryption
   Standard (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].
   This variant, known as Triple DES (3DES), processes each block of the
   plaintext three times, each time with a different key [Tuchman79].

   This document assumes that the reader is familiar with the related
   document "Security Architecture for the Internet Protocol" [RFC-
   1825], which defines the overall security plan for IP, and provides
   important background for this specification.



1.1.  Keys

   The secret 3DES key shared between the communicating parties is
   effectively 168-bits long.  This key consists of three independent
   56-bit quantities used by the DES algorithm.  Each of the three 56-
   bit subkeys is stored as a 64-bit (eight octet) quantity, with the
   least significant bit of each octet used as a parity bit.



1.2.  Initialization Vector

   This mode of 3DES requires an Initialization Vector (IV) that is
   eight octets in length.

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

   The method for selection of IV values is implementation dependent.

   Notes:
      A common acceptable technique is simply a counter, beginning with
      a randomly chosen value.  While this provides an easy method for
      preventing repetition, and is sufficiently robust for practical
      use, cryptanalysis may use the rare serendipitous occurrence when
      a corresponding bit position in the first DES block increments in
      exactly the same fashion.





Karn, et al                   Experimental                      [Page 2]

RFC 1851                        ESP 3DES                  September 1995


      Other implementations exhibit unpredictability, usually through a
      pseudo-random number generator.  Care should be taken that the
      periodicity of the number generator is long enough to prevent
      repetition during the lifetime of the session key.



1.3.  Data Size

   The 3DES algorithm operates on blocks of eight octets.  This often
   requires padding after the end of the unencrypted payload data.

   Both input and output result in the same number of octets, which
   facilitates in-place encryption and decryption.

   On receipt, if the length of the data to be decrypted is not an
   integral multiple of eight octets, then an error is indicated, as
   described in [RFC-1825].



1.4.  Performance

   Three DES-CBC implementations may be pipelined in series to provide
   parallel computation.  At the time of writing, at least one hardware
   implementation can encrypt or decrypt at about 1 Gbps [Schneier94, p.
   231].
























Karn, et al                   Experimental                      [Page 3]

RFC 1851                        ESP 3DES                  September 1995


2.  Payload Format


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Security Parameters Index (SPI)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Initialization Vector (IV)                  ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          Payload Data                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ... Padding           |  Pad Length   | Payload Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Security Parameters Index (SPI)

      A 32-bit value identifying the Security Parameters for this
      datagram.  The value MUST NOT be zero.

   Initialization Vector (IV)

      The size of this field is variable, although it is constant for
      all 3DES datagrams of the same SPI and IP Destination.  Octets are
      sent in network order (most significant octet first) [RFC-1700].

      The size MUST be a multiple of 32-bits.  Sizes of 32 and 64 bits
      are required to be supported.  The use of other sizes is beyond
      the scope of this specification.  The size is expected to be
      indicated by the key management mechanism.

      When the size is 32-bits, a 64-bit IV is formed from the 32-bit
      value followed by (concatenated with) the bit-wise complement of
      the 32-bit value.  This field size is most common, as it aligns
      the Payload Data for both 32-bit and 64-bit processing.

      All conformant implementations MUST also correctly process a 64-
      bit field size.  This provides strict compatibility with existing
      hardware implementations.

         It is the intent that the value not repeat during the lifetime
         of the encryption session key.  Even when a full 64-bit IV is
         used, the session key SHOULD be changed at least as frequently
         as 2**32 datagrams.




Karn, et al                   Experimental                      [Page 4]

RFC 1851                        ESP 3DES                  September 1995


   Payload Data

      The size of this field is variable.

      Prior to encryption and after decryption, this field begins with
      the IP Protocol/Payload header specified in the Payload Type
      field.  Note that in the case of IP-in-IP encapsulation (Payload
      Type 4), this will be another IP header.

   Padding

      The size of this field is variable.

      Prior to encryption, it is filled with unspecified implementation
      dependent (preferably random) values, to align the Pad Length and
      Payload Type fields at an eight octet boundary.

      After decryption, it MUST be ignored.

   Pad Length

      This field indicates the size of the Padding field.  It does not
      include the Pad Length and Payload Type fields.  The value
      typically ranges from 0 to 7, but may be up to 255 to permit
      hiding of the actual data length.

      This field is opaque.  That is, the value is set prior to
      encryption, and is examined only after decryption.

   Payload Type

      This field indicates the contents of the Payload Data field, using
      the IP Protocol/Payload value.  Up-to-date values of the IP
      Protocol/Payload are specified in the most recent "Assigned
      Numbers" [RFC-1700].

      This field is opaque.  That is, the value is set prior to
      encryption, and is examined only after decryption.

         For example, when encrypting an entire IP datagram (Tunnel-
         Mode), this field will contain the value 4, which indicates
         IP-in-IP encapsulation.









Karn, et al                   Experimental                      [Page 5]

RFC 1851                        ESP 3DES                  September 1995


3.  Algorithm

   The 3DES algorithm is a simple variant on the DES-CBC algorithm.  The
   DES function is replaced by three rounds of that function, an
   encryption followed by a decryption followed by an encryption, each
   with independant keys, k1, k2 and k3.

   Note that when all three keys (k1, k2 and k3) are the same, 3DES is
   equivalent to DES-CBC.  This property allows the 3DES hardware
   implementations to operate in DES mode without modification.

   For more explanation and implementation information for Triple DES,
   see [Schneier94].



3.1.  Encryption

   Append zero or more octets of (preferably random) padding to the
   plaintext, to make its modulo 8 length equal to 6.  For example, if
   the plaintext length is 41, 5 octets of padding are added.

   Append a Pad Length octet containing the number of padding octets
   just added.

   Append a Payload Type octet containing the IP Protocol/Payload value
   which identifies the protocol header that begins the payload.

   Provide an Initialization Vector (IV) of the size indicated by the
   SPI.

   Encrypt the payload with Triple DES (EDE mode), producing a
   ciphertext of the same length.

   Octets are mapped to DES blocks in network order (most significant
   octet first) [RFC-1700].  Octet 0 (modulo 8) of the payload
   corresponds to bits 1-8 of the 64-bit DES input block, while octet 7
   (modulo 8) corresponds to bits 57-64 of the DES input block.

   Construct an appropriate IP datagram for the target Destination, with
   the indicated SPI, IV, and payload.

   The Total/Payload Length in the encapsulating IP Header reflects the
   length of the encrypted data, plus the SPI, IV, padding, Pad Length,
   and Payload Type octets.






Karn, et al                   Experimental                      [Page 6]

RFC 1851                        ESP 3DES                  September 1995


3.2.  Decryption

   First, the SPI field is removed and examined.  This is used as an
   index into the local Security Parameter table to find the negotiated
   parameters and decryption key.

   The negotiated form of the IV determines the size of the IV field.
   These octets are removed, and an appropriate 64-bit IV value is
   constructed.

   The encrypted part of the payload is decrypted using Triple DES (DED
   mode).

   The Payload Type is removed and examined.  If it is unrecognized, the
   payload is discarded with an appropriate ICMP message.

   The Pad Length is removed and examined.  The specified number of pad
   octets are removed from the end of the decrypted payload, and the IP
   Total/Payload Length is adjusted accordingly.

   The IP Header(s) and the remaining portion of the decrypted payload
   are passed to the protocol receive routine specified by the Payload
   Type field.



Security Considerations

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

   Among other considerations, applications may wish to take care not to
   select weak keys for any of the three DES rounds, although the odds
   of picking one at random are low [Schneier94, p. 233].

   It was originally thought that DES might be a group, but it has been
   demonstrated that it is not [CW92].  Since DES is not a group,
   composition of multiple rounds of DES is not equivalent to simply
   using DES with a different key.

   Triple DES with independent keys is not, as naively might be
   expected, as difficult to break by brute force as a cryptosystem with
   three times the keylength.  A space/time tradeoff has been shown
   which can brute-force break triple block encryptions in the time



Karn, et al                   Experimental                      [Page 7]

RFC 1851                        ESP 3DES                  September 1995


   naively expected for double encryption [MH81].

   However, 2DES can be broken with a meet-in-the-middle attack, without
   significantly more complexity than breaking DES requires [ibid], so
   3DES with independant keys is actually needed to provide this level
   of security.  An attack on 3DES using two independent keys that is
   somewhat (sixteen times) faster than any known for independent keys
   has been shown [OW91].

   The cut and paste attack described by [Bell95] exploits the nature of
   all Cipher Block Chaining algorithms.  When a block is damaged in
   transmission, on decryption both it and the following block will be
   garbled by the decryption process, but all subsequent blocks will be
   decrypted correctly.  If an attacker has legitimate access to the
   same key, this feature can be used to insert or replay previously
   encrypted data of other users of the same engine, revealing the
   plaintext.  The usual (ICMP, TCP, UDP) transport checksum can detect
   this attack, but on its own is not considered cryptographically
   strong.  In this situation, user or connection oriented integrity
   checking is needed [RFC-1826].

   Although it is widely believed that 3DES is substantially stronger
   than DES, as it is less amenable to brute force attack, it should be
   noted that real cryptanalysis of 3DES might not use brute force
   methods at all.  Instead, it might be performed using variants on
   differential [BS93] or linear [Matsui94] cryptanalysis.  It should
   also be noted that no encryption algorithm is permanently safe from
   brute force attack, because of the increasing speed of modern
   computers.

   As with all cryptosystems, those responsible for applications with
   substantial risk when security is breeched should pay close attention
   to developments in cryptography, and especially cryptanalysis, and
   switch to other transforms should 3DES prove weak.



Acknowledgements

   Some of the text of this specification was derived from work by
   Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.

   Comments should be submitted to the ipsec@ans.net mailing list.








Karn, et al                   Experimental                      [Page 8]

RFC 1851                        ESP 3DES                  September 1995


References

   [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without
            Strong Integrity", Proceedings of the 32nd IETF, Danvers,
            MA, April 1995.

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

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

   [CW92]   Campbell, K.W., and Wiener, M.J., "Proof that DES Is Not a
            Group", Advances in Cryptology -- Crypto '92 Proceedings,
            Berlin: Springer-Verlag, 1993, pp 518-526.

   [FIPS-46]
            US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46, January 1977.

   [FIPS-46-1]
            US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46-1, January 1988.

   [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.

   [FIPS-81]
            US National Bureau of Standards, "DES Modes of Operation"
            Federal Information Processing Standard (FIPS) Publication
            81, December 1980.

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

   [MH81]   Merle, R.C., and Hellman, M., "On the Security of Multiple
            Encryption", Communications of the ACM, v. 24 n. 7, 1981,
            pp. 465-467.




Karn, et al                   Experimental                      [Page 9]

RFC 1851                        ESP 3DES                  September 1995


   [OW91]   van Oorschot, P.C., and Weiner, M.J.  "A Known-Plaintext
            Attack on Two-Key Triple Encryption", Advances in Cryptology
            -- Eurocrypt '90 Proceedings, Berlin: Springer-Verlag, 1991,
            pp. 318-325.

   [RFC-1800]
            Postel, J., "Internet Official Protocol Standards", STD 1,
            RFC 1800, USC/Information Sciences Institute, July 1995.

   [RFC-1700]
            Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
            1700, USC/Information Sciences Institute, October 1994.

   [RFC-1825]
            Atkinson, R., "Security Architecture for the Internet
            Protocol", RFC-1825, Naval Research Laboratory, July 1995.

   [RFC-1826]
            Atkinson, R., "IP Authentication Header", RFC-1826, Naval
            Research Laboratory, July 1995.

   [RFC-1827]
            Atkinson, R., "IP Encapsulating Security Protocol (ESP)",
            RFC-1827, Naval Research Laboratory, July 1995.

   [Schneier94]
            Schneier, B., "Applied Cryptography", John Wiley & Sons, New
            York, NY, 1994.  ISBN 0-471-59756-2

   [Tuchman79]
            Tuchman, W, "Hellman Presents No Shortcut Solutions to DES",
            IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41.



















Karn, et al                   Experimental                     [Page 10]

RFC 1851                        ESP 3DES                  September 1995


Author's Address

   Questions about this memo can also be directed to:

      Phil Karn
      Qualcomm, Inc.
      6455 Lusk Blvd.
      San Diego, California  92121-2779

      karn@unix.ka9q.ampr.org


      Perry Metzger
      Piermont Information Systems Inc.
      160 Cabrini Blvd., Suite #2
      New York, NY  10033

      perry@piermont.com


      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

      Bill.Simpson@um.cc.umich.edu
          bsimpson@MorningStar.com























Karn, et al                   Experimental                     [Page 11]