FTP Security Extensions (RFC2228)
Original Publication Date: 1997-Oct-01
Included in the Prior Art Database: 2019-Feb-15
Internet Society Requests For Comment (RFCs)
M. Horowitz: AUTHOR [+1]
This document defines extensions to the FTP specification STD 9, 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 (C) The Internet Society (1997). All Rights Reserved.
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
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 ac...