Re: [ftpext] Review of FTP HOSTS draft

[John C Klensin <[e-mail]>]

--On Tuesday, March 13, 2012 01:24 -0400 Anthony Bryan
<[e-mail]> wrote:

>...
>>> In Section 4:
>>> 
>>>   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.
>>> 
>>> How can this verification can be achieved? Please either add
>>> the text (for example by referencing RFC 6125, I can help
>>> with wordsmithing), or add another appropriate reference
>>> here.
>> 
>> RFC6125 does not discuss FTP.  I do not think that this
>> document is a suitable place for making that linkage by the
>> back door.  (I am not saying that FTP shouldn't be in
>> RFC6125 - it probably should - but that the introduction of
>> the 'HOST' command is not the way to do it.)
> 
> we could ask Alexey what he thinks it should say, as he
> offered help with the text?
> 
> or...
> 
>> Can we push for an update to RFC6125 that does include FTP
>> and then reference it in here?
> 
> I'm not sure - asking other to do more work when this WG has
> not accomplished anything yet may step on some toes :)
> 
> perhaps filing an erratum with information to be "Held For
> Document Update"? that is, if there's a revision, it will
> include the info.

Hmm.  4217 notwithstanding, it seems to me that, if we are not
going to turn FTP into a single-channel protocol through the
back door, there is the potential, first, for the server to
which the command channel is connected to have a certificate per
HOST name (virtual host) or one certificate for the physical
host/ host farm.  The server to (or from) which the data channel
is connected may be yet a different machine, actually one
machine per command for those commands that cause data to be
transferred (PUT and GET, but also LIST and NLST, etc.).  This
can be seen as another instance of scenario (iii) in Section 7
of RFC 4217 -- a case that 4217 excludes completely.  If one
were serious about using PASV in the general case, I think HOST
effectively introduces a fourth scenario -- "virtual host/
server farm-friendly client/server data exchange" -- that looks
a lot like scenario (ii) but that has most of the nasty
properties of scenario (iii), i.e., the control connection
proceeds as in scenario (ii) but the host/address specified for
the data connection by the (command channel) server is a
function of the argument to the HOST command, not just the
properties of the server hosting the command channel.

If this fourth scenario is excluded, as RFC 4217 excludes
Scenario (iii), then the utility of HOST, as specified in this
draft, in situations where TLS security is desired goes down
considerably: if FTP virtual hosts are supported via one
server-PI (control connection server) but multiple content
servers/hosts for different collections of virtual host file
systems, HOST is not usable with per-content-server
certificates.  I'd expect that case to be common, for obvious
reasons.

That is technically known as "a mess".  It requires
significantly more FTP-specific analysis than one could put into
an erratum or try to load onto RFC 6125bis.  It can be added to
the list of reasons I've been nervous about the possibility
that, because of the serial two-stream model, an FTP HOST
command opens up problems and unintended consequences that are
much broader than those experienced with HTTP 1.1 and its HOST
command.

At a minimum, I think this document is required to include some
discussion of issues that would be encountered if the HOST
command/extension were anticipated to be used in conjunction
with the RFC 4217 TLS one.  Perhaps some of the comments above
could be used to start that discussion; feel free to use or
adapt them.

     john