[ftpext] Review of FTP HOSTS draft

[Anthony Bryan <[e-mail]>]

Alexey Melnikov was kind enough to review this draft but was not on
the list so I am forwarding it for him.

we need to hear discussion on list about it.

thanks!


---------- Forwarded message ----------
From: Alexey Melnikov <[e-mail]>
Date: Sat, Feb 11, 2012 at 8:13 AM
Subject: Re: Request to review FTP HOSTS draft
To: Anthony Bryan <[e-mail]>


The document describes how HOST interacts with X.509 certificate checking.
But it should also talk about how the HOST command should interact with
the TLS extension for server name indication (a TLS extension which
works similarly to the HOST command.)

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.

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)

In Section 3.2.3:

  When the HOST command is used in combination with the FTP security
  extensions that were introduced in [RFC2228], it SHOULD precede the

Why the SHOULD and not a MUST like for the USER command?
I.e. what are the possible cases when it would be Ok to violate the SHOULD?
(I think MUST is more appropriate here, unless you have a good reason
to have a SHOULD.)

  security handshake.  This allows both user-PI and server-FTP
  processes to map an FTP HOST to security data appropriately.  The
  state diagram in Figure 3 shows a typical sequence of flow of control
  when HOST is used with the AUTH and ADAT commands that are discussed
  in [RFC2228].


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


3.4.  FEAT response for HOST command

  When replying to the FEAT command [RFC2389], a server-FTP process
  that supports the HOST command MUST include a line containing the
  single word "HOST".  This word is case insensitive, and MAY be sent
  in any mixture of upper or lower case, however it SHOULD be sent in

The SHOULD without any explanation is either pointless or dangerous,
because it doesn't help interoperability. Note that something like compatibility
with deployed software is an Ok reason for the SHOULD, but that
needs to be explained.

  upper case.  That is, the response SHOULD be:

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.