Request for Comments: 4217 IBM UK Ltd
Category: Standards Track October 2005
Securing FTP with TLS
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 (2005).
Abstract
This document describes a mechanism that can be used by FTP clients
and servers to implement security and authentication using the TLS
protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and
the extensions to the FTP protocol defined by RFC 2228, "FTP Security
Extensions". It describes the subset of the extensions that are
required and the parameters to be used, discusses some of the policy
issues that clients and servers will need to take, considers some of
the implications of those policies, and discusses some expected
behaviours of implementations to allow interoperation. This document
is intended to provide TLS support for FTP in a similar way to that
provided for SMTP in RFC 2487, "SMTP Service Extension for Secure
SMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading
to TLS Within HTTP/1.1.".
This specification is in accordance with RFC 959, "File Transfer
Protocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.",
and RFC 2228, "FTP Security Extensions".
Table of Contents
1. Introduction ....................................................3
2. Audience ........................................................5
3. Overview ........................................................5
4. Session Negotiation on the Control Port .........................5
4.1. Client Wants a Secured Session .............................5
4.2. Server Wants a Secured Session .............................6
5. Clearing the Control Port .......................................6
6. Response to the FEAT Command ....................................7
7. Data Connection Behaviour .......................................8
8. Mechanisms for the AUTH Command .................................9
9. Data Connection Security ........................................9
10. A Discussion of Negotiation Behaviour .........................11
10.1. The Server’s View of the Control Connection ..............11
10.2. The Server’s View of the Data Connection .................12
10.3. The Client’s View of the Control Connection ..............14
10.4. The Client’s View of the Data Connection .................15
11. Who Negotiates What, Where, and How ...........................15
11.1. Do we protect at all? ....................................15
11.2. What level of protection do we use on the Control
connection? ..............................................15
11.3. Do we protect data connections in general? ...............16
11.4. Is protection required for a particular data transfer? ...16
11.5. What level of protection is required for a
particular data ..........................................16
12. Timing Diagrams ...............................................16
12.1. Establishing a Protected Session .........................17
12.2. Establishing a Protected Session Without a
Password Request .........................................18
12.3. Establishing a Protected Session and then
Clearing with the CCC ....................................19
12.4. A Standard Data Transfer Without Protection ..............20
12.5. A Firewall-Friendly Data Transfer Without Protection .....20
12.6. A Standard Data Transfer with Protection .................21
12.7. A Firewall-Friendly Data Transfer with Protection ........21
13. Discussion of the REIN Command ................................22
14. Discussion of the STAT and ABOR Commands ......................22
15. Security Considerations .......................................23
15.1. Verification of Authentication Tokens ....................23
15.1.1. Server Certificates ...............................23
15.1.2. Client Certificates ...............................23
15.2. Addressing FTP Security Considerations [RFC-2577] ........24
15.2.1. Bounce Attack .....................................24
15.2.2. Restricting Access ................................24
15.2.3. Protecting Passwords ..............................24
15.2.4. Privacy ...........................................24
15.2.5. Protecting Usernames ..............................24
15.2.6. Port Stealing .....................................25
15.2.7. Software-Based Security Problems ..................25
15.3. Issues with the CCC Command ..............................25
16. IANA Considerations ...........................................25
17. Other Parameters ..............................................25
18. Scalability and Limits ........................................26
19. Applicability .................................................26
20. Acknowledgements ..............................................26
21. References ....................................................26
21.1. Normative References .....................................26
21.2. Informative References ...................................27
1. Introduction
This document describes how three other documents should be combined
to provide a useful, interoperable, and secure file transfer
protocol. Those documents are:
RFC 959 [RFC-959]
The description of the Internet File Transfer Protocol.
RFC 2246 [RFC-2246]
The description of the Transport Layer Security protocol
(developed from the Netscape Secure Sockets Layer (SSL)
protocol version 3.0).
RFC 2228 [RFC-2228]
Extensions to the FTP protocol to allow negotiation of security
mechanisms to allow authentication, confidentiality, and
message integrity.
This document is intended to provide TLS support for FTP in a similar
way to that provided for SMTP in RFC 3207 [RFC-3207] and HTTP in RFC
2817 [RFC-2817].
The security extensions to FTP in [RFC-2228] offer a comprehensive
set of commands and responses that can be used to add authentication,
integrity, and confidentiality to the FTP protocol. The TLS protocol
is a popular (due to its wholesale adoption in the HTTP environment)
mechanism for generally securing a socket connection.
Although TLS is not the only mechanism for securing file transfer, it
does offer some of the following positive attributes:
- Flexible security levels. TLS can support confidentiality,
integrity, authentication, or some combination of all of these.
During a session, this allows clients and servers to dynamically
decide on the level of security required for a particular data
transfer.
- Ability to provide strong authentication of the FTP server.
- It is possible to use TLS identities to authenticate client
users and client hosts.
- Formalised public key management. By use of well established
client identity mechanisms (supported by TLS) during the
authentication phase, certificate management may be built into a
central function. Whilst this may not be desirable for all uses
of secured file transfer, it offers advantages in certain
structured environments.
- Co-existence and interoperation with authentication mechanisms
that are already in place for the HTTPS protocol. This allows
web browsers to incorporate secure file transfer using the same
infrastructure that has been set up to allow secure web
browsing.
The TLS protocol is a development of the Netscape Communication
Corporation’s SSL protocol and this document can be used to allow the
FTP protocol to be used with either SSL or TLS. The actual protocol
used will be decided by the negotiation of the protected session by
the TLS/SSL layer. This document will only refer to the TLS
protocol; however, it is understood that the Client and Server MAY
actually be using SSL if they are so configured.
There are many ways in which these three protocols can be combined.
This document selects one method by which FTP can operate securely,
while providing both flexibility and interoperation. This
necessitates a brief description of the actual negotiation mechanism,
a detailed description of the required policies and practices, and a
discussion of the expected behaviours of clients and servers to allow
either party to impose their security requirements on the FTP
session.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" that
appear in this document are to be interpreted as described in
[RFC-2119].
2. Audience
This document is aimed at developers who wish to implement TLS as a
security mechanism to secure FTP clients and/or servers.
Systems administrators and architects should be fully aware of the
security implications discussed in [RFC-2228], which need to be
considered when choosing an implementation of this protocol and
configuring it to provide their required security.
3. Overview
A full description of the FTP security protocol enhancements is
contained in [RFC-2228]. This document describes how the AUTH, PROT,
PBSZ, and CCC commands, defined therein, should be implemented with
the TLS protocol.
In summary, an FTP session is established on the normal control port.
A client requests TLS with the AUTH command and then decides if it
wishes to secure the data connections by use of the PBSZ and PROT
commands. Should a client wish to make the control connection revert
back into plaintext (for example, once the authentication phase is
completed), then the CCC command can be used.
Implementation of this protocol extension does not ensure that each
and every session and data transfer is secure, it merely provides the
tools that allow a client and/or server to negotiate an acceptable or
required level of security for that given session or data transfer.
However, it is possible to have a server implementation that is
capable of refusing to operate in an insecure fashion.
4. Session Negotiation on the Control Port
The server listens on the normal FTP control port {FTP-PORT} and the
session initiation is not secured at all. Once the client wishes to
secure the session, the AUTH command is sent and the server MAY then
allow TLS negotiation to take place.
4.1. Client Wants a Secured Session
If a client wishes to attempt to secure a session, then it SHOULD, in
accordance with [RFC-2228], send the AUTH command with the parameter
requesting TLS {TLS-PARM} (’TLS’).
The client then needs to behave according to its policies depending
on the response received from the server and also the result of the
TLS negotiation. A client that receives an AUTH rejection MAY choose
to continue with the session unprotected if it so desires.
4.2. Server Wants a Secured Session
The FTP protocol does not allow a server to directly dictate client
behaviour; however, the same effect can be achieved by refusing to
accept certain FTP commands until the session is secured to a level
that is acceptable to the server.
In either case, ’234’ is the server response to an ’AUTH TLS’ command
that it will honour.
The ’334’ response, as defined in [RFC-2228], implies that an ADAT
exchange will follow. This document does not use the ADAT command
and so the ’334’ reply is incorrect.
The FTP protocol insists that a USER command be used to identify the
entity attempting to use the ftp server. Although the TLS
negotiation may be providing authentication information, the USER
command MUST still be issued by the client. However, it will be a
server implementation issue to decide which credentials to accept and
what consistency checks to make between the client cert used and the
parameter on the USER command.
[RFC-2228] states that the user must reauthorize (that is, reissue
some or all of the USER, PASS, and ACCT commands) following an AUTH
command. Additionally, this document specifies that all other
transfer parameters (other than the AUTH parameter) must be reset,
almost as if a REIN command was issued.
Reset transfer parameters after the AUTH command, including (but
are not limited to): user identity, default data ports, TYPE,
STRU, MODE, and current working directory.
5. Clearing the Control Port
There are circumstances in which it may be desirable to protect the
control connection only during part of the session and then to revert
back to a plaintext connection. This is often due to the limitations
of boundary devices such as NAT and firewalls, which expect to be
able to examine the content of the control connection in order to
modify their behaviour.
Typically the AUTH, USER, PASS, PBSZ, and PROT commands would be
protected within the TLS protocol and then the CCC command would be
issued to return to a plaintext socket state. This has important
Security Issues (which are discussed in the Security Considerations
section), but this document describes how the command should be used,
if the client and server still wish to use it after having considered
the issues.
When a server receives the CCC command, it should behave as follows:
If the server does not accept CCC commands (or does not understand
them), then a 500 reply should be sent.
Otherwise, if the control connection is not protected with TLS,
then a 533 reply should be sent.
Otherwise, if the server does not wish to allow the control
connection to be cleared at this time, then a 534 reply should be
sent.
Otherwise, the server is accepting the CCC command and should do
the following:
o Send a 200 reply.
o Shutdown the TLS session on the socket and leave it open.
o Continue the control connection in plaintext, expecting the
next command from the client to be in plaintext.
o Not accept any more PBSZ or PROT commands. All subsequent
data transfers must be protected with the current PROT
settings.
6. Response to the FEAT Command
The FEAT command (introduced in [RFC-2389]) allows servers with
additional features to advertise these to a client by responding to
the FEAT command. If a server supports the FEAT command, then it
MUST advertise supported AUTH, PBSZ, and PROT commands in the reply,
as described in section 3.2 of [RFC-2389]. Additionally, the AUTH
command should have a reply that identifies ’TLS’ as one of the
possible parameters to AUTH. It is not necessary to identify the
’TLS-C’ synonym separately.
Example reply (in the same style as [RFC-2389])
C> FEAT
S> 211-Extensions supported
S> AUTH TLS
S> PBSZ
S> PROT
S> 211 END
7. Data Connection Behaviour
The Data Connection in the FTP model can be used in one of three
ways. (Note: These descriptions are not necessarily placed in exact
chronological order, but do describe the steps required. See
diagrams later for clarification.)
i) Classic FTP client/server data exchange
- The client obtains a port; sends the port number to
the server; the server connects to the client. The
client issues a send or receive request to the server
on the control connection and the data transfer
commences on the data connection.
ii) Firewall-Friendly client/server data exchange (as
discussed in [RFC-1579]) using the PASV command to reverse
the direction of the data connection.
- The client requests that the server open a port; the
server obtains a port and returns the address and
port number to the client; the client connects to the
server on this port. The client issues a send or
receive request on the control connection, and the
data transfer commences on the data connection.
iii) Client-initiated server/server data exchange (proxy or
PASV connections).
- The client requests that server A opens a port;
server A obtains a port and returns it to the client;
the client sends this port number to server B.
Server B connects to server A. The client sends a
send or receive request to server A and the
complement to server B and the data transfer
commences. In this model, server A is the proxy or
PASV host and is a client for the Data Connection to
server B.
For i) and ii), the FTP client MUST be the TLS client and the FTP
server MUST be the TLS server.
That is to say, it does not matter which side initiates the
connection with a connect() call or which side reacts to the
connection via the accept() call; the FTP client, as defined in
[RFC-959], is always the TLS client, as defined in [RFC-2246].
In scenario iii), there is a problem in that neither server A nor
server B is the TLS client, given the fact that an FTP server must
act as a TLS server for Firewall-Friendly FTP [RFC-1579]. Thus, this
is explicitly excluded in the security extensions document [RFC-2228]
and in this document.
8. Mechanisms for the AUTH Command
The AUTH command takes a single parameter to define the security
mechanism to be negotiated. As the SSL/TLS protocols self-negotiate
their levels, there is no need to distinguish between SSL and TLS in
the application layer. The mechanism name for negotiating TLS is the
character string identified in {TLS-PARM}. This allows the client
and server to negotiate TLS on the control connection without
altering the protection of the data channel. To protect the data
channel as well, the PBSZ command, followed by the PROT command
sequence, MUST be used.
Note: The data connection state MAY be modified by the client issuing
the PROT command with the new desired level of data channel
protection and the server replying in the affirmative. This data
channel protection negotiation can happen at any point in the session
(even straight after a PORT or PASV command) and as often as is
required.
See also Section 16, "IANA Considerations".
9. Data Connection Security
The Data Connection security level is determined by the PROT command.
The PROT command, as specified in [RFC-2228], allows client/server
negotiation of the security level of the data connection. Once a
PROT command has been issued by the client and accepted by the
server returning the ’200’ reply, the security of subsequent data
connections MUST be at that level until another PROT command is
issued and accepted; the session ends and a REIN command is
issued, or the security of the session (via an AUTH command) is
re-negotiated.
Data Connection Security Negotiation (the PROT command)
Note: In line with [RFC-2228], there is no facility for securing
the Data connection with an insecure Control connection.
Specifically, the PROT command MUST be preceded by a PBSZ command,
and a PBSZ command MUST be preceded by a successful security data
exchange (the TLS negotiation in this case).
The command defined in [RFC-2228] to negotiate data connection
security is the PROT command. As defined, there are four values
that the PROT command parameter can take.
’C’ - Clear - neither Integrity nor Privacy
’S’ - Safe - Integrity without Privacy
’E’ - Confidential - Privacy without Integrity
’P’ - Private - Integrity and Privacy
As TLS negotiation encompasses (and exceeds) the Safe /
Confidential / Private distinction, only Private (use TLS) and
Clear (don’t use TLS) are used.
For TLS, the data connection can have one of two security levels.
1) Clear (requested by ’PROT C’)
2) Private (requested by ’PROT P’)
With ’Clear’ protection level, the data connection is made without
TLS. Thus, the connection is unauthenticated and has no
confidentiality or integrity. This might be the desired behaviour
for servers sending file lists, pre-encrypted data, or non-
sensitive data (e.g., for anonymous FTP servers).
If the data connection security level is ’Private’, then a TLS
negotiation must take place on the data connection to the
satisfaction of the Client and Server prior to any data being
transmitted over the connection. The TLS layers of the Client and
Server will be responsible for negotiating the exact TLS Cipher
Suites that will be used (and thus the eventual security of the
connection).
In addition, the PBSZ (protection buffer size) command, as
detailed in [RFC-2228], is compulsory prior to any PROT command.
This document also defines a data channel encapsulation mechanism
for protected data buffers. For FTP-TLS, which appears to the FTP
application as a streaming protection mechanism, this is not
required. Thus, the PBSZ command MUST still be issued, but must
have a parameter of ’0’ to indicate that no buffering is taking
place and the data connection should not be encapsulated.
Note that PBSZ 0 is not in the grammar of [RFC-2228], section 8.1,
where it is stated:
PBSZ <sp> <decimal-integer> <CRLF> <decimal-integer> ::= any
decimal integer from 1 to (2^32)-1
However, it should be noted that using a value of ’0’ to mean a
streaming protocol is a reasonable use of ’0’ for that parameter
and is not ambiguous.
Initial Data Connection Security
The initial state of the data connection MUST be ’Clear’ (this is
the behaviour as indicated by [RFC-2228]).
10. A Discussion of Negotiation Behaviour
As [RFC-2228] allows security qualities to be negotiated, enabled,
and disabled dynamically, this can make implementations seem quite
complex. However, in any given instance the behaviour should be
quite straightforward. Either the server will be enforcing the
policy of the server host or it will be providing security
capabilities requested by the client. Either the client will be
conforming to the server’s policy or will be endeavouring to provide
the capabilities that the user desires.
10.1. The Server’s View of the Control Connection