File: rfc2228.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 (1515 lines) | stat: -rw-r--r-- 58,733 bytes parent folder | download | duplicates (10)
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
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515






Network Working Group                                        M. Horowitz
Request for Comments: 2228                              Cygnus Solutions
Updates: 959                                                     S. Lunt
Category: Standards Track                                       Bellcore
                                                            October 1997

                        FTP Security Extensions

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 (1997).  All Rights Reserved.

Abstract

   This document defines extensions to the FTP specification STD 9, RFC
   959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985).  These extensions
   provide strong authentication, integrity, and confidentiality on both
   the control and data channels with the introduction of new optional
   commands, replies, and file transfer encodings.

   The following new optional commands are introduced in this
   specification:

      AUTH (Authentication/Security Mechanism),
      ADAT (Authentication/Security Data),
      PROT (Data Channel Protection Level),
      PBSZ (Protection Buffer Size),
      CCC (Clear Command Channel),
      MIC (Integrity Protected Command),
      CONF (Confidentiality Protected Command), and
      ENC (Privacy Protected Command).

   A new class of reply types (6yz) is also introduced for protected
   replies.

   None of the above commands are required to be implemented, but
   interdependencies exist.  These dependencies are documented with the
   commands.

   Note that this specification is compatible with STD 9, RFC 959.



Horowitz & Lunt             Standards Track                     [Page 1]

RFC 2228                FTP Security Extensions             October 1997


1.  Introduction

   The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959
   and in place on the Internet uses usernames and passwords passed in
   cleartext to authenticate clients to servers (via the USER and PASS
   commands).  Except for services such as "anonymous" FTP archives,
   this represents a security risk whereby passwords can be stolen
   through monitoring of local and wide-area networks.  This either aids
   potential attackers through password exposure and/or limits
   accessibility of files by FTP servers who cannot or will not accept
   the inherent security risks.

   Aside from the problem of authenticating users in a secure manner,
   there is also the problem of authenticating servers, protecting
   sensitive data and/or verifying its integrity.  An attacker may be
   able to access valuable or sensitive data merely by monitoring a
   network, or through active means may be able to delete or modify the
   data being transferred so as to corrupt its integrity.  An active
   attacker may also initiate spurious file transfers to and from a site
   of the attacker's choice, and may invoke other commands on the
   server.  FTP does not currently have any provision for the encryption
   or verification of the authenticity of commands, replies, or
   transferred data.  Note that these security services have value even
   to anonymous file access.

   Current practice for sending files securely is generally either:

      1.  via FTP of files pre-encrypted under keys which are manually
          distributed,

      2.  via electronic mail containing an encoding of a file encrypted
          under keys which are manually distributed,

      3.  via a PEM message, or

      4.  via the rcp command enhanced to use Kerberos.

   None of these means could be considered even a de facto standard, and
   none are truly interactive.  A need exists to securely transfer files
   using FTP in a secure manner which is supported within the FTP
   protocol in a consistent manner and which takes advantage of existing
   security infrastructure and technology.  Extensions are necessary to
   the FTP specification if these security services are to be introduced
   into the protocol in an interoperable way.







Horowitz & Lunt             Standards Track                     [Page 2]

RFC 2228                FTP Security Extensions             October 1997


   Although the FTP control connection follows the Telnet protocol, and
   Telnet has defined an authentication and encryption option [TELNET-
   SEC], [RFC-1123] explicitly forbids the use of Telnet option
   negotiation over the control connection (other than Synch and IP).

   Also, the Telnet authentication and encryption option does not
   provide for integrity protection only (without confidentiality), and
   does not address the protection of the data channel.

2.  FTP Security Overview

   At the highest level, the FTP security extensions seek to provide an
   abstract mechanism for authenticating and/or authorizing connections,
   and integrity and/or confidentiality protecting commands, replies,
   and data transfers.

   In the context of FTP security, authentication is the establishment
   of a client's identity and/or a server's identity in a secure way,
   usually using cryptographic techniques.  The basic FTP protocol does
   not have a concept of authentication.

   Authorization is the process of validating a user for login.  The
   basic authorization process involves the USER, PASS, and ACCT
   commands.  With the FTP security extensions, authentication
   established using a security mechanism may also be used to make the
   authorization decision.

   Without the security extensions, authentication of the client, as
   this term is usually understood, never happens.  FTP authorization is
   accomplished with a password, passed on the network in the clear as
   the argument to the PASS command.  The possessor of this password is
   assumed to be authorized to transfer files as the user named in the
   USER command, but the identity of the client is never securely
   established.

   An FTP security interaction begins with a client telling the server
   what security mechanism it wants to use with the AUTH command.  The
   server will either accept this mechanism, reject this mechanism, or,
   in the case of a server which does not implement the security
   extensions, reject the command completely.  The client may try
   multiple security mechanisms until it requests one which the server
   accepts.  This allows a rudimentary form of negotiation to take
   place.  (If more complex negotiation is desired, this may be
   implemented as a security mechanism.)  The server's reply will
   indicate if the client must respond with additional data for the






Horowitz & Lunt             Standards Track                     [Page 3]

