draft-ietf-ftpext2-hosts-01.txt   draft-ietf-ftpext2-hosts-02.txt 
FTPEXT2 Working Group P. Hethmon FTPEXT2 Working Group P. Hethmon
Internet-Draft Hethmon Brothers Internet-Draft Hethmon Brothers
Updates: 959 R. McMurray Updates: 959 (if approved) R. McMurray
Intended status: Standards Track Microsoft Intended status: Standards Track Microsoft Corporation
Expires: June 5, 2011 December 2010 Expires: August 29, 2011 February 25, 2011
File Transfer Protocol HOST Command for Virtual Hosts File Transfer Protocol HOST Command for Virtual Hosts
draft-ietf-ftpext2-hosts-01 draft-ietf-ftpext2-hosts-02
Abstract
The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not
provide a way for FTP clients and servers to differentiate between
multiple DNS names that are registered for a single IP address. This
document defines a new FTP command that provides a mechanism for FTP
clients and servers to identify individual virtual hosts on an FTP
server.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". 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 June 5, 2011. This Internet-Draft will expire on August 29, 2011.
Copyright Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described include Simplified BSD License text as described in Section 4.e of
in Section 4.e of the Trust Legal Provisions and are provided the Trust Legal Provisions and are provided without warranty as
without warranty as described in the BSD License. described in the Simplified BSD License.
Abstract
This document defines a new FTP command that provides a mechanism for
FTP clients and servers to identify individual virtual hosts on an
FTP server.
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Conventions ...........................................3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3
2.1. Basic Tokens ...............................................3 2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Server Replies .............................................4 2.2. Server Replies . . . . . . . . . . . . . . . . . . . . . . 4
3. The HOST command ................................................4 3. The HOST command . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Syntax of the HOST command ..................................5 3.1. Syntax of the HOST command . . . . . . . . . . . . . . . . 5
3.2. HOST command semantics ......................................7 3.2. HOST command semantics . . . . . . . . . . . . . . . . . . 8
3.2.1. REIN command semantics ..................................8 3.2.1. REIN command semantics . . . . . . . . . . . . . . . . 8
3.2.2. User-PI usage of HOST ...................................8 3.2.2. User-PI usage of HOST . . . . . . . . . . . . . . . . 9
3.2.3. State Diagrams ..........................................9 3.2.3. State Diagrams . . . . . . . . . . . . . . . . . . . . 10
3.3. HOST command errors ........................................12 3.3. HOST command errors . . . . . . . . . . . . . . . . . . . 18
3.4. FEAT response for HOST command .............................13 3.4. FEAT response for HOST command . . . . . . . . . . . . . . 19
4. Security Considerations ........................................14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations ............................................14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. References .....................................................14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1 Normative References ........................................14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20
6.2 Informative References ......................................15 6.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A: Unworkable Alternatives ...............................16 Appendix A. Unworkable Alternatives . . . . . . . . . . . . . . . 21
A.1. Overloading the CWD command ................................16 A.1. Overloading the CWD command . . . . . . . . . . . . . . . 21
A.2. Overloading the ACCT command ...............................16 A.2. Overloading the ACCT command . . . . . . . . . . . . . . . 22
A.3. Overloading the USER command ...............................17 A.3. Overloading the USER command . . . . . . . . . . . . . . . 22
A.4. Conclusion .................................................18 A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 23
Acknowledgments ...................................................18 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23
Authors' Addresses ................................................18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
It is common on the Internet for many DNS names to resolve to a It is common on the Internet for many DNS names to resolve to a
single IP address. This practice has introduced the concept of a single IP address. This practice has introduced the concept of a
"virtual host", where a host appears to exist as an independent "virtual host", where a host appears to exist as an independent
entity, but in reality shares its physical resources with one or entity, but in reality shares its physical resources with one or more
more similar hosts. similar hosts.
Such an arrangement presents some problems for FTP servers, as an FTP Such an arrangement presents some problems for FTP servers, as an FTP
server distinguishes incoming FTP connections by their IP addresses, server distinguishes incoming FTP connections by their IP addresses,
not their DNS names, because hosts are uniquely identified by their not their DNS names, because hosts are uniquely identified by their
address rather than name. That is, all DNS names that share an IP address rather than name. That is, all DNS names that share an IP
address are handled by the same FTP server and share the same Network address are handled by the same FTP server and share the same Network
Virtual File System (NVFS). Virtual File System (NVFS).
This means that different virtual hosts cannot offer different This means that different virtual hosts cannot offer different
virtual file systems to clients, nor can they offer different virtual file systems to clients, nor can they offer different
skipping to change at page 3, line 28 skipping to change at page 3, line 39
It should be noted that this same problem existed for HTTP/1.0 as It should be noted that this same problem existed for HTTP/1.0 as
defined in [RFC1945], and was resolved in HTTP/1.1 as defined in defined in [RFC1945], and was resolved in HTTP/1.1 as defined in
[RFC2616] through the addition of the Host request header. The goal [RFC2616] through the addition of the Host request header. The goal
of this document is to bring a similar level of feature parity to FTP of this document is to bring a similar level of feature parity to FTP
by introducing a new HOST command that allows user-FTP processes to by introducing a new HOST command that allows user-FTP processes to
specify which virtual host to connect to for a server-FTP process specify which virtual host to connect to for a server-FTP process
that is handling requests for multiple virtual hosts on a single IP that is handling requests for multiple virtual hosts on a single IP
address. address.
2. Document Conventions 2. Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
In examples, "C>" and "S>" indicate lines sent by the client and In examples, "C>" and "S>" indicate lines sent by the client and
server, respectively. server, respectively.
This document also uses notation defined in [RFC959] and [RFC1123]. This document also uses notation defined in [RFC0959] and [RFC1123].
In particular, the terms "reply", "user", "NVFS", "NVT", "file", In particular, the terms "reply", "user", "NVFS", "NVT", "file",
"pathname", "FTP commands", "DTP", "user-FTP process", "user-PI", "pathname", "FTP commands", "DTP", "user-FTP process", "user-PI",
"user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode", "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode",
"type", "control connection", "data connection", and "ASCII", are "type", "control connection", "data connection", and "ASCII", are all
all used here as defined there. used here as defined there.
Syntax required is defined using the Augmented BNF defined in Syntax required is defined using the Augmented BNF defined in
[RFC5234]. Some general ABNF definitions are required throughout the [RFC5234]. Some general ABNF definitions are required throughout the
document; those will be defined later in this section. At first document; those will be defined later in this section. At first
reading, it may be wise to simply recall that these definitions reading, it may be wise to simply recall that these definitions exist
exist here, and skip to the next section. here, and skip to the next section.
2.1. Basic Tokens 2.1. Basic Tokens
This document imports the core definitions given in Appendix B of This document imports the core definitions given in Appendix B of
[RFC5234]. There definitions will be found for basic ABNF elements [RFC5234]. There definitions will be found for basic ABNF elements
like ALPHA, DIGIT, SP, etc. To that, the following term is added like ALPHA, DIGIT, SP, etc. To that, the following term is added for
for use in this document. use in this document.
TCHAR = VCHAR / SP / HTAB ; visible plus white space TCHAR = VCHAR / SP / HTAB ; visible plus white space
The VCHAR (from [RFC5234]) and TCHAR rules give basic character The VCHAR (from [RFC5234]) and TCHAR rules give basic character types
types from varying sub-sets of the ASCII character set for use in from varying sub-sets of the ASCII character set for use in various
various commands and responses. commands and responses.
Note that in ABNF, string literals are case insensitive. That Note that in ABNF, string literals are case insensitive. That
convention is preserved in this document, and implies that FTP convention is preserved in this document, and implies that FTP
commands and parameters that are added by this specification have commands and parameters that are added by this specification have
values that can be represented in any case. That is, "HOST" is the values that can be represented in any case. That is, "HOST" is the
same as "host", "Host", "HoSt", etc., and "ftp.example.com" is the same as "host", "Host", "HoSt", etc., and "ftp.example.com" is the
same as "Ftp.Example.Com", "fTp.eXample.cOm", etc. same as "Ftp.Example.Com", "fTp.eXample.cOm", etc.
2.2. Server Replies 2.2. Server Replies
Section 4.2 of [RFC959] defines the format and meaning of replies Section 4.2 of [RFC0959] defines the format and meaning of replies by
by the server-PI to FTP commands from the user-PI. Those reply the server-PI to FTP commands from the user-PI. Those reply
conventions are used here without change. conventions are used here without change.
error-response = error-code SP *TCHAR CRLF error-response = error-code SP *TCHAR CRLF
error-code = ("4" / "5") 2DIGIT error-code = ("4" / "5") 2DIGIT
Implementers should note that the ABNF syntax (which was not used in Implementers should note that the ABNF syntax (which was not used in
[RFC959]) used in this document, and other FTP related documents, [RFC0959]) used in this document, and other FTP related documents,
sometimes shows replies using the one line format. Unless otherwise sometimes shows replies using the one line format. Unless otherwise
explicitly stated, that is not intended to imply that multi-line explicitly stated, that is not intended to imply that multi-line
responses are not permitted. Implementers should assume that, unless responses are not permitted. Implementers should assume that, unless
stated to the contrary, any reply to any FTP command (including QUIT) stated to the contrary, any reply to any FTP command (including QUIT)
can be of the multi-line format described in [RFC959]. can be of the multi-line format described in [RFC0959].
Throughout this document, replies will be identified by the three Throughout this document, replies will be identified by the three
digit code that is their first element. Thus the term "500 reply" 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". means a reply from the server-PI using the three digit code "500".
3. The HOST command 3. The HOST command
A new command "HOST" is added to the FTP command set to allow the 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 server-FTP process to determine to which of possibly many virtual
hosts the client wishes to connect. This command SHOULD be issued hosts the client wishes to connect. This command SHOULD be issued
before the user is authenticated, allowing the authentication scheme, before the user is authenticated, allowing the authentication scheme,
and set of legal users, to be dependent upon the virtual host chosen. and set of legal users, to be dependent upon the virtual host chosen.
Server-FTP processes SHOULD treat a situation where the HOST command Server-FTP processes SHOULD treat a situation where the HOST command
is issued after the user has been authenticated using one of the is issued after the user has been authenticated using one of the
following two behaviors: following two behaviors:
a. Treat the late HOST command as an erroneous sequence of a. Treat the late HOST command as an erroneous sequence of commands
commands and return a 503 reply. and return a 503 reply.
b. Treat the late HOST command as though a REIN command was sent b. Treat the late HOST command as though a REIN command was sent
before the HOST command and reset the user-PI to the state that before the HOST command and reset the user-PI to the state that
existed after the TCP connection was first established and before existed after the TCP connection was first established and before
the initial user authentication and then return the appropriate the initial user authentication and then return the appropriate
reply for the HOST command. reply for the HOST command.
Servers should note that the response to the HOST command is a Servers should note that the response to the HOST command is a
sensible time to send their "welcome" message. This allows the sensible time to send their "welcome" message. This allows the
message to be personalized for any virtual hosts that are supported, message to be personalized for any virtual hosts that are supported,
and also allows the client to determine the supported languages, or and also allows the client to determine the supported languages, or
representations, for the message, and other messages, via the FEAT representations, for the message, and other messages, via the FEAT
response, and select an appropriate one via the LANG command. See response, and select an appropriate one via the LANG command. See
[RFC2640] for more information. [RFC2640] for more information.
3.1. Syntax of the HOST command 3.1. Syntax of the HOST command
The HOST command is defined as follows. The HOST command is defined as follows.
host-command = "HOST" SP hostname CRLF host-command = "HOST" SP hostname CRLF
hostname = domain / IP-literal hostname = domain / IP-literal
domain = sub-domain *("." sub-domain) domain = sub-domain *("." sub-domain)
sub-domain = let-dig [ldh-str] sub-domain = let-dig [ldh-str]
let-dig = ALPHA / DIGIT let-dig = ALPHA / DIGIT
ldh-str = *( ALPHA / DIGIT / "-" ) let-dig ldh-str = *( ALPHA / DIGIT / "-" ) let-dig
skipping to change at page 6, line 24 skipping to change at page 7, line 10
made, after any client conversions have been completed that convert made, after any client conversions have been completed that convert
an abbreviated or local alias to a complete (fully qualified) domain an abbreviated or local alias to a complete (fully qualified) domain
name, but before resolving a DNS alias (owner of a CNAME resource name, but before resolving a DNS alias (owner of a CNAME resource
record) to its canonical name. record) to its canonical name.
Internationalization of domain names is only supported through the Internationalization of domain names is only supported through the
use of Punycode as described in [RFC3492]. use of Punycode as described in [RFC3492].
If the user was given an IPv4 or IPv6 literal address, and If the user was given an IPv4 or IPv6 literal address, and
consequently was not required to derive the literal address from a consequently was not required to derive the literal address from a
hostname, the client MAY send the HOST command with the IPv4 or hostname, the client MAY send the HOST command with the IPv4 or IPv6
IPv6 literal address as specified to it. While it may seem literal address as specified to it. While it may seem counter-
counter-intuitive to specify a literal address by using the HOST intuitive to specify a literal address by using the HOST command
command after the client has already connected to the server using after the client has already connected to the server using a literal
a literal address, this should be expected behavior because a address, this should be expected behavior because a user-FTP process
user-FTP process should not be required to differentiate between a should not be required to differentiate between a fully qualified
fully qualified domain name and an IPv4 or IPv6 network literal domain name and an IPv4 or IPv6 network literal address. That being
address. That being said, if the IPv4 or IPv6 literal address said, if the IPv4 or IPv6 literal address specified by the client
specified by the client does not match the literal address for the does not match the literal address for the server, the server MUST
server, the server MUST respond with a 504 reply to indicate that respond with a 504 reply to indicate that the IPv4 or IPv6 literal
the IPv4 or IPv6 literal address is not valid. address is not valid.
When the hostname parameter contains a literal address, square When the hostname parameter contains a literal address, square
brackets are expected to disambiguate IPv6 address syntax from port brackets are expected to disambiguate IPv6 address syntax from port
numbers syntax. Therefore, if the literal address is an IPv6 numbers syntax. Therefore, if the literal address is an IPv6
address, the IPv6 address is required to be enclosed in square address, the IPv6 address is required to be enclosed in square
brackets (after eliminating any syntax that might also - but is not brackets (after eliminating any syntax that might also - but is not
required to - be enclosed in brackets, and from which the server required to - be enclosed in brackets, and from which the server
deduced that a literal address had been specified.) For example, the deduced that a literal address had been specified.) For example, the
following examples MAY be sent if the client had been instructed to following examples MAY be sent if the client had been instructed to
respectively connect to "192.0.2.1", "FE80::c000:0201", or respectively connect to "192.0.2.1", "FE80::c000:0201", or
skipping to change at page 7, line 12 skipping to change at page 7, line 50
established a connection to the server-PI before the HOST command is established a connection to the server-PI before the HOST command is
sent, therefore specifying a different port with the HOST command has sent, therefore specifying a different port with the HOST command has
no meaning. For example, the server-PI MUST respond with a 501 reply no meaning. For example, the server-PI MUST respond with a 501 reply
if the client sends a HOST command with syntax like either of the if the client sends a HOST command with syntax like either of the
following examples: following examples:
HOST 192.0.2.1:2112 HOST 192.0.2.1:2112
HOST [FE80::c000:0201]:2112 HOST [FE80::c000:0201]:2112
The hostname parameter is otherwise to be treated as a fully The hostname parameter is otherwise to be treated as a fully
qualified domain name or relative name as those terms are defined qualified domain name or relative name as those terms are defined in
in section 3.1 of [RFC1034]. This implies that the name is to be section 3.1 of [RFC1034]. This implies that the name is to be
treated as a case-independent string, meaning that uppercase ASCII treated as a case-independent string, meaning that uppercase ASCII
characters are to be treated as equivalent to their corresponding characters are to be treated as equivalent to their corresponding
lowercase ASCII characters, but otherwise preserved as given. It lowercase ASCII characters, but otherwise preserved as given. It
also implies some limits on the length of the parameter and of the also implies some limits on the length of the parameter and of the
components that create its internal structure. Those limits are not components that create its internal structure. Those limits are not
altered in any way here. altered in any way here.
Neither [RFC1034] nor [RFC1035] impose any other restrictions upon Neither [RFC1034] nor [RFC1035] impose any other restrictions upon
what kinds of names can be stored in the DNS. This specification, what kinds of names can be stored in the DNS. This specification,
however, only allows the use of names that can be inferred from the however, only allows the use of names that can be inferred from the
ABNF grammar given for the "hostname". ABNF grammar given for the "hostname".
3.2. HOST command semantics 3.2. HOST command semantics
Upon receiving the HOST command, before authenticating the user-PI, a Upon receiving the HOST command, before authenticating the user-PI, a
server-FTP process SHOULD validate that the hostname given represents server-FTP process SHOULD validate that the hostname given represents
a valid virtual host for that server, and, if it is valid, establish a valid virtual host for that server, and, if it is valid, establish
the appropriate environment for that virtual host. The resultant the appropriate environment for that virtual host. The resultant
actions needed to create that environment are not specified here, and actions needed to create that environment are not specified here, and
may range from doing nothing at all, to performing a simple change of may range from doing nothing at all, to performing a simple change of
working directory, to changing authentication schemes and/or username working directory, to changing authentication schemes and/or username
and password lists, to making much more elaborate state changes, as and password lists, to making much more elaborate state changes, as
necessary. necessary.
The "220" reply code for the HOST command is the same as the code The "220" reply code for the HOST command is the same as the code
that is used in the initial "welcome" message that is sent after that is used in the initial "welcome" message that is sent after the
the connection is established. This reply code is used deliberately connection is established. This reply code is used deliberately in
in order to allow the implementation of a front-end FTP server as a order to allow the implementation of a front-end FTP server as a
wrapper, which simply waits for the HOST command, and then invokes a wrapper, which simply waits for the HOST command, and then invokes a
server that is compliant with [RFC959] in the appropriate environment server that is compliant with [RFC0959] in the appropriate
for the particular hostname received. environment for the particular hostname received.
If the hostname specified would normally be acceptable, but for any If the hostname specified would normally be acceptable, but for any
reason is temporarily unavailable, the server-FTP process SHOULD reason is temporarily unavailable, the server-FTP process SHOULD
reply to the HOST command with a 421 reply and close the connection. reply to the HOST command with a 421 reply and close the connection.
In this particular situation, the server-FTP process MAY choose to In this particular situation, the server-FTP process MAY choose to
keep the connection open in order to allow the user-PI an opportunity keep the connection open in order to allow the user-PI an opportunity
to choose another virtual host with a subsequent HOST command. to choose another virtual host with a subsequent HOST command.
If the hostname specified is unknown at the server, or if the server If the hostname specified is unknown at the server, or if the server
is otherwise unwilling to treat the particular connection as a is otherwise unwilling to treat the particular connection as a
connection to the hostname specified, the server SHOULD respond with connection to the hostname specified, the server SHOULD respond with
a 504 reply. a 504 reply.
3.2.1. REIN command semantics 3.2.1. REIN command semantics
As specified in [RFC959], the REIN command returns the state of As specified in [RFC0959], the REIN command returns the state of the
the connection to what it was immediately after the transport connection to what it was immediately after the transport connection
connection was opened. This specification makes no changes to that was opened. This specification makes no changes to that behavior.
behavior. The effect of a HOST command MUST be reset if a REIN
command is performed, and a new HOST command MUST be issued in order
to connect to a virtual host.
3.2.2. User-PI usage of HOST The effect of a HOST command MUST be reset if a REIN command is
performed, and a new HOST command MUST be issued in order to connect
to a virtual host.
3.2.2. User-PI usage of HOST
A user-PI that conforms to this specification MUST send the HOST A user-PI that conforms to this specification MUST send the HOST
command after opening the transport connection, or after any REIN command after opening the transport connection, or after any REIN
command, before attempting to authenticate the user with the USER command, before attempting to authenticate the user with the USER
command. The following example illustrates what a typical login command. The following example illustrates what a typical login
sequence might look like when the HOST command is used: sequence might look like when the HOST command is used:
C> HOST ftp.example.com C> HOST ftp.example.com
S> 220 Host accepted S> 220 Host accepted
C> USER foo C> USER foo
S> 331 Password required S> 331 Password required
C> PASS bar C> PASS bar
S> 230 User logged in S> 230 User logged in
The HOST command can be used in combination with the ACCT command The HOST command can be used in combination with the ACCT command to
to differentiate between a user's various accounts on a specific differentiate between a user's various accounts on a specific virtual
virtual host. In this scenario, the user-PI sends a HOST command host. In this scenario, the user-PI sends a HOST command which the
which the server-PI uses to route activity to the correct virtual server-PI uses to route activity to the correct virtual host; the
host; the user-PI sends credentials using the USER and PASS commands user-PI sends credentials using the USER and PASS commands which the
which the server-PI validates; then, the user-PI sends an ACCT server-PI validates; then, the user-PI sends an ACCT command to
command to specify any additional account information for the specify any additional account information for the server-PI
server-PI implementation. The following example illustrates a implementation. The following example illustrates a sequential
sequential series of client commands that specify both a HOST and series of client commands that specify both a HOST and ACCT, with the
ACCT, with the server responses omitted for brevity: server responses omitted for brevity:
C> HOST ftp.example.com C> HOST ftp.example.com
C> USER foo C> USER foo
C> PASS bar C> PASS bar
C> ACCT project1 C> ACCT project1
This is also true when the HOST command is used with the AUTH and This is also true when the HOST command is used with the AUTH and
ADAT commands that are discussed in [RFC2228] and [RFC4217]. In ADAT commands that are discussed in [RFC2228] and [RFC4217]. In this
this scenario, the user-PI sends a HOST command which the server-PI scenario, the user-PI sends a HOST command which the server-PI uses
uses to route activity to the correct virtual host, then the user-PI to route activity to the correct virtual host, then the user-PI uses
uses the AUTH and ADAT commands to negotiate the security mechanism the AUTH and ADAT commands to negotiate the security mechanism and
and certificate with the server-PI, then the user-PI sends user certificate with the server-PI, then the user-PI sends user
credentials using the USER and PASS commands which the server-PI credentials using the USER and PASS commands which the server-PI
validates. After which the user-PI MAY send an ACCT command to validates. After which the user-PI MAY send an ACCT command to
specify any additional account information for the server-PI specify any additional account information for the server-PI
implementation. The following example illustrates a sequential implementation. The following example illustrates a sequential
series of client commands that specify both a HOST and ACCT when series of client commands that specify both a HOST and ACCT when used
used in conjunction with the security commands that are discussed in conjunction with the security commands that are discussed in
in [RFC2228] and [RFC4217], with the server responses omitted for [RFC2228] and [RFC4217], with the server responses omitted for
brevity: brevity:
C> HOST ftp.example.com C> HOST ftp.example.com
C> AUTH <mechanism-name> C> AUTH <mechanism-name>
C> ADAT <base64data> C> ADAT <base64data>
C> USER foo C> USER foo
C> PASS bar C> PASS bar
C> ACCT project1 C> ACCT project1
3.2.3. State Diagrams 3.2.3. State Diagrams
The state diagrams in this section illustrate typical sequences for The state diagrams in this section illustrate typical sequences for
command and reply interchange between the user-PI and server-PI. command and reply interchange between the user-PI and server-PI.
These diagrams are modeled on the similar diagrams in section 6 of These diagrams are modeled on the similar diagrams in section 6 of
[RFC959]. [RFC0959].
In each diagram, the (B) "begin" state is assumed to occur after In each diagram, the (B) "begin" state is assumed to occur after the
the transport connection has opened, or after a REIN command has transport connection has opened, or after a REIN command has
succeeded. Other commands (such as FEAT [RFC2389]) that require no succeeded. Other commands (such as FEAT [RFC2389]) that require no
authentication may have intervened. authentication may have intervened.
Additionally, a three-digit reply indicates a precise server reply Additionally, a three-digit reply indicates a precise server reply
code. A single digit on a reply path indicates any server reply that 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 begins with that digit, except where a precise server reply code is
defined on another path. For example, a single digit "5" will apply defined on another path. For example, a single digit "5" will apply
to "500", "501", "502", etc., when those reply codes are not to "500", "501", "502", etc., when those reply codes are not
expressly defined in the diagram. For each command there are three expressly defined in the diagram. For each command there are three
possible outcomes: success (S), failure (F), and error (E). In the possible outcomes: success (S), failure (F), and error (E). In the
state diagrams below we use the symbol B for "begin", and the state diagrams below we use the symbol B for "begin", and the symbol
symbol W for "wait for reply". W for "wait for reply".
In each of these diagrams, a REIN command will return the diagram to In each of these diagrams, a REIN command will return the diagram to
the (B) "begin" state. the (B) "begin" state.
The state diagram in Figure 1 shows a typical sequence of flow of The state diagram in Figure 1 shows a typical sequence of flow of
control when HOST is used with USER and PASS to log in to a control when HOST is used with USER and PASS to log in to a
particular FTP virtual host. particular FTP virtual host.
+---+ HOST +---+ 1,3,5 +---+ HOST +---+ 1,3,5
| B |---------->| W |----------------- | B |---------->| W |-----------------
skipping to change at page 10, line 24 skipping to change at page 11, line 36
V | | ------->+---+ V | | ------->+---+
+---+ PASS +---+ 2 | | | S | +---+ PASS +---+ 2 | | | S |
| |---------->| W |-------------->+---+ | |---------->| W |-------------->+---+
+---+ +---+ | | +---+ +---+ | |
| | | | | |
|4,5 | | |4,5 | |
| | -->+---+ | | -->+---+
| --------->| F | | --------->| F |
---------------->+---+ ---------------->+---+
Figure 1: Typical login sequence with HOST command Figure 1: Typical login sequence with HOST command
The state diagram in Figure 2 shows the flow of control when a HOST The state diagram in Figure 2 shows the flow of control when a HOST
command is sent after a user has already successfully logged in to a command is sent after a user has already successfully logged in to a
virtual host with USER and PASS. virtual host with USER and PASS.
------------------------------ ------------------------------
| | | |
| | | |
V | V |
+---+ HOST +---+ 1,3,5 | +---+ HOST +---+ 1,3,5 |
skipping to change at page 11, line 11 skipping to change at page 12, line 42
+---+ PASS +---+ 2 | | | S |-------- +---+ PASS +---+ 2 | | | S |--------
| |---------->| W |-------------->+---+ | |---------->| W |-------------->+---+
+---+ +---+ | | +---+ +---+ | |
| | | | | |
|4,5 | | |4,5 | |
| | | | | |
| | -->+---+ | | -->+---+
| --------->| F | | --------->| F |
---------------->+---+ ---------------->+---+
Figure 2: Login sequence with repeated HOST command Figure 2: Login sequence with repeated HOST command
After a user has logged in, an additional account may be required by After a user has logged in, an additional account may be required by
the server and specified by the client by using ACCT command. With the server and specified by the client by using ACCT command. With
this in mind, the state diagram in Figure 3 shows a typical sequence this in mind, the state diagram in Figure 3 shows a typical sequence
of flow of control when HOST is used with USER and PASS to log in to of flow of control when HOST is used with USER and PASS to log in to
an FTP virtual host and ACCT is used to specify an account. an FTP virtual host and ACCT is used to specify an account.
+---+ HOST +---+ 1,3,5 +---+ HOST +---+ 1,3,5
| B |---------->| W |----------------- | B |---------->| W |-----------------
+---+ +---+ | +---+ +---+ |
skipping to change at page 11, line 53 skipping to change at page 13, line 45
-------------- -------- | ---- -------------- -------- | ----
| | | | | | | | | | | |
| | | | | | | | | | | |
| ------------ | | ------------ |
| 1,3| | | | | | 1,3| | | | |
V | 2| | | V V | 2| | | V
+---+ ACCT +---+-- | ------>+---+ +---+ ACCT +---+-- | ------>+---+
| |---------->| W | 4,5 --------->| F | | |---------->| W | 4,5 --------->| F |
+---+ +---+-------------->+---+ +---+ +---+-------------->+---+
Figure 3: Login sequence with HOST and ACCT commands Figure 3: Login sequence with HOST and ACCT commands
When the HOST command is used in combination with the FTP security When the HOST command is used in combination with the FTP security
extensions that were introduced in [RFC2228], it SHOULD precede extensions that were introduced in [RFC2228], it SHOULD precede the
the security handshake. This allows both user-PI and server-FTP security handshake. This allows both user-PI and server-FTP
processes to map an FTP HOST to security data appropriately. The processes to map an FTP HOST to security data appropriately. The
state diagram in Figure 4 shows a typical sequence of flow of control state diagram in Figure 4 shows a typical sequence of flow of control
when HOST is used with the AUTH and ADAT commands that are discussed when HOST is used with the AUTH and ADAT commands that are discussed
in [RFC2228]. in [RFC2228].
+---+ HOST +---+ 1,3,5 +---+ HOST +---+ 1,3,5
| B |---------->| W |------------------ | B |---------->| W |------------------
+---+ +---+ | +---+ +---+ |
| | | | | |
2,500,502 | | 4,501,503,504 | 2,500,502 | | 4,501,503,504 |
skipping to change at page 13, line 10 skipping to change at page 16, line 5
|4,5 | | |4,5 | |
| | -->+---+ | | -->+---+
| --------->| F | | --------->| F |
---------------->+---+ ---------------->+---+
Figure 4: Login sequence with HOST and AUTH/ADAT commands Figure 4: Login sequence with HOST and AUTH/ADAT commands
After a user has logged in with the security commands that are After a user has logged in with the security commands that are
discussed in [RFC2228], an additional account may be required by the discussed in [RFC2228], an additional account may be required by the
server and specified by the client by using ACCT command. The state server and specified by the client by using ACCT command. The state
diagram in Figure 5 shows a typical sequence of flow of control diagram in Figure 5 shows a typical sequence of flow of control when
when HOST is used with the AUTH and ADAT commands to log in to HOST is used with the AUTH and ADAT commands to log in to an FTP
an FTP virtual host and ACCT is used to specify an account. virtual host and ACCT is used to specify an account.
+---+ HOST +---+ 1,3,5 +---+ HOST +---+ 1,3,5
| B |---------->| W |------------------ | B |---------->| W |------------------
+---+ +---+ | +---+ +---+ |
| | | | | |
2,500,502 | | 4,501,503,504 | 2,500,502 | | 4,501,503,504 |
+-------------- -------------- | +-------------- -------------- |
| | | | | |
V | | V | |
+---+ AUTH +---+ 4,5 | | +---+ AUTH +---+ 4,5 | |
skipping to change at page 14, line 4 skipping to change at page 17, line 46
| | | | | | | | | | | |
| ----------- | | | ----------- | |
| 1| | | | | | 1| | | | |
V | | | | | V | | | | |
+---+ PASS +---+ 2 | ------->+---+ +---+ PASS +---+ 2 | ------->+---+
| |---------->| W |--------------->| S | | |---------->| W |--------------->| S |
+---+ +---+ ------------>+---+ +---+ +---+ ------------>+---+
| | | | | | | | | | | |
3 | |4,5| | | | 3 | |4,5| | | |
-------------- --------- | ---- -------------- --------- | ----
| | | | | | | | | | | |
| ------------- | | ------------- |
| 1,3| | | | | | 1,3| | | | |
V | 2| | | V V | 2| | | V
+---+ ACCT +---+-- | ------>+---+ +---+ ACCT +---+-- | ------>+---+
| |---------->| W | 4,5 --------->| F | | |---------->| W | 4,5 --------->| F |
+---+ +---+--------------->+---+ +---+ +---+--------------->+---+
Figure 5: Login sequence with HOST and AUTH/ADAT/ACCT commands Figure 5: Login sequence with HOST and AUTH/ADAT/ACCT commands
3.3. HOST command errors 3.3. HOST command errors
The server-PI SHOULD reply with a 500 or 502 reply if the HOST The server-PI SHOULD reply with a 500 or 502 reply if the HOST
command is unrecognized or unimplemented. command is unrecognized or unimplemented.
As discussed in section 3 of this document, if a HOST command is sent As discussed in section 3 of this document, if a HOST command is sent
after a user has been authenticated the server SHOULD do one of the after a user has been authenticated the server SHOULD do one of the
following: following:
a. Send a 503 reply for an invalid sequence of commands. a. Send a 503 reply for an invalid sequence of commands.
b. Treat the HOST command as though a REIN command was sent and b. Treat the HOST command as though a REIN command was sent and
reset the user-PI to the state that existed after the previous reset the user-PI to the state that existed after the previous
HOST command was sent and before the user had been authenticated, HOST command was sent and before the user had been authenticated,
and then return the appropriate reply for the HOST command. and then return the appropriate reply for the HOST command.
A 501 reply SHOULD be sent if the hostname given is syntactically A 501 reply SHOULD be sent if the hostname given is syntactically
invalid, and a 504 reply SHOULD be sent if a syntactically valid 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 hostname is not a valid virtual host name for the server. In all
such cases, the server-FTP process MUST do one of the following: such cases, the server-FTP process MUST do one of the following:
a. Ignore the HOST command and act as if a HOST command had not a. Ignore the HOST command and act as if a HOST command had not been
been sent. A user-FTP process MAY then send a subsequent HOST sent. A user-FTP process MAY then send a subsequent HOST command
command with a different hostname. with a different hostname.
b. Close the connection. b. Close the connection.
A user-PI receiving a 500 or 502 reply to a HOST command SHOULD A user-PI receiving a 500 or 502 reply to a HOST command SHOULD
assume that the server-PI does not implement virtual servers by using 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 the HOST command. The user-PI MAY then proceed to login as if the
HOST command had not been sent. HOST command had not been sent.
A user-PI receiving an error reply that is different from the errors 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 that have been described here SHOULD assume that the virtual HOST is
unavailable, and terminate communications. unavailable, and terminate communications.
A server-PI that receives a USER command to begin the authentication A server-PI that receives a USER command to begin the authentication
sequence without having received a HOST command SHOULD NOT reject the sequence without having received a HOST command SHOULD NOT reject the
USER command. Clients conforming to earlier FTP specifications do USER command. Clients conforming to earlier FTP specifications do
not send HOST commands. In this case the server MAY act as if some 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 default virtual host had been explicitly selected, or MAY enter an
environment that is different from that of any supported virtual environment that is different from that of any supported virtual
hosts, perhaps one in which a union of all available accounts exists hosts, perhaps one in which a union of all available accounts exists
and which presents an NVFS that appears to contain subdirectories and which presents an NVFS that appears to contain subdirectories
that contain the NVFS for all supported virtual hosts. that contain the NVFS for all supported virtual hosts.
3.4. FEAT response for HOST command 3.4. FEAT response for HOST command
When replying to the FEAT command [RFC2389], a server-FTP process When replying to the FEAT command [RFC2389], a server-FTP process
that supports the HOST command MUST include a line containing the that supports the HOST command MUST include a line containing the
single word "HOST". This word is case insensitive, and MAY be sent single word "HOST". This word is case insensitive, and MAY be sent
in any mixture of upper or lower case, however it SHOULD be sent in in any mixture of upper or lower case, however it SHOULD be sent in
upper case. That is, the response SHOULD be: upper case. That is, the response SHOULD be:
C> FEAT C> FEAT
S> 211- <any descriptive text> S> 211- <any descriptive text>
S> ... S> ...
S> HOST S> HOST
S> ... S> ...
S> 211 End S> 211 End
The ellipses indicate place holders where other features may be The ellipses indicate place holders where other features may be
included, and are not required. The one-space indentation of the included, and are not required. The one-space indentation of the
feature lines is mandatory [RFC2389]. feature lines is mandatory [RFC2389].
4. Security Considerations 4. Security Considerations
With the introduction of virtual hosts to FTP, server implementers With the introduction of virtual hosts to FTP, server implementers
will need to take some care to ensure that the integrity of will need to take some care to ensure that the integrity of
potentially sensitive information is maintained. For example, while potentially sensitive information is maintained. For example, while
hostnames may generally be assumed to be publicly available DNS hostnames may generally be assumed to be publicly available DNS
names, this may not always be the situation. Some organizations may names, this may not always be the situation. Some organizations may
use private hostnames, and that information SHOULD be protected when use private hostnames, and that information SHOULD be protected when
transmitted between the client and server by using a strong method of transmitted between the client and server by using a strong method of
encryption. encryption.
skipping to change at page 15, line 52 skipping to change at page 19, line 48
FTP server. For example, a virtual host "foo.example.com" on an FTP FTP server. For example, a virtual host "foo.example.com" on an FTP
server might use a specific username and password list, while the server might use a specific username and password list, while the
virtual host "bar.example.com" on the same FTP server might use a virtual host "bar.example.com" on the same FTP server might use a
different username and password list. In such a scenario, resetting different username and password list. In such a scenario, resetting
the security environment is necessary for virtual servers to appear the security environment is necessary for virtual servers to appear
to behave independently. to behave independently.
A general discussion of issues related to the security of FTP can be A general discussion of issues related to the security of FTP can be
found in [RFC2577]. found in [RFC2577].
5. IANA Considerations 5. IANA Considerations
IANA is requested to register the following FTP extension according IANA is requested to register the following FTP extension according
to the procedure established by [RFC5797]: to the procedure established by [RFC5797]:
+-------+------+-------------------+------+------+------------------+ +------+---------+-------------+------+------+----------------------+
| cmd | FEAT | description | type | conf | RFC#s/References | | cmd | FEAT | description | type | conf | RFC#s/References and |
| | Code | | | | and Notes | | | Code | | | | Notes |
+-------+------+-------------------+------+------+------------------+ +------+---------+-------------+------+------+----------------------+
| HOST | HOST | Hostname | a | o | [#1] | | HOST | HOST | Hostname | a | o | TBD |
+-------+------+-------------------+------+------+------------------+ +------+---------+-------------+------+------+----------------------+
[[ RFC Editor: Please update note #1 in the above table with the NOTE TO RFC EDITOR: Please update TBD in the above table with the
number of this document. ]] number of this document.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC959] Postel, J., Reynolds, J., "File Transfer Protocol (FTP)", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol
STD 9, RFC 959, October 1985 (FTP)", STD 9, RFC 959, October 1985.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987 STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987 Specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R,. "Requirements for Internet Hosts -- [RFC1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989 Application and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997 Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2228] Horowitz, M., Lunt, S., "FTP Security Extensions", [RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions",
RFC 2228, October 1997 RFC 2228, October 1997.
[RFC2389] Hethmon, P., Elz, R., "Feature negotiation mechanism for [RFC2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for
the File Transfer Protocol", RFC 2389, August 1998 the File Transfer Protocol", RFC 2389, August 1998.
[RFC2640] Curtin, W., "Internationalization of the File Transfer [RFC2640] Curtin, W., "Internationalization of the File Transfer
Protocol", RFC 2640, July 1999 Protocol", RFC 2640, July 1999.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications (IDNA)", for Internationalized Domain Names in Applications
RFC 3492, March 2003 (IDNA)", RFC 3492, March 2003.
[RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
October 2005 October 2005.
[RFC5234] Crocker, D., Overell, P., "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008 Specifications: ABNF", RFC 5234, January 2008.
6.2. Informative References 6.2. Informative References
[RFC1945] Berners-Lee, T., Fielding, R., Frystyk, H., "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC2577] Allman, M., Ostermann, S., "FTP Security Considerations", [RFC2577] Allman, M. and S. Ostermann, "FTP Security
RFC 2577, May 1999 Considerations", RFC 2577, May 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5797] Klensin, J., Hoenes, A., "FTP Command and Extension [RFC5797] Klensin, J. and A. Hoenes, "FTP Command and Extension
Registry", March 2010 Registry", RFC 5797, March 2010.
Appendix A: Unworkable Alternatives Appendix A. Unworkable Alternatives
Due to the level of scope for adding a new command to FTP, a brief Due to the level of scope for adding a new command to FTP, a brief
discussion of suggested alternatives to a HOST command and their discussion of suggested alternatives to a HOST command and their
respective limitations is warranted. The suggested alternatives respective limitations is warranted. The suggested alternatives that
that are discussed in this appendix have been proposed in the past, are discussed in this appendix have been proposed in the past, but
but each of these ideas was deemed insufficient for the reasons that each of these ideas was deemed insufficient for the reasons that are
are listed within each section of the appendix. listed within each section of the appendix.
A.1. Overloading the CWD command A.1. Overloading the CWD command
One suggested method to emulate a form of virtual hosts would be for One suggested method to emulate a form of virtual hosts would be for
the client to simply send a "CWD" command after connecting, using the the client to simply send a "CWD" command after connecting, using the
virtual host name as the argument to the CWD command. This would virtual host name as the argument to the CWD command. This would
allow the server-FTP process to implement the file stores of the allow the server-FTP process to implement the file stores of the
virtual hosts as sub-directories in its NVFS. This suggestion is virtual hosts as sub-directories in its NVFS. This suggestion is
simple in concept, and most server-FTP implementations support this simple in concept, and most server-FTP implementations support this
without requiring any code changes. While this method is simple to without requiring any code changes. While this method is simple to
describe, and to implement, it suffers from several drawbacks: describe, and to implement, it suffers from several drawbacks:
a. The "CWD" command is available only after the user-PI has a. The "CWD" command is available only after the user-PI has
authenticated itself to the server-FTP process. Thus, all virtual authenticated itself to the server-FTP process. Thus, all
hosts would be required to share a common authentication scheme virtual hosts would be required to share a common authentication
if they used this method. scheme if they used this method.
b. To make the virtual host truly transparent, either the b. To make the virtual host truly transparent, either the server-FTP
server-FTP process needs to be modified to include information process needs to be modified to include information that shows
that shows the special nature of this first CWD command (negating the special nature of this first CWD command (negating most of
most of the advantage of this scheme), or all users must see the the advantage of this scheme), or all users must see the same
same identical NVFS view upon connecting (they must connect in the identical NVFS view upon connecting (they must connect in the
same initial directory), or the NVFS must implement the full set same initial directory), or the NVFS must implement the full set
of virtual host directories at each possible initial directory of virtual host directories at each possible initial directory
for any possible user. for any possible user.
c. Unless the server is specially modified, a user connecting this c. Unless the server is specially modified, a user connecting this
way to a virtual host would be able to easily move to any other way to a virtual host would be able to easily move to any other
virtual host supported at the same server-FTP process, exposing virtual host supported at the same server-FTP process, exposing
the nature of the virtual host. the nature of the virtual host.
A.2. Overloading the ACCT command A.2. Overloading the ACCT command
Another suggested method would be to simply overload the "ACCT" for Another suggested method would be to simply overload the "ACCT" for
FTP virtual hosts, but this proposal is unacceptable for several FTP virtual hosts, but this proposal is unacceptable for several
reasons with regard to when the ACCT command is sent during the reasons with regard to when the ACCT command is sent during the
request flow. Sections 5.4 and 6 of [RFC959] document the request request flow. Sections 5.4 and 6 of [RFC0959] document the request
flow for a login sequence as USER -> PASS -> ACCT. This flow of flow for a login sequence as USER -> PASS -> ACCT. This flow of
commands may be acceptable when you are considering a single user commands may be acceptable when you are considering a single user
having multiple accounts on an FTP server, but fails to having multiple accounts on an FTP server, but fails to differentiate
differentiate between virtual hosts when you consider the following between virtual hosts when you consider the following two issues:
two issues:
a. The first problem with overloading the ACCT command is a. The first problem with overloading the ACCT command is
certificate negotiation when using the FTP security extensions certificate negotiation when using the FTP security extensions
that are documented in [RFC2228] and [RFC4217]. In order to that are documented in [RFC2228] and [RFC4217]. In order to
safeguard user credentials, security mechanism and certificate safeguard user credentials, security mechanism and certificate
negotiation must occur before login credentials are sent by the negotiation must occur before login credentials are sent by the
client. The problem with using the ACCT command in this scenario client. The problem with using the ACCT command in this scenario
is that there is no way of ensuring that the certificate matches is that there is no way of ensuring that the certificate matches
the correct virtual host before the user credentials are sent. the correct virtual host before the user credentials are sent.
b. The second problem with overloading the ACCT command is how b. The second problem with overloading the ACCT command is how user
user credentials are implemented for FTP virtual hosts. FTP credentials are implemented for FTP virtual hosts. FTP server
server implementations may allow the use of custom user implementations may allow the use of custom user credentials on a
credentials on a per-virtual-host basis. For example, in one per-virtual-host basis. For example, in one particular
particular implementation the virtual host negotiation occurs, implementation the virtual host negotiation occurs, and then the
and then the user credentials are looked up using the account user credentials are looked up using the account mechanism that
mechanism that is specific to that virtual host. So once again is specific to that virtual host. So once again the virtual host
the virtual host negotiation must take place before the user negotiation must take place before the user credentials are sent.
credentials are sent.
A.3. Overloading the USER command A.3. Overloading the USER command
An additional suggestion would be to overload well-known syntax An additional suggestion would be to overload well-known syntax
through the existing USER command, as illustrated in the following through the existing USER command, as illustrated in the following
example: example:
C> USER foo@example.com C> USER foo@example.com
S> 331 Password required S> 331 Password required
C> PASS bar C> PASS bar
S> 230 User logged in S> 230 User logged in
In this example, the user "foo" might be attempting to log on to the In this example, the user "foo" might be attempting to log on to the
virtual host "example.com" on an FTP server. This suggestion may virtual host "example.com" on an FTP server. This suggestion may
seem plausible at first, but introduces several implementation seem plausible at first, but introduces several implementation
problems. For example: problems. For example:
a. Some network environments already use the "username@hostname" a. Some network environments already use the "username@hostname"
syntax for network credentials, where the "hostname" portion syntax for network credentials, where the "hostname" portion
refers to the location of the user's credentials within the refers to the location of the user's credentials within the
network hierarchy. Using the "foo@example.com" syntax it becomes network hierarchy. Using the "foo@example.com" syntax it becomes
difficult to differentiate between the user "foo" logging into a difficult to differentiate between the user "foo" logging into a
virtual host named "example.com" on an FTP server versus the user virtual host named "example.com" on an FTP server versus the user
"foo@example.com" logging into an FTP server with no specified "foo@example.com" logging into an FTP server with no specified
virtual host. virtual host.
b. When using the FTP security extensions that are documented in b. When using the FTP security extensions that are documented in
[RFC2228] and [RFC4217], security mechanism and certificate [RFC2228] and [RFC4217], security mechanism and certificate
negotiation must occur before login credentials are sent by the negotiation must occur before login credentials are sent by the
client. More specifically, the AUTH/ADAT commands must be sent client. More specifically, the AUTH/ADAT commands must be sent
before the USER command in order to safeguard user credentials. before the USER command in order to safeguard user credentials.
If you overload the USER command, there is no way of ensuring that If you overload the USER command, there is no way of ensuring
the certificate matches the correct virtual host before the user that the certificate matches the correct virtual host before the
credentials are sent by the client. user credentials are sent by the client.
A.4. Conclusion A.4. Conclusion
The conclusion from the examination of the existing possibilities The conclusion from the examination of the existing possibilities
seems to be that in order to obtain an adequate emulation of "real" seems to be that in order to obtain an adequate emulation of "real"
FTP servers, client and server modifications to support virtual hosts FTP servers, client and server modifications to support virtual hosts
are necessary. Therefore a new FTP command seems the most likely are necessary. Therefore a new FTP command seems the most likely
solution to provide the required level of support. solution to provide the required level of support.
Acknowledgments Appendix B. Acknowledgements
Robert Elz and Paul Hethmon provided a detailed discussion of the Robert Elz and Paul Hethmon provided a detailed discussion of the
HOST command in their Internet draft titled "Extensions to FTP" HOST command in their Internet draft titled "Extensions to FTP" as
as part of their work with the FTPEXT Working Group at the IETF. part of their work with the FTPEXT Working Group at the IETF. Their
Their work formed the basis for much of this document, and their work formed the basis for much of this document, and their help has
help has been greatly appreciated. They would also like to credit been greatly appreciated. They would also like to credit Bernhard
Bernhard Rosenkraenzer for having first suggested and described the Rosenkraenzer for having first suggested and described the HOST
HOST command. command.
Alexey Melnikov, Alfred Hoenes, John Klensin, and Joe Touch have made Alexey Melnikov, Alfred Hoenes, John Klensin, and Joe Touch have made
several suggestions about earlier versions of this document; many of several suggestions about earlier versions of this document; many of
their suggestions have been incorporated, and their contributions are their suggestions have been incorporated, and their contributions are
gratefully acknowledged. In addition, Alec Rowell's assistance in gratefully acknowledged. In addition, Alec Rowell's assistance in
making sections of this document more readable was invaluable. making sections of this document more readable was invaluable.
Authors' Addresses Authors' Addresses
Paul Hethmon Paul Hethmon
Hethmon Brothers Hethmon Brothers
2305 Chukar Road 2305 Chukar Road
Knoxville, TN 37923 USA Knoxville, TN 37923
USA
Email: phethmon@hethmon.com Email: phethmon@hethmon.com
Robert McMurray Robert McMurray
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052
USA
Email: robmcm@microsoft.com Email: robmcm@microsoft.com
 End of changes. 97 change blocks. 
285 lines changed or deleted 272 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/