Network Working Group A. Medvinsky
Request for Comments: 2712 Excite
Category: Standards Track M. Hur
CyberSafe Corporation
October 1999
Network Working Group A. Medvinsky
Request for Comments: 2712 Excite
Category: Standards Track M. Hur
CyberSafe Corporation
October 1999
Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
向传输层安全性（TLS）中添加Kerberos密码套件
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
IESG Note:
IESG注：
The 40-bit ciphersuites defined in this memo are included only for the purpose of documenting the fact that those ciphersuite codes have already been assigned. 40-bit ciphersuites were designed to comply with US-centric, and now obsolete, export restrictions. They were never secure, and nowadays are inadequate even for casual applications. Implementation and use of the 40-bit ciphersuites defined in this document, and elsewhere, is strongly discouraged.
本备忘录中定义的40位密码套件仅用于记录已分配这些密码套件代码的事实。40位密码套件的设计符合以美国为中心、现已过时的出口限制。它们从来都不安全，现在甚至不适合临时应用。强烈反对实施和使用本文档和其他地方定义的40位密码套件。
This document proposes the addition of new cipher suites to the TLS protocol [1] to support Kerberos-based authentication. Kerberos credentials are used to achieve mutual authentication and to establish a master secret which is subsequently used to secure client-server communication.
本文档建议在TLS协议[1]中添加新的密码套件，以支持基于Kerberos的身份验证。Kerberos凭据用于实现相互身份验证和建立主密钥，该主密钥随后用于保护客户机-服务器通信。
Flexibility is one of the main strengths of the TLS protocol. Clients and servers can negotiate cipher suites to meet specific security and administrative policies. However, to date, authentication in TLS is limited only to public key solutions. As a result, TLS does not fully support organizations with heterogeneous security deployments that include authentication systems based on symmetric cryptography. Kerberos, originally developed at MIT, is
灵活性是TLS协议的主要优势之一。客户端和服务器可以协商密码套件以满足特定的安全和管理策略。然而，迄今为止，TLS中的身份验证仅限于公钥解决方案。因此，TLS不完全支持具有异构安全部署（包括基于对称加密的身份验证系统）的组织。Kerberos最初是在麻省理工学院开发的
based on an open standard [2] and is the most widely deployed symmetric key authentication system. This document proposes a new option for negotiating Kerberos authentication within the TLS framework. This achieves mutual authentication and the establishment of a master secret using Kerberos credentials. The proposed changes are minimal and, in fact, no different from adding a new public key algorithm to the TLS framework.
基于开放标准[2]，是部署最广泛的对称密钥认证系统。本文档提出了一个在TLS框架内协商Kerberos身份验证的新选项。这实现了相互身份验证和使用Kerberos凭据建立主密钥。建议的更改是最小的，事实上，与向TLS框架添加新的公钥算法没有什么不同。
This section describes the addition of the Kerberos authentication option to the TLS protocol. Throughout this document, we refer to the basic SSL handshake shown in Figure 1. For a review of the TLS handshake see [1].
本节介绍将Kerberos身份验证选项添加到TLS协议。在本文档中，我们参考了图1所示的基本SSL握手。有关TLS握手的回顾，请参见[1]。
CLIENT SERVER
------ ------
ClientHello
-------------------------------->
ServerHello
Certificate *
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
<-------------------------------
Certificate*
ClientKeyExchange
CertificateVerify*
change cipher spec
Finished
| -------------------------------->
| change cipher spec
| Finished
| |
| |
Application Data <------------------------------->Application Data
CLIENT SERVER
------ ------
ClientHello
-------------------------------->
ServerHello
Certificate *
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
<-------------------------------
Certificate*
ClientKeyExchange
CertificateVerify*
change cipher spec
Finished
| -------------------------------->
| change cipher spec
| Finished
| |
| |
Application Data <------------------------------->Application Data
FIGURE 1: The TLS protocol. All messages followed by a star are optional. Note: This figure was taken from an IETF document [1].
图1:TLS协议。所有带有星号的消息都是可选的。注：该图取自IETF文件[1]。
The TLS security context is negotiated in the client and server hello messages. For example: TLS_RSA_WITH_RC4_MD5 means the initial authentication will be done using the RSA public key algorithm, RC4 will be used for the session key, and MACs will be based on the MD5 algorithm. Thus, to facilitate the Kerberos authentication option, we must start by defining new cipher suites including (but not limited to):
TLS安全上下文在客户端和服务器hello消息中协商。例如：TLS_RSA_WITH_RC4_MD5意味着初始身份验证将使用RSA公钥算法完成，RC4将用于会话密钥，MAC将基于MD5算法。因此，为了简化Kerberos身份验证选项，我们必须首先定义新的密码套件，包括（但不限于）：
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B };
To establish a Kerberos-based security context, one or more of the above cipher suites must be specified in the client hello message. If the TLS server supports the Kerberos authentication option, the server hello message, sent to the client, will confirm the Kerberos cipher suite selected by the server. The server's certificate, the client
要建立基于Kerberos的安全上下文，必须在客户端hello消息中指定上述一个或多个密码套件。如果TLS服务器支持Kerberos身份验证选项，则发送到客户端的服务器hello消息将确认服务器选择的Kerberos密码套件。服务器的证书，客户端
CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be omitted since authentication and the establishment of a master secret will be done using the client's Kerberos credentials for the TLS server. The client's certificate will be omitted for the same reason. Note that these messages are specified as optional in the TLS protocol; therefore, omitting them is permissible.
图1所示的CertificateRequest和ServerKeyExchange将被省略，因为身份验证和主密钥的建立将使用TLS服务器的客户端Kerberos凭据完成。出于同样的原因，客户的证书将被省略。注意，这些消息在TLS协议中被指定为可选的；因此，省略它们是允许的。
The Kerberos option must be added to the ClientKeyExchange message as shown in Figure 2.
Kerberos选项必须添加到ClientKeyExchange消息中，如图2所示。
struct
{
select (KeyExchangeAlgorithm)
{
case krb5: KerberosWrapper; /* new addition */
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} Exchange_keys;
struct
{
select (KeyExchangeAlgorithm)
{
case krb5: KerberosWrapper; /* new addition */
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} Exchange_keys;
} ClientKeyExchange;
}客户密钥交换；
struct
{
opaque Ticket;
opaque authenticator; /* optional */
opaque EncryptedPreMasterSecret; /* encrypted with the session key
which is sealed in the ticket */
} KerberosWrapper; /* new addition */
struct
{
opaque Ticket;
opaque authenticator; /* optional */
opaque EncryptedPreMasterSecret; /* encrypted with the session key
which is sealed in the ticket */
} KerberosWrapper; /* new addition */
FIGURE 2: The Kerberos option in the ClientKeyExchange.
图2:ClientKeyExchange中的Kerberos选项。
To use the Kerberos authentication option, the TLS client must obtain a service ticket for the TLS server. In TLS, the ClientKeyExchange message is used to pass a random 48-byte pre-master secret to the server.
要使用Kerberos身份验证选项，TLS客户端必须获得TLS服务器的服务票证。在TLS中，ClientKeyExchange消息用于将随机的48字节预主密钥传递给服务器。
The client and server then use the pre-master secret to independently derive the master secret, which in turn is used for generating session keys and for MAC computations. Thus, if the Kerberos option is selected, the pre-master secret structure is the same as that used in the RSA case; it is encrypted under the Kerberos session key and sent to the TLS server along with the Kerberos credentials (see Figure 2). The ticket and authenticator are encoded per RFC 1510 (ASN.1 encoding). Once the ClientKeyExchange message is received, the server's secret key is used to unwrap the credentials and extract the pre-master secret.
然后，客户机和服务器使用预主密钥独立地派生主密钥，而主密钥又用于生成会话密钥和MAC计算。因此，如果选择Kerberos选项，则预主密钥结构与RSA情况中使用的相同；它在Kerberos会话密钥下加密，并与Kerberos凭据一起发送到TLS服务器（参见图2）。票据和验证器按照RFC 1510（ASN.1编码）进行编码。收到ClientKeyExchange消息后，服务器的密钥将用于打开凭据并提取预主密钥。
Note that a Kerberos authenticator is not required, since the master secret derived by the client and server is seeded with a random value passed in the server hello message, thus foiling replay attacks. However, the authenticator may still prove useful for passing authorization information and is thus allotted an optional field (see Figure 2).
请注意，不需要Kerberos验证器，因为客户机和服务器派生的主密钥使用服务器hello消息中传递的随机值作为种子，从而阻止重播攻击。然而，认证器在传递授权信息时仍然很有用，因此分配了一个可选字段（参见图2）。
Lastly, the client and server exchange the finished messages to complete the handshake. At this point we have achieved the following:
最后，客户端和服务器交换完成的消息以完成握手。在这一点上，我们取得了以下成就：
1) A master secret, used to protect all subsequent communication, is securely established.
1) 安全地建立用于保护所有后续通信的主密钥。
2) Mutual client-server authentication is achieved, since the TLS server proves knowledge of the master secret in the finished message.
2) 由于TLS服务器在完成的消息中证明了主密钥的知识，因此实现了相互客户机-服务器身份验证。
Note that the Kerberos option fits in seamlessly, without adding any new messages.
请注意，Kerberos选项可以无缝配合，而无需添加任何新消息。
4. Naming Conventions:
4. 命名约定：
To obtain an appropriate service ticket, the TLS client must determine the principal name of the TLS server. The Kerberos service naming convention is used for this purpose, as follows:
要获得适当的服务票证，TLS客户端必须确定TLS服务器的主体名称。Kerberos服务命名约定用于此目的，如下所示：
host/MachineName@Realm where: - The literal, "host", follows the Kerberos convention when not concerned about the protection domain on a particular machine. - "MachineName" is the particular instance of the service. - The Kerberos "Realm" is the domain name of the machine.
主人/MachineName@Realm其中：-当不关心特定计算机上的保护域时，“主机”字样遵循Kerberos约定。-“MachineName”是服务的特定实例。-Kerberos“领域”是计算机的域名。
The proposed Kerberos authentication option is added in exactly the same manner as a new public key algorithm would be added to TLS. Furthermore, it establishes the master secret in exactly the same manner.
建议的Kerberos身份验证选项的添加方式与新的公钥算法添加到TLS的方式完全相同。此外，它以完全相同的方式建立主秘密。
Kerberos ciphersuites are subject to the same security considerations as the TLS protocol. In addition, just as a public key implementation must take care to protect the private key (for example the PIN for a smartcard), a Kerberos implementation must take care to protect the long lived secret that is shared between the principal and the KDC. In particular, a weak password may be subject to a dictionary attack. In order to strengthen the initial authentication to a KDC, an implementor may choose to utilize secondary authentication via a token card, or one may utilize initial authentication to the KDC based on public key cryptography (commonly known as PKINIT - a product of the Common Authentication Technology working group of the IETF).
Kerberos密码套件受与TLS协议相同的安全考虑的约束。此外，正如公钥实现必须注意保护私钥（例如智能卡的PIN）一样，Kerberos实现也必须注意保护主体和KDC之间共享的长期秘密。特别是，弱密码可能会受到字典攻击。为了加强对KDC的初始认证，实施者可以选择通过令牌卡利用二次认证，或者可以利用基于公钥加密的对KDC的初始认证（通常称为PKINIT——IETF的公共认证技术工作组的产品）。
We would like to thank Clifford Neuman for his invaluable comments on earlier versions of this document.
我们要感谢Clifford Neuman对本文件早期版本的宝贵意见。
[1] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999.
[1] Dierks，T.和C.Allen，“TLS协议，版本1.0”，RFC 2246，1999年1月。
[2] Kohl J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[2] Kohl J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC 1510，1993年9月。
Ari Medvinsky Excite 555 Broadway Redwood City, CA 94063
加利福尼亚州百老汇红木城555号Ari Medvinsky Excite，邮编94063
Phone: +1 650 569 2119
EMail: amedvins@excitecorp.com
http://www.excite.com
Phone: +1 650 569 2119
EMail: amedvins@excitecorp.com
http://www.excite.com
Matthew Hur CyberSafe Corporation 1605 NW Sammamish Road Issaquah WA 98027-5378
Matthew Hur CyberSafe Corporation WA Issaquah Sammamish路西北1605号98027-5378
Phone: +1 425 391 6000
EMail: matt.hur@cybersafe.com
http://www.cybersafe.com
Phone: +1 425 391 6000
EMail: matt.hur@cybersafe.com
http://www.cybersafe.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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编辑功能的资金目前由互联网协会提供。