Network Working Group P. Hethmon INTERNET-DRAFT Hethmon Brothers draft-hethmon-mcmurray-ftp-hosts-03.txt R. McMurray Updates: 959 Microsoft Category: Experimental May 2009 File Transfer Protocol HOST Command Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 25, 2009. Copyright Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Hethmon & McMurray Expires November 25, 2009 [Page 1]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The File Transfer Protocol, as defined in [RFC959] and Section 4 of [RFC1123], is one of the oldest and widely used protocols on the Internet. This document addresses the subject of creating multi-homed hostname- based FTP servers on a single IP address. This is achieved by extending the FTP specification to add a HOST command that is used to specify individual FTP hosts. Table of Contents 1. Introduction.....................................................2 2. Document Conventions ...........................................3 2.1. Basic Tokens ...............................................4 2.2. Server Replies .............................................4 3. The HOST command ................................................5 3.1. Syntax of the HOST command ..................................5 3.2. HOST command semantics ......................................6 3.2.1. The REIN command .......................................7 3.2.2. User-PI usage of HOST ...................................7 3.3. HOST command errors ........................................10 3.4. FEAT response for HOST command .............................10 4. Security Considerations ........................................11 5. IANA Considerations ............................................11 6. References .....................................................11 6.1 Normative References ........................................11 6.2 Informative References ......................................11 7. Acknowledgments ................................................12 8. Authors' Addresses .............................................12 1. Introduction It has become common in the Internet for many domain names to be allocated to a single IP address. This has introduced the concept of a "virtual host", where a host appears to exist as an independent entity, but in reality shares all of its resources with one, or more, other such hosts. Such an arrangement presents some problems for FTP servers, as all the FTP server can detect is an incoming FTP connection to a particular IP address. That is, all domain names which share the IP address also share the FTP server, and more importantly, its Non-Volatile File System (NVFS). This means that the various virtual hosts cannot offer different virtual file systems to clients, nor can they offer different Hethmon & McMurray Expires November 25, 2009 [Page 2]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 authentication systems. No scheme can overcome this without modifications of some kind to the user-PI and the user-FTP process. That process is the only entity that knows which virtual host is required. It has performed the domain name to IP address translation, and thus has the original domain name available. One method which could be used to allow a style of virtual host would be for the client to simply send a "CWD" command after connecting, using the virtual host name as the argument to the CWD command. This would allow the server-FTP process to implement the file stores of the virtual hosts as sub-directories in its NVFS. This is simple, and supported by essentially all server-FTP implementations without requiring any code changes. While that method is simple to describe, and to implement, it suffers from several drawbacks. First, the "CWD" command is available only after the user-PI has authenticated itself to the server-FTP process. Thus, all virtual hosts would be required to share a common authentication scheme. Second, either the server-FTP process needs to be modified to understand the special nature of this first CWD command, negating most of the advantage of this scheme, or all users must see the same identical NVFS view upon connecting (they must connect in the same initial directory) or the NVFS must implement the full set of virtual host directories at each possible initial directory for any possible user, or the virtual host will not be truly transparent. Third, and again unless the server is specially modified, a user connecting this way to a virtual host would be able to trivially move to any other virtual host supported at the same server-FTP process, exposing the nature of the virtual host. Other schemes overloading other existing FTP commands have also been proposed. None of those have sufficient merit to be worth discussion. The conclusion from the examination of the possibilities seems to be that to obtain an adequate emulation of "real" FTP servers, server modifications to support virtual hosts are required. A new command seems most likely to provide the support required. 2. Document Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. In examples, "C>" and "S>" indicate lines sent by the client and server, respectively. This document also uses notation defined in [RFC959]. In Hethmon & McMurray Expires November 25, 2009 [Page 3]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 particular, the terms "reply", "user", "NVFS", "file", "pathname", "FTP commands", "DTP", "user-FTP process", "user-PI", "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", "type", "NVT", "control connection", "data connection", and "ASCII", are all used here as defined there. Syntax required is defined using the Augmented BNF defined in [RFC5234]. Some general ABNF definitions are required throughout the document, those will be defined later in this section. At first reading, it may be wise to simply recall that these definitions exist here, and skip to the next section. 2.1. Basic Tokens This document imports the core definitions given in Appendix A of [RFC5234]. There definitions will be found for basic ABNF elements like ALPHA, DIGIT, SP, etc. To that, the following term is added for use in this document. TCHAR = VCHAR / SP / HTAB ; visible plus white space The VCHAR (from [RFC5234]) and TCHAR types give basic character types from varying sub-sets of the ASCII character set for use in various commands and responses. Note that in ABNF, string literals are case insensitive. That convention is preserved in this document, and implies that FTP commands added by this specification have names that can be represented in any case. That is, "HOST" is the same as "host", "Host" and "HoSt" etc. However note that ALPHA, in particular, is case sensitive. 2.2. Server Replies Section 4.2 of [RFC959] defines the format and meaning of replies by the server-PI to FTP commands from the user-PI. Those reply conventions are used here without change. error-response = error-code SP *TCHAR CRLF error-code = ("4" / "5") 2DIGIT Implementors should note that the ABNF syntax (which was not used in [RFC959]) used in this document, and other FTP related documents, sometimes shows replies using the one line format. Unless otherwise explicitly stated, that is not intended to imply that multi-line responses are not permitted. Implementors should assume that, unless stated to the contrary, any reply to any FTP command (including QUIT) may be of the multi-line format described in [RFC959]. Throughout this document, replies will be identified by the three digit code that is their first element. Thus the term "500 reply" Hethmon & McMurray Expires November 25, 2009 [Page 4]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 means a reply from the server-PI using the three digit code "500". 3. The HOST command A new command "HOST" is added to the FTP command set to allow the server-FTP process to determine to which of possibly many virtual hosts the client wishes to connect. This command is intended to be issued before the user is authenticated, allowing the authentication scheme, and set of legal users, to be dependent upon the virtual host chosen. Server-FTP processes may, if they desire, permit the HOST command to be issued after the user has been authenticated, or may treat that as an erroneous sequence of commands. The behavior of the server-FTP process which does allow late HOST commands is undefined. One reasonable interpretation would be for the user-PI to be returned to the state that existed after the TCP connection was first established, before user authentication. Servers should note that the response to the HOST command is a sensible time to send their "welcome" message. This allows the message to be personalized for any virtual hosts that are supported, and also allows the client to determine the supported languages, or representations, for the message, and other messages, via the FEAT response, and selected an appropriate one via the LANG command. See [RFC2640] for more information. 3.1. Syntax of the HOST command The HOST command is defined as follows. host-command = "Host" SP hostname CRLF hostname = 1*DNCHAR 1*( "." 1*DNCHAR ) [ "." ] DNCHAR = ALPHA / DIGIT / "-" / "_" / "$" / "!" / "%" / "[" / "]" / ":" host-response = host-ok / error-response host-ok = "220" [ SP *TCHAR ] CRLF As with all FTP commands, the "HOST" command word is case independent, and may be specified in any character case desired. The "hostname" given as a parameter specifies the virtual host to which access is desired. It should normally be the same name that was used to obtain the IP address to which the FTP control connection was made, after any client conversions to convert an abbreviated or local alias to a complete (fully qualified) domain name, but before resolving a DNS alias (owner of a CNAME resource record) to its canonical name. If the client was given a network literal address, and consequently was not required to derive it from a hostname, it should send the HOST command with the network address, as specified to it, enclosed in brackets (after eliminating any syntax, which might also be Hethmon & McMurray Expires November 25, 2009 [Page 5]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 brackets, but is not required to be, from which the server deduced that a literal address had been specified.) That is, for example HOST [10.1.2.3] should be sent if the client had been instructed to connect to "10.1.2.3", or "[10.1.2.3]", or perhaps even IPv4:10.1.2.3. The method of indicating to a client that a literal address is to be used is beyond the scope of this specification. The parameter is otherwise to be treated as a "complete domain name", as that term is defined in section 3.1 of [RFC1034]. That implies that the name is to be treated as a case independent string, in that upper case ASCII characters are to be treated as equivalent to the corresponding lower case ASCII characters, but otherwise preserved as given. It also implies some limits on the length of the parameter and of the components that create its internal structure. Those limits are not altered in any way here. [RFC1034] imposes no other restrictions upon what kinds of names can be stored in the DNS. Nor does [RFC1035]. This specification, however, allows only a restricted set of names for the purposes of the HOST command. Those restrictions can be inferred from the ABNF grammar given for the "hostname". 3.2. HOST command semantics Upon receiving the HOST command, before authenticating the user-PI, a server-FTP process should validate that the hostname given represents a valid virtual host for that server, and if so, establish the appropriate environment for that virtual host. The meaning of that is not specified here, and may range from doing nothing at all, or performing a simple change of working directory, to much more elaborate state changes, as required. If the hostname specified is unknown at the server, or if the server is otherwise unwilling to treat the particular connection as a connection to the hostname specified, the server will respond with a 504 reply. Note: servers may require that the name specified is in some sense equivalent to the particular network address that was used to reach the server. If the hostname specified would normally be acceptable, but for any reason is temporarily unavailable, the server SHOULD reply to the HOST command with a 421 reply. The "220" reply code for the HOST command is the same as the code that is used on the initial connection established "welcome" message. This is done deliberately in order to allow the implementation of Hethmon & McMurray Expires November 25, 2009 [Page 6]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 the front-end FTP server as a wrapper which simply waits for the HOST command, and then invokes a server that is compliant with [RFC959] in the appropriate environment for the particular hostname received. 3.2.1. The REIN command As specified in [RFC959], the REIN command returns the state of the connection to that it was immediately after the transport connection was opened. That is not changed here. The effect of a HOST command will be lost if a REIN command is performed, a new HOST command must be issued. Implementors of user-FTP should be aware that server-FTP implementations which implement the HOST command as a wrapper around older implementations will be unable to correctly implement the REIN command. In such an implementation, REIN will typically return the server-FTP to the state that existed immediately after the HOST command was issued, instead of to the state immediately after the connection was opened. 3.2.2. User-PI usage of HOST A user-PI that conforms to this specification, MUST send the HOST command after opening the transport connection, or after any REIN command, before attempting to authenticate the user with the USER command. The following state diagram shows a typical sequence of flow of control, where the "B" (begin) state is assumed to occur after the transport connection has opened, or a REIN command has succeeded. Other commands (such as FEAT [RFC2389]) which require no authentication may have intervened. This diagram is modeled upon (and largely borrowed from) the similar diagram in section 6 of [RFC959]. In this diagram, a three digit reply indicates that precise server reply code, a single digit on a reply path indicates any server reply beginning with that digit, other than any three digit replies that might take another path. For each command there are three possible outcomes: success (S), failure (F), and error (E). In the state diagrams below we use the symbol B for "begin", and the symbol W for "wait for reply". +---+ HOST +---+ 1,3,5 | B |---------->| W |----------------- +---+ +---+ | | | | 2,500,502 | | 4,501,503,504 | -------------- ------------- | | | | Hethmon & McMurray Expires November 25, 2009 [Page 7]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 V 1 | V +---+ USER +---+-------------->+---+ | |---------->| W | 2 ----->| E | +---+ +---+------ | --->+---+ | | | | | | 3 | | 4,5 | | | | -------------- ----- | | | | | | | | | | | | | | | | | ---------- | | | 1| | | | | V | | | | | +---+ PASS +---+ 2 | ------->+---+ | |---------->| W |-------------->| S | +---+ +---+ ----------->+---+ | | | | | | 3 | |4,5| | | | -------------- -------- | ---- | | | | | | | | | | | | | ------------ | | 1,3| | | | | V | 2| | | V +---+ ACCT +---+-- | ------>+---+ | |---------->| W | 4,5 --------->| F | +---+ +---+-------------->+---+ The HOST command can be used in combination with the FTP Security Extensions that were introduced in [RFC2228], and SHOULD preceed the security handshake. This allows both user-PI and server-FTP processes to map an FTP HOST to security data appropriately. The following state diagram shows a typical sequence of flow of control when HOST is used with the AUTH and ADAT commands that are discussed in [RFC2228]. As with the preceeding diagram, the "B" (begin) state is assumed to occur after the transport connection has opened, or a REIN command has succeeded. Once again, other commands (such as FEAT [RFC2389]) which require no authentication may have intervened. In this diagram, a three digit reply indicates that precise server reply code, a single digit on a reply path indicates any server reply beginning with that digit, other than any three digit replies that might take another path. For each command there are three possible outcomes: success (S), failure (F), and error (E). In the state diagrams below we use the symbol B for "begin", and the symbol W for "wait for reply". Hethmon & McMurray Expires November 25, 2009 [Page 8]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 +---+ HOST +---+ 1,3,5 | B |---------->| W |----------------- +---+ +---+ | | | | 2,500,502 | | 4,501,503,504 | +-------------- ------------- | | | | V | | +---+ AUTH +---+ 4,5 | | | |---------->| W |----------->| | +---+ +---+ | | 234 | | | | --------- | 334 | | | | | | ---------------|------ | | | | | | | | V | V 335 | | | +---+ | ADAT +---+---- | | | |---------->| W | 4,5 | | +---+ | +---+----------->| | | | | | ---- 235| | | | -------------- | | | | | | V V 1 | V +---+ USER +---+-------------->+---+ | |---------->| W | 2 ----->| E | +---+ +---+------ | --->+---+ | | | | | | 3 | | 4,5 | | | | -------------- ----- | | | | | | | | | | | | | | | | | ---------- | | | 1| | | | | V | | | | | +---+ PASS +---+ 2 | ------->+---+ | |---------->| W |-------------->| S | +---+ +---+ ----------->+---+ | | | | | | 3 | |4,5| | | ---- -------------- -------- | | | | | | | | | | | | | | | ------------ | | 1,3| | | | | V | 2| | | V +---+ ACCT +---+-- | ------>+---+ | |---------->| W | 4,5 --------->| F | +---+ +---+-------------->+---+ Hethmon & McMurray Expires November 25, 2009 [Page 9]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 3.3. HOST command errors The server-PI should reply with a 500 or 502 reply if the HOST command is unrecognized or unimplemented. A 503 reply may be sent if the HOST command is given after a previous HOST command, or after a user has been authenticated. Alternately, the server may accept the command at such a time, with server-defined behavior. A 501 reply should be sent if the hostname given is syntactically invalid, and a 504 reply if a syntactically valid hostname is not a valid virtual host name for the server. In all such cases the server-FTP process should act as if no HOST command had been given. A user-PI receiving a 500 or 502 reply should assume that the server-PI does not implement the HOST command style virtual server. It may then proceed to login as if the HOST command had succeeded, and perhaps, attempt a CWD command to the hostname after authenticating the user. A user-PI receiving some other error reply should assume that the virtual HOST is unavailable, and terminate communications. A server-PI that receives a USER command, beginning the authentication sequence, without having received a HOST command SHOULD NOT reject the USER command. Clients conforming to earlier FTP specifications do not send HOST commands. In this case the server may act as if some default virtual host had been explicitly selected, or may enter an environment different from that of all supported virtual hosts, perhaps one in which a union of all available accounts exists, and which presents a NVFS which appears to contain sub-directories containing the NVFS for all virtual hosts supported. 3.4. FEAT response for HOST command A server-FTP process that supports the HOST command, and virtual FTP servers, MUST include in the response to the FEAT command [RFC2389], a feature line indicating that the HOST command is supported. This line should contain the single word "HOST". This MAY be sent in upper or lower case, or a mixture of both (it is case insensitive) but SHOULD be transmitted in upper case only. That is, the response SHOULD be C> Feat S> 211- <any descriptive text> S> ... S> HOST S> ... S> 211 End Hethmon & McMurray Expires November 25, 2009 [Page 10]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 The ellipses indicate place holders where other features may be included, and are not required. The one space indentation of the feature lines is mandatory [RFC2389]. 4. Security Considerations With the introduction of virtual hosts to FTP, and the possible accompanying multiple authentication environments, server implementors will need to take some care to ensure that integrity is maintained. A general discussion of issues related to the security of FTP can be found in [RFC2577]. 5. IANA Considerations This document has no IANA actions. 6. References 6.1. Normative References [RFC959] Postel, J., Reynolds, J., "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987 [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987 [RFC1123] Braden, R,. "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989 [RFC2228] Horowitz, M., Lunt, S., "FTP Security Extensions", RFC 2228, October 1997 [RFC2389] Hethmon, P., Elz, R., "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998 [RFC2577] Allman, M., Ostermann, S., "FTP Security Considerations", RFC 2577, May 1999 [RFC2640] Curtin, W., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999 [RFC5234] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008 6.2. Informative References Hethmon & McMurray Expires November 25, 2009 [Page 11]
INTERNET-DRAFT File Transfer Protocol HOST Command May 2009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 7. Acknowledgments Robert Elz and Paul Hethmon provided a detailed discussion of the HOST command in their Internet draft titled "Extensions to FTP" as part of their work with the FTPEXT Working Group at the IETF. Their work formed the basis for much of this document, and their help has been greatly appreciated. They would also like to credit Bernhard Rosenkraenzer for having first suggested and described the HOST command. 8. Authors' Addresses Paul Hethmon Hethmon Brothers 2305 Chukar Road Knoxville, TN 37923 USA Email: phethmon@hethmon.com Robert McMurray Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: robmcm@microsoft.com Hethmon & McMurray Expires November 25, 2009 [Page 12]
