GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4217

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

  1. 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.
  1. Ability to provide strong authentication of the FTP server.
  1. It is possible to use TLS identities to authenticate client

users and client hosts.

  1. 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.
  1. 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
  1. The client obtains a port; sends the port number to

the server; the server connects to the client. The

                 client issues a send or receive request to the server
                 on the control connection and the data transfer
                 commences on the data connection.
        ii) Firewall-Friendly client/server data exchange (as
            discussed in [RFC-1579]) using the PASV command to reverse
            the direction of the data connection.
  1. The client requests that the server open a port; the

server obtains a port and returns the address and

                 port number to the client; the client connects to the
                 server on this port.  The client issues a send or
                 receive request on the control connection, and the
                 data transfer commences on the data connection.
       iii) Client-initiated server/server data exchange (proxy or
            PASV connections).
  1. The client requests that server A opens a port;

server A obtains a port and returns it to the client;

                 the client sends this port number to server B.
                 Server B connects to server A.  The client sends a
                 send or receive request to server A and the
                 complement to server B and the data transfer
                 commences.  In this model, server A is the proxy or
                 PASV host and is a client for the Data Connection to
                 server B.
 For i) and ii), the FTP client MUST be the TLS client and the FTP
 server MUST be the TLS server.
 That is to say, it does not matter which side initiates the
 connection with a connect() call or which side reacts to the
 connection via the accept() call; the FTP client, as defined in
 [RFC-959], is always the TLS client, as defined in [RFC-2246].

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

 In scenario iii), there is a problem in that neither server A nor
 server B is the TLS client, given the fact that an FTP server must
 act as a TLS server for Firewall-Friendly FTP [RFC-1579].  Thus, this
 is explicitly excluded in the security extensions document [RFC-2228]
 and in this document.

8. Mechanisms for the AUTH Command

 The AUTH command takes a single parameter to define the security
 mechanism to be negotiated.  As the SSL/TLS protocols self-negotiate
 their levels, there is no need to distinguish between SSL and TLS in
 the application layer.  The mechanism name for negotiating TLS is the
 character string identified in {TLS-PARM}.  This allows the client
 and server to negotiate TLS on the control connection without
 altering the protection of the data channel.  To protect the data
 channel as well, the PBSZ command, followed by the PROT command
 sequence, MUST be used.
 Note: The data connection state MAY be modified by the client issuing
 the PROT command with the new desired level of data channel
 protection and the server replying in the affirmative.  This data
 channel protection negotiation can happen at any point in the session
 (even straight after a PORT or PASV command) and as often as is
 required.
 See also Section 16, "IANA Considerations".

9. Data Connection Security

 The Data Connection security level is determined by the PROT command.
    The PROT command, as specified in [RFC-2228], allows client/server
    negotiation of the security level of the data connection.  Once a
    PROT command has been issued by the client and accepted by the
    server returning the '200' reply, the security of subsequent data
    connections MUST be at that level until another PROT command is
    issued and accepted; the session ends and a REIN command is
    issued, or the security of the session (via an AUTH command) is
    re-negotiated.
 Data Connection Security Negotiation (the PROT command)
    Note: In line with [RFC-2228], there is no facility for securing
    the Data connection with an insecure Control connection.
    Specifically, the PROT command MUST be preceded by a PBSZ command,
    and a PBSZ command MUST be preceded by a successful security data
    exchange (the TLS negotiation in this case).

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

    The command defined in [RFC-2228] to negotiate data connection
    security is the PROT command.  As defined, there are four values
    that the PROT command parameter can take.
          'C' - Clear - neither Integrity nor Privacy
          'S' - Safe - Integrity without Privacy
          'E' - Confidential - Privacy without Integrity
          'P' - Private - Integrity and Privacy
    As TLS negotiation encompasses (and exceeds) the Safe /
    Confidential / Private distinction, only Private (use TLS) and
    Clear (don't use TLS) are used.
    For TLS, the data connection can have one of two security levels.
          1) Clear (requested by 'PROT C')
          2) Private (requested by 'PROT P')
    With 'Clear' protection level, the data connection is made without
    TLS.  Thus, the connection is unauthenticated and has no
    confidentiality or integrity.  This might be the desired behaviour
    for servers sending file lists, pre-encrypted data, or non-
    sensitive data (e.g., for anonymous FTP servers).
    If the data connection security level is 'Private', then a TLS
    negotiation must take place on the data connection to the
    satisfaction of the Client and Server prior to any data being
    transmitted over the connection.  The TLS layers of the Client and
    Server will be responsible for negotiating the exact TLS Cipher
    Suites that will be used (and thus the eventual security of the
    connection).
    In addition, the PBSZ (protection buffer size) command, as
    detailed in [RFC-2228], is compulsory prior to any PROT command.
    This document also defines a data channel encapsulation mechanism
    for protected data buffers.  For FTP-TLS, which appears to the FTP
    application as a streaming protection mechanism, this is not
    required.  Thus, the PBSZ command MUST still be issued, but must
    have a parameter of '0' to indicate that no buffering is taking
    place and the data connection should not be encapsulated.
    Note that PBSZ 0 is not in the grammar of [RFC-2228], section 8.1,
    where it is stated:

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

       PBSZ <sp> <decimal-integer> <CRLF> <decimal-integer> ::= any
       decimal integer from 1 to (2^32)-1
    However, it should be noted that using a value of '0' to mean a
    streaming protocol is a reasonable use of '0' for that parameter
    and is not ambiguous.
 Initial Data Connection Security
    The initial state of the data connection MUST be 'Clear' (this is
    the behaviour as indicated by [RFC-2228]).

10. A Discussion of Negotiation Behaviour

 As [RFC-2228] allows security qualities to be negotiated, enabled,
 and disabled dynamically, this can make implementations seem quite
 complex.  However, in any given instance the behaviour should be
 quite straightforward.  Either the server will be enforcing the
 policy of the server host or it will be providing security
 capabilities requested by the client.  Either the client will be
 conforming to the server's policy or will be endeavouring to provide
 the capabilities that the user desires.

10.1. The Server's View of the Control Connection

 A server MAY have a policy statement somewhere that might:
  1. Deny any command before TLS is negotiated (this might cause

problems if a SITE or some such command is required prior to

      login).
  1. Deny certain commands before TLS is negotiated (e.g., USER,

PASS, or ACCT).

  1. Deny insecure USER commands for certain users (e.g., not

ftp/anonymous).

  1. Deny secure USER commands for certain users (e.g.,

ftp/anonymous).

  1. Define the level(s) of TLS to be allowed.
  1. Define the CipherSuites allowed to be used (perhaps on a per

host/domain/… basis).

  1. Allow TLS authentication as a substitute for local

authentication.

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

  1. Define data connection policies (see next section).
    It is possible that the TLS negotiation may not be completed
    satisfactorily for the server, in which case it can be one of
    these states.
       The TLS negotiation failed completely
          In this case, the control connection should still be in an
          unprotected mode and the server SHOULD issue an unprotected
          '421' reply to end the session.
       The TLS negotiation completed successfully, but the server
       decides that the session parameters are not acceptable (e.g.,
       Distinguished Name in the client certificate is not permitted
       to use the server).
          In this case, the control connection should still be in a
          protected state, so the server MAY either continue to refuse
          to service commands or issue a protected '421' reply and
          close the connection.
       The TLS negotiation failed during the TLS handshake
          In this case, the control connection is in an unknown state
          and the server SHOULD simply drop the control connection.
 The server code will be responsible for implementing the required
 policies and ensuring that the client is prevented from circumventing
 the chosen security by refusing to service those commands that are
 against policy.

10.2. The Server's View of the Data Connection

 The server can take one of four basic views of the data connection.
    1 - Don't allow encryption at all (in which case the PROT command
        should not allow any value other than 'C' - if it is allowed
        at all).
    2 - Allow the client to choose protection or not.
    3 - Insist on data protection (in which case the PROT command must
        be issued prior to the first attempted data transfer).
    4 - Decide on one of the above three for each and every data
        connection.

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

 The server SHOULD only check the status of the data protection level
 (for options 3 and 4 above) on the actual command that will initiate
 the data transfer (and not on the PORT or PASV).  The following
 commands, defined in [RFC-959], cause data connections to be opened
 and thus may be rejected before any 1xx message due to an incorrect
 PROT setting.
       STOR
       RETR
       NLST
       LIST
       STOU
       APPE
 The reply to indicate that the PROT setting is incorrect is '521 data
 connection cannot be opened with this PROT setting'
 If the protection level indicates that TLS is required, then it
 should be negotiated once the data connection is made.  Thus, the
 '150' reply only states that the command can be used given the
 current PROT level.  Should the server not like the TLS negotiation,
 then it will close the data port immediately and follow the '150'
 command with a '522' reply, which indicates that the TLS negotiation
 failed or was unacceptable.  (Note: This means that the application
 can pass a standard list of CipherSuites to the TLS layer for
 negotiation, and review the one negotiated for applicability in each
 instance).
 The Security Considerations section discusses the issue of cross-
 checking any certificates used to authenticate the data connection
 with the one(s) used to authenticate the control connection.  This is
 an important security step.
 It is 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 a cleared control connection.  If this is the reason
 for 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.
 It should be noted that the TLS authentication of the server will be
 authentication of the server host itself and not a user on the server
 host.

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

10.3. The Client's View of the Control Connection

 In most cases, it is likely that the client will be using TLS because
 the server would refuse to interact insecurely.  To allow for this,
 clients SHOULD be flexible enough to manage the securing of a session
 at the appropriate time and still allow the user/server policies to
 dictate exactly when during the session the security is negotiated.
 In the case where it is the client that is insisting on the securing
 of the session, the client will need to ensure that the negotiations
 are all completed satisfactorily and will need to be able to sensibly
 inform the user should the server not support, or not be prepared to
 use, the required security levels.
 Clients SHOULD be coded in such a manner as to allow the timing of
 the AUTH, PBSZ, and PROT commands to be flexible and dictated by the
 server.  It is quite reasonable for a server to refuse certain
 commands prior to these commands.  Similarly, it is quite possible
 that a SITE or quoted command might be needed by a server prior to
 the AUTH.  A client MUST allow a user to override the timing of these
 commands to suit a specific server.
 For example, a client SHOULD NOT insist on sending the AUTH as the
 first command in a session, nor should it insist on issuing a
 PBSZ/PROT pair directly after the AUTH.  This may well be the default
 behaviour, but must be overridable by a user.
 The TLS negotiation may not be completed satisfactorily for the
 client, in which case it will be in one of these states:
    The TLS negotiation failed completely
       In this case, the control connection should still be in an
       unprotected mode and the client should issue an unprotected
       QUIT command to end the session.
    The TLS negotiation completed successfully, but the client decides
    that the session parameters are not acceptable (e.g.,
    Distinguished Name in certificate is not the actual server
    expected).
       In this case, the control connection should still be up in a
       protected state, so the client should issue a protected QUIT
       command to end the session.

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

    The TLS negotiation failed during the TLS handshake.
       In this case, the control connection is in an unknown state and
       the client should simply drop the control connection.

10.4. The Client's View of the Data Connection

 Client security policies
    Clients do not typically have 'policies' as such, instead they
    rely on the user to define their actions and, to a certain extent,
    are reactive to the server policy.  Thus, a client will need to
    have commands that will allow the user to switch the protection
    level of the data connection dynamically; however, there may be a
    general 'policy' that attempts all LIST and NLST commands on a
    Clear connection first (and automatically switches to Private if
    it fails).  In this case, there would need to be a user command
    available to ensure that a given data transfer was not attempted
    on an insecure data connection.
    Clients also need to understand that the level of the PROT setting
    is only checked for a particular data transfer after that transfer
    has been requested.  Thus, a refusal by the server to accept a
    particular data transfer should not be read by the client as a
    refusal to accept that data protection level completely, as not
    only may other data transfers be acceptable at that protection
    level, but it is entirely possible that the same transfer may be
    accepted at the same protection level at a later point in the
    session.
    It should be noted that the TLS authentication of the client
    should be an authentication of a user on the client host and not
    the client host itself.

11. Who Negotiates What, Where, and How

11.1. Do we protect at all?

 Client issues 'AUTH TLS', server accepts or rejects.  If the server
 needs AUTH, then it refuses to accept certain commands until it gets
 a successfully protected session.

11.2. What level of protection do we use on the Control connection?

 Decided entirely by the TLS CipherSuite negotiation.

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

11.3. Do we protect data connections in general?

 Client issues PROT command, server accepts or rejects.

11.4. Is protection required for a particular data transfer?

 A client would have already issued a PROT command if it required the
 connection to be protected.
 If a server needs to have the connection protected, then it will
 reply to the STOR/RETR/NLST/... command with a '522', indicating that
 the current state of the data connection protection level is not
 sufficient for that data transfer at that time.

11.5. What level of protection is required for a particular data

     transfer?
 Decided entirely by the TLS CipherSuite negotiation.
 Thus, for flexibility, it can be seen that it is desirable for the
 FTP application to be able to interact with the TLS layer upon which
 it sits to define and discover the exact TLS CipherSuites that are to
 be/have been negotiated and to make decisions accordingly.

12. Timing Diagrams

 These timing diagrams aim to help explain exactly how the TLS
 handshake and session protection fits into the existing logic of the
 FTP protocol.  Of course, the FTP protocol itself is not well
 described with respect to the timing of commands and responses in
 [RFC-959], so this is partly based on empirical observation of
 existing widespread client and server implementations.

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

12.1. Establishing a Protected Session

            Client                                 Server
   control          data                   data               control
 ====================================================================
                                                              socket()
                                                              bind()
   socket()
   connect()  ----------------------------------------------> accept()
             <----------------------------------------------  220
   AUTH TLS   ---------------------------------------------->
             <----------------------------------------------  234
   TLSneg()  <----------------------------------------------> TLSneg()
   PBSZ 0     ---------------------------------------------->
             <----------------------------------------------  200
   PROT P     ---------------------------------------------->
             <----------------------------------------------  200
   USER fred  ---------------------------------------------->
             <----------------------------------------------  331
   PASS pass  ---------------------------------------------->
             <----------------------------------------------  230
 Note 1: The order of the PBSZ/PROT pair and the USER/PASS pair (with
 respect to each other) is not important (i.e., the USER/PASS can
 happen prior to the PBSZ/PROT, or the server can refuse to allow a
 PBSZ/PROT pair until the USER/PASS pair has happened).
 Note 2: The PASS command might not be required at all (if the USER
 parameter and any client identity presented provide sufficient
 authentication).  The server would indicate this by issuing a '232'
 reply to the USER command instead of the '331', which requests a PASS
 from the client (see below).
 Note 3: The AUTH command might not be the first command after the
 receipt of the 220 welcome message.

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

12.2. Establishing a Protected Session Without a Password Request

     (The TLS Authentication is Sufficient)
            Client                                 Server
   control          data                   data               control
 ====================================================================
                                                              socket()
                                                              bind()
   socket()
   connect()  ----------------------------------------------> accept()
             <----------------------------------------------  220
   AUTH TLS   ---------------------------------------------->
             <----------------------------------------------  234
   TLSneg()  <----------------------------------------------> TLSneg()
   PBSZ 0     ---------------------------------------------->
             <----------------------------------------------  200
   PROT P     ---------------------------------------------->
             <----------------------------------------------  200
   USER fred  ---------------------------------------------->
             <----------------------------------------------  232

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

12.3. Establishing a Protected Session and then Clearing with the CCC

     Command
           Client                                 Server
  control          data                   data               control
====================================================================
                                                             socket()
                                                             bind()
  socket()
  connect()  ----------------------------------------------> accept()
            <----------------------------------------------  220
  AUTH TLS   ---------------------------------------------->
            <----------------------------------------------  234
  TLSneg()  <----------------------------------------------> TLSneg()
  PBSZ 0     ---------------------------------------------->
            <----------------------------------------------  200
  PROT P     ---------------------------------------------->
            <----------------------------------------------  200
  USER fred  ---------------------------------------------->
            <----------------------------------------------  232
  CCC        ---------------------------------------------->
            <----------------------------------------------  200
  TLSshutdown()  <-------------------------------------> TLSshutdown()
  1. The rest of the control session continues in plaintext with

protected data transfers (due to PROT P).

 Note: This has serious security issues (see Security Considerations
 section) but may be useful in a firewall/NAT scenario.

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

12.4. A Standard Data Transfer Without Protection

            Client                                 Server
   control          data                   data               control
 ====================================================================
                    socket()
                    bind()
   PORT w,x,y,z,a,b ----------------------------------------->
       <----------------------------------------------------- 200
   STOR file ------------------------------------------------>
                                           socket()
                                           bind()
       <----------------------------------------------------- 150
                    accept() <-----------  connect()
                    write()   -----------> read()
                    close()   -----------> close()
       <----------------------------------------------------- 226

12.5. A Firewall-Friendly Data Transfer Without Protection

            Client                                 Server
   control          data                   data               control
 ====================================================================
   PASV -------------------------------------------------------->
                                           socket()
                                           bind()
       <------------------------------------------ 227 (w,x,y,z,a,b)
                    socket()
   STOR file --------------------------------------------------->
                    connect()  ----------> accept()
       <-------------------------------------------------------- 150
                    write()    ----------> read()
                    close()    ----------> close()
       <-------------------------------------------------------- 226
 Note: Implementers should be aware that the connect()/accept()
 function is performed prior to the receipt of the reply from the STOR
 command.  This contrasts the with situation when a non-firewall-
 friendly PORT is used prior to the STOR, and the accept()/connect()
 is performed after the reply from the aforementioned STOR has been
 dealt with.

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

12.6. A Standard Data Transfer with Protection

            Client                                 Server
   control          data                   data               control
 ====================================================================
                    socket()
                    bind()
   PORT w,x,y,z,a,b -------------------------------------------->
       <-------------------------------------------------------- 200
   STOR file --------------------------------------------------->
                                           socket()
                                           bind()
       <-------------------------------------------------------- 150
                    accept()  <----------  connect()
                    TLSneg()  <----------> TLSneg()
                    TLSwrite() ----------> TLSread()
                    TLSshutdown() -------> TLSshutdown()
                    close()    ----------> close()
       <-------------------------------------------------------- 226

12.7. A Firewall-Friendly Data Transfer with Protection

            Client                                 Server
   control          data                   data               control
 ====================================================================
   PASV -------------------------------------------------------->
                                           socket()
                                           bind()
       <------------------------------------------ 227 (w,x,y,z,a,b)
                    socket()
   STOR file --------------------------------------------------->
                    connect()  ----------> accept()
       <-------------------------------------------------------- 150
                    TLSneg()   <---------> TLSneg()
                    TLSwrite()  ---------> TLSread()
                    TLSshutdown() -------> TLSshutdown()
                    close()     ---------> close()
       <-------------------------------------------------------- 226

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

13. Discussion of the REIN Command

 The REIN command, defined in [RFC-959], allows the user to reset the
 state of the FTP session.  From [RFC-959]:
    REINITIALIZE (REIN)
       This command terminates a USER, flushing all I/O and account
       information, except to allow any transfer in progress to be
       completed.  All parameters are reset to the default settings
       and the control connection is left open.  This is identical to
       the state in which a user finds himself immediately after the
       control connection is opened.  A USER command may be expected
       to follow.
 When this command is processed by the server, the TLS session(s) MUST
 be cleared and the control and data connections revert to
 unprotected, clear communications.  It MAY be acceptable to use
 cached TLS sessions for subsequent connections, however, a server
 MUST NOT mandate this.
 If the REIN command is being used to clear a TLS session, then the
 reply to the REIN command MUST be sent in a protected session prior
 to the session(s) being cleared.

14. Discussion of the STAT and ABOR Commands

 The ABOR and STAT commands and the use of TCP Urgent Pointers
    [RFC-959] describes the use of Telnet commands (IP and DM) and the
    TCP Urgent pointer to indicate the transmission of commands on the
    control channel during the execution of a data transfer.  FTP uses
    the Telnet Interrupt Process and Data Mark commands in conjunction
    with Urgent data to preface two commands: ABOR (Abort Transfer)
    and STAT (Status request).
    The Urgent Pointer was used because, in a Unix implementation, the
    receipt of a TCP packet marked as Urgent would result in the
    execution of the SIGURG interrupt handler.  This reliance on
    interrupt handlers was necessary on systems that did not implement
    select() or did not support multiple threads.  TLS does not
    support the notion of Urgent data.
    When TLS is implemented as a security method in FTP, the server
    SHOULD NOT rely on the use of SIGURG to process input on the
    control channel during data transfers.  The client MUST send all
    data, including Telnet commands, across the TLS session.

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

15. Security Considerations

 This document discusses how TLS may be used in conjunction with
 [RFC-2228] to provide mechanisms for securing FTP sessions.
 Discussions about security rationale and security properties are
 contained within the [RFC-2228] document and are not repeated here.

15.1. Verification of Authentication Tokens

 In this section, we assume that X.509 certificates will be used for
 the TLS authentication.  If some other identity token is used (e.g.,
 kerberos tickets - see [RFC-2712]), then similar, mechanism-specific
 considerations will need to be made.

15.1.1. Server Certificates

  1. Although it is entirely an implementation decision, it is

recommended that certificates used for server authentication of the

   TLS session contain the server identification information in a
   similar manner to those used for http servers (see [RFC-2818]).
  1. It is strongly recommended that the certificate used for server

authentication of Data connections be the same certificate as that

   used for the corresponding Control connection.  If different
   certificates are to be used, there should be some other mechanism
   that the client can use to cross-check the data and control
   connection server identities.
  1. If Server Certificates are not used, then many of the security

benefits will not be realised. For Example, in an anonymous

   Diffie-Hellman environment, there is no server identity
   authentication, so there is little protection against man-in-the-
   middle attacks.

15.1.2. Client Certificates

  1. Deciding which client certificates to allow and defining which

fields define what authentication information is entirely a server

   implementation issue.
  1. However, it is strongly recommended that the certificate used for

client authentication of Data connections be the same certificate

   as that used for the corresponding Control connection.  If
   different certificates are to be used, there should be some other
   mechanism that the server can use to cross-check the data and
   control connection client identities.

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

  1. If Client Certificates are not used, then many of the security

benefits will not be realised. For Example, it would still be

   possible for a malicious client to hijack a data connection.

15.2. Addressing FTP Security Considerations [RFC-2577]

15.2.1. Bounce Attack

 A bounce attack should be harder in a secured FTP environment
 because:
  1. The FTP server that is being used to initiate a false connection

will always be a 'server' in the TLS context. Therefore, only

      services that act as 'clients' in the TLS context could be
      vulnerable.  This would be a counter-intuitive way to implement
      TLS on a service.
  1. The FTP server would detect that the authentication credentials

for the data connection are not the same as those for the

      control connection, thus the server policies could be set to
      drop the data connection.
  1. Genuine users are less likely to initiate such attacks when the

authentication is strong, and malicious users are less likely to

      gain access to the FTP server if the authentication is not
      easily subverted (password guessing, network tracing, etc...)

15.2.2. Restricting Access

 This document presents a strong mechanism for solving the issue
 raised in this section.

15.2.3. Protecting Passwords

 The twin solutions of strong authentication and data confidentiality
 ensure that this is not an issue when TLS is used to protect the
 control session.

15.2.4. Privacy

 The TLS protocol ensures data confidentiality by encryption.  Privacy
 (e.g., access to download logs, user profile information, etc...) is
 outside the scope of this document (and [RFC-2577] presumably).

15.2.5. Protecting Usernames

 This is not an issue when TLS is used as the primary authentication
 mechanism.

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

15.2.6. Port Stealing

 This specification will do little for the Denial of Service element
 of this section; however, strong authentication on the data
 connection will prevent unauthorised connections from retrieving or
 submitting files.  Of course, this is only the case where strong
 client authentication is being used.  If client certificates are not
 used, then port stealing by a rogue client is still a problem.  If no
 strong authentication is in use at all (e.g., anonymous Diffie-
 Hellman), then the port stealing problem will remain.

15.2.7. Software-Based Security Problems

 Nothing in this specification will affect the discussion in this
 section.

15.3. Issues with the CCC Command

 Using the CCC command can create security issues.  For a full
 description, see the "CLEAR COMMAND CHANNEL (CCC)" section of
 [RFC-2228].  Clients should not assume that a server will allow the
 CCC command to be processed.
 Server implementations may wish to refuse to process the CCC command
 on a session that has not passed through some form of client
 authentication (e.g., TLS client auth or FTP USER/PASS).  This can
 prevent anonymous clients from repeatedly requesting AUTH TLS
 followed by CCC to tie up resources on the server.

16. IANA Considerations

 {FTP-PORT} - The port assigned to the FTP control connection is 21.

17. Other Parameters

 {TLS-PARM} - The parameter for the AUTH command to indicate that TLS
 is required.  To request the TLS protocol in accordance with this
 document, the client MUST use 'TLS'
    To maintain backward compatibility with older versions of this
    document, the server SHOULD accept 'TLS-C' as a synonym for 'TLS'.
    Note: [RFC-2228] states that these parameters are case-
    insensitive.

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

18. Scalability and Limits

 There are no issues other than those concerned with the ability of
 the server to refuse to have a complete TLS negotiation for each and
 every data connection, which will allow servers to retain throughput
 whilst using cycles only when necessary.

19. Applicability

 This mechanism is generally applicable as a mechanism for securing
 the FTP protocol.  It is unlikely that anonymous FTP clients or
 servers will require such security (although some might like the
 authentication features without the confidentiality).

20. Acknowledgements

 o  Netscape Communications Corporation for the original SSL protocol.
 o  Eric Young for the SSLeay libraries.
 o  University of California, Berkeley for the original
    implementations of FTP and ftpd, on which the initial
    implementation of these extensions were layered.
 o  IETF CAT working group.
 o  IETF TLS working group.
 o  IETF FTPEXT working group.
 o  Jeff Altman for the ABOR and STAT discussion.
 o  The various people who have help author this document throughout
    its protracted draft stages, namely Martin Carpenter, Eric Murray,
    Tim Hudson, and Volker Wiegand.

21. References

21.1. Normative References

 [RFC-959]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD
            9, RFC 959, October 1985.
 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC-2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
            2228, October 1997.

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

 [RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
            RFC 2246, January 1999.
 [RFC-2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for
            the File Transfer Protocol", RFC 2389, August 1998.

21.2. Informative References

 [RFC-1579] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February
            1994.
 [RFC-2222] Myers, J., "Simple Authentication and Security Layer
            (SASL)", RFC 2222, October 1997.
 [RFC-2577] Allman, M. and S. Ostermann, "FTP Security
            Considerations", RFC 2577, May 1999.
 [RFC-2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
            Suites to Transport Layer Security (TLS)", RFC 2712,
            October 1999.
 [RFC-2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
            HTTP/1.1", RFC 2817, May 2000.
 [RFC-2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
 [RFC-3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
            Transport Layer Security", RFC 3207, February 2002.

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

Contributors

 Tim Hudson
 RSA Data Security
 Australia Pty Ltd
 Phone: +61 7 3227 4444
 EMail: tjh@rsasecurity.com.au
 Volker Wiegand
 SuSE Linux
 EMail: wiegand@suse.de
 Martin Carpenter
 Verisign Ltd
 EMail: mcarpenter@verisign.com
 Eric Murray
 Wave Systems Inc.
 EMail: ericm@lne.com

Author's Address

 Paul Ford-Hutchinson
 IBM UK Ltd
 PO Box 31
 Birmingham Road
 Warwick
 United Kingdom
 Phone: +44 1926 462005
 EMail: rfc4217@ford-hutchinson.com

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

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Ford-Hutchinson Standards Track [Page 29]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4217.txt · Last modified: 2005/10/28 18:23 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki