7 Network Working Group M. Horowitz
8 Request for Comments: 2228 Cygnus Solutions
10 Category: Standards Track Bellcore
13 FTP Security Extensions
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (1997). All Rights Reserved.
29 This document defines extensions to the FTP specification STD 9, RFC
30 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions
31 provide strong authentication, integrity, and confidentiality on both
32 the control and data channels with the introduction of new optional
33 commands, replies, and file transfer encodings.
35 The following new optional commands are introduced in this
38 AUTH (Authentication/Security Mechanism),
39 ADAT (Authentication/Security Data),
40 PROT (Data Channel Protection Level),
41 PBSZ (Protection Buffer Size),
42 CCC (Clear Command Channel),
43 MIC (Integrity Protected Command),
44 CONF (Confidentiality Protected Command), and
45 ENC (Privacy Protected Command).
47 A new class of reply types (6yz) is also introduced for protected
50 None of the above commands are required to be implemented, but
51 interdependencies exist. These dependencies are documented with the
54 Note that this specification is compatible with STD 9, RFC 959.
58 Horowitz & Lunt Standards Track [Page 1]
60 RFC 2228 FTP Security Extensions October 1997
65 The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959
66 and in place on the Internet uses usernames and passwords passed in
67 cleartext to authenticate clients to servers (via the USER and PASS
68 commands). Except for services such as "anonymous" FTP archives,
69 this represents a security risk whereby passwords can be stolen
70 through monitoring of local and wide-area networks. This either aids
71 potential attackers through password exposure and/or limits
72 accessibility of files by FTP servers who cannot or will not accept
73 the inherent security risks.
75 Aside from the problem of authenticating users in a secure manner,
76 there is also the problem of authenticating servers, protecting
77 sensitive data and/or verifying its integrity. An attacker may be
78 able to access valuable or sensitive data merely by monitoring a
79 network, or through active means may be able to delete or modify the
80 data being transferred so as to corrupt its integrity. An active
81 attacker may also initiate spurious file transfers to and from a site
82 of the attacker's choice, and may invoke other commands on the
83 server. FTP does not currently have any provision for the encryption
84 or verification of the authenticity of commands, replies, or
85 transferred data. Note that these security services have value even
86 to anonymous file access.
88 Current practice for sending files securely is generally either:
90 1. via FTP of files pre-encrypted under keys which are manually
93 2. via electronic mail containing an encoding of a file encrypted
94 under keys which are manually distributed,
96 3. via a PEM message, or
98 4. via the rcp command enhanced to use Kerberos.
100 None of these means could be considered even a de facto standard, and
101 none are truly interactive. A need exists to securely transfer files
102 using FTP in a secure manner which is supported within the FTP
103 protocol in a consistent manner and which takes advantage of existing
104 security infrastructure and technology. Extensions are necessary to
105 the FTP specification if these security services are to be introduced
106 into the protocol in an interoperable way.
114 Horowitz & Lunt Standards Track [Page 2]
116 RFC 2228 FTP Security Extensions October 1997
119 Although the FTP control connection follows the Telnet protocol, and
120 Telnet has defined an authentication and encryption option [TELNET-
121 SEC], [RFC-1123] explicitly forbids the use of Telnet option
122 negotiation over the control connection (other than Synch and IP).
124 Also, the Telnet authentication and encryption option does not
125 provide for integrity protection only (without confidentiality), and
126 does not address the protection of the data channel.
128 2. FTP Security Overview
130 At the highest level, the FTP security extensions seek to provide an
131 abstract mechanism for authenticating and/or authorizing connections,
132 and integrity and/or confidentiality protecting commands, replies,
135 In the context of FTP security, authentication is the establishment
136 of a client's identity and/or a server's identity in a secure way,
137 usually using cryptographic techniques. The basic FTP protocol does
138 not have a concept of authentication.
140 Authorization is the process of validating a user for login. The
141 basic authorization process involves the USER, PASS, and ACCT
142 commands. With the FTP security extensions, authentication
143 established using a security mechanism may also be used to make the
144 authorization decision.
146 Without the security extensions, authentication of the client, as
147 this term is usually understood, never happens. FTP authorization is
148 accomplished with a password, passed on the network in the clear as
149 the argument to the PASS command. The possessor of this password is
150 assumed to be authorized to transfer files as the user named in the
151 USER command, but the identity of the client is never securely
154 An FTP security interaction begins with a client telling the server
155 what security mechanism it wants to use with the AUTH command. The
156 server will either accept this mechanism, reject this mechanism, or,
157 in the case of a server which does not implement the security
158 extensions, reject the command completely. The client may try
159 multiple security mechanisms until it requests one which the server
160 accepts. This allows a rudimentary form of negotiation to take
161 place. (If more complex negotiation is desired, this may be
162 implemented as a security mechanism.) The server's reply will
163 indicate if the client must respond with additional data for the
170 Horowitz & Lunt Standards Track [Page 3]
172 RFC 2228 FTP Security Extensions October 1997
175 security mechanism to interpret. If none is needed, this will
176 usually mean that the mechanism is one where the password (specified
177 by the PASS command) is to be interpreted differently, such as with a
178 token or one-time password system.
180 If the server requires additional security information, then the
181 client and server will enter into a security data exchange. The
182 client will send an ADAT command containing the first block of
183 security data. The server's reply will indicate if the data exchange
184 is complete, if there was an error, or if more data is needed. The
185 server's reply can optionally contain security data for the client to
186 interpret. If more data is needed, the client will send another ADAT
187 command containing the next block of data, and await the server's
188 reply. This exchange can continue as many times as necessary. Once
189 this exchange completes, the client and server have established a
190 security association. This security association may include
191 authentication (client, server, or mutual) and keying information for
192 integrity and/or confidentiality, depending on the mechanism in use.
194 The term "security data" here is carefully chosen. The purpose of
195 the security data exchange is to establish a security association,
196 which might not actually include any authentication at all, between
197 the client and the server as described above. For instance, a
198 Diffie-Hellman exchange establishes a secret key, but no
199 authentication takes place. If an FTP server has an RSA key pair but
200 the client does not, then the client can authenticate the server, but
201 the server cannot authenticate the client.
203 Once a security association is established, authentication which is a
204 part of this association may be used instead of or in addition to the
205 standard username/password exchange for authorizing a user to connect
206 to the server. A username specified by the USER command is always
207 required to specify the identity to be used on the server.
209 In order to prevent an attacker from inserting or deleting commands
210 on the control stream, if the security association supports
211 integrity, then the server and client must use integrity protection
212 on the control stream, unless it first transmits a CCC command to
213 turn off this requirement. Integrity protection is performed with
214 the MIC and ENC commands, and the 63z reply codes. The CCC command
215 and its reply must be transmitted with integrity protection.
216 Commands and replies may be transmitted without integrity (that is,
217 in the clear or with confidentiality only) only if no security
218 association is established, the negotiated security association does
219 not support integrity, or the CCC command has succeeded.
226 Horowitz & Lunt Standards Track [Page 4]
228 RFC 2228 FTP Security Extensions October 1997
231 Once the client and server have negotiated with the PBSZ command an
232 acceptable buffer size for encapsulating protected data over the data
233 channel, the security mechanism may also be used to protect data
236 Policy is not specified by this document. In particular, client and
237 server implementations may choose to implement restrictions on what
238 operations can be performed depending on the security association
239 which exists. For example, a server may require that a client
240 authorize via a security mechanism rather than using a password,
241 require that the client provide a one-time password from a token,
242 require at least integrity protection on the command channel, or
243 require that certain files only be transmitted encrypted. An
244 anonymous ftp client might refuse to do file transfers without
245 integrity protection in order to insure the validity of files
248 No particular set of functionality is required, except as
249 dependencies described in the next section. This means that none of
250 authentication, integrity, or confidentiality are required of an
251 implementation, although a mechanism which does none of these is not
252 of much use. For example, it is acceptable for a mechanism to
253 implement only integrity protection, one-way authentication and/or
254 encryption, encryption without any authentication or integrity
255 protection, or any other subset of functionality if policy or
256 technical considerations make this desirable. Of course, one peer
257 might require as a matter of policy stronger protection than the
258 other is able to provide, preventing perfect interoperability.
262 The following commands are optional, but dependent on each other.
263 They are extensions to the FTP Access Control Commands.
265 The reply codes documented here are generally described as
266 recommended, rather than required. The intent is that reply codes
267 describing the full range of success and failure modes exist, but
268 that servers be allowed to limit information presented to the client.
269 For example, a server might implement a particular security
270 mechanism, but have a policy restriction against using it. The
271 server should respond with a 534 reply code in this case, but may
272 respond with a 504 reply code if it does not wish to divulge that the
273 disallowed mechanism is supported. If the server does choose to use
274 a different reply code than the recommended one, it should try to use
275 a reply code which only differs in the last digit. In all cases, the
276 server must use a reply code which is documented as returnable from
277 the command received, and this reply code must begin with the same
278 digit as the recommended reply code for the situation.
282 Horowitz & Lunt Standards Track [Page 5]
284 RFC 2228 FTP Security Extensions October 1997
287 AUTHENTICATION/SECURITY MECHANISM (AUTH)
289 The argument field is a Telnet string identifying a supported
290 mechanism. This string is case-insensitive. Values must be
291 registered with the IANA, except that values beginning with "X-"
292 are reserved for local use.
294 If the server does not recognize the AUTH command, it must respond
295 with reply code 500. This is intended to encompass the large
296 deployed base of non-security-aware ftp servers, which will
297 respond with reply code 500 to any unrecognized command. If the
298 server does recognize the AUTH command but does not implement the
299 security extensions, it should respond with reply code 502.
301 If the server does not understand the named security mechanism, it
302 should respond with reply code 504.
304 If the server is not willing to accept the named security
305 mechanism, it should respond with reply code 534.
307 If the server is not able to accept the named security mechanism,
308 such as if a required resource is unavailable, it should respond
311 If the server is willing to accept the named security mechanism,
312 but requires security data, it must respond with reply code 334.
314 If the server is willing to accept the named security mechanism,
315 and does not require any security data, it must respond with reply
318 If the server is responding with a 334 reply code, it may include
319 security data as described in the next section.
321 Some servers will allow the AUTH command to be reissued in order
322 to establish new authentication. The AUTH command, if accepted,
323 removes any state associated with prior FTP Security commands.
324 The server must also require that the user reauthorize (that is,
325 reissue some or all of the USER, PASS, and ACCT commands) in this
326 case (see section 4 for an explanation of "authorize" in this
338 Horowitz & Lunt Standards Track [Page 6]
340 RFC 2228 FTP Security Extensions October 1997
343 AUTHENTICATION/SECURITY DATA (ADAT)
345 The argument field is a Telnet string representing base 64 encoded
346 security data (see Section 9, "Base 64 Encoding"). If a reply
347 code indicating success is returned, the server may also use a
348 string of the form "ADAT=base64data" as the text part of the reply
349 if it wishes to convey security data back to the client.
351 The data in both cases is specific to the security mechanism
352 specified by the previous AUTH command. The ADAT command, and the
353 associated replies, allow the client and server to conduct an
354 arbitrary security protocol. The security data exchange must
355 include enough information for both peers to be aware of which
356 optional features are available. For example, if the client does
357 not support data encryption, the server must be made aware of
358 this, so it will know not to send encrypted command channel
359 replies. It is strongly recommended that the security mechanism
360 provide sequencing on the command channel, to insure that commands
361 are not deleted, reordered, or replayed.
363 The ADAT command must be preceded by a successful AUTH command,
364 and cannot be issued once a security data exchange completes
365 (successfully or unsuccessfully), unless it is preceded by an AUTH
366 command to reset the security state.
368 If the server has not yet received an AUTH command, or if a prior
369 security data exchange completed, but the security state has not
370 been reset with an AUTH command, it should respond with reply code
373 If the server cannot base 64 decode the argument, it should
374 respond with reply code 501.
376 If the server rejects the security data (if a checksum fails, for
377 instance), it should respond with reply code 535.
379 If the server accepts the security data, and requires additional
380 data, it should respond with reply code 335.
382 If the server accepts the security data, but does not require any
383 additional data (i.e., the security data exchange has completed
384 successfully), it must respond with reply code 235.
386 If the server is responding with a 235 or 335 reply code, then it
387 may include security data in the text part of the reply as
394 Horowitz & Lunt Standards Track [Page 7]
396 RFC 2228 FTP Security Extensions October 1997
399 If the ADAT command returns an error, the security data exchange
400 will fail, and the client must reset its internal security state.
401 If the client becomes unsynchronized with the server (for example,
402 the server sends a 234 reply code to an AUTH command, but the
403 client has more data to transmit), then the client must reset the
404 server's security state.
406 PROTECTION BUFFER SIZE (PBSZ)
408 The argument is a decimal integer representing the maximum size,
409 in bytes, of the encoded data blocks to be sent or received during
410 file transfer. This number shall be no greater than can be
411 represented in a 32-bit unsigned integer.
413 This command allows the FTP client and server to negotiate a
414 maximum protected buffer size for the connection. There is no
415 default size; the client must issue a PBSZ command before it can
416 issue the first PROT command.
418 The PBSZ command must be preceded by a successful security data
421 If the server cannot parse the argument, or if it will not fit in
422 32 bits, it should respond with a 501 reply code.
424 If the server has not completed a security data exchange with the
425 client, it should respond with a 503 reply code.
427 Otherwise, the server must reply with a 200 reply code. If the
428 size provided by the client is too large for the server, it must
429 use a string of the form "PBSZ=number" in the text part of the
430 reply to indicate a smaller buffer size. The client and the
431 server must use the smaller of the two buffer sizes if both buffer
434 DATA CHANNEL PROTECTION LEVEL (PROT)
436 The argument is a single Telnet character code specifying the data
437 channel protection level.
439 This command indicates to the server what type of data channel
440 protection the client and server will be using. The following
450 Horowitz & Lunt Standards Track [Page 8]
452 RFC 2228 FTP Security Extensions October 1997
455 The default protection level if no other level is specified is
456 Clear. The Clear protection level indicates that the data channel
457 will carry the raw data of the file transfer, with no security
458 applied. The Safe protection level indicates that the data will
459 be integrity protected. The Confidential protection level
460 indicates that the data will be confidentiality protected. The
461 Private protection level indicates that the data will be integrity
462 and confidentiality protected.
464 It is reasonable for a security mechanism not to provide all data
465 channel protection levels. It is also reasonable for a mechanism
466 to provide more protection at a level than is required (for
467 instance, a mechanism might provide Confidential protection, but
468 include integrity-protection in that encoding, due to API or other
471 The PROT command must be preceded by a successful protection
472 buffer size negotiation.
474 If the server does not understand the specified protection level,
475 it should respond with reply code 504.
477 If the current security mechanism does not support the specified
478 protection level, the server should respond with reply code 536.
480 If the server has not completed a protection buffer size
481 negotiation with the client, it should respond with a 503 reply
484 The PROT command will be rejected and the server should reply 503
485 if no previous PBSZ command was issued.
487 If the server is not willing to accept the specified protection
488 level, it should respond with reply code 534.
490 If the server is not able to accept the specified protection
491 level, such as if a required resource is unavailable, it should
492 respond with reply code 431.
494 Otherwise, the server must reply with a 200 reply code to indicate
495 that the specified protection level is accepted.
497 CLEAR COMMAND CHANNEL (CCC)
499 This command does not take an argument.
506 Horowitz & Lunt Standards Track [Page 9]
508 RFC 2228 FTP Security Extensions October 1997
511 It is desirable in some environments to use a security mechanism
512 to authenticate and/or authorize the client and server, but not to
513 perform any integrity checking on the subsequent commands. This
514 might be used in an environment where IP security is in place,
515 insuring that the hosts are authenticated and that TCP streams
516 cannot be tampered, but where user authentication is desired.
518 If unprotected commands are allowed on any connection, then an
519 attacker could insert a command on the control stream, and the
520 server would have no way to know that it was invalid. In order to
521 prevent such attacks, once a security data exchange completes
522 successfully, if the security mechanism supports integrity, then
523 integrity (via the MIC or ENC command, and 631 or 632 reply) must
524 be used, until the CCC command is issued to enable non-integrity
525 protected control channel messages. The CCC command itself must
526 be integrity protected.
528 Once the CCC command completes successfully, if a command is not
529 protected, then the reply to that command must also not be
530 protected. This is to support interoperability with clients which
531 do not support protection once the CCC command has been issued.
533 This command must be preceded by a successful security data
536 If the command is not integrity-protected, the server must respond
537 with a 533 reply code.
539 If the server is not willing to turn off the integrity
540 requirement, it should respond with a 534 reply code.
542 Otherwise, the server must reply with a 200 reply code to indicate
543 that unprotected commands and replies may now be used on the
546 INTEGRITY PROTECTED COMMAND (MIC) and
547 CONFIDENTIALITY PROTECTED COMMAND (CONF) and
548 PRIVACY PROTECTED COMMAND (ENC)
550 The argument field of MIC is a Telnet string consisting of a base
551 64 encoded "safe" message produced by a security mechanism
552 specific message integrity procedure. The argument field of CONF
553 is a Telnet string consisting of a base 64 encoded "confidential"
554 message produced by a security mechanism specific confidentiality
555 procedure. The argument field of ENC is a Telnet string
556 consisting of a base 64 encoded "private" message produced by a
557 security mechanism specific message integrity and confidentiality
562 Horowitz & Lunt Standards Track [Page 10]
564 RFC 2228 FTP Security Extensions October 1997
567 The server will decode and/or verify the encoded message.
569 This command must be preceded by a successful security data
572 A server may require that the first command after a successful
573 security data exchange be CCC, and not implement the protection
574 commands at all. In this case, the server should respond with a
577 If the server cannot base 64 decode the argument, it should
578 respond with a 501 reply code.
580 If the server has not completed a security data exchange with the
581 client, it should respond with a 503 reply code.
583 If the server has completed a security data exchange with the
584 client using a mechanism which supports integrity, and requires a
585 CCC command due to policy or implementation limitations, it should
586 respond with a 503 reply code.
588 If the server rejects the command because it is not supported by
589 the current security mechanism, the server should respond with
592 If the server rejects the command (if a checksum fails, for
593 instance), it should respond with reply code 535.
595 If the server is not willing to accept the command (if privacy is
596 required by policy, for instance, or if a CONF command is received
597 before a CCC command), it should respond with reply code 533.
599 Otherwise, the command will be interpreted as an FTP command. An
600 end-of-line code need not be included, but if one is included, it
601 must be a Telnet end-of-line code, not a local end-of-line code.
603 The server may require that, under some or all circumstances, all
604 commands be protected. In this case, it should make a 533 reply
605 to commands other than MIC, CONF, and ENC.
607 4. Login Authorization
609 The security data exchange may, among other things, establish the
610 identity of the client in a secure way to the server. This identity
611 may be used as one input to the login authorization process.
618 Horowitz & Lunt Standards Track [Page 11]
620 RFC 2228 FTP Security Extensions October 1997
623 In response to the FTP login commands (AUTH, PASS, ACCT), the server
624 may choose to change the sequence of commands and replies specified
625 by RFC 959 as follows. There are also some new replies available.
627 If the server is willing to allow the user named by the USER command
628 to log in based on the identity established by the security data
629 exchange, it should respond with reply code 232.
631 If the security mechanism requires a challenge/response password, it
632 should respond to the USER command with reply code 336. The text
633 part of the reply should contain the challenge. The client must
634 display the challenge to the user before prompting for the password
635 in this case. This is particularly relevant to more sophisticated
636 clients or graphical user interfaces which provide dialog boxes or
637 other modal input. These clients should be careful not to prompt for
638 the password before the username has been sent to the server, in case
639 the user needs the challenge in the 336 reply to construct a valid
644 The new reply codes are divided into two classes. The first class is
645 new replies made necessary by the new FTP Security commands. The
646 second class is a new reply type to indicate protected replies.
648 5.1. New individual reply codes
650 232 User logged in, authorized by security data exchange.
651 234 Security data exchange complete.
652 235 [ADAT=base64data]
653 ; This reply indicates that the security data exchange
654 ; completed successfully. The square brackets are not
655 ; to be included in the reply, but indicate that
656 ; security data in the reply is optional.
658 334 [ADAT=base64data]
659 ; This reply indicates that the requested security mechanism
660 ; is ok, and includes security data to be used by the client
661 ; to construct the next command. The square brackets are not
662 ; to be included in the reply, but indicate that
663 ; security data in the reply is optional.
664 335 [ADAT=base64data]
665 ; This reply indicates that the security data is
666 ; acceptable, and more is required to complete the
667 ; security data exchange. The square brackets
668 ; are not to be included in the reply, but indicate
669 ; that security data in the reply is optional.
674 Horowitz & Lunt Standards Track [Page 12]
676 RFC 2228 FTP Security Extensions October 1997
679 336 Username okay, need password. Challenge is "...."
680 ; The exact representation of the challenge should be chosen
681 ; by the mechanism to be sensible to the human user of the
684 431 Need some unavailable resource to process security.
686 533 Command protection level denied for policy reasons.
687 534 Request denied for policy reasons.
688 535 Failed security check (hash, sequence, etc).
689 536 Requested PROT level not supported by mechanism.
690 537 Command protection level not supported by security mechanism.
692 5.2. Protected replies.
694 One new reply type is introduced:
698 There are three reply codes of this type. The first, reply
699 code 631 indicates an integrity protected reply. The
700 second, reply code 632, indicates a confidentiality and
701 integrity protected reply. the third, reply code 633,
702 indicates a confidentiality protected reply.
704 The text part of a 631 reply is a Telnet string consisting
705 of a base 64 encoded "safe" message produced by a security
706 mechanism specific message integrity procedure. The text
707 part of a 632 reply is a Telnet string consisting of a base
708 64 encoded "private" message produced by a security
709 mechanism specific message confidentiality and integrity
710 procedure. The text part of a 633 reply is a Telnet string
711 consisting of a base 64 encoded "confidential" message
712 produced by a security mechanism specific message
713 confidentiality procedure.
715 The client will decode and verify the encoded reply. How
716 failures decoding or verifying replies are handled is
717 implementation-specific. An end-of-line code need not be
718 included, but if one is included, it must be a Telnet end-
719 of-line code, not a local end-of-line code.
721 A protected reply may only be sent if a security data
722 exchange has succeeded.
724 The 63z reply may be a multiline reply. In this case, the
725 plaintext reply must be broken up into a number of
726 fragments. Each fragment must be protected, then base 64
730 Horowitz & Lunt Standards Track [Page 13]
732 RFC 2228 FTP Security Extensions October 1997
735 encoded in order into a separate line of the multiline
736 reply. There need not be any correspondence between the
737 line breaks in the plaintext reply and the encoded reply.
738 Telnet end-of-line codes must appear in the plaintext of the
739 encoded reply, except for the final end-of-line code, which
742 The multiline reply must be formatted more strictly than the
743 continuation specification in RFC 959. In particular, each
744 line before the last must be formed by the reply code,
745 followed immediately by a hyphen, followed by a base 64
746 encoded fragment of the reply.
748 For example, if the plaintext reply is
752 234 A line beginning with numbers
755 then the resulting protected reply could be any of the
756 following (the first example has a line break only to fit
759 631 base64(protect("123-First line\r\nSecond line\r\n 234 A line
760 631-base64(protect("123-First line\r\n"))
761 631-base64(protect("Second line\r\n"))
762 631-base64(protect(" 234 A line beginning with numbers\r\n"))
763 631 base64(protect("123 The last line"))
765 631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b"))
766 631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
768 6. Data Channel Encapsulation
770 When data transfers are protected between the client and server (in
771 either direction), certain transformations and encapsulations must be
772 performed so that the recipient can properly decode the transmitted
775 The sender must apply all protection services after transformations
776 associated with the representation type, file structure, and transfer
777 mode have been performed. The data sent over the data channel is,
778 for the purposes of protection, to be treated as a byte stream.
780 When performing a data transfer in an authenticated manner, the
781 authentication checks are performed on individual blocks of the file,
782 rather than on the file as a whole. Consequently, it is possible for
786 Horowitz & Lunt Standards Track [Page 14]
788 RFC 2228 FTP Security Extensions October 1997
791 insertion attacks to insert blocks into the data stream (i.e.,
792 replays) that authenticate correctly, but result in a corrupted file
793 being undetected by the receiver. To guard against such attacks, the
794 specific security mechanism employed should include mechanisms to
795 protect against such attacks. Many GSS-API mechanisms usable with
796 the specification in Appendix I, and the Kerberos mechanism in
799 The sender must take the input byte stream, and break it up into
800 blocks such that each block, when encoded using a security mechanism
801 specific procedure, will be no larger than the buffer size negotiated
802 by the client with the PBSZ command. Each block must be encoded,
803 then transmitted with the length of the encoded block prepended as a
804 four byte unsigned integer, most significant byte first.
806 When the end of the file is reached, the sender must encode a block
807 of zero bytes, and send this final block to the recipient before
808 closing the data connection.
810 The recipient will read the four byte length, read a block of data
811 that many bytes long, then decode and verify this block with a
812 security mechanism specific procedure. This must be repeated until a
813 block encoding a buffer of zero bytes is received. This indicates
814 the end of the encoded byte stream.
816 Any transformations associated with the representation type, file
817 structure, and transfer mode are to be performed by the recipient on
818 the byte stream resulting from the above process.
820 When using block transfer mode, the sender's (cleartext) buffer size
821 is independent of the block size.
823 The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE
824 command if the current protection level is not at the level dictated
825 by the server's security requirements for the particular file
828 If any data protection services fail at any time during data transfer
829 at the server end (including an attempt to send a buffer size greater
830 than the negotiated maximum), the server will send a 535 reply to the
831 data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE).
842 Horowitz & Lunt Standards Track [Page 15]
844 RFC 2228 FTP Security Extensions October 1997
847 7. Potential policy considerations
849 While there are no restrictions on client and server policy, there
850 are a few recommendations which an implementation should implement.
852 - Once a security data exchange takes place, a server should require
853 all commands be protected (with integrity and/or confidentiality),
854 and it should protect all replies. Replies should use the same
855 level of protection as the command which produced them. This
856 includes replies which indicate failure of the MIC, CONF, and ENC
857 commands. In particular, it is not meaningful to require that
858 AUTH and ADAT be protected; it is meaningful and useful to require
859 that PROT and PBSZ be protected. In particular, the use of CCC is
860 not recommended, but is defined in the interest of
861 interoperability between implementations which might desire such
864 - A client should encrypt the PASS command whenever possible. It is
865 reasonable for the server to refuse to accept a non-encrypted PASS
866 command if the server knows encryption is available.
868 - Although no security commands are required to be implemented, it
869 is recommended that an implementation provide all commands which
870 can be implemented, given the mechanisms supported and the policy
871 considerations of the site (export controls, for instance).
873 8. Declarative specifications
875 These sections are modelled after sections 5.3 and 5.4 of RFC 959,
876 which describe the same information, except for the standard FTP
877 commands and replies.
879 8.1. FTP Security commands and arguments
881 AUTH <SP> <mechanism-name> <CRLF>
882 ADAT <SP> <base64data> <CRLF>
883 PROT <SP> <prot-code> <CRLF>
884 PBSZ <SP> <decimal-integer> <CRLF>
885 MIC <SP> <base64data> <CRLF>
886 CONF <SP> <base64data> <CRLF>
887 ENC <SP> <base64data> <CRLF>
889 <mechanism-name> ::= <string>
890 <base64data> ::= <string>
891 ; must be formatted as described in section 9
892 <prot-code> ::= C | S | E | P
893 <decimal-integer> ::= any decimal integer from 1 to (2^32)-1
898 Horowitz & Lunt Standards Track [Page 16]
900 RFC 2228 FTP Security Extensions October 1997
903 8.2. Command-Reply sequences
905 Security Association Setup
916 Data protection negotiation commands
923 504, 536, 503, 534, 431
925 Command channel protection commands
935 Security-Enhanced login commands (only new replies listed)
939 Data channel commands (only new replies listed)
954 Horowitz & Lunt Standards Track [Page 17]
956 RFC 2228 FTP Security Extensions October 1997
966 In addition to these reply codes, any security command can return
967 500, 501, 502, 533, or 421. Any ftp command can return a reply
968 code encapsulated in a 631, 632, or 633 reply once a security data
969 exchange has completed successfully.
1010 Horowitz & Lunt Standards Track [Page 18]
1012 RFC 2228 FTP Security Extensions October 1997
1017 This section includes a state diagram which demonstrates the flow of
1018 authentication and authorization in a security enhanced FTP
1019 implementation. The rectangular blocks show states where the client
1020 must issue a command, and the diamond blocks show states where the
1021 server must issue a response.
1024 ,------------------, USER
1025 __\| Unauthenticated |_________\
1026 | /| (new connection) | /|
1027 | `------------------' |
1033 |<--------< >------------->. |
1039 | ,--------------------, | |
1040 | | Need Security Data |<--. | |
1041 | `--------------------' | | |
1046 | 4yz,5yz / \ 335 | | |
1047 `<--------< >-----------' | |
1053 ,---------------. | |
1054 ,--->| Authenticated |<--------' | After the client and server
1055 | `---------------' | have completed authenti-
1056 | | | cation, command must be
1057 | | USER | integrity-protected if
1058 | | | integrity is available. The
1059 | |<-------------------' CCC command may be issued to
1060 | V relax this restriction.
1066 Horowitz & Lunt Standards Track [Page 19]
1068 RFC 2228 FTP Security Extensions October 1997
1073 |<--------< >------------->.
1079 | ,---------------. |
1080 | | Need Password | |
1081 | `---------------' |
1087 |<--------< >------------->|
1093 | ,--------------. |
1094 | | Need Account | |
1095 | `--------------' |
1101 `<--------< >------------->|
1108 | Authorized |/________|
1122 Horowitz & Lunt Standards Track [Page 20]
1124 RFC 2228 FTP Security Extensions October 1997
1127 10. Base 64 Encoding
1129 Base 64 encoding is the same as the Printable Encoding described in
1130 Section 4.3.2.4 of [RFC-1421], except that line breaks must not be
1131 included. This encoding is defined as follows.
1133 Proceeding from left to right, the bit string resulting from the
1134 mechanism specific protection routine is encoded into characters
1135 which are universally representable at all sites, though not
1136 necessarily with the same bit patterns (e.g., although the character
1137 "E" is represented in an ASCII-based system as hexadecimal 45 and as
1138 hexadecimal C5 in an EBCDIC-based system, the local significance of
1139 the two representations is equivalent).
1141 A 64-character subset of International Alphabet IA5 is used, enabling
1142 6 bits to be represented per printable character. (The proposed
1143 subset of characters is represented identically in IA5 and ASCII.)
1144 The character "=" signifies a special processing function used for
1145 padding within the printable encoding procedure.
1147 The encoding process represents 24-bit groups of input bits as output
1148 strings of 4 encoded characters. Proceeding from left to right
1149 across a 24-bit input group output from the security mechanism
1150 specific message protection procedure, each 6-bit group is used as an
1151 index into an array of 64 printable characters, namely "[A-Z][a-
1152 z][0-9]+/". The character referenced by the index is placed in the
1153 output string. These characters are selected so as to be universally
1154 representable, and the set excludes characters with particular
1155 significance to Telnet (e.g., "<CR>", "<LF>", IAC).
1157 Special processing is performed if fewer than 24 bits are available
1158 in an input group at the end of a message. A full encoding quantum
1159 is always completed at the end of a message. When fewer than 24
1160 input bits are available in an input group, zero bits are added (on
1161 the right) to form an integral number of 6-bit groups. Output
1162 character positions which are not required to represent actual input
1163 data are set to the character "=". Since all canonically encoded
1164 output is an integral number of octets, only the following cases can
1165 arise: (1) the final quantum of encoding input is an integral
1166 multiple of 24 bits; here, the final unit of encoded output will be
1167 an integral multiple of 4 characters with no "=" padding, (2) the
1168 final quantum of encoding input is exactly 8 bits; here, the final
1169 unit of encoded output will be two characters followed by two "="
1170 padding characters, or (3) the final quantum of encoding input is
1171 exactly 16 bits; here, the final unit of encoded output will be three
1172 characters followed by one "=" padding character.
1178 Horowitz & Lunt Standards Track [Page 21]
1180 RFC 2228 FTP Security Extensions October 1997
1183 Implementors must keep in mind that the base 64 encodings in ADAT,
1184 MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily
1185 long. Thus, the entire line must be read before it can be processed.
1186 Several successive reads on the control channel may be necessary. It
1187 is not appropriate to for a server to reject a command containing a
1188 base 64 encoding simply because it is too long (assuming that the
1189 decoding is otherwise well formed in the context in which it was
1192 Case must not be ignored when reading commands and replies containing
1195 11. Security Considerations
1197 This entire document deals with security considerations related to
1198 the File Transfer Protocol.
1200 Third party file transfers cannot be secured using these extensions,
1201 since a security context cannot be established between two servers
1202 using these facilities (no control connection exists between servers
1203 over which to pass ADAT tokens). Further work in this area is
1206 12. Acknowledgements
1208 I would like to thank the members of the CAT WG, as well as all
1209 participants in discussions on the "cat-ietf@mit.edu" mailing list,
1210 for their contributions to this document. I would especially like to
1211 thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut,
1212 Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Karri Balk
1213 for their contributions to this work. Of course, without Steve Lunt,
1214 the author of the first six revisions of this document, it would not
1219 [TELNET-SEC] Borman, D., "Telnet Authentication and Encryption
1220 Option", Work in Progress.
1222 [RFC-1123] Braden, R., "Requirements for Internet Hosts --
1223 Application and Support", STD 3, RFC 1123, October 1989.
1225 [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
1226 Mail: Part I: Message Encryption and Authentication Procedures",
1227 RFC 1421, February 1993.
1234 Horowitz & Lunt Standards Track [Page 22]
1236 RFC 2228 FTP Security Extensions October 1997
1239 14. Author's Address
1243 955 Massachusetts Avenue
1246 Phone: +1 617 354 7688
1247 EMail: marc@cygnus.com
1290 Horowitz & Lunt Standards Track [Page 23]
1292 RFC 2228 FTP Security Extensions October 1997
1295 Appendix I: Specification under the GSSAPI
1297 In order to maximise the utility of new security mechanisms, it is
1298 desirable that new mechanisms be implemented as GSSAPI mechanisms
1299 rather than as FTP security mechanisms. This will enable existing
1300 ftp implementations to support the new mechanisms more easily, since
1301 little or no code will need to be changed. In addition, the
1302 mechanism will be usable by other protocols, such as IMAP, which are
1303 built on top of the GSSAPI, with no additional specification or
1304 implementation work needed by the mechanism designers.
1306 The security mechanism name (for the AUTH command) associated with
1307 all mechanisms employing the GSSAPI is GSSAPI. If the server
1308 supports a security mechanism employing the GSSAPI, it must respond
1309 with a 334 reply code indicating that an ADAT command is expected
1312 The client must begin the authentication exchange by calling
1313 GSS_Init_Sec_Context, passing in 0 for input_context_handle
1314 (initially), and a targ_name equal to output_name from
1315 GSS_Import_Name called with input_name_type of Host-Based Service and
1316 input_name_string of "ftp@hostname" where "hostname" is the fully
1317 qualified host name of the server with all letters in lower case.
1318 (Failing this, the client may try again using input_name_string of
1319 "host@hostname".) The output_token must then be base 64 encoded and
1320 sent to the server as the argument to an ADAT command. If
1321 GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client
1322 must expect a token to be returned in the reply to the ADAT command.
1323 This token must subsequently be passed to another call to
1324 GSS_Init_Sec_Context. In this case, if GSS_Init_Sec_Context returns
1325 no output_token, then the reply code from the server for the previous
1326 ADAT command must have been 235. If GSS_Init_Sec_Context returns
1327 GSS_S_COMPLETE, then no further tokens are expected from the server,
1328 and the client must consider the server authenticated.
1330 The server must base 64 decode the argument to the ADAT command and
1331 pass the resultant token to GSS_Accept_Sec_Context as input_token,
1332 setting acceptor_cred_handle to NULL (for "use default credentials"),
1333 and 0 for input_context_handle (initially). If an output_token is
1334 returned, it must be base 64 encoded and returned to the client by
1335 including "ADAT=base64string" in the text of the reply. If
1336 GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be
1337 235, and the server must consider the client authenticated. If
1338 GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code
1339 must be 335. Otherwise, the reply code should be 535, and the text
1340 of the reply should contain a descriptive error message.
1346 Horowitz & Lunt Standards Track [Page 24]
1348 RFC 2228 FTP Security Extensions October 1997
1351 The chan_bindings input to GSS_Init_Sec_Context and
1352 GSS_Accept_Sec_Context should use the client internet address and
1353 server internet address as the initiator and acceptor addresses,
1354 respectively. The address type for both should be GSS_C_AF_INET. No
1355 application data should be specified.
1357 Since GSSAPI supports anonymous peers to security contexts, it is
1358 possible that the client's authentication of the server does not
1359 actually establish an identity.
1361 The procedure associated with MIC commands, 631 replies, and Safe
1364 GSS_Wrap for the sender, with conf_flag == FALSE
1366 GSS_Unwrap for the receiver
1368 The procedure associated with ENC commands, 632 replies, and Private
1371 GSS_Wrap for the sender, with conf_flag == TRUE
1372 GSS_Unwrap for the receiver
1374 CONF commands and 633 replies are not supported.
1376 Both the client and server should inspect the value of conf_avail to
1377 determine whether the peer supports confidentiality services.
1379 When the security state is reset (when AUTH is received a second
1380 time, or when REIN is received), this should be done by calling the
1381 GSS_Delete_sec_context function.
1383 Appendix II: Specification under Kerberos version 4
1385 The security mechanism name (for the AUTH command) associated with
1386 Kerberos Version 4 is KERBEROS_V4. If the server supports
1387 KERBEROS_V4, it must respond with a 334 reply code indicating that an
1388 ADAT command is expected next.
1390 The client must retrieve a ticket for the Kerberos principal
1391 "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name
1392 of "ftp", an instance equal to the first part of the canonical host
1393 name of the server with all letters in lower case (as returned by
1394 krb_get_phost(3)), the server's realm name (as returned by
1395 krb_realmofhost(3)), and an arbitrary checksum. The ticket must then
1396 be base 64 encoded and sent as the argument to an ADAT command.
1402 Horowitz & Lunt Standards Track [Page 25]
1404 RFC 2228 FTP Security Extensions October 1997
1407 If the "ftp" principal name is not a registered principal in the
1408 Kerberos database, then the client may fall back on the "rcmd"
1409 principal name (same instance and realm). However, servers must
1410 accept only one or the other of these principal names, and must not
1411 be willing to accept either. Generally, if the server has a key for
1412 the "ftp" principal in its srvtab, then that principal only must be
1413 used, otherwise the "rcmd" principal only must be used.
1415 The server must base 64 decode the argument to the ADAT command and
1416 pass the result to krb_rd_req(3). The server must add one to the
1417 checksum from the authenticator, convert the result to network byte
1418 order (most significant byte first), and sign it using
1419 krb_mk_safe(3), and base 64 encode the result. Upon success, the
1420 server must reply to the client with a 235 code and include
1421 "ADAT=base64string" in the text of the reply. Upon failure, the
1422 server should reply 535.
1424 Upon receipt of the 235 reply from the server, the client must parse
1425 the text of the reply for the base 64 encoded data, decode it,
1426 convert it from network byte order, and pass the result to
1427 krb_rd_safe(3). The client must consider the server authenticated if
1428 the resultant checksum is equal to one plus the value previously
1431 The procedure associated with MIC commands, 631 replies, and Safe
1434 krb_mk_safe(3) for the sender
1435 krb_rd_safe(3) for the receiver
1437 The procedure associated with ENC commands, 632 replies, and Private
1440 krb_mk_priv(3) for the sender
1441 krb_rd_priv(3) for the receiver
1443 CONF commands and 633 replies are not supported.
1445 Note that this specification for KERBEROS_V4 contains no provision
1446 for negotiating alternate means for integrity and confidentiality
1447 routines. Note also that the ADAT exchange does not convey whether
1448 the peer supports confidentiality services.
1450 In order to stay within the allowed PBSZ, implementors must take note
1451 that a cleartext buffer will grow by 31 bytes when processed by
1452 krb_mk_safe(3) and will grow by 26 bytes when processed by
1458 Horowitz & Lunt Standards Track [Page 26]
1460 RFC 2228 FTP Security Extensions October 1997
1463 Full Copyright Statement
1465 Copyright (C) The Internet Society (1997). All Rights Reserved.
1467 This document and translations of it may be copied and furnished to
1468 others, and derivative works that comment on or otherwise explain it
1469 or assist in its implmentation may be prepared, copied, published
1470 andand distributed, in whole or in part, without restriction of any
1471 kind, provided that the above copyright notice and this paragraph are
1472 included on all such copies and derivative works. However, this
1473 document itself may not be modified in any way, such as by removing
1474 the copyright notice or references to the Internet Society or other
1475 Internet organizations, except as needed for the purpose of
1476 developing Internet standards in which case the procedures for
1477 copyrights defined in the Internet Standards process must be
1478 followed, or as required to translate it into languages other than
1481 The limited permissions granted above are perpetual and will not be
1482 revoked by the Internet Society or its successors or assigns.
1484 This document and the information contained herein is provided on an
1485 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1486 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1487 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1488 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1489 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1514 Horowitz & Lunt Standards Track [Page 27]