rfc2228.txt

伯克利做的SFTP安全文件传输协议

      data, it should respond with reply code 335.

      If the server accepts the security data, but does not require any
      additional data (i.e., the security data exchange has completed
      successfully), it must respond with reply code 235.

      If the server is responding with a 235 or 335 reply code, then it
      may include security data in the text part of the reply as
      specified above.





Horowitz & Lunt             Standards Track                     [Page 7]

RFC 2228                FTP Security Extensions             October 1997


      If the ADAT command returns an error, the security data exchange
      will fail, and the client must reset its internal security state.
      If the client becomes unsynchronized with the server (for example,
      the server sends a 234 reply code to an AUTH command, but the
      client has more data to transmit), then the client must reset the
      server's security state.

   PROTECTION BUFFER SIZE (PBSZ)

      The argument is a decimal integer representing the maximum size,
      in bytes, of the encoded data blocks to be sent or received during
      file transfer.  This number shall be no greater than can be
      represented in a 32-bit unsigned integer.

      This command allows the FTP client and server to negotiate a
      maximum protected buffer size for the connection.  There is no
      default size; the client must issue a PBSZ command before it can
      issue the first PROT command.

      The PBSZ command must be preceded by a successful security data
      exchange.

      If the server cannot parse the argument, or if it will not fit in
      32 bits, it should respond with a 501 reply code.

      If the server has not completed a security data exchange with the
      client, it should respond with a 503 reply code.

      Otherwise, the server must reply with a 200 reply code.  If the
      size provided by the client is too large for the server, it must
      use a string of the form "PBSZ=number" in the text part of the
      reply to indicate a smaller buffer size.  The client and the
      server must use the smaller of the two buffer sizes if both buffer
      sizes are specified.

   DATA CHANNEL PROTECTION LEVEL (PROT)

      The argument is a single Telnet character code specifying the data
      channel protection level.

      This command indicates to the server what type of data channel
      protection the client and server will be using.  The following
      codes are assigned:

         C - Clear
         S - Safe
         E - Confidential
         P - Private



Horowitz & Lunt             Standards Track                     [Page 8]

RFC 2228                FTP Security Extensions             October 1997


      The default protection level if no other level is specified is
      Clear.  The Clear protection level indicates that the data channel
      will carry the raw data of the file transfer, with no security
      applied.  The Safe protection level indicates that the data will
      be integrity protected.  The Confidential protection level
      indicates that the data will be confidentiality protected.  The
      Private protection level indicates that the data will be integrity
      and confidentiality protected.

      It is reasonable for a security mechanism not to provide all data
      channel protection levels.  It is also reasonable for a mechanism
      to provide more protection at a level than is required (for
      instance, a mechanism might provide Confidential protection, but
      include integrity-protection in that encoding, due to API or other
      considerations).

      The PROT command must be preceded by a successful protection
      buffer size negotiation.

      If the server does not understand the specified protection level,
      it should respond with reply code 504.

      If the current security mechanism does not support the specified
      protection level, the server should respond with reply code 536.

      If the server has not completed a protection buffer size
      negotiation with the client, it should respond with a 503 reply
      code.

      The PROT command will be rejected and the server should reply 503
      if no previous PBSZ command was issued.

      If the server is not willing to accept the specified protection
      level, it should respond with reply code 534.

      If the server is not able to accept the specified protection
      level, such as if a required resource is unavailable, it should
      respond with reply code 431.

      Otherwise, the server must reply with a 200 reply code to indicate
      that the specified protection level is accepted.

   CLEAR COMMAND CHANNEL (CCC)

      This command does not take an argument.






Horowitz & Lunt             Standards Track                     [Page 9]

