Network Working Group T. Ts'o
Request for Comments: 2942 VA Linux Systems
Category: Standards Track September 2000
Network Working Group T. Ts'o
Request for Comments: 2942 VA Linux Systems
Category: Standards Track September 2000
Telnet Authentication: Kerberos Version 5
Telnet身份验证：Kerberos版本5
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 how Kerberos Version 5 [1] is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option [2]. This mechanism can also used to provide keying material to provide data confidentiality services in conjunction with the telnet encryption option [3].
本文档描述如何将Kerberos版本5[1]与telnet协议一起使用。它描述了要与telnet身份验证选项一起使用的telnet身份验证子选项[2]。此机制还可用于提供密钥材料，以与telnet加密选项一起提供数据保密服务[3]。
Authentication Types
身份验证类型
KERBEROS_V5 2
KERBEROS_v52
Sub-option Commands
子选项命令
AUTH 0 REJECT 1 ACCEPT 2 RESPONSE 3 FORWARD 4 FORWARD_ACCEPT 5 FORWARD_REJECT 6
验证0拒绝1接受2响应3转发4转发接受5转发拒绝6
IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
KRB_AP_REQ message> IAC SE
IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
KRB_AP_REQ message> IAC SE
This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the remote side of the connection. The first octet of the <authentication-type-pair> value is KERBEROS_V5, to indicate that Version 5 of Kerberos is being used. The Kerberos V5 authenticator in the KRB_AP_REQ message must contain a Kerberos V5 checksum of the two-byte authentication type pair. This checksum must be verified by the server to assure that the authentication type pair was correctly negotiated. The Kerberos V5 authenticator must also include the optional subkey field, which shall be filled in with a randomly chosen key. This key shall be used for encryption purposes if encryption is negotiated, and shall be used as the negotiated session key (i.e., used as keyid 0) for the purposes of the telnet encryption option; if the subkey is not filled in, then the ticket session key will be used instead.
这用于将Kerberos V5[1]KRB_AP_REQ消息传递到连接的远程端。<authentication type pair>值的第一个八位组是KERBEROS\u V5，表示正在使用KERBEROS的版本5。KRB_AP_REQ消息中的Kerberos V5身份验证程序必须包含两字节身份验证类型对的Kerberos V5校验和。服务器必须验证此校验和，以确保正确协商了身份验证类型对。Kerberos V5身份验证程序还必须包括可选的子密钥字段，该字段应使用随机选择的密钥填充。如果协商加密，则该密钥应用于加密目的，并应作为协商会话密钥（即，用作keyid 0）用于telnet加密选项；如果未填写子密钥，则将使用票证会话密钥。
If data confidentiality services is desired the ENCRYPT_US-ING_TELOPT flag must be set in the authentication-type-pair as specified in [2].
如果需要数据机密性服务，则必须在[2]中指定的身份验证类型对中设置ENCRYPT_US-ING_TELOPT标志。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
IAC SB认证回复<认证类型对>接受IAC SE
This command indicates that the authentication was successful.
此命令表示身份验证成功。
If the AUTH_HOW_MUTUAL bit is set in the second octet of the authentication-type-pair, the RESPONSE command must be sent before the ACCEPT command is sent.
如果在身份验证类型对的第二个八位字节中设置了AUTH_HOW_MUTUAL bit，则必须在发送ACCEPT命令之前发送RESPONSE命令。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
<optional reason for rejection> IAC SE
IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
<optional reason for rejection> IAC SE
This command indicates that the authentication was not successful, and if there is any more data in the sub-option, it is an ASCII text message of the reason for the rejection.
此命令表示身份验证未成功，如果子选项中还有更多数据，则它是一条ASCII文本消息，说明拒绝的原因。
IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
<KRB_AP_REP message> IAC SE
IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
<KRB_AP_REP message> IAC SE
This command is used to perform mutual authentication. It is only used when the AUTH_HOW_MUTUAL bit is set in the second octet of the authentication-type-pair. After an AUTH command is verified, a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP message to perform the mutual authentication.
此命令用于执行相互身份验证。仅当在身份验证类型对的第二个八位字节中设置了AUTH_HOW_MUTUAL bit时才使用。验证AUTH命令后，将发送一个包含Kerberos V5 KRB_AP_REP消息的响应命令，以执行相互身份验证。
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
message> IAC SE
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
message> IAC SE
This command is used to forward kerberos credentials for use by the remote session. The credentials are passed as a Kerberos V5 KRB_CRED message which includes, among other things, the forwarded Kerberos ticket and a session key associated with the ticket. Part of the KRB_CRED message is encrypted in the key previously exchanged for the telnet session by the AUTH suboption.
此命令用于转发kerberos凭据以供远程会话使用。凭据作为Kerberos V5 KRB_CRED消息传递，其中包括转发的Kerberos票证和与票证关联的会话密钥。KRB_CRED消息的一部分在之前由AUTH子选项为telnet会话交换的密钥中加密。
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC SE
IAC SB身份验证<身份验证类型对>转发\u接受IAC SE
This command indicates that the credential forwarding was successful.
此命令表示凭证转发成功。
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT
<optional reason for rejection> IAC SE
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT
<optional reason for rejection> IAC SE
This command indicates that the credential forwarding was not successful, and if there is any more data in the suboption, it is an ASCII text message of the reason for the rejection.
此命令表示凭证转发未成功，如果子选项中还有更多数据，则它是一条说明拒绝原因的ASCII文本消息。
If the second octet of the authentication-type-pair has the AUTH_WHO bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial AUTH command, and the server responds with either ACCEPT or REJECT. In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the server will send a RESPONSE before it sends the ACCEPT.
如果身份验证类型对的第二个八位字节的AUTH_WHO位设置为AUTH_CLIENT_to_SERVER，则客户端发送初始AUTH命令，服务器响应为ACCEPT或REJECT。此外，如果AUTH_HOW位设置为AUTH_HOW_MUTUAL，则服务器将在发送接受之前发送响应。
If the second octet of the authentication-type-pair has the AUTH_WHO bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial AUTH command, and the client responds with either ACCEPT or REJECT. In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the client will send a RESPONSE before it sends the ACCEPT.
如果身份验证类型对的第二个八位字节将AUTH_WHO位设置为AUTH_SERVER_to_CLIENT，则服务器发送初始AUTH命令，客户端响应为ACCEPT或REJECT。此外，如果AUTH_HOW位设置为AUTH_HOW_MUTUAL，则客户端将在发送接受之前发送响应。
The Kerberos principal used by the server will generally be of the form "host/<hostname>@realm". That is, the first component of the Kerberos principal is "host"; the second component is the fully qualified lower-case hostname of the server; and the realm is the Kerberos realm to which the server belongs.
服务器使用的Kerberos主体通常采用“host/<hostname>@realm”的形式。也就是说，Kerberos主体的第一个组件是“主机”；第二个组件是服务器的完全限定小写主机名；领域是服务器所属的Kerberos领域。
Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP messages, the KRB_CRED structure, or the optional rejection text string must be doubled as specified in [4]. Otherwise the following byte might be mis-interpreted as a Telnet command.
KRB_AP_REQ或KRB_AP_REP消息、KRB_CRED结构或可选拒绝文本字符串中出现的任何Telnet IAC字符必须按照[4]中的规定加倍。否则，以下字节可能被错误解释为Telnet命令。
User "joe" may wish to log in as user "pete" on machine "foo". If "pete" has set things up on "foo" to allow "joe" access to his account, then the client would send IAC SB AUTHENTICATION NAME "pete" IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE> IAC SE
用户“joe”可能希望以用户“pete”的身份登录计算机“foo”。如果“pete”在“foo”上设置了允许“joe”访问其帐户的内容，则客户端将发送IAC SB身份验证名称“pete”IAC SE IAC SB身份验证为KERBEROS_V5身份验证<KRB_AP_REQ_MESSAGE>IAC SE
The server would then authenticate the user as "joe" from the KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by Kerberos, and if "pete" has allowed "joe" to use his account, the server would then continue the authentication sequence by sending a RESPONSE (to do mutual authentication, if it was requested) followed by the ACCEPT.
然后，服务器将从KRB_AP_REQ_消息中将用户身份验证为“joe”，如果Kerberos接受了KRB_AP_REQ_消息，并且如果“pete”允许“joe”使用他的帐户，那么服务器将通过发送响应（如果请求，则执行相互身份验证）然后发送接受来继续验证序列。
If forwarding has been requested, the client then sends IAC SB AUTHENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure with credentials to be forwarded> IAC SE. If the server succeeds in reading the forwarded credentials, the server sends FORWARD_ACCEPT else, a FORWARD_REJECT is sent back.
如果已请求转发，则客户端随后发送IAC SB身份验证为KERBEROS_V5客户端|相互转发<KRB_CRED structure with credentials to FORWARD>IAC SE。如果服务器成功读取转发的凭据，服务器将发送FORWARD_ACCEPT else，并返回FORWARD_REJECT。
Client Server IAC DO AUTHENTICATION IAC WILL AUTHENTICATION
客户端服务器IAC执行身份验证IAC将执行身份验证
[ The server is now free to request authentication information. ]
[服务器现在可以自由请求身份验证信息。]
IAC SB AUTHENTICATION SEND KERBEROS_V5 CLIENT|MUTUAL KERBEROS_V5 CLIENT|ONE_WAY IAC SE
IAC SB身份验证发送KERBEROS_V5客户端|相互KERBEROS_V5客户端|单向IAC SE
[ The server has requested mutual Version 5 Kerberos authentication. If mutual authentication is not supported, then the server is willing to do one-way authentication.
[服务器已请求相互版本5 Kerberos身份验证。如果不支持相互身份验证，则服务器愿意执行单向身份验证。
The client will now respond with the name of the user that it wants to log in as, and the Kerberos ticket. ]
客户机现在将使用它想要登录的用户的名称和Kerberos票证进行响应。]
IAC SB AUTHENTICATION NAME "pete" IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 CLIENT|MUTUAL AUTH <KRB_AP_REQ message> IAC SE
IAC SB身份验证名称“pete”IAC SE IAC SB身份验证是KERBEROS_V5客户端|相互身份验证<KRB_AP_REQ message>IAC SE
[ Since mutual authentication is desired, the server sends across a RESPONSE to prove that it really is the right server. ]
[由于需要相互身份验证，服务器会发送一个响应来证明它确实是正确的服务器。]
IAC SB AUTHENTICATION REPLY KERBEROS_V5 CLIENT|MUTUAL RESPONSE <KRB_AP_REP message> IAC SE
IAC SB身份验证回复KERBEROS_V5客户端|相互响应<KRB_AP_REP message>IAC SE
[ The server responds with an ACCEPT command to state that the authentication was successful. ]
[服务器响应一个ACCEPT命令，表示身份验证成功。]
IAC SB AUTHENTICATION REPLY KERBEROS_V5 CLIENT|MUTUAL ACCEPT IAC SE
IAC SB身份验证回复KERBEROS_V5客户端|相互接受IAC SE
[ If so requested, the client now sends the FORWARD command to forward credentials to the remote site. ]
[如果请求，客户端现在会发送转发命令，将凭据转发到远程站点。]
IAC SB AUTHENTICATION IS KER-BEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED message> IAC SE
IAC SB身份验证是KER-BEROS_V5客户端|相互转发<KRB_CRED message>IAC SE
[ The server responds with a FORWARD_ACCEPT command to state that the credential forwarding was successful. ]
[服务器响应FORWARD_ACCEPT命令，表示凭证转发成功。]
IAC SB AUTHENTICATION REPLY KERBEROS_V5 CLIENT|MUTUAL FORWARD_ACCEPT IAC SE
IAC SB身份验证回复KERBEROS_V5客户端|相互转发_接受IAC SE
The selection of the random session key in the Kerberos V5 authenticator is critical, since this key will be used for encrypting the telnet data stream if encryption is enabled. It is strongly advised that the random key selection be done using cryptographic techniques that involve the Kerberos ticket's session key. For example, using the current time, encrypting it with the ticket session key, and then correcting for key parity is a strong way to generate a subsession key, since the ticket session key is assumed to be never disclosed to an attacker.
Kerberos V5身份验证程序中随机会话密钥的选择至关重要，因为如果启用了加密，此密钥将用于加密telnet数据流。强烈建议使用涉及Kerberos票证会话密钥的加密技术进行随机密钥选择。例如，使用当前时间，使用票证会话密钥对其进行加密，然后更正密钥奇偶校验是生成子会话密钥的一种有效方法，因为假定票证会话密钥从未向攻击者公开。
Care should be taken before forwarding a user's Kerberos credentials to the remote server. If the remote server is not trustworthy, this could result in the user's credentials being compromised. Hence, the user interface should not forward credentials by default; it would be far safer to either require the user to explicitly request credentials forwarding for each connection, or to have a trusted list of hosts for which credentials forwarding is enabled, but to not enable credentials forwarding by default for all machines.
在将用户的Kerberos凭据转发到远程服务器之前，应小心。如果远程服务器不可信，这可能会导致用户的凭据受损。因此，默认情况下，用户界面不应转发凭据；要求用户为每个连接显式地请求凭据转发，或者为其启用凭据转发的主机提供一个受信任的列表，但在默认情况下不为所有计算机启用凭据转发，这样会安全得多。
The IAC SB AUTHENTICATION NAME name IAC SE message is unprotected in this protocol. Its contents should be verified by a secure method after authentication completes before it is used.
IAC SB身份验证名称IAC SE消息在此协议中不受保护。它的内容应该在身份验证完成后通过安全方法进行验证，然后才能使用。
The authentication type KERBEROS_V5 and its associated suboption values are registered with IANA. Any suboption values used to extend the protocol as described in this document must be registered with IANA before use. IANA is instructed not to issue new suboption values without submission of documentation of their use.
身份验证类型KERBEROS_V5及其关联的子选项值已向IANA注册。如本文档所述，用于扩展协议的任何子选项值必须在使用前向IANA注册。IANA被指示在未提交使用文件的情况下不得发布新的子选项值。
This document was originally written by Dave Borman of Cray Research, Inc. Theodore Ts'o of MIT revised it to reflect the latest implementation experience. Cliff Neuman and Prasad Upasani of USC's Information Sciences Institute developed the credential forwarding support.
本文档最初由Cray Research，Inc.的Dave Borman编写。麻省理工学院的Theodore Ts'o对其进行了修订，以反映最新的实施经验。南加州大学信息科学研究所的Cliff Neuman和Prasad Upasani开发了凭证转发支持。
In addition, the contributions of the Telnet Working Group are also gratefully acknowledged.
此外，还感谢Telnet工作组的贡献。
[1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication System (V5)", RFC 1510, September 1993.
[1] Kohl，J.和B.Neuman，“Kerberos网络身份验证系统（V5）”，RFC 1510，1993年9月。
[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] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, September 2000.
[3] 曹，T.，“Telnet数据加密选项”，RFC 29462000年9月。
[4] Postel, J. and J. Reynolds, "Telnet Option Specifications", STD 8, RFC 855, May 1983.
[4] Postel，J.和J.Reynolds，“Telnet选项规范”，标准8，RFC 855，1983年5月。
Theodore Ts'o VA Linux Systems 43 Pleasant St. Medford, MA 02155
Theodore T'o 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编辑功能的资金目前由互联网协会提供。