rfc2228.txt

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

Network Working Group                                        M. Horowitz
Request for Comments: 2228                              Cygnus Solutions
Updates: 959                                                     S. Lunt
Category: Standards Track                                       Bellcore
                                                            October 1997

                        FTP Security Extensions

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

Abstract

   This document defines extensions to the FTP specification STD 9, RFC
   959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985).  These extensions
   provide strong authentication, integrity, and confidentiality on both
   the control and data channels with the introduction of new optional
   commands, replies, and file transfer encodings.

   The following new optional commands are introduced in this
   specification:

      AUTH (Authentication/Security Mechanism),
      ADAT (Authentication/Security Data),
      PROT (Data Channel Protection Level),
      PBSZ (Protection Buffer Size),
      CCC (Clear Command Channel),
      MIC (Integrity Protected Command),
      CONF (Confidentiality Protected Command), and
      ENC (Privacy Protected Command).

   A new class of reply types (6yz) is also introduced for protected
   replies.

   None of the above commands are required to be implemented, but
   interdependencies exist.  These dependencies are documented with the
   commands.

   Note that this specification is compatible with STD 9, RFC 959.



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


1.  Introduction

   The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959
   and in place on the Internet uses usernames and passwords passed in
   cleartext to authenticate clients to servers (via the USER and PASS
   commands).  Except for services such as "anonymous" FTP archives,
   this represents a security risk whereby passwords can be stolen
   through monitoring of local and wide-area networks.  This either aids
   potential attackers through password exposure and/or limits
   accessibility of files by FTP servers who cannot or will not accept
   the inherent security risks.

   Aside from the problem of authenticating users in a secure manner,
   there is also the problem of authenticating servers, protecting
   sensitive data and/or verifying its integrity.  An attacker may be
   able to access valuable or sensitive data merely by monitoring a
   network, or through active means may be able to delete or modify the
   data being transferred so as to corrupt its integrity.  An active
   attacker may also initiate spurious file transfers to and from a site
   of the attacker's choice, and may invoke other commands on the
   server.  FTP does not currently have any provision for the encryption
   or verification of the authenticity of commands, replies, or
   transferred data.  Note that these security services have value even
   to anonymous file access.

   Current practice for sending files securely is generally either:

      1.  via FTP of files pre-encrypted under keys which are manually
          distributed,

      2.  via electronic mail containing an encoding of a file encrypted
          under keys which are manually distributed,

      3.  via a PEM message, or

      4.  via the rcp command enhanced to use Kerberos.

   None of these means could be considered even a de facto standard, and
   none are truly interactive.  A need exists to securely transfer files
   using FTP in a secure manner which is supported within the FTP
   protocol in a consistent manner and which takes advantage of existing
   security infrastructure and technology.  Extensions are necessary to
   the FTP specification if these security services are to be introduced
   into the protocol in an interoperable way.







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


   Although the FTP control connection follows the Telnet protocol, and
   Telnet has defined an authentication and encryption option [TELNET-
   SEC], [RFC-1123] explicitly forbids the use of Telnet option
   negotiation over the control connection (other than Synch and IP).

   Also, the Telnet authentication and encryption option does not
   provide for integrity protection only (without confidentiality), and
   does not address the protection of the data channel.

2.  FTP Security Overview

   At the highest level, the FTP security extensions seek to provide an
   abstract mechanism for authenticating and/or authorizing connections,
   and integrity and/or confidentiality protecting commands, replies,
   and data transfers.

   In the context of FTP security, authentication is the establishment
   of a client's identity and/or a server's identity in a secure way,
   usually using cryptographic techniques.  The basic FTP protocol does
   not have a concept of authentication.

   Authorization is the process of validating a user for login.  The
   basic authorization process involves the USER, PASS, and ACCT
   commands.  With the FTP security extensions, authentication
   established using a security mechanism may also be used to make the
   authorization decision.

   Without the security extensions, authentication of the client, as
   this term is usually understood, never happens.  FTP authorization is
   accomplished with a password, passed on the network in the clear as
   the argument to the PASS command.  The possessor of this password is
   assumed to be authorized to transfer files as the user named in the
   USER command, but the identity of the client is never securely
   established.

   An FTP security interaction begins with a client telling the server
   what security mechanism it wants to use with the AUTH command.  The
   server will either accept this mechanism, reject this mechanism, or,
   in the case of a server which does not implement the security
   extensions, reject the command completely.  The client may try
   multiple security mechanisms until it requests one which the server
   accepts.  This allows a rudimentary form of negotiation to take
   place.  (If more complex negotiation is desired, this may be
   implemented as a security mechanism.)  The server's reply will
   indicate if the client must respond with additional data for the






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


   security mechanism to interpret.  If none is needed, this will
   usually mean that the mechanism is one where the password (specified
   by the PASS command) is to be interpreted differently, such as with a
   token or one-time password system.

   If the server requires additional security information, then the
   client and server will enter into a security data exchange.  The
   client will send an ADAT command containing the first block of
   security data.  The server's reply will indicate if the data exchange
   is complete, if there was an error, or if more data is needed.  The
   server's reply can optionally contain security data for the client to
   interpret.  If more data is needed, the client will send another ADAT
   command containing the next block of data, and await the server's
   reply.  This exchange can continue as many times as necessary.  Once
   this exchange completes, the client and server have established a
   security association.  This security association may include
   authentication (client, server, or mutual) and keying information for
   integrity and/or confidentiality, depending on the mechanism in use.

   The term "security data" here is carefully chosen.  The purpose of
   the security data exchange is to establish a security association,
   which might not actually include any authentication at all, between
   the client and the server as described above.  For instance, a
   Diffie-Hellman exchange establishes a secret key, but no
   authentication takes place.  If an FTP server has an RSA key pair but
   the client does not, then the client can authenticate the server, but
   the server cannot authenticate the client.

   Once a security association is established, authentication which is a
   part of this association may be used instead of or in addition to the
   standard username/password exchange for authorizing a user to connect
   to the server.  A username specified by the USER command is always
   required to specify the identity to be used on the server.

   In order to prevent an attacker from inserting or deleting commands
   on the control stream, if the security association supports
   integrity, then the server and client must use integrity protection
   on the control stream, unless it first transmits a CCC command to
   turn off this requirement.  Integrity protection is performed with
   the MIC and ENC commands, and the 63z reply codes.  The CCC command
   and its reply must be transmitted with integrity protection.
   Commands and replies may be transmitted without integrity (that is,
   in the clear or with confidentiality only) only if no security
   association is established, the negotiated security association does
   not support integrity, or the CCC command has succeeded.






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


   Once the client and server have negotiated with the PBSZ command an
   acceptable buffer size for encapsulating protected data over the data
   channel, the security mechanism may also be used to protect data
   channel transfers.

   Policy is not specified by this document.  In particular, client and
   server implementations may choose to implement restrictions on what
   operations can be performed depending on the security association
   which exists.  For example, a server may require that a client
   authorize via a security mechanism rather than using a password,
   require that the client provide a one-time password from a token,
   require at least integrity protection on the command channel, or
   require that certain files only be transmitted encrypted.  An
   anonymous ftp client might refuse to do file transfers without
   integrity protection in order to insure the validity of files
   downloaded.

   No particular set of functionality is required, except as
   dependencies described in the next section.  This means that none of
   authentication, integrity, or confidentiality are required of an
   implementation, although a mechanism which does none of these is not
   of much use.  For example, it is acceptable for a mechanism to
   implement only integrity protection, one-way authentication and/or
   encryption, encryption without any authentication or integrity
   protection, or any other subset of functionality if policy or
   technical considerations make this desirable.  Of course, one peer
   might require as a matter of policy stronger protection than the
   other is able to provide, preventing perfect interoperability.

