diff options
Diffstat (limited to 'doc/rfc/rfc2228.txt')
| -rw-r--r-- | doc/rfc/rfc2228.txt | 1515 |
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc2228.txt b/doc/rfc/rfc2228.txt new file mode 100644 index 0000000..1fbfcbf --- /dev/null +++ b/doc/rfc/rfc2228.txt @@ -0,0 +1,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] + |