[secdir] SECDIR review of draft-ietf-ftpext2-hosts-02

<kathleen.moriarty@emc.com> Fri, 24 June 2011 16:04 UTC

Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4DFB111E80E9; Fri, 24 Jun 2011 09:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8UZXbsaShB7b; Fri, 24 Jun 2011 09:04:12 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com []) by ietfa.amsl.com (Postfix) with ESMTP id 317BB11E80E3; Fri, 24 Jun 2011 09:04:11 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5OG4AfA003537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2011 12:04:10 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com []) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 24 Jun 2011 12:03:52 -0400
Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5OG2GdT025061; Fri, 24 Jun 2011 12:02:17 -0400
Received: from mx06a.corp.emc.com ([]) by mxhub29.corp.emc.com ([]) with mapi; Fri, 24 Jun 2011 12:02:14 -0400
From: <kathleen.moriarty@emc.com>
To: <secdir@ietf.org>, <draft-ietf-ftpext2-hosts.all@tools.ietf.org>, <iesg@ietf.org>
Date: Fri, 24 Jun 2011 12:02:13 -0400
Thread-Topic: SECDIR review of draft-ietf-ftpext2-hosts-02
Thread-Index: AcwyiBUFO2skqoQCSLqk+KSpXVMV4Q==
Message-ID: <AE31510960917D478171C79369B660FA0E0325300F@MX06A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: phethmon@hethmon.com, robmcm@microsoft.com
Subject: [secdir] SECDIR review of draft-ietf-ftpext2-hosts-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2011 16:04:13 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary:  The document requires more information in the security considerations section.

Section 3.2:

In terms of the types of changes that may be made, it does state 'more elaborate changes' may be made depending on the environment.  However, for security and the developers reading the specification, I think it would be best to include the high end of the spectrum here and include isolation as one of the explicitly stated examples as the scenario may be used in hosted environments.

Upon receiving the HOST command, before authenticating the user-PI, a
   server-FTP process SHOULD validate that the hostname given represents
   a valid virtual host for that server, and, if it is valid, establish
   the appropriate environment for that virtual host.  The resultant
   actions needed to create that environment are not specified here, and
   may range from doing nothing at all, to performing a simple change of
   working directory, to changing authentication schemes and/or username
   and password lists, to making much more elaborate state changes, as

Section 4: Security Considerations

Please replace the term Confidentiality where you have listed "integrity" in the opening sentence as the protection of privacy related information is described through confidentiality.  The integrity and confidentiality of the data on the servers are both potentially important, but this opening sentence is in context of login parameters.

The second paragraph does address the authentication between virtual hosts, which is good.  I think it is also important to ensure readers are aware of possible concerns with segregation or isolation of the virtual FTP environments.  If there are security concerns that may include different user bases on the same physical host or different levels (sensitivity) of information in different FTP hosts on the same server, the ability to have segregation of the environments will be important (this will happen).  How can segregation/isolation be provided in this model?  Please include information on the options here.  I am assuming that since we are talking about multiple hosts on a single IP, that we may be within a physical host or a virtual environment that has one IP address.  If this is the case, what security options are available - authentication, access controls, etc.?  Please include them in this section.

Thank you,