draft-ietf-ftpext2-hosts-03.txt   draft-ietf-ftpext2-hosts-04.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: December 30, 2011 June 28, 2011 Expires: December 3, 2011 June 2011
File Transfer Protocol HOST Command for Virtual Hosts File Transfer Protocol HOST Command for Virtual Hosts
draft-ietf-ftpext2-hosts-03 draft-ietf-ftpext2-hosts-04
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 December 30, 2011. This Internet-Draft will expire on December 3, 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 . . . . . . . . . . . . . . . . . . . 17 3.3. HOST command errors . . . . . . . . . . . . . . . . . . . 16
3.4. FEAT response for HOST command . . . . . . . . . . . . . . 18 3.4. FEAT response for HOST command . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . . 19 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . . 20 6.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Unworkable Alternatives . . . . . . . . . . . . . . . 20 Appendix A. Unworkable Alternatives . . . . . . . . . . . . . . . 19
A.1. Overloading the CWD command . . . . . . . . . . . . . . . 21 A.1. Overloading the CWD command . . . . . . . . . . . . . . . 19
A.2. Overloading the ACCT command . . . . . . . . . . . . . . . 21 A.2. Overloading the ACCT command . . . . . . . . . . . . . . . 20
A.3. Overloading the USER command . . . . . . . . . . . . . . . 22 A.3. Overloading the USER command . . . . . . . . . . . . . . . 21
A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 23 A.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 23 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 10 skipping to change at page 5, line 10
can be of the multi-line format described in [RFC0959]. 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 MUST 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 that conform to this specification MUST treat a
situation where the HOST command is issued more than once before the
user has been authenticated as though a previous HOST command was not
sent, and return the appropriate reply for the new HOST command.
Server-FTP processes MUST treat a situation where the HOST command is Server-FTP processes MUST treat a situation where the HOST command is
issued more than once before the user has been authenticated as issued after the user has been authenticated as an erroneous sequence
though a REIN command was sent before each HOST command, and then of commands and return a 503 reply.
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
is issued after the user has been authenticated by using one of the
following two behaviors:
a. Treat the late HOST command as an erroneous sequence of commands
and return a 503 reply.
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
existed after the TCP connection was first established and before
the initial user authentication and then return the appropriate
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
skipping to change at page 8, line 29 skipping to change at page 8, line 29
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, changing authentication schemes and/or username working directory, changing authentication schemes and/or username
and password lists, or making much more elaborate state changes - and password lists, or making much more elaborate state changes -
such as creating isolated environments for each FTP session. 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.
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
server that is compliant with [RFC0959] in the appropriate
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
skipping to change at page 9, line 26 skipping to change at page 9, line 22
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 If a user-PI sends an additional HOST command before attempting to
authenticate the user, a server-FTP process that conforms to this authenticate the user, a server-FTP process that conforms to this
specification MUST treat the additional HOST command as though a REIN specification MUST treat the additional HOST command as though a
command was sent, and reset the user-PI to the state that existed previous HOST command was not sent, and return the appropriate reply
after the TCP connection was first established. For example, if a for the new HOST command. For example, if a user specifies the wrong
user specifies the wrong virtual host by mistake, sending a virtual host by mistake, sending a subsequent HOST command will
subsequent HOST command will rectify the error. The following rectify the error. The following example illustrates what the login
example illustrates what the login sequence might look like when the sequence might look like when the HOST command is sent twice before a
HOST command is sent twice before a user has been authenticated: user has been authenticated:
C> HOST foo.example.com C> HOST foo.example.com
S> 220 Host accepted S> 220 Host accepted
C> HOST bar.example.com C> HOST bar.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
skipping to change at page 10, line 15 skipping to change at page 10, line 15
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 this ADAT commands that are discussed in [RFC2228] and [RFC4217]. In this
scenario, the user-PI sends a HOST command which the server-PI uses scenario, the user-PI sends a HOST command which the server-PI uses
to route activity to the correct virtual host, then the user-PI uses to route activity to the correct virtual host, then the user-PI uses
the AUTH and ADAT commands to negotiate the security mechanism and the AUTH and ADAT commands to negotiate the security mechanism and
certificate with the server-PI, then the user-PI sends user relevant authentication token(s) with the server-PI, then the user-PI
credentials using the USER and PASS commands which the server-PI sends user credentials using the USER and PASS commands which the
validates. After which the user-PI MAY send an ACCT command to server-PI validates. After which the user-PI MAY send an ACCT
specify any additional account information for the server-PI command to specify any additional account information for the
implementation. The following example illustrates a sequential server-PI implementation. The following example illustrates a
series of client commands that specify both a HOST and ACCT when used sequential series of client commands that specify both a HOST and
in conjunction with the security commands that are discussed in ACCT when used in conjunction with the security commands that are
[RFC2228] and [RFC4217], with the server responses omitted for discussed in [RFC2228] and [RFC4217], with the server responses
brevity: omitted for 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
skipping to change at page 12, line 5 skipping to change at page 12, line 5
| |---------->| 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
command is sent after a user has already successfully logged in to a
virtual host with USER and PASS.
------------------------------
| |
| |
V |
+---+ HOST +---+ 1,3,5 |
| B |---------->| W |----------------- |
+---+ +---+ | |
| | | |
2,500,502 | | 4,501,503,504 | |
-------------- ----------- | |
| | V |
V 1 | +---+ |
+---+ USER +---+-------------->| E | |
| |---------->| W | 2 | +---+ |
+---+ +---+------- | ^ |
| | | | | |
3 | | 4,5 | | | |
-------------- ------ | | | |
| | | | | |
| ------------------- |
| 1| | | | |
V | | ------>+---+ HOST |
+---+ PASS +---+ 2 | | | S |--------
| |---------->| W |-------------->+---+
+---+ +---+ | |
| | |
|4,5 | |
| | --->+---+
| --------->| F |
---------------->+---+
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 2 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 |-----------------
+---+ +---+ | +---+ +---+ |
| | | | | |
2,500,502 | | 4,501,503,504 | 2,500,502 | | 4,501,503,504 |
-------------- ------------- | -------------- ------------- |
| | | | | |
skipping to change at page 13, line 45 skipping to change at page 12, 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 2: 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 the extensions that were introduced in [RFC2228], it SHOULD precede 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 3 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 15, line 51 skipping to change at page 14, line 51
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 3: 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 4 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.
+---+ 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 17, line 15 skipping to change at page 16, line 15
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 4: 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 MUST treat the
following: situation as an invalid sequence of commands and return a 503 reply.
a. Send a 503 reply for an invalid sequence of commands.
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
HOST command was sent and before the user had been authenticated,
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 been a. Ignore the HOST command and act as if a HOST command had not been
sent. A user-FTP process MAY then send a subsequent HOST command sent. A user-FTP process MAY then send a subsequent HOST command
with a different hostname. with a different hostname.
skipping to change at page 18, line 36 skipping to change at page 17, line 28
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
will need to take some care to ensure that the confidentiality of
potentially sensitive information is maintained. For example, while
hostnames may generally be assumed to be publicly available DNS
names, this may not always be the situation. Some organizations may
use private hostnames, and that information SHOULD be protected when
transmitted between the client and server by using a strong method of
encryption.
As discussed in section 3 of this document, a server implementation As discussed in section 3 of this document, a server implementation
MAY treat a HOST command that was sent after a user has been MUST treat an additional HOST command that was sent before a user has
authenticated as though a REIN command was sent. In this scenario, been authenticated as though a previous HOST command was not sent.
the server implementation SHOULD reset the authentication In this situation, the server implementation MUST reset the
environment, as that would allow for segregation between the security authentication environment, as that would allow for segregation
environments for each virtual host on an FTP server. The between the security environments for each virtual host on an FTP
implementation details for security environments may vary greatly server. The implementation details for security environments may
based on the requirements of each server implementation and operating vary greatly based on the requirements of each server implementation
system, and those details are outside the scope of the protocol and operating system, and those details are outside the scope of the
itself. For example, a virtual host "foo.example.com" on an FTP protocol itself. For example, a virtual host "foo.example.com" on an
server might use a specific username and password list, while the FTP 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 the virtual servers to the security environment is necessary for the virtual servers to
appear to behave independently from a client perspective, while the appear to behave independently from a client perspective, while the
actual server implementation details are irrelevant at the protocol actual server implementation details are irrelevant at the protocol
level. level.
Section 15.1.1 of [RFC4217] discusses the use of X.509 certificates
for server authentication. Taking the information from that document
into account, when securing FTP sessions with the security mechanisms
that are defined in [RFC4217], client implementations SHOULD verify
that the hostname they specify in the parameter for the HOST command
matches the identity that is specified in the server's X.509
certificate in order to prevent man-in-the-middle attacks.
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 and | | cmd | FEAT | description | type | conf | RFC#s/References and |
skipping to change at page 23, line 23 skipping to change at page 22, line 9
Appendix B. Acknowledgements 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" as HOST command in their Internet draft titled "Extensions to FTP" as
part of their work with the FTPEXT Working Group at the IETF. Their part of their work with the FTPEXT Working Group at the IETF. Their
work formed the basis for much of this document, and their help has work formed the basis for much of this document, and their help has
been greatly appreciated. They would also like to credit Bernhard been greatly appreciated. They would also like to credit Bernhard
Rosenkraenzer for having first suggested and described the HOST Rosenkraenzer for having first suggested and described the HOST
command. command.
Alexey Melnikov, Alfred Hoenes, John Klensin, and Joe Touch have made Several people have provided a wealth of constructive feedback about
several suggestions about earlier versions of this document; many of earlier versions of this document that have helped to shape its
their suggestions have been incorporated, and their contributions are development; many of their suggestions have been incorporated, and
gratefully acknowledged. In addition, Alec Rowell's assistance in their contributions are gratefully acknowledged. There are far too
making sections of this document more readable was invaluable. many to mention here, but authors of this document would like to
specifically thank Alexey Melnikov, Alfred Hoenes, John Klensin, Joe
Touch, Paul Ford-Hutchinson, Daniel Stenberg, Mykyta Yevstifeyev, and
Anthony Bryan for their assistance. In addition, Alec Rowell's help
in 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 Knoxville, TN 37923
USA USA
Email: phethmon@hethmon.com Email: phethmon@hethmon.com
 End of changes. 22 change blocks. 
133 lines changed or deleted 76 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/