Network Working Group                                         P. Hethmon
Internet-Draft                                          Hethmon Brothers
Updates: 959                                                 R. McMurray
Intended status: Standards Track                               Microsoft
Expires: February 2, 2010                                     July 2009


                  File Transfer Protocol HOST Command
                  draft-hethmon-mcmurray-ftp-hosts-06

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 February 2, 2010.

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

Hethmon & McMurray           Expires February 2, 2010           [Page 1]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009

   publication of this document (http://trustee.ietf.org/license-info).
   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 RFC 959 and Section 4
   of RFC 1123, is one of the oldest and most 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 .............................11
   4. Security Considerations ........................................11
   5. IANA Considerations ............................................11
   6. References .....................................................11
     6.1 Normative References ........................................11
     6.2 Informative References ......................................12
   7. Acknowledgments ................................................12
   8. Authors' Addresses .............................................12

1.  Introduction

   It is common on the Internet for many domain names to be allocated
   to a single IP address.  This practice 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
   similar hosts

   Such an arrangement presents some problems for FTP servers, as all
   an FTP server can detect is an incoming FTP connection to a
   particular IP address.  That is, all domain names that share an IP
   address also share the same FTP server, and more importantly, its
   Network Virtual File System (NVFS).

   This means that different virtual hosts cannot offer different

Hethmon & McMurray           Expires February 2, 2010           [Page 2]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009

   virtual file systems to clients, nor can they offer different
   authentication systems.

   No scheme can overcome this without modifications of some kind to the
   user-PI and to 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 that 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 most server-FTP implementations support this 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 if they used this method.  Secondly, to make
   the virtual host truly transparent, either the server-FTP process
   needs to be modified to include information that shows 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.  Thirdly, and
   again, unless the server is specially modified, a user connecting
   this way to a virtual host would be able to easily move to any other
   virtual host supported at the same server-FTP process, exposing the
   nature of the virtual host.

   Other schemes for 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 existing 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", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC2119].

   In examples, "C>" and "S>" indicate lines sent by the client and
   server, respectively.

Hethmon & McMurray           Expires February 2, 2010           [Page 3]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009


   This document also uses notation defined in [RFC959].  In
   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].


Hethmon & McMurray           Expires February 2, 2010           [Page 4]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009

   Throughout this document, replies will be identified by the three
   digit code that is their first element.  Thus the term "500 reply"
   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 SHOULD 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 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 a server-FTP process that
   allows 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 select 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 have been completed that
   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, the client should send

Hethmon & McMurray           Expires February 2, 2010           [Page 5]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009

   the HOST command with the network address, as specified to it.
   Square brackets are expected to disambiguate port numbers syntax from
   IPv6 address syntax.  Therefore, if the network address is an IPv6
   network address, the address should be enclosed in square brackets
   (after eliminating any syntax that might also - but is not required
   to - be enclosed in brackets, and from which the server deduced that
   a literal address had been specified.)  For example:

                         HOST 10.1.2.3
                         HOST [FE80::110:302]
                         HOST [::10.1.2.3]

   should be sent if the client had been instructed to respectively
   connect to "10.1.2.3", "FE80::110:302", or "10.1.2.3" and IPv6
   syntax is preferred.  The client MUST NOT send the port number as
   part of the HOST command, even when the client has been instructed
   to connect to a non-standard port.  For example, the server-PI
   should reply with a 501 reply if the client sends a HOST command
   with syntax like "HOST 10.1.2.3:8021" or "HOST [FE80::110:302]:2112".

   The parameter is otherwise to be treated as a fully qualified domain
   name or relative name as those terms are defined in section 3.1 of
   [RFC1034].  This implies that the name is to be treated as a
   case-independent string, in that uppercase ASCII characters are to
   be treated as equivalent to their corresponding lowercase 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.

   Neither [RFC1034] or [RFC1035] impose any other restrictions upon
   what kinds of names can be stored in the DNS.  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 it is valid, establish
   the appropriate environment for that virtual host.  The resultant
   actions needed to create that environment are not specified here, and
   may range from doing nothing at all, to performing a simple change of
   working directory, to making 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.

