draft-ietf-curdle-rc4-die-die-die-07.txt | draft-ietf-curdle-rc4-die-die-die-08.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) L. Camara | ||||
Internet-Draft L.Velvindron | ||||
Obsoletes: 4345 (if approved) July 22, 2018 | ||||
Updates: 4253 (if approved) | ||||
Intended Status: Best Current Practice | ||||
Expires: July 22, 2018 | ||||
Deprecating RC4 in Secure Shell (SSH) | Internet Engineering Task Force L. Camara | |||
draft-ietf-curdle-rc4-die-die-die-07 | Internet-Draft | |||
Obsoletes: 4325 (if approved) L. Velvindron | ||||
Updates: 4253 (if approved) August 9, 2018 | ||||
Intended status: Best Current Practice | ||||
Expires: February 10, 2019 | ||||
[[RFC-Editor: please replace the second character of my surname by | Deprecating RC4 in Secure Shell (SSH) | |||
U+00E2 when publishing as RFC in the header and in all pages.]] | draft-ietf-curdle-rc4-die-die-die-08 | |||
Abstract | Abstract | |||
This document deprecates RC4 in Secure Shell (SSH). Therefore, this | This document deprecates RC4 in Secure Shell (SSH). Therefore, this | |||
document updates RFC 4253, and moves to Historic RFC 4345. | document updates [RFC4253], and formally obsoletes and moves to | |||
Historic [RFC4345]. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on July 30, 2018. | This Internet-Draft will expire on February 10, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Why obsolete and move to Historic RFC 4345 . . . . . . . . . . 2 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 | |||
3. Updates to RFC 4253 . . . . . . . . . . . . . . . . . . . . . . 2 | 2. Updates to RFC 4253 . . . . . . . . . . . . . . . . . . . . . 2 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 2 | 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 | 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 | |||
6. Acknowlegdements . . . . . . . . . . . . . . . . . . . . . . . 3 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . . 3 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . . 3 | 6.2. Informative References . . . . . . . . . . . . . . . . . 4 | |||
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 3 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1. Introduction | 1. Introduction | |||
The usage of RC4 suites ( also designated as arcfour ) for SSH are | The usage of RC4 suites ( also designated as arcfour ) for SSH are | |||
specified in [RFC 4253] and [RFC 4345]. [RFC 4253] specifies the | specified in [RFC4253] and [RFC4345]. [RFC4253] specifies the | |||
allocation of the "arcfour" cipher for SSH. RFC 4345 specifies and | allocation of the "arcfour" cipher for SSH. [RFC4345] specifies and | |||
allocates the the "arcfour-128" and "arcfour-256" ciphers for SSH. | allocates the the "arcfour-128" and "arcfour-256" ciphers for SSH. | |||
RC4 encryption is steadily weakening in cryptographic strength | ||||
[RFC7465] [I-D.ietf-curdle-des-des-des-die-die-die], and the | ||||
deprecation process should be begun for their use in Secure Shell | ||||
(SSH) [RFC4253]. Accordingly, [RFC4253] is updated to note the | ||||
deprecation of the RC4 ciphers and [RFC4345] is moved to Historic as | ||||
all ciphers it specifies MUST NOT be used. | ||||
RC4 encryption is steadily weakening in cryptographic strength [RFC7457] | 1.1. Requirements Language | |||
[draft-ietf-curdle-des-des-des-die-die-die-05] and the deprecation process | ||||
should be begun for their use in SSH. | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
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 | 2. Updates to RFC 4253 | |||
RFC 4345 defines the "arcfour-128" and "arcfour-256" modes for SSH, | [RFC4253] is updated to prohibit arcfour's use in SSH. [RFC4253] | |||
and is obsoleted and moved to Historic as RC4 is broken [RFC7457]. | allocates the "arcfour" cipher in Section 6.3 by defining a list of | |||
The modes defined by RFC 4345 MUST NOT be used. | defined ciphers where the "arcfour" cipher appears as optional as | |||
mentioned below: | ||||
3. Updates to RFC 4253 | +---------------+-----------------+---------------------------------+ | |||
| arcfour | OPTIONAL | the ARCFOUR stream cipher with | | ||||
| | | a 128-bit key | | ||||
+---------------+-----------------+---------------------------------+ | ||||
RFC 4253 is updated to prohibit arcfour's use in SSH. | The current document updates the status of the "arcfour" ciphers in | |||
the list of [RFC4253] Section 6.3 by moving it from OPTIONAL to MUST | ||||
NOT. | ||||
The last sentence of the paragraph on RC4 (called "arcfour" | +----------+-----------+--------------------------------------------+ | |||
in [RFC4253]) in Section 6.3 of [RFC4253] should read: "Arcfour (also | | arcfour | MUST NOT | the ARCFOUR stream cipher with a 128-bit | | |||
known as RC4) is broken [RFC7457] and therefore it MUST NOT be used." | | | | key | | |||
+----------+-----------+--------------------------------------------+ | ||||
An informative reference to RFC 7457 is to be added to [RFC4253]. | [RFC4253] defines the "arcfour" ciphers with the text mentioned | |||
below: | ||||
4. IANA Considerations | The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys. | |||
The Arcfour cipher is believed to be compatible with the RC4 cipher | ||||
[SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and | ||||
should be used with caution. | ||||
IANA may need to take action as the status for RC4 and 3DES | The current document updates [RFC4253] Section 6.3 by replacing the | |||
algorithms for Secure Shell (SSH) is changed by this document | text above with the following text: | |||
(see Section 3, that updates [RFC4253]). | ||||
5. Security Considerations | The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys. | |||
The Arcfour cipher is believed to be compatible with the RC4 cipher | ||||
[SCHNEIER]. Arcfour (and RC4) is steadily weakening in cryptographic | ||||
strength [RFC7465] [I-D.ietf-curdle-des-des-des-die-die-die], and | ||||
MUST NOT be used. | ||||
3. IANA Considerations | ||||
The IANA is requested to update the Encryption Algorithm Name | ||||
Registry of the Secure Shell (SSH) Protocol Parameters [IANA]. The | ||||
Registration procedure is IETF Review which is achieved by this | ||||
document. The registry should be updated as follows: | ||||
+-------------+------------------------------------+ | ||||
| Encryption | Algorithm Name Reference Note | | ||||
+-------------+------------------------------------+ | ||||
| arcfour | [RFC-TBD] | | ||||
| arcfour128 | [RFC-TBD] | | ||||
| arcfour256 | [RFC-TBD] | | ||||
+-------------+------------------------------------+ | ||||
Where TBD is the RFC number assigned to the document. | ||||
All drafts are required to have an IANA considerations section (see | ||||
Guidelines for Writing an IANA Considerations Section in RFCs | ||||
[RFC5226] for a guide). If the draft does not require IANA to do | ||||
anything, the section contains an explicit statement that this is the | ||||
case (as above). If there are no requirements for IANA, the section | ||||
will be removed during conversion into an RFC by the RFC Editor. | ||||
4. Acknowledgements | ||||
The authors would like to thank Daniel Migault | ||||
5. Security Considerations | ||||
This document only prohibits the use of RC4 in SSH, and introduces no | This document only prohibits the use of RC4 in SSH, and introduces no | |||
new security considerations. | new security considerations. | |||
6. Acknowledgements | 6. References | |||
Thanks to the numerous authors which have shown the weaknesses of | 6.1. Normative References | |||
RC4 throughout the years, and to the several people which have | ||||
commented on the CURDLE mailing list about this document. | ||||
7. References | [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>. | ||||
7.1. Normative References | [SCHNEIER] | |||
Schneier, B., "Applied Cryptography Second Edition: | ||||
protocols algorithms and source in code in C", , 1996, | ||||
<SCHNEIER>. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | 6.2. Informative References | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in | [I-D.ietf-curdle-des-des-des-die-die-die] | |||
RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. | Kaduk, B. and M. Short, "Deprecate 3DES and RC4 in | |||
Kerberos", draft-ietf-curdle-des-des-des-die-die-die-05 | ||||
(work in progress), September 2017. | ||||
7.2. Informative References | [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) | |||
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, | ||||
January 2006, <https://www.rfc-editor.org/info/rfc4253>. | ||||
[RFC4253] Ylonen, T., and C. Lonvick, Ed., "The Secure Shell (SSH) | [RFC4345] Harris, B., "Improved Arcfour Modes for the Secure Shell | |||
Transport Layer Protocol", RFC 4253, January 2006. | (SSH) Transport Layer Protocol", RFC 4345, | |||
DOI 10.17487/RFC4345, January 2006, | ||||
<https://www.rfc-editor.org/info/rfc4345>. | ||||
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
Known Attacks on Transport Layer Security (TLS) and | IANA Considerations Section in RFCs", RFC 5226, | |||
Datagram TLS (DTLS)", RFC 7457, February 2015. | DOI 10.17487/RFC5226, May 2008, | |||
<https://www.rfc-editor.org/info/rfc5226>. | ||||
[[RFC-Editor: please replace the 'i' in my name by U+00ED and the | [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, | |||
first 'a' in the surname by U+00E2, as non-ASCII characters are | DOI 10.17487/RFC7465, February 2015, | |||
allowed as per RFC 7997]] | <https://www.rfc-editor.org/info/rfc7465>. | |||
8. Author's Address | Authors' Addresses | |||
Luis Camara | Luis Camara | |||
EMail: <luis.camara@live.com.pt> | Email: luis.camara@live.com.pt | |||
Loganaden Velvindron | Loganaden Velvindron | |||
Mauritius | ||||
EMail: <loganaden@gmail.com> | Email: logan@hackers.mu | |||
End of changes. 37 change blocks. | ||||
70 lines changed or deleted | 126 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |