Network Working Group S. Josefsson
Request for Comments: 5021 SJD
Updates: 4120 August 2007
Category: Standards Track
Network Working Group S. Josefsson
Request for Comments: 5021 SJD
Updates: 4120 August 2007
Category: Standards Track
Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP
通过TCP的扩展Kerberos版本5密钥分发中心（KDC）交换
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiate TCP-specific Kerberos extensions.
本文档描述了通过TCP传输使用Kerberos V5协议时的可扩展性机制。该机制使用长度字段中的保留高位。它可用于协商特定于TCP的Kerberos扩展。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. Extension Mechanism for TCP Transport . . . . . . . . . . . . . 2
4. Interoperability Consideration . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Copying Conditions . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. Extension Mechanism for TCP Transport . . . . . . . . . . . . . 2
4. Interoperability Consideration . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Copying Conditions . . . . . . . . . . . . . . . . . . 6
The Kerberos V5 [3] specification, in section 7.2.2, reserves the high order bit in the initial length field for TCP transport for future expansion. This document updates [3] to describe the behaviour when that bit is set. This mechanism is intended for extensions that are specific for the TCP transport.
第7.2.2节中的Kerberos V5[3]规范在初始长度字段中为TCP传输保留高阶位，以备将来扩展。本文档更新[3]以描述设置该位时的行为。此机制用于特定于TCP传输的扩展。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The reserved high bit of the request length field is used to signal the use of this extension mechanism. When the reserved high bit is set in the length field, the remaining 31 bits of the initial 4 octets are interpreted as a bitmap. Each bit in the bitmask can be used to request a particular extension. The 31 bits form the "extension bitmask". It is expected that other documents will describe the details associated with particular bits.
请求长度字段的保留高位用于发出使用此扩展机制的信号。在长度字段中设置保留高位时，初始4个八位字节的其余31位将被解释为位图。位掩码中的每一位都可用于请求特定的扩展。31位构成“扩展位掩码”。预计其他文件将描述与特定比特相关的细节。
A 4-octet value with only the high bit set, and thus the extension bitmask all zeros, is called a PROBE. A client may send a probe to find out which extensions a KDC supports. A client may also set particular bits in the extension bitmask directly, if it does not need to query the KDC for available extensions before deciding which extension to request.
只有高位设置的4位八位组值，因此扩展位掩码全部为零，称为探测。客户端可能会发送一个探测，以找出KDC支持哪些扩展。如果客户机在决定请求哪个扩展之前不需要查询KDC以获得可用的扩展，那么它也可以直接在扩展位掩码中设置特定的位。
Note that clients are not forced to use this extension mechanism, and further, clients are expected to only use it when they wish to negotiate a particular extension.
请注意，不会强制客户机使用此扩展机制，而且，客户机只希望在协商特定扩展时使用它。
The protocol is as follows. The client MUST begin by sending a 4-octet value with the high bit set. The packet is thus either a PROBE or a specific request for some extension(s). The client MUST NOT send additional data before the server has responded.
协议如下。客户端必须首先发送一个具有高位设置的4位八位组值。因此，数据包要么是探测，要么是对某些扩展的特定请求。在服务器响应之前，客户端不得发送其他数据。
If a KDC receives a request for a set of extensions that it supports, it MUST respond by sending a 4-octet zero value, i.e., 0x00000000. The KDC MAY directly send additional data after the zero value, without waiting for the client to respond, as specified by the particular negotiated extension. (Note: A 4-octet zero value can never be sent by an implementation that conforms to RFC 4120 and that does not support this extension mechanism, because a KRB-ERROR is always of non-zero size.)
如果KDC接收到对其支持的一组扩展的请求，它必须通过发送4个八位组的零值来响应，即0x00000000。KDC可以在零值之后直接发送附加数据，而无需等待客户机响应，如特定协商扩展指定的那样。（注意：符合RFC 4120且不支持此扩展机制的实现永远不能发送4个八位组的零值，因为KRB错误的大小始终为非零。）
If a KDC receives a PROBE, or if a KDC does not support all extensions corresponding to set bits in the extension bitmask, the KDC MUST return 4 octets with the high bit set, and with the remaining bitmask indicating which extensions it supports. The KDC then MUST wait, and the client MUST send a second 4-octet value with the high bit set. If the second 4-octet value is a PROBE or an unsupported extension, the KDC MUST close the connection. This can be used by the client to shut down a session when the KDC did not support an extension that is required by the client. If the second 4-octet value is a supported extension, the KDC MUST respond by sending a 4-octet zero value, i.e., 0x00000000. The KDC MAY directly send additional data after the zero value, as specified by the particular negotiated extension.
如果KDC接收到探测，或者KDC不支持与扩展位掩码中的设置位对应的所有扩展，则KDC必须返回4个八位字节，其中高位集和剩余的位掩码指示它支持哪些扩展。然后KDC必须等待，客户机必须发送第二个4-octet值和高位集。如果第二个4-octet值是探测或不受支持的扩展，KDC必须关闭连接。当KDC不支持客户机所需的扩展时，客户机可以使用它来关闭会话。如果第二个4-octet值是受支持的扩展，KDC必须通过发送一个4-octet零值（即0x00000000）进行响应。KDC可以在零值之后直接发送额外的数据，如特定协商扩展指定的那样。
The client and KDC SHOULD wait for the other side to respond according to this protocol, and the client and KDC SHOULD NOT close the connection prematurely. Resource availability considerations may influence whether, and for how long, the client and KDC will wait for the other side to respond to a request.
客户端和KDC应该等待另一方根据此协议做出响应，并且客户端和KDC不应该过早地关闭连接。资源可用性考虑因素可能会影响客户端和KDC是否以及等待对方响应请求的时间。
The KDC MUST NOT support the extension mechanism if it does not support any extensions. If no extensions are supported, the KDC MUST return a KRB-ERROR message with the error KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream, similar to what an implementation that does not understand this extension mechanism would do.
如果KDC不支持任何扩展，它就不能支持扩展机制。如果不支持扩展，KDC必须返回带有错误KRB_ERR_FIELD_TOOLONG的KRB-ERROR消息，并且必须关闭TCP流，这与不理解此扩展机制的实现所做的类似。
The behaviour when more than one non-high bit is set depends on the particular extension mechanisms. If a requested extension (bit X) does not specify how it interacts with another requested extension (bit Y), the KDC MUST treat the request as a PROBE or unsupported extension, and proceed as above.
设置多个非高位时的行为取决于特定的扩展机制。如果请求的扩展（位X）没有指定它如何与另一个请求的扩展（位Y）交互，KDC必须将该请求视为探测或不受支持的扩展，并如上所述进行处理。
Each extension MUST describe the structure of protocol data beyond the length field, and the behaviour of the client and KDC. In particular, the structure may be a protocol with its own message framing. If an extension mechanism reserves multiple bits, it MUST describe how they interact.
每个扩展必须描述长度字段之外的协议数据结构，以及客户端和KDC的行为。具体而言，该结构可以是具有其自己的消息帧的协议。如果扩展机制保留多个位，则必须描述它们如何交互。
Implementations with support for TCP that do not claim to conform to RFC 4120 may not handle the high bit correctly. The KDC behaviour may include closing the TCP connection without any response, and logging an error message in the KDC log. When this was written, this problem existed in modern versions of popular KDC implementations. Implementations experiencing trouble getting the expected responses from a KDC might assume that the KDC does not support this extension mechanism. A client might remember this semi-permanently, to avoid
支持TCP但未声明符合RFC 4120的实现可能无法正确处理高位。KDC行为可能包括在没有任何响应的情况下关闭TCP连接，以及在KDC日志中记录错误消息。写这篇文章时，这个问题存在于流行KDC实现的现代版本中。从KDC获取预期响应时遇到问题的实现可能会假定KDC不支持此扩展机制。客户可能会半永久地记住这一点，以避免
triggering the same problematic behaviour on the KDC every time. Care should be taken to avoid unexpected behaviour for the user when the KDC is eventually upgraded. Implementations might also provide a way to enable and disable this extension on a per-realm basis. How to handle these backwards compatibility quirks are in general left unspecified.
每次在KDC上触发相同的问题行为。当KDC最终升级时，应注意避免用户出现意外行为。实现还可以提供一种在每个领域基础上启用和禁用此扩展的方法。如何处理这些向后兼容性的怪癖通常没有明确说明。
Because the initial length field is not protected, it is possible for an active attacker (i.e., one that is able to modify traffic between the client and the KDC) to make it appear to the client that the server does not support this extension mechanism (a downgrade attack). Further, active attackers can also interfere with the negotiation of which extensions are supported, which may also result in a downgrade attack. This problem can be solved by having a policy in the clients and in the KDC to reject connections that do not have the desired properties. The problem can also be mitigated by having the negotiated extension send a cryptographic checksum of the offered extensions.
由于初始长度字段不受保护，因此活动攻击者（即能够修改客户端和KDC之间通信量的攻击者）可能会使客户端觉得服务器不支持此扩展机制（降级攻击）。此外，主动攻击者还可以干扰支持哪些扩展的协商，这也可能导致降级攻击。这个问题可以通过在客户端和KDC中使用拒绝不具有所需属性的连接的策略来解决。通过让协商扩展发送所提供扩展的加密校验和，也可以缓解该问题。
IANA has created a new registry for "Kerberos TCP Extensions". The initial contents of this registry are:
IANA已经为“Kerberos TCP扩展”创建了一个新的注册表。此注册表的初始内容包括：
Bit # Reference
----- ---------
0..29 AVAILABLE for registration.
30 RESERVED. RFC 5021
Bit # Reference
----- ---------
0..29 AVAILABLE for registration.
30 RESERVED. RFC 5021
IANA will register values 0 to 29 after IESG Approval, as defined in BCP 64 [2]. Assigning value 30 requires a Standards Action that updates or obsoletes this document.
IANA将根据BCP 64[2]中的定义，在IESG批准后注册值0至29。分配值30需要更新或废弃此文档的标准操作。
Registration policy: The IESG will act as a steward for the namespace, considering whether the registration is justified given the limited size of the namespace. The IESG will also confirm that proposed registrations are not harmful to the Internet.
注册策略：IESG将充当名称空间的管理员，考虑在名称空间大小有限的情况下注册是否合理。IESG还将确认提议的注册不会对互联网造成危害。
Nicolas Williams, Jeffrey Hutzelman, Sam Hartman, and Chris Newman provided comments that improved the protocol and document.
Nicolas Williams、Jeffrey Hutzelman、Sam Hartman和Chris Newman提供了改进方案和文件的意见。
Thanks to Andrew Bartlett who pointed out that some implementations (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with regards to the high bit, which resulted in an Interoperability Consideration.
感谢Andrew Bartlett，他指出一些实现（MIT Kerberos和Heimdal）在高位方面没有正确遵循RFC 4120，这导致了互操作性的考虑。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[3] Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
Regarding this entire document or any portion of it, the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.
对于本文件的全部或任何部分，作者不作任何保证，也不对因使用本文件而造成的任何损坏负责。作者向任何人授予不可撤销的使用、修改和分发许可，允许其以任何方式使用、修改和分发，但不得削弱任何其他人使用、修改和分发的权利，前提是重新分发的衍生作品不包含误导性的作者或版本信息。衍生作品无需根据类似条款获得许可。
Author's Address
作者地址
Simon Josefsson SJD
西蒙·约瑟夫森SJD
EMail: simon@josefsson.org
EMail: simon@josefsson.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.translate error, please retry
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。