File: rfc2773.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 (507 lines) | stat: -rw-r--r-- 20,008 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






Network Working Group                                        R. Housley
Request for Comments: 2773                                       P. Yee
Updates: 959                                                     SPYRUS
Category: Experimental                                          W. Nace
                                                                    NSA
                                                          February 2000


                   Encryption using KEA and SKIPJACK

Status of this Memo

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

Copyright Notice

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

Abstract

   This document defines a method to encrypt a file transfer using the
   FTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)",
   (October 1985) [3] and RFC 2228, "FTP Security Extensions" (October
   1997) [1].  This method will use the Key Exchange Algorithm (KEA) to
   give mutual authentication and establish the data encryption keys.
   SKIPJACK is used to encrypt file data and the FTP command channel.

1.0 Introduction

   The File Transfer Protocol (FTP) provides no protocol security except
   for a user authentication password which is transmitted in the clear.
   In addition, the protocol does not protect the file transfer session
   beyond the original authentication phase.

   The Internet Engineering Task Force (IETF) Common Authentication
   Technology (CAT) Working Group has proposed security extensions to
   FTP.  These extensions allow the protocol to use more flexible
   security schemes, and in particular allows for various levels of
   protection for the FTP command and data connections.  This document
   describes a profile for the FTP Security Extensions by which these
   mechanisms may be provisioned using the Key Exchange Algorithm (KEA)
   in conjunction with the SKIPJACK symmetric encryption algorithm.






Housley, et al.               Experimental                      [Page 1]

RFC 2773           Encryption using KEA and SKIPJACK      February 2000


   FTP Security Extensions [1] provides:

      *  user authentication -- augmenting the normal password
         mechanism;

      *  server authentication -- normally done in conjunction with user
         authentication;

      *  session parameter negotiation -- in particular, encryption keys
         and attributes;

      *  command connection protection -- integrity, confidentiality, or
         both;

      *  data transfer protection -- same as for command connection
         protection.

   In order to support the above security services, the two FTP entities
   negotiate a mechanism.  This process is open-ended and completes when
   both entities agree on an acceptable mechanism or when the initiating
   party (always the client) is unable to suggest an agreeable
   mechanism.  Once the entities agree upon a mechanism, they may
   commence authentication and/or parameter negotiation.

   Authentication and parameter negotiation occur within an unbounded
   series of exchanges.  At the completion of the exchanges, the
   entities will either be authenticated (unilateral or mutually), and
   may, additionally, be ready to protect FTP commands and data.

   Following the exchanges, the entities negotiate the size of the
   buffers they will use in protecting the commands and data that
   follow.  This process is accomplished in two steps: the client offers
   a suggested buffer size and the server may either refuse it, counter
   it, or accept it.

   At this point, the entities may issue protected commands within the
   bounds of the parameters negotiated through the security exchanges.
   Protected commands are issued by applying the protection services
   required to the normal commands and Base64 encoding the results. The
   encoded results are sent as the data field within a ENC (integrity
   and confidentiality) command.  Base64 is an encoding for mapping
   binary data onto a textual character set that is able to pass through
   most 7-bit systems without loss.  The server sends back responses in
   new result codes which allow the identical protections and Base64
   encoding to be applied to the results.  Protection of the data
   transfers can be specified via the PROT command which supports the





Housley, et al.               Experimental                      [Page 2]

RFC 2773           Encryption using KEA and SKIPJACK      February 2000


   same protections as those afforded the other FTP commands.  PROT
   commands may be sent on a transfer-by-transfer basis, however, the
   session parameters may not be changed within a session.

2.0  Key Exchange Algorithm (KEA) Profile

   This paper profiles KEA with SKIPJACK to achieve certain security
   services when used in conjunction with the FTP Security Extensions
   framework.  FTP entities may use KEA to give mutual authentication
   and establish data encryption keys.  We specify a simple token format
   and set of exchanges to deliver these services.  Functions that may
   be performed by the Fortezza Crypto Card.

   The reader should be familiar with the extensions in order to
   understand the protocol steps that follow.  In the context of the FTP
   Security Extensions, we suggest the usage of KEA with SKIPJACK for
   authentication, integrity, and confidentiality.

   A client may mutually authenticate with a server.  What follows are
   the protocol steps necessary to perform KEA authentication under the
   FTP Security Extensions framework.  Where failure modes are
   encountered, the return codes follow those specified in the
   Extensions.  They are not enumerated in this document as they are
   invariant among the mechanisms used.  The certificates are ASN.1
   encoded.

   The exchanges detailed below presume a working knowledge of the FTP
   Security Extensions.  The notation for concatenation is " || ".
   Decryption of encrypted data and certification path validation is
   implicitly assumed, but is not shown.

---------------------------------------------------------------------
  Client                             Server

  AUTH KEA-SKIPJACK              -->
                                      <-- 334 ADAT=Base64( Certb || Rb )
  ADAT Base64( Certa || Ra ||
    WMEK || IV || Encrypt(
    Label-Type || Label-Length ||
    Label-List || pad || ICV ) ) -->
                                     <-- 235 ADAT=Base64( IV )
---------------------------------------------------------------------
                             Figure 1

   The server and client certificates contain KEA public keys.  The
   client and server use KEA to generate a shared SKIPJACK symmetric
   key, called the TEK.  The client uses the random number generator to
   create a second SKIPJACK key, called the MEK.  The MEK is wrapped in



Housley, et al.               Experimental                      [Page 3]

RFC 2773           Encryption using KEA and SKIPJACK      February 2000


   the TEK for transfer to the server.  An initialization vector (IV)
   associated with the MEK is generated by the client and transferred to
   the server.  A list of security labels that the client wants to use
   for this FTP session may be transferred to the server encrypted in
   the MEK.  As shown in Figure 2, the security label data is formatted
   as a one octet type value, a four octet label length, the security
   label list, padding, followed by an eight octet integrity check value
   (ICV).  Figure 3 lists the label types.  If the label type is absent
   (value of zero length), then the label size must be zero.

   In order to ensure that the length of the plain text is a multiple of
   the cryptographic block size, padding shall be performed as follows.
   The input to the SKIPJACK CBC encryption process shall be padded to a
   multiple of 8 octets.  Let n be the length in octets of the input.
   Pad the input by appending 8 - (n mod 8) octets to the end of the
   message, each having the value 8 - (n mod 8), the number of octets
   being added.  In hexadecimal, he possible pad strings are: 01, 0202,
   030303, 04040404, 0505050505, 060606060606, 07070707070707, and
   0808080808080808.  All input is padded with 1 to 8 octets to produce
   a multiple of 8 octets in length.  This pad technique is used
   whenever SKIPJACK CBC encryption is performed.

   An ICV is calculated over the plaintext security label and padding.
   The ICV algorithm used is the 32-bit one's complement addition of
   each 32-bit block followed by 32 zero bits.  This ICV technique is
   used in conjunction with SKIPJACK CBC encryption to provide data
   integrity.

   ---------------------------------------------------------------------
                 Label Type                1 Octet
                 Label Length              4 octets
                 Label List                variable length
                 Pad                       1 to 8 octets
                 ICV                       8 octets
   ---------------------------------------------------------------------
                                Figure 2

   ---------------------------------------------------------------------
              Label Type   Label Syntax                Reference
              0            Absent                      Not applicable
              1            MSP                         SDN.701[2]
              2-255        Reserved for Future Use     To Be Determined

   ---------------------------------------------------------------------
                                Figure 3






Housley, et al.               Experimental                      [Page 4]

RFC 2773           Encryption using KEA and SKIPJACK      February 2000


   FTP command channel operations are now confidentiality protected.  To
   provide integrity, the command sequence number, padding, and ICV are
   appended to each command prior to encryption.

   Sequence integrity is provided by using a 16-bit sequence number
   which is incremented for each command.  The sequence number is
   initialized with the least significant 16-bits of Ra.  The server
   response will include the same sequence number as the client command.

   An ICV is calculated over the individual commands (including the
   carriage return and line feed required to terminate commands), the
   sequence number, and pad.

   ---------------------------------------------------------------------
     Client                             Server

     ENC Base64(Encrypt("PBSZ 65535"
         || SEQ || pad || ICV ))     -->
                                        <-- 632  Base64(Encrypt("200" ||
                                                   SEQ || pad || ICV))
     ENC Base64(Encrypt("USER yee"
           || SEQ || pad || ICV))    -->
                                        <-- 632  Base64(Encrypt("331" ||
                                                   SEQ || pad || ICV))
     ENC Base64(Encrypt("PASS
           fortezza" || SEQ ||
           pad || ICV))              -->
                                        <-- 631  Base64(Sign("230"))
   ---------------------------------------------------------------------
                                Figure 4

   After decryption, both parties verifying the integrity of the PBSZ
   commands by checking for the expected sequence number and correct
   ICV.  The correct SKIPJACK key calculation, ICV checking, and the
   validation of the certificates containing the KEA public keys
   provides mutual identification and authentication.

   ---------------------------------------------------------------------
     Client                          Server

     ENC Base64(Encrypt("PROT P" ||
             SEQ || pad || ICV))  -->
                                     <-- 632 Base64(Encrypt("200" || SEQ
                                                    ||  pad || ICV))
   ---------------------------------------------------------------------
                                Figure 5





Housley, et al.               Experimental                      [Page 5]

