Subject: Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 24 Jun 2011 19:52:30 +0300

Hello,

This document is well written; I'm strongly for its publication on 
Standards Track.  I have an only remark.  This document doesn't seem to 
mention what is the behavior of the server if HOST command is sent after 
one HOST has already been sent.  Eg.

C> HOST example.com
S> 220 Host OK
C> USER foo
S> 331 Specify password
C> PASS bar
S> 230 Logged in
C> HOST example.org
S> ????

I suppose the server may treat this as REIN and then switching to 
specified host, if the user is authenticated, and just switch to such 
host if the user isn't already logged in.  Another option is sending 503 
reply, as invalid sequence of commands.

Thanks,
Mykyta Yevstifeyev

16.06.2011 16:05, The IESG wrote:
> 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
>
> [ . . . ]

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 25 Jun 2011 07:32:36 +0300

24.06.2011 22:08, Robert McMurray wrote:
> Thanks, Mykyta.
>
> Section 3.3 already addresses that scenario in the second paragraph - and the server behaviors are exactly what you were suggesting:
>
>     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
>     following:
>
>     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.
OK, and if HOST is sent for the second time when the user hasn't got 
authenticated, eg.

S> 220 Server ready
C> HOST example.com
S> 220 HOST OK
C> HOST example.org
S> ???

I suppose it may be 503 reply or switching to the identified host with 
220 reply.  This situation isn't mentioned in your document.

Mykyta Yevstifeyev
> Thanks again!
>
> Robert McMurray
>
> -----Original Message-----
> From: Mykyta Yevstifeyev [mailto:[email-masked]]
> Sent: Friday, June 24, 2011 9:53 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [ftpext] Last Call:<draft-ietf-ftpext2-hosts-02.txt>  (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard
>
> Hello,
>
> This document is well written; I'm strongly for its publication on Standards Track.  I have an only remark.  This document doesn't seem to mention what is the behavior of the server if HOST command is sent after one HOST has already been sent.  Eg.
>
> C>  HOST example.com
> S>  220 Host OK
> C>  USER foo
> S>  331 Specify password
> C>  PASS bar
> S>  230 Logged in
> C>  HOST example.org
> S>  ????
>
> I suppose the server may treat this as REIN and then switching to specified host, if the user is authenticated, and just switch to such host if the user isn't already logged in.  Another option is sending 503 reply, as invalid sequence of commands.
>
> Thanks,
> Mykyta Yevstifeyev
>
>
>

---

From: Robert McMurray <[email-masked]>
Date: Fri, 24 Jun 2011 19:08:18 +0000

Thanks, Mykyta.

Thanks again!

Robert McMurray

-----Original Message-----
From: Mykyta Yevstifeyev [mailto:[email-masked]] 
Sent: Friday, June 24, 2011 9:53 AM
To: [email-masked]; [email-masked]
Subject: Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard

Hello,

C> HOST example.com
S> 220 Host OK
C> USER foo
S> 331 Specify password
C> PASS bar
S> 230 Logged in
C> HOST example.org
S> ????

Thanks,
Mykyta Yevstifeyev

---

From: Robert McMurray <[email-masked]>
Date: Mon, 27 Jun 2011 17:24:53 +0000

Thanks Mykyta,

Ah, now I see your point - that's a great catch, and I will add a section to a new version of the draft that I am working on for other IETF comments.

Thanks again!

-----Original Message-----
From: Mykyta Yevstifeyev [mailto:[email-masked]] 
Sent: Friday, June 24, 2011 9:33 PM
To: Robert McMurray
Cc: [email-masked]; [email-masked]
Subject: Re: [ftpext] Last Call: <draft-ietf-ftpext2-hosts-02.txt> (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard

S> 220 Server ready
C> HOST example.com
S> 220 HOST OK
C> HOST example.org
S> ???

Mykyta Yevstifeyev

---

From: Paul Ford-Hutchinson <[email-masked]>
Date: Mon, 27 Jun 2011 21:38:54 +0100

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 <[email-masked]>
To:
IETF-Announce <[email-masked]>
Cc:
[email-masked]
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:
[email-masked]

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
[email-masked] mailing lists by 2011-06-30. Exceptionally, comments may be
sent to [email-masked] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ftpext

---

From: Robert McMurray <[email-masked]>
Date: Wed, 29 Jun 2011 02:04:16 +0000

Thanks, Paul.

I believe that I have addressed all of your comments with the following actions:

--------------------
Section 3:
--------------------

> 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.

Agreed - I changed that verbiage.

--------------------
Section 3.2:
--------------------

> I suggest that either the "wrapper" concept is
> dropped from the document altogether...

I removed that verbiage. (That was detail for a possible server implementation anyway.)

--------------------
Section 3.2.2:
--------------------

> should be "to negotiate the security mechanism
> and relevant authentication token(s)"

I changed that as well.

--------------------
Section 4
--------------------

> The "strong method of encryption" is a bit
> vague. I don't think we can publish this
> paragraph without being more explicit about
> what this really means. 

I removed that paragraph. By way of explanation, this was in reference a server implementation detail that in hindsight probably shouldn't be in this document. More specifically, some FTP servers and clients support Implicit FTPS, but that is not defined by RFC and lately considered deprecated, so it's best to just remove that information.

> I repeat my initial point - this has to be a MUST.

Agreed - I changed that verbiage.

> I would like some mention of the linkage
> between the identity returned in an X.509
> certificate and the parameter to the HOST
> command at the protocol specification level.

I have attached a new version of the draft that contains suggested wording for this request, with all of the other changes that I have addressed as well.

Thanks!

Robert