3.  New FTP Commands

   The following commands are optional, but dependent on each other.
   They are extensions to the FTP Access Control Commands.

   The reply codes documented here are generally described as
   recommended, rather than required.  The intent is that reply codes
   describing the full range of success and failure modes exist, but
   that servers be allowed to limit information presented to the client.
   For example, a server might implement a particular security
   mechanism, but have a policy restriction against using it.  The
   server should respond with a 534 reply code in this case, but may
   respond with a 504 reply code if it does not wish to divulge that the
   disallowed mechanism is supported.  If the server does choose to use
   a different reply code than the recommended one, it should try to use
   a reply code which only differs in the last digit.  In all cases, the
   server must use a reply code which is documented as returnable from
   the command received, and this reply code must begin with the same
   digit as the recommended reply code for the situation.



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


   AUTHENTICATION/SECURITY MECHANISM (AUTH)

      The argument field is a Telnet string identifying a supported
      mechanism.  This string is case-insensitive.  Values must be
      registered with the IANA, except that values beginning with "X-"
      are reserved for local use.

      If the server does not recognize the AUTH command, it must respond
      with reply code 500.  This is intended to encompass the large
      deployed base of non-security-aware ftp servers, which will
      respond with reply code 500 to any unrecognized command.  If the
      server does recognize the AUTH command but does not implement the
      security extensions, it should respond with reply code 502.

      If the server does not understand the named security mechanism, it
      should respond with reply code 504.

      If the server is not willing to accept the named security
      mechanism, it should respond with reply code 534.

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

      If the server is willing to accept the named security mechanism,
      but requires security data, it must respond with reply code 334.

      If the server is willing to accept the named security mechanism,
      and does not require any security data, it must respond with reply
      code 234.

      If the server is responding with a 334 reply code, it may include
      security data as described in the next section.

      Some servers will allow the AUTH command to be reissued in order
      to establish new authentication.  The AUTH command, if accepted,
      removes any state associated with prior FTP Security commands.
      The server must also require that the user reauthorize (that is,
      reissue some or all of the USER, PASS, and ACCT commands) in this
      case (see section 4 for an explanation of "authorize" in this
      context).










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


   AUTHENTICATION/SECURITY DATA (ADAT)

      The argument field is a Telnet string representing base 64 encoded
      security data (see Section 9, "Base 64 Encoding").  If a reply
      code indicating success is returned, the server may also use a
      string of the form "ADAT=base64data" as the text part of the reply
      if it wishes to convey security data back to the client.

      The data in both cases is specific to the security mechanism
      specified by the previous AUTH command.  The ADAT command, and the
      associated replies, allow the client and server to conduct an
      arbitrary security protocol.  The security data exchange must
      include enough information for both peers to be aware of which
      optional features are available.  For example, if the client does
      not support data encryption, the server must be made aware of
      this, so it will know not to send encrypted command channel
      replies.  It is strongly recommended that the security mechanism
      provide sequencing on the command channel, to insure that commands
      are not deleted, reordered, or replayed.

      The ADAT command must be preceded by a successful AUTH command,
      and cannot be issued once a security data exchange completes
      (successfully or unsuccessfully), unless it is preceded by an AUTH
      command to reset the security state.

      If the server has not yet received an AUTH command, or if a prior
      security data exchange completed, but the security state has not
      been reset with an AUTH command, it should respond with reply code
      503.

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

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

      If the server accepts the security data, and requires additional