Folks, some comments on the FTP HOST draft....
Section 3:
Server-FTP processes SHOULD treat a situation where the HOST command
is issued after the user has been authenticated 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.
Surely the first SHOULD has to be a MUST. Otherwise we have a situation
where, upon receipt of a valid HOST, some server implementations will
implicitly REIN and clear AUTH/USER/ACCT and some will not. That would be
an interoperability nightmare.
Section 3.2:
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
connection is established. This reply code is used deliberately in
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.
I'm a little concerned that this presents the "wrapper" to be a lot more
lightweight than it actually will need to be. Such a wrapper will need to
stay in the session in order to monitor for future HOST commands (which
presumably will not be understood by the [RFC0959] compliant servers) and
implicitly close and reopen a new session (or issue a REIN). If the
session between the client and real FTP server is AUTH protected then this
may be impossible.
If we really do allow for such a lightweight wrapper, then this draft
needs to mention that there is a perfectly expected mode of operation for
a client where a FEAT command may initially return HOST and an initial
HOST may indeed work - but after that - all bets are off.
I suggest that either the "wrapper" concept is dropped from the document
altogether, or a fuller description of what a wrapper might be expected to
do (and - more importantly, how a client may need to be written to allow
for one to be there) is included.
Section 3.2.2:
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
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
the AUTH and ADAT commands to negotiate the security mechanism and
certificate with the server-PI ...
"to negotiate the security mechanism and certificate"
should be
"to negotiate the security mechanism and relevant authentication token(s)"
(RFC2228 is not dependent on 'certificates')
Section 4:
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.
The "strong method of encryption" is a bit vague. Are we suggesting
something like TLS? In which case it won't work - as the HOST precedes
the AUTH. Or are we suggesting some mutually shared secret between the
client and the server for the parameter to the HOST command - somehow
bootstrapped by some unspecified mechanism? (or are we simply assuming
such environments would be expected to be running over a VPN anyway?)
I don't think we can publish this paragraph without being more explicit
about what this really means.
Server implementations SHOULD reset the security environment when a
HOST command is sent after a user has logged in.
I repeat my initial point - this has to be a MUST - otherwise the client
has no idea what the state of a session is after the HOST is processed.
In the case of RFC4217, this is crucial - because a REIN closes the TLS
session. A client has to know if that is expected or not, this cannot be
left to a server implementation decision.
I believe that there's a good argument for stating that a HOST following a
successful initial HOST MUST be preceded by an explicit REIN, but if we
are going to let that slide, then we must be clear that a HOST always
implies an implicit REIN. (Note that RFC4217 has some words about the
REIN response being transmitted on the protected channel prior to the
dropping of the TLS session, it is precisely due to nuances like this,
that I fee the REIN should be explicit - otherwise a similar statement
would need to be made about the response to the HOST)
Finally, I would like some mention of the linkage (or more importantly,
lack of mandated linkage) between the identity returned in an X.509
certificate (in the case of RFC4217) and the parameter to the HOST command
at the protocol specification level. A pointer to the first paragraph of
section 15.1.1 of [RFC4217] would be fine....
Although it is entirely an implementation decision, it is
recommended that certificates used for server authentication of the
TLS session contain the server identification information in a
similar manner to those used for http servers (see [RFC-2818])
Paul.
--
Paul Ford-Hutchinson CISSP - Tivoli Security Consultant
IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU
IBM Certified Deployment Professional - Tivoli Compliance Insight Manager
V8.5
Tel +44 (0)7500 078379 (internal: 37269105)
From:
The IESG <iesg-secretary(_at_)ietf(_dot_)org>
To:
IETF-Announce <ietf-announce(_at_)ietf(_dot_)org>
Cc:
ftpext(_at_)ietf(_dot_)org
Date:
16/06/2011 14:06
Subject:
[ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer
Protocol HOST Command for Virtual Hosts) to Proposed Standard
Sent by:
ftpext-bounces(_at_)ietf(_dot_)org
The IESG has received a request from the FTP Extensions, 2nd edition WG
(ftpext2) to consider the following document:
- 'File Transfer Protocol HOST Command for Virtual Hosts'
<draft-ietf-ftpext2-hosts-02.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2011-06-30. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
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.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ftpext2-hosts/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
ftpext mailing list
ftpext(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ftpext
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf