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@xxxxxxxx> |
| To: | IETF-Announce <ietf-announce@xxxxxxxx> |
| Cc: | ftpext@xxxxxxxx |
| 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@xxxxxxxx |
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@xxxxxxxx mailing lists by 2011-06-30. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ftpext
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf