1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
|
<pre>Internet Engineering Task Force (IETF) B. Kaduk
Request for Comments: 8429 Akamai
BCP: 218 M. Short
Updates: <a href="./rfc3961">3961</a>, <a href="./rfc4120">4120</a> Microsoft Corporation
Category: Best Current Practice October 2018
ISSN: 2070-1721
<span class="h1">Deprecate Triple-DES (3DES) and RC4 in Kerberos</span>
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, <a href="./rfc4757">RFC 4757</a> has been moved to
Historic status, as none of the encryption types it specifies should
be used, and <a href="./rfc3961">RFC 3961</a> has been updated to note the deprecation of the
triple-DES encryption types. <a href="./rfc4120">RFC 4120</a> is likewise updated to remove
the recommendation to implement triple-DES encryption and checksum
types.
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 <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8429">https://www.rfc-editor.org/info/rfc8429</a>.
<span class="grey">Kaduk & Short Best Current Practice [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8429">RFC 8429</a> Deprecate 3DES and RC4 in Kerberos October 2018</span>
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Requirements Notation . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Affected Specifications . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Affected Encryption Types . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. RC4 Weakness . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5.1">5.1</a>. Statistical Biases . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5.2">5.2</a>. Password Hash . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.3">5.3</a>. Cross-Protocol Key Reuse . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.4">5.4</a>. Interoperability Concerns . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6">6</a>. Triple-DES Weakness . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-6.1">6.1</a>. Password-Based Keys . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6.2">6.2</a>. Block Size . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6.3">6.3</a>. Interoperability Concerns . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-7">7</a>. Recommendations . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-9">9</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<span class="grey">Kaduk & Short Best Current Practice [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8429">RFC 8429</a> Deprecate 3DES and RC4 in Kerberos October 2018</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
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, <a href="./rfc4757">RFC</a>
<a href="./rfc4757">4757</a> has been moved to Historic status, as none of the encryption
types it specifies should be used, and <a href="./rfc3961">RFC 3961</a> has been updated to
note the deprecation of the triple-DES encryption types. <a href="./rfc4120">RFC 4120</a> is
likewise updated to remove the recommendation to implement triple-DES
encryption and checksum types.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements Notation</span>
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
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Affected Specifications</span>
The RC4 Kerberos encryption types (including rc4-hmac) are specified
in [<a href="./rfc4757" title=""The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows"">RFC4757</a>], which has been moved to Historic status.
The des3-cbc-sha1-kd encryption type is specified in [<a href="./rfc3961" title=""Encryption and Checksum Specifications for Kerberos 5"">RFC3961</a>].
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.
The Kerberos specification ([<a href="./rfc4120" title=""The Kerberos Network Authentication Service (V5)"">RFC4120</a>]) includes recommendations for
which encryption and checksum types to implement; the deprecated
encryption and checksum types are now disrecommended to implement.
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.
<span class="grey">Kaduk & Short Best Current Practice [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8429">RFC 8429</a> Deprecate 3DES and RC4 in Kerberos October 2018</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Affected Encryption Types</span>
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 |
+----------------+--------------------------+
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. RC4 Weakness</span>
RC4's weakness as a TLS cipher due to statistical biases in the
keystream has been well publicized [<a href="./rfc7465" title=""Prohibiting RC4 Cipher Suites"">RFC7465</a>], 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.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Statistical Biases</span>
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 [<a href="./rfc7465" title=""Prohibiting RC4 Cipher Suites"">RFC7465</a>]. 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.
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.
<span class="grey">Kaduk & Short Best Current Practice [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8429">RFC 8429</a> Deprecate 3DES and RC4 in Kerberos October 2018</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Password Hash</span>
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.
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 [<a href="./rfc6150" title=""MD4 to Historic Status"">RFC6150</a>].
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.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Cross-Protocol Key Reuse</span>
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 [<a href="#ref-MS-NLMP" title=""[MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol"">MS-NLMP</a>] to use
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
<span class="grey">Kaduk & Short Best Current Practice [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8429">RFC 8429</a> Deprecate 3DES and RC4 in Kerberos October 2018</span>
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.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Interoperability Concerns</span>
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 [<a href="./rfc6649" title=""Deprecate DES, RC4-HMAC- EXP, and Other Weak Cryptographic Algorithms in Kerberos"">RFC6649</a>], machines running
those operating systems must use 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.
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 [<a href="#ref-MITKRB5" title=""Kerberos: The Network Authentication Protocol"">MITKRB5</a>] 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 [<a href="#ref-HEIMDAL" title=""The Heimdal Kerberos 5, PKIX, CMS, GSS- API, SPNEGO, NTLM, Digest-MD5 and, SASL implementation"">HEIMDAL</a>] 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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Triple-DES Weakness</span>
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.
<span class="grey">Kaduk & Short Best Current Practice [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8429">RFC 8429</a> Deprecate 3DES and RC4 in Kerberos October 2018</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Password-Based Keys</span>
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.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Block Size</span>
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.
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.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Interoperability Concerns</span>
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.
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.
<span class="grey">Kaduk & Short Best Current Practice [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8429">RFC 8429</a> Deprecate 3DES and RC4 in Kerberos October 2018</span>
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.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Recommendations</span>
This document hereby removes the following RECOMMENDED types from
[<a href="./rfc4120" title=""The Kerberos Network Authentication Service (V5)"">RFC4120</a>]:
Encryption: DES3-CBC-SHA1-KD
Checksum: 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 [<a href="./rfc3961" title=""Encryption and Checksum Specifications for Kerberos 5"">RFC3961</a>] and
[<a href="./rfc4120" title=""The Kerberos Network Authentication Service (V5)"">RFC4120</a>]).
Kerberos implementations and deployments SHOULD NOT implement or
deploy the RC4 encryption type 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 [<a href="./rfc3961" title=""Encryption and Checksum Specifications for Kerberos 5"">RFC3961</a>] and
[<a href="./rfc4120" title=""The Kerberos Network Authentication Service (V5)"">RFC4120</a>]).
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, [<a href="./rfc4757" title=""The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows"">RFC4757</a>]
has been made Historic by this document.)
Kerberos GSS mechanism implementations and deployments SHOULD NOT
implement or deploy the following SEAL_ALGs: RC4(1000) and
DES3KD(0200).
Per this document, [<a href="./rfc4757" title=""The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows"">RFC4757</a>] has been reclassified as Historic.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
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.
<span class="grey">Kaduk & Short Best Current Practice [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8429">RFC 8429</a> Deprecate 3DES and RC4 in Kerberos October 2018</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
IANA has updated the "Kerberos Encryption Type Numbers" registry
[<a href="#ref-IANA-KRB">IANA-KRB</a>] to note that 1) encryption types 1, 2, 3, and 24 are
deprecated, with [<a href="./rfc6649" title=""Deprecate DES, RC4-HMAC- EXP, and Other Weak Cryptographic Algorithms in Kerberos"">RFC6649</a>] as the reference and that 2) encryption
types 5, 7, 16, and 23 are deprecated, with this document as the
reference.
Similarly, IANA has updated the "Kerberos Checksum Type Numbers"
registry [<a href="#ref-IANA-KRB">IANA-KRB</a>] to note that 1) checksum type values 1, 2, 3, 4,
5, 6, and 8 are deprecated, with [<a href="./rfc6649" title=""Deprecate DES, RC4-HMAC- EXP, and Other Weak Cryptographic Algorithms in Kerberos"">RFC6649</a>] as the reference, and that
2) checksum type values 7, 12, and 13 are deprecated, with this
document as the reference.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3961">RFC3961</a>] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", <a href="./rfc3961">RFC 3961</a>, DOI 10.17487/RFC3961, February
2005, <<a href="https://www.rfc-editor.org/info/rfc3961">https://www.rfc-editor.org/info/rfc3961</a>>.
[<a id="ref-RFC4120">RFC4120</a>] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", <a href="./rfc4120">RFC 4120</a>,
DOI 10.17487/RFC4120, July 2005,
<<a href="https://www.rfc-editor.org/info/rfc4120">https://www.rfc-editor.org/info/rfc4120</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-HEIMDAL">HEIMDAL</a>] Heimdal Project, "The Heimdal Kerberos 5, PKIX, CMS, GSS-
API, SPNEGO, NTLM, Digest-MD5 and, SASL implementation",
<<a href="https://www.h5l.org/">https://www.h5l.org/</a>>.
[<a id="ref-IANA-KRB">IANA-KRB</a>]
IANA, "Kerberos Parameters",
<<a href="https://www.iana.org/assignments/kerberos-parameters/">https://www.iana.org/assignments/kerberos-parameters/</a>>.
[<a id="ref-MITKRB5">MITKRB5</a>] MIT, "Kerberos: The Network Authentication Protocol",
<<a href="https://web.mit.edu/kerberos/">https://web.mit.edu/kerberos/</a>>.
<span class="grey">Kaduk & Short Best Current Practice [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8429">RFC 8429</a> Deprecate 3DES and RC4 in Kerberos October 2018</span>
[<a id="ref-MS-NLMP">MS-NLMP</a>] Microsoft Corporation, "[<a href="#ref-MS-NLMP" title=""[MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol"">MS-NLMP</a>]: NT LAN Manager (NTLM)
Authentication Protocol", September 2017,
<<a href="https://msdn.microsoft.com/en-us/library/cc236621.aspx">https://msdn.microsoft.com/en-us/library/cc236621.aspx</a>>.
[<a id="ref-RFC4757">RFC4757</a>] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
Kerberos Encryption Types Used by Microsoft Windows",
<a href="./rfc4757">RFC 4757</a>, DOI 10.17487/RFC4757, December 2006,
<<a href="https://www.rfc-editor.org/info/rfc4757">https://www.rfc-editor.org/info/rfc4757</a>>.
[<a id="ref-RFC6150">RFC6150</a>] Turner, S. and L. Chen, "MD4 to Historic Status",
<a href="./rfc6150">RFC 6150</a>, DOI 10.17487/RFC6150, March 2011,
<<a href="https://www.rfc-editor.org/info/rfc6150">https://www.rfc-editor.org/info/rfc6150</a>>.
[<a id="ref-RFC6649">RFC6649</a>] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-
EXP, and Other Weak Cryptographic Algorithms in Kerberos",
<a href="https://www.rfc-editor.org/bcp/bcp179">BCP 179</a>, <a href="./rfc6649">RFC 6649</a>, DOI 10.17487/RFC6649, July 2012,
<<a href="https://www.rfc-editor.org/info/rfc6649">https://www.rfc-editor.org/info/rfc6649</a>>.
[<a id="ref-RFC7465">RFC7465</a>] Popov, A., "Prohibiting RC4 Cipher Suites", <a href="./rfc7465">RFC 7465</a>,
DOI 10.17487/RFC7465, February 2015,
<<a href="https://www.rfc-editor.org/info/rfc7465">https://www.rfc-editor.org/info/rfc7465</a>>.
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
Email: kaduk@mit.edu
Michiko Short
Microsoft Corporation
Email: michikos@microsoft.com
Kaduk & Short Best Current Practice [Page 10]
</pre>
|
