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

<kathleen.moriarty@emc.com> Sat, 25 June 2011 02:51 UTC

Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A76111E808E; Fri, 24 Jun 2011 19:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD1tvj-dkE5l; Fri, 24 Jun 2011 19:51:41 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E9A5111E809E; Fri, 24 Jun 2011 19:51:40 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5P2paTi005499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2011 22:51:36 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 24 Jun 2011 22:51:25 -0400
Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.221.46.113]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5P2nbUg008198; Fri, 24 Jun 2011 22:49:37 -0400
Received: from mx06a.corp.emc.com ([169.254.1.199]) by mxhub05.corp.emc.com ([128.221.46.113]) with mapi; Fri, 24 Jun 2011 22:49:37 -0400
From: kathleen.moriarty@emc.com
To: robmcm@microsoft.com, secdir@ietf.org, draft-ietf-ftpext2-hosts.all@tools.ietf.org, iesg@ietf.org
Date: Fri, 24 Jun 2011 22:49:36 -0400
Thread-Topic: SECDIR review of draft-ietf-ftpext2-hosts-02
Thread-Index: AcwyiBUFO2skqoQCSLqk+KSpXVMV4QADvEhgAAyN90AAAphKUAADsoUw
Message-ID: <AE31510960917D478171C79369B660FA0E032531C2@MX06A.corp.emc.com>
References: <AE31510960917D478171C79369B660FA0E0325300F@MX06A.corp.emc.com> <01AA9EC92749BF4894AC2B3039EA4A2C1949D137@CH1PRD0302MB131.namprd03.prod.outlook.com> <AE31510960917D478171C79369B660FA0E032531B8@MX06A.corp.emc.com> <01AA9EC92749BF4894AC2B3039EA4A2C1949DC3F@CH1PRD0302MB131.namprd03.prod.outlook.com>
In-Reply-To: <01AA9EC92749BF4894AC2B3039EA4A2C1949DC3F@CH1PRD0302MB131.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: phethmon@hethmon.com, anthonybryan@gmail.com
Subject: Re: [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: Sat, 25 Jun 2011 02:51:42 -0000

Thanks again, Robert.  The suggested paragraph works for me.  Once that is in, I think we are good on the security review.

Best regards,
Kathleen

-----Original Message-----
From: Robert McMurray [mailto:robmcm@microsoft.com] 
Sent: Friday, June 24, 2011 9:48 PM
To: Moriarty, Kathleen; secdir@ietf.org; draft-ietf-ftpext2-hosts.all@tools.ietf.org; iesg@ietf.org
Cc: phethmon@hethmon.com; anthonybryan@gmail.com
Subject: RE: SECDIR review of draft-ietf-ftpext2-hosts-02

Thanks, Kathleen.

At the protocol level I am only concerned that the security environment is reset; how the environment is created and reset is implementation-specific. So my intention was to highlight as a security consideration that an implementer should be aware that they might have work to do in this scenario, but the details are up to them. With that in mind, what do you think of this rewording for that section?

"As discussed in section 3.3 of this document, a server implementation MAY treat a HOST command that was sent after a user has been authenticated as though a REIN command was sent. In this scenario, the server implementation SHOULD reset the authentication environment, as that would allow for segregation between the security environments for each virtual host on an FTP server. The implementation details for security environments may vary greatly based on the requirements of each server implementation and operating system, and those details are outside the scope of the protocol itself. For example, a virtual host "foo.example.com" on an FTP server might use a specific username and password list, while the virtual host "bar.example.com" on the same FTP server might use a different username and password list. In such a scenario, resetting the security environment is necessary for the virtual servers to appear to behave independently from a client perspective, while the actual server implementation details are irrelevant at the protocol level."

Thanks again!
Robert

-----Original Message-----
From: kathleen.moriarty@emc.com [mailto:kathleen.moriarty@emc.com] 
Sent: Friday, June 24, 2011 4:53 PM
To: Robert McMurray; secdir@ietf.org; draft-ietf-ftpext2-hosts.all@tools.ietf.org; iesg@ietf.org
Cc: phethmon@hethmon.com; anthonybryan@gmail.com
Subject: RE: SECDIR review of draft-ietf-ftpext2-hosts-02

Hi, Robert.

Thank you for making the updates.  I think the change for section 3.2 looks good, thanks!

As for the security considerations, the ADs may have an opinion here as well.  My thought process is that if you are concerned about the environment that the user authenticates into, wouldn't the environment itself be a concern as well?  The authentication consideration is to ensure the user gets authenticated into the right environment.  If there is no segregation available between environments, that would be a security consideration.  If that varies between OSes, that would be a consideration as well.  You might not have to detail it out, but it should be stated as a consideration as this may not be a solution possible in a number of use cases.

Thank you,
Kathleen