Internet Engineering Task Force (IETF) S. Josefsson
Request for Comments: 6251 SJD AB
Category: Informational May 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Josefsson
Request for Comments: 6251 SJD AB
Category: Informational May 2011
ISSN: 2070-1721
Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol
通过传输层安全（TLS）协议使用Kerberos版本5
Abstract
摘要
This document specifies how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol in order to provide additional security features.
本文档指定如何通过传输层安全性（TLS）协议传输Kerberos V5协议，以提供其他安全功能。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6251.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6251.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction and Background .....................................2
2. Kerberos V5 STARTTLS Extension ..................................3
3. Examples ........................................................4
4. STARTTLS-Aware KDC Discovery ....................................5
5. Server Certificates .............................................6
6. IANA Considerations .............................................7
7. Acknowledgements ................................................7
8. Security Considerations .........................................7
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................8
1. Introduction and Background .....................................2
2. Kerberos V5 STARTTLS Extension ..................................3
3. Examples ........................................................4
4. STARTTLS-Aware KDC Discovery ....................................5
5. Server Certificates .............................................6
6. IANA Considerations .............................................7
7. Acknowledgements ................................................7
8. Security Considerations .........................................7
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................8
This document describes how a Kerberos V5 [RFC4120] implementation may upgrade communication between clients and Key Distribution Centers (KDCs) to use the Transport Layer Security (TLS) [RFC5246] protocol.
本文档描述了Kerberos V5[RFC4120]实现如何升级客户端和密钥分发中心（KDC）之间的通信，以使用传输层安全性（TLS）[RFC5246]协议。
The TLS protocol offers integrity- and privacy-protected exchanges that can be authenticated using X.509 certificates, OpenPGP keys [RFC6091], and usernames and passwords via Secure Remote Password (SRP) [RFC5054].
TLS协议提供了完整性和隐私保护的交换，可以使用X.509证书、OpenPGP密钥[RFC6091]以及通过安全远程密码（SRP）[RFC5054]的用户名和密码进行身份验证。
There are several reasons to use Kerberos V5 over TLS.
在TLS上使用Kerberos V5有几个原因。
o It prevents downgrade attacks affecting, e.g., encryption types and pre-auth data negotiation. The encryption type field in KDC-REQ and the METHOD-DATA field with the requested pre-auth types from the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP are sent without integrity or privacy protection in Kerberos V5. This allows an active attacker to replace the encryption type with a compromised encryption type, e.g., 56-bit DES, or request that clients should use a broken pre-auth type.
o 它可以防止影响加密类型和预验证数据协商等的降级攻击。KDC-REQ中的encryption type字段和METHOD-DATA字段以及KDC-REP中服务器请求的预验证类型（KDC_ERR_PREAUTH_REQUIRED errors）在Kerberos V5中发送时没有完整性或隐私保护。这使得主动攻击者可以使用受损的加密类型（例如56位DES）替换加密类型，或者请求客户端使用损坏的预验证类型。
Since clients in general cannot know the encryption types other servers support, or the pre-auth types servers prefer or require, it is difficult for the client to detect if there was a man in the middle or if the remote server simply did not support a stronger encryption type or preferred another pre-auth type.
由于一般客户不能知道其他服务器支持的加密类型，或者预AuthType服务器喜欢或需要，所以客户端很难检测中间是否有人，或者远程服务器根本不支持更强的加密类型或优选另一个预AuthType。
o Kerberos exchanges are privacy protected. Parts of many Kerberos packets are transferred without privacy protection (i.e., encryption). That part contains information, such as the client principal name, the server principal name, the encryption types supported by the client, the lifetime of tickets, etc. Revealing such information is, in some threat models, considered a problem.
o Kerberos交换受隐私保护。许多Kerberos数据包的一部分是在没有隐私保护（即加密）的情况下传输的。该部分包含信息，例如客户端主体名称、服务器主体名称、客户端支持的加密类型、票据的生存期等。在某些威胁模型中，披露此类信息被视为一个问题。
o It provides additional authentication against the KDC. In some situations, users are equipped with smart cards with an RSA authentication key. In others, users have an OpenPGP client on their desktop, with a public OpenPGP key known to the server.
o 它提供了针对KDC的附加身份验证。在某些情况下，用户会配备带有RSA身份验证密钥的智能卡。在其他情况下，用户的桌面上有一个OpenPGP客户端，服务器知道一个公共OpenPGP密钥。
o It provides explicit server authentication of the KDC to the client. In traditional Kerberos V5, authentication of the KDC is proved as a side effect that the KDC knows your encryption key (i.e., your password).
o 它向客户端提供KDC的显式服务器身份验证。在传统的Kerberos V5中，KDC的身份验证被证明是KDC知道您的加密密钥（即密码）的副作用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The STARTTLS extension uses the Kerberos V5 TCP extension mechanism [RFC5021]. The extension uses bit 0 in the extension bitmask.
STARTTLS扩展使用Kerberos V5 TCP扩展机制[RFC5021]。扩展使用扩展位掩码中的位0。
The protocol is as follows. The client requests the extension by setting the STARTTLS bit in the TCP extension mechanism bitmask. (How to deal with extension negotiation failures at this point is described in [RFC5021].) After the server has sent the 4-octet value 0x00000000 to indicate support of this extension, the stream will be controlled by the TLS protocol and its framing. The TLS protocol is initiated by the client.
协议如下。客户端通过在TCP扩展机制位掩码中设置STARTTLS位来请求扩展。（此时如何处理扩展协商失败，请参见[RFC5021]）服务器发送4个八位字节的值0x00000000以表示支持此扩展后，流将由TLS协议及其帧控制。TLS协议由客户端启动。
Typically, the client initiates the TLS handshake protocol by sending a client hello, the server responds, and the handshake continues until it either succeeds or fails.
通常，客户机通过发送客户机hello来启动TLS握手协议，服务器响应，握手继续，直到成功或失败。
If, for any reason, the handshake fails, the STARTTLS protocol will also fail, and the TLS error is used as the error indication. In this case, no further messages can be exchanged over the same TCP session.
如果由于任何原因握手失败，STARTTLS协议也将失败，TLS错误将用作错误指示。在这种情况下，无法在同一TCP会话上交换更多消息。
If the handshake succeeds, the Kerberos V5 authentication protocol is performed within the protected TLS channel, like a normal TCP Kerberos V5 exchange. In particular, this means that every Kerberos V5 packet will be prefixed by a 4-octet length field that indicates the length of the Kerberos V5 packet.
如果握手成功，Kerberos V5身份验证协议将在受保护的TLS通道内执行，就像正常的TCP Kerberos V5交换一样。特别是，这意味着每个Kerberos V5数据包的前缀将是一个4位字节长度字段，该字段指示Kerberos V5数据包的长度。
When no further Kerberos V5 messages need to be transferred in the TLS session, the TLS session MUST be shut down properly using the close_notify alert. When the TLS session is shut down, the TCP connection cannot be re-used to send any further data and MUST be closed.
如果不需要在TLS会话中传输更多Kerberos V5消息，则必须使用close_notify警报正确关闭TLS会话。TLS会话关闭时，TCP连接不能重新用于发送任何进一步的数据，必须关闭。
A complete packet flow for a successful AS-REQ/REP exchange protected by this mechanism will be as follows. The "STARTTLS-bit" is a 4-octet value with only the bit allocated for this extension set, and | is the binary OR operation.
受此机制保护的成功AS-REQ/REP交换的完整数据包流如下所示。“STARTTLS位”是一个4位八位组值，仅为该扩展集分配位，|是二进制或运算。
Client Server
客户端服务器
[ Kerberos V5 TCP extension mechanism negotiation starts ]
[Kerberos V5 TCP扩展机制协商开始]
0x80000000 | STARTTLS-bit -------->
0x00000000
<--------
0x80000000 | STARTTLS-bit -------->
0x00000000
<--------
[ TLS negotiation starts ]
[TLS谈判开始]
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
[ Kerberos V5 negotiation starts ]
[Kerberos V5协商开始]
4-octet length field
Kerberos V5 AS-REQ -------->
4-octet length field
Kerberos V5 AS-REP
<--------
4-octet length field
Kerberos V5 AS-REQ -------->
4-octet length field
Kerberos V5 AS-REP
<--------
* Indicates optional or situation-dependent messages that are not always sent
* 指示并非始终发送的可选消息或情况相关消息
Section 7.2.3 of Kerberos V5 [RFC4120] describes how Domain Name System (DNS) SRV records [RFC2782] can be used to find the address of a KDC. We define a new Service of "kerberos-tls" to indicate that the particular KDC is intended to support this STARTTLS extension. The Proto (tcp), Realm, TTL, Class, SRV, Priority, Weight, Port, and Target have the same meaning as in RFC 4120.
Kerberos V5[RFC4120]的第7.2.3节描述了如何使用域名系统（DNS）SRV记录[RFC2782]查找KDC的地址。我们定义了一个新的“kerberos-tls”服务，以表明特定的KDC打算支持这个STARTTLS扩展。协议（tcp）、领域、TTL、类、SRV、优先级、权重、端口和目标与RFC4120中的含义相同。
For example:
例如：
_kerberos-tls._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos tls._tcp.EXAMPLE.COM。在SRV 0 88 kdc1.example.com中。
_kerberos-tls._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
_kerberos tls._tcp.EXAMPLE.COM。在SRV 1 0 88 kdc2.example.com中。
The TLS protocol may be used in a mode that provides server authentication using, for example, X.509 and OpenPGP.
TLS协议可在使用例如X.509和OpenPGP提供服务器认证的模式中使用。
A goal for the protocol described in this memo is that it should be as easy to implement and deploy on clients as support for UDP/TCP. Since many client environments do not have access to long-term storage, or to long-term storage that is sufficiently secure to enable validation of server certificates, the Kerberos V5 STARTTLS protocol does not require clients to verify server certificates. If server certification had been required, then environments with constrained clients such as those mentioned would be forced to disable TLS; this would arguably be worse than TLS without server certificate validation, as the use of TLS, even without server certificate validation, protects against some attacks that Kerberos V5 over UDP/TCP does not. For example, even without server certificate validation, TLS does protect against passive network sniffing aimed at tracking Kerberos service usage by a given client.
本备忘录中描述的协议的目标是，它应该像支持UDP/TCP一样易于在客户端实现和部署。由于许多客户机环境无法访问长期存储，或者无法访问足够安全的长期存储以启用服务器证书验证，因此Kerberos V5 STARTTLS协议不要求客户机验证服务器证书。如果需要服务器认证，则具有受限客户端的环境（如上述客户端）将被迫禁用TLS；这可能比没有服务器证书验证的TLS更糟糕，因为使用TLS，即使没有服务器证书验证，也可以抵御某些通过UDP/TCP的Kerberos V5无法抵御的攻击。例如，即使没有服务器证书验证，TLS也可以防止被动网络嗅探，目的是跟踪给定客户端的Kerberos服务使用情况。
However, note that the use of TLS without server certificate verification opens up a range of active attacks such as man in the middle.
然而，请注意，没有服务器证书验证的TLS的使用打开了一系列主动攻击，例如中间人。
When clients have the ability, they MUST validate the server certificate. For this reason, if a KDC presents an X.509 server certificate over TLS, it MUST contain an otherName Subject Alternative Name (SAN) identified using a type-id of id-krb5starttls-san. The intention is to bind the server certificate to the Kerberos realm for the purpose of using Kerberos V5 STARTTLS. The value field of the otherName should contain the realm as the "Realm" ASN.1 type.
当客户端具有此能力时，它们必须验证服务器证书。因此，如果KDC通过TLS提供X.509服务器证书，则它必须包含使用id-krb5starttls-SAN类型id标识的其他名称使用者替代名称（SAN）。目的是将服务器证书绑定到Kerberos领域，以便使用Kerberos V5 STARTTLS。otherName的值字段应包含作为“realm”ASN.1类型的领域。
id-krb5starttls-san OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) gnu(11591)
shishi(6) krb5starttls-san(1) }
id-krb5starttls-san OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) gnu(11591)
shishi(6) krb5starttls-san(1) }
To validate a server certificate, the client MAY use local configuration (e.g., a list that maps the Kerberos realm to a copy of the server's certificate) and compare that with the authentication information provided from the server via TLS. For illustration, the
为了验证服务器证书，客户端可以使用本地配置（例如，将Kerberos领域映射到服务器证书副本的列表），并将其与服务器通过TLS提供的身份验证信息进行比较。为了举例说明
server certificate could be an X.509 certificate or an OpenPGP key. In this mode, the client needs no processing related to id-krb5starttls-san.
服务器证书可以是X.509证书或OpenPGP密钥。在此模式下，客户端不需要与id-krb5starttls-san相关的处理。
When the server presents an X.509 server certificate, clients MAY use "Certification Path Validation" as described in [RFC5280] to validate the KDC server certificate. In addition, unless the client can otherwise verify that the server certificate is bound to the KDC of the target realm, the client MUST verify that the server certificate contains the id-krb5starttls-san SAN and that the value is identical to the intended Kerberos realm.
当服务器提供X.509服务器证书时，客户端可以使用[RFC5280]中所述的“证书路径验证”来验证KDC服务器证书。此外，除非客户端可以验证服务器证书是否绑定到目标领域的KDC，否则客户端必须验证服务器证书是否包含id-krb5starttls-san san，以及该值是否与预期的Kerberos领域相同。
Per [RFC5021], the IANA has allocated a bit (value 0) in the "Kerberos TCP Extensions" registry for Krb5 over TLS, the extension described in this document.
根据[RFC5021]，IANA在“Kerberos TCP Extensions”注册表中通过TLS为Krb5分配了一个位（值0），本文档中描述了该扩展。
Miguel A. Garcia, Sam Hartman, Jeffrey Hutzelman, Magnus Nystroem, and Peter Saint-Andre (in alphabetical order) provided comments that improved the protocol and document.
Miguel A.Garcia、Sam Hartman、Jeffrey Hutzelman、Magnus Nystroem和Peter Saint Andre（按字母顺序）提供了改进协议和文件的意见。
The security considerations in Kerberos V5, TLS, and the Kerberos V5 TCP extension mechanism are inherited.
Kerberos V5、TLS和Kerberos V5 TCP扩展机制中的安全注意事项是继承的。
Note that TLS does not protect against man-in-the-middle attacks unless clients verify the KDC's credentials (X.509 certificate, OpenPGP key, etc.) correctly. Although certificate validation adds an extra layer of protection, that is not considered strictly necessary to improve the security profile of Kerberos V5 as outlined in this document.
请注意，除非客户机正确验证KDC的凭据（X.509证书、OpenPGP密钥等），否则TLS不会防止中间人攻击。尽管证书验证增加了一个额外的保护层，但这对于改进kerberosv5的安全配置文件（如本文所述）并不是绝对必要的。
If server authentication is used, some information about the server (such as its name) is visible to passive attackers.
如果使用服务器身份验证，被动攻击者可以看到有关服务器的某些信息（例如其名称）。
To protect against the inherent downgrade attack in the extension framework, implementations SHOULD offer a policy mode that requires this extension to always be successfully negotiated, for a particular realm, or generally. For interoperability with implementations that do not support this extension, the policy mode SHOULD be disabled by default.
为了防止扩展框架中固有的降级攻击，实现应该提供一种策略模式，该模式要求始终为特定领域或一般领域成功协商此扩展。对于与不支持此扩展的实现的互操作性，默认情况下应禁用策略模式。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC5021] Josefsson, S., "Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP", RFC 5021, August 2007.
[RFC5021]Josefsson，S.，“通过TCP的扩展Kerberos版本5密钥分发中心（KDC）交换”，RFC 50212007年8月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, November 2007.
[RFC5054]Taylor，D.，Wu，T.，Mavrogiannopoulos，N.，和T.Perrin，“使用安全远程密码（SRP）协议进行TLS身份验证”，RFC 5054，2007年11月。
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, February 2011.
[RFC6091]Mavrogiannopoulos，N.和D.Gillmor，“使用OpenPGP密钥进行传输层安全（TLS）认证”，RFC 60912011年2月。
Author's Address
作者地址
Simon Josefsson Simon Josefsson Datakonsult AB Hagagatan 24 Stockholm 113 47 Sweden
Simon Josefsson Simon Josefsson Datakonsult AB Hagagatan 24斯德哥尔摩113 47瑞典
EMail: simon@josefsson.org
URI: http://josefsson.org/
EMail: simon@josefsson.org
URI: http://josefsson.org/