Re: [ftpext] Review of FTP HOSTS draft

[Anthony Bryan <[e-mail]>]

Paul, thanks for reading & reviewing the review!

On Mon, Feb 27, 2012 at 7:42 AM, Paul Ford-Hutchinson
<[e-mail]> wrote:
>
> Some comments ...
>
> [e-mail] 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