Re: [ftpext] Review of FTP HOSTS draft

Paul Ford-Hutchinson <paulfordh@uk.ibm.com> Mon, 27 February 2012 12:42 UTC

Return-Path: <paulfordh@uk.ibm.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE14E21F86F1 for <ftpext@ietfa.amsl.com>; Mon, 27 Feb 2012 04:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5vitBak6Tsg for <ftpext@ietfa.amsl.com>; Mon, 27 Feb 2012 04:42:54 -0800 (PST)
Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE4921F86A8 for <ftpext@ietf.org>; Mon, 27 Feb 2012 04:42:49 -0800 (PST)
Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <ftpext@ietf.org> from <paulfordh@uk.ibm.com>; Mon, 27 Feb 2012 12:42:45 -0000
Received: from d06nrmr1707.portsmouth.uk.ibm.com (9.149.39.225) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 27 Feb 2012 12:42:43 -0000
Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q1RCggPb2695322 for <ftpext@ietf.org>; Mon, 27 Feb 2012 12:42:42 GMT
Received: from d06av09.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q1RCgglY012327 for <ftpext@ietf.org>; Mon, 27 Feb 2012 05:42:42 -0700
Received: from d06ml006.portsmouth.uk.ibm.com (d06ml006.portsmouth.uk.ibm.com [9.149.76.132]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q1RCggTf012324 for <ftpext@ietf.org>; Mon, 27 Feb 2012 05:42:42 -0700
In-Reply-To: <CANqTPeiid++rpn1H8yELmeQhG=XEwt8q5uTCiuifw82OOu8xjg@mail.gmail.com>
References: <CANqTPeiid++rpn1H8yELmeQhG=XEwt8q5uTCiuifw82OOu8xjg@mail.gmail.com>
To: ftpext@ietf.org
MIME-Version: 1.0
X-KeepSent: 9010AA09:3E3DBA43-802579B1:0042EAD0; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
From: Paul Ford-Hutchinson <paulfordh@uk.ibm.com>
Message-ID: <OF9010AA09.3E3DBA43-ON802579B1.0042EAD0-802579B1.0045D2EB@uk.ibm.com>
Date: Mon, 27 Feb 2012 12:42:35 +0000
X-MIMETrack: Serialize by Router on D06ML006/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 27/02/2012 12:42:36, Serialize complete at 27/02/2012 12:42:36
Content-Type: multipart/alternative; boundary="=_alternative 0045BD86802579B1_="
x-cbid: 12022712-0342-0000-0000-000001015032
Subject: Re: [ftpext] Review of FTP HOSTS draft
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2012 12:42:57 -0000

Some comments ...

ftpext-bounces@ietf.org 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.
> 
> 
> 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.)

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.

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

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

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

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

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

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

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

Cheers,
Paul

> _______________________________________________
> ftpext mailing list
> ftpext@ietf.org
> https://www.ietf.org/mailman/listinfo/ftpext
>