Internet Engineering Task Force (IETF) L. Camara Internet-Draft January10,26, 2018 Obsoletes: 4345 (if approved) Updates: 4253 (if approved) Intended Status: Best Current Practice Expires: July14,30, 2018DepreciatingDeprecating RC4 in Secure Shell (SSH)draft-ietf-curdle-rc4-die-die-die-05draft-ietf-curdle-rc4-die-die-die-06 [[RFC-Editor: please replace the second character of my surname by U+00E2 when publishing as RFC in the header and in all pages. Non-ASCII characters are allowed in RFCs as per RFC 7997.]] Abstract This documentdepreciatesdeprecates RC4 in Secure Shell (SSH). Therefore, this document updates RFC 4253, and formally obsoletes and moves to Historic RFC 4345. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July14,30, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Why obsolete and move to Historic RFC 4345 . . . . . . . . . . 2 3. Updates to RFC 4253 . . . . . . . . . . . . . . . . . . . . . . 2 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 2 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 6. Acknowlegdements . . . . . . . . . . . . . . . . . . . . . . . 3 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 3 7.2. Informative References . . . . . . . . . . . . . . . . . . . 3 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .43 1. Introduction RC4 isextremely weak [RFC6649]broken [RFC7457][RFC7465]and this documentdepreciatesdeprecates its use inall IETF protocols, including Kerberos andSecure Shell (SSH). Thereasons for obsoleting RFC 4345 are discussed in Section 2. The updates to RFC 4253 and the reasons for doing them are specified in Section 3. Thekey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119, RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Why obsolete and move to Historic RFC 4345 RFC 4345 defines the "arcfour-128" and "arcfour-256" modes forSecure Shell (SSH),SSH, and is obsoleted and moved to Historic as RC4 isextremely weak [RFC6649, RFC7457] and there is research that is at least 5 years old that totally breaks all practical usage of RC4 [RFC6649].broken [RFC7457]. The modes defined by RFC 4345 MUST NOT be used. 3. Updates to RFC 4253 RFC 4253 is updated tonote the depreciation of arcfour.prohibit arcfour's use in SSH. The last sentence of the paragraph on RC4 (called "arcfour" in [RFC4253]) in Section 6.3 of [RFC4253] should read: "Arcfour(and(also known as RC4)are extremely weakis broken [RFC7457] and therefore it MUST NOT be used." An informative reference to RFC 7457 is to be added to [RFC4253]. 4. IANA Considerations IANA may need to take action as the status for RC4 and 3DES algorithms for Secure Shell (SSH) is changed by this document (see Section 3, that updates [RFC4253]). 5. Security Considerations This documentdepreciates RC4, that is obsolete cryptography,only prohibits the use of RC4 in SSH, andseveral attacks that render it useless have been published published [RFC6649] [RFC7457] [RFC7465].introduces no new security considerations. 6. Acknowledgements Thanks to the numerous authors which have shown the weaknesses of RC4 throughout theyears.years, and to the several people which have commented on the CURDLE mailing list about this document. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. 7.2. Informative References [RFC4253] Ylonen, T., and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.[RFC6151] Turner, S., and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011. [RFC6649] Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC- EXP, and Other Weak Cryptographic Algorithms in Kerberos", BCP 179, RFC 6649, July 2012.[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, February 2015.[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, February 2015. [RFCxxxx] Kaduk, B., and M. Short, "Deprecate 3DES and RC4 in Kerberos", draft-ietf-curdle-des-des-des-die-die-die-05, Work in Progress.[[RFC-Editor: please replace the 'i' in my name by U+00ED and the first 'a' in the surname by U+00E2, as non-ASCII characters are allowed as per RFC 7997]]11.8. Author's Address Luis Camara EMail: <luis.camara@live.com.pt>