RFC 2773           Encryption using KEA and SKIPJACK      February 2000


   At this point, files may be sent or received with encryption and
   integrity services in use.  If encryption is used, then the first
   buffer will contain the token followed by enough encrypted file
   octets to completely fill the buffer (unless the file is too short to
   fill the buffer).  Subsequent buffers contain only encrypted file
   octets.  All buffers are completely full except the final buffer.

   ---------------------------------------------------------------------
     Client                         Server

     ENC Base64(Encrypt(
        ("RETR foo.bar") ||
        SEQ || pad || ICV))    -->
                                    <-- 632 Base64(Encrypt("150" ||
                                                SEQ || pad || ICV))
   ---------------------------------------------------------------------
                                Figure 6

   The next figure shows the header information and the file data.

   ---------------------------------------------------------------------
                Plaintext Token IV    24 octets
                WMEK                  12 octets
                Hashvalue             20 octets
                IV                    24 octets
                Label Type            1 octets
                Label Length          4 octets
                Label                 Label Length octets
                Pad                   1 to 8 octets
                ICV                   8 octets
   ---------------------------------------------------------------------
                                Figure 7

2.1  Pre-encrypted File Support

   In order to support both on-the-fly encryption and pre-encrypted
   files, a token is defined for carrying a file encryption key (FEK).
   To prevent truncation and ensure file integrity, the token also
   includes a hash computed on the complete file.  The token also
   contains the security label associate with the file.  This FEK is
   wrapped in the session TEK.  The token is encrypted in the session
   TEK using SKIPJACK CBC mode.  The token contains a 12 octet wrapped
   FEK, a 20 octet file hash, a 24 octet file IV, a 1 octet label type,
   a 4 octet label length, a variable length label value, a one to 8
   octet pad, and an 8 octet ICV.  The first 24 octets of the token are
   the plaintext IV used to encrypt the remainder of the token.  The
   token requires its own encryption IV because it is transmitted across
   the data channel, not the command channel, and ordering between the



Housley, et al.               Experimental                      [Page 6]

RFC 2773           Encryption using KEA and SKIPJACK      February 2000


   channels cannot be guaranteed.  Storage of precomputed keys and
   hashes for files in the file system is a local implementation matter;
   however, it is suggested that if a file is pre-encrypted, then the
   FEK be wrapped in a local storage key.  When the file is needed, the
   FEK is unwrapped using the local storage key, and then rewrapped in
   the session TEK.  Figure 8 shows the assembled token.

   ---------------------------------------------------------------------
               Plaintext Token IV            24 octets
               Wrapped FEK                   12 octets
               Hashvalue                     20 octets
               IV                            24 octets
               Label Type                    1 octet
               Label Length                  4 octets
               Label                         Label Length octets
               Pad                           1 to 8 octets
               ICV                           8 octets
   ---------------------------------------------------------------------
                                 Figure 8

3.0  Table of Key Terminology

   In order to clarify the usage of various keys in this protocol,
   Figure 9 summarizes key types and their usage:

   ---------------------------------------------------------------------
                Key Type         Usage
                TEK              Encryption of token at the beginning of
                                 each file, also wraps the MEK and the FEK
                MEK              Encryption of command channel
                FEK              Encryption of the file itself (may be
                                 done out of scope of FTP)

   ---------------------------------------------------------------------
                                 Figure 9

4.0  Security Considerations

   This entire memo is about security mechanisms.  For KEA to provide
   the authentication and key management discussed, the implementation
   must protect the private key from disclosure.  For SKIPJACK to
   provide the confidentiality discussed, the implementation must
   protect the shared symmetric keys from disclosure.

5.0  Acknowledgements

   We would like to thank Todd Horting for insights gained during
   implementation of this specification.



Housley, et al.               Experimental                      [Page 7]

RFC 2773           Encryption using KEA and SKIPJACK      February 2000


6.0  References

   [1]  Horowitz, M. and S. Lunt,  "FTP Security Extensions", RFC 2228,
        October 1997.

   [2]  Message Security Protocol 4.0 (MSP), Revision A. Secure Data
        Network System (SDNS) Specification, SDN.701, February 6, 1997.

   [3]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
        959, October 1985.

7.0  Authors' Addresses

   Russell Housley
   SPYRUS
   381 Elden Street
   Suite 1120
   Herndon, VA 20170
   USA

   Phone: +1 703 707-0696
   EMail: housley@spyrus.com


   Peter Yee
   SPYRUS
   5303 Betsy Ross Drive
   Santa Clara, CA 95054
   USA

   Phone: +1 408 327-1901
   EMail: yee@spyrus.com



















Housley, et al.               Experimental                      [Page 8]

RFC 2773           Encryption using KEA and SKIPJACK      February 2000


8.0  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Housley, et al.               Experimental                      [Page 9]