rfc4217.txt

一个用QT开发的FTP客户端

      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.




Ford-Hutchinson             Standards Track                    [Page 22]

RFC 4217                 Securing FTP with TLS              October 2005


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.





Ford-Hutchinson             Standards Track                    [Page 23]

RFC 4217                 Securing FTP with TLS              October 2005


   - 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.



Ford-Hutchinson             Standards Track                    [Page 24]

RFC 4217                 Securing FTP with TLS              October 2005


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.







Ford-Hutchinson             Standards Track                    [Page 25]

RFC 4217                 Securing FTP with TLS              October 2005


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.



Ford-Hutchinson             Standards Track                    [Page 26]

RFC 4217                 Securing FTP with TLS              October 2005


   [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.























Ford-Hutchinson             Standards Track                    [Page 27]

RFC 4217                 Securing FTP with TLS              October 2005


Contributors

   Tim Hudson
   RSA Data Security
   Australia Pty Ltd

   Phone: [phone]
   EMail: [e-mail]


   Volker Wiegand
   SuSE Linux

   EMail: [e-mail]


   Martin Carpenter
   Verisign Ltd

   EMail: [e-mail]


   Eric Murray
   Wave Systems Inc.

   EMail: [e-mail]

Author's Address

   Paul Ford-Hutchinson
   IBM UK Ltd
   PO Box 31
   Birmingham Road
   Warwick
   United Kingdom

   Phone: [phone]
   EMail: [e-mail]













Ford-Hutchinson             Standards Track                    [Page 28]

RFC 4217                 Securing FTP with TLS              October 2005


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-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Ford-Hutchinson             Standards Track                    [Page 29]