rfc4217.txt

一个用QT开发的FTP客户端

Network Working Group                                 P. Ford-Hutchinson
Request for Comments: 4217                                    IBM UK Ltd
Category: Standards Track                                   October 2005


                         Securing FTP with TLS

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a mechanism that can be used by FTP clients
   and servers to implement security and authentication using the TLS
   protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and
   the extensions to the FTP protocol defined by RFC 2228, "FTP Security
   Extensions".  It describes the subset of the extensions that are
   required and the parameters to be used, discusses some of the policy
   issues that clients and servers will need to take, considers some of
   the implications of those policies, and discusses some expected
   behaviours of implementations to allow interoperation.  This document
   is intended to provide TLS support for FTP in a similar way to that
   provided for SMTP in RFC 2487, "SMTP Service Extension for Secure
   SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading
   to TLS Within HTTP/1.1.".

   This specification is in accordance with RFC 959, "File Transfer
   Protocol".  It relies on RFC 2246, "The TLS Protocol Version 1.0.",
   and RFC 2228, "FTP Security Extensions".













Ford-Hutchinson             Standards Track                     [Page 1]

RFC 4217                 Securing FTP with TLS              October 2005


Table of Contents

   1. Introduction ....................................................3
   2. Audience ........................................................5
   3. Overview ........................................................5
   4. Session Negotiation on the Control Port .........................5
      4.1. Client Wants a Secured Session .............................5
      4.2. Server Wants a Secured Session .............................6
   5. Clearing the Control Port .......................................6
   6. Response to the FEAT Command ....................................7
   7. Data Connection Behaviour .......................................8
   8. Mechanisms for the AUTH Command .................................9
   9. Data Connection Security ........................................9
   10. A Discussion of Negotiation Behaviour .........................11
      10.1. The Server's View of the Control Connection ..............11
      10.2. The Server's View of the Data Connection .................12
      10.3. The Client's View of the Control Connection ..............14
      10.4. The Client's View of the Data Connection .................15
   11. Who Negotiates What, Where, and How ...........................15
      11.1. Do we protect at all? ....................................15
      11.2. What level of protection do we use on the Control
            connection? ..............................................15
      11.3. Do we protect data connections in general? ...............16
      11.4. Is protection required for a particular data transfer? ...16
      11.5. What level of protection is required for a
            particular data ..........................................16
   12. Timing Diagrams ...............................................16
      12.1. Establishing a Protected Session .........................17
      12.2. Establishing a Protected Session Without a
            Password Request .........................................18
      12.3. Establishing a Protected Session and then
            Clearing with the CCC ....................................19
      12.4. A Standard Data Transfer Without Protection ..............20
      12.5. A Firewall-Friendly Data Transfer Without Protection .....20
      12.6. A Standard Data Transfer with Protection .................21
      12.7. A Firewall-Friendly Data Transfer with Protection ........21
   13. Discussion of the REIN Command ................................22
   14. Discussion of the STAT and ABOR Commands ......................22
   15. Security Considerations .......................................23
      15.1. Verification of Authentication Tokens ....................23
           15.1.1. Server Certificates ...............................23
           15.1.2. Client Certificates ...............................23
      15.2. Addressing FTP Security Considerations [RFC-2577] ........24
           15.2.1. Bounce Attack .....................................24
           15.2.2. Restricting Access ................................24
           15.2.3. Protecting Passwords ..............................24
           15.2.4. Privacy ...........................................24
           15.2.5. Protecting Usernames ..............................24



Ford-Hutchinson             Standards Track                     [Page 2]

RFC 4217                 Securing FTP with TLS              October 2005


           15.2.6. Port Stealing .....................................25
           15.2.7. Software-Based Security Problems ..................25
      15.3. Issues with the CCC Command ..............................25
   16. IANA Considerations ...........................................25
   17. Other Parameters ..............................................25
   18. Scalability and Limits ........................................26
   19. Applicability .................................................26
   20. Acknowledgements ..............................................26
   21. References ....................................................26
      21.1. Normative References .....................................26
      21.2. Informative References ...................................27

