rfc2228.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

  631 base64(protect("123-First line\r\nSecond line\r\n  234 A line
  631-base64(protect("123-First line\r\n"))
  631-base64(protect("Second line\r\n"))
  631-base64(protect("  234 A line beginning with numbers\r\n"))
  631 base64(protect("123 The last line"))

  631-base64(protect("123-First line\r\nSecond line\r\n  234 A line b"))
  631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))

6.  Data Channel Encapsulation

   When data transfers are protected between the client and server (in
   either direction), certain transformations and encapsulations must be
   performed so that the recipient can properly decode the transmitted
   file.

   The sender must apply all protection services after transformations
   associated with the representation type, file structure, and transfer
   mode have been performed.  The data sent over the data channel is,
   for the purposes of protection, to be treated as a byte stream.

   When performing a data transfer in an authenticated manner, the
   authentication checks are performed on individual blocks of the file,
   rather than on the file as a whole. Consequently, it is possible for



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


   insertion attacks to insert blocks into the data stream (i.e.,
   replays) that authenticate correctly, but result in a corrupted file
   being undetected by the receiver. To guard against such attacks, the
   specific security mechanism employed should include mechanisms to
   protect against such attacks.  Many GSS-API mechanisms usable with
   the specification in Appendix I, and the Kerberos mechanism in
   Appendix II do so.

   The sender must take the input byte stream, and break it up into
   blocks such that each block, when encoded using a security mechanism
   specific procedure, will be no larger than the buffer size negotiated
   by the client with the PBSZ command.  Each block must be encoded,
   then transmitted with the length of the encoded block prepended as a
   four byte unsigned integer, most significant byte first.

   When the end of the file is reached, the sender must encode a block
   of zero bytes, and send this final block to the recipient before
   closing the data connection.

   The recipient will read the four byte length, read a block of data
   that many bytes long, then decode and verify this block with a
   security mechanism specific procedure.  This must be repeated until a
   block encoding a buffer of zero bytes is received.  This indicates
   the end of the encoded byte stream.

   Any transformations associated with the representation type, file
   structure, and transfer mode are to be performed by the recipient on
   the byte stream resulting from the above process.

   When using block transfer mode, the sender's (cleartext) buffer size
   is independent of the block size.

   The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE
   command if the current protection level is not at the level dictated
   by the server's security requirements for the particular file
   transfer.

   If any data protection services fail at any time during data transfer
   at the server end (including an attempt to send a buffer size greater
   than the negotiated maximum), the server will send a 535 reply to the
   data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE).










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


7.  Potential policy considerations

   While there are no restrictions on client and server policy, there
   are a few recommendations which an implementation should implement.

    - Once a security data exchange takes place, a server should require
      all commands be protected (with integrity and/or confidentiality),
      and it should protect all replies.  Replies should use the same
      level of protection as the command which produced them.  This
      includes replies which indicate failure of the MIC, CONF, and ENC
      commands.  In particular, it is not meaningful to require that
      AUTH and ADAT be protected; it is meaningful and useful to require
      that PROT and PBSZ be protected.  In particular, the use of CCC is
      not recommended, but is defined in the interest of
      interoperability between implementations which might desire such
      functionality.

    - A client should encrypt the PASS command whenever possible.  It is
      reasonable for the server to refuse to accept a non-encrypted PASS
      command if the server knows encryption is available.

    - Although no security commands are required to be implemented, it
      is recommended that an implementation provide all commands which
      can be implemented, given the mechanisms supported and the policy
      considerations of the site (export controls, for instance).

