File: rfc2419.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 (675 lines) | stat: -rw-r--r-- 24,414 bytes parent folder | download | duplicates (7)
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
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675






Network Working Group                                         K. Sklower
Request for Comments: 2419            University of California, Berkeley
Obsoletes: 1969                                                 G. Meyer
Category: Standards Track                                          Shiva
                                                          September 1998


         The PPP DES Encryption Protocol, Version 2 (DESE-bis)

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

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.

   The PPP Encryption Control Protocol (ECP) [2] provides a method to
   negotiate and utilize encryption protocols over PPP encapsulated
   links.

   This document provides specific details for the use of the DES
   standard [5, 6] for encrypting PPP encapsulated packets.

Acknowledgements

   The authors extend hearty thanks to Fred Baker of Cisco, Philip
   Rakity of Flowpoint, and William Simpson of Daydreamer for helpful
   improvements to the clarity and correctness of the document.

Table of Contents

   1. Introduction ................................................  2
   1.1. Motivation ................................................  2
   1.2. Conventions ...............................................  2
   2. General Overview ............................................  2
   3. Structure of This Specification .............................  4
   4. DESE Configuration Option for ECP ...........................  4
   5. Packet Format for DESE ......................................  5



Sklower & Meyer             Standards Track                     [Page 1]

RFC 2419                 PPP DES Encryption v2            September 1998


   6. Encryption ..................................................  6
   6.1. Padding Considerations ....................................  7
   6.2. Generation of the Ciphertext ..............................  8
   6.3. Retrieval of the Plaintext ................................  8
   6.4. Recovery after Packet Loss ................................  8
   7. MRU Considerations ..........................................  9
   8. Differences from RFC 1969 ...................................  9
   8.1. When to Pad ...............................................  9
   8.2. Assigned Numbers ..........................................  9
   8.3. Minor Editorial Changes ...................................  9
   9. Security Considerations .....................................  9
   10. References ................................................. 10
   11. Authors' Addresses ......................................... 11
   12. Full Copyright Statement ................................... 12

1.  Introduction

1.1.  Motivation

   The purpose of this memo is two-fold: to show how one specifies the
   necessary details of a "data" or "bearer" protocol given the context
   of the generic PPP Encryption Control Protocol, and also to provide
   at least one commonly-understood means of secure data transmission
   between PPP implementations.

   The DES encryption algorithm is a well studied, understood and widely
   implemented encryption algorithm.  The DES cipher was designed for
   efficient implementation in hardware, and consequently may be
   relatively expensive to implement in software.  However, its
   pervasiveness makes it seem like a reasonable choice for a "model"
   encryption protocol.

   Source code implementing DES in the "Electronic Code Book Mode" can be
   found in [7].  US export laws forbid the inclusion of
   compilation-ready source code in this document.

1.2.  Conventions

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

2.  General Overview

   The purpose of encrypting packets exchanged between two PPP
   implementations is to attempt to insure the privacy of communication
   conducted via the two implementations.  The encryption process
   depends on the specification of an encryption algorithm and a shared



Sklower & Meyer             Standards Track                     [Page 2]

RFC 2419                 PPP DES Encryption v2            September 1998


   secret (usually involving at least a key) between the sender and
   receiver.

   Generally, the encryptor will take a PPP packet including the
   protocol field, apply the chosen encryption algorithm, place the
   resulting cipher text (and in this specification, an explicit
   sequence number) in the information field of another PPP packet.  The
   decryptor will apply the inverse algorithm and interpret the
   resulting plain text as if it were a PPP packet which had arrived
   directly on the interface.

   The means by which the secret becomes known to both communicating
   elements is beyond the scope of this document; usually some form of
   manual configuration is involved.  Implementations might make use of
   PPP authentication, or the EndPoint Identifier Option described in
   PPP Multilink [3], as factors in selecting the shared secret.  If the
   secret can be deduced by analysis of the communication between the
   two parties, then no privacy is guaranteed.

   While the US Data Encryption Standard (DES) algorithm [5, 6] provides
   multiple modes of use, this specification selects the use of only one
   mode in conjunction with the PPP Encryption Control Protocol (ECP):
   the Cipher Block Chaining (CBC) mode.  In addition to the US
   Government publications cited above, the CBC mode is also discussed
   in [7], although no C source code is provided for it per se.

   The initialization vector for this mode is deduced from an explicit
   64-bit nonce, which is exchanged in the clear during the negotiation
   phase.  The 56-bit key required by all DES modes is established as a
   shared secret between the implementations.

   One reason for choosing the chaining mode is that it is generally
   thought to require more computation resources to deduce a 64 bit key
   used for DES encryption by analysis of the encrypted communication
   stream when chaining mode is used, compared with the situation where
   each block is encrypted separately with no chaining.  Certainly,
   identical sequences of plaintext will produce different ciphers when
   chaining mode is in effect, thus complicating analysis.

   However, if chaining is to extend beyond packet boundaries, both the
   sender and receiver must agree on the order the packets were
   encrypted.  Thus, this specification provides for an explicit 16 bit
   sequence number to sequence decryption of the packets.  This mode of
   operation even allows recovery from occasional packet loss; details
   are also given below.






