Network Working Group P. Ford-Hutchinson
Request for Comments: 4217 IBM UK Ltd
Category: Standards Track October 2005
Network Working Group P. Ford-Hutchinson
Request for Comments: 4217 IBM UK Ltd
Category: Standards Track October 2005
Securing FTP with TLS
使用TLS保护FTP
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.".
本文档描述了一种机制，FTP客户端和服务器可以使用RFC 2246“TLS协议版本1.0”定义的TLS协议和RFC 2228“FTP安全扩展”定义的FTP协议扩展来实现安全性和身份验证。它描述了所需扩展的子集和要使用的参数，讨论了客户端和服务器将需要采取的一些策略问题，考虑了这些策略的一些含义，并讨论了实现的一些预期行为以允许互操作。本文档旨在以与RFC 2487“用于传输层安全的安全SMTP的SMTP服务扩展”和RFC 2817“在HTTP/1.1中升级到TLS”中为SMTP提供类似的方式为FTP提供TLS支持。
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".
本规范符合RFC 959“文件传输协议”。它依赖于RFC 2246“TLS协议1.0版”和RFC 2228“FTP安全扩展”。
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
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
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
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]
RFC 959[RFC-959]
The description of the Internet File Transfer Protocol.
Internet文件传输协议的说明。
RFC 2246 [RFC-2246]
RFC 2246[RFC-2246]
The description of the Transport Layer Security protocol (developed from the Netscape Secure Sockets Layer (SSL) protocol version 3.0).
传输层安全协议的说明（由Netscape安全套接字层（SSL）协议3.0版开发）。
RFC 2228 [RFC-2228]
RFC 2228[RFC-2228]
Extensions to the FTP protocol to allow negotiation of security mechanisms to allow authentication, confidentiality, and message integrity.
对FTP协议的扩展，允许协商安全机制，以实现身份验证、机密性和消息完整性。
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].
本文档旨在以类似于RFC 3207[RFC-3207]中SMTP和RFC 2817[RFC-2817]中HTTP的方式为FTP提供TLS支持。
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.
[RFC-2228]中的FTP安全扩展提供了一套全面的命令和响应，可用于为FTP协议添加身份验证、完整性和机密性。TLS协议是一种普遍用于保护套接字连接安全的机制（因为它在HTTP环境中被大量采用）。
Although TLS is not the only mechanism for securing file transfer, it does offer some of the following positive attributes:
虽然TLS不是保护文件传输的唯一机制，但它确实提供了以下一些积极的特性：
- 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.
- 灵活的安全级别。TLS可以支持机密性、完整性、身份验证或所有这些的组合。在会话期间，这允许客户端和服务器动态决定特定数据传输所需的安全级别。
- Ability to provide strong authentication of the FTP server.
- 能够提供FTP服务器的强身份验证。
- It is possible to use TLS identities to authenticate client users and client hosts.
- 可以使用TLS身份验证客户端用户和客户端主机。
- 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.
- 正式公开密钥管理。通过在身份验证阶段使用完善的客户端身份机制（由TLS支持），可以将证书管理构建到中心功能中。虽然这可能不适合所有安全文件传输的使用，但它在某些结构化环境中具有优势。
- 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.
- 与HTTPS协议已有的身份验证机制共存和互操作。这允许web浏览器使用已设置为允许安全web浏览的相同基础结构合并安全文件传输。
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.
TLS协议是Netscape Communication Corporation SSL协议的发展，本文档可用于允许FTP协议与SSL或TLS一起使用。实际使用的协议将由TLS/SSL层对受保护会话的协商决定。本文件仅参考TLS协议；但是，可以理解的是，如果客户机和服务器是这样配置的，那么它们实际上可能正在使用SSL。
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.
这三种协议可以通过多种方式组合在一起。本文档选择了一种FTP安全运行的方法，同时提供了灵活性和互操作性。这需要对实际协商机制进行简要描述，详细描述所需的策略和实践，并讨论客户端和服务器的预期行为，以允许任何一方将其安全要求强加给FTP会话。
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].
本文件中出现的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
This document is aimed at developers who wish to implement TLS as a security mechanism to secure FTP clients and/or servers.
本文档面向希望将TLS作为安全机制来实现FTP客户端和/或服务器安全的开发人员。
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.
系统管理员和架构师应充分了解[RFC-2228]中讨论的安全影响，在选择本协议的实现并配置它以提供其所需的安全性时，需要考虑这些影响。
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.
[RFC-2228]中包含FTP安全协议增强功能的完整说明。本文档描述了如何使用TLS协议实现其中定义的AUTH、PROT、PBSZ和CCC命令。
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.
总之，在正常控制端口上建立FTP会话。客户端使用AUTH命令请求TLS，然后决定是否希望使用PBSZ和PROT命令保护数据连接。如果客户端希望将控制连接恢复为纯文本（例如，一旦身份验证阶段完成），则可以使用CCC命令。
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.
此协议扩展的实现并不能确保每个会话和数据传输都是安全的，它只提供了允许客户端和/或服务器协商给定会话或数据传输的可接受或所需安全级别的工具。但是，也可以使用能够拒绝以不安全方式操作的服务器实现。
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.
服务器在正常FTP控制端口{FTP-port}上侦听，会话启动根本不安全。一旦客户端希望保护会话，将发送AUTH命令，然后服务器将允许TLS协商进行。
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').
如果客户机希望尝试保护会话，则应根据[RFC-2228]发送带有参数请求TLS{TLS-PARM}（'TLS'）的AUTH命令。
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.
然后，客户机需要根据从服务器收到的响应以及TLS协商的结果，根据其策略进行操作。接收到身份验证拒绝的客户端如果愿意，可以选择继续不受保护的会话。
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.
FTP协议不允许服务器直接指令客户端行为；但是，在会话安全到服务器可以接受的级别之前，可以通过拒绝接受某些FTP命令来实现相同的效果。
In either case, '234' is the server response to an 'AUTH TLS' command that it will honour.
在任何一种情况下，“234”都是服务器对其将执行的“AUTH TLS”命令的响应。
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.
[RFC-2228]中定义的“334”响应意味着随后将进行ADAT交换。此文档未使用ADAT命令，因此“334”答复不正确。
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.
FTP协议坚持使用用户命令来标识试图使用FTP服务器的实体。尽管TLS协商可能提供身份验证信息，但用户命令仍必须由客户端发出。但是，决定接受哪些凭据以及在使用的客户端证书和用户命令上的参数之间进行哪些一致性检查将是服务器实现的问题。
[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.
[RFC-2228]规定用户必须在执行AUTH命令后重新授权（即重新发出部分或全部user、PASS和ACCT命令）。此外，本文档规定必须重置所有其他传输参数（AUTH参数除外），就像发出REIN命令一样。
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.
AUTH命令后重置传输参数，包括（但不限于）：用户标识、默认数据端口、类型、STRU、模式和当前工作目录。
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.
在某些情况下，可能希望仅在部分会话期间保护控制连接，然后恢复到纯文本连接。这通常是由于NAT和防火墙等边界设备的限制，它们希望能够检查控制连接的内容以修改其行为。
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.
通常，AUTH、USER、PASS、PBSZ和PROT命令将在TLS协议中受到保护，然后发出CCC命令以返回明文套接字状态。这有一些重要的安全问题（在“安全注意事项”一节中讨论），但如果客户机和服务器在考虑了这些问题后仍希望使用该命令，则本文档将介绍如何使用该命令。
When a server receives the CCC command, it should behave as follows:
当服务器收到CCC命令时，其行为应如下所示：
If the server does not accept CCC commands (or does not understand them), then a 500 reply should be sent.
如果服务器不接受CCC命令（或不理解它们），则应发送500条回复。
Otherwise, if the control connection is not protected with TLS, then a 533 reply should be sent.
否则，如果控制连接不受TLS保护，则应发送533回复。
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.
否则，如果服务器不希望此时清除控制连接，则应发送534回复。
Otherwise, the server is accepting the CCC command and should do the following:
否则，服务器将接受CCC命令，并应执行以下操作：
o Send a 200 reply.
o 发送200回复。
o Shutdown the TLS session on the socket and leave it open.
o 关闭套接字上的TLS会话并使其保持打开状态。
o Continue the control connection in plaintext, expecting the next command from the client to be in plaintext.
o 继续以明文形式进行控制连接，希望客户端的下一个命令是明文形式。
o Not accept any more PBSZ or PROT commands. All subsequent data transfers must be protected with the current PROT settings.
o 不再接受任何PBSZ或PROT命令。所有后续数据传输必须使用当前保护设置进行保护。
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.
FEAT命令（在[RFC-2389]中介绍）允许具有附加功能的服务器通过响应FEAT命令向客户机公布这些功能。如果服务器支持FEAT命令，则必须在回复中公布支持的AUTH、PBSZ和PROT命令，如[RFC-2389]第3.2节所述。此外，AUTH命令应该有一个应答，将“TLS”标识为AUTH的可能参数之一。没有必要单独识别“TLS-C”同义词。
Example reply (in the same style as [RFC-2389])
回复示例（与[RFC-2389]样式相同）
C> FEAT S> 211-Extensions supported S> AUTH TLS S> PBSZ S> PROT S> 211 END
C> FEAT S>211扩展支持S>AUTH TLS>PBSZ S>PROT S>211 END
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.)
FTP模型中的数据连接可以通过以下三种方式之一使用。（注意：这些描述不一定按确切的时间顺序排列，但确实描述了所需的步骤。请参阅后面的图表以了解说明。）
i) Classic FTP client/server data exchange
i) 经典FTP客户端/服务器数据交换
- 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.
ii）防火墙友好型客户机/服务器数据交换（如[RFC-1579]中所述），使用PASV命令反转数据连接方向。
- 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).
iii）客户端启动的服务器/服务器数据交换（代理或PASV连接）。
- 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.
- 客户端请求服务器A打开一个端口；服务器A获取端口并将其返回给客户端；客户端将此端口号发送到服务器B。服务器B连接到服务器A。客户端向服务器A发送发送发送或接收请求，并向服务器B发送补充，然后开始数据传输。在此模型中，服务器A是代理或PASV主机，是与服务器B进行数据连接的客户端。
For i) and ii), the FTP client MUST be the TLS client and the FTP server MUST be the TLS server.
对于i）和ii），FTP客户端必须是TLS客户端，FTP服务器必须是TLS服务器。
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].
也就是说，无论哪一方使用connect（）调用启动连接，还是哪一方通过accept（）调用对连接作出反应；[RFC-959]中定义的FTP客户端始终是[RFC-2246]中定义的TLS客户端。
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.
在场景iii）中，存在一个问题，即服务器a和服务器B都不是TLS客户端，因为FTP服务器必须充当防火墙友好型FTP的TLS服务器[RFC-1579]。因此，安全扩展文档[RFC-2228]和本文档中明确排除了这一点。
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.
AUTH命令使用单个参数来定义要协商的安全机制。由于SSL/TLS协议自行协商其级别，因此无需在应用层中区分SSL和TLS。协商TLS的机制名称是{TLS-PARM}中标识的字符串。这允许客户端和服务器协商控制连接上的TLS，而不改变数据通道的保护。为了保护数据通道，必须使用PBSZ命令，后跟PROT命令序列。
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.
注意：数据连接状态可以由客户端发出PROT命令，并具有新的所需数据通道保护级别和服务器响应的方式来修改。此数据通道保护协商可以在会话中的任何时间点（甚至在端口或PASV命令发出后）进行，并且可以根据需要随时进行。
See also Section 16, "IANA Considerations".
另见第16节“IANA注意事项”。
The Data Connection security level is determined by the PROT command.
数据连接安全级别由PROT命令确定。
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.
[RFC-2228]中指定的PROT命令允许客户机/服务器协商数据连接的安全级别。一旦客户端发出PROT命令并被返回“200”回复的服务器接受，后续数据连接的安全性必须处于该级别，直到发出并接受另一个PROT命令；会话结束并发出REIN命令，或者（通过AUTH命令）重新协商会话的安全性。
Data Connection Security Negotiation (the PROT command)
数据连接安全协商（PROT命令）
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).
注：根据[RFC-2228]，不存在通过不安全的控制连接保护数据连接的设施。具体来说，PROT命令前面必须有PBSZ命令，PBSZ命令前面必须有成功的安全数据交换（本例中为TLS协商）。
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.
[RFC-2228]中定义的协商数据连接安全的命令是PROT命令。根据定义，PROT命令参数可以接受四个值。
'C' - Clear - neither Integrity nor Privacy
“C”-清晰-既不完整也不隐私
'S' - Safe - Integrity without Privacy
“S”-安全-没有隐私的完整性
'E' - Confidential - Privacy without Integrity
“E”-机密-没有完整性的隐私
'P' - Private - Integrity and Privacy
“P”-隐私-完整性和隐私
As TLS negotiation encompasses (and exceeds) the Safe / Confidential / Private distinction, only Private (use TLS) and Clear (don't use TLS) are used.
由于TLS协商包含（并超过）安全/机密/私有的区别，因此仅使用私有（使用TLS）和透明（不使用TLS）。
For TLS, the data connection can have one of two security levels.
对于TLS，数据连接可以具有两个安全级别之一。
1) Clear (requested by 'PROT C')
1) 清除（由“保护C”要求）
2) Private (requested by 'PROT P')
2) 专用（由“保护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).
使用“清除”保护级别，数据连接不使用TLS。因此，连接未经验证，不具有机密性或完整性。对于发送文件列表、预加密数据或非敏感数据的服务器（例如，匿名FTP服务器），这可能是理想的行为。
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).
如果数据连接安全级别为“专用”，则在通过连接传输任何数据之前，必须在数据连接上进行TLS协商，以使客户端和服务器满意。客户机和服务器的TLS层将负责协商将使用的确切TLS密码套件（以及连接的最终安全性）。
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.
此外，如[RFC-2228]中所述，PBSZ（保护缓冲区大小）命令在任何PROT命令之前是强制性的。本文档还定义了受保护数据缓冲区的数据通道封装机制。对于FTP-TLS（FTP应用程序将其视为流保护机制），这不是必需的。因此，仍然必须发出PBSZ命令，但必须具有参数“0”，以指示未发生缓冲，并且不应封装数据连接。
Note that PBSZ 0 is not in the grammar of [RFC-2228], section 8.1, where it is stated:
注意，PBSZ 0不在[RFC-2228]第8.1节的语法中，其中规定：
PBSZ <sp> <decimal-integer> <CRLF> <decimal-integer> ::= any
decimal integer from 1 to (2^32)-1
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.
但是，应注意，使用值“0”表示流式传输协议是对该参数使用“0”的合理方式，并且没有歧义。
Initial Data Connection Security
初始数据连接安全性
The initial state of the data connection MUST be 'Clear' (this is the behaviour as indicated by [RFC-2228]).
数据连接的初始状态必须为“清除”（这是[RFC-2228]所指示的行为）。
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.
由于[RFC-2228]允许动态协商、启用和禁用安全质量，这会使实现看起来相当复杂。然而，在任何给定的情况下，行为都应该非常简单。服务器将强制执行服务器主机的策略，或者提供客户端请求的安全功能。客户机将遵守服务器的策略，或者将努力提供用户所需的功能。
A server MAY have a policy statement somewhere that might:
服务器的某个位置可能有一个策略语句，该语句可能：
- Deny any command before TLS is negotiated (this might cause problems if a SITE or some such command is required prior to login).
- 在协商TLS之前拒绝任何命令（如果在登录之前需要站点或某些此类命令，则可能会导致问题）。
- Deny certain commands before TLS is negotiated (e.g., USER, PASS, or ACCT).
- 在协商TLS之前拒绝某些命令（例如，USER、PASS或ACCT）。
- Deny insecure USER commands for certain users (e.g., not ftp/anonymous).
- 拒绝对某些用户使用不安全的用户命令（例如，非ftp/匿名）。
- Deny secure USER commands for certain users (e.g., ftp/anonymous).
- 拒绝某些用户的安全用户命令（例如ftp/匿名）。
- Define the level(s) of TLS to be allowed.
- 定义允许的TLS级别。
- Define the CipherSuites allowed to be used (perhaps on a per host/domain/... basis).
- 定义允许使用的密码套件（可能基于每个主机/域/…）。
- Allow TLS authentication as a substitute for local authentication.
- 允许TLS身份验证作为本地身份验证的替代。
- Define data connection policies (see next section).
- 定义数据连接策略（请参阅下一节）。
It is possible that the TLS negotiation may not be completed satisfactorily for the server, in which case it can be one of these states.
对于服务器，TLS协商可能无法令人满意地完成，在这种情况下，可能是以下状态之一。
The TLS negotiation failed completely
TLS谈判完全失败
In this case, the control connection should still be in an unprotected mode and the server SHOULD issue an unprotected '421' reply to end the session.
在这种情况下，控制连接仍应处于未受保护的模式，服务器应发出未受保护的“421”回复以结束会话。
The TLS negotiation completed successfully, but the server decides that the session parameters are not acceptable (e.g., Distinguished Name in the client certificate is not permitted to use the server).
TLS协商已成功完成，但服务器决定会话参数不可接受（例如，不允许客户端证书中的可分辨名称使用服务器）。
In this case, the control connection should still be in a protected state, so the server MAY either continue to refuse to service commands or issue a protected '421' reply and close the connection.
在这种情况下，控制连接仍应处于受保护状态，因此服务器可能会继续拒绝服务命令，或发出受保护的“421”回复并关闭连接。
The TLS negotiation failed during the TLS handshake
TLS握手期间TLS协商失败
In this case, the control connection is in an unknown state and the server SHOULD simply drop the control connection.
在这种情况下，控制连接处于未知状态，服务器只需断开控制连接即可。
The server code will be responsible for implementing the required policies and ensuring that the client is prevented from circumventing the chosen security by refusing to service those commands that are against policy.
服务器代码将负责实现所需的策略，并确保通过拒绝服务那些违反策略的命令来防止客户端绕过所选的安全性。
The server can take one of four basic views of the data connection.
服务器可以获取数据连接的四个基本视图之一。
1 - Don't allow encryption at all (in which case the PROT command should not allow any value other than 'C' - if it is allowed at all).
1-根本不允许加密（在这种情况下，PROT命令不应允许除“C”以外的任何值，如果允许的话）。
2 - Allow the client to choose protection or not.
2-允许客户端选择是否保护。
3 - Insist on data protection (in which case the PROT command must be issued prior to the first attempted data transfer).
3-坚持数据保护（在这种情况下，必须在首次尝试数据传输之前发出PROT命令）。
4 - Decide on one of the above three for each and every data connection.
4-为每个数据连接选择上述三个选项中的一个。
The server SHOULD only check the status of the data protection level (for options 3 and 4 above) on the actual command that will initiate the data transfer (and not on the PORT or PASV). The following commands, defined in [RFC-959], cause data connections to be opened and thus may be rejected before any 1xx message due to an incorrect PROT setting.
服务器应仅在将启动数据传输的实际命令上（而不是在端口或PASV上）检查数据保护级别的状态（对于上述选项3和4）。[RFC-959]中定义的以下命令会导致数据连接被打开，因此，由于保护设置不正确，可能会在任何1xx消息之前被拒绝。
STOR RETR NLST LIST STOU APPE
存储报告列表
The reply to indicate that the PROT setting is incorrect is '521 data connection cannot be opened with this PROT setting'
表示保护设置不正确的回复是“521数据连接无法使用此保护设置打开”
If the protection level indicates that TLS is required, then it should be negotiated once the data connection is made. Thus, the '150' reply only states that the command can be used given the current PROT level. Should the server not like the TLS negotiation, then it will close the data port immediately and follow the '150' command with a '522' reply, which indicates that the TLS negotiation failed or was unacceptable. (Note: This means that the application can pass a standard list of CipherSuites to the TLS layer for negotiation, and review the one negotiated for applicability in each instance).
如果保护级别表明需要TLS，则应在建立数据连接后协商。因此，“150”回复仅说明在当前保护级别下可以使用该命令。如果服务器不喜欢TLS协商，那么它将立即关闭数据端口，并按照“150”命令发出“522”回复，这表示TLS协商失败或不可接受。（注意：这意味着应用程序可以将密码套件的标准列表传递给TLS层进行协商，并审查协商后的列表在每个实例中的适用性）。
The Security Considerations section discusses the issue of cross-checking any certificates used to authenticate the data connection with the one(s) used to authenticate the control connection. This is an important security step.
安全注意事项部分讨论了交叉检查用于验证数据连接的任何证书与用于验证控制连接的证书的问题。这是一个重要的安全步骤。
It is reasonable for the server to insist that the data connection uses a TLS cached session. This might be a cache of a previous data connection or of a cleared control connection. If this is the reason for the refusal to allow the data transfer, then the '522' reply should indicate this.
服务器坚持数据连接使用TLS缓存会话是合理的。这可能是先前数据连接或已清除控制连接的缓存。如果这是拒绝允许数据传输的原因，则“522”回复应表明这一点。
Note: This has an important impact on client design, but allows servers to minimise the cycles used during TLS negotiation by refusing to perform a full negotiation with a previously authenticated client.
注意：这对客户端设计有重要影响，但允许服务器通过拒绝与以前经过身份验证的客户端执行完全协商来最大限度地减少TLS协商期间使用的周期。
It should be noted that the TLS authentication of the server will be authentication of the server host itself and not a user on the server host.
应该注意的是，服务器的TLS身份验证将是服务器主机本身的身份验证，而不是服务器主机上的用户的身份验证。
In most cases, it is likely that the client will be using TLS because the server would refuse to interact insecurely. To allow for this, clients SHOULD be flexible enough to manage the securing of a session at the appropriate time and still allow the user/server policies to dictate exactly when during the session the security is negotiated.
在大多数情况下，客户端很可能会使用TLS，因为服务器会拒绝不安全的交互。为了实现这一点，客户机应该足够灵活，能够在适当的时间管理会话的安全性，并且仍然允许用户/服务器策略在会话期间准确指示何时协商安全性。
In the case where it is the client that is insisting on the securing of the session, the client will need to ensure that the negotiations are all completed satisfactorily and will need to be able to sensibly inform the user should the server not support, or not be prepared to use, the required security levels.
在客户端坚持会话安全的情况下，客户端需要确保协商圆满完成，并且如果服务器不支持或不准备使用所需的安全级别，客户端需要能够明智地通知用户。
Clients SHOULD be coded in such a manner as to allow the timing of the AUTH, PBSZ, and PROT commands to be flexible and dictated by the server. It is quite reasonable for a server to refuse certain commands prior to these commands. Similarly, it is quite possible that a SITE or quoted command might be needed by a server prior to the AUTH. A client MUST allow a user to override the timing of these commands to suit a specific server.
客户机的编码方式应使AUTH、PBSZ和PROT命令的计时灵活，并由服务器决定。在这些命令之前，服务器拒绝某些命令是非常合理的。类似地，在进行身份验证之前，服务器可能需要站点或引用的命令。客户端必须允许用户覆盖这些命令的计时，以适应特定的服务器。
For example, a client SHOULD NOT insist on sending the AUTH as the first command in a session, nor should it insist on issuing a PBSZ/PROT pair directly after the AUTH. This may well be the default behaviour, but must be overridable by a user.
例如，客户端不应坚持将AUTH作为会话中的第一个命令发送，也不应坚持在AUTH之后直接发出PBSZ/PROT对。这可能是默认行为，但必须由用户覆盖。
The TLS negotiation may not be completed satisfactorily for the client, in which case it will be in one of these states:
对于客户而言，TLS谈判可能无法令人满意地完成，在这种情况下，谈判将处于以下状态之一：
The TLS negotiation failed completely
TLS谈判完全失败
In this case, the control connection should still be in an unprotected mode and the client should issue an unprotected QUIT command to end the session.
在这种情况下，控制连接仍应处于不受保护的模式，客户端应发出不受保护的QUIT命令以结束会话。
The TLS negotiation completed successfully, but the client decides that the session parameters are not acceptable (e.g., Distinguished Name in certificate is not the actual server expected).
TLS协商已成功完成，但客户端认为会话参数不可接受（例如，证书中的可分辨名称不是预期的实际服务器）。
In this case, the control connection should still be up in a protected state, so the client should issue a protected QUIT command to end the session.
在这种情况下，控制连接仍应处于受保护状态，因此客户端应发出受保护的QUIT命令以结束会话。
The TLS negotiation failed during the TLS handshake.
TLS握手期间TLS协商失败。
In this case, the control connection is in an unknown state and the client should simply drop the control connection.
在这种情况下，控制连接处于未知状态，客户端只需删除控制连接即可。
Client security policies
客户端安全策略
Clients do not typically have 'policies' as such, instead they rely on the user to define their actions and, to a certain extent, are reactive to the server policy. Thus, a client will need to have commands that will allow the user to switch the protection level of the data connection dynamically; however, there may be a general 'policy' that attempts all LIST and NLST commands on a Clear connection first (and automatically switches to Private if it fails). In this case, there would need to be a user command available to ensure that a given data transfer was not attempted on an insecure data connection.
客户端通常不具有这样的“策略”，而是依赖用户定义其操作，并且在一定程度上对服务器策略作出反应。因此，客户机将需要具有允许用户动态切换数据连接的保护级别的命令；但是，可能有一个通用的“策略”，该策略首先尝试清除连接上的所有LIST和NLST命令（如果失败，则自动切换到Private）。在这种情况下，需要有一个可用的用户命令，以确保在不安全的数据连接上未尝试进行给定的数据传输。
Clients also need to understand that the level of the PROT setting is only checked for a particular data transfer after that transfer has been requested. Thus, a refusal by the server to accept a particular data transfer should not be read by the client as a refusal to accept that data protection level completely, as not only may other data transfers be acceptable at that protection level, but it is entirely possible that the same transfer may be accepted at the same protection level at a later point in the session.
客户端还需要了解，只有在请求传输后，才会检查特定数据传输的保护设置级别。因此，客户端不应将服务器拒绝接受特定数据传输理解为拒绝完全接受该数据保护级别，因为在该保护级别上不仅可以接受其他数据传输，但是，完全有可能在会话的稍后时间，在相同的保护级别上接受相同的传输。
It should be noted that the TLS authentication of the client should be an authentication of a user on the client host and not the client host itself.
应该注意，客户机的TLS身份验证应该是客户机主机上的用户身份验证，而不是客户机主机本身。
Client issues 'AUTH TLS', server accepts or rejects. If the server needs AUTH, then it refuses to accept certain commands until it gets a successfully protected session.
客户端发出“验证TLS”，服务器接受或拒绝。如果服务器需要身份验证，则在成功获得受保护的会话之前，它拒绝接受某些命令。
Decided entirely by the TLS CipherSuite negotiation.
完全由TLS CipherSuite协商决定。
Client issues PROT command, server accepts or rejects.
客户端发出PROT命令，服务器接受或拒绝。
A client would have already issued a PROT command if it required the connection to be protected.
如果客户端要求保护连接，那么它可能已经发出了PROT命令。
If a server needs to have the connection protected, then it will reply to the STOR/RETR/NLST/... command with a '522', indicating that the current state of the data connection protection level is not sufficient for that data transfer at that time.
如果服务器需要保护连接，那么它将回复STOR/RETR/NLST/。。。带有“522”的命令，指示数据连接保护级别的当前状态不足以进行当时的数据传输。
11.5. What level of protection is required for a particular data transfer?
11.5. 特定数据传输需要什么级别的保护？
Decided entirely by the TLS CipherSuite negotiation.
完全由TLS CipherSuite协商决定。
Thus, for flexibility, it can be seen that it is desirable for the FTP application to be able to interact with the TLS layer upon which it sits to define and discover the exact TLS CipherSuites that are to be/have been negotiated and to make decisions accordingly.
因此，为了灵活性，可以看出FTP应用程序需要能够与其所在的TLS层交互，以定义和发现要协商/已经协商的确切TLS密码套件，并据此做出决策。
These timing diagrams aim to help explain exactly how the TLS handshake and session protection fits into the existing logic of the FTP protocol. Of course, the FTP protocol itself is not well described with respect to the timing of commands and responses in [RFC-959], so this is partly based on empirical observation of existing widespread client and server implementations.
这些时序图旨在帮助准确解释TLS握手和会话保护如何融入FTP协议的现有逻辑。当然，在[RFC-959]中，FTP协议本身没有很好地描述命令和响应的时间，因此这部分是基于对现有广泛的客户端和服务器实现的经验观察。
Client Server
control data data control
====================================================================
Client Server
control data data control
====================================================================
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 331
PASS pass ---------------------------------------------->
<---------------------------------------------- 230
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 331
PASS pass ---------------------------------------------->
<---------------------------------------------- 230
Note 1: The order of the PBSZ/PROT pair and the USER/PASS pair (with respect to each other) is not important (i.e., the USER/PASS can happen prior to the PBSZ/PROT, or the server can refuse to allow a PBSZ/PROT pair until the USER/PASS pair has happened).
注1：PBSZ/PROT对和用户/通行证对的顺序（就彼此而言）并不重要（即，用户/通行证可以发生在PBSZ/PROT之前，或者服务器可以在用户/通行证对发生之前拒绝允许PBSZ/PROT对）。
Note 2: The PASS command might not be required at all (if the USER parameter and any client identity presented provide sufficient authentication). The server would indicate this by issuing a '232' reply to the USER command instead of the '331', which requests a PASS from the client (see below).
注2：可能根本不需要PASS命令（如果提供的用户参数和任何客户端标识提供了足够的身份验证）。服务器将通过向用户命令发出“232”回复来指示这一点，而不是“331”，后者从客户端请求通过（见下文）。
Note 3: The AUTH command might not be the first command after the receipt of the 220 welcome message.
注意3:AUTH命令可能不是收到欢迎消息后的第一个命令。
12.2. Establishing a Protected Session Without a Password Request (The TLS Authentication is Sufficient)
12.2. 在没有密码请求的情况下建立受保护会话（TLS身份验证已足够）
Client Server
control data data control
====================================================================
Client Server
control data data control
====================================================================
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 232
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 232
12.3. Establishing a Protected Session and then Clearing with the CCC Command
12.3. 建立受保护的会话，然后使用CCC命令清除
Client Server
control data data control
====================================================================
Client Server
control data data control
====================================================================
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 232
CCC ---------------------------------------------->
<---------------------------------------------- 200
TLSshutdown() <-------------------------------------> TLSshutdown()
socket()
bind()
socket()
connect() ----------------------------------------------> accept()
<---------------------------------------------- 220
AUTH TLS ---------------------------------------------->
<---------------------------------------------- 234
TLSneg() <----------------------------------------------> TLSneg()
PBSZ 0 ---------------------------------------------->
<---------------------------------------------- 200
PROT P ---------------------------------------------->
<---------------------------------------------- 200
USER fred ---------------------------------------------->
<---------------------------------------------- 232
CCC ---------------------------------------------->
<---------------------------------------------- 200
TLSshutdown() <-------------------------------------> TLSshutdown()
- The rest of the control session continues in plaintext with protected data transfers (due to PROT P).
- 控制会话的其余部分继续以明文形式进行，并进行受保护的数据传输（由于PROT P）。
Note: This has serious security issues (see Security Considerations section) but may be useful in a firewall/NAT scenario.
注意：这有严重的安全问题（请参阅“安全注意事项”一节），但在防火墙/NAT场景中可能很有用。
Client Server
control data data control
====================================================================
Client Server
control data data control
====================================================================
socket()
bind()
PORT w,x,y,z,a,b ----------------------------------------->
<----------------------------------------------------- 200
STOR file ------------------------------------------------>
socket()
bind()
<----------------------------------------------------- 150
accept() <----------- connect()
write() -----------> read()
close() -----------> close()
<----------------------------------------------------- 226
socket()
bind()
PORT w,x,y,z,a,b ----------------------------------------->
<----------------------------------------------------- 200
STOR file ------------------------------------------------>
socket()
bind()
<----------------------------------------------------- 150
accept() <----------- connect()
write() -----------> read()
close() -----------> close()
<----------------------------------------------------- 226
Client Server
control data data control
====================================================================
Client Server
control data data control
====================================================================
PASV -------------------------------------------------------->
socket()
bind()
<------------------------------------------ 227 (w,x,y,z,a,b)
socket()
STOR file --------------------------------------------------->
connect() ----------> accept()
<-------------------------------------------------------- 150
write() ----------> read()
close() ----------> close()
<-------------------------------------------------------- 226
PASV -------------------------------------------------------->
socket()
bind()
<------------------------------------------ 227 (w,x,y,z,a,b)
socket()
STOR file --------------------------------------------------->
connect() ----------> accept()
<-------------------------------------------------------- 150
write() ----------> read()
close() ----------> close()
<-------------------------------------------------------- 226
Note: Implementers should be aware that the connect()/accept() function is performed prior to the receipt of the reply from the STOR command. This contrasts the with situation when a non-firewall-friendly PORT is used prior to the STOR, and the accept()/connect() is performed after the reply from the aforementioned STOR has been dealt with.
注意：实现者应该知道connect（）/accept（）函数是在从STOR命令接收回复之前执行的。这与在STOR之前使用非防火墙友好端口，并且在处理上述STOR的回复后执行accept（）/connect（）的情况形成对比。
Client Server
control data data control
====================================================================
Client Server
control data data control
====================================================================
socket()
bind()
PORT w,x,y,z,a,b -------------------------------------------->
<-------------------------------------------------------- 200
STOR file --------------------------------------------------->
socket()
bind()
<-------------------------------------------------------- 150
accept() <---------- connect()
TLSneg() <----------> TLSneg()
TLSwrite() ----------> TLSread()
TLSshutdown() -------> TLSshutdown()
close() ----------> close()
<-------------------------------------------------------- 226
socket()
bind()
PORT w,x,y,z,a,b -------------------------------------------->
<-------------------------------------------------------- 200
STOR file --------------------------------------------------->
socket()
bind()
<-------------------------------------------------------- 150
accept() <---------- connect()
TLSneg() <----------> TLSneg()
TLSwrite() ----------> TLSread()
TLSshutdown() -------> TLSshutdown()
close() ----------> close()
<-------------------------------------------------------- 226
Client Server
control data data control
====================================================================
Client Server
control data data control
====================================================================
PASV -------------------------------------------------------->
socket()
bind()
<------------------------------------------ 227 (w,x,y,z,a,b)
socket()
STOR file --------------------------------------------------->
connect() ----------> accept()
<-------------------------------------------------------- 150
TLSneg() <---------> TLSneg()
TLSwrite() ---------> TLSread()
TLSshutdown() -------> TLSshutdown()
close() ---------> close()
<-------------------------------------------------------- 226
PASV -------------------------------------------------------->
socket()
bind()
<------------------------------------------ 227 (w,x,y,z,a,b)
socket()
STOR file --------------------------------------------------->
connect() ----------> accept()
<-------------------------------------------------------- 150
TLSneg() <---------> TLSneg()
TLSwrite() ---------> TLSread()
TLSshutdown() -------> TLSshutdown()
close() ---------> close()
<-------------------------------------------------------- 226
The REIN command, defined in [RFC-959], allows the user to reset the state of the FTP session. From [RFC-959]:
[RFC-959]中定义的REIN命令允许用户重置FTP会话的状态。从[RFC-959]：
REINITIALIZE (REIN)
重新初始化（REIN）
This command terminates a USER, flushing all I/O and account information, except to allow any transfer in progress to be completed. All parameters are reset to the default settings and the control connection is left open. This is identical to the state in which a user finds himself immediately after the control connection is opened. A USER command may be expected to follow.
此命令终止用户，刷新所有I/O和帐户信息，但允许完成任何正在进行的传输除外。所有参数均重置为默认设置，控制连接保持打开状态。这与用户在控件连接打开后立即发现自己的状态相同。可能会出现一个用户命令。
When this command is processed by the server, the TLS session(s) MUST be cleared and the control and data connections revert to unprotected, clear communications. It MAY be acceptable to use cached TLS sessions for subsequent connections, however, a server MUST NOT mandate this.
当服务器处理此命令时，必须清除TLS会话，并且控制和数据连接恢复为未受保护的清除通信。可以将缓存的TLS会话用于后续连接，但是，服务器不得强制执行此操作。
If the REIN command is being used to clear a TLS session, then the reply to the REIN command MUST be sent in a protected session prior to the session(s) being cleared.
如果REIN命令用于清除TLS会话，则在清除会话之前，必须在受保护会话中发送对REIN命令的回复。
The ABOR and STAT commands and the use of TCP Urgent Pointers
ABOR和STAT命令以及TCP紧急指针的使用
[RFC-959] describes the use of Telnet commands (IP and DM) and the TCP Urgent pointer to indicate the transmission of commands on the control channel during the execution of a data transfer. FTP uses the Telnet Interrupt Process and Data Mark commands in conjunction with Urgent data to preface two commands: ABOR (Abort Transfer) and STAT (Status request).
[RFC-959]描述了在执行数据传输期间，使用Telnet命令（IP和DM）和TCP紧急指针指示控制通道上的命令传输。FTP将Telnet中断过程和数据标记命令与紧急数据一起用于两个命令：ABOR（中止传输）和STAT（状态请求）。
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.
之所以使用紧急指针，是因为在Unix实现中，接收标记为紧急的TCP数据包将导致执行SIGURG中断处理程序。对于未实现select（）或不支持多线程的系统，这种对中断处理程序的依赖是必要的。TLS不支持紧急数据的概念。
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.
当TLS作为FTP中的一种安全方法实现时，服务器在数据传输期间不应依赖于使用SIGURG来处理控制通道上的输入。客户端必须通过TLS会话发送所有数据，包括Telnet命令。
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.
本文档讨论了如何将TLS与[RFC-2228]结合使用，以提供保护FTP会话的机制。关于安全原理和安全属性的讨论包含在[RFC-2228]文件中，此处不再重复。
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.
在本节中，我们假设X.509证书将用于TLS身份验证。如果使用了其他身份令牌（例如kerberos票证-请参见[RFC-2712]），则需要考虑类似的特定于机制的因素。
- 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]).
- 尽管这完全是一项实施决策，但建议用于TLS会话服务器身份验证的证书以与http服务器类似的方式包含服务器标识信息（请参见[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.
- 如果不使用服务器证书，那么许多安全好处将无法实现。例如，在匿名Diffie-Hellman环境中，没有服务器身份验证，因此对中间人攻击几乎没有保护。
- 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.
- 如果不使用客户端证书，那么许多安全好处将无法实现。例如，恶意客户端仍有可能劫持数据连接。
A bounce attack should be harder in a secured FTP environment because:
在安全的FTP环境中，反弹攻击应该更难，因为：
- 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.
- 用于启动错误连接的FTP服务器在TLS上下文中始终是“服务器”。因此，只有在TLS上下文中充当“客户机”的服务才可能易受攻击。这是在服务上实现TLS的一种违反直觉的方法。
- 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.
- FTP服务器将检测到数据连接的身份验证凭据与控制连接的身份验证凭据不同，因此可以将服务器策略设置为断开数据连接。
- 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...)
- 当身份验证很强时，真正的用户不太可能发起此类攻击，如果身份验证不容易被破坏（密码猜测、网络跟踪等），恶意用户也不太可能访问FTP服务器
This document presents a strong mechanism for solving the issue raised in this section.
本文件为解决本节提出的问题提供了强有力的机制。
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.
强大的身份验证和数据机密性这两个解决方案确保了在使用TLS保护控制会话时，这不是一个问题。
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).
TLS协议通过加密确保数据的机密性。隐私（例如，访问下载日志、用户配置文件信息等）不在本文件范围内（以及[RFC-2577]的范围内）。
This is not an issue when TLS is used as the primary authentication mechanism.
当TLS用作主要身份验证机制时，这不是问题。
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.
本规范对本节中的拒绝服务元素几乎没有作用；但是，数据连接上的强身份验证将防止未经授权的连接检索或提交文件。当然，这只是使用强客户端身份验证的情况。如果不使用客户端证书，那么恶意客户端窃取端口仍然是一个问题。如果根本没有使用强身份验证（例如，匿名Diffie-Hellman），则端口窃取问题仍然存在。
Nothing in this specification will affect the discussion in this section.
本规范中的任何内容都不会影响本节中的讨论。
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.
使用CCC命令可能会产生安全问题。有关完整说明，请参阅[RFC-2228]的“清除命令通道（CCC）”部分。客户端不应假定服务器将允许处理CCC命令。
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.
服务器实现可能希望在未通过某种形式的客户端身份验证（例如，TLS客户端身份验证或FTP用户/PASS）的会话上拒绝处理CCC命令。这可以防止匿名客户端重复请求身份验证TLS，然后请求CCC以占用服务器上的资源。
{FTP-PORT} - The port assigned to the FTP control connection is 21.
{FTP-PORT}-分配给FTP控制连接的端口为21。
{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'
{TLS-PARM}-AUTH命令的参数，用于指示需要TLS。要根据本文件请求TLS协议，客户必须使用“TLS”
To maintain backward compatibility with older versions of this document, the server SHOULD accept 'TLS-C' as a synonym for 'TLS'.
为保持与本文档旧版本的向后兼容性，服务器应接受“TLS-C”作为“TLS”的同义词。
Note: [RFC-2228] states that these parameters are case-insensitive.
注：[RFC-2228]说明这些参数不区分大小写。
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.
除了与服务器拒绝为每个数据连接进行完整TLS协商的能力有关的问题外，没有其他问题，这将允许服务器保留吞吐量，同时仅在必要时使用周期。
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).
此机制通常适用于保护FTP协议的机制。匿名FTP客户端或服务器不太可能需要这种安全性（尽管有些人可能喜欢没有保密性的身份验证功能）。
o Netscape Communications Corporation for the original SSL protocol.
o Netscape Communications Corporation的原始SSL协议。
o Eric Young for the SSLeay libraries.
o 埃里克·杨为斯莱伊图书馆工作。
o University of California, Berkeley for the original implementations of FTP and ftpd, on which the initial implementation of these extensions were layered.
o 加利福尼亚大学，伯克利的FTP和FTPD的原始实现，其中这些扩展的初步实现是分层的。
o IETF CAT working group.
o IETF CAT工作组。
o IETF TLS working group.
o IETF TLS工作组。
o IETF FTPEXT working group.
o IETF FTPEXT工作组。
o Jeff Altman for the ABOR and STAT discussion.
o 杰夫·奥特曼（Jeff Altman）负责ABOR和STAT讨论。
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.
o 在本文件漫长的起草阶段，帮助编写本文件的各种人，即马丁·卡彭特、埃里克·默里、蒂姆·哈德森和沃尔克·维根。
[RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC-959]Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997.
[RFC-2228]Horowitz，M.和S.Lunt，“FTP安全扩展”，RFC 2228，1997年10月。
[RFC-2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC-2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[RFC-2389] Hethmon, P. and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998.
[RFC-2389]Hethmon，P.和R.Elz，“文件传输协议的特征协商机制”，RFC 2389，1998年8月。
[RFC-1579] Bellovin, S., "Firewall-Friendly FTP", RFC 1579, February 1994.
[RFC-1579]Bellovin，S.，“防火墙友好FTP”，RFC 1579，1994年2月。
[RFC-2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC-2222]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC 2222，1997年10月。
[RFC-2577] Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, May 1999.
[RFC-2577]Allman，M.和S.Ostermann，“FTP安全注意事项”，RFC 2577，1999年5月。
[RFC-2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
[RFC-2712]Medvinsky，A.和M.Hur，“将Kerberos密码套件添加到传输层安全性（TLS）”，RFC 2712，1999年10月。
[RFC-2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC-2817]Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 2817，2000年5月。
[RFC-2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC-2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[RFC-3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC-3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，2002年2月。
Contributors
贡献者
Tim Hudson RSA Data Security Australia Pty Ltd
Tim Hudson RSA澳大利亚数据安全私人有限公司
Phone: +61 7 3227 4444
EMail: tjh@rsasecurity.com.au
Phone: +61 7 3227 4444
EMail: tjh@rsasecurity.com.au
Volker Wiegand SuSE Linux
沃克·维根·苏斯Linux
EMail: wiegand@suse.de
EMail: wiegand@suse.de
Martin Carpenter Verisign Ltd
马丁卡彭特威瑞斯有限公司
EMail: mcarpenter@verisign.com
EMail: mcarpenter@verisign.com
Eric Murray Wave Systems Inc.
埃里克·默里波浪系统公司。
EMail: ericm@lne.com
EMail: ericm@lne.com
Author's Address
作者地址
Paul Ford-Hutchinson IBM UK Ltd PO Box 31 Birmingham Road Warwick United Kingdom
Paul Ford Hutchinson IBM UK Ltd英国沃里克伯明翰路31号邮政信箱
Phone: +44 1926 462005
EMail: rfc4217@ford-hutchinson.com
Phone: +44 1926 462005
EMail: rfc4217@ford-hutchinson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。