RFC 2228                FTP Security Extensions             October 1997


      It is desirable in some environments to use a security mechanism
      to authenticate and/or authorize the client and server, but not to
      perform any integrity checking on the subsequent commands.  This
      might be used in an environment where IP security is in place,
      insuring that the hosts are authenticated and that TCP streams
      cannot be tampered, but where user authentication is desired.

      If unprotected commands are allowed on any connection, then an
      attacker could insert a command on the control stream, and the
      server would have no way to know that it was invalid.  In order to
      prevent such attacks, once a security data exchange completes
      successfully, if the security mechanism supports integrity, then
      integrity (via the MIC or ENC command, and 631 or 632 reply) must
      be used, until the CCC command is issued to enable non-integrity
      protected control channel messages.  The CCC command itself must
      be integrity protected.

      Once the CCC command completes successfully, if a command is not
      protected, then the reply to that command must also not be
      protected.  This is to support interoperability with clients which
      do not support protection once the CCC command has been issued.

      This command must be preceded by a successful security data
      exchange.

      If the command is not integrity-protected, the server must respond
      with a 533 reply code.

      If the server is not willing to turn off the integrity
      requirement, it should respond with a 534 reply code.

      Otherwise, the server must reply with a 200 reply code to indicate
      that unprotected commands and replies may now be used on the
      command channel.

   INTEGRITY PROTECTED COMMAND (MIC) and
   CONFIDENTIALITY PROTECTED COMMAND (CONF) and
   PRIVACY PROTECTED COMMAND (ENC)

      The argument field of MIC is a Telnet string consisting of a base
      64 encoded "safe" message produced by a security mechanism
      specific message integrity procedure.  The argument field of CONF
      is a Telnet string consisting of a base 64 encoded "confidential"
      message produced by a security mechanism specific confidentiality
      procedure.  The argument field of ENC is a Telnet string
      consisting of a base 64 encoded "private" message produced by a
      security mechanism specific message integrity and confidentiality
      procedure.



Horowitz & Lunt             Standards Track                    [Page 10]

RFC 2228                FTP Security Extensions             October 1997


      The server will decode and/or verify the encoded message.

      This command must be preceded by a successful security data
      exchange.

      A server may require that the first command after a successful
      security data exchange be CCC, and not implement the protection
      commands at all.  In this case, the server should respond with a
      502 reply code.

      If the server cannot base 64 decode the argument, it should
      respond with a 501 reply code.

      If the server has not completed a security data exchange with the
      client, it should respond with a 503 reply code.

      If the server has completed a security data exchange with the
      client using a mechanism which supports integrity, and requires a
      CCC command due to policy or implementation limitations, it should
      respond with a 503 reply code.

      If the server rejects the command because it is not supported by
      the current security mechanism, the server should respond with
      reply code 537.

      If the server rejects the command (if a checksum fails, for
      instance), it should respond with reply code 535.

      If the server is not willing to accept the command (if privacy is
      required by policy, for instance, or if a CONF command is received
      before a CCC command), it should respond with reply code 533.

      Otherwise, the command will be interpreted as an FTP command.  An
      end-of-line code need not be included, but if one is included, it
      must be a Telnet end-of-line code, not a local end-of-line code.

      The server may require that, under some or all circumstances, all
      commands be protected.  In this case, it should make a 533 reply
      to commands other than MIC, CONF, and ENC.

4.  Login Authorization

   The security data exchange may, among other things, establish the
   identity of the client in a secure way to the server.  This identity
   may be used as one input to the login authorization process.






Horowitz & Lunt             Standards Track                    [Page 11]

RFC 2228                FTP Security Extensions             October 1997


   In response to the FTP login commands (AUTH, PASS, ACCT), the server
   may choose to change the sequence of commands and replies specified
   by RFC 959 as follows.  There are also some new replies available.

   If the server is willing to allow the user named by the USER command
   to log in based on the identity established by the security data
   exchange, it should respond with reply code 232.

   If the security mechanism requires a challenge/response password, it
   should respond to the USER command with reply code 336.  The text
   part of the reply should contain the challenge.  The client must
   display the challenge to the user before prompting for the password
   in this case.  This is particularly relevant to more sophisticated
   clients or graphical user interfaces which provide dialog boxes or
   other modal input.  These clients should be careful not to prompt for
   the password before the username has been sent to the server, in case
   the user needs the challenge in the 336 reply to construct a valid
   password.

