Re: [ftpext] Review of FTP HOSTS draft

Robert McMurray <> Wed, 14 March 2012 05:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AABA21F8564 for <>; Tue, 13 Mar 2012 22:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.467
X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8tr3HiqkjnNs for <>; Tue, 13 Mar 2012 22:48:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6C6B321F8562 for <>; Tue, 13 Mar 2012 22:48:58 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Wed, 14 Mar 2012 05:48:59 +0000
Received: from mail101-db3 (localhost []) by (Postfix) with ESMTP id 591354A0373 for <>; Wed, 14 Mar 2012 05:48:59 +0000 (UTC)
X-SpamScore: -50
X-BigFish: VS-50(zzbb2dI9371I1b0bM542M1432N98dK4015I111aI148cM179cMzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
Received-SPF: pass (mail101-db3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail101-db3 (localhost.localdomain []) by mail101-db3 (MessageSwitch) id 1331704137587872_7065; Wed, 14 Mar 2012 05:48:57 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 81A0F100048 for <>; Wed, 14 Mar 2012 05:48:57 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 14 Mar 2012 05:48:56 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 14 Mar 2012 05:48:52 +0000
Received: from ( by ( with Microsoft SMTP Server id; Wed, 14 Mar 2012 05:48:53 +0000
Received: from mail183-va3 (localhost []) by (Postfix) with ESMTP id B7C58260165 for <>; Wed, 14 Mar 2012 05:48:53 +0000 (UTC)
Received: from mail183-va3 (localhost.localdomain []) by mail183-va3 (MessageSwitch) id 1331704128334377_11875; Wed, 14 Mar 2012 05:48:48 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 4B60E100134; Wed, 14 Mar 2012 05:48:48 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 14 Mar 2012 05:48:47 +0000
Received: from ([]) by ([]) with mapi id 14.16.0123.000; Wed, 14 Mar 2012 05:48:45 +0000
From: Robert McMurray <>
To: Anthony Bryan <>, Paul Ford-Hutchinson <>, "" <>
Thread-Topic: [ftpext] Review of FTP HOSTS draft
Thread-Index: AQHNASMcg4ZtTdf/DkyeggS/LEFc05ZpSDMw
Date: Wed, 14 Mar 2012 05:48:44 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [ftpext] Review of FTP HOSTS draft
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Mar 2012 05:49:00 -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 [] 
Sent: Monday, March 12, 2012 10:24 PM
To: Paul Ford-Hutchinson
Subject: Re: [ftpext] Review of FTP HOSTS draft

Paul, thanks for reading & reviewing the review!

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


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


> 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 [ ]
  )) Easier, More Reliable, Self Healing Downloads