Skip to main content

Securing FTP with TLS
draft-murray-auth-ftp-ssl-16

Revision differences

Document history

Date Rev. By Action
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for Steven Bellovin
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2005-03-02
16 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-02-24
16 Amy Vezza IESG state changed to Approved-announcement sent
2005-02-24
16 Amy Vezza IESG has approved the document
2005-02-24
16 Amy Vezza Closed "Approve" ballot
2005-02-24
16 Ted Hardie State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ted Hardie
2005-02-24
16 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2005-02-10
16 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-02-10
16 (System) New version available: draft-murray-auth-ftp-ssl-16.txt
2004-10-15
16 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2004-10-15
16 (System) Removed from agenda for telechat - 2004-10-14
2004-10-14
16 Steven Bellovin [Ballot comment]
My comments have been folded in to Russ' DISCUSS.
2004-10-14
16 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin
2004-10-14
16 Thomas Narten
[Ballot comment]
There is no IANA considerations asking to register the commands/names used. But it seems FTP never created an IANA registry. Should probably be …
[Ballot comment]
There is no IANA considerations asking to register the commands/names used. But it seems FTP never created an IANA registry. Should probably be fixed at some point...
2004-10-14
16 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten
2004-10-14
16 Harald Alvestrand
[Ballot comment]
Reviewed by John Loughney, Gen-ART

His review:

Technically, the document is ready, but it needs an additional editorial pass.
File a No Objection, …
[Ballot comment]
Reviewed by John Loughney, Gen-ART

His review:

Technically, the document is ready, but it needs an additional editorial pass.
File a No Objection, but request an additional editorial pass.

Comments:

1) References need splitting.
2) Draft is using  RFC2026 boilerplate, needs update
3) ToC is off.
4) Footers need to be fixed, they currently say:
Ford-Hutchinson                                        FORMFEED[Page 1]
5) Abstract reads more like an introduction, it should be shortened.
6) Need blank line between paragraphs in many places.
7) Page 4:
    "The File Transfer Protocol (FTP) currently defined in [RFC-959] and
  in place on the Internet is an excellent mechanism for exchanging
  files. "
Suplufeous text, delete.  Most file exchangers are using non-IETF protocols
these days .... 
8) Sub-section titles shouldn't be indented.
9) 1st page header should be corrected.
10) Section 11 has formatting problems.
11) IPR & Copyright text need updating.
2004-10-14
16 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2004-10-14
16 Allison Mankin
[Ballot comment]
In the course of fixes for other purposes, the discussion in Section 15
of dropping FTP's use of the TCP URG should be …
[Ballot comment]
In the course of fixes for other purposes, the discussion in Section 15
of dropping FTP's use of the TCP URG should be cleaned up.  This is
not clear:

                                                                                    The TLS
      session will be corrupted if any data is sent on a socket while
      TLS is active.
2004-10-14
16 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2004-10-14
16 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2004-10-14
16 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2004-10-14
16 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2004-10-13
16 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-10-13
16 Russ Housley
[Ballot comment]
The Abstract is way too long.  It is a full page.  Much of the information
  belongs in the Introduction.  Once moved to …
[Ballot comment]
The Abstract is way too long.  It is a full page.  Much of the information
  belongs in the Introduction.  Once moved to the Introduction, the list of
  bullets should also include one about authentication of the FTP server,
  which is not normally provided.

  I propose a rewording of the last paragraph of the Introduction:

    There are many ways in which these three protocols might be combined.
    This document selects one method by which FTP can operate securely,
    while providing both flexibility and interoperation.  This necessitates
    a brief description of the actual negotiation mechanism, a detailed
    description of the required policies and practices, and a discussion
    of the expected behaviours of clients and servers to allow either
    party to impose their security requirements on the FTP session.

  In the Overview: s/PBSZ:PROT/PBSZ and PROT/

  The paragraph indentation is inconsistent in sections 5 and 11.

  In section 5.2: s/USER command must still/USER command MUST still/

  In section 9: s/PBSZ:PROT command sequence/PBSZ command followed by the PROT command/

  In section 16.2.1: s/COULD/could/
2004-10-13
16 Russ Housley
[Ballot discuss]
Section 16.1.1 says:
  :
  : Similarly, it is recommended that the certificate used for
  : server authentication of Data connections …
