FTP Security Extensions
updates
- rfc-959 — File Transfer Protocol
Extracted elements (29)
New security mechanisms are encouraged to be implemented as GSSAPI mechanisms rather than native FTP security mechanisms so that existing FTP implementations can support them with minimal code changes, and so the mechanism is reusable by other GSSAPI-based protocols such as IMAP with no additional specification work.
No specific combination of authentication, integrity, or confidentiality is required by this specification. Partial implementations (e.g., integrity only, one-way authentication, or encryption without integrity) are explicitly permitted to accommodate policy constraints such as export controls.
Telnet authentication and encryption options were not used for FTP security because RFC 1123 explicitly forbids Telnet option negotiation over the FTP control connection (other than Synch and IP). Additionally, the Telnet mechanism does not provide integrity-only protection or address data channel security.
The CCC command exists to support environments where IP-layer security already provides host authentication and TCP stream integrity, making per-command integrity redundant. Without CCC, once integrity is negotiated it cannot be disabled, which would prevent interoperability in such deployments.
Once CCC succeeds, if a command is not protected, its reply MUST also not be protected, to support interoperability with clients that do not support protection after CCC has been issued. Replies should use the same level of protection as the command that produced them.
These extensions are designed to be compatible with RFC 959 (STD 9). Servers that do not recognize the AUTH command will respond with 500 (unrecognized command), consistent with the large deployed base of non-security-aware FTP servers. Servers that recognize but do not implement the extensions should respond with 502.
If the server is willing to accept the named security mechanism and requires security data, it MUST respond with reply code 334. If it does not require any security data, it MUST respond with reply code 234.
It is not appropriate for a server to reject a command containing a base 64 encoding simply because it is long (assuming the decoding is otherwise well-formed). Case MUST NOT be ignored when reading commands and replies containing base 64 encodings.
Once a security data exchange completes successfully, if the mechanism supports integrity, integrity protection via MIC or ENC commands (and 631 or 632 replies) MUST be used on the control channel until a successful CCC command is issued. If the CCC command is not integrity-protected, the server MUST respond with 533.
The ADAT command MUST be preceded by a successful AUTH command and cannot be issued once a security data exchange has completed unless reset by a new AUTH command. If the server has not received AUTH or if a prior exchange completed without reset, it should respond with reply code 503.
The AUTH command, if accepted, removes any state associated with prior FTP Security commands. The server MUST also require that the user reauthorize (reissue some or all of USER, PASS, and ACCT) when a new AUTH is accepted.
The PROT command MUST be preceded by a successful PBSZ negotiation; the server MUST reject PROT with a 503 reply if no previous PBSZ command was issued. A successful PROT command yields a 200 reply.
The sender MUST break the input byte stream into blocks such that each encoded block is no larger than the PBSZ-negotiated buffer size, encode each block with the security mechanism, and prepend the 4-byte encoded-block length. All protection services are applied after FTP representation/structure/mode transformations.
The server MUST reply 534 to STOR, STOU, RETR, LIST, NLST, or APPE if the current data channel protection level does not meet the server's security requirements for that transfer. If data protection services fail during transfer (including receipt of an oversized buffer), the server MUST send a 535 reply to the data transfer command.
A new 6yz reply class is introduced for protected replies: 631 (integrity protected), 632 (integrity and confidentiality protected), 633 (confidentiality protected). The text part is a base 64 encoded message produced by the security mechanism. Multiline 6yz replies must protect and encode each fragment separately, with each continuation line formed as 'code-base64fragment'.
MIC carries a base 64 encoded integrity-protected ('safe') message; CONF carries a base 64 encoded confidentiality-protected ('confidential') message; ENC carries a base 64 encoded message with both integrity and confidentiality ('private'). The server decodes and verifies the argument and then interprets the content as an FTP command.
New error reply codes introduced: 431 (required resource unavailable), 533 (command protection level denied by policy), 534 (request denied by policy), 535 (failed security check — hash, sequence, etc.), 536 (requested PROT level not supported by mechanism), 537 (command protection level not supported by mechanism).
New reply codes introduced include: 232 (user logged in via security exchange), 234 (security data exchange complete, no data needed), 235 (security data exchange completed successfully), 334 (mechanism accepted, security data required), 335 (security data accepted, more required), 336 (challenge/response password required).
The ADAT command carries base 64 encoded security data enabling an arbitrary multi-round security protocol exchange. The server replies 235 when the exchange completes successfully (optionally including 'ADAT=base64data' in reply text), 335 when more data is needed, or 501/535/503 on errors.
The AUTH command initiates security negotiation by specifying a case-insensitive mechanism name. The server responds with 234 (accepted, no data needed), 334 (accepted, data required), 504 (unknown mechanism), 534 (policy rejection), or 431 (resource unavailable). Mechanism names must be IANA-registered except those prefixed with 'X-'.
The CCC (Clear Command Channel) command takes no argument and allows reverting the control channel to unprotected mode after a security association is established. It must itself be transmitted with integrity protection, and its reply must also be integrity protected.
The PBSZ command negotiates the maximum encoded block size (a decimal integer up to 2^32-1 bytes) for data channel protection. There is no default; the client must issue PBSZ before any PROT command. If the server's maximum is smaller, it signals this via 'PBSZ=number' in the 200 reply text, and both sides must use the smaller value.
The PROT command sets the data channel protection level with a single character: C (Clear — raw data, no security), S (Safe — integrity protected), E (Confidential — confidentiality protected), or P (Private — integrity and confidentiality protected). The default level if no PROT is issued is Clear.
This document establishes an IANA registry for FTP security mechanism names used with the AUTH command. Names are case-insensitive strings; those beginning with 'X-' are reserved for local use without registration. Appendices specify two initial values: GSSAPI and KERBEROS_V4.
Block-level authentication of data channel transfers enables insertion attacks: an adversary can replay individually valid blocks into the data stream producing a corrupted but undetected result. The security mechanism must include sequencing or anti-replay protections; many GSS-API mechanisms and the Kerberos mechanism in the appendices do so.
Third-party file transfers (server-to-server) cannot be secured using these extensions because no control connection exists between the two servers over which to exchange ADAT tokens, making it impossible to establish a security context between them.
The authentication/authorization flow has six states: Unauthenticated (new connection), Need Security Data (awaiting ADAT after 334), Authenticated (security exchange complete via 234 or 235), Need Password (USER accepted, password required), Need Account, and Authorized (logged in). AUTH transitions from Unauthenticated to Need Security Data or directly to Authenticated; ADAT cycles through Need Security Data on 335 until 235 triggers Authenticated.
Base 64 encoding used in ADAT, MIC, CONF, ENC commands and 63z replies uses a 64-character IA5 subset ([A-Z][a-z][0-9]+/) with '=' padding, encoding 6 bits per character in 24-bit groups. Unlike RFC 1421, line breaks MUST NOT be included. Implementations must read the entire line before processing, as encodings may be arbitrarily long.
Protected data channel blocks are framed as a 4-byte unsigned integer length (most significant byte first) followed by the security-mechanism-encoded data block. The sender MUST encode a final zero-byte block and transmit it before closing the data connection to signal end-of-stream to the recipient.