Sklower & Meyer             Standards Track                     [Page 3]

RFC 2419                 PPP DES Encryption v2            September 1998


3.  Structure of This Specification

   The PPP Encryption Control Protocol (ECP), provides a framework for
   negotiating parameters associated with encryption, such as choosing
   the algorithm.  It specifies the assigned numbers to be used as PPP
   protocol numbers for the "data packets" to be carried as the
   associated "data protocol", and describes the state machine.

   Thus, a specification for use in that matrix need only describe any
   additional configuration options required to specify a particular
   algorithm, and the process by which one encrypts/decrypts the
   information once the Opened state has been achieved.

4.  DESE Configuration Option for ECP

   Description

        The ECP DESE Configuration Option indicates that the issuing
        implementation is offering to employ this specification for
        decrypting communications on the link, and may be thought of as
        a request for its peer to encrypt packets in this manner.

        The ECP DESE Configuration Option has the following fields,
        which are transmitted from left to right:

                    Figure 1:  ECP DESE Configuration Option

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Type = 3    |    Length     |         Initial Nonce ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type

             Type = 3, to indicate the DESE-bis protocol.  The former
             value 1 indicating the previous DESE specification is
             deprecated, i.e.  systems implementing this specification
             MUST NOT offer the former value 1 in a configure-request
             and MUST configure-reject the former value on receipt of a
             configure-request containing it.

        Length

             10






Sklower & Meyer             Standards Track                     [Page 4]

RFC 2419                 PPP DES Encryption v2            September 1998


        Initial Nonce

             This field is an 8 byte quantity which is used by the peer
             implementation to encrypt the first packet transmitted
             after the sender reaches the opened state.

             To guard against replay attacks, the implementation SHOULD
             offer a different value during each ECP negotiation.  An
             example might be to use the number of seconds since Jan
             1st, 1970 (GMT/UT) in the upper 32 bits, and the current
             number of nanoseconds relative to the last second mark in
             the lower 32 bits.

             Its formulaic role is described in the Encryption section
             below.

5.  Packet Format for DESE

   Description

        The DESE packets themselves have the following fields:

                  Figure 2:  DES Encryption Protocol Packet Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Address    |    Control    |     0000      |  Protocol ID  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Seq. No. High | Seq. No. Low  |        Ciphertext ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Address and Control

             These fields MUST be present unless the PPP Address and
             Control Field Compression option (ACFC) has been
             negotiated.

        Protocol ID

             The value of this field is 0x53 or 0x55; the latter
             indicates that ciphertext includes headers for the
             Multilink Protocol, and REQUIRES that the Individual Link
             Encryption Control Protocol has reached the opened state.
             The leading zero MAY be absent if the PPP Protocol Field
             Compression option (PFC) has been negotiated.





Sklower & Meyer             Standards Track                     [Page 5]

