Subject: Re: [ftpext] Review of FTP HOSTS draft

From: Anthony Bryan <[email-masked]>
Date: Tue, 13 Mar 2012 01:24:03 -0400

Paul, thanks for reading & reviewing the review!

On Mon, Feb 27, 2012 at 7:42 AM, Paul Ford-Hutchinson
<[email-masked]> wrote:
>
> Some comments ...
>
> [email-masked] wrote on 24/02/2012 23:20:48:
>
>
>
>> Alexey Melnikov was kind enough to review this draft but was not on
>> the list so I am forwarding it for him.
>>
>> 1.  Introduction
>>
>>   This means that different virtual hosts cannot offer different
>>   virtual file systems to clients, nor can they offer different
>>   authentication systems.  Any scheme to overcome this issue needs to
>>   indicate not only the destination IP address, but also the virtual
>>   host name that is associated with the desired virtual FTP server.
>>   Typical user-FTP processes currently use hostnames to perform
>>   hostname to IP address resolution and then ignore hostnames for the
>>   rest of the FTP session, therefore any mechanism to overcome this
>>   issue would require modifications to the user-PI and server-PI.
>>
>> Minor: You should have references for terms like user-PI/server-PI the
>> first
>> time you reference them.
>
> [RFC959] ?

yes

>> In 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
>>   relevant authentication token(s) with the server-PI, then the user-PI
>>   sends user credentials using the USER and PASS commands which the
>>   server-PI validates.  After which the user-PI MAY send an ACCT
>>   command to specify any additional account information for the
>>   server-PI implementation.  The following example illustrates a
>>   sequential series of client commands that specify both a HOST and
>>   ACCT when used in conjunction with the security commands that are
>>   discussed in [RFC2228] and [RFC4217], with the server responses
>>   omitted for brevity:
>>
>>        C> HOST ftp.example.com
>>        C> AUTH <mechanism-name>
>>        C> ADAT <base64data>
>>        C> USER foo
>>        C> PASS bar
>>        C> ACCT project1
>>
>> Is USER/PASS actually required after ADAT? (Just asking)
>
> according to the various RFCs; ADAT, USER and PASS are all optional.  This
> is just an elaboration of what was already in [RFC2228].

maybe that is worth clarifying? (as below)

>> 3.3.  HOST command errors
>>
>>   The server-PI SHOULD reply with a 500 or 502 reply if the HOST
>>   command is unrecognized or unimplemented.
>>
>> This requirement is strange: you are either making a requirement on an
>> implementation which doesn't support this specification (and thus you
>> can't
>> do that), or you are saying that an implementation can recognize but
>> not implement the HOST command which seems pointless.
>> I suggest deleting this sentence (or clarify its purpose).
>
> It does appear that this is just explicitly restating the standard FTP
> responses.

yes, perhaps taking a cue from RFC 3659 would be good (some of my
drafts need this change as well):

"Where the command cannot be correctly parsed, a 500 or 501 reply
should be sent, as specified in RFC 959."
...

7.2.1. Error Responses to MLSx commands

   Many of the 4xy and 5xy responses defined in section 4.2 of STD 9,
   RFC 959 are possible in response to the MLST and MLSD commands.
   In particular, syntax errors can generate 500 or 501 replies.  Giving
   a pathname that exists but is not a directory as the argument to a
   MLSD command generates a 501 reply.  Giving a name that does not
   exist, or for which access permission (to obtain directory
   information as requested) is not granted will elicit a 550 reply.
   Other replies (530, 553, 503, 504, and any of the 4xy replies) are
   also possible in appropriate circumstances.

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

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Mar 2012 03:25:28 -0400

--On Tuesday, March 13, 2012 01:24 -0400 Anthony Bryan
<[email-masked]> 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

---

From: Robert McMurray <[email-masked]>
Date: Wed, 14 Mar 2012 05:48:44 +0000

Thanks, Anthony.

As an FYI - I've been watching the WG discussions about the HOST draft, but I probably won't have a chance to offer up a rewritten draft for at least a few weeks due to pressing work-related priorities. (We all have to pay the bills somehow.)

Thanks again,
Robert McMurray

-----Original Message-----
From: Anthony Bryan [mailto:[email-masked]] 
Sent: Monday, March 12, 2012 10:24 PM
To: Paul Ford-Hutchinson
Cc: [email-masked]
Subject: Re: [ftpext] Review of FTP HOSTS draft

On Mon, Feb 27, 2012 at 7:42 AM, Paul Ford-Hutchinson <[email-masked]> wrote:
>> Minor: You should have references for terms like user-PI/server-PI 
>> the first time you reference them.
>
> [RFC959] ?

yes

> according to the various RFCs; ADAT, USER and PASS are all optional.  
> This is just an elaboration of what was already in [RFC2228].

>> This requirement is strange: you are either making a requirement on 
>> an implementation which doesn't support this specification (and thus 
>> you can't do that), or you are saying that an implementation can 
>> recognize but not implement the HOST command which seems pointless.

yes, perhaps taking a cue from RFC 3659 would be good (some of my drafts need this change as well):

"Where the command cannot be correctly parsed, a 500 or 501 reply should be sent, as specified in RFC 959."
...

> 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 

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.