RFC 2228                FTP Security Extensions             October 1997


   security mechanism to interpret.  If none is needed, this will
   usually mean that the mechanism is one where the password (specified
   by the PASS command) is to be interpreted differently, such as with a
   token or one-time password system.

   If the server requires additional security information, then the
   client and server will enter into a security data exchange.  The
   client will send an ADAT command containing the first block of
   security data.  The server's reply will indicate if the data exchange
   is complete, if there was an error, or if more data is needed.  The
   server's reply can optionally contain security data for the client to
   interpret.  If more data is needed, the client will send another ADAT
   command containing the next block of data, and await the server's
   reply.  This exchange can continue as many times as necessary.  Once
   this exchange completes, the client and server have established a
   security association.  This security association may include
   authentication (client, server, or mutual) and keying information for
   integrity and/or confidentiality, depending on the mechanism in use.

   The term "security data" here is carefully chosen.  The purpose of
   the security data exchange is to establish a security association,
   which might not actually include any authentication at all, between
   the client and the server as described above.  For instance, a
   Diffie-Hellman exchange establishes a secret key, but no
   authentication takes place.  If an FTP server has an RSA key pair but
   the client does not, then the client can authenticate the server, but
   the server cannot authenticate the client.

   Once a security association is established, authentication which is a
   part of this association may be used instead of or in addition to the
   standard username/password exchange for authorizing a user to connect
   to the server.  A username specified by the USER command is always
   required to specify the identity to be used on the server.

   In order to prevent an attacker from inserting or deleting commands
   on the control stream, if the security association supports
   integrity, then the server and client must use integrity protection
   on the control stream, unless it first transmits a CCC command to
   turn off this requirement.  Integrity protection is performed with
   the MIC and ENC commands, and the 63z reply codes.  The CCC command
   and its reply must be transmitted with integrity protection.
   Commands and replies may be transmitted without integrity (that is,
   in the clear or with confidentiality only) only if no security
   association is established, the negotiated security association does
   not support integrity, or the CCC command has succeeded.






Horowitz & Lunt             Standards Track                     [Page 4]

RFC 2228                FTP Security Extensions             October 1997


   Once the client and server have negotiated with the PBSZ command an
   acceptable buffer size for encapsulating protected data over the data
   channel, the security mechanism may also be used to protect data
   channel transfers.

   Policy is not specified by this document.  In particular, client and
   server implementations may choose to implement restrictions on what
   operations can be performed depending on the security association
   which exists.  For example, a server may require that a client
   authorize via a security mechanism rather than using a password,
   require that the client provide a one-time password from a token,
   require at least integrity protection on the command channel, or
   require that certain files only be transmitted encrypted.  An
   anonymous ftp client might refuse to do file transfers without
   integrity protection in order to insure the validity of files
   downloaded.

   No particular set of functionality is required, except as
   dependencies described in the next section.  This means that none of
   authentication, integrity, or confidentiality are required of an
   implementation, although a mechanism which does none of these is not
   of much use.  For example, it is acceptable for a mechanism to
   implement only integrity protection, one-way authentication and/or
   encryption, encryption without any authentication or integrity
   protection, or any other subset of functionality if policy or
   technical considerations make this desirable.  Of course, one peer
   might require as a matter of policy stronger protection than the
   other is able to provide, preventing perfect interoperability.

3.  New FTP Commands

   The following commands are optional, but dependent on each other.
   They are extensions to the FTP Access Control Commands.

   The reply codes documented here are generally described as
   recommended, rather than required.  The intent is that reply codes
   describing the full range of success and failure modes exist, but
   that servers be allowed to limit information presented to the client.
   For example, a server might implement a particular security
   mechanism, but have a policy restriction against using it.  The
   server should respond with a 534 reply code in this case, but may
   respond with a 504 reply code if it does not wish to divulge that the
   disallowed mechanism is supported.  If the server does choose to use
   a different reply code than the recommended one, it should try to use
   a reply code which only differs in the last digit.  In all cases, the
   server must use a reply code which is documented as returnable from
   the command received, and this reply code must begin with the same
   digit as the recommended reply code for the situation.



Horowitz & Lunt             Standards Track                     [Page 5]

RFC 2228                FTP Security Extensions             October 1997


   AUTHENTICATION/SECURITY MECHANISM (AUTH)

      The argument field is a Telnet string identifying a supported
      mechanism.  This string is case-insensitive.  Values must be
      registered with the IANA, except that values beginning with "X-"
      are reserved for local use.

      If the server does not recognize the AUTH command, it must respond
      with reply code 500.  This is intended to encompass the large
      deployed base of non-security-aware ftp servers, which will
      respond with reply code 500 to any unrecognized command.  If the
      server does recognize the AUTH command but does not implement the
      security extensions, it should respond with reply code 502.

      If the server does not understand the named security mechanism, it
      should respond with reply code 504.

      If the server is not willing to accept the named security
      mechanism, it should respond with reply code 534.

      If the server is not able to accept the named security mechanism,
      such as if a required resource is unavailable, it should respond
      with reply code 431.

      If the server is willing to accept the named security mechanism,
      but requires security data, it must respond with reply code 334.

      If the server is willing to accept the named security mechanism,
      and does not require any security data, it must respond with reply
      code 234.

      If the server is responding with a 334 reply code, it may include
      security data as described in the next section.

      Some servers will allow the AUTH command to be reissued in order
      to establish new authentication.  The AUTH command, if accepted,
      removes any state associated with prior FTP Security commands.
      The server must also require that the user reauthorize (that is,
      reissue some or all of the USER, PASS, and ACCT commands) in this
      case (see section 4 for an explanation of "authorize" in this
      context).










Horowitz & Lunt             Standards Track                     [Page 6]

