Network Working Group T. Ts'o
Request for Comments: 2946 VA Linux Systems
Category: Standards Track September 2000
Network Working Group T. Ts'o
Request for Comments: 2946 VA Linux Systems
Category: Standards Track September 2000
Telnet Data Encryption Option
Telnet数据加密选项
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. While this document summarizes currently utilized encryption types and codes, it does not define a specific encryption algorithm. Separate documents are to be published defining implementations of this option for each encryption algorithm.
本文档描述了一种将telnet加密选项作为为telnet数据流提供数据机密性服务的通用方法。虽然本文档总结了当前使用的加密类型和代码，但并未定义特定的加密算法。将发布单独的文件，为每个加密算法定义此选项的实现。
ENCRYPT 38
加密38
Encryption Commands IS 0 SUPPORT 1 REPLY 2 START 3 END 4 REQUEST-START 5 REQUEST-END 6 ENC_KEYID 7 DEC_KEYID 8
加密命令为0支持1回复2开始3结束4请求开始5请求结束6加密密钥ID 7 DEC密钥ID 8
Encryption Types NULL 0 DES_CFB64 1 DES_OFB64 2
加密类型NULL 0 DES_CFB64 1 DES_OFB64 2
DES3_CFB64 3 DES3_OFB64 4 CAST5_40_CFB64 8 CAST5_40_OFB64 9 CAST128_CFB64 10 CAST128_OFB64 11
第3步是第4步是第5步是第40步是第8步是第9步是第12步是第10步
Following historical practice, future encryption type numbers will be assigned by the IANA under a First Come First Served policy as outlined by RFC 2434 [3]. Despite the fact that authentication type numbers are allocated out of an 8-bit number space (as are most values in the telnet specification) it is not anticipated that the number space is or will become in danger of being exhausted. However, if this should become an issue, when over 50% of the number space becomes allocated, the IANA shall refer allocation requests to either the IESG or a designated expert for approval.
按照历史惯例，IANA将按照RFC 2434[3]概述的先到先得政策分配未来的加密类型编号。尽管认证类型号是从8位数字空间中分配出来的（就像telnet规范中的大多数值一样），但预计数字空间不会或将有耗尽的危险。然而，如果这成为一个问题，当超过50%的数字空间被分配时，IANA应将分配请求提交给IESG或指定专家批准。
IAC WILL ENCRYPT
IAC将加密
The sender of this command is willing to send encrypted data.
此命令的发送方愿意发送加密数据。
IAC WONT ENCRYPT
IAC不会加密
The sender of this command refuses to send encrypted data.
此命令的发件人拒绝发送加密数据。
IAC DO ENCRYPT
加密
The sender of this command is willing to receive encrypted data.
此命令的发送方愿意接收加密数据。
IAC DONT ENCRYPT
IAC不加密
The sender of this command refuses to accept encrypted data.
此命令的发送方拒绝接受加密数据。
IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE
IAC SB加密支持加密类型列表IAC SE
The sender of this command is stating which types of encryption it will support. Only the side of the connection that is DO ENCRYPT may send the SUPPORT command. The current types of encryption are listed in the current version of the Assigned Numbers document [1].
此命令的发送方正在说明它将支持哪些类型的加密。只有连接的DO ENCRYPT端可以发送支持命令。当前的加密类型列在分配号码文档的当前版本中[1]。
The encryption-type-list may only include types which can actually be supported during the current session. If ENCRYPT is negotiated in conjunction with AUTH the SUPPORT message MUST NOT be sent until after the session key has been determined. Otherwise,
加密类型列表只能包括在当前会话期间实际支持的类型。如果加密与身份验证一起协商，则在确定会话密钥之前，不得发送支持消息。否则
it is impossible to know if the selected encryption type can be properly initialized based upon the type and length of the key that is available."
根据可用密钥的类型和长度，无法知道所选加密类型是否可以正确初始化。”
IAC SB ENCRYPT IS encryption-type ... IAC SE
IAC SB ENCRYPT是加密类型。。。IAC SE
The sender of this command is stating which type of encryption to use, and any initial data that is needed. Only the side of the connection that is WILL ENCRYPT may send the IS command to initialize the encryption-type scheme.
此命令的发送方将说明要使用的加密类型以及所需的任何初始数据。只有将加密的连接端可以发送is命令来初始化加密类型方案。
IAC SB ENCRYPT REPLY encryption-type ... IAC SE
IAC SB加密回复加密类型。。。IAC SE
The sender of this command is continuing the initial data exchange in order to initialize the encryption-type scheme. Only the side of the connection that is DO ENCRYPT may send the REPLY command.
此命令的发送方正在继续初始数据交换，以初始化加密类型方案。只有连接的DO ENCRYPT端可以发送应答命令。
IAC SB ENCRYPT START keyid IAC SE
IAC SB加密启动密钥ID IAC SE
The sender of this command is stating that all data following the command in the data stream will be be encrypted via the previously negotiated method of data encryption. Only the side of the connection that is WILL ENCRYPT may send the START command.
此命令的发送方声明数据流中的所有命令后的数据将通过先前协商的数据加密方法进行加密。只有将加密的连接端可以发送START命令。
The keyid is a variable length field. It is used by various encryption mechanisms to identify which encryption key is to be used, when multiple encryption keys might be known on either side of the connection. The keyid field is encoded with the most significant byte first, and a keyid value of zero is reserved to indicate the default encryption key (this would typically be an encryption key derived during authentication, with the AUTHENTICATION option). The keyid field must be at least one byte long. The only valid values for "keyid" will be those that have been received in a DEC_KEYID command.
keyid是一个可变长度字段。当连接的任意一侧都可能知道多个加密密钥时，各种加密机制使用它来标识要使用的加密密钥。keyid字段首先用最高有效字节编码，保留keyid值零以指示默认加密密钥（这通常是在身份验证期间派生的加密密钥，带有身份验证选项）。keyid字段的长度必须至少为一个字节。“keyid”的唯一有效值将是在DEC_keyid命令中接收到的值。
IAC SB ENCRYPT END IAC SE
IAC SB加密结束IAC SE
The sender of this command is stating that all data following the command in the data stream will not be encrypted. Only the side of the connection that is WILL ENCRYPT may send the END
此命令的发送方声明数据流中该命令之后的所有数据都不会加密。只有将要加密的连接端可以发送END
IAC SB ENCRYPT REQUEST-START keyid IAC SE
IAC SB加密请求启动密钥ID IAC SE
The sender of this command requests that the remote side begin encryption of the telnet data stream. Only the side of the connection that is DO ENCRYPT may send the REQUEST-START command. The keyid is only advisory, and my be omitted.
此命令的发送方请求远程端开始加密telnet数据流。只有连接的加密端可以发送REQUEST-START命令。keyid只是一个建议，不能省略我的。
IAC SB ENCRYPT REQUEST-END IAC SE
IAC SB加密请求端IAC SE
The sender of this command requests that the remote side stop encryption of the telnet data stream. Only the side of the connection that is DO ENCRYPT may send the REQUEST-END command.
此命令的发送方请求远程端停止telnet数据流的加密。只有连接的DO ENCRYPT端可以发送请求端命令。
IAC SB ENCRYPT ENC_KEYID keyid IAC SE
IAC SB加密ENC_密钥ID密钥ID IAC SE
The sender of this requests that the remote side verify that "keyid" maps to a valid key; or verifies that the "keyid" received in a DEC_KEYID command is valid. If keyid is omitted, it implies that there are no more known keyids, and that the attempt to find a common keyid has failed. Only the side of the connection that is WILL ENCRYPT may send the ENC_KEYID command.
此消息的发送方请求远程端验证“keyid”是否映射到有效密钥；或验证DEC_keyid命令中接收的“keyid”是否有效。如果省略了keyid，则表示没有更多已知的keyid，并且查找公共keyid的尝试失败。只有将加密的连接端可以发送ENC_KEYID命令。
IAC SB ENCRYPT DEC_KEYID keyid IAC SE
IAC SB ENCRYPT DEC_KEYID KEYID IAC SE
The sender of this requests that the remote side verify that "keyid" maps to a valid key on the remote side; or verifies that the "keyid" received in a ENC_KEYID command is valid. If keyid is omitted, it implies that there are no more known keyids, and that the attempt to find a common keyid has failed. Only the side of the connection that is DO ENCRYPT may send the DEC_KEYID command.
此消息的发送方请求远程端验证“keyid”是否映射到远程端的有效密钥；或验证在ENC_keyid命令中接收的“keyid”是否有效。如果省略了keyid，则表示没有更多已知的keyid，并且查找公共keyid的尝试失败。只有连接的加密端可以发送DEC_KEYID命令。
The default specification for this option is
此选项的默认规范为
WONT ENCRYPT DONT ENCRYPT
不加密不加密
meaning there will not be any encryption of the Telnet data stream.
这意味着不会对Telnet数据流进行任何加密。
The Telnet protocol has no form of protection from some intervening gateway looking at IP packets as they travel through the network. This is especially dangerous when passwords are sent as clear text over the network. This option provides a method for encrypting the data stream.
Telnet协议没有任何形式的保护，以防止某些干预网关在IP数据包通过网络时查看它们。当密码以明文形式通过网络发送时，这尤其危险。此选项提供加密数据流的方法。
Once the Encryption option is in effect, all data in the negotiated direction, including TELNET options, is encrypted. Encryption begins with the octet of data immediately following the "IAC SB ENCRYPT START encryption-type IAC SE" command. Encryption ends after the "IAC SB ENCRYPT END IAC SE" command.
一旦加密选项生效，协商方向上的所有数据（包括TELNET选项）都将加密。加密从紧跟在“IAC SB ENCRYPT START Encryption type IAC SE”命令之后的八位字节数据开始。加密在“IAC SB ENCRYPT END IAC SE”命令后结束。
WILL and DO are used only at the beginning of the connection to obtain and grant permission for future negotiations. The ENCRYPT option must be negotiated in both directions.
WILL和DO仅在连接开始时用于获取和授予未来谈判的许可。必须在两个方向协商加密选项。
Once the two hosts have exchanged a WILL and a DO, the sender of the DO ENCRYPT must send a ENCRYPT SUPPORT command to let the remote side know the types of encryption it is willing to accept. In the request, a list of supported encryption schemes is sent. Only the sender of the DO may send a list of supported encryption types (IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE). Only the sender of the WILL may actually transmit encrypted data. This is initiated via the "IAC SB ENCRYPT START IAC SE" command, and terminated via the "IAC SB ENCRYPT END IAC SE" command. If a START is received, and then a second START is received before receiving an END, the second START is ignored.
一旦两台主机交换了遗嘱和DO，DO ENCRYPT的发送方必须发送ENCRYPT SUPPORT命令，以让远程端知道它愿意接受的加密类型。在请求中，将发送支持的加密方案列表。只有DO的发送方可以发送支持的加密类型列表（IAC SB ENCRYPT SUPPORT encryption type list IAC SE）。只有遗嘱的发送者才能实际传输加密数据。这通过“IAC SB ENCRYPT START IAC SE”命令启动，并通过“IAC SB ENCRYPT END IAC SE”命令终止。如果接收到启动，然后在接收结束之前接收到第二个启动，则忽略第二个启动。
If the sender of the DO would like the remote side to begin sending encrypted data, it can send the "IAC SB ENCRYPT REQUEST-START IAC SE" command. If the sender of the DO would like the remote side to stop sending encrypted data, it can send the "IAC SB ENCRYPT REQUEST-STOP IAC SE" command.
如果DO的发送方希望远程端开始发送加密数据，则可以发送“IAC SB ENCRYPT REQUEST-START IAC SE”命令。如果DO的发送方希望远程端停止发送加密数据，则可以发送“IAC SB ENCRYPT REQUEST-stop IAC SE”命令。
If the receiver of the SUPPORT command does not support any of the encryption types listed in the SUPPORT command, it should send an "IAC SB ENCRYPT IS NULL IAC SE" to indicate that there are no encryption types in common. It may also send an IAC WONT ENCRYPT command to turn off the ENCRYPT option.
如果SUPPORT命令的接收者不支持SUPPORT命令中列出的任何加密类型，则应发送“IAC SB ENCRYPT IS NULL IAC SE”以指示没有共同的加密类型。它还可能发送IAC WONT ENCRYPT命令以关闭加密选项。
The order of the encryption types in a SUPPORT command must be ordered to indicate a preference for different encryption types, the first type being the most preferred, and the last type the least preferred.
支持命令中加密类型的顺序必须进行排序，以指示不同加密类型的首选项，第一种类型是最首选的，最后一种类型是最不首选的。
If the ENCRYPT option has been enabled, and encrypted data is being received, the receipt of an "IAC WONT ENCRYPT" implies the receipt of an "IAC SB ENCRYPT END IAC SE", e.g., the Telnet data stream is no longer encrypted.
如果已启用加密选项，并且正在接收加密数据，则接收到“IAC WONT ENCRYPT”意味着接收到“IAC SB ENCRYPT END IAC SE”，例如，Telnet数据流不再加密。
The following example demonstrates the use of the option:
以下示例演示了该选项的使用：
Host1 Host2
Host1 Host2
[ Host1 requests Host2 negotiate the encryption of data that
Host2 sends to Host1. Host2 agrees to negotiate the encryption
of data that it sends to Host1. ]
DO ENCRYPT
WILL ENCRYPT
[ Host1 requests that Host2 enable encryption as soon as the
initialization is completed, and informs Host2 that is supports
DES_CFB64. ]
IAC SB ENCRYPT REQUEST-START IAC
SE
IAC SB ENCRYPT SUPPORT DES_CFB64
IAC SE
[ Host2 sends the initial feed to Host1. Host1 acknowledges
receipt of the IV. ]
IAC SB ENCRYPT IS DES_CFB64
CFB64_IV 144 146 63 229 237 148
81 143 IAC SE
IAC SB ENCRYPT REPLY DES_CFB64
CFB64_IV_OK 103 207 181 71 224
55 229 98 IAC SE
[ Host2 is now free to start sending encrypted data, and since a
REQUEST-START was received, it enables encryption. ]
IAC SB ENCRYPT START IAC SE
[ All data from Host2 to Host1 is now encrypted. ]
IAC SB ENCRYPT END IAC SE
[ All data from Host2 to Host1 is now in clear text again. ]
[ Host1 requests Host2 negotiate the encryption of data that
Host2 sends to Host1. Host2 agrees to negotiate the encryption
of data that it sends to Host1. ]
DO ENCRYPT
WILL ENCRYPT
[ Host1 requests that Host2 enable encryption as soon as the
initialization is completed, and informs Host2 that is supports
DES_CFB64. ]
IAC SB ENCRYPT REQUEST-START IAC
SE
IAC SB ENCRYPT SUPPORT DES_CFB64
IAC SE
[ Host2 sends the initial feed to Host1. Host1 acknowledges
receipt of the IV. ]
IAC SB ENCRYPT IS DES_CFB64
CFB64_IV 144 146 63 229 237 148
81 143 IAC SE
IAC SB ENCRYPT REPLY DES_CFB64
CFB64_IV_OK 103 207 181 71 224
55 229 98 IAC SE
[ Host2 is now free to start sending encrypted data, and since a
REQUEST-START was received, it enables encryption. ]
IAC SB ENCRYPT START IAC SE
[ All data from Host2 to Host1 is now encrypted. ]
IAC SB ENCRYPT END IAC SE
[ All data from Host2 to Host1 is now in clear text again. ]
It is expected that any implementation that supports the Telnet ENCRYPT option will support all of this specification.
任何支持Telnet ENCRYPT选项的实现都将支持此规范的所有内容。
The ENCRYPT option used in isolation provides protection against passive attacks, but not against active attacks. In other words, it will provide protection from someone who is just watching the IP packets as they pass through the network. However, an attacker who is able to modify packets in flight could prevent the ENCRYPT option from being negotiated.
单独使用的ENCRYPT选项提供了针对被动攻击的保护，但不能针对主动攻击。换言之，它将提供保护，以防有人在IP数据包通过网络时监视它们。但是，能够在飞行中修改数据包的攻击者可能会阻止协商加密选项。
This flaw can be remedied by using the Telnet Authentication option alongside the ENCRYPT option. Specifically, setting ENCRYPT_USING_TELOPT in the authentication-type-pair can be used to force that Encryption be negotiated even in the face of active attacks.
此漏洞可以通过在加密选项旁边使用Telnet身份验证选项来修复。具体地说，在身份验证类型对中设置ENCRYPT_USING_TELOPT可用于强制协商加密，即使在面临主动攻击时也是如此。
In addition, an active attacker can interfere with attempts to start or restart encryption. If encryption is requested by the user, and the client is unable to negotiate enabling or re-enabling encryption, the client must assume that it is being attacked, and MUST immediately terminate the telnet connection.
此外，活动攻击者可以干扰启动或重新启动加密的尝试。如果用户请求加密，而客户端无法协商启用或重新启用加密，则客户端必须假定它受到攻击，并且必须立即终止telnet连接。
The specification defines a method for providing data confidentiality to the telnet data stream. Unfortunately all of the encryption mechanism provided under this option do not provide data integrity, because of the complexity of specifying a protocol which provided integrity services efficiently in a stream-oriented protocol.
该规范定义了一种为telnet数据流提供数据机密性的方法。不幸的是，此选项下提供的所有加密机制都不提供数据完整性，因为在面向流的协议中指定有效提供完整性服务的协议非常复杂。
The TELNET START_TLS specification provides a scheme which provides confidentiality, integrity, and compression, and future work for telnet encryption should closely examine using this specification. One promising approach would use the anonymous Diffie-Hellman mode of TLS, followed by the telnet AUTHENTICATION option where the authentication mechanism would include the client and server finished messages computed during the TLS negotiation.
TELNET START_TLS规范提供了一个提供机密性、完整性和压缩的方案，TELNET加密的未来工作应使用该规范进行仔细检查。一种有希望的方法是使用TLS的匿名Diffie-Hellman模式，然后是telnet身份验证选项，其中身份验证机制将包括在TLS协商期间计算的客户端和服务器完成的消息。
This document was originally written by Dave Borman of Cray Research, with the assistance of Theodore Ts'o of MIT and the IETF Telnet Working Group.
本文件最初由Cray Research的Dave Borman在麻省理工学院的Theodore T'o和IETF Telnet工作组的协助下编写。
[1] Reynolds, J. and J. Postel, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[1] Reynolds，J.和J.Postel，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
[2] Ts'o，T.和J.Altman，“Telnet认证选项”，RFC 29412000年9月。
[3] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Alvestrand，H.和T.Narten，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
Theodore Ts'o, Editor VA Linux Systems 43 Pleasant St. Medford, MA 02155
西奥多·曹，编辑VA Linux Systems 43马萨诸塞州圣梅德福德，邮编02155
Phone: (781) 391-3464 EMail: tytso@mit.edu
电话：（781）391-3464电子邮件：tytso@mit.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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 implementation may be prepared, copied, published and 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。