1.  Introduction

   This document describes how three other documents should be combined
   to provide a useful, interoperable, and secure file transfer
   protocol.  Those documents are:

      RFC 959 [RFC-959]

         The description of the Internet File Transfer Protocol.

      RFC 2246 [RFC-2246]

         The description of the Transport Layer Security protocol
         (developed from the Netscape Secure Sockets Layer (SSL)
         protocol version 3.0).

      RFC 2228 [RFC-2228]

         Extensions to the FTP protocol to allow negotiation of security
         mechanisms to allow authentication, confidentiality, and
         message integrity.

   This document is intended to provide TLS support for FTP in a similar
   way to that provided for SMTP in RFC 3207 [RFC-3207] and HTTP in RFC
   2817 [RFC-2817].

   The security extensions to FTP in [RFC-2228] offer a comprehensive
   set of commands and responses that can be used to add authentication,
   integrity, and confidentiality to the FTP protocol.  The TLS protocol
   is a popular (due to its wholesale adoption in the HTTP environment)
   mechanism for generally securing a socket connection.

   Although TLS is not the only mechanism for securing file transfer, it
   does offer some of the following positive attributes:





Ford-Hutchinson             Standards Track                     [Page 3]

RFC 4217                 Securing FTP with TLS              October 2005


      - Flexible security levels.  TLS can support confidentiality,
        integrity, authentication, or some combination of all of these.
        During a session, this allows clients and servers to dynamically
        decide on the level of security required for a particular data
        transfer.

      - Ability to provide strong authentication of the FTP server.

      - It is possible to use TLS identities to authenticate client
        users and client hosts.

      - Formalised public key management.  By use of well established
        client identity mechanisms (supported by TLS) during the
        authentication phase, certificate management may be built into a
        central function.  Whilst this may not be desirable for all uses
        of secured file transfer, it offers advantages in certain
        structured environments.

      - Co-existence and interoperation with authentication mechanisms
        that are already in place for the HTTPS protocol.  This allows
        web browsers to incorporate secure file transfer using the same
        infrastructure that has been set up to allow secure web
        browsing.

   The TLS protocol is a development of the Netscape Communication
   Corporation's SSL protocol and this document can be used to allow the
   FTP protocol to be used with either SSL or TLS.  The actual protocol
   used will be decided by the negotiation of the protected session by
   the TLS/SSL layer.  This document will only refer to the TLS
   protocol; however, it is understood that the Client and Server MAY
   actually be using SSL if they are so configured.

   There are many ways in which these three protocols can 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.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" that
   appear in this document are to be interpreted as described in
   [RFC-2119].






Ford-Hutchinson             Standards Track                     [Page 4]

RFC 4217                 Securing FTP with TLS              October 2005


2.  Audience

   This document is aimed at developers who wish to implement TLS as a
   security mechanism to secure FTP clients and/or servers.

   Systems administrators and architects should be fully aware of the
   security implications discussed in [RFC-2228], which need to be
   considered when choosing an implementation of this protocol and
   configuring it to provide their required security.

3.  Overview

   A full description of the FTP security protocol enhancements is
   contained in [RFC-2228].  This document describes how the AUTH, PROT,
   PBSZ, and CCC commands, defined therein, should be implemented with
   the TLS protocol.

   In summary, an FTP session is established on the normal control port.
   A client requests TLS with the AUTH command and then decides if it
   wishes to secure the data connections by use of the PBSZ and PROT
   commands.  Should a client wish to make the control connection revert
   back into plaintext (for example, once the authentication phase is
   completed), then the CCC command can be used.

   Implementation of this protocol extension does not ensure that each
   and every session and data transfer is secure, it merely provides the
   tools that allow a client and/or server to negotiate an acceptable or
   required level of security for that given session or data transfer.
   However, it is possible to have a server implementation that is
   capable of refusing to operate in an insecure fashion.

4.  Session Negotiation on the Control Port

   The server listens on the normal FTP control port {FTP-PORT} and the
   session initiation is not secured at all.  Once the client wishes to
   secure the session, the AUTH command is sent and the server MAY then
   allow TLS negotiation to take place.

