with Urgent data to preface two commands: ABOR (Abort Transfer)
and STAT (Status request).
The Urgent Pointer was used because, in a Unix implementation, the
receipt of a TCP packet marked as Urgent would result in the
execution of the SIGURG interrupt handler. This reliance on
interrupt handlers was necessary on systems that did not implement
select() or did not support multiple threads. TLS does not
support the notion of Urgent data.
When TLS is implemented as a security method in FTP, the server
SHOULD NOT rely on the use of SIGURG to process input on the
control channel during data transfers. The client MUST send all
data, including Telnet commands, across the TLS session.
15. Security Considerations
This document discusses how TLS may be used in conjunction with
[RFC-2228] to provide mechanisms for securing FTP sessions.
Discussions about security rationale and security properties are
contained within the [RFC-2228] document and are not repeated here.
15.1. Verification of Authentication Tokens
In this section, we assume that X.509 certificates will be used for
the TLS authentication. If some other identity token is used (e.g.,
kerberos tickets - see [RFC-2712]), then similar, mechanism-specific
considerations will need to be made.
15.1.1. Server Certificates
- Although it is entirely an implementation decision, it is
recommended that certificates used for server authentication of the
TLS session contain the server identification information in a
similar manner to those used for http servers (see [RFC-2818]).
- It is strongly recommended that the certificate used for server
authentication of Data connections be the same certificate as that
used for the corresponding Control connection. If different
certificates are to be used, there should be some other mechanism
that the client can use to cross-check the data and control
connection server identities.
- If Server Certificates are not used, then many of the security
benefits will not be realised. For Example, in an anonymous
Diffie-Hellman environment, there is no server identity
authentication, so there is little protection against man-in-the-
middle attacks.
15.1.2. Client Certificates
- Deciding which client certificates to allow and defining which
fields define what authentication information is entirely a server
implementation issue.
- However, it is strongly recommended that the certificate used for
client authentication of Data connections be the same certificate
as that used for the corresponding Control connection. If
different certificates are to be used, there should be some other
mechanism that the server can use to cross-check the data and
control connection client identities.
- If Client Certificates are not used, then many of the security
benefits will not be realised. For Example, it would still be
possible for a malicious client to hijack a data connection.
15.2. Addressing FTP Security Considerations [RFC-2577]
15.2.1. Bounce Attack
A bounce attack should be harder in a secured FTP environment
because:
- The FTP server that is being used to initiate a false connection
will always be a ’server’ in the TLS context. Therefore, only
services that act as ’clients’ in the TLS context could be
vulnerable. This would be a counter-intuitive way to implement
TLS on a service.
- The FTP server would detect that the authentication credentials
for the data connection are not the same as those for the
control connection, thus the server policies could be set to
drop the data connection.
- Genuine users are less likely to initiate such attacks when the
authentication is strong, and malicious users are less likely to
gain access to the FTP server if the authentication is not
easily subverted (password guessing, network tracing, etc...)
15.2.2. Restricting Access
This document presents a strong mechanism for solving the issue
raised in this section.
15.2.3. Protecting Passwords
The twin solutions of strong authentication and data confidentiality
ensure that this is not an issue when TLS is used to protect the
control session.
15.2.4. Privacy
The TLS protocol ensures data confidentiality by encryption. Privacy
(e.g., access to download logs, user profile information, etc...) is
outside the scope of this document (and [RFC-2577] presumably).
15.2.5. Protecting Usernames
This is not an issue when TLS is used as the primary authentication
mechanism.
15.2.6. Port Stealing
This specification will do little for the Denial of Service element
of this section; however, strong authentication on the data
connection will prevent unauthorised connections from retrieving or
submitting files. Of course, this is only the case where strong
client authentication is being used. If client certificates are not
used, then port stealing by a rogue client is still a problem. If no
strong authentication is in use at all (e.g., anonymous Diffie-
Hellman), then the port stealing problem will remain.
15.2.7. Software-Based Security Problems
Nothing in this specification will affect the discussion in this
section.
15.3. Issues with the CCC Command
Using the CCC command can create security issues. For a full
description, see the "CLEAR COMMAND CHANNEL (CCC)" section of
[RFC-2228]. Clients should not assume that a server will allow the
CCC command to be processed.
Server implementations may wish to refuse to process the CCC command
on a session that has not passed through some form of client
authentication (e.g., TLS client auth or FTP USER/PASS). This can
prevent anonymous clients from repeatedly requesting AUTH TLS
followed by CCC to tie up resources on the server.
16. IANA Considerations
{FTP-PORT} - The port assigned to the FTP control connection is 21.
17. Other Parameters
{TLS-PARM} - The parameter for the AUTH command to indicate that TLS
is required. To request the TLS protocol in accordance with this
document, the client MUST use ’TLS’
To maintain backward compatibility with older versions of this
document, the server SHOULD accept ’TLS-C’ as a synonym for ’TLS’.
Note: [RFC-2228] states that these parameters are case-
insensitive.
18. Scalability and Limits
There are no issues other than those concerned with the ability of
the server to refuse to have a complete TLS negotiation for each and
every data connection, which will allow servers to retain throughput
whilst using cycles only when necessary.
19. Applicability
This mechanism is generally applicable as a mechanism for securing
the FTP protocol. It is unlikely that anonymous FTP clients or
servers will require such security (although some might like the
authentication features without the confidentiality).
20. Acknowledgements
o Netscape Communications Corporation for the original SSL protocol.
o Eric Young for the SSLeay libraries.
o University of California, Berkeley for the original
implementations of FTP and ftpd, on which the initial
implementation of these extensions were layered.
o IETF CAT working group.
o IETF TLS working group.
o IETF FTPEXT working group.
o Jeff Altman for the ABOR and STAT discussion.
o The various people who have help author this document throughout
its protracted draft stages, namely Martin Carpenter, Eric Murray,
Tim Hudson, and Volker Wiegand.
21. References
21.1. Normative References
[RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, October 1985.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
2228, October 1997.
[RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC-2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for
the File Transfer Protocol", RFC 2389, August 1998.
21.2. Informative References
[RFC-1579] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February
1994.
[RFC-2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC-2577] Allman, M. and S. Ostermann, "FTP Security
Considerations", RFC 2577, May 1999.
[RFC-2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
[RFC-2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[RFC-2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC-3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
Contributors
Tim Hudson
RSA Data Security
Australia Pty Ltd
Phone: +61 7 3227 4444
EMail: tjh@rsasecurity.com.au
Volker Wiegand
SuSE Linux
EMail: wiegand@suse.de
Martin Carpenter
Verisign Ltd
EMail: mcarpenter@verisign.com
Eric Murray
Wave Systems Inc.
EMail: ericm@lne.com
Author’s Address
Paul Ford-Hutchinson
IBM UK Ltd
PO Box 31
Birmingham Road
Warwick
United Kingdom
Phone: +44 1926 462005
EMail: rfc4217@ford-hutchinson.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.