RFC 2228                FTP Security Extensions             October 1997


   AUTHENTICATION/SECURITY DATA (ADAT)

      The argument field is a Telnet string representing base 64 encoded
      security data (see Section 9, "Base 64 Encoding").  If a reply
      code indicating success is returned, the server may also use a
      string of the form "ADAT=base64data" as the text part of the reply
      if it wishes to convey security data back to the client.

      The data in both cases is specific to the security mechanism
      specified by the previous AUTH command.  The ADAT command, and the
      associated replies, allow the client and server to conduct an
      arbitrary security protocol.  The security data exchange must
      include enough information for both peers to be aware of which
      optional features are available.  For example, if the client does
      not support data encryption, the server must be made aware of
      this, so it will know not to send encrypted command channel
      replies.  It is strongly recommended that the security mechanism
      provide sequencing on the command channel, to insure that commands
      are not deleted, reordered, or replayed.

      The ADAT command must be preceded by a successful AUTH command,
      and cannot be issued once a security data exchange completes
      (successfully or unsuccessfully), unless it is preceded by an AUTH
      command to reset the security state.

      If the server has not yet received an AUTH command, or if a prior
      security data exchange completed, but the security state has not
      been reset with an AUTH command, it should respond with reply code
      503.

      If the server cannot base 64 decode the argument, it should
      respond with reply code 501.

      If the server rejects the security data (if a checksum fails, for
      instance), it should respond with reply code 535.

      If the server accepts the security data, and requires additional
      data, it should respond with reply code 335.

      If the server accepts the security data, but does not require any
      additional data (i.e., the security data exchange has completed
      successfully), it must respond with reply code 235.

      If the server is responding with a 235 or 335 reply code, then it
      may include security data in the text part of the reply as
      specified above.





Horowitz & Lunt             Standards Track                     [Page 7]

RFC 2228                FTP Security Extensions             October 1997


      If the ADAT command returns an error, the security data exchange
      will fail, and the client must reset its internal security state.
      If the client becomes unsynchronized with the server (for example,
      the server sends a 234 reply code to an AUTH command, but the
      client has more data to transmit), then the client must reset the
      server's security state.

   PROTECTION BUFFER SIZE (PBSZ)

      The argument is a decimal integer representing the maximum size,
      in bytes, of the encoded data blocks to be sent or received during
      file transfer.  This number shall be no greater than can be
      represented in a 32-bit unsigned integer.

      This command allows the FTP client and server to negotiate a
      maximum protected buffer size for the connection.  There is no
      default size; the client must issue a PBSZ command before it can
      issue the first PROT command.

      The PBSZ command must be preceded by a successful security data
      exchange.

      If the server cannot parse the argument, or if it will not fit in
      32 bits, it should respond with a 501 reply code.

      If the server has not completed a security data exchange with the
      client, it should respond with a 503 reply code.

      Otherwise, the server must reply with a 200 reply code.  If the
      size provided by the client is too large for the server, it must
      use a string of the form "PBSZ=number" in the text part of the
      reply to indicate a smaller buffer size.  The client and the
      server must use the smaller of the two buffer sizes if both buffer
      sizes are specified.

   DATA CHANNEL PROTECTION LEVEL (PROT)

      The argument is a single Telnet character code specifying the data
      channel protection level.

      This command indicates to the server what type of data channel
      protection the client and server will be using.  The following
      codes are assigned:

         C - Clear
         S - Safe
         E - Confidential
         P - Private



Horowitz & Lunt             Standards Track                     [Page 8]

RFC 2228                FTP Security Extensions             October 1997


      The default protection level if no other level is specified is
      Clear.  The Clear protection level indicates that the data channel
      will carry the raw data of the file transfer, with no security
      applied.  The Safe protection level indicates that the data will
      be integrity protected.  The Confidential protection level
      indicates that the data will be confidentiality protected.  The
      Private protection level indicates that the data will be integrity
      and confidentiality protected.

      It is reasonable for a security mechanism not to provide all data
      channel protection levels.  It is also reasonable for a mechanism
      to provide more protection at a level than is required (for
      instance, a mechanism might provide Confidential protection, but
      include integrity-protection in that encoding, due to API or other
      considerations).

      The PROT command must be preceded by a successful protection
      buffer size negotiation.

      If the server does not understand the specified protection level,
      it should respond with reply code 504.

      If the current security mechanism does not support the specified
      protection level, the server should respond with reply code 536.

      If the server has not completed a protection buffer size
      negotiation with the client, it should respond with a 503 reply
      code.

      The PROT command will be rejected and the server should reply 503
      if no previous PBSZ command was issued.

      If the server is not willing to accept the specified protection
      level, it should respond with reply code 534.

      If the server is not able to accept the specified protection
      level, such as if a required resource is unavailable, it should
      respond with reply code 431.

      Otherwise, the server must reply with a 200 reply code to indicate
      that the specified protection level is accepted.

   CLEAR COMMAND CHANNEL (CCC)

      This command does not take an argument.






Horowitz & Lunt             Standards Track                     [Page 9]

