Network Working Group T. Ts'o, Editor
Request for Comments: 2941 VA Linux Systems
Obsoletes: 1416 J. Altman
Category: Standards Track Columbia University
September 2000
Network Working Group T. Ts'o, Editor
Request for Comments: 2941 VA Linux Systems
Obsoletes: 1416 J. Altman
Category: Standards Track Columbia University
September 2000
Telnet Authentication 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 the authentication option to the telnet [1] protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type.
本文档将telnet[1]协议的身份验证选项描述为协商身份验证类型和模式的通用方法，包括是否应使用加密以及是否应转发凭据。虽然本文档总结了当前使用的命令和类型，但并未定义特定的身份验证类型。将发布定义每种认证类型的单独文件。
This document updates a previous specification of the telnet authentication option, RFC 1416 [2], so that it can be used to securely enable the telnet encryption option [3].
本文档更新了以前的telnet身份验证选项规范RFC 1416[2]，以便可以使用它安全地启用telnet加密选项[3]。
AUTHENTICATION 37
认证37
Authentication Commands IS 0 SEND 1 REPLY 2 NAME 3
身份验证命令为0发送1回复2名称3
Authentication Types NULL 0 KERBEROS_V4 1
身份验证类型NULL 0 KERBEROS\u V4 1
KERBEROS_V5 2 SPX* 3 MINK* 4 SRP 5 RSA*[also used by SRA*] 6 SSL* 7 [unassigned] 8 [unassigned] 9 LOKI* 10 SSA* 11 KEA_SJ 12 KEA_SJ_INTEG 13 DSS 14 NTLM* 15
KERBEROS_V5 2 SPX*3 MINK*4 SRP 5 RSA*[也由SRA使用*]6 SSL*7[未分配]8[未分配]9 LOKI*10 SSA*11 KEA_SJ 12 KEA_SJ_INTEG 13 DSS 14 NTLM*15
Authentication types followed by (*) were never submitted to the IETF for consideration as an Internet standard.
后跟（*）的认证类型从未提交给IETF作为互联网标准考虑。
Following historical practice, future authentication type numbers and authentication modifiers will be assigned by the IANA under a First Come First Served policy as outlined by RFC 2434 [4]. 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 is instructed not to issue new suboption values without submission of documentation of their use.
按照历史惯例，IANA将按照RFC 2434[4]概述的先到先得政策分配未来的认证类型编号和认证修饰符。尽管认证类型号是从8位数字空间中分配出来的（就像telnet规范中的大多数值一样），但预计数字空间不会或将有耗尽的危险。然而，如果这成为一个问题，当超过50%的数字空间被分配时，IANA应将分配请求提交给IESG或指定专家批准。IANA被指示在未提交使用文件的情况下不得发布新的子选项值。
Modifiers AUTH_WHO_MASK 1 AUTH_CLIENT_TO_SERVER 0 AUTH_SERVER_TO_CLIENT 1
修饰符AUTH_WHO_掩码1 AUTH_CLIENT_TO_SERVER 0 AUTH_SERVER_TO_CLIENT 1
AUTH_HOW_MASK 2 AUTH_HOW_ONE_WAY 0 AUTH_HOW_MUTUAL 2
验证方式掩码2验证方式单向0验证方式双向2
ENCRYPT_MASK 20 ENCRYPT_OFF 0 ENCRYPT_USING_TELOPT 4 ENCRYPT_AFTER_EXCHANGE 16 ENCRYPT_RESERVED 20
加密\u掩码20加密\u关闭0使用\u TELOPT 4加密\u交换后16加密\u保留20
INI_CRED_FWD_MASK 8 INI_CRED_FWD_OFF 0
这张面具8张，这张面具关闭了0张
INI_CRED_FWD_ON 8
这是8号的信
This document makes reference to a "server" and a "client". For the purposes of this document, the "server" is the side of the connection that performed the passive TCP open (TCP LISTEN state), and the "client" is the side of the connection that did the active open.
本文档引用了“服务器”和“客户端”。在本文档中，“服务器”是执行被动TCP打开（TCP侦听状态）的连接端，“客户端”是执行主动打开的连接端。
IAC WILL AUTHENTICATION
IAC将进行身份验证
The client side of the connection sends this command to indicate that it is willing to send and receive authentication information.
连接的客户端发送此命令以指示它愿意发送和接收身份验证信息。
IAC DO AUTHENTICATION
IAC DO认证
The servers side of the connection sends this command to indicate that it is willing to send and receive authentication information.
连接的服务器端发送此命令以指示它愿意发送和接收身份验证信息。
IAC WONT AUTHENTICATION
自动认证
The client side of the connection sends this command to indicate that it refuses to send or receive authentication information; the server side must send this command if it receives a DO AUTHENTICATION command.
连接的客户端发送此命令以指示它拒绝发送或接收身份验证信息；如果服务器端收到DO身份验证命令，则必须发送此命令。
IAC DONT AUTHENTICATION
IAC身份验证
The server side of the connection sends this command to indicate that it refuses to send or receive authentication information; the client side must send this command if it receives a WILL AUTHENTICATION command.
连接的服务器端发送此命令以指示它拒绝发送或接收身份验证信息；如果客户端收到WILL身份验证命令，则必须发送此命令。
IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC SE
IAC SB身份验证发送身份验证类型对列表IAC SE
The sender of this command (the server) requests that the remote side send authentication information for one of the authentication types listed in "authentication-type-pair-list". The "authentication-type-pair-list" is an ordered list of "authentication-type" pairs. Only the server side (DO AUTHENTICATION) is allowed to send this.
此命令的发送方（服务器）请求远程端发送“身份验证类型对列表”中列出的身份验证类型之一的身份验证信息。“认证类型对列表”是“认证类型”对的有序列表。仅允许服务器端（DO身份验证）发送此消息。
IAC SB AUTHENTICATION IS authentication-type-pair <auth data> IAC SE
IAC SB身份验证是身份验证类型对<auth data>IAC SE
The sender of this command (the client) is sending the authentication information for authentication type "authentication-type-pair". Only the client side (WILL AUTHENTICATION) is allowed to send this.
此命令的发送方（客户端）正在发送身份验证类型“身份验证类型对”的身份验证信息。仅允许客户端（WILL AUTHENTICATION）发送此消息。
IAC SB AUTHENTICATION REPLY authentication-type-pair <auth data> IAC SE
IAC SB身份验证应答身份验证类型对<auth data>IAC SE
The sender of this command (the server) is sending a reply to the the authentication information received in a previous IS command. Only the server side (DO AUTHENTICATION) is allowed to send this.
此命令的发送方（服务器）正在发送对上一个is命令中接收到的身份验证信息的回复。仅允许服务器端（DO身份验证）发送此消息。
IAC SB AUTHENTICATION NAME remote-user IAC SE
IAC SB身份验证名称远程用户IAC SE
This optional command is sent to specify the account name on the remote host that the user wishes to be authorized to use. Note that authentication may succeed, and the authorization to use a particular account may still fail. Some authentication mechanisms may ignore this command.
发送此可选命令是为了指定用户希望被授权使用的远程主机上的帐户名。请注意，身份验证可能会成功，使用特定帐户的授权仍可能失败。某些身份验证机制可能会忽略此命令。
The "authentication-type-pair" is two octets, the first is the authentication type, and the second is a modifier to the type. The authentication type may or may not include built-in encryption. For instance, when the Kerberos 4 authentication type is negotiated encryption must be negotiated with the telnet ENCRYPT option. However, the SSL and KEA_SJ authentication types provide an encrypted channel as part of a successful telnet AUTH option negotiation.
“身份验证类型对”是两个八位字节，第一个是身份验证类型，第二个是类型的修饰符。身份验证类型可能包括也可能不包括内置加密。例如，当Kerberos 4身份验证类型为协商加密时，必须使用telnet ENCRYPT选项协商加密。但是，SSL和KEA_SJ身份验证类型提供了一个加密通道，作为成功的telnet身份验证选项协商的一部分。
There are currently five one bit fields defined in the modifier. The first two of these bits are processed as a pair, the AUTH_WHO_MASK bit and the AUTH_HOW_MASK bit. There are four possible combinations of these two bits:
修改器中当前定义了五个一位字段。前两个位成对处理，即身份验证谁屏蔽位和身份验证如何屏蔽位。这两个位有四种可能的组合：
AUTH_CLIENT_TO_SERVER AUTH_HOW_ONE_WAY
身份验证客户端到服务器身份验证方式
The client will send authentication information about the local user to the server. If the negotiation is successful, the server will have authenticated the user on the client side of the connection.
客户端将向服务器发送有关本地用户的身份验证信息。如果协商成功，服务器将在连接的客户端对用户进行身份验证。
AUTH_SERVER_TO_CLIENT AUTH_HOW_ONE_WAY
身份验证服务器到客户端身份验证方式
The server will authenticate itself to the client. If the negotiation is successful, the client will know that it is connected to the server that it wants to be connected to.
服务器将向客户端进行自身身份验证。如果协商成功，客户端将知道它已连接到要连接的服务器。
AUTH_CLIENT_TO_SERVER AUTH_HOW_MUTUAL
身份验证客户端到服务器身份验证方式
The client will send authentication information about the local user to the server, and then the server will authenticate
客户端将向服务器发送有关本地用户的身份验证信息，然后服务器将进行身份验证
itself to the client. If the negotiation is successful, the server will have authenticated the user on the client side of the connection, and the client will know that it is connected to the server that it wants to be connected to.
把它自己交给客户。如果协商成功，服务器将在连接的客户端对用户进行身份验证，并且客户端将知道它已连接到要连接的服务器。
AUTH_SERVER_TO_CLIENT AUTH_HOW_MUTUAL
身份验证服务器到客户端身份验证方式
The server will authenticate itself to the client, and then the client will authenticate itself to the server. If the negotiation is successful, the client will know that it is connected to the server that it wants to be connected to, and the server will know that the client is who it claims to be.
服务器将向客户机进行自身身份验证，然后客户机将向服务器进行自身身份验证。如果协商成功，客户机将知道它已连接到它想要连接的服务器，并且服务器将知道客户机就是它声称的客户机。
The third and fifth bits in the modifier are the ENCRYPT_MASK bits. These bits are used to determine if and how encryption should be enabled. Of the four possible combinations only three are currently defined:
修饰符中的第三位和第五位是加密掩码位。这些位用于确定是否以及如何启用加密。在四种可能的组合中，目前仅定义了三种：
ENCRYPT_OFF
加密关闭
Encryption will not be used for this session. TELOPT ENCRYPT SHOULD NOT be negotiated. This mode MUST be used with all AUTH types that do not provide a shared secret to be used as a session key.
加密将不用于此会话。不应协商TELOPT ENCRYPT。此模式必须与所有未提供用作会话密钥的共享密钥的身份验证类型一起使用。
ENCRYPT_USING_TELOPT
使用_TELOPT加密
Encryption will be negotiated via the use of TELOPT ENCRYPT. Immediately after authentication has completed TELOPT ENCRYPT MUST be negotiated in both directions. This is required to occur before credentials forwarding; other telnet options are negotiated; or any user data is transmitted. A failure to successfully negotiate TELOPT ENCRYPT in either direction MUST result in immediate session termination.
加密将通过使用TELOPT ENCRYPT进行协商。验证完成后，必须立即在两个方向协商TELOPT加密。这需要在凭证转发之前发生；其他telnet选项正在协商中；或者传输任何用户数据。未能成功协商任一方向的TELOPT ENCRYPT必须立即终止会话。
ENCRYPT_AFTER_EXCHANGE
交换后加密\u
Encryption will be activated in both directions immediately after the successful exchange of the shared secret to be used as the session key. The encryption algorithm to be used MUST be implied by the AUTH type.
成功交换用作会话密钥的共享密钥后，将立即在两个方向上激活加密。要使用的加密算法必须由AUTH类型暗示。
The fourth bit field in the modifier is the INI_CRED_FWD_MASK bit. This bit is either set to INI_CRED_FWD_ON or INI_CRED_FWD_OFF. This bit is set by the client to advise the server to expect forwarded credentials from the client.
修饰符中的第四位字段是INI_CRED_FWD_掩码位。该位设置为INI_CRED_FWD_ON或INI_CRED_FWD_OFF。此位由客户端设置，以建议服务器期望从客户端转发凭据。
INI_CRED_FWD_OFF
这是我的信
The client will not be forwarding credentials to the server. This mode must be used if the selected authentication method does not support credentials forwarding.
客户端将不会将凭据转发到服务器。如果选定的身份验证方法不支持凭据转发，则必须使用此模式。
INI_CRED_FWD_ON
这是我的信
Once authentication, and perhaps encryption, completes, the client will immediately forward authentication credentials to the server.
一旦身份验证（可能还有加密）完成，客户端将立即将身份验证凭据转发给服务器。
The motivation for this advisory bit is that the server may wish to wait until the forwarded credentials have been sent before starting any operating system specific login procedures which may depend on these credentials. Note that credentials forwarding may not be supported by all authentication mechanisms. It is a protocol error to set this bit if the underlying authentication mechanism does not support credentials forwarding.
此建议位的动机是，服务器可能希望在启动任何操作系统特定的登录过程（可能依赖于这些凭据）之前，等待转发的凭据发送完毕。请注意，并非所有身份验证机制都支持凭据转发。如果基础身份验证机制不支持凭据转发，则设置此位是一个协议错误。
Credentials forwarding MUST NOT be performed if AUTH_CLIENT_TO_SERVER|AUTH_HOW_ONE_WAY was used since the identity of the server can not be assured. Credentials SHOULD NOT be forwarded if the telnet connection is not protected using some encryption or integrity protection services.
如果身份验证客户端到服务器，身份验证单向使用，则不得执行凭据转发，因为无法确保服务器的身份。如果telnet连接未使用某些加密或完整性保护服务进行保护，则不应转发凭据。
Note that older implementations of the telnet authentication option will not understand the ENCRYPT_MASK and INI_CRED_FWD_MASK bits. Hence an implementation wishing to offer these bits should offer authentication type pairs with these bits both set and not set if backwards compatibility is required.
请注意，telnet身份验证选项的旧实现将不理解加密掩码和INI_CRED_FWD_掩码位。因此，如果需要向后兼容，则希望提供这些位的实现应提供这些位已设置和未设置的身份验证类型对。
The default specification for this option is
此选项的默认规范为
WONT AUTHENTICATION DONT AUTHENTICATION
身份验证不需要身份验证吗
meaning there will not be any exchange of authentication information.
这意味着不会有任何身份验证信息的交换。
One of the deficiencies of the Telnet protocol is that in order to log into remote systems, users have to type their passwords, which are passed in clear text through the network. If the connections go through untrusted networks, there is the possibility that passwords will be compromised by someone watching the packets while in transit.
Telnet协议的一个缺陷是，为了登录远程系统，用户必须键入密码，密码以明文形式通过网络传递。如果连接通过不受信任的网络，则有可能在传输过程中有人监视数据包而泄露密码。
The purpose of the AUTHENTICATION option is to provide a framework for the passing of authentication information through the TELNET session, and a mechanism to enable encryption of the data stream as a side effect of successful authentication or via subsequent use of the telnet ENCRYPT option. This means that: 1) the users password will not be sent in clear text across the network, 2) if the front end telnet process has the appropriate authentication information, it can automatically send the information, and the user will not have to type any password. 3) once authentication has succeeded, the data stream can be encrypted to provide protection against active attacks.
身份验证选项的目的是提供一个框架，用于通过TELNET会话传递身份验证信息，以及一种机制，以作为成功身份验证的副作用或通过随后使用TELNET ENCRYPT选项来启用数据流加密。这意味着：1）用户密码不会通过网络以明文形式发送，2）如果前端telnet进程具有适当的身份验证信息，它可以自动发送信息，用户不必键入任何密码。3） 身份验证成功后，可以对数据流进行加密，以防止主动攻击。
It is intended that the AUTHENTICATION option be general enough that it can be used to pass information for any authentication and encryption system.
认证选项应足够通用，可用于传递任何认证和加密系统的信息。
The ability to negotiate a common authentication mechanism between client and server is a feature of the authentication option that should be used with caution. When the negotiation is performed, no authentication has yet occurred. Therefore each system has no way of knowing whether or not it is talking to the system it intends. An intruder could attempt to negotiate the use of an authentication system which is either weak, or already compromised by the intruder.
在客户机和服务器之间协商通用身份验证机制的能力是身份验证选项的一项功能，应谨慎使用。执行协商时，尚未发生身份验证。因此，每个系统都无法知道它是否正在与它想要的系统对话。入侵者可能会尝试协商身份验证系统的使用，该系统要么很弱，要么已经被入侵者破坏。
If the authentication type requires that encryption be enabled as a separate optional negotiation (the ENCRYPT option), it will provide a window of vulnerability from when the authentication completes, up to and including the negotiation to turn on encryption by an active attacker. An active attack is one where the underlying TCP stream can be modified or taken over by the active attacker. If the server only offers authentication type pairs that include the ENCRYPT_USING_TELOPT set in the ENCRYPT_MASK field, this will avoid the window of vulnerability, since both parties will agree that telnet ENCRYPT option must be successfully negotiated immediately following the successful completion of telnet AUTH.
如果身份验证类型要求将加密作为单独的可选协商（加密选项）启用，则它将提供一个漏洞窗口，从身份验证完成时开始，直到并包括由活动攻击者开启加密的协商。主动攻击是指主动攻击者可以修改或接管底层TCP流的攻击。如果服务器仅提供包含ENCRYPT_MASK字段中ENCRYPT_USING_TELOPT集的身份验证类型对，这将避免出现漏洞窗口，因为双方同意，必须在telnet AUTH成功完成后立即成功协商telnet ENCRYPT选项。
Other authentication types link the enabling of encryption as a side effect of successful authentication. This will also provide protection against the active attacker. The ENCRYPT_AFTER_EXCHANGE bit allows these authentication types to negotiate encryption so that it can be made optional.
其他身份验证类型将启用加密链接为成功身份验证的副作用。这还将提供针对活动攻击者的保护。ENCRYPT\u AFTER\u交换位允许这些身份验证类型协商加密，以便使其成为可选的。
Another opportunity for active attacks is presented when encryption may be turned on and off without re-authentication. Once encryption is disabled, an attacker may hijack the telnet stream, and interfere with attempts to restart encryption. Therefore, a client SHOULD NOT
当可以在不重新验证的情况下打开和关闭加密时，会出现另一种主动攻击的机会。一旦禁用加密，攻击者可能会劫持telnet流，并干扰重新启动加密的尝试。因此，客户机不应该
support the ability to turn off encryption. Once encryption is disabled, if an attempt to re-enable encryption fails, the client MUST terminate the telnet connection.
支持关闭加密功能。禁用加密后，如果重新启用加密的尝试失败，客户端必须终止telnet连接。
It is important that in both cases the authentication type pair be integrity protected at the end of the authentication exchange. This must be specified for each authentication type to ensure that the result of the telnet authentication option negotiation is agreed to by both the client and the server. Some authentication type suboptions may wish to include all of the telnet authentication negotiation exchanges in the integrity checksum, to fully protect the entire exchange.
在这两种情况下，身份验证类型对都必须在身份验证交换结束时受到完整性保护。必须为每种身份验证类型指定此选项，以确保客户端和服务器都同意telnet身份验证选项协商的结果。某些身份验证类型子选项可能希望在完整性校验和中包括所有telnet身份验证协商交换，以完全保护整个交换。
Each side MUST verify the consistency of the auth-type-pairs in each message received. Any variation in the auth-type-pair MUST be treated as a fatal protocol error.
每一方必须验证收到的每条消息中的身份验证类型对的一致性。身份验证类型对中的任何变化都必须视为致命的协议错误。
WILL and DO are used only at the beginning of the connection to obtain and grant permission for future negotiations.
WILL和DO仅在连接开始时用于获取和授予未来谈判的许可。
The authentication is only negotiated in one direction; the server must send the "DO", and the client must send the "WILL". This restriction is due to the nature of authentication; there are three possible cases; server authenticates client, client authenticates server, and server and client authenticate each other. By only negotiating the option in one direction, and then determining which of the three cases is being used via the suboption, potential ambiguity is removed. If the server receives a "DO", it must respond with a "WONT". If the client receives a "WILL", it must respond with a "DONT".
认证仅在一个方向上协商；服务器必须发送“DO”，客户端必须发送“WILL”。这种限制是由于身份验证的性质造成的；有三种可能的情况；服务器验证客户端，客户端验证服务器，服务器和客户端相互验证。通过仅在一个方向上协商选项，然后通过子选项确定三种情况中的哪一种正在使用，可以消除潜在的歧义。如果服务器收到“DO”，则必须以“WONT”响应。如果客户收到“遗嘱”，则必须回答“不”。
Once the two hosts have exchanged a DO and a WILL, the server is free to request authentication information. In the request, a list of supported authentication types is sent. Only the server may send requests ("IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC SE"). Only the client may transmit authentication information via the "IAC SB AUTHENTICATION IS authentication-type ... IAC SE" command. Only the server may send replies ("IAC SB AUTHENTICATION REPLY authentication-type ... IAC SE"). As many IS and REPLY suboptions may be exchanged as are needed for the particular authentication scheme chosen.
一旦两台主机交换了DO和WILL，服务器就可以自由请求身份验证信息。在请求中，将发送支持的身份验证类型列表。只有服务器可以发送请求（“IAC SB AUTHENTICATION send AUTHENTICATION type pair list IAC SE”）。只有客户端可以通过“IAC SB authentication IS authentication type…IAC SE”命令传输身份验证信息。只有服务器可以发送回复（“IAC SB认证回复认证类型…IAC SE”）。对于所选择的特定认证方案，可以根据需要交换尽可能多的IS和REPLY子选项。
If the client does not support any of the authentication types listed in the authentication-type-pair-list, a type of NULL should be used to indicate this in the IS reply. Note that if the client responds with a type of NULL, the server may choose to close the connection.
如果客户端不支持“身份验证类型对”列表中列出的任何身份验证类型，则应在IS应答中使用NULL类型来指示这一点。请注意，如果客户机以NULL类型响应，服务器可能会选择关闭连接。
When the server has concluded that authentication cannot be negotiated with the client it should send IAC DONT AUTH to the client.
当服务器断定无法与客户端协商身份验证时，它应向客户端发送IAC NOT AUTH。
The order of the authentication types MUST be ordered to indicate a preference for different authentication types, the first type being the most preferred, and the last type the least preferred.
必须对认证类型的顺序进行排序，以指示不同认证类型的首选项，第一种类型是最首选的，最后一种类型是最不首选的。
As long as the server is WILL AUTH it may request authentication information at any time. This is done by sending a new list of supported authentication types. Requesting authentication information may be done as a way of verifying the validity of the client's credentials after an extended period of time or to negotiate a new session key for use during encryption.
只要服务器进行身份验证，它就可以随时请求身份验证信息。这是通过发送支持的身份验证类型的新列表来完成的。请求认证信息可以作为在延长的时间段之后验证客户端凭证的有效性的一种方式，或者协商用于加密期间的新会话密钥。
Normally protocol specifications do not address user interface specifications. However, due to the fact that the user will probably want to be able to configure the authentication and encryption and know whether or not the negotiations succeeded, some guidance needs to be given to implementors to provide some minimum level of user control.
通常，协议规范不涉及用户界面规范。然而，由于用户可能希望能够配置身份验证和加密，并知道协商是否成功，因此需要向实施者提供一些指导，以提供某种最低级别的用户控制。
The user MUST be able to specify whether or not authentication is to be used, and whether or not encryption is to used if the authentication succeeds. There SHOULD be at least four settings, REQUIRE, PROMPT, WARN and DISABLE. Setting the authentication switch to REQUIRE means that if the authentication fails, then an appropriate error message must be displayed and the TELNET connection must be terminated. Setting the authentication switch to PROMPT means that if the authentication fails, then an appropriate error message must be displayed and the user must be prompted for confirmation before continuing the TELNET session. Setting the authentication switch to WARN means that if the authentication fails, then an appropriate error message must be displayed before continuing the TELNET session. Setting the authentication switch to DISABLE means that authentication will not be attempted. The encryption switch SHOULD have the same settings as the authentication switch; however its settings are only used when authentication succeeds. The default setting for both switches should be WARN. Both of these switches may be implemented as a single switch, though having them separate gives more control to the user.
用户必须能够指定是否使用身份验证，以及如果身份验证成功，是否使用加密。应该至少有四种设置，需要、提示、警告和禁用。将身份验证开关设置为REQUIRE意味着如果身份验证失败，则必须显示相应的错误消息，并且必须终止TELNET连接。将身份验证开关设置为“提示”意味着，如果身份验证失败，则必须显示相应的错误消息，并且在继续TELNET会话之前，必须提示用户进行确认。将身份验证开关设置为警告意味着，如果身份验证失败，则必须在继续TELNET会话之前显示相应的错误消息。将身份验证开关设置为禁用意味着不会尝试身份验证。加密交换机应具有与身份验证交换机相同的设置；但是，其设置仅在身份验证成功时使用。两个开关的默认设置都应为WARN。这两个开关都可以作为一个开关来实现，尽管将它们分开可以为用户提供更多的控制。
The following is an example of use of the option:
以下是使用该选项的示例：
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KERBEROS_V4 CLIENT|MUTUAL
KERBEROS_V4 CLIENT|ONE_WAY IAC
SE
[ The server has requested mutual Kerberos authentication, but is
willing to do just one-way Kerberos authentication. The client
will now respond with the name of the user that it wants to log
in as, and the Kerberos ticket. ]
IAC SB AUTHENTICATION NAME "joe"
IAC SE
IAC SB AUTHENTICATION IS
KERBEROS_V4 CLIENT|MUTUAL AUTH 4
7 1 67 82 65 89 46 67 7 9 77 0
48 24 49 244 109 240 50 208 43
35 25 116 104 44 167 21 201 224
229 145 20 2 244 213 220 33 134
148 4 251 249 233 229 152 77 2
109 130 231 33 146 190 248 1 9
31 95 94 15 120 224 0 225 76 205
70 136 245 190 199 147 155 13
IAC SE
[ The server responds with an ACCEPT command to state that the
authentication was successful. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V4 CLIENT|MUTUAL ACCEPT
IAC SE
[ Next, the client sends across a CHALLENGE to verify that it is
really talking to the right server. ]
IAC SB AUTHENTICATION IS
KERBEROS_V4 CLIENT|MUTUAL
CHALLENGE xx xx xx xx xx xx xx
xx IAC SE
[ Lastly, the server sends across a RESPONSE to prove that it
really is the right server.
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KERBEROS_V4 CLIENT|MUTUAL
KERBEROS_V4 CLIENT|ONE_WAY IAC
SE
[ The server has requested mutual Kerberos authentication, but is
willing to do just one-way Kerberos authentication. The client
will now respond with the name of the user that it wants to log
in as, and the Kerberos ticket. ]
IAC SB AUTHENTICATION NAME "joe"
IAC SE
IAC SB AUTHENTICATION IS
KERBEROS_V4 CLIENT|MUTUAL AUTH 4
7 1 67 82 65 89 46 67 7 9 77 0
48 24 49 244 109 240 50 208 43
35 25 116 104 44 167 21 201 224
229 145 20 2 244 213 220 33 134
148 4 251 249 233 229 152 77 2
109 130 231 33 146 190 248 1 9
31 95 94 15 120 224 0 225 76 205
70 136 245 190 199 147 155 13
IAC SE
[ The server responds with an ACCEPT command to state that the
authentication was successful. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V4 CLIENT|MUTUAL ACCEPT
IAC SE
[ Next, the client sends across a CHALLENGE to verify that it is
really talking to the right server. ]
IAC SB AUTHENTICATION IS
KERBEROS_V4 CLIENT|MUTUAL
CHALLENGE xx xx xx xx xx xx xx
xx IAC SE
[ Lastly, the server sends across a RESPONSE to prove that it
really is the right server.
IAC SB AUTHENTICATION REPLY KERBEROS_V4 CLIENT|MUTUAL RESPONSE yy yy yy yy yy yy yy yy IAC SE
IAC SB身份验证回复KERBEROS_V4客户端|相互响应yy yy yy yy yy yy yy IAC SE
The following is an example of use of the option with encryption negotiated via telnet ENCRYPT:
以下是通过telnet ENCRYPT协商使用加密选项的示例：
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
KERBEROS_V4 CLIENT|ONE_WAY IAC
SE
[ The server has requested mutual Kerberos authentication, but is
willing to do just one-way Kerberos authentication. In both
cases it is willing to encrypt the data stream. The client
will now respond with the name of the user that it wants to log
in as, and the Kerberos ticket. ]
IAC SB AUTHENTICATION NAME "joe"
IAC SE
IAC SB AUTHENTICATION IS
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
AUTH 4 7 1 67 82 65 89 46 67 7 9
77 0 48 24 49 244 109 240 50 208
43 35 25 116 104 44 167 21 201
224 229 145 20 2 244 213 220 33
134 148 4 251 249 233 229 152 77
2 109 130 231 33 146 190 248 1 9
31 95 94 15 120 224 0 225 76 205
70 136 245 190 199 147 155 13
IAC SE
[ The server responds with an ACCEPT command to state that the
authentication was successful. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
ACCEPT IAC SE
[ Next, the client sends across a CHALLENGE to verify that it is
really talking to the right server. ]
IAC SB AUTHENTICATION IS
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
KERBEROS_V4 CLIENT|ONE_WAY IAC
SE
[ The server has requested mutual Kerberos authentication, but is
willing to do just one-way Kerberos authentication. In both
cases it is willing to encrypt the data stream. The client
will now respond with the name of the user that it wants to log
in as, and the Kerberos ticket. ]
IAC SB AUTHENTICATION NAME "joe"
IAC SE
IAC SB AUTHENTICATION IS
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
AUTH 4 7 1 67 82 65 89 46 67 7 9
77 0 48 24 49 244 109 240 50 208
43 35 25 116 104 44 167 21 201
224 229 145 20 2 244 213 220 33
134 148 4 251 249 233 229 152 77
2 109 130 231 33 146 190 248 1 9
31 95 94 15 120 224 0 225 76 205
70 136 245 190 199 147 155 13
IAC SE
[ The server responds with an ACCEPT command to state that the
authentication was successful. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
ACCEPT IAC SE
[ Next, the client sends across a CHALLENGE to verify that it is
really talking to the right server. ]
IAC SB AUTHENTICATION IS
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
CHALLENGE xx xx xx xx xx xx xx xx IAC SE [ The server sends across a RESPONSE to prove that it really is the right server. ] IAC SB AUTHENTICATION REPLY KERBEROS_V4 CLIENT|MUTUAL|ENCRYPT_USING_TELOPT RESPONSE yy yy yy yy yy yy yy yy IAC SE [ At this point, the client and server begin to negotiate the telnet ENCRYPT option in each direction for a secure channel. If the option fails in either direction for any reason the connection must be immediately terminated. ]
挑战xx xx xx xx xx xx xx xx IAC SE[服务器发送响应以证明它确实是正确的服务器。]IAC SB身份验证回复KERBEROS_V4客户端|相互|使用_teloptresponse yy yy yy yy yy IAC SE加密|[此时，客户端和服务器开始在每个方向协商telnet ENCRYPT选项以获得安全通道。如果该选项因任何原因在任一方向失败，则必须立即终止连接。]
The following is an example of use of the option with integrated encryption:
以下是使用集成加密选项的示例：
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
IAC SE
[ The server has requested mutual KEA authentication with
SKIPJACK encryption. The client will now respond with the name
of the user that it wants to log in as and the KEA cert. ]
IAC SB AUTHENTICATION NAME "joe"
IAC SE IAC SB AUTHENTICATION IS
KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
'1' CertA||Ra IAC SE
[ The server responds with its KEA Cert. ]
IAC SB AUTHENTICATION REPLY
KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
'2'
CertB||Rb||IVb||Encrypt(NonceB)
IAC SE
[ Next, the client sends across a CHALLENGE to verify that it is
really talking to the right server. ]
IAC SB AUTHENTICATION IS KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
'3' IVa||Encrypt( NonceB xor
0x0C18 || NonceA ) IAC SE
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
IAC SE
[ The server has requested mutual KEA authentication with
SKIPJACK encryption. The client will now respond with the name
of the user that it wants to log in as and the KEA cert. ]
IAC SB AUTHENTICATION NAME "joe"
IAC SE IAC SB AUTHENTICATION IS
KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
'1' CertA||Ra IAC SE
[ The server responds with its KEA Cert. ]
IAC SB AUTHENTICATION REPLY
KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
'2'
CertB||Rb||IVb||Encrypt(NonceB)
IAC SE
[ Next, the client sends across a CHALLENGE to verify that it is
really talking to the right server. ]
IAC SB AUTHENTICATION IS KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
'3' IVa||Encrypt( NonceB xor
0x0C18 || NonceA ) IAC SE
[ At this point, the client begins to encrypt the outgoing data stream, and the server, after receiving this command, begins to decrypt the incoming data stream. Lastly, the server sends across a RESPONSE to prove that it really is the right server. ] IAC SB AUTHENTICATION REPLY KEA_SJ CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE '4' Encrypt( NonceA xor 0x0C18 ) IAC SE [ At this point, the server begins to encrypt its outgoing data stream, and the client, after receiving this command, begins to decrypt its incoming data stream. ]
[此时，客户端开始加密传出数据流，服务器在收到此命令后开始解密传入数据流。最后，服务器发送一个响应以证明它确实是正确的服务器。]IAC SB身份验证回复KEA|U SJ客户端|相互|在交换“4”加密后加密|（NonceA xor 0x0C18）IAC SE[此时，服务器开始加密其传出数据流，而客户端在收到此命令后，开始解密其传入数据流。]
It is expected that any implementation that supports the Telnet AUTHENTICATION option will support all of this specification.
任何支持Telnet身份验证选项的实现都将支持此规范的所有内容。
This memo describes a general framework for adding authentication and encryption to the telnet protocol. The actual authentication mechanism is described in the authentication suboption specifications, and the security of the authentication option is dependent on the strengths and weaknesses of the authentication suboption.
本备忘录描述了向telnet协议添加身份验证和加密的一般框架。认证子选项规范中描述了实际的认证机制，认证选项的安全性取决于认证子选项的优缺点。
It should be noted that the negotiation of the authentication type pair is not protected, thus allowing an attacker to force the result of the authentication to the weakest mutually acceptable method. (For example, even if both sides of the negotiation can accept a "strong" mechanism and a "40-bit" mechanism, an attacker could force selection of the "40-bit" mechanism.) An implementation should therefore only accept an authentication mechanism to be negotiated if it is willing to trust it as being secure.
应该注意的是，身份验证类型对的协商不受保护，因此允许攻击者将身份验证结果强制为双方都能接受的最弱方法。（例如，即使协商双方都可以接受“强”机制和“40位”机制，攻击者也可以强制选择“40位”机制。）因此，实现只有在愿意相信要协商的身份验证机制是安全的情况下才应该接受该机制。
It should also be noted that the negotiation of the username in the IAC SB AUTHENTICATION NAME name IAC SE message is not protected. Implementations should verify the value by a secure method before using this untrusted value.
还应注意，IAC SB身份验证名称IAC SE消息中的用户名协商不受保护。在使用此不受信任的值之前，实现应通过安全方法验证该值。
Many people have worked on this document over the span of many years. Dave Borman was a document editor and author of much of the original text. Other folks who have contributed ideas and suggestions to this text include: David Carrel, Jeff Schiller, and Richard Basch.
多年来，许多人都在编写这一文件。Dave Borman是一名文档编辑，也是大部分原始文本的作者。其他为本文提供想法和建议的人包括：大卫·卡雷尔、杰夫·席勒和理查德·巴斯克。
[1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[1] Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[2] Borman D., "Telnet Authentication Option", RFC 1416, February 1993.
[2] Borman D.，“Telnet认证选项”，RFC 1416，1993年2月。
[3] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, September 2000.
[3] 曹，T.，“Telnet数据加密选项”，RFC 29462000年9月。
[4] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] 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
Jeffrey Altman Columbia University Watson Hall Room 716 612 West 115th Street New York NY 10025
Jeffrey Altman哥伦比亚大学沃森大厅716 612室纽约州西115街10025
Phone: +1 (212) 854-1344
EMail: jaltman@columbia.edu
Phone: +1 (212) 854-1344
EMail: jaltman@columbia.edu
Mailing List: telnet-wg@BSDI.COM
邮寄名单：telnet-wg@BSDI.COM
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编辑功能的资金目前由互联网协会提供。