rfc4217.txt

这是 关于FTP最新版本的PROFTP的 源码

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

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

                 - 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:

      - Deny any command before TLS is negotiated (this might cause
        problems if a SITE or some such command is required prior to
        login).

      - Deny certain commands before TLS is negotiated (e.g., USER,
        PASS, or ACCT).

      - Deny insecure USER commands for certain users (e.g., not
        ftp/anonymous).

      - Deny secure USER commands for certain users (e.g.,
        ftp/anonymous).

      - Define the level(s) of TLS to be allowed.

      - Define the CipherSuites allowed to be used (perhaps on a per
        host/domain/...  basis).

      - Allow TLS authentication as a substitute for local
        authentication.




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


      - 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