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

From: <[email-masked]>
Date: Fri, 24 Jun 2011 12:02:13 -0400

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

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,
Kathleen

---

From: Robert McMurray <[email-masked]>
Date: Fri, 24 Jun 2011 19:03:16 +0000

Thanks, Kathleen.

[Note: Adding Anthony Bryan as the document shepherd.]

Here is a suggested rewording of the fragment from Section 3.2 for which you had requested an update - does this agree with what you were looking for?

"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, or changing authentication schemes and/or username and password lists, or making much more elaborate state changes - such as creating isolated environments for each FTP session."

Your first of comment about Section 4 is an easy change - thanks!

Your second set of comments about Section 4 seems to me to be less about the protocol and more about the actual implementation details, which I think we should avoid. As an example, I have a background on UNIX, Windows, and several other platforms; the way that I might choose to implement segregation/isolation for each of those platforms will differ radically. For example, process isolation might come to mind as one possible implementation, but the way that processes actually work varies greatly depending on the platform, and it might only make sense on one platform and not the others, but in any case we shouldn't be suggesting something that specific in an RFC anyway. For that matter, the way that accounts and permissions are used on each platform also differs greatly, so it does not seem to make sense to call out those concepts, either. In the end, each server implementer has a variety of platform-specific options that are available within their specific situation when they are considering how to implement their unique security environments, and all of which are outside the scope of this draft.  With that in mind, I do not think that Section 4 should be updated with verbiage that says something to the effect of, "Actual server implementations for creating security environments for virtual hosts are outside the scope of this document, but you could use a combination of platform-specific technologies such as authentication, isolation, access control, etc."

That being said, I have attached an updated version of the draft in TXT and XML format.

Thanks!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 24, 2011 9:02 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; Robert McMurray
Subject: SECDIR review of draft-ietf-ftpext2-hosts-02

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.

Section 3.2:

Thank you,
Kathleen

---

From: <[email-masked]>
Date: Fri, 24 Jun 2011 19:52:30 -0400

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

-----Original Message-----
From: Robert McMurray [mailto:[email-masked]] 
Sent: Friday, June 24, 2011 3:03 PM
To: Moriarty, Kathleen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; Anthony Bryan ([email-masked])
Subject: RE: SECDIR review of draft-ietf-ftpext2-hosts-02

Thanks, Kathleen.

Thanks!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 24, 2011 9:02 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; Robert McMurray
Subject: SECDIR review of draft-ietf-ftpext2-hosts-02

Section 3.2:

Thank you,
Kathleen

---

From: Robert McMurray <[email-masked]>
Date: Sat, 25 Jun 2011 01:47:58 +0000

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: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 24, 2011 4:53 PM
To: Robert McMurray; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: SECDIR review of draft-ietf-ftpext2-hosts-02

Hi, Robert.

Thank you,
Kathleen

---

From: <[email-masked]>
Date: Fri, 24 Jun 2011 22:49:36 -0400

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:[email-masked]] 
Sent: Friday, June 24, 2011 9:48 PM
To: Moriarty, Kathleen; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: SECDIR review of draft-ietf-ftpext2-hosts-02

Thanks, Kathleen.

Thanks again!
Robert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 24, 2011 4:53 PM
To: Robert McMurray; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: SECDIR review of draft-ietf-ftpext2-hosts-02

Hi, Robert.

Thank you,
Kathleen