Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard
Paul Ford-Hutchinson <paulfordh@uk.ibm.com> Mon, 27 June 2011 20:39 UTC
Return-Path: <paulfordh@uk.ibm.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C891611E817D; Mon, 27 Jun 2011 13:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Te0Z71JTLQrX; Mon, 27 Jun 2011 13:39:07 -0700 (PDT)
Received: from mtagate1.uk.ibm.com (mtagate1.uk.ibm.com [194.196.100.161]) by ietfa.amsl.com (Postfix) with ESMTP id CBB6211E80D5; Mon, 27 Jun 2011 13:39:06 -0700 (PDT)
Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p5RKd4HB025532; Mon, 27 Jun 2011 20:39:04 GMT
Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p5RKcvw31912958; Mon, 27 Jun 2011 21:39:04 +0100
Received: from d06av09.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p5RKcvdr030572; Mon, 27 Jun 2011 14:38:57 -0600
Received: from d06ml069.portsmouth.uk.ibm.com (d06ml069.portsmouth.uk.ibm.com [9.149.38.218]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p5RKcvHR030569; Mon, 27 Jun 2011 14:38:57 -0600
In-Reply-To: <20110616130503.4854.51928.idtracker@ietfa.amsl.com>
References: <20110616130503.4854.51928.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
MIME-Version: 1.0
X-KeepSent: A9997572:88B3CCF9-802578BC:006F9F84; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
From: Paul Ford-Hutchinson <paulfordh@uk.ibm.com>
Message-ID: <OFA9997572.88B3CCF9-ON802578BC.006F9F84-802578BC.00716B95@uk.ibm.com>
Date: Mon, 27 Jun 2011 21:38:54 +0100
X-MIMETrack: Serialize by Router on D06ML069/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 27/06/2011 21:38:56, Serialize complete at 27/06/2011 21:38:56
Content-Type: multipart/alternative; boundary="=_alternative 00716646802578BC_="
Cc: ftpext@ietf.org
Subject: Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2011 20:39:08 -0000
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@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Cc: ftpext@ietf.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@ietf.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@ietf.org mailing lists by 2011-06-30. Exceptionally, comments may be sent to iesg@ietf.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@ietf.org https://www.ietf.org/mailman/listinfo/ftpext
- [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.… The IESG
- Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts… Mykyta Yevstifeyev
- Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts… Robert McMurray
- Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts… Mykyta Yevstifeyev
- Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts… Robert McMurray
- Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts… Paul Ford-Hutchinson
- Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts… Robert McMurray