RFC 2228                FTP Security Extensions             October 1997


      It is desirable in some environments to use a security mechanism
      to authenticate and/or authorize the client and server, but not to
      perform any integrity checking on the subsequent commands.  This
      might be used in an environment where IP security is in place,
      insuring that the hosts are authenticated and that TCP streams
      cannot be tampered, but where user authentication is desired.

      If unprotected commands are allowed on any connection, then an
      attacker could insert a command on the control stream, and the
      server would have no way to know that it was invalid.  In order to
      prevent such attacks, once a security data exchange completes
      successfully, if the security mechanism supports integrity, then
      integrity (via the MIC or ENC command, and 631 or 632 reply) must
      be used, until the CCC command is issued to enable non-integrity
      protected control channel messages.  The CCC command itself must
      be integrity protected.

      Once the CCC command completes successfully, if a command is not
      protected, then the reply to that command must also not be
      protected.  This is to support interoperability with clients which
      do not support protection once the CCC command has been issued.

      This command must be preceded by a successful security data
      exchange.

      If the command is not integrity-protected, the server must respond
      with a 533 reply code.

      If the server is not willing to turn off the integrity
      requirement, it should respond with a 534 reply code.

      Otherwise, the server must reply with a 200 reply code to indicate
      that unprotected commands and replies may now be used on the
      command channel.

   INTEGRITY PROTECTED COMMAND (MIC) and
   CONFIDENTIALITY PROTECTED COMMAND (CONF) and
   PRIVACY PROTECTED COMMAND (ENC)

      The argument field of MIC is a Telnet string consisting of a base
      64 encoded "safe" message produced by a security mechanism
      specific message integrity procedure.  The argument field of CONF
      is a Telnet string consisting of a base 64 encoded "confidential"
      message produced by a security mechanism specific confidentiality
      procedure.  The argument field of ENC is a Telnet string
      consisting of a base 64 encoded "private" message produced by a
      security mechanism specific message integrity and confidentiality
      procedure.



Horowitz & Lunt             Standards Track                    [Page 10]

RFC 2228                FTP Security Extensions             October 1997


      The server will decode and/or verify the encoded message.

      This command must be preceded by a successful security data
      exchange.

      A server may require that the first command after a successful
      security data exchange be CCC, and not implement the protection
      commands at all.  In this case, the server should respond with a
      502 reply code.

      If the server cannot base 64 decode the argument, it should
      respond with a 501 reply code.

      If the server has not completed a security data exchange with the
      client, it should respond with a 503 reply code.

      If the server has completed a security data exchange with the
      client using a mechanism which supports integrity, and requires a
      CCC command due to policy or implementation limitations, it should
      respond with a 503 reply code.

      If the server rejects the command because it is not supported by
      the current security mechanism, the server should respond with
      reply code 537.

      If the server rejects the command (if a checksum fails, for
      instance), it should respond with reply code 535.

      If the server is not willing to accept the command (if privacy is
      required by policy, for instance, or if a CONF command is received
      before a CCC command), it should respond with reply code 533.

      Otherwise, the command will be interpreted as an FTP command.  An
      end-of-line code need not be included, but if one is included, it
      must be a Telnet end-of-line code, not a local end-of-line code.

      The server may require that, under some or all circumstances, all
      commands be protected.  In this case, it should make a 533 reply
      to commands other than MIC, CONF, and ENC.

4.  Login Authorization

   The security data exchange may, among other things, establish the
   identity of the client in a secure way to the server.  This identity
   may be used as one input to the login authorization process.






Horowitz & Lunt             Standards Track                    [Page 11]

RFC 2228                FTP Security Extensions             October 1997


   In response to the FTP login commands (AUTH, PASS, ACCT), the server
   may choose to change the sequence of commands and replies specified
   by RFC 959 as follows.  There are also some new replies available.

   If the server is willing to allow the user named by the USER command
   to log in based on the identity established by the security data
   exchange, it should respond with reply code 232.

   If the security mechanism requires a challenge/response password, it
   should respond to the USER command with reply code 336.  The text
   part of the reply should contain the challenge.  The client must
   display the challenge to the user before prompting for the password
   in this case.  This is particularly relevant to more sophisticated
   clients or graphical user interfaces which provide dialog boxes or
   other modal input.  These clients should be careful not to prompt for
   the password before the username has been sent to the server, in case
   the user needs the challenge in the 336 reply to construct a valid
   password.

5.  New FTP Replies

   The new reply codes are divided into two classes.  The first class is
   new replies made necessary by the new FTP Security commands.  The
   second class is a new reply type to indicate protected replies.

   5.1.  New individual reply codes

      232 User logged in, authorized by security data exchange.
      234 Security data exchange complete.
      235 [ADAT=base64data]
            ; This reply indicates that the security data exchange
            ; completed successfully.  The square brackets are not
            ; to be included in the reply, but indicate that
            ; security data in the reply is optional.

      334 [ADAT=base64data]
            ; This reply indicates that the requested security mechanism
            ; is ok, and includes security data to be used by the client
            ; to construct the next command.  The square brackets are not
            ; to be included in the reply, but indicate that
            ; security data in the reply is optional.
      335 [ADAT=base64data]
            ; This reply indicates that the security data is
            ; acceptable, and more is required to complete the
            ; security data exchange.  The square brackets
            ; are not to be included in the reply, but indicate
            ; that security data in the reply is optional.




Horowitz & Lunt             Standards Track                    [Page 12]

RFC 2228                FTP Security Extensions             October 1997


      336 Username okay, need password.  Challenge is "...."
            ; The exact representation of the challenge should be chosen
            ; by the mechanism to be sensible to the human user of the
            ; system.

      431 Need some unavailable resource to process security.

      533 Command protection level denied for policy reasons.
      534 Request denied for policy reasons.
      535 Failed security check (hash, sequence, etc).
      536 Requested PROT level not supported by mechanism.
      537 Command protection level not supported by security mechanism.

   5.2.  Protected replies.

      One new reply type is introduced:

         6yz   Protected reply

            There are three reply codes of this type.  The first, reply
            code 631 indicates an integrity protected reply.  The
            second, reply code 632, indicates a confidentiality and
            integrity protected reply.  the third, reply code 633,
            indicates a confidentiality protected reply.

            The text part of a 631 reply is a Telnet string consisting
            of a base 64 encoded "safe" message produced by a security
            mechanism specific message integrity procedure.  The text
            part of a 632 reply is a Telnet string consisting of a base
            64 encoded "private" message produced by a security
            mechanism specific message confidentiality and integrity
            procedure.  The text part of a 633 reply is a Telnet string
            consisting of a base 64 encoded "confidential" message
            produced by a security mechanism specific message
            confidentiality procedure.

            The client will decode and verify the encoded reply.  How
            failures decoding or verifying replies are handled is
            implementation-specific.  An end-of-line code need not be
            included, but if one is included, it must be a Telnet end-
            of-line code, not a local end-of-line code.

            A protected reply may only be sent if a security data
            exchange has succeeded.

            The 63z reply may be a multiline reply.  In this case, the
            plaintext reply must be broken up into a number of
            fragments.  Each fragment must be protected, then base 64



Horowitz & Lunt             Standards Track                    [Page 13]

RFC 2228                FTP Security Extensions             October 1997


            encoded in order into a separate line of the multiline
            reply.  There need not be any correspondence between the
            line breaks in the plaintext reply and the encoded reply.
            Telnet end-of-line codes must appear in the plaintext of the
            encoded reply, except for the final end-of-line code, which
            is optional.

            The multiline reply must be formatted more strictly than the
            continuation specification in RFC 959.  In particular, each
            line before the last must be formed by the reply code,
            followed immediately by a hyphen, followed by a base 64
            encoded fragment of the reply.

            For example, if the plaintext reply is

               123-First line
               Second line
                 234 A line beginning with numbers
               123 The last line

            then the resulting protected reply could be any of the
            following (the first example has a line break only to fit
            within the margins):

  631 base64(protect("123-First line\r\nSecond line\r\n  234 A line
  631-base64(protect("123-First line\r\n"))
  631-base64(protect("Second line\r\n"))
  631-base64(protect("  234 A line beginning with numbers\r\n"))
  631 base64(protect("123 The last line"))

  631-base64(protect("123-First line\r\nSecond line\r\n  234 A line b"))
  631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))

6.  Data Channel Encapsulation

   When data transfers are protected between the client and server (in
   either direction), certain transformations and encapsulations must be
   performed so that the recipient can properly decode the transmitted
   file.

   The sender must apply all protection services after transformations
   associated with the representation type, file structure, and transfer
   mode have been performed.  The data sent over the data channel is,
   for the purposes of protection, to be treated as a byte stream.

   When performing a data transfer in an authenticated manner, the
   authentication checks are performed on individual blocks of the file,
   rather than on the file as a whole. Consequently, it is possible for



Horowitz & Lunt             Standards Track                    [Page 14]

RFC 2228                FTP Security Extensions             October 1997


   insertion attacks to insert blocks into the data stream (i.e.,
   replays) that authenticate correctly, but result in a corrupted file
   being undetected by the receiver. To guard against such attacks, the
   specific security mechanism employed should include mechanisms to
   protect against such attacks.  Many GSS-API mechanisms usable with
   the specification in Appendix I, and the Kerberos mechanism in
   Appendix II do so.

   The sender must take the input byte stream, and break it up into
   blocks such that each block, when encoded using a security mechanism
   specific procedure, will be no larger than the buffer size negotiated
   by the client with the PBSZ command.  Each block must be encoded,
   then transmitted with the length of the encoded block prepended as a
   four byte unsigned integer, most significant byte first.

   When the end of the file is reached, the sender must encode a block
   of zero bytes, and send this final block to the recipient before
   closing the data connection.

   The recipient will read the four byte length, read a block of data
   that many bytes long, then decode and verify this block with a
   security mechanism specific procedure.  This must be repeated until a
   block encoding a buffer of zero bytes is received.  This indicates
   the end of the encoded byte stream.

   Any transformations associated with the representation type, file
   structure, and transfer mode are to be performed by the recipient on
   the byte stream resulting from the above process.

   When using block transfer mode, the sender's (cleartext) buffer size
   is independent of the block size.

   The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE
   command if the current protection level is not at the level dictated
   by the server's security requirements for the particular file
   transfer.

   If any data protection services fail at any time during data transfer
   at the server end (including an attempt to send a buffer size greater
   than the negotiated maximum), the server will send a 535 reply to the
   data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE).










Horowitz & Lunt             Standards Track                    [Page 15]

RFC 2228                FTP Security Extensions             October 1997


7.  Potential policy considerations

   While there are no restrictions on client and server policy, there
   are a few recommendations which an implementation should implement.

    - Once a security data exchange takes place, a server should require
      all commands be protected (with integrity and/or confidentiality),
      and it should protect all replies.  Replies should use the same
      level of protection as the command which produced them.  This
      includes replies which indicate failure of the MIC, CONF, and ENC
      commands.  In particular, it is not meaningful to require that
      AUTH and ADAT be protected; it is meaningful and useful to require
      that PROT and PBSZ be protected.  In particular, the use of CCC is
      not recommended, but is defined in the interest of
      interoperability between implementations which might desire such
      functionality.

    - A client should encrypt the PASS command whenever possible.  It is
      reasonable for the server to refuse to accept a non-encrypted PASS
      command if the server knows encryption is available.

    - Although no security commands are required to be implemented, it
      is recommended that an implementation provide all commands which
      can be implemented, given the mechanisms supported and the policy
      considerations of the site (export controls, for instance).

8.  Declarative specifications

   These sections are modelled after sections 5.3 and 5.4 of RFC 959,
   which describe the same information, except for the standard FTP
   commands and replies.

   8.1.  FTP Security commands and arguments

      AUTH <SP> <mechanism-name> <CRLF>
      ADAT <SP> <base64data> <CRLF>
      PROT <SP> <prot-code> <CRLF>
      PBSZ <SP> <decimal-integer> <CRLF>
      MIC <SP> <base64data> <CRLF>
      CONF <SP> <base64data> <CRLF>
      ENC <SP> <base64data> <CRLF>

      <mechanism-name> ::= <string>
      <base64data> ::= <string>
              ; must be formatted as described in section 9
      <prot-code> ::= C | S | E | P
      <decimal-integer> ::= any decimal integer from 1 to (2^32)-1




Horowitz & Lunt             Standards Track                    [Page 16]

RFC 2228                FTP Security Extensions             October 1997


   8.2.  Command-Reply sequences

      Security Association Setup
         AUTH
            234
            334
            502, 504, 534, 431
            500, 501, 421
         ADAT
            235
            335
            503, 501, 535
            500, 501, 421
      Data protection negotiation commands
         PBSZ
            200
            503
            500, 501, 421, 530
         PROT
            200
            504, 536, 503, 534, 431
            500, 501, 421, 530
      Command channel protection commands
         MIC
            535, 533
            500, 501, 421
         CONF
            535, 533
            500, 501, 421
         ENC
            535, 533
            500, 501, 421
      Security-Enhanced login commands (only new replies listed)
         USER
            232
            336
      Data channel commands (only new replies listed)
         STOR
            534, 535
         STOU
            534, 535
         RETR
            534, 535








Horowitz & Lunt             Standards Track                    [Page 17]

RFC 2228                FTP Security Extensions             October 1997


         LIST
            534, 535
         NLST
            534, 535
         APPE
            534, 535

      In addition to these reply codes, any security command can return
      500, 501, 502, 533, or 421.  Any ftp command can return a reply
      code encapsulated in a 631, 632, or 633 reply once a security data
      exchange has completed successfully.








































Horowitz & Lunt             Standards Track                    [Page 18]

RFC 2228                FTP Security Extensions             October 1997


9.  State Diagrams

   This section includes a state diagram which demonstrates the flow of
   authentication and authorization in a security enhanced FTP
   implementation.  The rectangular blocks show states where the client
   must issue a command, and the diamond blocks show states where the
   server must issue a response.


          ,------------------,  USER
       __\| Unauthenticated  |_________\
      |  /| (new connection) |         /|
      |   `------------------'          |
      |            |                    |
      |            | AUTH               |
      |            V                    |
      |           / \                   |
      | 4yz,5yz  /   \   234            |
      |<--------<     >------------->.  |
      |          \   /               |  |
      |           \_/                |  |
      |            |                 |  |
      |            | 334             |  |
      |            V                 |  |
      |  ,--------------------,      |  |
      |  | Need Security Data |<--.  |  |
      |  `--------------------'   |  |  |
      |            |              |  |  |
      |            | ADAT         |  |  |
      |            V              |  |  |
      |           / \             |  |  |
      | 4yz,5yz  /   \   335      |  |  |
      `<--------<     >-----------'  |  |
                 \   /               |  |
                  \_/                |  |
                   |                 |  |
                   | 235             |  |
                   V                 |  |
           ,---------------.         |  |
      ,--->| Authenticated |<--------'  |  After the client and server
      |    `---------------'            |  have completed authenti-
      |            |                    |  cation, command must be
      |            | USER               |  integrity-protected if
      |            |                    |  integrity is available.  The
      |            |<-------------------'  CCC command may be issued to
      |            V                       relax this restriction.





Horowitz & Lunt             Standards Track                    [Page 19]

RFC 2228                FTP Security Extensions             October 1997


      |           / \
      | 4yz,5yz  /   \   2yz
      |<--------<     >------------->.
      |          \   /               |
      |           \_/                |
      |            |                 |
      |            | 3yz             |
      |            V                 |
      |    ,---------------.         |
      |    | Need Password |         |
      |    `---------------'         |
      |            |                 |
      |            | PASS            |
      |            V                 |
      |           / \                |
      | 4yz,5yz  /   \   2yz         |
      |<--------<     >------------->|
      |          \   /               |
      |           \_/                |
      |            |                 |
      |            | 3yz             |
      |            V                 |
      |    ,--------------.          |
      |    | Need Account |          |
      |    `--------------'          |
      |            |                 |
      |            | ACCT            |
      |            V                 |
      |           / \                |
      | 4yz,5yz  /   \   2yz         |
      `<--------<     >------------->|
                 \   /               |
                  \_/                |
                   |                 |
                   | 3yz             |
                   V                 |
             ,-------------.         |
             | Authorized  |/________|
             | (Logged in) |\
             `-------------'











Horowitz & Lunt             Standards Track                    [Page 20]

RFC 2228                FTP Security Extensions             October 1997


10.  Base 64 Encoding

   Base 64 encoding is the same as the Printable Encoding described in
   Section 4.3.2.4 of [RFC-1421], except that line breaks must not be
   included. This encoding is defined as follows.

   Proceeding from left to right, the bit string resulting from the
   mechanism specific protection routine is encoded into characters
   which are universally representable at all sites, though not
   necessarily with the same bit patterns (e.g., although the character
   "E" is represented in an ASCII-based system as hexadecimal 45 and as
   hexadecimal C5 in an EBCDIC-based system, the local significance of
   the two representations is equivalent).

   A 64-character subset of International Alphabet IA5 is used, enabling
   6 bits to be represented per printable character.  (The proposed
   subset of characters is represented identically in IA5 and ASCII.)
   The character "=" signifies a special processing function used for
   padding within the printable encoding procedure.

   The encoding process represents 24-bit groups of input bits as output
   strings of 4 encoded characters.  Proceeding from left to right
   across a 24-bit input group output from the security mechanism
   specific message protection procedure, each 6-bit group is used as an
   index into an array of 64 printable characters, namely "[A-Z][a-
   z][0-9]+/".  The character referenced by the index is placed in the
   output string.  These characters are selected so as to be universally
   representable, and the set excludes characters with particular
   significance to Telnet (e.g., "<CR>", "<LF>", IAC).

   Special processing is performed if fewer than 24 bits are available
   in an input group at the end of a message.  A full encoding quantum
   is always completed at the end of a message.  When fewer than 24
   input bits are available in an input group, zero bits are added (on
   the right) to form an integral number of 6-bit groups.  Output
   character positions which are not required to represent actual input
   data are set to the character "=".  Since all canonically encoded
   output is an integral number of octets, only the following cases can
   arise: (1) the final quantum of encoding input is an integral
   multiple of 24 bits; here, the final unit of encoded output will be
   an integral multiple of 4 characters with no "=" padding, (2) the
   final quantum of encoding input is exactly 8 bits; here, the final
   unit of encoded output will be two characters followed by two "="
   padding characters, or (3) the final quantum of encoding input is
   exactly 16 bits; here, the final unit of encoded output will be three
   characters followed by one "=" padding character.





Horowitz & Lunt             Standards Track                    [Page 21]

RFC 2228                FTP Security Extensions             October 1997


   Implementors must keep in mind that the base 64 encodings in ADAT,
   MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily
   long.  Thus, the entire line must be read before it can be processed.
   Several successive reads on the control channel may be necessary.  It
   is not appropriate to for a server to reject a command containing a
   base 64 encoding simply because it is too long (assuming that the
   decoding is otherwise well formed in the context in which it was
   sent).

   Case must not be ignored when reading commands and replies containing
   base 64 encodings.

11.  Security Considerations

   This entire document deals with security considerations related to
   the File Transfer Protocol.

   Third party file transfers cannot be secured using these extensions,
   since a security context cannot be established between two servers
   using these facilities (no control connection exists between servers
   over which to pass ADAT tokens).  Further work in this area is
   deferred.

12.  Acknowledgements

   I would like to thank the members of the CAT WG, as well as all
   participants in discussions on the "cat-ietf@mit.edu" mailing list,
   for their contributions to this document.  I would especially like to
   thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut,
   Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Karri Balk
   for their contributions to this work.  Of course, without Steve Lunt,
   the author of the first six revisions of this document, it would not
   exist at all.

