Network Working Group M. Horowitz
Request for Comments: 2228 Cygnus Solutions
Updates: 959 S. Lunt
Category: Standards Track Bellcore
October 1997
Network Working Group M. Horowitz
Request for Comments: 2228 Cygnus Solutions
Updates: 959 S. Lunt
Category: Standards Track Bellcore
October 1997
FTP Security Extensions
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 (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
Abstract
摘要
This document defines extensions to the FTP specification STD 9, RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings.
本文件定义了FTP规范STD 9，RFC 959，“文件传输协议（FTP）”（1985年10月）的扩展。这些扩展通过引入新的可选命令、应答和文件传输编码，在控制通道和数据通道上提供了强大的身份验证、完整性和机密性。
The following new optional commands are introduced in this specification:
本规范中引入了以下新的可选命令：
AUTH (Authentication/Security Mechanism), ADAT (Authentication/Security Data), PROT (Data Channel Protection Level), PBSZ (Protection Buffer Size), CCC (Clear Command Channel), MIC (Integrity Protected Command), CONF (Confidentiality Protected Command), and ENC (Privacy Protected Command).
AUTH（身份验证/安全机制）、ADAT（身份验证/安全数据）、PROT（数据通道保护级别）、PBSZ（保护缓冲区大小）、CCC（清除命令通道）、MIC（完整性保护命令）、CONF（机密性保护命令）和ENC（隐私保护命令）。
A new class of reply types (6yz) is also introduced for protected replies.
还为受保护的回复引入了一类新的回复类型（6yz）。
None of the above commands are required to be implemented, but interdependencies exist. These dependencies are documented with the commands.
不需要实现上述任何命令，但存在相互依赖关系。这些依赖关系用命令记录。
Note that this specification is compatible with STD 9, RFC 959.
请注意，本规范与STD 9、RFC 959兼容。
The File Transfer Protocol (FTP) currently defined in STD 9, RFC 959 and in place on the Internet uses usernames and passwords passed in cleartext to authenticate clients to servers (via the USER and PASS commands). Except for services such as "anonymous" FTP archives, this represents a security risk whereby passwords can be stolen through monitoring of local and wide-area networks. This either aids potential attackers through password exposure and/or limits accessibility of files by FTP servers who cannot or will not accept the inherent security risks.
当前在STD 9、RFC 959和Internet上定义的文件传输协议（FTP）使用以明文形式传递的用户名和密码（通过用户和PASS命令）对服务器的客户端进行身份验证。除了“匿名”FTP档案等服务外，这代表了一种安全风险，即通过监控局域网和广域网，密码可能被盗。这可以通过密码暴露来帮助潜在攻击者和/或限制FTP服务器对文件的访问，这些服务器不能或不会接受固有的安全风险。
Aside from the problem of authenticating users in a secure manner, there is also the problem of authenticating servers, protecting sensitive data and/or verifying its integrity. An attacker may be able to access valuable or sensitive data merely by monitoring a network, or through active means may be able to delete or modify the data being transferred so as to corrupt its integrity. An active attacker may also initiate spurious file transfers to and from a site of the attacker's choice, and may invoke other commands on the server. FTP does not currently have any provision for the encryption or verification of the authenticity of commands, replies, or transferred data. Note that these security services have value even to anonymous file access.
除了以安全方式验证用户的问题外，还存在验证服务器、保护敏感数据和/或验证其完整性的问题。攻击者可能仅通过监视网络就能够访问有价值或敏感的数据，或者通过主动手段删除或修改正在传输的数据，从而破坏其完整性。主动攻击者还可能发起与攻击者选择的站点之间的虚假文件传输，并可能调用服务器上的其他命令。FTP目前没有任何关于加密或验证命令、回复或传输数据真实性的规定。请注意，这些安全服务甚至对匿名文件访问也有价值。
Current practice for sending files securely is generally either:
当前安全发送文件的做法通常是：
1. via FTP of files pre-encrypted under keys which are manually distributed,
1. 通过手动分发的密钥预加密文件的FTP，
2. via electronic mail containing an encoding of a file encrypted under keys which are manually distributed,
2. 通过包含手动分发密钥加密文件编码的电子邮件，
3. via a PEM message, or
3. 通过PEM消息，或
4. via the rcp command enhanced to use Kerberos.
4. 通过rcp命令增强以使用Kerberos。
None of these means could be considered even a de facto standard, and none are truly interactive. A need exists to securely transfer files using FTP in a secure manner which is supported within the FTP protocol in a consistent manner and which takes advantage of existing security infrastructure and technology. Extensions are necessary to the FTP specification if these security services are to be introduced into the protocol in an interoperable way.
所有这些手段都不能被视为事实上的标准，也没有真正的互动。需要以一种安全的方式使用FTP安全地传输文件，这种方式在FTP协议中得到一致的支持，并利用现有的安全基础设施和技术。如果要以可互操作的方式将这些安全服务引入协议，则必须对FTP规范进行扩展。
Although the FTP control connection follows the Telnet protocol, and Telnet has defined an authentication and encryption option [TELNET-SEC], [RFC-1123] explicitly forbids the use of Telnet option negotiation over the control connection (other than Synch and IP).
尽管FTP控制连接遵循Telnet协议，并且Telnet定义了身份验证和加密选项[Telnet-SEC]，但[RFC-1123]明确禁止在控制连接上使用Telnet选项协商（同步和IP除外）。
Also, the Telnet authentication and encryption option does not provide for integrity protection only (without confidentiality), and does not address the protection of the data channel.
此外，Telnet身份验证和加密选项不仅不提供完整性保护（无保密性），也不解决数据通道的保护问题。
At the highest level, the FTP security extensions seek to provide an abstract mechanism for authenticating and/or authorizing connections, and integrity and/or confidentiality protecting commands, replies, and data transfers.
在最高级别，FTP安全扩展旨在提供一种抽象机制，用于验证和/或授权连接，以及保护命令、回复和数据传输的完整性和/或机密性。
In the context of FTP security, authentication is the establishment of a client's identity and/or a server's identity in a secure way, usually using cryptographic techniques. The basic FTP protocol does not have a concept of authentication.
在FTP安全的上下文中，身份验证是以安全的方式建立客户端身份和/或服务器身份，通常使用加密技术。基本FTP协议没有身份验证的概念。
Authorization is the process of validating a user for login. The basic authorization process involves the USER, PASS, and ACCT commands. With the FTP security extensions, authentication established using a security mechanism may also be used to make the authorization decision.
授权是验证用户登录的过程。基本授权过程涉及用户、PASS和ACCT命令。对于FTP安全扩展，使用安全机制建立的身份验证也可用于做出授权决策。
Without the security extensions, authentication of the client, as this term is usually understood, never happens. FTP authorization is accomplished with a password, passed on the network in the clear as the argument to the PASS command. The possessor of this password is assumed to be authorized to transfer files as the user named in the USER command, but the identity of the client is never securely established.
如果没有安全扩展，客户机的身份验证，正如通常理解的那样，永远不会发生。FTP授权是通过密码完成的，密码以明文形式在网络上传递，作为PASS命令的参数。假定此密码的拥有者被授权以用户命令中指定的用户的身份传输文件，但客户端的身份永远无法安全地建立。
An FTP security interaction begins with a client telling the server what security mechanism it wants to use with the AUTH command. The server will either accept this mechanism, reject this mechanism, or, in the case of a server which does not implement the security extensions, reject the command completely. The client may try multiple security mechanisms until it requests one which the server accepts. This allows a rudimentary form of negotiation to take place. (If more complex negotiation is desired, this may be implemented as a security mechanism.) The server's reply will indicate if the client must respond with additional data for the
FTP安全交互从一个客户端开始，告诉服务器它希望在AUTH命令中使用什么安全机制。服务器要么接受该机制，要么拒绝该机制，如果服务器未实现安全扩展，则完全拒绝该命令。客户端可能会尝试多种安全机制，直到它请求服务器接受的安全机制为止。这就允许进行初步形式的谈判。（如果需要更复杂的协商，这可以作为一种安全机制来实现。）服务器的回复将指示客户机是否必须为该协商响应附加数据
security mechanism to interpret. If none is needed, this will usually mean that the mechanism is one where the password (specified by the PASS command) is to be interpreted differently, such as with a token or one-time password system.
用于解释的安全机制。如果不需要密码，这通常意味着该机制将对密码（由PASS命令指定）进行不同的解释，例如使用令牌或一次性密码系统。
If the server requires additional security information, then the client and server will enter into a security data exchange. The client will send an ADAT command containing the first block of security data. The server's reply will indicate if the data exchange is complete, if there was an error, or if more data is needed. The server's reply can optionally contain security data for the client to interpret. If more data is needed, the client will send another ADAT command containing the next block of data, and await the server's reply. This exchange can continue as many times as necessary. Once this exchange completes, the client and server have established a security association. This security association may include authentication (client, server, or mutual) and keying information for integrity and/or confidentiality, depending on the mechanism in use.
如果服务器需要其他安全信息，则客户端和服务器将进行安全数据交换。客户端将发送包含第一个安全数据块的ADAT命令。服务器的回复将指示数据交换是否完成、是否有错误或是否需要更多数据。服务器的回复可以选择性地包含客户端要解释的安全数据。如果需要更多数据，客户端将发送另一个包含下一个数据块的ADAT命令，并等待服务器的回复。这种交换可以根据需要继续多次。此交换完成后，客户端和服务器就建立了安全关联。此安全关联可能包括完整性和/或机密性的身份验证（客户端、服务器或双方）和密钥信息，具体取决于使用的机制。
The term "security data" here is carefully chosen. The purpose of the security data exchange is to establish a security association, which might not actually include any authentication at all, between the client and the server as described above. For instance, a Diffie-Hellman exchange establishes a secret key, but no authentication takes place. If an FTP server has an RSA key pair but the client does not, then the client can authenticate the server, but the server cannot authenticate the client.
这里的术语“安全数据”是经过仔细选择的。安全数据交换的目的是在客户机和服务器之间建立安全关联，如上文所述，该关联实际上可能根本不包括任何身份验证。例如，Diffie-Hellman交换建立一个密钥，但不进行身份验证。如果FTP服务器具有RSA密钥对，但客户端没有，则客户端可以对服务器进行身份验证，但服务器无法对客户端进行身份验证。
Once a security association is established, authentication which is a part of this association may be used instead of or in addition to the standard username/password exchange for authorizing a user to connect to the server. A username specified by the USER command is always required to specify the identity to be used on the server.
一旦建立了安全关联，作为该关联一部分的身份验证可以用来代替或补充标准用户名/密码交换，以授权用户连接到服务器。用户命令指定的用户名始终是指定要在服务器上使用的标识所必需的。
In order to prevent an attacker from inserting or deleting commands on the control stream, if the security association supports integrity, then the server and client must use integrity protection on the control stream, unless it first transmits a CCC command to turn off this requirement. Integrity protection is performed with the MIC and ENC commands, and the 63z reply codes. The CCC command and its reply must be transmitted with integrity protection. Commands and replies may be transmitted without integrity (that is, in the clear or with confidentiality only) only if no security association is established, the negotiated security association does not support integrity, or the CCC command has succeeded.
为了防止攻击者在控制流上插入或删除命令，如果安全关联支持完整性，则服务器和客户端必须在控制流上使用完整性保护，除非它首先发送CCC命令以关闭此要求。完整性保护通过MIC和ENC命令以及63z回复代码执行。CCC命令及其回复必须通过完整性保护进行传输。只有在未建立安全关联、协商的安全关联不支持完整性或CCC命令已成功的情况下，才能在没有完整性的情况下传输命令和回复（即，以明文或仅保密的方式）。
Once the client and server have negotiated with the PBSZ command an acceptable buffer size for encapsulating protected data over the data channel, the security mechanism may also be used to protect data channel transfers.
一旦客户机和服务器与PBSZ命令协商了可接受的缓冲区大小，以便通过数据通道封装受保护的数据，安全机制也可用于保护数据通道传输。
Policy is not specified by this document. In particular, client and server implementations may choose to implement restrictions on what operations can be performed depending on the security association which exists. For example, a server may require that a client authorize via a security mechanism rather than using a password, require that the client provide a one-time password from a token, require at least integrity protection on the command channel, or require that certain files only be transmitted encrypted. An anonymous ftp client might refuse to do file transfers without integrity protection in order to insure the validity of files downloaded.
此文档未指定策略。特别是，客户机和服务器实现可能会根据存在的安全关联选择对可以执行的操作实施限制。例如，服务器可能要求客户端通过安全机制而不是使用密码进行授权，要求客户端提供来自令牌的一次性密码，要求至少在命令通道上进行完整性保护，或者要求仅加密传输某些文件。匿名ftp客户端可能拒绝在没有完整性保护的情况下进行文件传输，以确保下载文件的有效性。
No particular set of functionality is required, except as dependencies described in the next section. This means that none of authentication, integrity, or confidentiality are required of an implementation, although a mechanism which does none of these is not of much use. For example, it is acceptable for a mechanism to implement only integrity protection, one-way authentication and/or encryption, encryption without any authentication or integrity protection, or any other subset of functionality if policy or technical considerations make this desirable. Of course, one peer might require as a matter of policy stronger protection than the other is able to provide, preventing perfect interoperability.
除下一节中描述的依赖项外，不需要任何特定的功能集。这意味着一个实现不需要任何身份验证、完整性或机密性，尽管一个不做这些的机制没有多大用处。例如，如果出于政策或技术考虑，仅实现完整性保护、单向身份验证和/或加密、无任何身份验证或完整性保护的加密或任何其他功能子集是可以接受的。当然，作为一种策略，一个对等方可能需要比另一个对等方能够提供的更强大的保护，从而妨碍了完美的互操作性。
The following commands are optional, but dependent on each other. They are extensions to the FTP Access Control Commands.
以下命令是可选的，但相互依赖。它们是FTP访问控制命令的扩展。
The reply codes documented here are generally described as recommended, rather than required. The intent is that reply codes describing the full range of success and failure modes exist, but that servers be allowed to limit information presented to the client. For example, a server might implement a particular security mechanism, but have a policy restriction against using it. The server should respond with a 534 reply code in this case, but may respond with a 504 reply code if it does not wish to divulge that the disallowed mechanism is supported. If the server does choose to use a different reply code than the recommended one, it should try to use a reply code which only differs in the last digit. In all cases, the server must use a reply code which is documented as returnable from the command received, and this reply code must begin with the same digit as the recommended reply code for the situation.
此处记录的回复代码通常被描述为推荐代码，而不是必需代码。其目的是存在描述全部成功和失败模式的应答代码，但允许服务器限制向客户端提供的信息。例如，服务器可能实现特定的安全机制，但对使用该机制有策略限制。在这种情况下，服务器应使用534回复代码进行响应，但如果不想透露支持不允许的机制，则可以使用504回复代码进行响应。如果服务器选择使用不同于推荐的回复代码，则应尝试使用仅在最后一位不同的回复代码。在所有情况下，服务器都必须使用回复代码，该代码记录为可从收到的命令返回，并且该回复代码必须以与该情况下建议的回复代码相同的数字开头。
AUTHENTICATION/SECURITY MECHANISM (AUTH)
身份验证/安全机制（AUTH）
The argument field is a Telnet string identifying a supported mechanism. This string is case-insensitive. Values must be registered with the IANA, except that values beginning with "X-" are reserved for local use.
参数字段是标识受支持机制的Telnet字符串。此字符串不区分大小写。值必须向IANA注册，但以“X-”开头的值保留供本地使用。
If the server does not recognize the AUTH command, it must respond with reply code 500. This is intended to encompass the large deployed base of non-security-aware ftp servers, which will respond with reply code 500 to any unrecognized command. If the server does recognize the AUTH command but does not implement the security extensions, it should respond with reply code 502.
如果服务器无法识别AUTH命令，则必须使用应答代码500进行响应。这是为了涵盖大量部署的非安全感知ftp服务器，这些服务器将以应答代码500响应任何无法识别的命令。如果服务器确实识别AUTH命令，但未实现安全扩展，则应使用应答代码502进行响应。
If the server does not understand the named security mechanism, it should respond with reply code 504.
如果服务器不理解命名的安全机制，则应使用应答代码504进行响应。
If the server is not willing to accept the named security mechanism, it should respond with reply code 534.
如果服务器不愿意接受命名的安全机制，则应使用应答代码534进行响应。
If the server is not able to accept the named security mechanism, such as if a required resource is unavailable, it should respond with reply code 431.
如果服务器无法接受命名的安全机制，例如如果所需的资源不可用，则应使用回复代码431进行响应。
If the server is willing to accept the named security mechanism, but requires security data, it must respond with reply code 334.
如果服务器愿意接受命名的安全机制，但需要安全数据，则必须使用应答代码334进行响应。
If the server is willing to accept the named security mechanism, and does not require any security data, it must respond with reply code 234.
如果服务器愿意接受命名的安全机制，并且不需要任何安全数据，则必须使用应答代码234进行响应。
If the server is responding with a 334 reply code, it may include security data as described in the next section.
如果服务器使用334应答码进行响应，则它可以包括下一节中描述的安全数据。
Some servers will allow the AUTH command to be reissued in order to establish new authentication. The AUTH command, if accepted, removes any state associated with prior FTP Security commands. The server must also require that the user reauthorize (that is, reissue some or all of the USER, PASS, and ACCT commands) in this case (see section 4 for an explanation of "authorize" in this context).
某些服务器将允许重新发出AUTH命令以建立新的身份验证。AUTH命令（如果接受）将删除与以前的FTP安全命令关联的任何状态。在这种情况下，服务器还必须要求用户重新授权（即，重新发出部分或全部user、PASS和ACCT命令）（有关此上下文中“authorize”的解释，请参阅第4节）。
AUTHENTICATION/SECURITY DATA (ADAT)
身份验证/安全数据（ADAT）
The argument field is a Telnet string representing base 64 encoded security data (see Section 9, "Base 64 Encoding"). If a reply code indicating success is returned, the server may also use a string of the form "ADAT=base64data" as the text part of the reply if it wishes to convey security data back to the client.
参数字段是表示base 64编码的安全数据的Telnet字符串（请参阅第9节“base 64编码”）。如果返回了指示成功的应答代码，则如果服务器希望将安全数据传送回客户端，则还可以使用“ADAT=base64data”形式的字符串作为应答的文本部分。
The data in both cases is specific to the security mechanism specified by the previous AUTH command. The ADAT command, and the associated replies, allow the client and server to conduct an arbitrary security protocol. The security data exchange must include enough information for both peers to be aware of which optional features are available. For example, if the client does not support data encryption, the server must be made aware of this, so it will know not to send encrypted command channel replies. It is strongly recommended that the security mechanism provide sequencing on the command channel, to insure that commands are not deleted, reordered, or replayed.
这两种情况下的数据都特定于上一个AUTH命令指定的安全机制。ADAT命令和相关的回复允许客户端和服务器执行任意安全协议。安全数据交换必须包含足够的信息，以便两个对等方都知道哪些可选功能可用。例如，如果客户端不支持数据加密，则必须让服务器知道这一点，以便它知道不发送加密的命令通道回复。强烈建议安全机制在命令通道上提供顺序，以确保命令不会被删除、重新排序或重播。
The ADAT command must be preceded by a successful AUTH command, and cannot be issued once a security data exchange completes (successfully or unsuccessfully), unless it is preceded by an AUTH command to reset the security state.
ADAT命令前面必须有一个成功的AUTH命令，并且在安全数据交换完成（成功或失败）后不能发出，除非它前面有一个AUTH命令来重置安全状态。
If the server has not yet received an AUTH command, or if a prior security data exchange completed, but the security state has not been reset with an AUTH command, it should respond with reply code 503.
如果服务器尚未收到AUTH命令，或者之前的安全数据交换已完成，但安全状态尚未使用AUTH命令重置，则服务器应以回复代码503进行响应。
If the server cannot base 64 decode the argument, it should respond with reply code 501.
如果服务器无法对参数进行Base64解码，则应使用回复代码501进行响应。
If the server rejects the security data (if a checksum fails, for instance), it should respond with reply code 535.
如果服务器拒绝安全数据（例如，如果校验和失败），它应该用应答代码535进行响应。
If the server accepts the security data, and requires additional data, it should respond with reply code 335.
如果服务器接受安全数据，并且需要额外的数据，则应使用应答代码335进行响应。
If the server accepts the security data, but does not require any additional data (i.e., the security data exchange has completed successfully), it must respond with reply code 235.
如果服务器接受安全数据，但不需要任何附加数据（即，安全数据交换已成功完成），则必须使用回复代码235进行响应。
If the server is responding with a 235 or 335 reply code, then it may include security data in the text part of the reply as specified above.
如果服务器使用235或335回复代码进行响应，那么它可能会在如上所述的回复文本部分中包含安全数据。
If the ADAT command returns an error, the security data exchange will fail, and the client must reset its internal security state. If the client becomes unsynchronized with the server (for example, the server sends a 234 reply code to an AUTH command, but the client has more data to transmit), then the client must reset the server's security state.
如果ADAT命令返回错误，安全数据交换将失败，客户端必须重置其内部安全状态。如果客户端与服务器不同步（例如，服务器向AUTH命令发送234回复代码，但客户端有更多数据要传输），则客户端必须重置服务器的安全状态。
PROTECTION BUFFER SIZE (PBSZ)
保护缓冲区大小（PBSZ）
The argument is a decimal integer representing the maximum size, in bytes, of the encoded data blocks to be sent or received during file transfer. This number shall be no greater than can be represented in a 32-bit unsigned integer.
该参数是一个十进制整数，表示文件传输期间要发送或接收的编码数据块的最大大小（以字节为单位）。该数字不得大于32位无符号整数所能表示的数字。
This command allows the FTP client and server to negotiate a maximum protected buffer size for the connection. There is no default size; the client must issue a PBSZ command before it can issue the first PROT command.
此命令允许FTP客户端和服务器协商连接的最大受保护缓冲区大小。没有默认大小；客户端必须先发出PBSZ命令，然后才能发出第一个PROT命令。
The PBSZ command must be preceded by a successful security data exchange.
PBSZ命令之前必须成功地进行安全数据交换。
If the server cannot parse the argument, or if it will not fit in 32 bits, it should respond with a 501 reply code.
如果服务器无法解析该参数，或者该参数不适合32位，则应使用501回复代码进行响应。
If the server has not completed a security data exchange with the client, it should respond with a 503 reply code.
如果服务器尚未完成与客户端的安全数据交换，则应使用503回复代码进行响应。
Otherwise, the server must reply with a 200 reply code. If the size provided by the client is too large for the server, it must use a string of the form "PBSZ=number" in the text part of the reply to indicate a smaller buffer size. The client and the server must use the smaller of the two buffer sizes if both buffer sizes are specified.
否则，服务器必须使用200回复代码进行回复。如果客户端提供的大小对于服务器来说太大，它必须在回复的文本部分中使用“PBSZ=number”形式的字符串来指示较小的缓冲区大小。如果指定了两种缓冲区大小，则客户端和服务器必须使用两种缓冲区大小中较小的一种。
DATA CHANNEL PROTECTION LEVEL (PROT)
数据通道保护级别（PROT）
The argument is a single Telnet character code specifying the data channel protection level.
参数是指定数据通道保护级别的单个Telnet字符代码。
This command indicates to the server what type of data channel protection the client and server will be using. The following codes are assigned:
此命令向服务器指示客户端和服务器将使用何种类型的数据通道保护。分配了以下代码：
C - Clear S - Safe E - Confidential P - Private
C-清晰S-安全E-机密P-私人
The default protection level if no other level is specified is Clear. The Clear protection level indicates that the data channel will carry the raw data of the file transfer, with no security applied. The Safe protection level indicates that the data will be integrity protected. The Confidential protection level indicates that the data will be confidentiality protected. The Private protection level indicates that the data will be integrity and confidentiality protected.
如果未指定其他级别，则默认保护级别为清除。清除保护级别表示数据通道将承载文件传输的原始数据，而不应用任何安全性。安全保护级别表示数据将受到完整性保护。机密保护级别表示数据将受到机密保护。私有保护级别表示数据将受到完整性和机密性保护。
It is reasonable for a security mechanism not to provide all data channel protection levels. It is also reasonable for a mechanism to provide more protection at a level than is required (for instance, a mechanism might provide Confidential protection, but include integrity-protection in that encoding, due to API or other considerations).
安全机制不提供所有数据通道保护级别是合理的。机制在某个级别上提供比所需级别更多的保护也是合理的（例如，机制可能提供机密保护，但由于API或其他考虑，在该编码中包括完整性保护）。
The PROT command must be preceded by a successful protection buffer size negotiation.
PROT命令之前必须进行成功的保护缓冲区大小协商。
If the server does not understand the specified protection level, it should respond with reply code 504.
如果服务器不理解指定的保护级别，则应使用应答代码504进行响应。
If the current security mechanism does not support the specified protection level, the server should respond with reply code 536.
如果当前安全机制不支持指定的保护级别，则服务器应使用应答代码536进行响应。
If the server has not completed a protection buffer size negotiation with the client, it should respond with a 503 reply code.
如果服务器尚未完成与客户端的保护缓冲区大小协商，则应使用503回复代码进行响应。
The PROT command will be rejected and the server should reply 503 if no previous PBSZ command was issued.
如果之前没有发出PBSZ命令，PROT命令将被拒绝，服务器应回复503。
If the server is not willing to accept the specified protection level, it should respond with reply code 534.
如果服务器不愿意接受指定的保护级别，则应使用应答代码534进行响应。
If the server is not able to accept the specified protection level, such as if a required resource is unavailable, it should respond with reply code 431.
如果服务器无法接受指定的保护级别，例如，如果所需资源不可用，则应使用回复代码431进行响应。
Otherwise, the server must reply with a 200 reply code to indicate that the specified protection level is accepted.
否则，服务器必须使用200回复代码进行回复，以表明指定的保护级别已被接受。
CLEAR COMMAND CHANNEL (CCC)
清除命令通道（CCC）
This command does not take an argument.
此命令不接受参数。
It is desirable in some environments to use a security mechanism to authenticate and/or authorize the client and server, but not to perform any integrity checking on the subsequent commands. This might be used in an environment where IP security is in place, insuring that the hosts are authenticated and that TCP streams cannot be tampered, but where user authentication is desired.
在某些环境中，希望使用安全机制对客户端和服务器进行身份验证和/或授权，但不要对后续命令执行任何完整性检查。这可能用于IP安全性已到位的环境中，确保主机经过身份验证，TCP流不能被篡改，但需要用户身份验证。
If unprotected commands are allowed on any connection, then an attacker could insert a command on the control stream, and the server would have no way to know that it was invalid. In order to prevent such attacks, once a security data exchange completes successfully, if the security mechanism supports integrity, then integrity (via the MIC or ENC command, and 631 or 632 reply) must be used, until the CCC command is issued to enable non-integrity protected control channel messages. The CCC command itself must be integrity protected.
如果允许在任何连接上使用未受保护的命令，则攻击者可以在控制流上插入命令，服务器将无法知道该命令无效。为了防止此类攻击，一旦安全数据交换成功完成，如果安全机制支持完整性，则必须使用完整性（通过MIC或ENC命令，以及631或632应答），直到发出CCC命令以启用非完整性保护的控制通道消息。CCC命令本身必须受到完整性保护。
Once the CCC command completes successfully, if a command is not protected, then the reply to that command must also not be protected. This is to support interoperability with clients which do not support protection once the CCC command has been issued.
CCC命令成功完成后，如果命令未受保护，则对该命令的回复也必须不受保护。这是为了在发出CCC命令后支持与不支持保护的客户端的互操作性。
This command must be preceded by a successful security data exchange.
此命令之前必须有成功的安全数据交换。
If the command is not integrity-protected, the server must respond with a 533 reply code.
如果命令不受完整性保护，服务器必须使用533回复代码进行响应。
If the server is not willing to turn off the integrity requirement, it should respond with a 534 reply code.
如果服务器不愿意关闭完整性要求，则应使用534回复代码进行响应。
Otherwise, the server must reply with a 200 reply code to indicate that unprotected commands and replies may now be used on the command channel.
否则，服务器必须使用200回复代码进行回复，以指示现在可以在命令通道上使用未受保护的命令和回复。
INTEGRITY PROTECTED COMMAND (MIC) and CONFIDENTIALITY PROTECTED COMMAND (CONF) and PRIVACY PROTECTED COMMAND (ENC)
完整性保护命令（MIC）、机密性保护命令（CONF）和隐私保护命令（ENC）
The argument field of MIC is a Telnet string consisting of a base 64 encoded "safe" message produced by a security mechanism specific message integrity procedure. The argument field of CONF is a Telnet string consisting of a base 64 encoded "confidential" message produced by a security mechanism specific confidentiality procedure. The argument field of ENC is a Telnet string consisting of a base 64 encoded "private" message produced by a security mechanism specific message integrity and confidentiality procedure.
MIC的参数字段是一个Telnet字符串，包含由特定于安全机制的消息完整性过程生成的base 64编码的“safe”消息。CONF的参数字段是一个Telnet字符串，由特定于安全机制的保密过程生成的base 64编码的“机密”消息组成。ENC的参数字段是一个Telnet字符串，由安全机制特定的消息完整性和机密性过程生成的base 64编码的“private”消息组成。
The server will decode and/or verify the encoded message.
服务器将解码和/或验证编码的消息。
This command must be preceded by a successful security data exchange.
此命令之前必须有成功的安全数据交换。
A server may require that the first command after a successful security data exchange be CCC, and not implement the protection commands at all. In this case, the server should respond with a 502 reply code.
服务器可能要求成功安全数据交换后的第一个命令是CCC，而根本不执行保护命令。在这种情况下，服务器应使用502回复代码进行响应。
If the server cannot base 64 decode the argument, it should respond with a 501 reply code.
如果服务器无法对参数进行Base64解码，则应使用501回复代码进行响应。
If the server has not completed a security data exchange with the client, it should respond with a 503 reply code.
如果服务器尚未完成与客户端的安全数据交换，则应使用503回复代码进行响应。
If the server has completed a security data exchange with the client using a mechanism which supports integrity, and requires a CCC command due to policy or implementation limitations, it should respond with a 503 reply code.
如果服务器使用支持完整性的机制完成了与客户端的安全数据交换，并且由于策略或实现限制而需要CCC命令，则应使用503回复代码进行响应。
If the server rejects the command because it is not supported by the current security mechanism, the server should respond with reply code 537.
如果服务器因为当前安全机制不支持该命令而拒绝该命令，则服务器应使用应答代码537进行响应。
If the server rejects the command (if a checksum fails, for instance), it should respond with reply code 535.
如果服务器拒绝该命令（例如，如果校验和失败），它应该以应答代码535进行响应。
If the server is not willing to accept the command (if privacy is required by policy, for instance, or if a CONF command is received before a CCC command), it should respond with reply code 533.
如果服务器不愿意接受该命令（例如，如果策略要求隐私，或者如果在CCC命令之前收到CONF命令），则服务器应使用应答代码533进行响应。
Otherwise, the command will be interpreted as an FTP command. An end-of-line code need not be included, but if one is included, it must be a Telnet end-of-line code, not a local end-of-line code.
否则，该命令将被解释为FTP命令。不需要包括线端代码，但如果包括线端代码，则必须是Telnet线端代码，而不是本地线端代码。
The server may require that, under some or all circumstances, all commands be protected. In this case, it should make a 533 reply to commands other than MIC, CONF, and ENC.
在某些或所有情况下，服务器可能要求保护所有命令。在这种情况下，它应该对MIC、CONF和ENC以外的命令进行533应答。
The security data exchange may, among other things, establish the identity of the client in a secure way to the server. This identity may be used as one input to the login authorization process.
除其他外，安全数据交换可以以安全的方式向服务器建立客户端的身份。此标识可用作登录授权过程的一个输入。
In response to the FTP login commands (AUTH, PASS, ACCT), the server may choose to change the sequence of commands and replies specified by RFC 959 as follows. There are also some new replies available.
为了响应FTP登录命令（AUTH、PASS、ACCT），服务器可以选择按如下方式更改RFC 959指定的命令和回复序列。还有一些新的答复。
If the server is willing to allow the user named by the USER command to log in based on the identity established by the security data exchange, it should respond with reply code 232.
如果服务器愿意允许用户命令指定的用户基于安全数据交换建立的身份登录，则服务器应使用应答代码232进行响应。
If the security mechanism requires a challenge/response password, it should respond to the USER command with reply code 336. The text part of the reply should contain the challenge. The client must display the challenge to the user before prompting for the password in this case. This is particularly relevant to more sophisticated clients or graphical user interfaces which provide dialog boxes or other modal input. These clients should be careful not to prompt for the password before the username has been sent to the server, in case the user needs the challenge in the 336 reply to construct a valid password.
如果安全机制需要质询/响应密码，则应使用回复代码336响应用户命令。答复的文本部分应包含质疑。在这种情况下，客户端必须在提示输入密码之前向用户显示质询。这尤其适用于提供对话框或其他模式输入的更复杂的客户端或图形用户界面。这些客户端应注意在用户名发送到服务器之前不要提示输入密码，以防用户需要在336回复中提出质疑来构造有效密码。
The new reply codes are divided into two classes. The first class is new replies made necessary by the new FTP Security commands. The second class is a new reply type to indicate protected replies.
新的应答码分为两类。第一类是新的FTP安全命令所必需的新回复。第二个类是一种新的回复类型，用于指示受保护的回复。
5.1. New individual reply codes
5.1. 新的个人回复代码
232 User logged in, authorized by security data exchange.
234 Security data exchange complete.
235 [ADAT=base64data]
; This reply indicates that the security data exchange
; completed successfully. The square brackets are not
; to be included in the reply, but indicate that
; security data in the reply is optional.
232 User logged in, authorized by security data exchange.
234 Security data exchange complete.
235 [ADAT=base64data]
; This reply indicates that the security data exchange
; completed successfully. The square brackets are not
; to be included in the reply, but indicate that
; security data in the reply is optional.
334 [ADAT=base64data]
; This reply indicates that the requested security mechanism
; is ok, and includes security data to be used by the client
; to construct the next command. The square brackets are not
; to be included in the reply, but indicate that
; security data in the reply is optional.
335 [ADAT=base64data]
; This reply indicates that the security data is
; acceptable, and more is required to complete the
; security data exchange. The square brackets
; are not to be included in the reply, but indicate
; that security data in the reply is optional.
334 [ADAT=base64data]
; This reply indicates that the requested security mechanism
; is ok, and includes security data to be used by the client
; to construct the next command. The square brackets are not
; to be included in the reply, but indicate that
; security data in the reply is optional.
335 [ADAT=base64data]
; This reply indicates that the security data is
; acceptable, and more is required to complete the
; security data exchange. The square brackets
; are not to be included in the reply, but indicate
; that security data in the reply is optional.
336 Username okay, need password. Challenge is "...."
; The exact representation of the challenge should be chosen
; by the mechanism to be sensible to the human user of the
; system.
336 Username okay, need password. Challenge is "...."
; The exact representation of the challenge should be chosen
; by the mechanism to be sensible to the human user of the
; system.
431 Need some unavailable resource to process security.
431需要一些不可用的资源来处理安全性。
533 Command protection level denied for policy reasons. 534 Request denied for policy reasons. 535 Failed security check (hash, sequence, etc). 536 Requested PROT level not supported by mechanism. 537 Command protection level not supported by security mechanism.
533由于策略原因，命令保护级别被拒绝。534由于政策原因，请求被拒绝。535安全检查失败（哈希、序列等）。536机制不支持请求的保护级别。537安全机制不支持命令保护级别。
5.2. Protected replies.
5.2. 受保护的答复。
One new reply type is introduced:
引入了一种新的回复类型：
6yz Protected reply
6yz保护应答
There are three reply codes of this type. The first, reply code 631 indicates an integrity protected reply. The second, reply code 632, indicates a confidentiality and integrity protected reply. the third, reply code 633, indicates a confidentiality protected reply.
此类型有三个回复代码。第一个应答代码631表示完整性保护应答。第二个应答代码632表示受机密性和完整性保护的应答。第三个应答代码633表示受保密保护的应答。
The text part of a 631 reply is a Telnet string consisting of a base 64 encoded "safe" message produced by a security mechanism specific message integrity procedure. The text part of a 632 reply is a Telnet string consisting of a base 64 encoded "private" message produced by a security mechanism specific message confidentiality and integrity procedure. The text part of a 633 reply is a Telnet string consisting of a base 64 encoded "confidential" message produced by a security mechanism specific message confidentiality procedure.
631回复的文本部分是Telnet字符串，由安全机制特定的消息完整性过程生成的base 64编码的“安全”消息组成。632回复的文本部分是一个Telnet字符串，由安全机制特定的消息机密性和完整性过程生成的base 64编码“private”消息组成。633回复的文本部分是Telnet字符串，由安全机制特定的消息保密过程生成的base 64编码的“机密”消息组成。
The client will decode and verify the encoded reply. How failures decoding or verifying replies are handled is implementation-specific. An end-of-line code need not be included, but if one is included, it must be a Telnet end-of-line code, not a local end-of-line code.
客户端将解码并验证编码的回复。解码或验证回复失败的处理方式取决于具体实现。不需要包括线端代码，但如果包括线端代码，则必须是Telnet线端代码，而不是本地线端代码。
A protected reply may only be sent if a security data exchange has succeeded.
只有在安全数据交换成功的情况下，才能发送受保护的回复。
The 63z reply may be a multiline reply. In this case, the plaintext reply must be broken up into a number of fragments. Each fragment must be protected, then base 64
63z回复可以是多行回复。在这种情况下，必须将明文回复分解为多个片段。每个片段都必须受到保护，然后是base 64
encoded in order into a separate line of the multiline reply. There need not be any correspondence between the line breaks in the plaintext reply and the encoded reply. Telnet end-of-line codes must appear in the plaintext of the encoded reply, except for the final end-of-line code, which is optional.
按顺序编码到多行应答的单独行中。明文回复和编码回复中的换行符之间不需要有任何对应关系。Telnet行尾代码必须以编码回复的明文形式出现，但最终行尾代码除外，该代码是可选的。
The multiline reply must be formatted more strictly than the continuation specification in RFC 959. In particular, each line before the last must be formed by the reply code, followed immediately by a hyphen, followed by a base 64 encoded fragment of the reply.
多行回复的格式必须比RFC 959中的延续规范更严格。特别是，最后一行之前的每一行必须由回复代码组成，后面紧跟着连字符，后面紧跟着回复的base 64编码片段。
For example, if the plaintext reply is
例如，如果明文回复为
123-First line Second line 234 A line beginning with numbers 123 The last line
123第一行第二行234以数字123开头的行最后一行
then the resulting protected reply could be any of the following (the first example has a line break only to fit within the margins):
然后，生成的受保护回复可以是以下任意一种（第一个示例中有一个换行符，仅用于填充边距）：
631 base64(protect("123-First line\r\nSecond line\r\n 234 A line
631-base64(protect("123-First line\r\n"))
631-base64(protect("Second line\r\n"))
631-base64(protect(" 234 A line beginning with numbers\r\n"))
631 base64(protect("123 The last line"))
631 base64(protect("123-First line\r\nSecond line\r\n 234 A line
631-base64(protect("123-First line\r\n"))
631-base64(protect("Second line\r\n"))
631-base64(protect(" 234 A line beginning with numbers\r\n"))
631 base64(protect("123 The last line"))
631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b"))
631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
631-base64(protect("123-First line\r\nSecond line\r\n 234 A line b"))
631 base64(protect("eginning with numbers\r\n123 The last line\r\n"))
When data transfers are protected between the client and server (in either direction), certain transformations and encapsulations must be performed so that the recipient can properly decode the transmitted file.
当客户机和服务器之间的数据传输受到保护时（在任意方向），必须执行某些转换和封装，以便接收方能够正确解码传输的文件。
The sender must apply all protection services after transformations associated with the representation type, file structure, and transfer mode have been performed. The data sent over the data channel is, for the purposes of protection, to be treated as a byte stream.
在执行与表示类型、文件结构和传输模式关联的转换后，发送方必须应用所有保护服务。出于保护目的，通过数据通道发送的数据将被视为字节流。
When performing a data transfer in an authenticated manner, the authentication checks are performed on individual blocks of the file, rather than on the file as a whole. Consequently, it is possible for
当以经过身份验证的方式执行数据传输时，将对文件的各个块执行身份验证检查，而不是对整个文件执行身份验证检查。因此，这是可能的
insertion attacks to insert blocks into the data stream (i.e., replays) that authenticate correctly, but result in a corrupted file being undetected by the receiver. To guard against such attacks, the specific security mechanism employed should include mechanisms to protect against such attacks. Many GSS-API mechanisms usable with the specification in Appendix I, and the Kerberos mechanism in Appendix II do so.
插入攻击将块插入正确验证的数据流（即重播），但导致接收方无法检测到损坏的文件。为防范此类攻击，所采用的特定安全机制应包括防范此类攻击的机制。许多GSS-API机制可以与附录I中的规范一起使用，而附录II中的Kerberos机制可以这样做。
The sender must take the input byte stream, and break it up into blocks such that each block, when encoded using a security mechanism specific procedure, will be no larger than the buffer size negotiated by the client with the PBSZ command. Each block must be encoded, then transmitted with the length of the encoded block prepended as a four byte unsigned integer, most significant byte first.
发送方必须获取输入字节流，并将其分解为块，以便在使用特定于安全机制的过程进行编码时，每个块都不会大于客户端使用PBSZ命令协商的缓冲区大小。必须对每个块进行编码，然后将编码块的长度作为一个四字节无符号整数（最高有效字节在前）进行传输。
When the end of the file is reached, the sender must encode a block of zero bytes, and send this final block to the recipient before closing the data connection.
当到达文件末尾时，发送方必须编码一个零字节的块，并在关闭数据连接之前将最后一个块发送给接收方。
The recipient will read the four byte length, read a block of data that many bytes long, then decode and verify this block with a security mechanism specific procedure. This must be repeated until a block encoding a buffer of zero bytes is received. This indicates the end of the encoded byte stream.
接收者将读取四个字节的长度，读取一个多字节长的数据块，然后使用特定于安全机制的过程对该数据块进行解码和验证。必须重复此操作，直到接收到编码零字节缓冲区的块。这表示编码字节流的结束。
Any transformations associated with the representation type, file structure, and transfer mode are to be performed by the recipient on the byte stream resulting from the above process.
与表示类型、文件结构和传输模式相关的任何转换都将由接收方在由上述过程产生的字节流上执行。
When using block transfer mode, the sender's (cleartext) buffer size is independent of the block size.
使用块传输模式时，发送方（明文）缓冲区大小与块大小无关。
The server will reply 534 to a STOR, STOU, RETR, LIST, NLST, or APPE command if the current protection level is not at the level dictated by the server's security requirements for the particular file transfer.
如果当前保护级别不在特定文件传输的服务器安全要求规定的级别，则服务器将对STOR、STOU、RETR、LIST、NLST或APPE命令回复534。
If any data protection services fail at any time during data transfer at the server end (including an attempt to send a buffer size greater than the negotiated maximum), the server will send a 535 reply to the data transfer command (either STOR, STOU, RETR, LIST, NLST, or APPE).
如果任何数据保护服务在服务器端数据传输过程中的任何时候失败（包括尝试发送大于协商最大值的缓冲区大小），服务器将向数据传输命令（STOR、STOU、RETR、LIST、NLST或APPE）发送535回复。
While there are no restrictions on client and server policy, there are a few recommendations which an implementation should implement.
虽然对客户端和服务器策略没有限制，但有一些建议是实现应该实现的。
- Once a security data exchange takes place, a server should require all commands be protected (with integrity and/or confidentiality), and it should protect all replies. Replies should use the same level of protection as the command which produced them. This includes replies which indicate failure of the MIC, CONF, and ENC commands. In particular, it is not meaningful to require that AUTH and ADAT be protected; it is meaningful and useful to require that PROT and PBSZ be protected. In particular, the use of CCC is not recommended, but is defined in the interest of interoperability between implementations which might desire such functionality.
- 一旦发生安全数据交换，服务器应要求保护所有命令（具有完整性和/或机密性），并应保护所有回复。回复应使用与生成它们的命令相同的保护级别。这包括指示MIC、CONF和ENC命令失败的应答。特别是，要求对AUTH和ADAT进行保护是没有意义的；要求保护PROT和PBSZ是有意义和有用的。特别是，不建议使用CCC，但定义CCC是为了实现可能需要此类功能的实现之间的互操作性。
- A client should encrypt the PASS command whenever possible. It is reasonable for the server to refuse to accept a non-encrypted PASS command if the server knows encryption is available.
- 客户机应尽可能加密PASS命令。如果服务器知道加密可用，则服务器拒绝接受未加密的PASS命令是合理的。
- Although no security commands are required to be implemented, it is recommended that an implementation provide all commands which can be implemented, given the mechanisms supported and the policy considerations of the site (export controls, for instance).
- 尽管不需要执行任何安全命令，但鉴于支持的机制和站点的策略考虑（例如，导出控制），建议执行提供所有可以执行的命令。
These sections are modelled after sections 5.3 and 5.4 of RFC 959, which describe the same information, except for the standard FTP commands and replies.
这些章节是根据RFC 959第5.3节和第5.4节建模的，这些章节描述了相同的信息，但标准FTP命令和回复除外。
8.1. FTP Security commands and arguments
8.1. FTP安全命令和参数
AUTH <SP> <mechanism-name> <CRLF>
ADAT <SP> <base64data> <CRLF>
PROT <SP> <prot-code> <CRLF>
PBSZ <SP> <decimal-integer> <CRLF>
MIC <SP> <base64data> <CRLF>
CONF <SP> <base64data> <CRLF>
ENC <SP> <base64data> <CRLF>
AUTH <SP> <mechanism-name> <CRLF>
ADAT <SP> <base64data> <CRLF>
PROT <SP> <prot-code> <CRLF>
PBSZ <SP> <decimal-integer> <CRLF>
MIC <SP> <base64data> <CRLF>
CONF <SP> <base64data> <CRLF>
ENC <SP> <base64data> <CRLF>
<mechanism-name> ::= <string>
<base64data> ::= <string>
; must be formatted as described in section 9
<prot-code> ::= C | S | E | P
<decimal-integer> ::= any decimal integer from 1 to (2^32)-1
<mechanism-name> ::= <string>
<base64data> ::= <string>
; must be formatted as described in section 9
<prot-code> ::= C | S | E | P
<decimal-integer> ::= any decimal integer from 1 to (2^32)-1
8.2. Command-Reply sequences
8.2. 命令应答序列
Security Association Setup AUTH 234 334 502, 504, 534, 431 500, 501, 421 ADAT 235 335 503, 501, 535 500, 501, 421 Data protection negotiation commands PBSZ 200 503 500, 501, 421, 530 PROT 200 504, 536, 503, 534, 431 500, 501, 421, 530 Command channel protection commands MIC 535, 533 500, 501, 421 CONF 535, 533 500, 501, 421 ENC 535, 533 500, 501, 421 Security-Enhanced login commands (only new replies listed) USER 232 336 Data channel commands (only new replies listed) STOR 534, 535 STOU 534, 535 RETR 534, 535
安全关联设置验证234 334 502、504、534、431 500、501、421 ADAT 235 335 503、501、535 500、501、421数据保护协商命令PBSZ 200 503 500、501、421、530 PROT 200 504、536、503、534、431 500、501、421、530命令通道保护命令MIC 535、533 500、501、421 CONF 535、533 500、501、501、421 ENC 535、533 500、501，421安全增强登录命令（仅列出新回复）用户232 336数据通道命令（仅列出新回复）STOR 534、535 STOU 534、535 RETR 534、535
LIST 534, 535 NLST 534, 535 APPE 534, 535
列表534535 NLST 534535 APPE 534535
In addition to these reply codes, any security command can return 500, 501, 502, 533, or 421. Any ftp command can return a reply code encapsulated in a 631, 632, or 633 reply once a security data exchange has completed successfully.
除了这些应答码，任何安全命令都可以返回500、501、502、533或421。一旦安全数据交换成功完成，任何ftp命令都可以返回封装在631、632或633应答中的应答代码。
This section includes a state diagram which demonstrates the flow of authentication and authorization in a security enhanced FTP implementation. The rectangular blocks show states where the client must issue a command, and the diamond blocks show states where the server must issue a response.
本节包括一个状态图，它演示了增强安全性的FTP实现中的身份验证和授权流程。矩形块显示客户端必须发出命令的状态，菱形块显示服务器必须发出响应的状态。
,------------------, USER
__\| Unauthenticated |_________\
| /| (new connection) | /|
| `------------------' |
| | |
| | AUTH |
| V |
| / \ |
| 4yz,5yz / \ 234 |
|<--------< >------------->. |
| \ / | |
| \_/ | |
| | | |
| | 334 | |
| V | |
| ,--------------------, | |
| | Need Security Data |<--. | |
| `--------------------' | | |
| | | | |
| | ADAT | | |
| V | | |
| / \ | | |
| 4yz,5yz / \ 335 | | |
`<--------< >-----------' | |
\ / | |
\_/ | |
| | |
| 235 | |
V | |
,---------------. | |
,--->| Authenticated |<--------' | After the client and server
| `---------------' | have completed authenti-
| | | cation, command must be
| | USER | integrity-protected if
| | | integrity is available. The
| |<-------------------' CCC command may be issued to
| V relax this restriction.
,------------------, USER
__\| Unauthenticated |_________\
| /| (new connection) | /|
| `------------------' |
| | |
| | AUTH |
| V |
| / \ |
| 4yz,5yz / \ 234 |
|<--------< >------------->. |
| \ / | |
| \_/ | |
| | | |
| | 334 | |
| V | |
| ,--------------------, | |
| | Need Security Data |<--. | |
| `--------------------' | | |
| | | | |
| | ADAT | | |
| V | | |
| / \ | | |
| 4yz,5yz / \ 335 | | |
`<--------< >-----------' | |
\ / | |
\_/ | |
| | |
| 235 | |
V | |
,---------------. | |
,--->| Authenticated |<--------' | After the client and server
| `---------------' | have completed authenti-
| | | cation, command must be
| | USER | integrity-protected if
| | | integrity is available. The
| |<-------------------' CCC command may be issued to
| V relax this restriction.
| / \
| 4yz,5yz / \ 2yz
|<--------< >------------->.
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,---------------. |
| | Need Password | |
| `---------------' |
| | |
| | PASS |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
|<--------< >------------->|
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,--------------. |
| | Need Account | |
| `--------------' |
| | |
| | ACCT |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
`<--------< >------------->|
\ / |
\_/ |
| |
| 3yz |
V |
,-------------. |
| Authorized |/________|
| (Logged in) |\
`-------------'
| / \
| 4yz,5yz / \ 2yz
|<--------< >------------->.
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,---------------. |
| | Need Password | |
| `---------------' |
| | |
| | PASS |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
|<--------< >------------->|
| \ / |
| \_/ |
| | |
| | 3yz |
| V |
| ,--------------. |
| | Need Account | |
| `--------------' |
| | |
| | ACCT |
| V |
| / \ |
| 4yz,5yz / \ 2yz |
`<--------< >------------->|
\ / |
\_/ |
| |
| 3yz |
V |
,-------------. |
| Authorized |/________|
| (Logged in) |\
`-------------'
Base 64 encoding is the same as the Printable Encoding described in Section 4.3.2.4 of [RFC-1421], except that line breaks must not be included. This encoding is defined as follows.
Base 64编码与[RFC-1421]第4.3.2.4节中描述的可打印编码相同，但不得包括换行符。此编码定义如下。
Proceeding from left to right, the bit string resulting from the mechanism specific protection routine is encoded into characters which are universally representable at all sites, though not necessarily with the same bit patterns (e.g., although the character "E" is represented in an ASCII-based system as hexadecimal 45 and as hexadecimal C5 in an EBCDIC-based system, the local significance of the two representations is equivalent).
从左到右，由机制特定保护例程产生的位字符串被编码成可在所有站点上普遍表示的字符，尽管不一定具有相同的位模式（例如，尽管字符“e”在基于ASCII的系统中表示为十六进制45，在基于EBCDIC的系统中表示为十六进制C5，这两种表示的局部意义是等效的）。
A 64-character subset of International Alphabet IA5 is used, enabling 6 bits to be represented per printable character. (The proposed subset of characters is represented identically in IA5 and ASCII.) The character "=" signifies a special processing function used for padding within the printable encoding procedure.
使用国际字母表IA5的64个字符子集，使每个可打印字符能够表示6位。（建议的字符子集在IA5和ASCII中表示相同。）字符“=”表示用于在可打印编码过程中填充的特殊处理函数。
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right across a 24-bit input group output from the security mechanism specific message protection procedure, each 6-bit group is used as an index into an array of 64 printable characters, namely "[A-Z][a-z][0-9]+/". The character referenced by the index is placed in the output string. These characters are selected so as to be universally representable, and the set excludes characters with particular significance to Telnet (e.g., "<CR>", "<LF>", IAC).
编码过程将输入位的24位组表示为4个编码字符的输出字符串。从安全机制特定的消息保护过程输出的24位输入组从左到右，每个6位组用作64个可打印字符数组的索引，即“[a-Z][a-Z][0-9]+/”。索引引用的字符被放置在输出字符串中。选择这些字符以使其具有普遍的代表性，并且该集合不包括对Telnet具有特殊意义的字符（例如，“<CR>”、“<LF>”、IAC）。
Special processing is performed if fewer than 24 bits are available in an input group at the end of a message. A full encoding quantum is always completed at the end of a message. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Output character positions which are not required to represent actual input data are set to the character "=". Since all canonically encoded output is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.
如果消息末尾的输入组中可用位少于24位，则执行特殊处理。完整编码量始终在消息末尾完成。当一个输入组中可用的输入位少于24位时，将添加零位（右侧）以形成整数个6位组。不需要表示实际输入数据的输出字符位置设置为字符“=”。由于所有规范编码的输出都是整数个八位字节，因此只能出现以下情况：（1）编码输入的最终量是24位的整数倍；这里，编码输出的最终单位将是4个字符的整数倍，没有“=”填充，（2）编码输入的最终量正好是8位；这里，编码输出的最终单位将是两个字符后跟两个“=”填充字符，或者（3）编码输入的最终量正好是16位；这里，编码输出的最终单位是三个字符，后跟一个“=”填充字符。
Implementors must keep in mind that the base 64 encodings in ADAT, MIC, CONF, and ENC commands, and in 63z replies may be arbitrarily long. Thus, the entire line must be read before it can be processed. Several successive reads on the control channel may be necessary. It is not appropriate to for a server to reject a command containing a base 64 encoding simply because it is too long (assuming that the decoding is otherwise well formed in the context in which it was sent).
实现者必须记住，ADAT、MIC、CONF和ENC命令以及63z应答中的基本64编码可能任意长。因此，必须先读取整行，然后才能对其进行处理。可能需要在控制通道上进行多次连续读取。如果服务器仅仅因为包含base 64编码的命令太长而拒绝该命令是不合适的（假设解码在发送该命令的上下文中格式良好）。
Case must not be ignored when reading commands and replies containing base 64 encodings.
在读取包含base 64编码的命令和回复时，不能忽略大小写。
This entire document deals with security considerations related to the File Transfer Protocol.
整个文档涉及与文件传输协议相关的安全注意事项。
Third party file transfers cannot be secured using these extensions, since a security context cannot be established between two servers using these facilities (no control connection exists between servers over which to pass ADAT tokens). Further work in this area is deferred.
无法使用这些扩展名保护第三方文件传输，因为无法使用这些功能在两台服务器之间建立安全上下文（要传递ADAT令牌的服务器之间不存在控制连接）。这方面的进一步工作推迟。
I would like to thank the members of the CAT WG, as well as all participants in discussions on the "cat-ietf@mit.edu" mailing list, for their contributions to this document. I would especially like to thank Sam Sjogren, John Linn, Ted Ts'o, Jordan Brown, Michael Kogut, Derrick Brashear, John Gardiner Myers, Denis Pinkas, and Karri Balk for their contributions to this work. Of course, without Steve Lunt, the author of the first six revisions of this document, it would not exist at all.
我要感谢CAT工作组的成员以及所有参与“CAT”讨论的参与者-ietf@mit.edu“邮件列表，感谢他们对本文件的贡献。我要特别感谢萨姆·佐格伦、约翰·林恩、特德·曹、乔丹·布朗、迈克尔·科古特、德里克·布拉希尔、约翰·加德纳·迈尔斯、丹尼斯·平卡斯和卡里·巴尔克对这项工作的贡献。当然，如果没有本文件前六次修订的作者Steve Lunt，它将根本不存在。
[TELNET-SEC] Borman, D., "Telnet Authentication and Encryption Option", Work in Progress.
[TELNET-SEC]Borman，D.，“TELNET身份验证和加密选项”，正在进行中。
[RFC-1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC-1123]Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
[RFC-1421]Linn，J.，“互联网电子邮件的隐私增强：第一部分：信息加密和认证程序”，RFC 14211993年2月。
Marc Horowitz Cygnus Solutions 955 Massachusetts Avenue Cambridge, MA 02139
马萨诸塞州剑桥马萨诸塞大道955号Marc Horowitz Cygnus Solutions，邮编：02139
Phone: +1 617 354 7688
EMail: marc@cygnus.com
Phone: +1 617 354 7688
EMail: marc@cygnus.com
Appendix I: Specification under the GSSAPI
附录一：GSSAPI下的规范
In order to maximise the utility of new security mechanisms, it is desirable that new mechanisms be implemented as GSSAPI mechanisms rather than as FTP security mechanisms. This will enable existing ftp implementations to support the new mechanisms more easily, since little or no code will need to be changed. In addition, the mechanism will be usable by other protocols, such as IMAP, which are built on top of the GSSAPI, with no additional specification or implementation work needed by the mechanism designers.
为了最大限度地利用新的安全机制，希望将新机制实现为GSSAPI机制，而不是FTP安全机制。这将使现有的ftp实现更容易支持新的机制，因为几乎不需要更改代码。此外，该机制还可以被其他协议使用，例如构建在GSSAPI之上的IMAP，机制设计者不需要额外的规范或实现工作。
The security mechanism name (for the AUTH command) associated with all mechanisms employing the GSSAPI is GSSAPI. If the server supports a security mechanism employing the GSSAPI, it must respond with a 334 reply code indicating that an ADAT command is expected next.
与使用GSSAPI的所有机制关联的安全机制名称（用于AUTH命令）为GSSAPI。如果服务器支持采用GSSAPI的安全机制，则它必须使用334回复代码进行响应，指示下一步需要ADAT命令。
The client must begin the authentication exchange by calling GSS_Init_Sec_Context, passing in 0 for input_context_handle (initially), and a targ_name equal to output_name from GSS_Import_Name called with input_name_type of Host-Based Service and input_name_string of "ftp@hostname" where "hostname" is the fully qualified host name of the server with all letters in lower case. (Failing this, the client may try again using input_name_string of "host@hostname".) The output_token must then be base 64 encoded and sent to the server as the argument to an ADAT command. If GSS_Init_Sec_Context returns GSS_S_CONTINUE_NEEDED, then the client must expect a token to be returned in the reply to the ADAT command. This token must subsequently be passed to another call to GSS_Init_Sec_Context. In this case, if GSS_Init_Sec_Context returns no output_token, then the reply code from the server for the previous ADAT command must have been 235. If GSS_Init_Sec_Context returns GSS_S_COMPLETE, then no further tokens are expected from the server, and the client must consider the server authenticated.
客户端必须通过调用GSS_Init_Sec_Context开始身份验证交换，为输入_Context_句柄（最初）传递0，并传递一个等于GSS_Import_name的输出_name的target_name，该名称由基于主机的服务的输入_name类型和输入_name_字符串调用ftp@hostname其中“主机名”服务器的完全限定主机名，所有字母均以小写字母表示。（如果失败，客户端可能会使用输入\名称\字符串重试”host@hostname“）然后必须对输出_令牌进行base 64编码，并将其作为ADAT命令的参数发送到服务器。如果GSS_Init_Sec_上下文返回所需的GSS_S_CONTINUE_，则客户端必须期望在对ADAT命令的答复中返回令牌。此令牌随后必须传递给另一个对GSS_Init_Sec_上下文的调用。在这种情况下，如果GSS_Init_Sec_上下文未返回任何output_令牌，则来自服务器的前一个ADAT命令的应答代码必须为235。如果GSSY-IITY-SeCixEnror返回GSSY-SH完成，则不会从服务器预期进一步的令牌，并且客户端必须考虑服务器验证。
The server must base 64 decode the argument to the ADAT command and pass the resultant token to GSS_Accept_Sec_Context as input_token, setting acceptor_cred_handle to NULL (for "use default credentials"), and 0 for input_context_handle (initially). If an output_token is returned, it must be base 64 encoded and returned to the client by including "ADAT=base64string" in the text of the reply. If GSS_Accept_Sec_Context returns GSS_S_COMPLETE, the reply code must be 235, and the server must consider the client authenticated. If GSS_Accept_Sec_Context returns GSS_S_CONTINUE_NEEDED, the reply code must be 335. Otherwise, the reply code should be 535, and the text of the reply should contain a descriptive error message.
服务器必须对ADAT命令的参数进行64位基本解码，并将结果令牌作为输入令牌传递给GSS_Accept_Sec_Context，将acceptor_cred_handle设置为NULL（用于“使用默认凭据”），将0设置为输入上下文句柄（最初）。如果返回一个输出标记，则必须对其进行base64编码，并通过在回复文本中包含“ADAT=base64string”将其返回给客户端。如果GSSYAccEtTySeCixEnror返回GSSY-SH完成，则应答代码必须为235，并且服务器必须考虑已验证的客户端。如果GSS_Accept_Sec_上下文返回GSS_CONTINUE_NEEDED，则回复代码必须为335。否则，回复代码应为535，回复文本应包含描述性错误消息。
The chan_bindings input to GSS_Init_Sec_Context and GSS_Accept_Sec_Context should use the client internet address and server internet address as the initiator and acceptor addresses, respectively. The address type for both should be GSS_C_AF_INET. No application data should be specified.
GSS_Init_Sec_上下文和GSS_Accept_Sec_上下文的chan_绑定输入应分别使用客户端internet地址和服务器internet地址作为发起方和接受方地址。两者的地址类型均应为GSS_C_AF_INET。不应指定任何应用程序数据。
Since GSSAPI supports anonymous peers to security contexts, it is possible that the client's authentication of the server does not actually establish an identity.
由于GSSAPI支持安全上下文的匿名对等点，因此客户端对服务器的身份验证可能不会实际建立身份。
The procedure associated with MIC commands, 631 replies, and Safe file transfers is:
与MIC命令、631应答和安全文件传输相关的过程如下：
GSS_Wrap for the sender, with conf_flag == FALSE
发送方的GSS_包装，conf_标志==FALSE
GSS_Unwrap for the receiver
GSS_为接收器展开
The procedure associated with ENC commands, 632 replies, and Private file transfers is:
与ENC命令、632回复和专用文件传输相关的过程如下：
GSS_Wrap for the sender, with conf_flag == TRUE GSS_Unwrap for the receiver
发送方的GSS_包装，接收方的conf_标志==TRUE GSS_展开
CONF commands and 633 replies are not supported.
不支持CONF命令和633回复。
Both the client and server should inspect the value of conf_avail to determine whether the peer supports confidentiality services.
客户端和服务器都应该检查conf_avail的值，以确定对等方是否支持保密服务。
When the security state is reset (when AUTH is received a second time, or when REIN is received), this should be done by calling the GSS_Delete_sec_context function.
当安全状态重置时（第二次收到AUTH或收到REIN时），应通过调用GSS_Delete_sec_上下文函数来完成。
Appendix II: Specification under Kerberos version 4
附录二：Kerberos版本4下的规范
The security mechanism name (for the AUTH command) associated with Kerberos Version 4 is KERBEROS_V4. If the server supports KERBEROS_V4, it must respond with a 334 reply code indicating that an ADAT command is expected next.
与Kerberos版本4关联的安全机制名称（用于AUTH命令）是Kerberos\u V4。如果服务器支持KERBEROS_V4，则它必须使用334回复代码进行响应，指示下一步需要ADAT命令。
The client must retrieve a ticket for the Kerberos principal "ftp.hostname@realm" by calling krb_mk_req(3) with a principal name of "ftp", an instance equal to the first part of the canonical host name of the server with all letters in lower case (as returned by krb_get_phost(3)), the server's realm name (as returned by krb_realmofhost(3)), and an arbitrary checksum. The ticket must then be base 64 encoded and sent as the argument to an ADAT command.
客户端必须检索Kerberos主体“ftp”的票证。hostname@realm“通过使用主体名称“ftp”调用krb_mk_req（3），一个实例等于服务器规范主机名的第一部分，所有字母都用小写（由krb_get_phost（3）返回），服务器的域名（由krb_realmofhost（3）返回），和任意校验和。然后，必须对票据进行base 64编码，并将其作为参数发送给ADAT命令。
If the "ftp" principal name is not a registered principal in the Kerberos database, then the client may fall back on the "rcmd" principal name (same instance and realm). However, servers must accept only one or the other of these principal names, and must not be willing to accept either. Generally, if the server has a key for the "ftp" principal in its srvtab, then that principal only must be used, otherwise the "rcmd" principal only must be used.
如果“ftp”主体名称不是Kerberos数据库中注册的主体，那么客户端可能会依赖于“rcmd”主体名称（相同的实例和领域）。但是，服务器必须只接受这些主体名称中的一个或另一个，并且不愿意接受任何一个。通常，如果服务器的srvtab中有“ftp”主体的密钥，则只能使用该主体，否则只能使用“rcmd”主体。
The server must base 64 decode the argument to the ADAT command and pass the result to krb_rd_req(3). The server must add one to the checksum from the authenticator, convert the result to network byte order (most significant byte first), and sign it using krb_mk_safe(3), and base 64 encode the result. Upon success, the server must reply to the client with a 235 code and include "ADAT=base64string" in the text of the reply. Upon failure, the server should reply 535.
服务器必须将参数base64解码为ADAT命令，并将结果传递给krb_rd_req（3）。服务器必须向验证器的校验和中添加一个，将结果转换为网络字节顺序（首先是最高有效字节），并使用krb_mk_safe（3）对其签名，并对结果进行base 64编码。成功后，服务器必须使用235代码回复客户端，并在回复文本中包含“ADAT=base64string”。失败时，服务器应回复535。
Upon receipt of the 235 reply from the server, the client must parse the text of the reply for the base 64 encoded data, decode it, convert it from network byte order, and pass the result to krb_rd_safe(3). The client must consider the server authenticated if the resultant checksum is equal to one plus the value previously sent.
在从服务器接收到235回复后，客户端必须解析基本64编码数据的回复文本，对其进行解码，将其从网络字节顺序转换，并将结果传递给krb_rd_safe（3）。如果得到的校验和等于加上先前发送的值，则客户端必须考虑服务器验证。
The procedure associated with MIC commands, 631 replies, and Safe file transfers is:
与MIC命令、631应答和安全文件传输相关的过程如下：
krb_mk_safe(3) for the sender krb_rd_safe(3) for the receiver
发送方的krb_mk_保险箱（3）接收方的krb_rd_保险箱（3）
The procedure associated with ENC commands, 632 replies, and Private file transfers is:
与ENC命令、632回复和专用文件传输相关的过程如下：
krb_mk_priv(3) for the sender krb_rd_priv(3) for the receiver
发送方的krb_mk_priv（3）接收方的krb_rd_priv（3）
CONF commands and 633 replies are not supported.
不支持CONF命令和633回复。
Note that this specification for KERBEROS_V4 contains no provision for negotiating alternate means for integrity and confidentiality routines. Note also that the ADAT exchange does not convey whether the peer supports confidentiality services.
请注意，此KERBEROS_V4规范不包含协商完整性和机密性例程替代方法的规定。还请注意，ADAT交换并不表示对等方是否支持保密服务。
In order to stay within the allowed PBSZ, implementors must take note that a cleartext buffer will grow by 31 bytes when processed by krb_mk_safe(3) and will grow by 26 bytes when processed by krb_mk_priv(3).
为了保持在允许的PBSZ内，实现者必须注意，当由krb_mk_safe（3）处理时，明文缓冲区将增长31字节，当由krb_mk_priv（3）处理时，明文缓冲区将增长26字节。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published andand distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。