FTP Security Extensions
RFC 2228

Document Type RFC - Proposed Standard (October 1997; No errata)
Updates RFC 959
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2228 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
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).
Show full document text