draft-ietf-ftpext2-hosts-02.txt   draft-ietf-ftpext2-hosts-03.txt 
FTPEXT2 Working Group P. Hethmon FTPEXT2 Working Group P. Hethmon
Internet-Draft Hethmon Brothers Internet-Draft Hethmon Brothers
Updates: 959 (if approved) R. McMurray Updates: 959 (if approved) R. McMurray
Intended status: Standards Track Microsoft Corporation Intended status: Standards Track Microsoft Corporation
Expires: August 29, 2011 February 25, 2011 Expires: December 30, 2011 June 28, 2011
File Transfer Protocol HOST Command for Virtual Hosts File Transfer Protocol HOST Command for Virtual Hosts
draft-ietf-ftpext2-hosts-02 draft-ietf-ftpext2-hosts-03
Abstract Abstract
The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not
provide a way for FTP clients and servers to differentiate between provide a way for FTP clients and servers to differentiate between
multiple DNS names that are registered for a single IP address. This multiple DNS names that are registered for a single IP address. This
document defines a new FTP command that provides a mechanism for FTP document defines a new FTP command that provides a mechanism for FTP
clients and servers to identify individual virtual hosts on an FTP clients and servers to identify individual virtual hosts on an FTP
server. server.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on August 29, 2011. This Internet-Draft will expire on December 30, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3
2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Basic Tokens . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Server Replies . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Server Replies . . . . . . . . . . . . . . . . . . . . . . 4
3. The HOST command . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 9 3.2.2. User-PI usage of HOST . . . . . . . . . . . . . . . . 9
3.2.3. State Diagrams . . . . . . . . . . . . . . . . . . . . 10 3.2.3. State Diagrams . . . . . . . . . . . . . . . . . . . . 10
3.3. HOST command errors . . . . . . . . . . . . . . . . . . . 18 3.3. HOST command errors . . . . . . . . . . . . . . . . . . . 17
3.4. FEAT response for HOST command . . . . . . . . . . . . . . 19 3.4. FEAT response for HOST command . . . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . . 20 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . . 21 6.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Unworkable Alternatives . . . . . . . . . . . . . . . 21 Appendix A. Unworkable Alternatives . . . . . . . . . . . . . . . 20
A.1. Overloading the CWD command . . . . . . . . . . . . . . . 21 A.1. Overloading the CWD command . . . . . . . . . . . . . . . 21
A.2. Overloading the ACCT command . . . . . . . . . . . . . . . 22 A.2. Overloading the ACCT command . . . . . . . . . . . . . . . 21
A.3. Overloading the USER command . . . . . . . . . . . . . . . 22 A.3. Overloading the USER command . . . . . . . . . . . . . . . 22
A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 23 A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 more entity, but in reality shares its physical resources with one or 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
skipping to change at page 5, line 13 skipping to change at page 5, line 13
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 MUST treat a situation where the HOST command is
issued more than once before the user has been authenticated as
though a REIN command was sent before each HOST command, and then
reset the user-PI to the state that existed after the TCP connection
was first established and return the appropriate reply for the HOST
command.
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 by using one of the
following two behaviors: following two behaviors:
a. Treat the late HOST command as an erroneous sequence of commands a. Treat the late HOST command as an erroneous sequence of 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.
skipping to change at page 8, line 23 skipping to change at page 8, line 23
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, changing authentication schemes and/or username
and password lists, to making much more elaborate state changes, as and password lists, or making much more elaborate state changes -
necessary. such as creating isolated environments for each FTP session.
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 the that is used in the initial "welcome" message that is sent after the
connection is established. This reply code is used deliberately in connection is established. This reply code is used deliberately 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 [RFC0959] in the appropriate server that is compliant with [RFC0959] in the appropriate
environment 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
skipping to change at page 9, line 24 skipping to change at page 9, line 24
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
If a user-PI sends an additional HOST command before attempting to
authenticate the user, a server-FTP process that conforms to this
specification MUST treat the additional HOST command as though a REIN
command was sent, and reset the user-PI to the state that existed
after the TCP connection was first established. For example, if a
user specifies the wrong virtual host by mistake, sending a
subsequent HOST command will rectify the error. The following
example illustrates what the login sequence might look like when the
HOST command is sent twice before a user has been authenticated:
C> HOST foo.example.com
S> 220 Host accepted
C> HOST bar.example.com
S> 220 Host accepted
C> USER foo
S> 331 Password required
C> PASS bar
S> 230 User logged in
The HOST command can be used in combination with the ACCT command to The HOST command can be used in combination with the ACCT command to
differentiate between a user's various accounts on a specific virtual differentiate between a user's various accounts on a specific virtual
host. In this scenario, the user-PI sends a HOST command which the host. In this scenario, the user-PI sends a HOST command which the
server-PI uses to route activity to the correct virtual host; the server-PI uses to route activity to the correct virtual host; the
user-PI sends credentials using the USER and PASS commands which the user-PI sends credentials using the USER and PASS commands which the
server-PI validates; then, the user-PI sends an ACCT command to server-PI validates; then, the user-PI sends 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, with the series of client commands that specify both a HOST and ACCT, with the
server responses omitted for brevity: server responses omitted for brevity:
skipping to change at page 11, line 14 skipping to change at page 11, line 17
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 |-----------------
+---+ +---+ | +---+ +---+ |
| | | | | |
2,500,502 | | 4,501,503,504 | 2,500,502 | | 4,501,503,504 |
-------------- ------------ | -------------- ----------- |
| | | | | V
V 1 | V V 1 | +---+
+---+ USER +---+-------------->+---+ +---+ USER +---+-------------->| E |
| |---------->| W | 2 | | E | | |---------->| W | 2 | +---+
+---+ +---+------ ----->+---+ +---+ +---+------- | ^
| | | | | | | | | |
3 | | 4,5 | | | 3 | | 4,5 | | |
-------------- ----- | | | -------------- ----- | | |
| | | | | | | | | |
| ---------- | | -------------------
| 1| | | | | 1| | | |
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 |
| B |---------->| W |----------------- | | B |---------->| W |----------------- |
+---+ +---+ | | +---+ +---+ | |
| | | | | | | |
2,500,502 | | 4,501,503,504 | | 2,500,502 | | 4,501,503,504 | |
-------------- ------------ | | -------------- ----------- | |
| | | | | | V |
V 1 | V | V 1 | +---+ |
+---+ USER +---+-------------->+---+ | +---+ USER +---+-------------->| E | |
| |---------->| W | 2 | | E | | | |---------->| W | 2 | +---+ |
+---+ +---+------ ----->+---+ | +---+ +---+------- | ^ |
| | | | | | | | | | | |
3 | | 4,5 | | | | 3 | | 4,5 | | | |
-------------- ----- | | | | -------------- ------ | | | |
| | | | | | | | | | | |
| ---------- | | | ------------------- |
| | | | | | | 1| | | | |
| 1| | | | | V | | ------>+---+ HOST |
V | | ------->+---+ HOST | +---+ 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.
skipping to change at page 15, line 10 skipping to change at page 15, line 10
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 |
+-------------- ------------- | -------------- ------------- |
| | | | | |
V | | V | |
+---+ AUTH +---+ 4,5 | | +---+ AUTH +---+ 4,5 | |
| |---------->| W |----------->| | | |---------->| W |----------->| |
+---+ +---+ | | +---+ +---+ | |
234 | | | | 334 | | | |
--------- | 334 | | -------------- | | |
| | | | | 234 | | |
---------------|------- | | | ------------ | |
V | 4,5 | |
+---+ | ADAT +---+----------->| |
| |---------->| W | 335 | |
+---+ | +---+----- | |
^ | | | | |
| | | | | | | | | | | |
V | V 335 | | | ----------------------- | |
+---+ | ADAT +---+----- | |
| |---------->| W | 4,5 | |
+---+ | +---+----------->| |
| | | | | | | |
---- 235| | | ---- 235 | | |
| -------------- | | | -------------- | |
| | | | | | | V
V V 1 | V V V 1 | +---+
+---+ USER +---+--------------->+---+ +---+ USER +---+--------------->| E |
| |---------->| W | 2 | | E | | |---------->| W | 2 | +---+
+---+ +---+------- ----->+---+ +---+ +---+------- | ^
| | | | | | | | | |
3 | | 4,5 | | | 3 | | 4,5 | | |
-------------- ------ | | | -------------- ------ | | |
| | | | | | | | | |
| ----------- | | --------------------
| 1| | | | | 1| | | |
V | | ------->+---+ V | | ------->+---+
+---+ PASS +---+ 2 | | | S | +---+ PASS +---+ 2 | | | S |
| |---------->| W |--------------->+---+ | |---------->| W |--------------->+---+
+---+ +---+ | | +---+ +---+ | |
| | | | | |
|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 when diagram in Figure 5 shows a typical sequence of flow of control when
HOST is used with the AUTH and ADAT commands to log in to an FTP HOST is used with the AUTH and ADAT commands to log in to an FTP
virtual host and ACCT is used to specify an account. virtual host and ACCT is used to specify an account.
skipping to change at page 17, line 16 skipping to change at page 16, line 23
| 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 | |
| |---------->| W |------------>| | | |---------->| W |------------>| |
+---+ +---+ | | +---+ +---+ | |
234 | | | | 334 | | | |
--------- | 334 | | -------------- | | |
| | | | | 234 | | |
---------------|------- | | | ------------ | |
V | 4,5 | |
+---+ | ADAT +---+------------>| |
| |---------->| W | 335 | |
+---+ | +---+----- | |
^ | | | | |
| | | | | | | | | | | |
V | V 335 | | | ----------------------- | |
+---+ | ADAT +---+----- | |
| |---------->| W | 4,5 | |
+---+ | +---+------------>| |
| | | | | | | |
---- 235| | | ---- 235| | |
| -------------- | | | -------------- | |
| | | | | | | |
V V 1 | V V V 1 | V
+---+ USER +---+--------------->+---+ +---+ USER +---+--------------->+---+
| |---------->| W | 2 ----->| E | | |---------->| W | 2 ----->| E |
+---+ +---+------- | --->+---+ +---+ +---+------- | --->+---+
| | | | | | | | | | | |
3 | | 4,5 | | | | 3 | | 4,5 | | | |
skipping to change at page 19, line 27 skipping to change at page 18, line 37
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 confidentiality 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.
Server implementations SHOULD reset the security environment when a As discussed in section 3 of this document, a server implementation
HOST command is sent after a user has logged in. This allows for MAY treat a HOST command that was sent after a user has been
individual authentication environments for each virtual host on an authenticated as though a REIN command was sent. In this scenario,
FTP server. For example, a virtual host "foo.example.com" on an FTP the server implementation SHOULD reset the authentication
environment, as that would allow for segregation between the security
environments for each virtual host on an FTP server. The
implementation details for security environments may vary greatly
based on the requirements of each server implementation and operating
system, and those details are outside the scope of the protocol
itself. 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 the virtual servers to
to behave independently. appear to behave independently from a client perspective, while the
actual server implementation details are irrelevant at the protocol
level.
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]:
+------+---------+-------------+------+------+----------------------+ +------+---------+-------------+------+------+----------------------+
 End of changes. 26 change blocks. 
94 lines changed or deleted 131 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/