idnits 2.17.1 draft-harris-ssh-arcfour-fixes-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 187. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 200. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 2005) is 6883 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-secsh-assignednumbers' is defined on line 131, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-secsh-newmodes-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'SCHNEIER' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Harris 3 Internet-Draft June 2005 4 Expires: December 3, 2005 6 Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer 7 Protocol 8 draft-harris-ssh-arcfour-fixes-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 3, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document specifies methods of using the Arcfour cipher in the 42 Secure Shell (SSH) protocol which mitigate the weakness of the 43 cipher's key-scheduling algorithm. 45 1. Introduction 47 Secure Shell (SSH) [I-D.ietf-secsh-architecture] is a secure remote- 48 login protocol. It allows for the use of an extensible variety of 49 symmetric cipher algorithms to provide confidentiality for data in 50 transit. One of the algorithms specified in the base protocol is 51 "arcfour", which specifies the use of Arcfour (also known as RC4), a 52 fast stream cipher. As [I-D.ietf-secsh-transport] says, though, 53 "Arcfour (and RC4) has problems with weak keys, and should be used 54 with caution." These problems are described in more detail in 55 [MANTIN01], along with a recommendation to discard the first 1536 56 bytes of keystream so as to ensure that the cipher's internal state 57 is thoroughly mixed. This document specifies new cipher algorithms 58 for SSH which follow this recommendation. 60 2. Conventions Used in this Document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 3. Applicability Statement 68 Implementations of Arcfour are typically slightly faster and much 69 smaller than those of any other encryption algorithm currently 70 defined for SSH. This must be balanced, though, against the known 71 security problems with Arcfour described in Section 5. In most 72 cases, where speed and code size aren't critical issues, the 73 algorithms specified by [I-D.ietf-secsh-newmodes] should be used 74 instead. 76 4. Algorithm Definitions 78 The "arcfour128" algorithm is the RC4 cipher as described in 79 [SCHNEIER], using a 128-bit key. The first 1536 bytes of keystream 80 generated by the cipher MUST be discarded, with the first byte of the 81 first encrypted packet being encrypted using the 1537th byte of 82 keystream. 84 The "arcfour256" algorithm is the same, but using a 256-bit key. 86 5. Security Considerations 88 The security considerations in [I-D.ietf-secsh-architecture] apply. 90 The discarded bytes of keystream MUST be kept secret and MUST NOT be 91 transmitted over the network. The contents of these bytes could 92 reveal information about the key. 94 There are two classes of attack on Arcfour described in [MIRINOV]. 95 Strong distinguishers distinguish an Arcfour keystream from 96 randomness given the start of the stream, and are defended against by 97 the algorithm defined in this document. Weak distinguishers can 98 operate on any part of the keystream, and the best ones, described in 99 [FMcG] and [MANTIN05], can use data from multiple different 100 keystreams. A consequence of this is that encrypting the same data 101 (for instance, a password) sufficiently many times in separate 102 Arcfour keystreams can be sufficient to leak information about it to 103 an adversary. It is thus RECOMMENDED that Arcfour (either in the 104 form described here or that described in [I-D.ietf-secsh- 105 architecture]) not be used for high-volume password-authenticated 106 connections. 108 6. IANA Considerations 110 IANA is requested to assign the Encryption Algorithm Names 111 "arcfour128" and "arcfour256" in accordance with [I-D.ietf-secsh- 112 assignednumbers]. 114 7. References 116 7.1 Normative References 118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 119 Requirement Levels", BCP 14, RFC 2119, March 1997. 121 [I-D.ietf-secsh-architecture] 122 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 123 draft-ietf-secsh-architecture-22 (work in progress), 124 March 2005. 126 [I-D.ietf-secsh-transport] 127 Lonvick, C., "SSH Transport Layer Protocol", 128 draft-ietf-secsh-transport-24 (work in progress), 129 March 2005. 131 [I-D.ietf-secsh-assignednumbers] 132 Lehtinen, S. and C. Lonvick, "SSH Protocol Assigned 133 Numbers", draft-ietf-secsh-assignednumbers-12 (work in 134 progress), March 2005. 136 [I-D.ietf-secsh-newmodes] 137 Bellare, M., "SSH Transport Layer Encryption Modes", 138 draft-ietf-secsh-newmodes-04 (work in progress), 139 April 2005. 141 [SCHNEIER] 142 Schneier, B., "Applied Cryptography Second Edition: 143 protocols algorithms and source in code in C", John Wiley 144 and Sons, New York, NY, 1996. 146 7.2 Informative References 148 [FMcG] Fluhrer, S. and D. McGrew, "Statistical Analysis of the 149 Alleged RC4 Keystream Generator", The Proceedings of the 150 Fast Software Encryption Workshop 2000, 2000, 151 . 153 [MANTIN01] 154 Mantin, I., "Analysis of the Stream Cipher RC4", M.Sc. 155 Thesis, Weizmann Institute of Science, 2001, . 158 [MIRINOV] Mirinov, I., "(Not So) Random Shuffles of RC4", 159 CRYPTO 2002, 2002. 161 [MANTIN05] 162 Mantin, I., "Predicting and Distinguishing Attacks on RC4 163 Keystream Generator", EUROCRYPT 2005, 2005. 165 Author's Address 167 Ben Harris 168 37 Milton Road 169 CAMBRIDGE CB4 1XA 170 GB 172 Email: bjh21@bjh21.me.uk 174 Trademark notice 176 "RC4" and "SSH" are registered trademarks in the United States. 178 Intellectual Property Statement 180 The IETF takes no position regarding the validity or scope of any 181 Intellectual Property Rights or other rights that might be claimed to 182 pertain to the implementation or use of the technology described in 183 this document or the extent to which any license under such rights 184 might or might not be available; nor does it represent that it has 185 made any independent effort to identify any such rights. Information 186 on the procedures with respect to rights in RFC documents can be 187 found in BCP 78 and BCP 79. 189 Copies of IPR disclosures made to the IETF Secretariat and any 190 assurances of licenses to be made available, or the result of an 191 attempt made to obtain a general license or permission for the use of 192 such proprietary rights by implementers or users of this 193 specification can be obtained from the IETF on-line IPR repository at 194 http://www.ietf.org/ipr. 196 The IETF invites any interested party to bring to its attention any 197 copyrights, patents or patent applications, or other proprietary 198 rights that may cover technology that may be required to implement 199 this standard. Please address the information to the IETF at 200 ietf-ipr@ietf.org. 202 Disclaimer of Validity 204 This document and the information contained herein are provided on an 205 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 206 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 207 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 208 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 209 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 210 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 212 Copyright Statement 214 Copyright (C) The Internet Society (2005). This document is subject 215 to the rights, licenses and restrictions contained in BCP 78, and 216 except as set forth therein, the authors retain all their rights. 218 Acknowledgment 220 Funding for the RFC Editor function is currently provided by the 221 Internet Society.