Subject: [ftpext] Review of FTP HOSTS draft

From: Anthony Bryan <[email-masked]>
Date: Fri, 24 Feb 2012 18:20:48 -0500

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 <[email-masked]>
Date: Sat, Feb 11, 2012 at 8:13 AM
Subject: Re: Request to review FTP HOSTS draft
To: Anthony Bryan <[email-masked]>

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.

---

From: Paul Ford-Hutchinson <[email-masked]>
Date: Mon, 27 Feb 2012 12:42:35 +0000

Some comments ...

> works similarly to the HOST command.)

This seems a reasonable statement, however I would observe that [RFC4217] 
is pretty much silent on the issue of trust entirely.

We have three options:

a) HOST and TLS extension MUST match
b) HOST and TLS extension SHOULD match
c) There is no documented linkage between HOST and TLS extension

(b) doesn't add any value - so let's not do that.
(a) has an issue in that any linkage would be pre-supposing that the 
payload for the two fields would be in some way mappable to each other. 
Given how FTP server implementations and SSL stack implementations have 
seemed to evolve almost at odds with each other, this might actually be 
pretty tricky to do.

I'm happy to have this link explicitly stated as long as we are sure that 
the meaning of the fields is exactly the same and the payloads of each are 
directly linkable.

> Minor: You should have references for terms like user-PI/server-PI the 
first

[RFC959] ?

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

> (I think MUST is more appropriate here, unless you have a good reason

I can see cases where a HOST command happens after AUTH, in which case, 
the server may happily object to the HOST altogether, or simply reject it 
should it have a parameter which doesn't match what it knows has been 
negotiated.

I can also see an interesting change to the proposed HOST command where it 
gets used without a parameter to request the hostname that the server 
thinks it is running as (perhaps one requested by the TLS extension.)

> I suggest deleting this sentence (or clarify its purpose).

It does appear that this is just explicitly restating the standard FTP 
responses.

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

Can we push for an update to RFC6125 that does include FTP and then 
reference it in here?

Cheers,
Paul

> _______________________________________________
> ftpext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ftpext
>