rfc4217.txt

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

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

   - 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