[要約] RFC 8429は、KerberosにおけるTriple-DES（3DES）とRC4の非推奨化に関するものであり、これらの暗号アルゴリズムの使用を停止することを目的としています。
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でのTriple-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は、指定する暗号化タイプを使用する必要がないため、Historicステータスに移行しました。また、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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
triple-DES（3DES）およびRC4暗号化タイプ（enctypes）は、暗号の強度が着実に弱まっているため、Kerberosでの使用を非推奨にするプロセスを開始する必要があります。したがって、RFC 4757は、指定する暗号化タイプを使用する必要がないため、Historicステータスに移行しました。また、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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The RC4 Kerberos encryption types (including rc4-hmac) are specified in [RFC4757], which has been moved to Historic status.
RC4 Kerberos暗号化タイプ（rc4-hmacを含む）は、[RFC4757]で指定されており、Historicステータスに移行しています。
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.
des3-cbc-sha1-kd暗号化タイプは[RFC3961]で指定されています。追加のtriple-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 |
+----------------+--------------------------+
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.
キーストリームの統計的バイアスによるTLS暗号としてのRC4の弱点は広く公表されており[RFC7465]、これらの統計的バイアスはRC4暗号の利用者に懸念を引き起こします。ただし、RC4 Kerberos enctypeには追加の欠陥があります。これらの欠陥により、enctypeを使用するアプリケーションのセキュリティが低下します。脆弱化は、パスワードハッシュアルゴリズムの脆弱性、プロトコル間でのキーマテリアルの再利用、パスワードハッシュ時のソルトの欠如など、さまざまな理由で発生します。
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]。これらの攻撃の少なくとも一部は、同じプレーンテキストの何千ものコピーを繰り返し暗号化することに依存しています。 Webサイトの悪意のあるjavascriptがそのようなトラフィックを引き起こすのは簡単ですが、Kerberos化されたアプリケーションにこのような繰り返し暗号化を生成させる簡単な方法があるかどうかは不明です。統計的バイアスは、出力ストリームの以前のビットで最も顕著です。これは、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の長期鍵は、ランダム（サービスのキータブで使用される可能性がある）またはパスワードから派生したもの（たとえば、個々のユーザーがシステムに対して認証するため）のいずれかです。 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].
また、ユーザーパスワードから暗号シークレットを取得する場合、ハッシュ関数への入力として、ユーザーと認証の領域の両方に固有の値を含めることもベストプラクティスです。このユーザー固有の入力は「塩」と呼ばれます。 Kerberosプリンシパルのデフォルトのソルトには、これらのベストプラクティスに従って、プリンシパルの名前とレルムの名前の両方が含まれています。ただし、RC4暗号化タイプは、string2key関数へのソルト入力を無視します。この関数自体は、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.
ハッシュへのソルト入力の省略は暗号化のベストプラクティスに反し、攻撃者がパスワードハッシュの「レインボーテーブル」を作成することを可能にします。このようなテーブルは、すべての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 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.
残念ながら、アプリケーションへの認証にNTLMを使用するシステムはまだ存在しており、アプリケーションサーバーがユーザーパスワードのNTパスワードハッシュを所有する可能性があります。 RC4 string2key関数はNTLMスキームと互換性があるように選択されているため、これらのアプリケーションサーバーは、パスワードが不明であっても、これらのユーザーの長期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は、2つのパーティがKerberosを使用して通信できるようにする最強のenctypeです。特に、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.
同様に、1つのピアが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の安全な代替手段をサポートしています。 Windowsは、Windows VistaおよびServer 2008のリリースで2007-2008以降AESをサポートしています。MITKerberos [MITKRB5]は、Generic Security Service Application ProgramのKerberosメカニズムを含め、バージョン1.3.2のリリースで2004年以降、AES enctypeを完全にサポートしています。インターフェース（GSSAPI）。 Heimdal [HEIMDAL]は、バージョン0.7のリリースで2005年以来AESを完全にサポートしています。新しいソフトウェアとの混合環境で10年前のサポートされていないソフトウェアを実行する問題はまだあるかもしれませんが、そのような問題は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に使用されるようなTriple-DESの欠陥は、RC4の欠陥ほどひどいものではありませんが、その使用を廃止することには十分な正当化があります。 RC4 enctypesの場合と同様に、string2keyアルゴリズムは弱いです。さらに、トリプルDES暗号化タイプはすべてのKerberos実装に実装されていなかったため、環境によっては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アルゴリズムが行うように、ブルートフォース攻撃が遅くなることはありません。 saltは、RC4とは対照的に、des3-cbc-sha1-kdのstring2key関数で使用されますが、一般的なパスワードに対するブルートフォース辞書攻撃は依然として実行可能です。
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.
triple-DES暗号化タイプは、開発の早い段階（1999年頃）および1.2リリースでMIT Kerberosによって実装されましたが、暗号化タイプ17および18（AES）が実装されたとき（2003年まで）は置き換えられました。 AES enctypeは1.3リリースに存在していました。 Heimdal Kerberos実装は1999年にtriple-DESのバージョンも提供しました（ただし、GSSAPI部分はその後しばらくMITと相互運用できませんでした）、0.7リリースで2005年にAESのサポートを得ました。 HeimdalとMIT krb5の両方が約12年間AES enctypeをサポートしており、トリプル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暗号化タイプを実装したことがありません。 AESのサポートは、Windows VistaおよびWindows Server 2008で導入されました。 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.
triple-DES暗号化タイプは、特に最新のCPUで利用可能なハードウェアアクセラレーションを使用するAESのパフォーマンスと比較して、非常に遅い暗号化を提供します。 AESが使用できないというまれなケースを除いて、トリプルDESが他の暗号化タイプよりも優れている点はありません。
This document hereby removes the following RECOMMENDED types from [RFC4120]:
このドキュメントは、[RFC4120]から以下のRECOMMENDEDタイプを削除します。
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の実装と展開では、DES3-CBC-MD5（5）、DES3-CBC-SHA1（7）、DES3-CBC-SHA1-KD（16）のトリプルDES暗号化タイプを実装または展開するべきではありません（更新[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メカニズムの実装と展開では、SMAC_5のHMAC MD1（1100）とHMAC SHA1 DES3 KD（0400）を実装または展開する必要があります（SHOULD NOT）。 （その内容はすべて非推奨になり、[RFC4757]はこのドキュメントによって歴史的となっています。）
Kerberos GSS mechanism implementations and deployments SHOULD NOT implement or deploy the following SEAL_ALGs: RC4(1000) and DES3KD(0200).
Kerberos GSSメカニズムの実装と配備は、次のSEAL_ALGを実装または配備するべきではありません：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 Encryption Type Numbers」レジストリ[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 Checksum Type Numbers」レジストリ[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、「The Kerberos Network Authentication Service（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：The Network Authentication Protocol」、<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] Microsoft Corporation、「[MS-NLMP]：NT LAN Manager（NTLM）Authentication Protocol」、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、「Microsoft 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]ターナー、S。およびL.チェン、「MD4 to Historic Status」、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、「非推奨のDES、RC4-HMAC-EXP、およびその他のKerberosの弱い暗号アルゴリズム」、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。、「Prohibiting RC4 Cipher Suites」、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
Michiko Short Microsoft Corporation
みちこ しょｒｔ みｃろそｆｔ こｒぽらちおん
Email: michikos@microsoft.com