File: rfc2420.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 (451 lines) | stat: -rw-r--r-- 16,729 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






Network Working Group                                         H. Kummert
Request for Comments: 2420                                   Nentec GmbH
Category: Standards Track                                 September 1998


             The PPP Triple-DES Encryption Protocol (3DESE)

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 Triple-DES
   standard (3DES) [6] for encrypting PPP encapsulated packets.

Table of Contents

   1.   Introduction .............................................. 2
   1.1  Algorithm ................................................. 2
   1.2  Keys ...................................................... 3
   2.   3DESE Configuration Option for ECP ........................ 3
   3.   Packet format for 3DESE ................................... 4
   4.   Encryption ................................................ 5
   4.1  Padding ................................................... 5
   4.2  Recovery after packet loss ................................ 6
   5.   Security Considerations ................................... 6
   6.   References ................................................ 7
   7.   Acknowledgements .......................................... 7
   8.   Author's Address .......................................... 7
   9.   Full Copyright Statement .................................. 8





Kummert                     Standards Track                     [Page 1]

RFC 2420               PPP Triple-DES Encryption          September 1998


1. Introduction

   The purpose of encrypting packets exchanged between two PPP
   implementations is to attempt to insure the privacy of communication
   conducted via the two implementations. There exists a large variety
   of encryption algorithms, where one is the DES algorithm. The DES
   encryption algorithm is a well studied, understood and widely
   implemented encryption algorithm.  Triple-DES means that this
   algorithm is applied three times on the data to be encrypted before
   it is sent over the line. The variant used is the DES-EDE3-CBC, which
   is described in more detail in the text. It was also chosen to be
   applied in the security section of IP [5].

   This document shows how to send via the Triple-DES algorithm
   encrypted packets over a point-to-point-link. It lies in the context
   of the generic PPP Encryption Control Protocol [2].

   Because of the use of the CBC-mode a sequence number is provided to
   ensure the right order of transmitted packets. So lost packets can be
   detected.

   The padding section reflects the result of the discussion on this
   topic on the ppp mailing list.

   In this document, the key words "MUST", "SHOULD", and "recommended"
   are to be interpreted as described in [3].

1.1  Algorithm

   The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC
   algorithm.  In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd
   with the first 64-bit (8 octet) plaintext block (P1).  The keyed DES
   function is iterated three times, an encryption (E) followed by a
   decryption (D) followed by an encryption (E), and generates the
   ciphertext (C1) for the block. Each iteration uses an independent
   key: k1, k2 and k3.

   For successive blocks, the previous ciphertext block is XOR'd with
   the current 8-octet plaintext block (Pi). The keyed DES-EDE3
   encryption function generates the ciphertext (Ci) for that block.











Kummert                     Standards Track                     [Page 2]

RFC 2420               PPP Triple-DES Encryption          September 1998


                      P1             P2                 Pi
                      |              |                  |
               IV--->(X)    +------>(X)      +-------->(X)
                      v     |        v       |          v
                   +-----+  |     +-----+    |       +-----+
               k1->|  E  |  | k1->|  E  |    :   k1->|  E  |
                   +-----+  |     +-----+    :       +-----+
                      |     |        |       :          |
                      v     |        v       :          v
                   +-----+  ^     +-----+    ^       +-----+
               k2->|  D  |  | k2->|  D  |    |   k2->|  D  |
                   +-----+  |     +-----+    |       +-----+
                      |     |        |       |          |
                      v     |        v       |          v
                   +-----+  |     +-----+    |       +-----+
               k3->|  E  |  | k3->|  E  |    |   k3->|  E  |
                   +-----+  |     +-----+    |       +-----+
                      |     |        |       |          |
                      +---->+        +------>+          +---->
                      |              |                  |
                      C1             C2                 Ci

   To decrypt, the order of the functions is reversed: decrypt with k3,
   encrypt with k2, decrypt with k1, and XOR with the previous cipher-
   text block.

   When all three keys (k1, k2 and k3) are the same, DES-EDE3-CBC is
   equivalent to DES-CBC.

1.2  Keys

   The secret DES-EDE3 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 (8 octet) quantity, with the least
   significant bit of each octet used as a parity bit.

   When configuring keys for 3DESE those with incorrect parity or so-
   called weak keys [6] SHOULD be rejected.

2.  3DESE Configuration Option for ECP

   Description

        The ECP 3DESE 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



Kummert                     Standards Track                     [Page 3]