13.  References

   [TELNET-SEC] Borman, D., "Telnet Authentication and Encryption
      Option", Work in Progress.

   [RFC-1123] Braden, R., "Requirements for Internet Hosts --
      Application and Support", STD 3, RFC 1123, October 1989.

   [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
      Mail: Part I: Message Encryption and Authentication Procedures",
      RFC 1421, February 1993.






Horowitz & Lunt             Standards Track                    [Page 22]

RFC 2228                FTP Security Extensions             October 1997


14.  Author's Address

   Marc Horowitz
   Cygnus Solutions
   955 Massachusetts Avenue
   Cambridge, MA 02139

   Phone: +1 617 354 7688
   EMail: marc@cygnus.com










































Horowitz & Lunt             Standards Track                    [Page 23]

RFC 2228                FTP Security Extensions             October 1997


Appendix I: Specification under the GSSAPI

   In order to maximise the utility of new security mechanisms, it is
   desirable that new mechanisms be implemented as GSSAPI mechanisms
   rather than as FTP security mechanisms.  This will enable existing
   ftp implementations to support the new mechanisms more easily, since
   little or no code will need to be changed.  In addition, the
   mechanism will be usable by other protocols, such as IMAP, which are
   built on top of the GSSAPI, with no additional specification or
   implementation work needed by the mechanism designers.

   The security mechanism name (for the AUTH command) associated with
   all mechanisms employing the GSSAPI is GSSAPI.  If the server
   supports a security mechanism employing the GSSAPI, it must respond
   with a 334 reply code indicating that an ADAT command is expected
   next.

   The client must begin the authentication exchange by calling
   GSS_Init_Sec_Context, passing in 0 for input_context_handle
   (initially), and a targ_name equal to output_name from
   GSS_Import_Name called with input_name_type of Host-Based Service and
   input_name_string of "ftp@hostname" where "hostname" is the fully
   qualified host name of the server with all letters in lower case.
   (Failing this, the client may try again using input_name_string of
   "host@hostname".) The output_token must then be base 64 encoded and
   sent to the server as the argument to an ADAT command.  If
   GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client
   must expect a token to be returned in the reply to the ADAT command.
   This token must subsequently be passed to another call to
   GSS_Init_Sec_Context.  In this case, if GSS_Init_Sec_Context returns
   no output_token, then the reply code from the server for the previous
   ADAT command must have been 235.  If GSS_Init_Sec_Context returns
   GSS_S_COMPLETE, then no further tokens are expected from the server,
   and the client must consider the server authenticated.

   The server must base 64 decode the argument to the ADAT command and
   pass the resultant token to GSS_Accept_Sec_Context as input_token,
   setting acceptor_cred_handle to NULL (for "use default credentials"),
   and 0 for input_context_handle (initially).  If an output_token is
   returned, it must be base 64 encoded and returned to the client by
   including "ADAT=base64string" in the text of the reply.  If
   GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be
   235, and the server must consider the client authenticated.  If
   GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code
   must be 335.  Otherwise, the reply code should be 535, and the text
   of the reply should contain a descriptive error message.





Horowitz & Lunt             Standards Track                    [Page 24]

RFC 2228                FTP Security Extensions             October 1997


   The chan_bindings input to GSS_Init_Sec_Context and
   GSS_Accept_Sec_Context should use the client internet address and
   server internet address as the initiator and acceptor addresses,
   respectively.  The address type for both should be GSS_C_AF_INET. No
   application data should be specified.

   Since GSSAPI supports anonymous peers to security contexts, it is
   possible that the client's authentication of the server does not
   actually establish an identity.

   The procedure associated with MIC commands, 631 replies, and Safe
   file transfers is:

      GSS_Wrap for the sender, with conf_flag == FALSE

      GSS_Unwrap for the receiver

   The procedure associated with ENC commands, 632 replies, and Private
   file transfers is:

      GSS_Wrap for the sender, with conf_flag == TRUE
      GSS_Unwrap for the receiver

   CONF commands and 633 replies are not supported.

   Both the client and server should inspect the value of conf_avail to
   determine whether the peer supports confidentiality services.

   When the security state is reset (when AUTH is received a second
   time, or when REIN is received), this should be done by calling the
   GSS_Delete_sec_context function.

Appendix II:  Specification under Kerberos version 4

   The security mechanism name (for the AUTH command) associated with
   Kerberos Version 4 is KERBEROS_V4.  If the server supports
   KERBEROS_V4, it must respond with a 334 reply code indicating that an
   ADAT command is expected next.

   The client must retrieve a ticket for the Kerberos principal
   "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name
   of "ftp", an instance equal to the first part of the canonical host
   name of the server with all letters in lower case (as returned by
   krb_get_phost(3)), the server's realm name (as returned by
   krb_realmofhost(3)), and an arbitrary checksum.  The ticket must then
   be base 64 encoded and sent as the argument to an ADAT command.





Horowitz & Lunt             Standards Track                    [Page 25]

RFC 2228                FTP Security Extensions             October 1997


   If the "ftp" principal name is not a registered principal in the
   Kerberos database, then the client may fall back on the "rcmd"
   principal name (same instance and realm).  However, servers must
   accept only one or the other of these principal names, and must not
   be willing to accept either.  Generally, if the server has a key for
   the "ftp" principal in its srvtab, then that principal only must be
   used, otherwise the "rcmd" principal only must be used.

   The server must base 64 decode the argument to the ADAT command and
   pass the result to krb_rd_req(3).  The server must add one to the
   checksum from the authenticator, convert the result to network byte
   order (most significant byte first), and sign it using
   krb_mk_safe(3), and base 64 encode the result.  Upon success, the
   server must reply to the client with a 235 code and include
   "ADAT=base64string" in the text of the reply.  Upon failure, the
   server should reply 535.

   Upon receipt of the 235 reply from the server, the client must parse
   the text of the reply for the base 64 encoded data, decode it,
   convert it from network byte order, and pass the result to
   krb_rd_safe(3).  The client must consider the server authenticated if
   the resultant checksum is equal to one plus the value previously
   sent.

   The procedure associated with MIC commands, 631 replies, and Safe
   file transfers is:

      krb_mk_safe(3) for the sender
      krb_rd_safe(3) for the receiver

   The procedure associated with ENC commands, 632 replies, and Private
   file transfers is:

      krb_mk_priv(3) for the sender
      krb_rd_priv(3) for the receiver

   CONF commands and 633 replies are not supported.

   Note that this specification for KERBEROS_V4 contains no provision
   for negotiating alternate means for integrity and confidentiality
   routines.  Note also that the ADAT exchange does not convey whether
   the peer supports confidentiality services.

   In order to stay within the allowed PBSZ, implementors must take note
   that a cleartext buffer will grow by 31 bytes when processed by
   krb_mk_safe(3) and will grow by 26 bytes when processed by
   krb_mk_priv(3).




Horowitz & Lunt             Standards Track                    [Page 26]

RFC 2228                FTP Security Extensions             October 1997


Full Copyright Statement

   Copyright (C) The Internet Society (1997).  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 implmentation may be prepared, copied, published
   andand 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.
























Horowitz & Lunt             Standards Track                    [Page 27]