8.  Declarative specifications

   These sections are modelled after sections 5.3 and 5.4 of RFC 959,
   which describe the same information, except for the standard FTP
   commands and replies.

   8.1.  FTP Security commands and arguments

      AUTH <SP> <mechanism-name> <CRLF>
      ADAT <SP> <base64data> <CRLF>
      PROT <SP> <prot-code> <CRLF>
      PBSZ <SP> <decimal-integer> <CRLF>
      MIC <SP> <base64data> <CRLF>
      CONF <SP> <base64data> <CRLF>
      ENC <SP> <base64data> <CRLF>

      <mechanism-name> ::= <string>
      <base64data> ::= <string>
              ; must be formatted as described in section 9
      <prot-code> ::= C | S | E | P
      <decimal-integer> ::= any decimal integer from 1 to (2^32)-1




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


   8.2.  Command-Reply sequences

      Security Association Setup
         AUTH
            234
            334
            502, 504, 534, 431
            500, 501, 421
         ADAT
            235
            335
            503, 501, 535
            500, 501, 421
      Data protection negotiation commands
         PBSZ
            200
            503
            500, 501, 421, 530
         PROT
            200
            504, 536, 503, 534, 431
            500, 501, 421, 530
      Command channel protection commands
         MIC
            535, 533
            500, 501, 421
         CONF
            535, 533
            500, 501, 421
         ENC
            535, 533
            500, 501, 421
      Security-Enhanced login commands (only new replies listed)
         USER
            232
            336
      Data channel commands (only new replies listed)
         STOR
            534, 535
         STOU
            534, 535
         RETR
            534, 535








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


         LIST
            534, 535
         NLST
            534, 535
         APPE
            534, 535

      In addition to these reply codes, any security command can return
      500, 501, 502, 533, or 421.  Any ftp command can return a reply
      code encapsulated in a 631, 632, or 633 reply once a security data
      exchange has completed successfully.








































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


9.  State Diagrams

   This section includes a state diagram which demonstrates the flow of
   authentication and authorization in a security enhanced FTP
   implementation.  The rectangular blocks show states where the client
   must issue a command, and the diamond blocks show states where the
   server must issue a response.


          ,------------------,  USER
       __\| Unauthenticated  |_________\
      |  /| (new connection) |         /|
      |   `------------------'          |
      |            |                    |
      |            | AUTH               |
      |            V                    |
      |           / \                   |
      | 4yz,5yz  /   \   234            |
      |<--------<     >------------->.  |
      |          \   /               |  |
      |           \_/                |  |
      |            |                 |  |
      |            | 334             |  |
      |            V                 |  |
      |  ,--------------------,      |  |
      |  | Need Security Data |<--.  |  |
      |  `--------------------'   |  |  |
      |            |              |  |  |
      |            | ADAT         |  |  |
      |            V              |  |  |
      |           / \             |  |  |
      | 4yz,5yz  /   \   335      |  |  |
      `<--------<     >-----------'  |  |
                 \   /               |  |
                  \_/                |  |
                   |                 |  |
                   | 235             |  |
                   V                 |  |
           ,---------------.         |  |
      ,--->| Authenticated |<--------'  |  After the client and server
      |    `---------------'            |  have completed authenti-
      |            |                    |  cation, command must be
      |            | USER               |  integrity-protected if
      |            |                    |  integrity is available.  The
      |            |<-------------------'  CCC command may be issued to
      |            V                       relax this restriction.





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


      |           / \
      | 4yz,5yz  /   \   2yz
      |<--------<     >------------->.
      |          \   /               |
      |           \_/                |
      |            |                 |
      |            | 3yz             |
      |            V                 |
      |    ,---------------.         |
      |    | Need Password |         |
      |    `---------------'         |
      |            |                 |
      |            | PASS            |
      |            V                 |
      |           / \                |
      | 4yz,5yz  /   \   2yz         |
      |<--------<     >------------->|
      |          \   /               |
      |           \_/                |
      |            |                 |
      |            | 3yz             |
      |            V                 |
      |    ,--------------.          |
      |    | Need Account |          |
      |    `--------------'          |
      |            |                 |
      |            | ACCT            |
      |            V                 |
      |           / \                |
      | 4yz,5yz  /   \   2yz         |
      `<--------<     >------------->|
                 \   /               |
                  \_/                |
                   |                 |
                   | 3yz             |
                   V                 |
             ,-------------.         |
             | Authorized  |/________|
             | (Logged in) |\
             `-------------'











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


10.  Base 64 Encoding

   Base 64 encoding is the same as the Printable Encoding described in
   Section 4.3.2.4 of [RFC-1421], except that line breaks must not be
   included. This encoding is defined as follows.

   Proceeding from left to right, the bit string resulting from the
   mechanism specific protection routine is encoded into characters
   which are universally representable at all sites, though not
   necessarily with the same bit patterns (e.g., although the character
   "E" is represented in an ASCII-based system as hexadecimal 45 and as