[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

FTPEXT Working Group                                         G. Lundberg
Internet-Draft                                 WU-FTPD Development Group
Expiration Date: November 28, 2002                              May 2002


                     FTP Data Connection Assurance
           draft-ietf-ftpext-data-connection-assurance-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   To view the list of IETF Internet-Draft Mirror Sites, see
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document specifies an extension to the File Transfer Protocol
   (FTP) by which a user and server can exchange data port connection
   information which may then be used to provide connection assurance.

   Two new commands are introduced.  Through use of these commands and
   their replies, the user and server exchange information allowing
   verification of the socket addresses for a data connection prior to
   actual data transmission over the connection.

   Implementation of this extension is RECOMMENDED.






Lundberg                Expires November 28, 2002               [Page 1]


Internet-Draft        FTP Data Connection Assurance             May 2002


Table of Contents

      Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . .   1
   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2. ACTIVE ESTABLISH (ESTA)  . . . . . . . . . . . . . . . . . . .   5
   3. PASSIVE ESTABLISH (ESTP) . . . . . . . . . . . . . . . . . . .   8
   4. Connection Management  . . . . . . . . . . . . . . . . . . . .  11
   5. FEAT Response  . . . . . . . . . . . . . . . . . . . . . . . .  12
   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  12
   7. Security Considerations  . . . . . . . . . . . . . . . . . . .  13
      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  14
      Normative References . . . . . . . . . . . . . . . . . . . . .  14
      Informative References . . . . . . . . . . . . . . . . . . . .  14
      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  15
      Annex A - Address Family Numbers . . . . . . . . . . . . . . .  16
      Annex B - Network Address Formats  . . . . . . . . . . . . . .  16
      Annex C - Examples of Use  . . . . . . . . . . . . . . . . . .  16
         C.1 PORT Mode . . . . . . . . . . . . . . . . . . . . . . .  17
         C.2 PASV Mode . . . . . . . . . . . . . . . . . . . . . . .  18
         C.3 Server-to-Server Mode . . . . . . . . . . . . . . . . .  19
      Annex D - Implementation Considerations  . . . . . . . . . . .  21
         D.1 Interactively Finding the Specified Connection  . . . .  21
         D.2 Automatically Finding the Specified Connection  . . . .  22
         D.3 Using a Common Passive Socket . . . . . . . . . . . . .  22
      Full Copyright Statement . . . . . . . . . . . . . . . . . . .  24


























Lundberg                Expires November 28, 2002               [Page 2]


Internet-Draft        FTP Data Connection Assurance             May 2002


1. Introduction

   The intention of this protocol extension is to address the security
   issue involved with the problem of a race condition in the existing
   File Transfer Protocol [DS, CERT2].  This condition allows an
   attacker the ability to receive unauthorized transmissions from, or
   transmit unauthorized information to, the passive party of a file
   transfer.  The attack makes use of the timing window between when the
   passive socket is prepared and when an active connection to that
   passive socket actually occurs.

   The security industry identifier for this issue is CVE-1999-0351
   [CVE].

   The problem is fairly well known within the FTP community and has
   been discussed for some time [DS].  Since it does not pose a direct
   threat to the security of hosts on the Internet, and generally
   presents only limited inconvenience to users, little attention has
   been paid to the issue.  It is, however, a growing concern to a
   number of private, corporate and governmental users who desire
   assurance that their information is delivered only to the intended
   recipients yet who are unwilling to sacrifice availability or inter-
   operability by use of cryptographic methods [RFC2228, MURRAY].  The
   fact that the FTP makes no attempt to prevent, or even provide a
   means to detect, these events is unacceptable.

   Several independent implementations of attacks making use of this
   window are known to exist [KS, JG], and at least one event has been
   claimed to have occurred against a vendor site to obtain unauthorized
   copies of potentially proprietary information.  To date, all known
   attacks depend upon weaknesses in TCP implementations, but with the
   relatively small number of TCP ports and advances in distributed
   attack methods this condition cannot be expected to continue.

   To fully understand the problem, and the solution presented, a basic
   understanding of some features of the FTP is required.

   The FTP model [RFC959] uses two communication channels: the data
   connection is responsible for exchanging files and other data; the
   control connection provides control and synchronization of the data
   connection and transmissions over it.  While the control connection
   exists throughout the lifetime of an FTP session, data connections
   are often transitory, existing only for the duration of a single file
   transfer.

   The FTP model is usually presented as two processes: the User-FTP
   implementation and the Server-FTP implementation.  Each of these
   processes are further separated into the protocol interpreter (PI)



Lundberg                Expires November 28, 2002               [Page 3]


Internet-Draft        FTP Data Connection Assurance             May 2002


   and the data transfer process (DTP).  A Server-FTP always implements
   both a PI and a DTP.  The User-FTP, however, may implement only a PI;
   using an external process as its DTP (as is the case, for example, in
   a server-to-server transfer).

   Existing FTP commands [RFC959, RFC1639, RFC2428] allow the user to
   determine which end-point has responsibility for actively initiating
   the data connection.  The other end-point passively awaits this
   connection.  To cause the Server-DTP to operate in passive mode, the
   user sends a PASV, LPSV or EPSV command, requesting the Server-DTP
   create a passive socket and report the address assigned.  To cause
   the Server-DTP to operate in active mode, the user creates (or
   obtains through other means) a passive socket and communicates its
   address to the Server-FTP process through the PORT, LPRT or EPRT
   commands.

   The user actively initiates the data connection immediately prior to
   issuing the data transfer command.  (It may do so any time after
   receipt of the reply to the PASV, LPSV or EPSV command, and must do
   so prior to issuing the data transfer command.)  The Server-FTP
   process must initiate the data connection upon receipt of the data
   transfer command and prior to issuing a reply to that command.

   The delay involved, between the creation of the passive socket and
   establishment of the data connection using it, presents a window
   during which an attacker can actively establish a connection to the
   passive socket.

   Unfortunately, the FTP provides no means to assure that the active
   socket is the one intended; the passive participant simply accepts
   the first connection presented.  While all parties have knowledge of
   the address assigned to the passive socket, only the process actively
   initiating the connection knows the address of the active socket.
   Without some means of communicating this information to all parties,
   there is insufficient information to judge whether the connection
   originated from the intended participant.

   The protocol presented is intended to provide just that: a means to
   exchange active socket address information.

   In the development of the protocol specified in this document,
   several alternatives were considered.

   The STAT command [RFC959] could be issued by the user to discover the
   address of the active socket.  The format of the reply to the STAT
   command, however, is not well defined; to be usable, a consistent,
   machine readable response is needed.  Requiring the reply to the STAT
   command to provide the necessary information in a usable fashion



Lundberg                Expires November 28, 2002               [Page 4]


Internet-Draft        FTP Data Connection Assurance             May 2002


   would cause inter-operation problems with existing implementations,
   and is only a partial solution since it does not address the needs of
   the Server-FTP process when operating in passive mode.

   Some existing Server-FTP implementations attempt to reduce the impact
   of the problem by placing requirements upon which remote socket
   addresses they will accept [GL].  These requirements violate the
   spirit, if not the letter, of the FTP specifications, negatively
   impacting its usability, and can raise complex configuration issues
   for server administrators.  In addition, these methods are only a
   partial solution since they do not address the needs of the user.

   [DS] suggests exchanging verification information over the control
   and data connections, however doing so would prevent inter-
   operability with existing implementations.  Existing specifications
   [RFC2228, MURRAY] can provide just such a solution but are not widely
   deployed and, to assure connection integrity, do not inter-operate
   with existing (non-cryptographic) implementations.

   What is required is a solution which addresses the problem for all
   parties, operates with little added overhead and minimal (optimally,
   no) configuration requirements, does not break inter-operability with
   existing implementations, and which is straightforward to deploy,
   without the processing overhead and potential legal issues involved
   with cryptographic methods.

   The new commands presented here provide for the exchange the active
   socket address between the user and the Server-FTP process.  This
   presents both parties (or, in the case of server-to-server transfers,
   all three parties) with the information necessary to evaluate the
   connection end-points prior to commencing transmission.

   When reading the following specifications, the key words "MUST",
   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED",  "MAY", and "OPTIONAL" are to be interpreted as
   described in RFC 2119 [RFC2119].

2. ACTIVE ESTABLISH (ESTA)

   The user should issue the ESTA command before issuing any other data
   transfer command when the Server-DTP is in active mode and a usable
   data connection is not already present.

   This command instructs the Server-DTP to immediately establish a
   connection from its data port to the currently selected passive
   address, and to report back to the user the address information for
   the active socket actually used on the new connection.




Lundberg                Expires November 28, 2002               [Page 5]


Internet-Draft        FTP Data Connection Assurance             May 2002


   The active socket on the connection is the local address.  In
   [POSIX], for example, this is the value returned via the getsockname
   function; which may differ from the address requested by the bind
   function.

   The user must have already prepared a passive socket to accept the
   connection, and communicated the address information for that socket
   to the Server-FTP process using the PORT, LPRT or EPRT command.  For
   a server-to-server transfer, this means the user must have already
   successfully instructed the other, passive Server-DTP to prepare the
   passive socket.

   If the Server-DTP has already accepted an established data connection
   to the passive socket, it should report the local address for that
   connection.  Thus, the ESTA command is repeatable, and may be issued
   to either server in a server-to-server transfer at any time that the
   user wishes the server to report the local address it observes on the
   fully established data connection.

   The establishment of the connection may take some time, and the
   Server-DTP may make several attempts before reporting a failure.  The
   implementation should include a time out limiting the duration of the
   connection attempts.  The Server-FTP process should be capable of
   accepting the ABOR command during this period, and should interpret
   the ABOR command as a request to cease the connection attempt or
   close the connection if the attempt has already succeeded.

   The ESTA command is analogous to the PASV, LPSV and EPSV commands,
   and returns a result formatted the same as that which would be
   produced by the EPSV command [RFC2428] (even if the EPSV command is
   not implemented).

   The format of the ESTA command is:

      ESTA <CRLF>

   The ESTA command takes no arguments.

   Possible replies to the ESTA command, and their meanings, include:

      225 Data connection open; no transfer in progress.
      421 Service not available, closing control connection.
      425 Can't open data connection.
      500 Syntax error, command unrecognized.
      501 Syntax error in parameters or arguments.
      502 Command not implemented.
      520 Requested action not taken; DTP is in passive mode.




Lundberg                Expires November 28, 2002               [Page 6]


Internet-Draft        FTP Data Connection Assurance             May 2002


   With the exception of response code 225, the User-FTP process must
   not depend upon the actual text (if any) included with the reply.

   A Server-FTP process which does not implement the ESTA command will
   reply with either response code 500 or 502.  For compatibility with
   existing implementations, the User-FTP process must be prepared for
   this reply.  It should be possible to proceed with the data transfer.
   Local site policy, however, may dictate refusal to continue
   communication with implementations which do not support ESTA.

   The response code 520 indicates that the Server-DTP was unable to
   accept a connection from the passive socket because it is operating
   in passive mode and does not have the address of a remote passive
   socket to connect to.  This should not occur if there is already a
   fully established data connection.

   The response code 425 indicates that the Server-DTP was unable to
   establish a connection to the passive socket.  This should not occur
   if there is already a fully established data connection.  In [POSIX],
   for example, this would occur when the connect function returns an
   error indication; possible causes might include a refused connection,
   an unreachable passive socket address, time-out, resource depletion,
   or internal implementation errors.

   Response code 225 indicates that the Server-DTP has established a
   connection to the passive socket, or already had a fully established
   data connection.

   The Server-FTP process must format the text of reply for response
   code 225 in a manner similar to a positive completion reply to the
   EPSV command (even if the EPSV command is not actually implemented).
   Unlike the EPSV reply, the Server-FTP process must include the full
   protocol address information actually observed on the data connection
   for the local socket in the ESTA report.

   Upon receipt of reply 225, the user's DTP should accept the
   connection from the passive socket and then the User-FTP process
   should compare the information provided with the reply against that
   obtained locally from the established connection.

   If the two do not exactly match, the user should terminate the data
   connection by issuing the ABOR command, and should not proceed to
   issue a data transfer command.

   For a server-to-server transfer, the information provided in the
   response to ESTA should be compared with the information provided in
   the response to the ESTP command.  For the User-FTP process, the
   information provided in the response to ESTA should be compared



Lundberg                Expires November 28, 2002               [Page 7]


Internet-Draft        FTP Data Connection Assurance             May 2002


   against the remote address observed on the fully established data
   connection.  In [POSIX], for example, this is the value returned via
   the address argument to the accept function.

   The format of the response code 225 reply is:

      225 <SP> <text> <SP> (<d><proto><d><addr><d><port><d>) <CRLF>

   The unformatted text portion of the reply (<text>) may be any
   message, and may be omitted.  If present, it must be separated from
   the formatted portion of the reply by at least one space character.

   The formatted portion of the reply must be enclosed in parentheses,
   formatted exactly as the arguments to the ESTP command (below), and
   has the same meaning.

   Following the separating space and parenthesis, a delimiter character
   (<d>) must be specified.  The delimiter character must be one octet
   in range 33 to 126, inclusive.  The character "|" (ASCII 124) is
   recommended; unless it coincides with a character needed to encode
   the arguments.

   Note that the discussion which follows presumes the use of TCP over
   an Internet Protocol but should not be taken as a requirement that
   only those protocols may be used: from the point of view of the ESTA
   command, any protocol is acceptable.  The number and meaning of any
   arguments which follow <proto> is protocol-specific; this memo
   specifies the arguments for TCP over the Internet Protocols in use at
   the time of its writing.

   The protocol argument (<proto>) must be an address family number
   assigned by the IANA.  This number indicates the protocol to be used
   (and, implicitly, the number, meaning, and maximum lengths, of the
   remaining arguments).

   The network address argument (<addr>) is a protocol-specific string
   representation of the network address for the active socket observed
   on the connection.  Refer to Annex B for the formats required for the
   Internet Protocols.

   The port number argument (<port>) must be the string representation
   of the number of the TCP port used by the active socket observed on
   the connection.

3. PASSIVE ESTABLISH (ESTP)

   The user should issue the ESTP command before issuing any other data
   transfer command when the Server-DTP has been placed in passive mode



Lundberg                Expires November 28, 2002               [Page 8]


Internet-Draft        FTP Data Connection Assurance             May 2002


   and a usable data connection is not already present.

   This command instructs the Server-DTP to accept a connection from the
   passive socket listening on its data port, and to report back to the
   user the address information for the active socket observed on the
   new connection.

   The active socket observed on the connection is the remote address.
   In [POSIX], for example, this is the value returned via the address
   argument to the accept function.

   The user must have already established an active connection to the
   Server-DTP using the address and port information previously obtained
   from the PASV, LPSV or EPSV command.  For a server-to-server
   transfer, this means the user must have already successfully
   instructed the other, active Server-DTP to establish the connection.

   If the Server-DTP has already accepted an established data connection
   from the passive socket, it should report the remote address for that
   connection.  Thus, the ESTP command is repeatable, and may be issued
   to either server in a server-to-server transfer at any time that the
   user wishes the server to report the remote address it observes on
   the fully established data connection.

   The Server-DTP must not await new connections on the passive socket.
   The ESTP command indicates the user believes an established
   connection already exists.  If this is not the case, the Server-DTP
   must immediately report this fact.

   The ESTP command is analogous to the PORT, LPRT and EPRT commands,
   and requires a parameter formatted the same as that which would be
   provided with the EPRT command [RFC2428] (even if the EPRT command is
   not implemented).  The protocol, network address and port information
   provided with the command must be that of the active socket.

   In a server-to-server transfer, the address of the active socket is
   returned in the response to the ESTA command.  For the User-FTP
   process, this address is the local information observed on the
   established active connection.  In [POSIX], for example, this is the
   value returned via the getsockname function; which may differ from
   the address requested by the bind function.

   The format of the ESTP command is:

      ESTP <SP> <d><proto><d><addr><d><port><d> <CRLF>

   The ESTP command keyword must be followed by a single space character
   (ASCII 32).  Following the space, a delimiter character (<d>) must be



Lundberg                Expires November 28, 2002               [Page 9]


Internet-Draft        FTP Data Connection Assurance             May 2002


   specified.  The delimiter character must be one octet in range 33 to
   126, inclusive.  The character "|" (ASCII 124) is recommended; unless
   it coincides with a character needed to encode the arguments.

   Note that the command format shown, and the discussion which follows,
   presume the use of TCP over an Internet Protocol but should not be
   taken as a requirement that only those protocols may be used: from
   the point of view of the ESTP command, any protocol is acceptable.
   The number and meaning of any arguments which follow <proto> is
   protocol-specific; this memo specifies the arguments for TCP over the
   Internet Protocols in use at the time of its writing.

   The protocol argument (<proto>) must be an address family number
   assigned by the IANA.  This number indicates the protocol to be used
   (and, implicitly, the number, meaning, and maximum lengths, of the
   remaining arguments).

   The network address argument (<addr>) is a protocol-specific string
   representation of the network address for the active socket observed
   on the connection.  Refer to Annex B for the formats required for the
   Internet Protocols.

   The port number argument (<port>) must be the string representation
   of the number of the TCP port used by the active socket observed on
   the connection.

   Possible replies to the ESTP command, and their meanings, include:

      225 Data connection open; no transfer in progress.
      421 Service not available, closing control connection.
      425 Can't open data connection.
      500 Syntax error, command unrecognized.
      501 Syntax error in parameters or arguments.
      502 Command not implemented.
      520 Requested action not taken; DTP is in active mode.

   With the exception of response code 225, the User-FTP process must
   not depend upon the actual text (if any) included with the reply.

   A Server-FTP process which does not implement the ESTP command will
   reply with either response code 500 or 502.  For compatibility with
   existing implementations, the User-FTP process must be prepared for
   this reply.  It should be possible to proceed with the data transfer.
   Local site policy, however, may dictate refusal to continue
   communication with implementations which do not support ESTP.

   The response code 520 indicates that the Server-DTP was unable to
   accept a connection from the passive socket because it is operating



Lundberg                Expires November 28, 2002              [Page 10]


Internet-Draft        FTP Data Connection Assurance             May 2002


   in active mode and there is no passive socket.  This should not occur
   if there is already a fully established data connection.

   The response code 425 indicates that the Server-DTP was unable to
   accept a connection from the passive socket.  This should not occur
   if there is already a fully established data connection.  In [POSIX],
   for example, this would occur when the accept function returns an
   error indication; possible causes might include an aborted
   connection, resource depletion, or internal implementation errors.

   Response code 225 indicates that the Server-DTP has accepted a
   passive data connection, or already had a fully established data
   connection.

   The Server-FTP process must format the text of reply for response
   code 225 in a manner similar to a positive completion reply to the
   EPSV command (even if the EPSV command is not actually implemented).
   Unlike the EPSV reply, the Server-FTP process must include the full
   protocol address information actually observed on the data connection
   for the remote socket in the ESTP report.

   Upon receipt of reply 225, the User-FTP process should compare the
   information provided with the reply against that obtained locally
   from the established connection.

   If the two do not exactly match, the user should terminate the data
   connection by issuing the ABOR command, and should not proceed to
   issue a data transfer command.

   The format of the response code 225 reply is:

      225 <SP> <text> <SP> (<d><proto><d><addr><d><port><d>) <CRLF>

   The unformatted text portion of the reply (<text>) may be any
   message, and may be omitted.  If present, it must be separated from
   the formatted portion of the reply by at least one space character.

   The formatted portion of the reply must be enclosed in parentheses,
   formatted exactly as the arguments to the ESTP command, and has the
   same meaning.

4. Connection Management

   Implementations should, for the purposes of connection management,
   treat the ESTA and ESTP commands as data transfer commands.  As data
   transfer commands, the addition of the ESTA and ESTP commands does
   not significantly change connection management requirements.




Lundberg                Expires November 28, 2002              [Page 11]


Internet-Draft        FTP Data Connection Assurance             May 2002


   Since these commands leave the connection established, but unused, a
   subsequent data transfer command should not cause establishment of a
   new data connection; the implementation should see that it has an
   established connection suitable for use with the desired data
   transfer and proceed to use that connection.

5. FEAT Response

   The specifications for the ESTA and ESTP commands provide the means
   to reliably determine the Server-FTP process's support for the
   commands.

   The user may issue a FEAT command [RFC2389] prior to use of the ESTA
   or ESTP command.  This may allow the user to determine if the Server-
   FTP process supports these commands.  However, since deployment of
   Server-FTP implementations which support the FEAT command is not yet
   wide-spread, the user should not rely upon implementation of the FEAT
   command to indicate implementation of the ESTA and ESTP commands.

   A Server-FTP which implements the ESTA and ESTP commands may (from
   the point of view of this specification) implement the FEAT command.
   If so, it must include, in the response to the FEAT command, a
   feature line indicating support for the ESTA and ESTP commands.

   The feature line must be formatted as:

      <SP> ESTA <CRLF>

   As specified in [RFC2389], the feature-name text, "ESTA," is not case
   sensitive, but should be transmitted in upper-case, and the feature
   line must begin with a single space character and end with a normal
   Telnet end-of-line sequence.

   At this time, options are not envisioned for either command.  To
   allow separate options for ESTA and ESTP, the user should also accept
   the text "ESTP" as indicating support for both commands.  The user,
   however, should accept options on the FEAT response and discard any
   it does not recognize.  When options appear, they must be separated
   from the feature-name text by exactly one space character.

6. IANA Considerations

   The specifications in this memo make reference to assignment lists
   currently maintained by the Internet Assigned Numbers Authority
   (IANA); no new assignments are specified, and no new assignment lists
   are required.

   The list of valid feature names sent in response to the FTP FEAT



Lundberg                Expires November 28, 2002              [Page 12]


Internet-Draft        FTP Data Connection Assurance             May 2002


   command is believed to be first-come first-served, and managed
   outside the control of the IANA.

   Specific examples taken from IANA-maintained lists at the time of
   this writing are for illustrative and informative purposes only.

7. Security Issues

   The ESTP command, and the replies to both ESTA and ESTP, contain
   network addressing information which could be used to gather
   information about internal network architectures.  However, since
   similar information is already transmitted on the FTP control
   connection, it presents no risk not already present in the FTP.

   The intention of this protocol extension is to address the security
   issue involved with the problem of a race condition in the existing
   File Transfer Protocol [DS, CERT2].  This condition allows an
   attacker the ability to receive unauthorized transmissions from, or
   transmit unauthorized information to, the passive party of a file
   transfer.  The attack makes use of the timing window between when the
   passive socket is prepared and when an active connection to that
   passive socket actually occurs.

   The security industry identifier for this issue is CVE-1999-0351
   [CVE].

   Denial of Service attacks can make use of this issue.  The described
   protocol is equally susceptible to Denial of Service attacks.  It
   can, however, make their effect much more apparent since data
   transfers will fail where they may have incorrectly appeared to have
   succeeded without these protocol extensions.

   The described protocol does not address the issue of "FTP Bounce"
   (CVE-1999-0017); where an attacker, via the control connection,
   instructs the Server-DTP to actively establish a data connection to a
   third party [CERT1].

   The protocol presented also makes no attempt to secure the actual
   data transmission; it only provides a means to determine the proper
   data connection has been established prior to initiating data
   transfer over that channel.  Alternatives, such as provided by the
   FTP Security Extensions [RFC2228, MURRAY], should be considered when
   data security is an issue.  Unfortunately, these methods are not, as
   yet, widely deployed.  ([MURRAY] is a work in process.  Wide spread
   deployment, if it occurs at all, will be some time in the future.)
   The extensions provided by this protocol provide added measures which
   can compliment those alternatives, but cannot replace them.




Lundberg                Expires November 28, 2002              [Page 13]


Internet-Draft        FTP Data Connection Assurance             May 2002


   The use of any Network Address Translation scheme, or certain proxy
   implementations, may render this protocol unusable.  The protocol
   involves the transmission of network address information over the FTP
   control connection.  Address translators, including proxy
   implementations which do not implement this protocol, can cause a
   mismatch between the information transmitted and the address actually
   observed at the communication channel end-point.

Acknowledgments

   The following people provided significant assistance with the
   analysis of the problem, the proposed solution, and the preparation
   of this document:

      The members of vulnerability handling team at the CERT
      Coordination Center.

      Paul Ford-Hutchinson of IBM UK Ltd.

      Ian Willis of Sun Microsystems.

Normative References

   [RFC959]    J. Postel and J. Reynolds, "FILE TRANSFER PROTOCOL
               (FTP)", STD 9, RFC 959, October 1985.

   [RFC1123]   IETF, "Requirements for Internet Hosts -- Application and
               Support", STD 3, RFC 1123, October 1989.

   [RFC2119]   S. Bradner, "Key words for use in RFCs to Indicate
               Requirements Levels", RFC 2119, BCP 14, March 1997.

   [RFC2389]   P. Hethmon and R. Elz, "Feature negotiation mechanism for
               the File Transfer Protocol", RFC 2389, August 1998.

   [RFC2428]   M. Allman, S. Ostermann and C. Metz, "FTP Extensions for
               IPv6 and NATs", RFC 2428, September 1998.

Informative References

   [RFC1639]   D. Piscitello, "FTP Operation Over Big Address Records
               (FOOBAR)", RFC 1639, June 1994.

   [RFC2228]   M. Horowitz and S. Lunt, "FTP Security Extensions", RFC
               2228, October 1997.

   [MURRAY]    P. Ford-Hutchinson, et al, "Securing FTP with TLS", IETF
               Internet-Draft, Work in process.



Lundberg                Expires November 28, 2002              [Page 14]


Internet-Draft        FTP Data Connection Assurance             May 2002


   [POSIX]     IEEE and The Open Group, "Base Specifications, Issue 6",
               IEEE Std 1003.1-2001, January 2001.

   The following references are only available electronically.  The URL
   given for each is believed to be the "original source."  At least one
   is known to be no longer available from that source.  All documents
   cited, however, are widely mirrored and known to be readily located
   using search engines.

   [DS]        D. Sacerdote, "Some problems with the File Transfer
               Protocol, a failure of common implementations, and
               suggestions for repair.",
               http://www.secnet.com/papers/ftp-paper.html, April 1996.

   [CERT1]     CERT Coordination Center, "Problems with the FTP PORT
               Command or Why You Don't Want Just Any PORT in a Storm",
               http://www.cert.org/tech_tips/ftp_port_attacks.html,
               April 1998.

   [JG]        J. Gerber, "FTP PASV "Pizza Thief" Exploit",
               http://www.infowar.com/iwftp/iw_sec/iw_sec_01.txt,
               February 1999.

   [GL]        G. Lundberg, "Security update for wu-ftpd 2.4.2 (beta 18)
               VR13", ftp://ftp.wu-ftpd.org/pub/wu-ftpd-
               attic/ANNOUNCE-2.4.2-beta-18-vr14, February 1999.

   [CVE]       Mitre Corp., "Common Vulnerabilities and Exposures",
               http://cve.mitre.org/, September 1999.

   [KS]        K. Seifried, "Problems with the FTP protocol",
               http://seifried.org/security/network/20010926-ftp-
               protocol.html, September 2001.

   [CERT2]     J. Lanza and J. Pickel, "File Transfer Protocol allows
               data connection hijacking via PASV mode race condition",
               http://www.kb.cert.org/vuls/id/2558, April 2002.

Author's Address

   Gregory A. Lundberg
   WU-FTPD Development Group
   1441 Elmdale Drive
   Dayton, OH 45409-1615
   US

   Phone: +1 937 299 7653
   Email: lundberg@vr.net



Lundberg                Expires November 28, 2002              [Page 15]


Internet-Draft        FTP Data Connection Assurance             May 2002


Annex A - Address Family Numbers

   The ESTP command, and the responses to both ESTA and ESTP, make use
   of the address family number.  For informational purposes, the
   following table shows the assignments for the Internet Protocols as
   of the writing of this document.  Refer to the IANA for a current
   list of all address family numbers.

      AF Number   Protocol
      ---------   --------
      1           Internet Protocol, Version 4 (STD 5, RFC 791)
      2           Internet Protocol, Version 6 (RFC 2460)

   Normative References for Address Family Numbers

      Since publication of [RFC1700], the IANA has moved to an on-line
      database for management of the assigned numbers.

      [IANA]      IANA, "Protocol Numbers and Assignment Services",
                  http://www.iana.org/numbers.html

      [RFC1700]   J. Reynolds and J Postel, "ASSIGNED NUMBERS", STD 2,
                  RFC 1700, October 1994.

Annex B - Network Address Formats

   The ESTP command, and the responses to both ESTA and ESTP, contain
   network addresses.  Each network protocol has a required form for
   representation of its addresses.  For informational purposes, the
   following table shows the formats for the Internet Procotols as of
   the writing of this document.

      AF Number   Address Format      Example
      ---------   --------------      -------
      1           dotted decimal      132.235.1.2
      2           IPv6 string         1080::8:800:200C:417A

   Normative References for Network Address Formats

      [RFC952]    K. Harrenstien, M. Stahl and E. Feinler, "DOD INTERNET
                  HOST TABLE SPECIFICATION", RFC 952, October 1985.

      [RFC2373]   R. Hinden and S. Deering, "IP Version 6 Addressing
                  Architecture", RFC 2373, July 1998.

Annex C - Examples of Use

   The following examples show typical uses of the ESTA and ESTP



Lundberg                Expires November 28, 2002              [Page 16]


Internet-Draft        FTP Data Connection Assurance             May 2002


   commands detecting an unauthorized connection to the passive socket.

   The assumption in these examples is that the TCP implementation on
   the host will establish multiple connections on a passive socket and
   return them to the implementation in the order established.  Thus, a
   second active connection will succeed without error.  Experience
   shows this assumption holds true for most existing implementations.

   The examples all use the following IPv4 addresses, which are assumed
   routable on the example network without address translation.

   user 192.168.1.2

      The user; either actively connecting, passively accepting
      connections, or not participating in the data transfer.

   active 172.16.3.4

      The Server-FTP process actively connecting (PORT mode).  The
      Server-FTP process will use TCP port 20, as assigned by IANA for
      this purpose.

   passive 172.16.5.6

      The Server-FTP process passively accepting connections (PASV
      mode).

   attacker 10.7.8.9

      The attacker actively connecting to the passive socket used in the
      particular example.  The example attacker uses TCP port 20 in a
      simplistic (and likely successful) attempt to thwart fire-wall
      filtering rules, and to fool the passive FTP implementation (as
      well as intrusion detection systems which may be monitoring the
      traffic) into believing it is an actual Server-FTP implementation.

C.1 PORT Mode

      The user prepares a passive socket and transmits its address to
      the active Server-DTP.  The user's DTP is now listening for
      connections on that socket.

      The window for the attacker to connect is now open.

   user --> active: PORT 192,168,1,2,12,34

      The attacker connects to the passive socket.




Lundberg                Expires November 28, 2002              [Page 17]


Internet-Draft        FTP Data Connection Assurance             May 2002


   active --> user: 200 Okay.

      The Server-DTP is now prepared to actively establish a connection
      to the specified passive socket.

   user --> active: ESTA

      The Server-DTP establishes the specified connection and returns
      the address of the active socket (the local address on the Server-
      DTP).

      The window for the attacker to connect has now closed.

   active --> user: 225 Connected from (|1|172.16.3.4|20|)

      The user's DTP accepts the first connection from the passive
      socket.  In this case, the connection from the attacker.  It
      retrieves the active socket address (the remote address) and
      compares it to the information returned from the Server-FTP
      process.

      Seeing a mismatch, the user immediately terminates the established
      data connection (to the attacker).  Note the passive socket, and
      the established connection from the Server-DTP queued upon it,
      remain.

      In most cases, however, since the passive socket is now "tainted,"
      the user will desire to also close the passive socket.  To do so,
      it must first instruct the Server-FTP process to abort the
      connection.

   user --> active: ABOR

      The Server-DTP closes its data connection.

   active --> user: 226 Connection closed, abort successful.

      The user may now close the passive socket and proceed with the
      remainder of its error-recovery process.

C.2 PASV Mode

      The user requests the Server-DTP create a passive socket and
      report its address.

   user --> passive: PASV

      The Server-DTP prepares the requested passive socket.  The Server-



Lundberg                Expires November 28, 2002              [Page 18]


Internet-Draft        FTP Data Connection Assurance             May 2002


      DTP is now listening for connections on that socket.

      The window for the attacker to connect is now open.

   passive --> user: 227 Listening on 172,16,5,6,78,90

      The attacker connects to the passive socket.

      The user establishes the specified connection and sends the
      address of the active socket (the address local) to the Server-FTP
      process.

      The window for the attacker to connect has now closed.

   user --> passive: ESTP |1|192.168.1.2|43210|

      The Server-DTP accepts the first connection from the passive
      socket.  In this case, the connection is from the attacker.  It
      retrieves the active socket address (the remote address) and
      returns it to the user.

   passive --> user: 225 Connected to (|1|10.7.8.9|20|)

      The user compares the address returned with the address assigned
      to its (local) active socket.  Seeing a mismatch, it terminates
      the data connection prior to issuing a command which would
      actually transmit data.

   user --> passive: ABOR

      The Server-DTP closes the data connection (to the attacker).  Note
      the passive socket remains, as does the user's connection queued
      upon it.

   passive --> user: 226 Connection closed, abort successful.

      The user proceeds with error recovery.  In most cases, since the
      passive socket is now "tainted," the user will close its data
      connection and instruct the Server-FTP process to close the
      passive socket and prepare another.

C.3 Server-to-Server Mode

      The user requests the Server-DTP create a passive socket and
      report its address.

   user --> passive: PASV




Lundberg                Expires November 28, 2002              [Page 19]


Internet-Draft        FTP Data Connection Assurance             May 2002


      The Server-DTP prepares the requested passive socket.  The Server-
      DTP is now listening for connections on that socket.

      The window for the attacker to connect is now open.

   passive --> user: 227 Listening on 172,16,5,6,78,90

      The user forwards the passive socket address to the second Server-
      FTP process.

   user --> active: PORT 172,16,5,6,78,90

      The attacker connects to the passive socket.

   active --> user: 200 Okay.

      The second Server-DTP is now prepared to actively establish a
      connection to the specified passive socket.

   user --> active: ESTA

      The second Server-DTP establishes the specified connection and
      returns the address of the active socket (the local address on the
      Server-DTP).

      The window for the attacker to connect has now closed.

   active --> user: 225 Connected from (|1|172.16.3.4|20|)

      The user forwards this information to the first Server-FTP
      process, informing it to accept a passive connection.

   user --> passive: ESTP |1|172.16.3.4|20|

      The Server-DTP accepts the first connection from the passive
      socket.  In this case, the connection is from the attacker.  It
      retrieves the active socket address (the remote address) and
      returns it to the user.

   passive --> user: 225 Connected to (|1|10.7.8.9|20|)

      The user compares the address returned with the address provided
      by the second Server-FTP process.  Seeing a mismatch, it proceeds
      to begin error-recovery by instructing the first Server-DTP to
      close the data connection (to the attacker).

   user --> passive: ABOR




Lundberg                Expires November 28, 2002              [Page 20]


Internet-Draft        FTP Data Connection Assurance             May 2002


      The first Server-DTP closes the data connection (to the attacker).
      Note the passive socket remains, as does the second Server-DTP's
      connection queued upon it.

   passive --> user: 226 Connection closed, abort successful.

      The user proceeds with error recovery.  In most cases, since the
      passive socket is now "tainted," the user will want to instruct
      the first Server-FTP process to close the passive socket and
      prepare another.  Before it does so, however, it must instruct the
      second Server-FTP process to close its data connection.

   user --> active: ABOR

      The second Server-DTP closes its data connection.

   active --> user: 226 Connection closed, abort successful.

      The user may now instruct the first Server-FTP process to close
      the passive socket and proceed with the remainder of the error-
      recovery process.

Annex D - Implementation Considerations

   The ESTA and ESTP commands present some interesting possibilities for
   implementers; three of which are discussed here.

   Experience shows the implementation of the TCP passive socket, on
   most hosts, queues incoming connections.  While in the queue, the
   connections are established and simply not being used by the
   application.  In [POSIX], for example, the accept function removes
   those connections from the queue, making them available to the
   application.  This operation usually involves no network activity; to
   the remote end-point, the status of the established connection
   (queued or accepted) is transparent.

   The formal specifications of the ESTA and ESTP commands indicate the
   implementation accepts the first connection queued upon the passive
   socket.  There may, however, be several connections queued.  One of
   them can be expected to be the intended connection.

D.1 Interactively Finding the Specified Connection

   In sessions involving a passive Server-DTP, the user could make use
   of the (probable) behavior of TCP passive sockets in an attempt to
   locate the desired data connection.

   Quite simply, after instructing the passive Server-FTP process to



Lundberg                Expires November 28, 2002              [Page 21]


Internet-Draft        FTP Data Connection Assurance             May 2002


   close the data connection (to the attacker), instead of immediately
   requesting the preparation of a new passive socket, the user could
   issue another ESTP command.

   Using this scheme, the user is instructing the passive Server-DTP to
   step through each connection queued on its passive socket until it
   (the user) finds one which is acceptable.

   The danger is that attackers can establish new connections faster
   than the user can process them interactively.  Thus, while this
   approach is viable, the user must guard against connection floods by
   imposing a limit (either by time or number of attempts) and
   proceeding on the basis of the last-accepted, mismatched connection
   once that limit has been reached.

   A user, seeking maximum robustness, may implement this approach.  The
   Server-FTP process should provide its own guards against connection
   flooding, either by using the automatic method outlined next, or by
   limiting (by time or attempts) the user's repeated use of the ESTP
   command.

D.2 Automatically Finding the Specified Connection

   The implementer will note that, when using passive mode, the desired
   address is known prior to accepting a connection from the passive
   socket.  For the user, this address was obtained from the response to
   the ESTA command.  For the passive Server-DTP it was given with the
   ESTP command.

   This presents the (rather appealing) possibility of stepping through
   each connection queued on the passive socket until one with the
   desired address is located.

   It has the advantage of not involving any network traffic, as is
   required when interactively seeking the correct connection, and could
   more quickly reduce resources used (wasted) by the attacker
   connections.

   Implementations should consider this approach.  Since this is being
   done with local operations, it is significantly faster than the
   interactive approach.  Connection floods, however, are still a
   possibility which must be guarded against.

D.3 Using a Common Passive Socket

   An extension of automatically finding the desired connection is the
   possibility of using a common passive socket for all data transfers.




Lundberg                Expires November 28, 2002              [Page 22]


Internet-Draft        FTP Data Connection Assurance             May 2002


   If the implementation issues with this approach can be addressed, it
   would greatly reduce the configuration issues faced by fire-wall
   administrators, and could significantly enhance both the usability
   and security of the FTP.

   Basically, the Server-DTP always has a passive socket prepared, and
   reports the address of that socket in response to all PASV, LPSV and
   EPSV commands.

   Those tempted to implement this approach are strongly cautioned to
   carefully consider all aspects, some of which are presented here.
   The discussion, however, is probably incomplete and bears careful
   analysis and further research by implementers.

   The most obvious problem is that the implementation needs some means
   to queue connections already accepted, but not yet matched to
   sessions by the ESTP command.  This could place a significant load on
   resources, especially when faced with a connection flood, and the
   total number of such connections possible may be restricted by host
   limitations.

   Another problem is that some connections will never be matched.  In
   terms of the passive race condition, they would represent attackers;
   but those connections could simply be the result of failed sessions.
   Queue-time limitations and other means might provide the solution to
   this problem.

   The appeal of this possibility, however, is so great that it bears
   further research.  If the implementation issues can be properly
   addressed, whether through protocol enhancements or through
   implementation guidelines, this could become the preferred mode of
   use for passive sockets in Server-FTP implementations.



















Lundberg                Expires November 28, 2002              [Page 23]


Internet-Draft        FTP Data Connection Assurance             May 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to The Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by The Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and 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.

Acknowledgement

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



















Lundberg                Expires November 28, 2002              [Page 24]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/