[Ballot discuss]
Section 16.1.1 says:
  :
  : Similarly, it is recommended that the certificate used for
  : server authentication of Data connections is the same
  : certificate as that used for the corresponding Control
  : connection.
  :
  I do not see how two different certificates can be used.  The
  authentication and authorization decisions are very complex if
  different ones are permitted.  It is just too complex.

  Section 16.1.2 has a similar problem, allowing the client to
  present a different authentication token on the command channel
  and the data channel.  I assume that an authentication token
  is a client certificate.

  The whole issue could be avoided by requiring the data channel
  to be protected by resuming the TLS session that protects the
  control channel.  This approach strongly binds the control
  channel and the data channel together, which seems like a
  requirement to me.
2004-10-13
16 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley
2004-10-12
16 Steven Bellovin
[Ballot discuss]
[Review includes comments from Eric Rescorla]

Section 11.2 says:

      Section 15.1.1 discusses the issue of cross-checking a certificate
    …
[Ballot discuss]
[Review includes comments from Eric Rescorla]

Section 11.2 says:

      Section 15.1.1 discusses the issue of cross-checking a certificate
      used to authenticate the data connection with the one used to
      authenticate the control connection.  This is an important
      security step.

There is no 15.1.1.  16.1.1 talks about server-side certficates for data channels being checked by the client.  It doesn't discuss the server cross-checking the client certificate.  Which threat is more serious is context-dependent, but both checks MUST be made.

If client side certificates are not used, there is no way for the server to make such a check.  This fact -- and its implications -- need to be discussed in the Security Considerations section.

More generally, there needs to be strong linkage between the control channel's session and the data channels.  The easiest way to do this is to REQUIRE that all data channels be resumptions of the control channel session.  This is suggested as an option; it needs to be mandatory. 

You need to reset all of the state in the connection (ASCII vs. BINARY, etc.) after the TLS channel is established. Otherwise, there are a variety of active attacks.
2004-10-11
16 Steven Bellovin
[Ballot discuss]
Section 11.2 says:

      Section 15.1.1 discusses the issue of cross-checking a certificate
      used to authenticate the data …
[Ballot discuss]
Section 11.2 says:

      Section 15.1.1 discusses the issue of cross-checking a certificate
      used to authenticate the data connection with the one used to
      authenticate the control connection.  This is an important
      security step.

There is no 15.1.1.  16.1.1 talks about server-side certficates for data channels being checked by the client.  It doesn't discuss the server cross-checking the client certificate.  Which threat is more serious is context-dependent, but both checks should be made.

If client side certificates are not used, there is no way for the server to make such a check.  This fact -- and its implications -- need to be discussed in the Security Considerations section.
2004-10-11
16 Steven Bellovin
[Ballot discuss]
Section 11.2 says:

      Section 15.1.1 discusses the issue of cross-checking a certificate
      used to authenticate the data …
[Ballot discuss]
Section 11.2 says:

      Section 15.1.1 discusses the issue of cross-checking a certificate
      used to authenticate the data connection with the one used to
      authenticate the control connection.  This is an important
      security step.

There is no 15.1.1.  16.1.1 talks about server-side certficates for data channels being checked by the client.  It doesn't discuss the server cross-checking the client certificate.  Which threat is more serious is context-dependent, but both checks should be made.

If client side certificates are not used, there is no way for the server to make such a check.  This fact -- and its implications -- need to be discussed in the Security Considerations section.

11.2 says

      It is quite reasonable for the server to insist that the data
      connection uses a TLS cached session.  This might be a cache of a
      previous data connection or of the control connection.