RFC 2419                 PPP DES Encryption v2            September 1998


        Sequence Number

             These 16-bit numbers are assigned by the encryptor
             sequentially starting with 0 (for the first packet
             transmitted once ECP has reached the opened state.

        Ciphertext

             The generation of this data is described in the next
             section.

6.  Encryption

   Once the ECP has reached the Opened state, the sender MUST NOT apply
   the encryption procedure to LCP packets nor ECP packets.

   If the async control character map option has been negotiated on the
   link, the sender applies mapping after the encryption algorithm has
   been run.

   The encryption algorithm is generally to pad the Protocol and
   Information fields of a PPP packet to some multiple of 8 bytes, and
   apply DES in Chaining Block Cipher mode with a 56-bit key K.

   There are a lot of details concerning what constitutes the Protocol
   and Information fields, in the presence or non-presence of Multilink,
   and whether the ACFC and PFC options have been negotiated, and the
   sort of padding chosen.

   Regardless of whether ACFC has been negotiated on the link, the
   sender applies the encryption procedure to only that portion of the
   packet excluding the address and control field.

   If the Multilink Protocol has been negotiated and encryption is to be
   construed as being applied to each link separately, then the
   encryption procedure is to be applied to the (possibly extended)
   protocol and information fields of the packet in the Multilink
   Protocol.

   If the Multilink Protocol has been negotiated and encryption is to be
   construed as being applied to the bundle, then the multilink
   procedure is to be applied to the resulting DESE packets.









Sklower & Meyer             Standards Track                     [Page 6]

RFC 2419                 PPP DES Encryption v2            September 1998


6.1.  Padding Considerations

   Since the DES algorithm operates on blocks of 8 octets, plain text
   packets which are of length not a multiple of 8 octets must be
   padded.  This can be injurious to the interpretation of some
   protocols which do not contain an explicit length field in their
   protocol headers.

   Since there is no standard directory of protocols which are
   susceptible to corruption through padding, this can lead to confusion
   over which protocols should be protected against padding-induced
   corruption.  Consequently, this specification requires that the
   unambiguous technique described below MUST be applied to ALL plain
   text packets.

   The method of padding is based on that described for the LCP Self-
   Describing-Padding (SDP) option (as defined in RFC 1570 [4]), but
   differs in two respects: first, maximum-pad value is fixed to be 8,
   and second, the method is to be applied to ALL packets, not just
   "specifically identified protocols".

   Plain text which is not a multiple of 8 octets long MUST be padded
   prior to encrypting the plain text with sufficient octets in the
   sequence of octets 1, 2, 3 ... 7 to make the plain text a multiple of
   8 octets.

   Plain text which is already a multiple of 8 octets may require
   padding with a further 8 octets (1, 2, 3 ... 8).  These additional
   octets MUST be appended prior to encrypting the plain text if the
   last octet of the plain text has a value of 1 through 8, inclusive.

   After the peer has decrypted the cipher text, it strips off the
   Self-Describing-Padding octets, to recreate the original plain text.

   Note that after decrypting, only the content of the last octet need
   be examined to determine how many pad bytes should be removed.
   However, the peer SHOULD discard the frame if all the octets forming
   the padding do not match the scheme just described.

   The padding operation described above is performed independently of
   whether or not the LCP Self-Describing-Padding (SDP) option has been
   negotiated.  If it has, SDP would be applied to the packet as a whole
   after it had been ciphered and after the Encryption Protocol
   Identifiers had been prepended.







Sklower & Meyer             Standards Track                     [Page 7]

RFC 2419                 PPP DES Encryption v2            September 1998


6.2.  Generation of the Ciphertext

   In this discussion, E[k] will denote the basic DES cipher determined
   by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the
   corresponding decryption mechanism.  The padded plaintext described
   in the previous section then becomes a sequence of 64 bit blocks P[i]
   (where i ranges from 1 to n).  The circumflex character (^)
   represents the bit-wise exclusive-or operation applied to 64-bit
   blocks.

   When encrypting the first packet to be transmitted in the opened
   state let C[0] be the result of applying E[k] to the Initial Nonce
   received in the peer's ECP DESE option; otherwise let C[0] be the
   final block of the previously transmitted packet.

   The ciphertext for the packet is generated by the iterative process

                        C[i] = E[k](P[i] ^ C[i-1])

   for i running between 1 and n.

6.3.  Retrieval of the Plaintext

   When decrypting the first packet received in the opened state, let
   C[0] be the result of applying E[k] to the Initial Nonce transmitted
   in the ECP DESE option.  The first packet will have sequence number
   zero.  For subsequent packets, let C[0] be the final block of the
   previous packet in sequence space.  Decryption is then accomplished
   by

                        P[i] = C[i-1] ^ D[k](C[i]),

   for i running between 1 and n.

6.4.  Recovery after Packet Loss

   Packet loss is detected when there is a discontinuity in the sequence
   numbers of consecutive packets.  Suppose packet number N - 1 has an
   unrecoverable error or is otherwise lost, but packets N and N + 1 are
   received correctly.

   Since the algorithm in the previous section requires C[0] for packet
   N to be C[last] for packet N - 1, it will be impossible to decode
   packet N.  However, all packets N + 1 and following can be decoded in
   the usual way, since all that is required is the last block of
   ciphertext of the previous packet (in this case packet N, which WAS
   received).




Sklower & Meyer             Standards Track                     [Page 8]

RFC 2419                 PPP DES Encryption v2            September 1998


7.  MRU Considerations

   Because padding can occur, and because there is an additional
   protocol field in effect, implementations should take into account
   the growth of the packets.  As an example, if PFC had been
   negotiated, and if the MRU before had been exactly a multiple of 8,
   then the plaintext resulting combining a full sized data packets with
   a one byte protocol field would require an additional 7 bytes of
   padding, and the sequence number would be an additional 2 bytes so
   that the information field in the DESE protocol is now 10 bytes
   larger than that in the original packet.  Because the convention is
   that PPP options are independent of each other, negotiation of DESE
   does not, by itself, automatically increase the MRU value.

8.  Differences from RFC 1969

8.1.  When to Pad

   In RFC 1969, the method of Self-Describing Padding was not applied to
   all packets transmitted using DESE.  Following the method of the SDP
   option itself, only "specifically identified protocols", were to be
   padded.  Protocols with an explicit length identifier were exempt.
   (Examples included non-VJ-compressed IP, XNS, CLNP).

   In this speficiation, the method is applied to ALL packets.

   Secondly, this specification is clarified as being completely
   independent of the Self-Describing-Padding option for PPP, and fixes
   the maximum number of padding octets as 8.

8.2.  Assigned Numbers

   Since this specification could theoretically cause misinterpretation
   of a packet transmitted according to the previous specification, a
   new type field number has been assigned for the DESE-bis protocol

8.3.  Minor Editorial Changes

   This specification has been designated a standards track document.
   Some other language has been changed for greater clarity.

9.  Security Considerations

   This proposal is concerned with providing confidentiality solely.  It
   does not describe any mechanisms for integrity, authentication or
   nonrepudiation.  It does not guarantee that any message received has
   not been modified in transit through replay, cut-and-paste or active




Sklower & Meyer             Standards Track                     [Page 9]

RFC 2419                 PPP DES Encryption v2            September 1998


   tampering.  It does not provide authentication of the source of any
   packet received, or protect against the sender of any packet denying
   its authorship.

   This proposal relies on exterior and unspecified methods for
   authentication and retrieval of shared secrets.  It proposes no new
   technology for privacy, but merely describes a convention for the
   application of the DES cipher to data transmission between PPP
   implementation.

   Any methodology for the protection and retrieval of shared secrets,
   and any limitations of the DES cipher are relevant to the use
   described here.

10.  References

   [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
       RFC 1661, July 1994.

   [2] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June
       1996.

   [3] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti,
       "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

   [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January
       1994.

   [5] National Bureau of Standards, "Data Encryption Standard", FIPS
       PUB 46 (January 1977).

   [6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB
       81 (December 1980).

   [7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and
       source code in C", John Wiley & Sons, Inc. 1994.  There is an
       errata associated with the book, and people can get a copy by
       sending e-mail to schneier@counterpane.com.

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










Sklower & Meyer             Standards Track                    [Page 10]

RFC 2419                 PPP DES Encryption v2            September 1998


11.  Authors' Addresses

   Keith Sklower
   Computer Science Department
   339 Soda Hall, Mail Stop 1776
   University of California
   Berkeley, CA 94720-1776

   Phone:  (510) 642-9587
   EMail:  sklower@CS.Berkeley.EDU


   Gerry M. Meyer
   Cisco Systems Ltd.
   Bothwell House, Pochard Way,
   Strathclyde Business Park,
   Bellshill, ML4 3HB
   Scotland, UK

   Phone: (UK) (pending)
   Fax:   (UK) (pending)
   Email: gemeyer@cisco.com





























Sklower & Meyer             Standards Track                    [Page 11]

RFC 2419                 PPP DES Encryption v2            September 1998


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
























Sklower & Meyer             Standards Track                    [Page 12]