5.  New FTP Replies

   The new reply codes are divided into two classes.  The first class is
   new replies made necessary by the new FTP Security commands.  The
   second class is a new reply type to indicate protected replies.

   5.1.  New individual reply codes

      232 User logged in, authorized by security data exchange.
      234 Security data exchange complete.
      235 [ADAT=base64data]
            ; This reply indicates that the security data exchange
            ; completed successfully.  The square brackets are not
            ; to be included in the reply, but indicate that
            ; security data in the reply is optional.

      334 [ADAT=base64data]
            ; This reply indicates that the requested security mechanism
            ; is ok, and includes security data to be used by the client
            ; to construct the next command.  The square brackets are not
            ; to be included in the reply, but indicate that
            ; security data in the reply is optional.
      335 [ADAT=base64data]
            ; This reply indicates that the security data is
            ; acceptable, and more is required to complete the
            ; security data exchange.  The square brackets
            ; are not to be included in the reply, but indicate
            ; that security data in the reply is optional.




Horowitz & Lunt             Standards Track                    [Page 12]

RFC 2228                FTP Security Extensions             October 1997


      336 Username okay, need password.  Challenge is "...."
            ; The exact representation of the challenge should be chosen
            ; by the mechanism to be sensible to the human user of the
            ; system.

      431 Need some unavailable resource to process security.

      533 Command protection level denied for policy reasons.
      534 Request denied for policy reasons.
      535 Failed security check (hash, sequence, etc).
      536 Requested PROT level not supported by mechanism.
      537 Command protection level not supported by security mechanism.

   5.2.  Protected replies.

      One new reply type is introduced:

         6yz   Protected reply

            There are three reply codes of this type.  The first, reply
            code 631 indicates an integrity protected reply.  The
            second, reply code 632, indicates a confidentiality and
            integrity protected reply.  the third, reply code 633,
            indicates a confidentiality protected reply.

            The text part of a 631 reply is a Telnet string consisting
            of a base 64 encoded "safe" message produced by a security
            mechanism specific message integrity procedure.  The text
            part of a 632 reply is a Telnet string consisting of a base
            64 encoded "private" message produced by a security
            mechanism specific message confidentiality and integrity
            procedure.  The text part of a 633 reply is a Telnet string
            consisting of a base 64 encoded "confidential" message
            produced by a security mechanism specific message
            confidentiality procedure.

            The client will decode and verify the encoded reply.  How
            failures decoding or verifying replies are handled is
            implementation-specific.  An end-of-line code need not be
            included, but if one is included, it must be a Telnet end-
            of-line code, not a local end-of-line code.

            A protected reply may only be sent if a security data
            exchange has succeeded.

            The 63z reply may be a multiline reply.  In this case, the
            plaintext reply must be broken up into a number of
            fragments.  Each fragment must be protected, then base 64



Horowitz & Lunt             Standards Track                    [Page 13]

RFC 2228                FTP Security Extensions             October 1997


            encoded in order into a separate line of the multiline
            reply.  There need not be any correspondence between the
            line breaks in the plaintext reply and the encoded reply.
            Telnet end-of-line codes must appear in the plaintext of the
            encoded reply, except for the final end-of-line code, which
            is optional.

            The multiline reply must be formatted more strictly than the
            continuation specification in RFC 959.  In particular, each
            line before the last must be formed by the reply code,
            followed immediately by a hyphen, followed by a base 64
            encoded fragment of the reply.

            For example, if the plaintext reply is

               123-First line
               Second line
                 234 A line beginning with numbers
               123 The last line

            then the resulting protected reply could be any of the
            following (the first example has a line break only to fit
            within the margins):