Hethmon & McMurray           Expires February 2, 2010           [Page 6]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009


   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 of an established "welcome"
   message.  This reply code is used deliberately in order to allow the
   implementation of 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.  This specification makes no changes to that
   behavior.  The effect of a HOST command will be lost if a REIN
   command is performed, and a new HOST command must be issued.

   Implementors of user-FTP should be aware that server-FTP
   implementations that implement the HOST command as a wrapper around
   older implementations will be unable to correctly implement the REIN
   command.  If they do, REIN will typically return the server-FTP to
   the state that it was in immediately after the HOST command was
   issued, instead of to the state that it was in 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 after a REIN command has
   succeeded.  Other commands (such as FEAT [RFC2389]) that require no
   authentication may have intervened.  This diagram is modeled on
   (and largely borrowed from) the similar diagram in section 6 of
   [RFC959].

   In this diagram, a three-digit reply indicates a precise server reply
   code. A single digit on a reply path indicates any server reply that
   begins with that digit, except where a precise server reply code is

Hethmon & McMurray           Expires February 2, 2010           [Page 7]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009

   defined on another path. For example, a single digit "5" will apply
   to "500", "501", "502", etc., when those reply codes are not
   expressly defined in the diagram. 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    |
                 --------------   -------------     |
                |                              |    |
                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 precede
   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].

Hethmon & McMurray           Expires February 2, 2010           [Page 8]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009


   As with the preceding diagram, the "B" (begin) state is assumed to
   occur after the transport connection has opened, or after a REIN
   command has succeeded.  Once again, other commands (such as FEAT
   [RFC2389]) that require no authentication may have intervened.

   In this diagram, a three-digit reply indicates a precise server reply
   code. A single digit on a reply path indicates any server reply that
   begins with that digit, except where a precise server reply code is
   defined on another path. For example, a single digit "5" will apply
   to "500", "501", "502", etc., when those reply codes are not
   expressly defined in the diagram. 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    |
                +--------------   -------------     |
                |                              |    |
                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   | | | |
                 --------------   -----  | | | |
                |                      | | | | |
                |                      | | | | |
                |                ----------  | |

Hethmon & McMurray           Expires February 2, 2010           [Page 9]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009

                |              1|      | |   | |
                V               |      | |   | |
              +---+   PASS    +---+ 2  |  ------->+---+
              |   |---------->| W |-------------->| S |
              +---+           +---+   ----------->+---+
                               | |   | |     | |
                             3 | |4,5| |     |  ----
                 --------------   --------   |      |
                |                    | |  |  |      |
                |                    | |  |  |      |
                |                ------------       |
                |            1,3|    | |  |         |
                V               |   2| |  |         V
              +---+   ACCT    +---+--  |   ------>+---+
              |   |---------->| W | 4,5 --------->| F |
              +---+           +---+-------------->+---+


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 define
   behavior that allows the HOST command after a user has been
   authenticated.  A 501 reply should be sent if the hostname given is
   syntactically invalid, and a 504 reply should be sent 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 virtual servers by using the HOST
   command. The user-PI may then proceed to login as if the HOST command
   had succeeded, and may attempt a CWD command to the hostname after
   authenticating the user.

   A user-PI receiving an error reply that is different from the errors
   that have been described here 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 any
   supported virtual hosts, perhaps one in which a union of all
   available accounts exists, and which presents an NVFS that appears
   to contain subdirectories that contain the NVFS for all supported
   virtual hosts.

Hethmon & McMurray          Expires February 2, 2010           [Page 10]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009


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 command word is
   case insensitive, but it 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

   The ellipses indicate place holders where other features may be
   included, and are not required.  The single space indentation before
   each feature line 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


Hethmon & McMurray          Expires February 2, 2010           [Page 11]


INTERNET-DRAFT      File Transfer Protocol HOST Command      August 2009

   [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

   [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 February 2, 2010           [Page 12]