RFC 2420               PPP Triple-DES Encryption          September 1998


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

                   Figure 1:  ECP 3DESE 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      |    Length     |         Initial Nonce ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

           2, to indicate the 3DESE protocol.

      Length

           10

      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.

3.  Packet format for 3DESE

   Description

        The 3DESE packets that contain the encrypted payload have the
        following fields:

               Figure 2:  3DESE 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



Kummert                     Standards Track                     [Page 4]

RFC 2420               PPP Triple-DES Encryption          September 1998


              negotiated.

        Protocol ID

              The value of this field is 0x53 or 0x55; the latter
              indicates the use of the Individual Link Encryption
              Control Protocol and that the ciphertext contains a
              Multilink fragment.  Protocol Field Compression MAY be
              applied to the leading zero if negotiated.

        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.

4.  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 3DES as described in section 1.1 with the three 56-bit keys k1,
   k2 and k3.

   The encryption procedure is only applied to that portion of the
   packet excluding the address and control field.

   When encrypting the first packet after ECP stepped into opened state
   the Initial Nonce is encrypted via 3DES-algorithm before its use.

4.1  Padding

   Since the 3DES algorithm operates on blocks of 8 octets, plain text
   packets which are of length not a multiple of 8 octets must be padded
   prior to encrypting.  If this padding is not removed after decryption
   this can be injurious to the interpretation of some protocols which
   do not contain an explicit length field in their protocol headers.



Kummert                     Standards Track                     [Page 5]

RFC 2420               PPP Triple-DES Encryption          September 1998


   Therefore all packets not already a multiple of eight bytes in length
   MUST be padded prior to encrypting using the unambiguous technique of
   Self Describing Padding with a Maximum Pad Value (MPV) of 8. This
   means that the plain text is padded with the sequence of octets 1, 2,
   3, .. 7 since its length is a multiple of 8 octets. Negotiation of
   SDP is not needed.  Negotiation of the LCP Self Describing Option may
   be negotiated independently to solve an orthogonal problem.

   Plain text which length is already a multiple of 8 octets may require
   padding with a further 8 octets (1, 2, 3 ... 8).  These additional
   octets MUST only be appended, if the last octet of the plain text had
   a value of 8 or less.

   When using Multilink and encrypting on individual links it is
   recommended that all non-terminating fragments have a length
   divisible by 8. So no additional padding is needed on those
   fragments.

   After the peer has decrypted the ciphertext, it strips off the Self
   Describing Padding octets to recreate the original plain text.  The
   peer SHOULD discard the frame if the octets forming the padding do
   not match the Self Describing Padding scheme just described.

   Note that after decrypting, only the content of the last byte needs
   to be examined to determine the presence or absence of a Self
   Described Pad.

4.2  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 previously described algorithm requires the last Ci of
   packet N - 1 to decrypt C1 of packet N, it will be impossible to
   decrypt packet N.  However, all packets N + 1 and following can be
   decrypted 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).

5.  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
   tampering.  It does not provide authentication of the source of any



Kummert                     Standards Track                     [Page 6]

RFC 2420               PPP Triple-DES Encryption          September 1998


   packet received, or protect against the sender of any packet denying
   its authorship.

   Security issues are the primary subject of this memo. This proposal
   relies on exterior and unspecified methods for retrieval of shared
   secrets.  It proposes no new technology for privacy, but merely
   describes a convention for the application of the 3DES cipher to data
   transmission between PPP implementations.  Any methodology for the
   protection and retrieval of shared secrets, and any limitations of
   the 3DES cipher are relevant to the use described here.

6.  References

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


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

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

   [4]  Sklower, K., and G. Meyer, "The PPP DES Encryption Protocol,
        Version 2 (DESE-bis)", RFC 2419, September 1998.

   [5]  Doraswamy, N., Metzger, P., Simpson, W., "The ESP Triple DES
        Transform", Work in Progress, June 1997.

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

7.  Acknowledgements

   Many portions of this document were taken from [4] and [5]. Bill
   Simpson gave useful hints on the initial revision.

8. Author's Address

   Holger Kummert
   Nentec Gesellschaft fuer Netzwerktechnologie
   76227 Karlsruhe, Killisfeldstr. 64, Germany

   Phone: +49 721 9495 0
   EMail: kummert@nentec.de






Kummert                     Standards Track                     [Page 7]

RFC 2420               PPP Triple-DES Encryption          September 1998


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
























Kummert                     Standards Track                     [Page 8]