idnits 2.17.1
draft-luis140219-curdle-rc4-die-die-die-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
-- The draft header indicates that this document obsoletes RFC4757, but the
abstract doesn't seem to directly say this. It does mention RFC4757
though, so this could be OK.
-- The draft header indicates that this document obsoletes RFC4345, but the
abstract doesn't seem to directly say this. It does mention RFC4345
though, so this could be OK.
-- The draft header indicates that this document obsoletes RFC3078, but the
abstract doesn't seem to directly say this. It does mention RFC3078
though, so this could be OK.
-- The draft header indicates that this document obsoletes RFC3079, but the
abstract doesn't seem to directly say this. It does mention RFC3079
though, so this could be OK.
-- The draft header indicates that this document updates RFC7905, but the
abstract doesn't seem to directly say this. It does mention RFC7905
though, so this could be OK.
-- The draft header indicates that this document updates RFC6733, but the
abstract doesn't seem to directly say this. It does mention RFC6733
though, so this could be OK.
-- The draft header indicates that this document updates RFC6649, but the
abstract doesn't seem to directly say this. It does mention RFC6649
though, so this could be OK.
-- The draft header indicates that this document updates RFC7457, but the
abstract doesn't seem to directly say this. It does mention RFC7457
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords -- however, there's a paragraph with
a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
(Using the creation date from RFC2118, updated by this document, for
RFC5378 checks: 1997-02-20)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 3, 2017) is 2482 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFCyyyy' is mentioned on line 181, but not defined
== Missing Reference: 'RFC6733' is mentioned on line 310, but not defined
== Outdated reference: A later version (-05) exists of
draft-ietf-curdle-des-des-des-die-die-die-03
-- Obsolete informational reference (is this intentional?): RFC 3501
(Obsoleted by RFC 9051)
Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 11 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Internet Engineering Task Force (IETF) L. Camara
2 Internet-Draft July 3, 2017
3 Obsoletes: 3078, 3079, 4345, 4757, 6229
4 Updates: 2118, 3501, 3961, 4120, 4253, 6150
5 Updates: 6649, 6733, 7457, 7905, xxxx
6 Intended Status: Best Current Practice
7 Expires: January 4, 2018
9 Deprecating RC4 in all IETF Protocols
10 draft-luis140219-curdle-rc4-die-die-die-02
12 [[RFC-Editor: Please replace all instances of xxxx in this document with
13 the RFC number of draft-ietf-curdle-des-des-des-die-die-die.]]
15 [[RFC-Editor: please replace the second character of my surname by
16 U+00E2 when publishing as RFC in the header and in all pages.
17 Non-ASCII characters are allowed in RFCs as per RFC 7997.]]
19 Abstract
21 RC4 is extremely weak as shown by RFC 6649 and RFC 7457, is
22 prohibited in TLS by RFC 7465, is prohibited in Kerberos by RFC xxxx
23 and it needs to be prohibited in all IETF protocols. Documents that
24 provide technology that can only use RC4 are obsoleted by this
25 document, so this document obsoletes and moves to Historic RFC 3078
26 "Microsoft Point-to-Point Encryption (MPPE) Protocol" (only supports
27 RC4, RFC 3079 that is also part of that protocol is also obsoleted),
28 RFC 4345 "Improved Arcfour Modes for the Secure Shell (SSH) Transport
29 Layer Protocol" (note Arcfour and RC4 are synonymous), RFC 4757 "The
30 RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows" (only
31 supports RC4) and RFC 6229 "Test Vectors for the Stream Cipher RC4"
32 (provides test vectors for historic cryptography). RFC 2118,
33 RFC 3501, RFC 3961, RFC 4120, RFC 4253, RFC 6150, RFC 6649, RFC 6733,
34 RFC 7457, RFC 7905 and RFC xxxx are updated to note the deprecation
35 of RC4 in all IETF protocols. (Please do not confuse RFC 4757 with
36 RFC 7457.)
38 Status of This Memo
40 This Internet-Draft is submitted in full conformance with the
41 provisions of BCP 78 and BCP 79.
43 Internet-Drafts are working documents of the Internet Engineering
44 Task Force (IETF). Note that other groups may also distribute
45 working documents as Internet-Drafts. The list of current Internet-
46 Drafts is at http://datatracker.ietf.org/drafts/current/.
48 Internet-Drafts are draft documents valid for a maximum of six months
49 and may be updated, replaced, or obsoleted by other documents at any
50 time. It is inappropriate to use Internet-Drafts as reference
51 material or to cite them other than as "work in progress."
53 This Internet-Draft will expire on January 4, 2018.
55 Copyright Notice
57 Copyright (c) 2017 IETF Trust and the persons identified as the
58 document authors. All rights reserved.
60 This document is subject to BCP 78 and the IETF Trust's Legal
61 Provisions Relating to IETF Documents
62 (http://trustee.ietf.org/license-info) in effect on the date of
63 publication of this document. Please review these documents
64 carefully, as they describe your rights and restrictions with respect
65 to this document. Code Components extracted from this document must
66 include Simplified BSD License text as described in Section 4.e of
67 the Trust Legal Provisions and are provided without warranty as
68 described in the Simplified BSD License.
70 Table of Contents
72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
73 2. Why obsolete those RFCs and move them to Historic . . . . . . . 3
74 3. Updates to RFC 2118 . . . . . . . . . . . . . . . . . . . . . . 3
75 4. Updates to RFC 3501 . . . . . . . . . . . . . . . . . . . . . . 3
76 5. Updates to RFC 3961 . . . . . . . . . . . . . . . . . . . . . . 4
77 6. Updates to RFC 4120 . . . . . . . . . . . . . . . . . . . . . . 4
78 7. Updates to RFC 4253 . . . . . . . . . . . . . . . . . . . . . . 4
79 8. Updates to RFC 6150 . . . . . . . . . . . . . . . . . . . . . . 5
80 9. Updates to RFC 6649 . . . . . . . . . . . . . . . . . . . . . . 5
81 10. Updates to RFC 6733 . . . . . . . . . . . . . . . . . . . . . 6
82 11. Updates to RFC 7457 . . . . . . . . . . . . . . . . . . . . . 7
83 12. Updates to RFC 7465 . . . . . . . . . . . . . . . . . . . . . 7
84 13. Updates to RFC 7905 . . . . . . . . . . . . . . . . . . . . . 7
85 14. Updates to RFC xxxx . . . . . . . . . . . . . . . . . . . . . 8
86 15. Action to be taken . . . . . . . . . . . . . . . . . . . . . . 8
87 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
88 17. Security Considerations . . . . . . . . . . . . . . . . . . . 9
89 18. Acknowlegdements . . . . . . . . . . . . . . . . . . . . . . . 9
90 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
91 19.1. Normative References . . . . . . . . . . . . . . . . . . . . 9
92 19.2. Informative References . . . . . . . . . . . . . . . . . . . 10
93 20. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
94 Appendix A. Status of Updated Documents as of 2017-06-17 . . . . . 11
95 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 13
97 1. Introduction
99 RC4 is extremely weak [RFC6649, RFC7457, RFCxxxx] and this document
100 deprecates its use in all IETF protocols, including Kerberos and
101 Secure Shell (SSH). The reasons for obsoleting RFC 3078, RFC 3079,
102 RFC 4345 and RFC 4757 and moving them to Historic are discussed in
103 Section 2. The updates to RFC 2118, RFC 3501, RFC 3961, RFC 4120,
104 RFC 4253, RFC 6150, RFC 6649, RFC 6733, RFC 7457, RFC 7905 and
105 RFC xxxx and the reasons for doing them are specified in sections 3,
106 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 and 14, respectively. The status of
107 the updated RFCs as of the writing of this document is available in
108 Appendix A.
110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
112 document are to be interpreted as described in
113 BCP 14 [RFC2119, RFC8174].
115 2. Why obsolete those RFCs and move them to Historic
117 RFC 3078 is no longer used by supported Microsoft Windows versions
118 and is moved to Historic and obsoleted by this document as it only
119 supports RC4 for encryption. RFC 2118 is updated to note the
120 moving of RFC 3078 (that updated RFC 2118) to Historic and its
121 obsoleting. RFC 3079, that is effectively part of RFC 3078, is also
122 moved to Historic as it only supports RC4 for encryption.
124 RFC 4345 defines the "arcfour-128" and "arcfour-256" modes for Secure
125 Shell (SSH), and is moved to Historic as RC4 is extremely
126 weak [RFC6649, RFC7457, RFCxxxx] and there is research that is at
127 least 5 years old that totally breaks all practical usage of
128 RC4 [RFC6649].
130 RFC 4757 is obsoleted and moved to Historic as it is no longer used
131 by supported Microsoft Windows versions (support for Windows XP ended
132 8 April 2014, any unofficial support for officially unsupported
133 Microsoft Windows versions will certainly remove RC4) and specifies
134 RC4-HMAC as used by Microsoft Windows in Kerberos, that should have
135 been obsoleted, not updated, by RFC 6649. RFC xxxx also obsoletes
136 RFC 4757. Additionally, MD4 is extremely weak and not
137 one-way [RFC6150] and this is another reason to move RFC 4757 to
138 Historic, as well as the myriads of other reasons specified
139 in [RFC6150].
141 RFC 6229 provides test vectors for RC4 and is obsoleted and moved to
142 Historic by this document as RC4 is deprecated in all IETF protocols.
144 3. Updates to RFC 2118
146 RFC 2118 is updated to note the obsoleting of RFC 3078 and the
147 moving of RFC 3078 to Historic (see Section 2).
149 4. Updates to RFC 3501
151 In Section 11.1 of [RFC3501], it is stated that:
153 """
154 IMAP client and server implementations MUST implement the
155 TLS_RSA_WITH_RC4_128_MD5 {TLS} cipher suite, and SHOULD implement the
156 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA {TLS} cipher suite. This is
157 important as it assures that any two compliant implementations can be
158 configured to interoperate. All other cipher suites are OPTIONAL.
159 Note that this is a change from section 2.1 of {IMAP_TLS}.
160 """
162 [[References were replaced with curly braces to avoid nits. When
163 publishing, revert back to references.]]
165 The above paragraph of [RFC3501] required that implementations of
166 IMAP clients and servers implement a RC4 cipher suite in TLS
167 (contradicts [RFC7465]) and recommends implementing a weak cipher
168 suite (DSA is not recommended by some sources and 3DES is used in
169 the suite). Unfortunately, at the time of writing of RFC 3501,
170 AES cipher suites were extremely new (the first AES cipher suites
171 were defined in RFC 3268, published in June 2002), less than 1 year
172 old and the strongest choice they have come up with at the time was
173 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
175 As the document is over 14 years old, the above paragraph of [RFC3501]
176 is replaced with the following paragraph:
178 """
179 IMAP client and server implementations were formerly required to
180 implement TLS_RSA_WITH_RC4_128_MD5 {TLS}, an extremely weak cipher
181 suite [RFC6151, RFC6649, RFC7457, RFCxxxx, RFCyyyy] that TLS clients
182 MUST NOT implement per [RFC7465]. Compatibility requirements were
183 removed in the grounds of security, and all clients and servers
184 SHOULD implement TLS 1.2 {TLS} and the
185 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 {TLS} cipher suite.
186 """
188 The TLS reference in [RFC3501] should be replaced with a reference to
189 RFC 5246, and references to RFC 6151, RFC 6649, RFC 7457, RFC 7465,
190 RFC xxxx and this document (as RFC yyyy) should be added.
192 5. Updates to RFC 3961
194 RFC 3961 is updated to note the deprecation of rc4-hmac and
195 rc4-hmac-exp (referred to in Section 8 of [RFC3961]). rc4-hmac is
196 NOT RECOMMENDED by [RFCxxxx] and rc4-hmac-exp is NOT RECOMMENDED
197 by [RFC6649].
199 6. Updates to RFC 4120
201 RFC 4120 is updated to note the deprecation of rc4-hmac and
202 rc4-hmac-exp.
204 7. Updates to RFC 4253
206 RFC 4253 is updated to note the deprecation of arcfour and 3des-cbc.
208 This document changes "OPTIONAL" to "NOT RECOMMENDED" for arcfour and
209 "REQUIRED" to "OPTIONAL" for 3des-cbc in the table of
210 Section 6.3 of [RFC4253] as 3DES is weak and maintaining the
211 requirement will compromise systems. [RFC4253] was published in 2006,
212 11 years ago, and states that """At some future time, it is expected
213 that another algorithm, one with better strength, will become so
214 prevalent and ubiquitous that the use of "3des-cbc" will be
215 deprecated by another STANDARDS ACTION."""
217 The "future time" referred to by [RFC4253] is set to 2017, the
218 "STANDARDS ACTION" is set to the publication of this document and
219 the "algorithm" is set to the Advanced Encryption Standard (AES), as
220 AES is ubiquitous in Kerberos implementations (see Section 11).
222 The paragraph on RC4 (called "arcfour" in [RFC4253]) in
223 Section 6.3 of [RFC4253] currently reads:
224 """
225 The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys.
226 The Arcfour cipher is believed to be compatible with the RC4 cipher
227 [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and
228 should be used with caution.
229 """
231 It should read:
232 """
233 The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys.
234 The Arcfour cipher is believed to be compatible with the RC4 cipher
235 [SCHNEIER]. Arcfour (and RC4) are extremely weak [RFC6649, RFC7457,
236 RFCxxxx, RFCyyyy] and therefore their use is NOT RECOMMENDED.
237 """
239 References to RFC 6649, RFC 7457, RFC xxxx and this document (the
240 reference to this document is RFCyyyy in the above paragraph) should
241 be added to Section 6.3 of [RFC4253].
243 8. Updates to RFC 6150
245 RFC 6150 moves MD4 to Historic. Note the RFC contains a typo: "MD2"
246 should be "MD4". RFC 6150 references RFC 4757, obsoleted by this
247 document, as using MD4. The expression "with the one exception of
248 Microsoft's use of MD4 as part of RC4-HMAC in Windows,", as well as
249 all expressions indicating algorithms using RC4 are a problem to the
250 deprecation of MD4, should be removed from Section 4 of [RFC6150].
252 9. Updates to RFC 6649
254 RFC 6649, also known as BCP 179, deprecates DES, RC4-HMAC-EXP and
255 other weak cryptography in Kerberos. It is updated to note the
256 deprecation of rc4-hmac and the deprecation of RC4 in all IETF
257 protocols.
259 The security considerations of [RFC6649] (Section 6 of [RFC6649])
260 read, in their last paragraph:
262 """
263 The security considerations of [RFC4757] continue to apply to
264 RC4-HMAC, including the known weaknesses of RC4 and MD4, and this
265 document does not change the Informational status of [RFC4757] for
266 now. The main reason to not actively discourage the use of RC4-HMAC
267 is that it is the only encryption type that interoperates with older
268 versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed.
269 These older versions of Microsoft Windows will likely be in use until
270 at least 2015.
271 """
273 This is updated to note that Windows XP is without official support
274 for 3 years (support for Windows XP ended 8 April 2014).
276 An important quote from [RFC6649] (Section 6 of [RFC6649]):
277 """
278 Removing support for single DES improves security because DES is
279 considered to be insecure. RC4-HMAC-EXP has a similarly inadequate
280 key size, so removing support for it also improves security.
281 """
283 10. Updates to RFC 6733
285 Section 13.1. of [RFC6733] currently reads:
286 """
287 Diameter nodes MUST be able to negotiate the following TLS/TCP and
288 DTLS/SCTP cipher suites:
290 TLS_RSA_WITH_RC4_128_MD5
291 TLS_RSA_WITH_RC4_128_SHA
292 TLS_RSA_WITH_3DES_EDE_CBC_SHA
294 Diameter nodes SHOULD be able to negotiate the following TLS/TCP and
295 DTLS/SCTP cipher suite:
297 TLS_RSA_WITH_AES_128_CBC_SHA
299 Note that it is quite possible that support for the
300 TLS_RSA_WITH_AES_128_CBC_SHA cipher suite will be REQUIRED at some
301 future date. Diameter nodes MAY negotiate other TLS/TCP and DTLS/
302 SCTP cipher suites.
303 """
305 The above paragraphs required that clients implement two RC4 cipher
306 suites and a 3DES cipher suite (but recommends implementing an AES
307 cipher suite).
309 RFC 6733 was published in October 2012, and the above paragraphs
310 of [RFC6733] are to be replaced with:
312 """
313 Diameter nodes were formerly required to implement insecure RC4
314 cipher suites and weak 3DES cipher suites. RC4 MUST NOT be used
315 because it is prohibited by RFC 7465.
317 Diameter nodes MUST support at least one of the following cipher
318 suites:
320 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
321 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
322 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
323 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
324 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
325 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
326 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
327 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
328 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
329 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
331 TLS_RSA_WITH_AES_128_CBC_SHA was not chosen to be absolutely required
332 as Diameter nodes may require all connections to use forward secrecy
333 by only implementing cipher suites with forward secrecy.
334 TLS_RSA_WITH_AES_128_CBC_SHA is not a forward secrecy cipher suite
335 because all connections can be decrypted once the private RSA key is
336 known by an attacker.
337 """
339 Several choices were given because of patent concerns with Elliptic
340 Curve Cryptography (ECC) and problems of older implementations with
341 ECC and GCM cipher suites.
343 11. Updates to RFC 7457
345 RFC 7457, an Informational RFC describing attacks against Transport
346 Layer Security (TLS) and Datagram Transport Layer Security (DTLS), is
347 updated to note the deprecation of RC4 in all IETF protocols.
349 12. Updates to RFC 7465
351 RFC 7465 prohibits RC4 cipher suites in Transport Layer Security
352 (TLS) and is updated to note the deprecation of RC4 in all IETF
353 protocols.
355 13. Updates to RFC 7905
357 RFC 7905, describing the ChaCha20-Poly1305 stream cipher to replace
358 RC4 in Transport Layer Security (TLS), is updated to note the
359 deprecation of RC4 in all IETF protocols, including TLS. [RFC7465],
360 that prohibited RC4 cipher suites, did not update RFC 7905, so this
361 document will do so.
363 14. Updates to RFC xxxx
365 RFC xxxx deprecates 3DES and RC4 in Kerberos, obsoletes RFC 4757 and
366 updates RFC 3961, and is updated by this document to note the
367 moving of RC4 RFCs (RFC 4345 and RFC 6229) and Microsoft technology
368 dependent on RC4 (RFC 3078 and RFC 4757).
370 An important quote from [RFCxxxx] (Section 5.4 of [RFCxxxx]):
371 """
372 Fortuntately, modern (i.e., supported) Kerberos implementations
373 support a secure alternative to RC4, in the form of AES. Windows has
374 supported AES since 2007-2008 with the release of Windows Vista and
375 Server 2008, respectively; MIT Kerberos [MITKRB5] has fully supported
376 AES (including the GSSAPI mechanism) since 2004 with the release of
377 version 1.3.2; Heimdal [HEIMDAL] has fully supported AES since 2005
378 with the release of version 0.7. Though there may still be issues
379 running ten-year-old unsupported software in mixed environments with
380 new software, issues of that sort seem unlikely to be unique to
381 Kerberos, and the aministrators of such environments are expected to
382 be capable of devising workarounds.
383 """
384 (note the quote contains typos: "Fortuntately" and "aministrators")
386 15. Action to be taken
388 RC4 MUST NOT be used in new implementations of IETF protocols, and
389 RC4 MUST be eliminated as fast as possible from the existing Internet
390 infrastructure, as RC4 is extremely weak [RFC6649, RFC7457, RFCxxxx].
391 New RFCs MAY use the phrase "RC4 is extremely weak [RFC6649, RFC7457,
392 RFCxxxx]" with references to RFC 6649, RFC 7457 and RFC xxxx. Whether
393 the references to these documents is normative or informative is
394 determined by BCP 9 and BCP 97, whose relevant documents for this
395 purpose are RFC 2026, RFC 3967, RFC 4897, RFC 6410 and RFC 8067.
397 Microsoft Corporation SHOULD take action to eradicate RC4 in all
398 its software and systems.
400 New IETF protocols MUST NOT allow RC4, and new versions of existing
401 IETF protocols MUST either not allow RC4 or recommend not to use RC4
402 (for example, using "NOT RECOMMENDED" or "SHOULD NOT").
404 16. IANA Considerations
406 IANA may need to take action as the status for RC4 and 3DES
407 algorithms for Secure Shell (SSH) is changed by this document
408 (see Section 6, that updates [RFC4253]).
410 17. Security Considerations
412 This document deprecates RC4, that is obsolete cryptography, and
413 several attacks that render it useless have been published [RFC6649].
414 Refer to Section 5 of [RFCxxxx] for further security considerations.
416 18. Acknowledgements
418 [[RFC-Editor: When possible, add native names according to the
419 conventions of RFC 7997.]]
421 Thanks to the following people for writing reference material:
423 * Sean Turner and Lily Chen for writing RFC 6151, that contains
424 updated security considerations for MD5 and HMAC-MD5.
426 * Love Hornquist Astrand and Tom Yu for writing RFC 6649, that
427 deprecates weak cryptographic algorithms in Kerberos.
429 * Yaron Sheffer, Ralph Holz and Peter Saint-Andre for writing
430 RFC 7457, that summarises known attacks against Transport Layer
431 Security (TLS).
433 * Andrei Popov for writing RFC 7465, that prohibits RC4 cipher
434 suites in Transport Layer Security (TLS).
436 * Julien Elie for sending me an email about the requirements to
437 implement RC4 cipher suites in RFC 3501 and RFC 6733.
439 Also thanks to SSL Labs for capping server grades to B (RC4 only used
440 with older protocols) and C (RC4 used with modern protocols) when
441 servers support RC4, and flagging cipher suites and clients using RC4
442 with a red colour (for INSECURE and RC4). You can test any server at
443 .
445 Refer to the acknowledgements section of RFC 6649, RFC 7457 and
446 RFC xxxx for further acknowledgements.
448 19. References
450 19.1. Normative References
452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
453 Requirement Levels", BCP 14, RFC 2119, March 1997.
455 [RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-
456 EXP, and Other Weak Cryptographic Algorithms in Kerberos",
457 BCP 179, RFC 6649, July 2012.
459 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
460 RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.
462 [RFCxxxx] Kaduk, B., and M. Short, "Deprecate 3DES and RC4 in
463 Kerberos", draft-ietf-curdle-des-des-des-die-die-die-03,
464 Work in Progress.
466 19.2. Informative References
468 [HEIMDAL] Heimdal Project, "Heimdal Kerberos Implementation", April
469 2017, .
471 [MITKRB5] MIT, "MIT Kerberos Implementation", March 2017,
472 .
474 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - Version
475 4rev1", RFC 3501, March 2003.
477 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
478 Kerberos 5", RFC 3961, February 2005.
480 [RFC4253] Ylonen, T., and C. Lonvick, Ed., "The Secure Shell (SSH)
481 Transport Layer Protocol", RFC 4253, January 2006.
483 [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
484 Kerberos Encryption Types Used by Microsoft Windows",
485 RFC 4757, December 2606.
487 [RFC6150] Turner, S., and L. Chen, "MD4 to Historic Status",
488 RFC 6150, March 2011.
490 [RFC6151] Turner, S., and L. Chen, "Updated Security Considerations
491 for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
492 RFC 6151, March 2011.
494 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
495 Known Attacks on Transport Layer Security (TLS) and
496 Datagram TLS (DTLS)", RFC 7457, February 2015.
498 [RFC7465] Popov, A., "Deprecating RC4 Cipher Suites", RFC 7465,
499 February 2015.
501 [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
502 protocols algorithms and source in code in C", John Wiley
503 and Sons, New York, NY, 1996.
505 [[RFC-Editor: please replace the 'i' in my name by U+00ED and the
506 first 'a' in the surname by U+00E2, as non-ASCII characters are
507 allowed as per RFC 7997]]
509 20. Author's Address
511 Luis Camara
513 EMail:
515 Appendix A. Status of Updated Documents as of 2017-06-24
517 [[RFC-Editor: Please replace with updated data when publishing as RFC
518 and replace "2017-06-24" by the date of publishing.
519 Leave the table below in a page of its own.]]
520 +----------+-----------------------+--------------------------------+
521 | RFC #### | Status | Updated by |
522 +----------+-----------------------+--------------------------------+
523 | RFC 2118 | Informational | RFC 3078 |
524 +----------+-----------------------+--------------------------------+
525 | | | RFC 4466, RFC 4469, RFC 4551, |
526 | RFC 3501 | Proposed Standard | RFC 5032, RFC 5182, RFC 5738, |
527 | | | RFC 6186, RFC 6858, RFC 7817 |
528 +----------+-----------------------+--------------------------------+
529 | RFC 3961 | Proposed Standard | RFC xxxx |
530 +----------+-----------------------+--------------------------------+
531 | | | RFC 4537, RFC 5021, RFC 5896, |
532 | RFC 4120 | Proposed Standard | RFC 6111, RFC 6112, RFC 6113, |
533 | | | RFC 6649, RFC 6806, RFC 7751, |
534 | | | RFC 8062, RFC 8129 |
535 +----------+-----------------------+--------------------------------+
536 | RFC 4253 | Proposed Standard | RFC 6668 |
537 +----------+-----------------------+--------------------------------+
538 | RFC 6150 | Informational | |
539 +----------+-----------------------+--------------------------------+
540 | RFC 6649 | Best Current Practice | |
541 | | (BCP 179) | |
542 +----------+-----------------------+--------------------------------+
543 | RFC 6733 | Proposed Standard | RFC 7075 |
544 +----------+-----------------------+--------------------------------+
545 | RFC 7457 | Informational | |
546 +----------+-----------------------+--------------------------------+
547 | RFC 7465 | Proposed Standard | |
548 +----------+-----------------------+--------------------------------+
549 | RFC 7905 | Proposed Standard | |
550 +----------+-----------------------+--------------------------------+
551 | RFC xxxx | Best Current Practice | This draft is [RFCxxxx] |
552 | | | |
553 +----------+-----------------------+--------------------------------+
555 Appendix B. Changelog
557 [[RFC-Editor: please remove this section when publishing.]]
559 02 - changed title to "Deprecating RC4 in all IETF Protocols", changed
560 the header of all pages to "Deprecating RC4 in all Protocols",
561 updated RFC 3501 and RFC 6733, simplified the reference to
562 draft-ietf-curdle-des-des-des-die-die-die to a simple "Work in
563 Progress" reference and fixed typos.
565 01 - explained reasons for updating RFC 7905 and added an informative
566 reference to RFC 4757 to take away a missing reference warning.
568 00 - first version. [RFCxxxx] is a reference to
569 draft-ietf-curdle-des-des-des-die-die-die. The quote in
570 Section 11 is from version 03 of this draft (posted 2017-06-15)