4.1.  Client Wants a Secured Session

   If a client wishes to attempt to secure a session, then it SHOULD, in
   accordance with [RFC-2228], send the AUTH command with the parameter
   requesting TLS {TLS-PARM} ('TLS').

   The client then needs to behave according to its policies depending
   on the response received from the server and also the result of the
   TLS negotiation.  A client that receives an AUTH rejection MAY choose
   to continue with the session unprotected if it so desires.



Ford-Hutchinson             Standards Track                     [Page 5]

RFC 4217                 Securing FTP with TLS              October 2005


4.2.  Server Wants a Secured Session

   The FTP protocol does not allow a server to directly dictate client
   behaviour; however, the same effect can be achieved by refusing to
   accept certain FTP commands until the session is secured to a level
   that is acceptable to the server.

   In either case, '234' is the server response to an 'AUTH TLS' command
   that it will honour.

   The '334' response, as defined in [RFC-2228], implies that an ADAT
   exchange will follow.  This document does not use the ADAT command
   and so the '334' reply is incorrect.

   The FTP protocol insists that a USER command be used to identify the
   entity attempting to use the ftp server.  Although the TLS
   negotiation may be providing authentication information, the USER
   command MUST still be issued by the client.  However, it will be a
   server implementation issue to decide which credentials to accept and
   what consistency checks to make between the client cert used and the
   parameter on the USER command.

   [RFC-2228] states that the user must reauthorize (that is, reissue
   some or all of the USER, PASS, and ACCT commands) following an AUTH
   command.  Additionally, this document specifies that all other
   transfer parameters (other than the AUTH parameter) must be reset,
   almost as if a REIN command was issued.

      Reset transfer parameters after the AUTH command, including (but
      are not limited to): user identity, default data ports, TYPE,
      STRU, MODE, and current working directory.

5.  Clearing the Control Port

   There are circumstances in which it may be desirable to protect the
   control connection only during part of the session and then to revert
   back to a plaintext connection.  This is often due to the limitations
   of boundary devices such as NAT and firewalls, which expect to be
   able to examine the content of the control connection in order to
   modify their behaviour.

   Typically the AUTH, USER, PASS, PBSZ, and PROT commands would be
   protected within the TLS protocol and then the CCC command would be
   issued to return to a plaintext socket state.  This has important
   Security Issues (which are discussed in the Security Considerations
   section), but this document describes how the command should be used,
   if the client and server still wish to use it after having considered
   the issues.



Ford-Hutchinson             Standards Track                     [Page 6]

RFC 4217                 Securing FTP with TLS              October 2005


   When a server receives the CCC command, it should behave as follows:

      If the server does not accept CCC commands (or does not understand
      them), then a 500 reply should be sent.

      Otherwise, if the control connection is not protected with TLS,
      then a 533 reply should be sent.

      Otherwise, if the server does not wish to allow the control
      connection to be cleared at this time, then a 534 reply should be
      sent.

      Otherwise, the server is accepting the CCC command and should do
      the following:

         o  Send a 200 reply.

         o  Shutdown the TLS session on the socket and leave it open.

         o  Continue the control connection in plaintext, expecting the
            next command from the client to be in plaintext.

         o  Not accept any more PBSZ or PROT commands.  All subsequent
            data transfers must be protected with the current PROT
            settings.

6.  Response to the FEAT Command

   The FEAT command (introduced in [RFC-2389]) allows servers with
   additional features to advertise these to a client by responding to
   the FEAT command.  If a server supports the FEAT command, then it
   MUST advertise supported AUTH, PBSZ, and PROT commands in the reply,
   as described in section 3.2 of [RFC-2389].  Additionally, the AUTH
   command should have a reply that identifies 'TLS' as one of the
   possible parameters to AUTH.  It is not necessary to identify the
   'TLS-C' synonym separately.

   Example reply (in the same style as [RFC-2389])

      C> FEAT
      S> 211-Extensions supported
      S>  AUTH TLS
      S>  PBSZ
      S>  PROT
      S> 211 END






Ford-Hutchinson             Standards Track                     [Page 7]

RFC 4217                 Securing FTP with TLS              October 2005


7.  Data Connection Behaviour

   The Data Connection in the FTP model can be used in one of three
   ways.  (Note: These descriptions are not necessarily placed in exact
   chronological order, but do describe the steps required.  See
   diagrams later for clarification.)

            i) Classic FTP client/server data exchange