rfc2228.txt

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

   hexadecimal C5 in an EBCDIC-based system, the local significance of
   the two representations is equivalent).

   A 64-character subset of International Alphabet IA5 is used, enabling
   6 bits to be represented per printable character.  (The proposed
   subset of characters is represented identically in IA5 and ASCII.)
   The character "=" signifies a special processing function used for
   padding within the printable encoding procedure.

   The encoding process represents 24-bit groups of input bits as output
   strings of 4 encoded characters.  Proceeding from left to right
   across a 24-bit input group output from the security mechanism
   specific message protection procedure, each 6-bit group is used as an
   index into an array of 64 printable characters, namely "[A-Z][a-
   z][0-9]+/".  The character referenced by the index is placed in the
   output string.  These characters are selected so as to be universally
   representable, and the set excludes characters with particular
   significance to Telnet (e.g., "<CR>", "<LF>", IAC).

   Special processing is performed if fewer than 24 bits are available
   in an input group at the end of a message.  A full encoding quantum
   is always completed at the end of a message.  When fewer than 24
   input bits are available in an input group, zero bits are added (on
   the right) to form an integral number of 6-bit groups.  Output
   character positions which are not required to represent actual input
   data are set to the character "=".  Since all canonically encoded
   output is an integral number of octets, only the following cases can
   arise: (1) the final quantum of encoding input is an integral
   multiple of 24 bits; here, the final unit of encoded output will be
   an integral multiple of 4 characters with no "=" padding, (2) the
   final quantum of encoding input is exactly 8 bits; here, the final
   unit of encoded output will be two characters followed by two "="
   padding characters, or (3) the final quantum of encoding input is
   exactly 16 bits; here, the final unit of encoded output will be three
   characters followed by one "=" padding character.





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


   Implementors must keep in mind that the base 64 encodings in ADAT,
   MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily
   long.  Thus, the entire line must be read before it can be processed.
   Several successive reads on the control channel may be necessary.  It
   is not appropriate to for a server to reject a command containing a
   base 64 encoding simply because it is too long (assuming that the
   decoding is otherwise well formed in the context in which it was
   sent).

   Case must not be ignored when reading commands and replies containing
   base 64 encodings.

11.  Security Considerations

   This entire document deals with security considerations related to
   the File Transfer Protocol.

   Third party file transfers cannot be secured using these extensions,
   since a security context cannot be established between two servers
   using these facilities (no control connection exists between servers
   over which to pass ADAT tokens).  Further work in this area is
   deferred.

12.  Acknowledgements

   I would like to thank the members of the CAT WG, as well as all
   participants in discussions on the "[e-mail]" mailing list,
   for their contributions to this document.  I would especially like to
   thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut,
   Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Karri Balk
   for their contributions to this work.  Of course, without Steve Lunt,
   the author of the first six revisions of this document, it would not
   exist at all.

13.  References

   [TELNET-SEC] Borman, D., "Telnet Authentication and Encryption
      Option", Work in Progress.

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

   [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic
      Mail: Part I: Message Encryption and Authentication Procedures",
      RFC 1421, February 1993.






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


14.  Author's Address

   Marc Horowitz
   Cygnus Solutions
   955 Massachusetts Avenue
   Cambridge, MA 02139

   Phone: [phone]
   EMail: [e-mail]










































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


Appendix I: Specification under the GSSAPI

   In order to maximise the utility of new security mechanisms, it is
   desirable that new mechanisms be implemented as GSSAPI mechanisms
   rather than as FTP security mechanisms.  This will enable existing
   ftp implementations to support the new mechanisms more easily, since
   little or no code will need to be changed.  In addition, the
   mechanism will be usable by other protocols, such as IMAP, which are
   built on top of the GSSAPI, with no additional specification or
   implementation work needed by the mechanism designers.

   The security mechanism name (for the AUTH command) associated with
   all mechanisms employing the GSSAPI is GSSAPI.  If the server
   supports a security mechanism employing the GSSAPI, it must respond
   with a 334 reply code indicating that an ADAT command is expected
   next.

   The client must begin the authentication exchange by calling
   GSS_Init_Sec_Context, passing in 0 for input_context_handle
   (initially), and a targ_name equal to output_name from
   GSS_Import_Name called with input_name_type of Host-Based Service and
   input_name_string of "ftp@hostname" where "hostname" is the fully
   qualified host name of the server with all letters in lower case.
   (Failing this, the client may try again using input_name_string of
   "host@hostname".) The output_token must then be base 64 encoded and
   sent to the server as the argument to an ADAT command.  If
   GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client
   must expect a token to be returned in the reply to the ADAT command.
   This token must subsequently be passed to another call to
   GSS_Init_Sec_Context.  In this case, if GSS_Init_Sec_Context returns
   no output_token, then the reply code from the server for the previous
   ADAT command must have been 235.  If GSS_Init_Sec_Context returns
   GSS_S_COMPLETE, then no further tokens are expected from the server,
   and the client must consider the server authenticated.

   The server must base 64 decode the argument to the ADAT command and
   pass the resultant token to GSS_Accept_Sec_Context as input_token,
   setting acceptor_cred_handle to NULL (for "use default credentials"),
   and 0 for input_context_handle (initially).  If an output_token is
   returned, it must be base 64 encoded and returned to the client by
   including "ADAT=base64string" in the text of the reply.  If
   GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be
   235, and the server must consider the client authenticated.  If
   GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code
   must be 335.  Otherwise, the reply code should be 535, and the text
   of the reply should contain a descriptive error message.





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


   The chan_bindings input to GSS_Init_Sec_Context and
   GSS_Accept_Sec_Context should use the client internet address and
   server internet address as the initiator and acceptor addresses,
   respectively.  The address type for both should be GSS_C_AF_INET. No
   application data should be specified.

   Since GSSAPI supports anonymous peers to security contexts, it is
   possible that the client's authentication of the server does not
   actually establish an identity.

   The procedure associated with MIC commands, 631 replies, and Safe
   file transfers is:

      GSS_Wrap for the sender, with conf_flag == FALSE

      GSS_Unwrap for the receiver

   The procedure associated with ENC commands, 632 replies, and Private
   file transfers is:

      GSS_Wrap for the sender, with conf_flag == TRUE
      GSS_Unwrap for the receiver

   CONF commands and 633 replies are not supported.

   Both the client and server should inspect the value of conf_avail to
   determine whether the peer supports confidentiality services.

   When the security state is reset (when AUTH is received a second
   time, or when REIN is received), this should be done by calling the
   GSS_Delete_sec_context function.

Appendix II:  Specification under Kerberos version 4

   The security mechanism name (for the AUTH command) associated with
   Kerberos Version 4 is KERBEROS_V4.  If the server supports
   KERBEROS_V4, it must respond with a 334 reply code indicating that an
   ADAT command is expected next.

   The client must retrieve a ticket for the Kerberos principal
   "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name
   of "ftp", an instance equal to the first part of the canonical host
   name of the server with all letters in lower case (as returned by
   krb_get_phost(3)), the server's realm name (as returned by
   krb_realmofhost(3)), and an arbitrary checksum.  The ticket must then
   be base 64 encoded and sent as the argument to an ADAT command.





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


   If the "ftp" principal name is not a registered principal in the
   Kerberos database, then the client may fall back on the "rcmd"
   principal name (same instance and realm).  However, servers must
   accept only one or the other of these principal names, and must not
   be willing to accept either.  Generally, if the server has a key for
   the "ftp" principal in its srvtab, then that principal only must be
   used, otherwise the "rcmd" principal only must be used.

   The server must base 64 decode the argument to the ADAT command and
   pass the result to krb_rd_req(3).  The server must add one to the
   checksum from the authenticator, convert the result to network byte
   order (most significant byte first), and sign it using
   krb_mk_safe(3), and base 64 encode the result.  Upon success, the
   server must reply to the client with a 235 code and include
   "ADAT=base64string" in the text of the reply.  Upon failure, the
   server should reply 535.

   Upon receipt of the 235 reply from the server, the client must parse
   the text of the reply for the base 64 encoded data, decode it,
   convert it from network byte order, and pass the result to
   krb_rd_safe(3).  The client must consider the server authenticated if
   the resultant checksum is equal to one plus the value previously
   sent.

   The procedure associated with MIC commands, 631 replies, and Safe
   file transfers is:

      krb_mk_safe(3) for the sender
      krb_rd_safe(3) for the receiver

   The procedure associated with ENC commands, 632 replies, and Private
   file transfers is:

      krb_mk_priv(3) for the sender
      krb_rd_priv(3) for the receiver

   CONF commands and 633 replies are not supported.

   Note that this specification for KERBEROS_V4 contains no provision
   for negotiating alternate means for integrity and confidentiality
   routines.  Note also that the ADAT exchange does not convey whether
   the peer supports confidentiality services.

   In order to stay within the allowed PBSZ, implementors must take note
   that a cleartext buffer will grow by 31 bytes when processed by
   krb_mk_safe(3) and will grow by 26 bytes when processed by
   krb_mk_priv(3).




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


Full Copyright Statement

   Copyright (C) The Internet Society (1997).  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 implmentation may be prepared, copied, published
   andand 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 DISCLAIMS 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.
























Horowitz & Lunt             Standards Track                    [Page 27]