I don't see how the control connection's cached session can be used if
the control connection is still open. This may make sense if a CCC command has been issued; that restriction should be noted.
2004-10-11
16 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin
2004-10-10
16 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-10-04
16 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck
2004-10-04
16 Scott Hollenbeck [Ballot comment]
References need to be split and the page numbers in the Table of Contents are off by quite a bit.
2004-10-04
16 Scott Hollenbeck [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-09-28
16 Ted Hardie Placed on agenda for telechat - 2004-10-14 by Ted Hardie
2004-09-28
16 Ted Hardie State Changes to IESG Evaluation from Waiting for Writeup by Ted Hardie
2004-09-28
16 Ted Hardie [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie
2004-09-28
16 Ted Hardie Ballot has been issued by Ted Hardie
2004-09-28
16 Ted Hardie Created "Approve" ballot
2004-09-13
16 (System) State has been changed to Waiting for Writeup from In Last Call by system
2004-08-19
16 Michelle Cotton
IANA Last Call Comments:
We understand this document to have no IANA Actions.  The
IANA Considerations section only points out an assigned
port number already …
IANA Last Call Comments:
We understand this document to have no IANA Actions.  The
IANA Considerations section only points out an assigned
port number already in the registry.
2004-08-16
16 Amy Vezza Last call sent
2004-08-16
16 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2004-08-16
16 Ted Hardie State Changes to Last Call Requested from Publication Requested::External Party by Ted Hardie
2004-08-16
16 Ted Hardie Last Call was requested by Ted Hardie
2004-08-16
16 (System) Ballot writeup text was added
2004-08-16
16 (System) Last call text was added
2004-08-16
16 (System) Ballot approval text was added
2004-08-16
16 Ted Hardie Area acronymn has been changed to app from gen
2004-08-16
16 Ted Hardie Intended Status has been changed to Proposed Standard from None
2004-08-13
15 (System) New version available: draft-murray-auth-ftp-ssl-15.txt
2004-06-17
14 (System) New version available: draft-murray-auth-ftp-ssl-14.txt
2004-05-18
16 Ted Hardie State Changes to Publication Requested::External Party from Publication Requested by Ted Hardie
2004-05-18
16 Ted Hardie Pinged authors to respond to review comments.
2004-03-11
13 (System) New version available: draft-murray-auth-ftp-ssl-13.txt
2003-11-09
16 Ted Hardie

It's not clear to me that what is being described here is secure.
Because FTP is two connections, you need some way to tie the …

It's not clear to me that what is being described here is secure.
Because FTP is two connections, you need some way to tie the
control channel to the data channel. The authors suggest
a way to do it, but don't explain why it's crucial:

      It is quite reasonable for the server to insist that the data
      connection uses a TLS cached session.  This might be a cache of a
      previous data connection or of the control connection.  If this is
      the reason for the the refusal to allow the data transfer then the
      '522' reply should indicate this.
      Note: this has an important impact on client design, but allows
      servers to minimise the cycles used during TLS negotiation by
      refusing to perform a full negotiation with a previously
      authenticated client.

This isn't just a performance optimization. It's a critical security
feature.

In general, I found this document quite hard to follow. There's
never any explicit statement of the security properties they are trying
to achieve or of how things work on the large scale. This makes it very
hard to assess whether the desired security properties are being
achieved.  Sections 9, 10, and 11 are extremely sketchy and don't
explain things in anywhere near enough detail. For instance, S 11 is
just diagrams plus notes. No real explanation.

{TLS-PARM} is referenced in S 4.1 but not defined until S 16.

The document needs extensive copy-edit before publication.

-Ekr
2003-08-27
12 (System) New version available: draft-murray-auth-ftp-ssl-12.txt
2003-05-23
16 Ned Freed Shepherding AD has been changed to Hardie, Ted from Freed, Ned
2003-03-27
11 (System) New version available: draft-murray-auth-ftp-ssl-11.txt
2002-12-02
16 Steven Bellovin Being referred to the ftpext working group.
2002-12-02
16 Steven Bellovin Shepherding AD has been changed to Freed, Ned from Bellovin, Steve
2002-11-14
16 Steven Bellovin Draft Added by Bellovin, Steve
2002-10-01
10 (System) New version available: draft-murray-auth-ftp-ssl-10.txt
2002-04-03
09 (System) New version available: draft-murray-auth-ftp-ssl-09.txt
2001-10-09
08 (System) New version available: draft-murray-auth-ftp-ssl-08.txt
2001-04-09
07 (System) New version available: draft-murray-auth-ftp-ssl-07.txt
2000-09-19
06 (System) New version available: draft-murray-auth-ftp-ssl-06.txt
2000-01-27
05 (System) New version available: draft-murray-auth-ftp-ssl-05.txt
1998-09-02
04 (System) New version available: draft-murray-auth-ftp-ssl-04.txt
1998-08-14
03 (System) New version available: draft-murray-auth-ftp-ssl-03.txt
1997-08-01
02 (System) New version available: draft-murray-auth-ftp-ssl-02.txt
1997-03-26
01 (System) New version available: draft-murray-auth-ftp-ssl-01.txt
1996-11-28
00 (System) New version available: draft-murray-auth-ftp-ssl-00.txt