Internet Engineering Task Force (IETF) B. Kaduk
Request for Comments: 8429 Akamai
BCP: 218 M. Short
Updates: 3961, 4120 Microsoft Corporation
Category: Best Current Practice October 2018
ISSN: 2070-1721
Internet Engineering Task Force (IETF) B. Kaduk
Request for Comments: 8429 Akamai
BCP: 218 M. Short
Updates: 3961, 4120 Microsoft Corporation
Category: Best Current Practice October 2018
ISSN: 2070-1721
Deprecate Triple-DES (3DES) and RC4 in Kerberos
反对Kerberos中的三重DES（3DES）和RC4
Abstract
摘要
The triple-DES (3DES) and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos. Accordingly, RFC 4757 has been moved to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types.
三重DES（3DES）和RC4加密类型的加密强度正在稳步减弱，在Kerberos中使用它们应该开始弃用过程。因此，RFC 4757已移至历史状态，因为它指定的任何加密类型都不应使用，并且RFC 3961已更新，以注意三重DES加密类型的弃用。RFC 4120也同样进行了更新，删除了实现三重DES加密和校验和类型的建议。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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). Further information on BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8429.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8429.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Affected Specifications . . . . . . . . . . . . . . . . . . . 3
4. Affected Encryption Types . . . . . . . . . . . . . . . . . . 4
5. RC4 Weakness . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Statistical Biases . . . . . . . . . . . . . . . . . . . 4
5.2. Password Hash . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Cross-Protocol Key Reuse . . . . . . . . . . . . . . . . 5
5.4. Interoperability Concerns . . . . . . . . . . . . . . . . 6
6. Triple-DES Weakness . . . . . . . . . . . . . . . . . . . . . 6
6.1. Password-Based Keys . . . . . . . . . . . . . . . . . . . 7
6.2. Block Size . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Interoperability Concerns . . . . . . . . . . . . . . . . 7
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Affected Specifications . . . . . . . . . . . . . . . . . . . 3
4. Affected Encryption Types . . . . . . . . . . . . . . . . . . 4
5. RC4 Weakness . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Statistical Biases . . . . . . . . . . . . . . . . . . . 4
5.2. Password Hash . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Cross-Protocol Key Reuse . . . . . . . . . . . . . . . . 5
5.4. Interoperability Concerns . . . . . . . . . . . . . . . . 6
6. Triple-DES Weakness . . . . . . . . . . . . . . . . . . . . . 6
6.1. Password-Based Keys . . . . . . . . . . . . . . . . . . . 7
6.2. Block Size . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Interoperability Concerns . . . . . . . . . . . . . . . . 7
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
The triple-DES (3DES) and RC4 encryption types (enctypes) are steadily weakening in cryptographic strength, and the deprecation process should begin for their use in Kerberos. Accordingly, RFC 4757 has been moved to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 has been updated to note the deprecation of the triple-DES encryption types. RFC 4120 is likewise updated to remove the recommendation to implement triple-DES encryption and checksum types.
三重DES（3DES）和RC4加密类型（enctypes）的加密强度正在稳步减弱，应该开始在Kerberos中使用它们的弃用过程。因此，RFC 4757已移至历史状态，因为它指定的任何加密类型都不应使用，并且RFC 3961已更新，以注意三重DES加密类型的弃用。RFC 4120也同样进行了更新，删除了实现三重DES加密和校验和类型的建议。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The RC4 Kerberos encryption types (including rc4-hmac) are specified in [RFC4757], which has been moved to Historic status.
[RFC4757]中指定了RC4 Kerberos加密类型（包括RC4 hmac），该类型已移至历史状态。
The des3-cbc-sha1-kd encryption type is specified in [RFC3961]. Additional triple-DES encryption type codepoints are in use and in the IANA registry with no formal specification, in particular des3-cbc-md5 and des3-cbc-sha1. These unspecified encryption types are also deprecated by this document.
[RFC3961]中指定了des3-cbc-sha1-kd加密类型。其他三重DES加密类型代码点正在使用中，且在IANA注册表中没有正式规范，特别是des3-cbc-md5和des3-cbc-sha1。本文档也不推荐使用这些未指定的加密类型。
The Kerberos specification ([RFC4120]) includes recommendations for which encryption and checksum types to implement; the deprecated encryption and checksum types are now disrecommended to implement.
Kerberos规范（[RFC4120]）包括要实现哪些加密和校验和类型的建议；不推荐使用的加密和校验和类型现在不建议实现。
Though the RC4 and triple-DES encryption types are still in use in some deployments, the above status changes are made to discourage their use.
尽管RC4和triple-DES加密类型仍在某些部署中使用，但上面的状态更改旨在阻止它们的使用。
The following encryption types are deprecated. The numbers are the official identifiers; the names are only for convenience.
不推荐使用以下加密类型。这些数字是官方标识；这些名字只是为了方便。
+----------------+--------------------------+
| enctype number | enctype convenience name |
+----------------+--------------------------+
| 5 | des3-cbc-md5 |
| | |
| 7 | des3-cbc-sha1 |
| | |
| 16 | des3-cbc-sha1-kd |
| | |
| 23 | rc4-hmac |
+----------------+--------------------------+
+----------------+--------------------------+
| enctype number | enctype convenience name |
+----------------+--------------------------+
| 5 | des3-cbc-md5 |
| | |
| 7 | des3-cbc-sha1 |
| | |
| 16 | des3-cbc-sha1-kd |
| | |
| 23 | rc4-hmac |
+----------------+--------------------------+
RC4's weakness as a TLS cipher due to statistical biases in the keystream has been well publicized [RFC7465], and these statistical biases cause concern for any consumer of the RC4 cipher. However, the RC4 Kerberos enctypes have additional flaws. These flaws reduce the security of applications that use the enctypes; the weakening occurs for various reasons, including the weakness of the password hashing algorithm, the reuse of key material across protocols, and the lack of a salt when hashing the password.
由于密钥流中的统计偏差，RC4作为TLS密码的弱点已经得到了广泛的宣传[RFC7465]，这些统计偏差引起了RC4密码使用者的担忧。但是，RC4 Kerberos加密类型还有其他缺陷。这些缺陷降低了使用EncType的应用程序的安全性；出现这种弱化的原因有很多，包括密码散列算法的弱点、跨协议重用密钥材料以及散列密码时缺少salt。
The RC4 stream cipher is known to have statistical biases in its output, which have led to practical attacks against protocols such as TLS that use RC4 [RFC7465]. At least some of these attacks rely on repeated encryptions of thousands of copies of the same plaintext; although it is easy for malicious javascript in a website to cause such traffic, it is unclear whether there is an easy way to induce a kerberized application to generate such repeated encryptions. The statistical biases are most pronounced for earlier bits in the output stream, which is somewhat mitigated by the use of a confounder in Kerberos messages: the first 64 bits of plaintext are a random confounder, and are thus of no use to an attacker who can retrieve them.
众所周知，RC4流密码的输出中存在统计偏差，这导致了对使用RC4的TLS等协议的实际攻击[RFC7465]。至少其中一些攻击依赖于对同一明文的数千份副本的重复加密；尽管网站中的恶意javascript很容易导致此类流量，但目前尚不清楚是否有一种简单的方法可以诱导kerberized应用程序生成此类重复加密。统计偏差对于输出流中的较早位最为明显，在Kerberos消息中使用混淆会有所缓解：明文的前64位是随机混淆，因此对于能够检索它们的攻击者没有任何用处。
Nonetheless, the statistical biases in the RC4 keystream extend well past 64 bits and provide potential attack surface to an attacker. Continuing to use a known weak algorithm is inviting further development of attacks.
尽管如此，RC4密钥流中的统计偏差远远超过64位，为攻击者提供了潜在的攻击面。继续使用已知的弱算法会导致攻击的进一步发展。
Kerberos long-term keys can be either random (as might be used in a service's keytab) or derived from a password (e.g., for individual users to authenticate to a system). The specification for a Kerberos encryption type must include a "string2key" algorithm for generating a raw crypto key from a string (i.e., password). Modern encryption types, such as those using the AES and Camellia block ciphers, use a string2key function based on the Password-Based Key Derivation Function 2 (PBKDF2) algorithm. This algorithm involves many iterations of a cryptographic hash function, designed to increase the computational effort required to perform a brute-force password-guessing attack. There is an additional option to specify an increased iteration count for a given principal, providing some modicum of adaptability for increases in computing power.
Kerberos长期密钥可以是随机的（可能在服务的keytab中使用），也可以是从密码派生的（例如，用于单个用户对系统进行身份验证）。Kerberos加密类型的规范必须包括用于从字符串（即密码）生成原始加密密钥的“string2key”算法。现代加密类型，例如使用AES和Camellia分组密码的加密类型，使用基于密码的密钥派生函数2（PBKDF2）算法的string2key函数。该算法涉及加密哈希函数的多次迭代，旨在增加执行蛮力密码猜测攻击所需的计算工作量。还有一个额外的选项可以为给定的主体指定增加的迭代次数，从而为计算能力的增加提供一些适应性。
It is also best practice, when deriving cryptographic secrets from user passwords, to include as input to the hash function a value that is unique to both the user and the realm of authentication; this user-specific input is known as a "salt". The default salt for Kerberos principals includes both the name of the principal and the name of the realm, in accordance with these best practices. However, the RC4 encryption types ignore the salt input to the string2key function; the function itself is a single iteration of the MD4 hash function applied to the UTF-16 encoded password, with no salt at all. The MD4 hash function is very old and considered to be weak and unsuitable for new cryptographic applications at this time [RFC6150].
从用户密码中获取密码机密时，最好将用户和认证领域都唯一的值作为哈希函数的输入；这种特定于用户的输入称为“salt”。根据这些最佳实践，Kerberos主体的默认salt包括主体名称和领域名称。但是，RC4加密类型忽略string2key函数的salt输入；该函数本身是应用于UTF-16编码密码的MD4哈希函数的一次迭代，完全没有盐。MD4哈希函数非常古老，目前被认为很弱，不适合新的加密应用程序[RFC6150]。
The omission of a salt input to the hash is contrary to cryptographic best practices and allows an attacker to construct a "rainbow table" of password hashes; such tables are applicable to all principals in all Kerberos realms. Given the prevalence of poor-quality user-selected passwords, it is likely that a rainbow table derived from a database of common passwords would be able to compromise a sizable number of Kerberos principals in any realm using RC4 encryption types for password-derived keys.
省略对散列的salt输入违反了加密最佳实践，并允许攻击者构建密码散列的“彩虹表”；此类表适用于所有Kerberos领域中的所有主体。鉴于用户选择的低质量密码的普遍存在，从通用密码数据库派生的彩虹表很可能会危害任何领域中使用RC4加密类型作为密码派生密钥的大量Kerberos主体。
The selection of unsalted MD4 as the Kerberos string2key function was deliberate, since it allowed systems to be converted in-place from the old NT LAN Manager (NTLM) logon protocol [MS-NLMP] to use Kerberos.
选择无盐MD4作为Kerberos string2key函数是经过深思熟虑的，因为它允许系统从旧的NT LAN Manager（NTLM）登录协议[MS-NLMP]就地转换为使用Kerberos。
Unfortunately, there still exist systems using NTLM for authentication to applications, which can result in application servers possessing the NT password hash of user passwords. Because the RC4 string2key function was chosen to be compatible with the NTLM
不幸的是，仍然存在使用NTLM对应用程序进行身份验证的系统，这可能导致应用程序服务器拥有用户密码的NT密码散列。因为选择RC4 string2key函数与NTLM兼容
scheme, these application servers also possess the long-term Kerberos key for those users, even though the password is unknown. The cross-protocol use of the long-term key/password hash was convenient for migrating to Kerberos, but it now provides a vulnerability in Kerberos as NTLM continues to be used.
根据该方案，这些应用服务器还拥有这些用户的长期Kerberos密钥，即使密码未知。长期密钥/密码哈希的跨协议使用便于迁移到Kerberos，但随着NTLM的继续使用，它现在在Kerberos中提供了一个漏洞。
The RC4 Kerberos encryption type remains in use in many environments because of interoperability requirements. In those sites, RC4 is the strongest enctype that allows two parties to use Kerberos to communicate. In particular, the Kerberos implementations included with Windows XP and Windows Server 2003 support only single-DES and RC4. Since single-DES is deprecated [RFC6649], machines running those operating systems must use RC4.
由于互操作性要求，RC4 Kerberos加密类型仍在许多环境中使用。在这些站点中，RC4是允许双方使用Kerberos进行通信的最强加密类型。特别是，Windows XP和Windows Server 2003中包含的Kerberos实现仅支持单个DES和RC4。由于不推荐使用单DES[RFC6649]，运行这些操作系统的机器必须使用RC4。
Similarly, there are cross-realm deployments in which the cross-realm key was initially established when one peer only supported RC4, or machines only supporting RC4 need to obtain a cross-realm Ticket-Granting Ticket. It can be difficult to inventory all clients in a Kerberos realm and know what implementations will be used by those client principals; this leads to concerns that disabling RC4 will cause breakage on machines that are unknown to the realm administrators.
类似地，也有跨领域部署，其中跨领域密钥最初是在一个对等方仅支持RC4或仅支持RC4的计算机需要获得跨领域票据授予票据时建立的。很难清点Kerberos领域中的所有客户机，也很难知道这些客户机主体将使用什么实现；这导致人们担心，禁用RC4将导致领域管理员未知的计算机上的中断。
Fortunately, modern (i.e., supported) Kerberos implementations support a secure alternative to RC4 in the form of AES. Windows has supported AES since 2007-2008 with the release of Windows Vista and Server 2008. MIT Kerberos [MITKRB5] has fully supported AES enctypes since 2004 with the release of version 1.3.2, including the Kerberos mechanism for the Generic Security Service Application Program Interface (GSSAPI). Heimdal [HEIMDAL] has fully supported AES since 2005 with the release of version 0.7. Though there may still be issues running ten-year-old unsupported software in mixed environments with new software, issues of that sort seem unlikely to be unique to Kerberos, and the administrators of such environments are expected to be capable of devising workarounds.
幸运的是，现代（即受支持的）Kerberos实现以AES的形式支持RC4的安全替代方案。自2007-2008年Windows Vista和Server 2008发布以来，Windows一直支持AES。自2004年1.3.2版发布以来，MIT Kerberos[MITKRB5]已经完全支持AES加密类型，包括通用安全服务应用程序接口（GSSAPI）的Kerberos机制。Heimdal[Heimdal]自2005年发布0.7版以来就完全支持AES。尽管在与新软件混合的环境中运行十年前不受支持的软件可能仍然存在问题，但这类问题似乎不太可能是Kerberos独有的，并且此类环境的管理员应该能够设计解决方法。
The flaws in triple-DES as used for Kerberos are not quite as damning as those in RC4, but there is still ample justification for deprecating its use. As is the case for the RC4 enctypes, the string2key algorithm is weak. Additionally, the triple-DES encryption types were not implemented in all Kerberos implementations, and the 64-bit block size may be problematic in some environments.
用于Kerberos的三重DES中的缺陷并不像RC4中的缺陷那么严重，但是仍然有充分的理由反对使用它。与RC4 EncType的情况一样，string2key算法很弱。此外，并非所有Kerberos实现中都实现了三重DES加密类型，在某些环境中，64位块大小可能存在问题。
The n-fold-based string2key function used by the des3-cbc-sha1-kd encryption type is an ad hoc construction that should not be considered cryptographically sound. It is known to not provide effective mixing of the input bits and is computationally easy to evaluate. As such, it does not slow down brute-force attacks in the way that the computationally demanding PBKDF2 algorithm used by more modern encryption types does. The salt is used by des3-cbc-sha1-kd's string2key function, in contrast to RC4, but a brute-force dictionary attack on common passwords may still be feasible.
des3-cbc-sha1-kd加密类型使用的基于n折叠的string2key函数是一种特殊构造，不应将其视为可靠的加密。众所周知，它不能提供输入位的有效混合，并且在计算上易于评估。因此，它不会像更现代的加密类型使用的计算要求更高的PBKDF2算法那样减慢暴力攻击的速度。与RC4不同，des3-cbc-sha1-kd的string2key函数使用salt，但对常用密码的暴力字典攻击可能仍然可行。
Triple-DES is based on the single-DES primitive, simply using additional key material and nested encryption. Therefore, it inherits the 64-bit cipher block size from single-DES. As a result, an attacker who can collect approximately 2**32 blocks of ciphertext has a good chance of finding a cipher block collision (the "birthday attack"), which would potentially reveal a couple of blocks of plaintext.
三重DES基于单DES原语，只需使用额外的密钥材料和嵌套加密。因此，它从单个DES继承64位密码块大小。因此，能够收集大约2**32个密文块的攻击者很有可能发现密码块冲突（“生日攻击”），这可能会暴露出几个明文块。
A cipher block collision would not necessarily cause the key itself to be leaked, so the plaintext revealed by such a collision would be limited. For some sites, that may be an acceptable risk, but it is still considered a weakness in the encryption type.
密码块冲突不一定会导致密钥本身泄漏，因此这种冲突所揭示的明文将受到限制。对于某些站点，这可能是一个可接受的风险，但它仍然被认为是加密类型中的一个弱点。
The triple-DES encryption types were implemented by MIT Kerberos early in its development (ca. 1999) and present in the 1.2 release, but they were superseded when encryption types 17 and 18 (AES) were implemented (by 2003); the AES enctypes were present in the 1.3 release. The Heimdal Kerberos implementation also provided a version of triple-DES in 1999 (though the GSSAPI portions remained non-interoperable with MIT for some time after that), gaining support for AES in 2005 with its 0.7 release. Both Heimdal and MIT krb5 have supported the AES enctypes for some 12 years, and it is expected that deployments that support triple-DES but not AES are quite rare.
MIT Kerberos在其开发早期（约1999年）就实现了三重DES加密类型，并出现在1.2版本中，但在实现加密类型17和18（AES）时（到2003年），三重DES加密类型被取代；AES EncType出现在1.3版本中。Heimdal Kerberos实现还在1999年提供了triple DES的一个版本（尽管在那之后的一段时间内GSSAPI部分仍然无法与MIT进行互操作），并在2005年的0.7版本中获得了对AES的支持。Heimdal和MIT krb5都支持AES加密类型已经有12年了，预计支持三重DES但不支持AES的部署非常罕见。
The Kerberos implementation in Microsoft Windows has never implemented the triple-DES encryption type. Support for AES was introduced with Windows Vista and Windows Server 2008; older versions such as Windows XP and Windows Server 2003 only supported the RC4 and single-DES encryption types.
Microsoft Windows中的Kerberos实现从未实现过三重DES加密类型。Windows Vista和Windows Server 2008引入了对AES的支持；Windows XP和Windows Server 2003等旧版本仅支持RC4和单DES加密类型。
The triple-DES encryption type offers very slow encryption, especially compared to the performance of AES using the hardware acceleration available in modern CPUs. There are no areas where triple-DES offers advantages over other encryption types except in the rare case where AES is not available.
三重DES加密类型提供非常慢的加密，尤其是与使用现代CPU中可用的硬件加速的AES性能相比。除了少数情况下AES不可用外，triple DES在任何领域都比不上其他加密类型。
This document hereby removes the following RECOMMENDED types from [RFC4120]:
本文件特此从[RFC4120]中删除以下推荐类型：
Encryption: DES3-CBC-SHA1-KD
加密：DES3-CBC-SHA1-KD
Checksum: HMAC-SHA1-DES3-KD
校验和：HMAC-SHA1-DES3-KD
Kerberos implementations and deployments SHOULD NOT implement or deploy the following triple-DES encryption types: DES3-CBC-MD5(5), DES3-CBC-SHA1(7), and DES3-CBC-SHA1-KD(16) (updates [RFC3961] and [RFC4120]).
Kerberos实现和部署不应实现或部署以下三重DES加密类型：DES3-CBC-MD5（5）、DES3-CBC-SHA1（7）和DES3-CBC-SHA1-KD（16）（更新[RFC3961]和[RFC4120]）。
Kerberos implementations and deployments SHOULD NOT implement or deploy the RC4 encryption type RC4-HMAC(23).
Kerberos实现和部署不应实现或部署RC4加密类型RC4-HMAC（23）。
Kerberos implementations and deployments SHOULD NOT implement or deploy the following checksum types: RSA-MD5(7), RSA-MD5-DES3(9), HMAC-SHA1-DES3-KD(12), and HMAC-SHA1-DES3(13) (updates [RFC3961] and [RFC4120]).
Kerberos实现和部署不应实现或部署以下校验和类型：RSA-MD5（7）、RSA-MD5-DES3（9）、HMAC-SHA1-DES3-KD（12）和HMAC-SHA1-DES3（13）（更新[RFC3961]和[RFC4120]）。
Kerberos GSS mechanism implementations and deployments SHOULD NOT implement or deploy the following SGN_ALGs: HMAC MD5(1100) and HMAC SHA1 DES3 KD(0400). (With all its content now deprecated, [RFC4757] has been made Historic by this document.)
Kerberos GSS机制实现和部署不应实现或部署以下SGN_ALG:HMAC MD5（1100）和HMAC SHA1 DES3 KD（0400）。（由于其所有内容现已弃用，[RFC4757]已成为本文档的历史性内容。）
Kerberos GSS mechanism implementations and deployments SHOULD NOT implement or deploy the following SEAL_ALGs: RC4(1000) and DES3KD(0200).
Kerberos GSS机制的实现和部署不应实现或部署以下SEAL_ALGs:RC4（1000）和DES3KD（0200）。
Per this document, [RFC4757] has been reclassified as Historic.
根据本文件，[RFC4757]已重新分类为历史记录。
This document is entirely about security considerations, namely that the use of the triple-DES and RC4 Kerberos encryption types is not secure, and they should not be used.
本文档完全是关于安全方面的考虑，即使用三重DES和RC4 Kerberos加密类型是不安全的，不应使用它们。
IANA has updated the "Kerberos Encryption Type Numbers" registry [IANA-KRB] to note that 1) encryption types 1, 2, 3, and 24 are deprecated, with [RFC6649] as the reference and that 2) encryption types 5, 7, 16, and 23 are deprecated, with this document as the reference.
IANA更新了“Kerberos加密类型编号”注册表[IANA-KRB]，注意到1）不推荐使用加密类型1、2、3和24，以[RFC6649]为参考；2）不推荐使用加密类型5、7、16和23，以本文档为参考。
Similarly, IANA has updated the "Kerberos Checksum Type Numbers" registry [IANA-KRB] to note that 1) checksum type values 1, 2, 3, 4, 5, 6, and 8 are deprecated, with [RFC6649] as the reference, and that 2) checksum type values 7, 12, and 13 are deprecated, with this document as the reference.
类似地，IANA更新了“Kerberos校验和类型号”注册表[IANA-KRB]，以注意1）校验和类型值1、2、3、4、5、6和8已弃用，以[RFC6649]为参考，2）校验和类型值7、12和13已弃用，以本文档为参考。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 2005, <https://www.rfc-editor.org/info/rfc3961>.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，DOI 10.17487/RFC3961，2005年2月<https://www.rfc-editor.org/info/rfc3961>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <https://www.rfc-editor.org/info/rfc4120>.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC 4120，DOI 10.17487/RFC4120，2005年7月<https://www.rfc-editor.org/info/rfc4120>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[HEIMDAL] Heimdal Project, "The Heimdal Kerberos 5, PKIX, CMS, GSS-API, SPNEGO, NTLM, Digest-MD5 and, SASL implementation", <https://www.h5l.org/>.
[HEIMDAL]HEIMDAL项目，“HEIMDAL Kerberos 5、PKIX、CMS、GSS-API、SPNEGO、NTLM、Digest-MD5和SASL实现”<https://www.h5l.org/>.
[IANA-KRB] IANA, "Kerberos Parameters", <https://www.iana.org/assignments/kerberos-parameters/>.
[IANA-KRB]IANA，“Kerberos参数”<https://www.iana.org/assignments/kerberos-parameters/>.
[MITKRB5] MIT, "Kerberos: The Network Authentication Protocol", <https://web.mit.edu/kerberos/>.
[MITKRB5]MIT，“Kerberos:网络身份验证协议”<https://web.mit.edu/kerberos/>.
[MS-NLMP] Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol", September 2017, <https://msdn.microsoft.com/en-us/library/cc236621.aspx>.
[MS-NLMP]微软公司，[MS-NLMP]：NT LAN Manager（NTLM）身份验证协议，2017年9月<https://msdn.microsoft.com/en-us/library/cc236621.aspx>.
[RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows", RFC 4757, DOI 10.17487/RFC4757, December 2006, <https://www.rfc-editor.org/info/rfc4757>.
[RFC4757]Jaganathan，K.，Zhu，L.，和J.Brezak，“微软Windows使用的RC4-HMAC Kerberos加密类型”，RFC 4757，DOI 10.17487/RFC4757，2006年12月<https://www.rfc-editor.org/info/rfc4757>.
[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", RFC 6150, DOI 10.17487/RFC6150, March 2011, <https://www.rfc-editor.org/info/rfc6150>.
[RFC6150]Turner，S.和L.Chen，“MD4的历史地位”，RFC 6150，DOI 10.17487/RFC6150，2011年3月<https://www.rfc-editor.org/info/rfc6150>.
[RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos", BCP 179, RFC 6649, DOI 10.17487/RFC6649, July 2012, <https://www.rfc-editor.org/info/rfc6649>.
[RFC6649]Hornquist Astrand，L.和T.Yu，“反对Kerberos中的DES、RC4-HMAC-EXP和其他弱加密算法”，BCP 179，RFC 6649，DOI 10.17487/RFC6649，2012年7月<https://www.rfc-editor.org/info/rfc6649>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, <https://www.rfc-editor.org/info/rfc7465>.
[RFC7465]Popov，A.，“禁止RC4密码套件”，RFC 7465，DOI 10.17487/RFC7465，2015年2月<https://www.rfc-editor.org/info/rfc7465>.
Acknowledgements
致谢
Many people have contributed to the understanding of the weaknesses of these encryption types over the years, and they cannot all be named here.
多年来，许多人都为理解这些加密类型的弱点做出了贡献，这里不能一一列举。
Authors' Addresses
作者地址
Benjamin Kaduk Akamai Technologies
Benjamin Kaduk Akamai Technologies
Email: kaduk@mit.edu
Email: kaduk@mit.edu
Michiko Short Microsoft Corporation
美智子微软公司
Email: michikos@microsoft.com
Email: michikos@microsoft.com