idnits 2.17.1 draft-harris-ssh-rsa-kex-06.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 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. ** 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 == Line 108 has weird spacing: '... string ser...' == Line 144 has weird spacing: '... string sig...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 19, 2005) is 6697 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 289, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2' Summary: 5 errors (**), 0 flaws (~~), 6 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 December 19, 2005 4 Expires: June 22, 2006 6 Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH) 7 Transport Layer Protocol 8 draft-harris-ssh-rsa-kex-06 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 June 22, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This memo describes a key-exchange method for the Secure Shell (SSH) 42 protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. 43 It uses much less client CPU time than the Diffie-Hellman algorithm 44 specified as part of the core protocol, and hence is particularly 45 suitable for slow client systems. 47 1. Introduction 49 Secure Shell (SSH) [I-D.ietf-secsh-architecture] is a secure remote- 50 login protocol. The core protocol uses Diffie-Hellman key exchange. 51 On slow CPUs, this key exchange can take tens of seconds to complete, 52 which can be irritating for the user. A previous version of the SSH 53 protocol, described in [SSH1] uses a key-exchange method based on 54 Rivest-Shamir-Adleman (RSA) public-key encryption, which consumes an 55 order of magnitude less CPU time on the client, and hence is 56 particularly suitable for slow client systems such as mobile devices. 57 This memo describes a key-exchange mechanism for the version of SSH 58 described in [I-D.ietf-secsh-architecture] which is similar to that 59 used by the older version, and about as fast, while retaining the 60 security advantages of the newer protocol. 62 2. Conventions Used in this Document 64 The key words "MUST" and "SHOULD" in this document are to be 65 interpreted as described in [RFC2119]. 67 The data types "byte", "string", and "mpint" are defined in section 5 68 of [I-D.ietf-secsh-architecture]. 70 Other terminology and symbols have the same meaning as in [I-D.ietf- 71 secsh-transport]. 73 3. Overview 75 The RSA key-exchange method consists of three messages. The server 76 sends to the client an RSA public key, K_T, to which the server holds 77 the private key. This may be a transient key generated solely for 78 this SSH connection, or it may be re-used for several connections. 79 The client generates a string of random bytes, K, encrypts it using 80 K_T, and sends the result back to the server, which decrypts it. The 81 client and server each hash K, K_T, and the various key-exchange 82 parameters to generate the exchange hash, H, which is used to 83 generate the encryption keys for the session, and the server signs H 84 with its host key and sends the signature to the client. The client 85 then verifies the host key as described in section 8 of [I-D.ietf- 86 secsh-transport]. 88 This method provides explicit server identification as defined in 89 section 7 of [I-D.ietf-secsh-transport]. It requires a signature- 90 capable host key. 92 4. Details 94 The RSA key exchange method has the following parameters: 96 HASH hash algorithm for calculating exchange hash etc. 97 HLEN output length of HASH in bits 98 MINKLEN minimum transient RSA modulus length in bits 100 Their values are defined in Section 5 and Section 6 for the two 101 methods defined by this document. 103 The method uses the following messages. 105 First, the server sends: 107 byte SSH_MSG_KEXRSA_PUBKEY 108 string server public host key and certificates (K_S) 109 string K_T, transient RSA public key 111 The key K_T is encoded according to the "ssh-rsa" scheme described in 112 section 6.6 of [I-D.ietf-secsh-transport]. Note that unlike an "ssh- 113 rsa" host key, K_T is only used for encryption, and not for 114 signature. The modulus of K_T MUST be at least MINKLEN bits long. 116 The client generates a random integer, K, in the range 117 0 <= K < 2^(KLEN-2*HLEN-49), where KLEN is the length of the modulus 118 of K_T, in bits. The client then uses K_T to encrypt: 120 mpint K, the shared secret 122 The encryption is performed according to the RSAES-OAEP scheme of 123 [RFC3447], with a mask generation function of MGF1-with-HASH, a hash 124 of HASH, and an empty label. See Appendix A for a proof that the 125 encoding of K is always short enough to be thus encrypted. Having 126 performed the encryption, the client sends: 128 byte SSH_MSG_KEXRSA_SECRET 129 string RSAES-OAEP-ENCRYPT(K_T, K) 131 Note that the last stage of RSAES-OAEP-ENCRYPT is to encode an 132 integer as an octet-string using the I2OSP primitive of [RFC3447]. 133 This, combined with encoding the result as an SSH "string", gives a 134 result which is similar, but not identical, to the SSH "mpint" 135 encoding applied to that integer. This is the same encoding as is 136 used by "ssh-rsa" signatures in [I-D.ietf-secsh-transport]. 138 The server decrypts K. If a decryption error occurs, the server 139 SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of 140 SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect. Otherwise, 141 the server responds with: 143 byte SSH_MSG_KEXRSA_DONE 144 string signature of H with host key 146 The hash H is computed as the HASH hash of the concatenation of the 147 following: 149 string V_C, the client's identification string 150 (CR and LF excluded) 151 string V_S, the server's identification string 152 (CR and LF excluded) 153 string I_C, the payload of the client's SSH_MSG_KEXINIT 154 string I_S, the payload of the server's SSH_MSG_KEXINIT 155 string K_S, the host key 156 string K_T, the transient RSA key 157 string RSAES_OAEP_ENCRYPT(K_T, K), the encrypted secret 158 mpint K, the shared secret 160 This value is called the exchange hash, and it is used to 161 authenticate the key exchange. The exchange hash SHOULD be kept 162 secret. 164 The signature algorithm MUST be applied over H, not the original 165 data. Most signature algorithms include hashing and additional 166 padding. For example, "ssh-dss" specifies SHA-1 hashing. In such 167 cases, the data is first hashed with HASH to compute H, and H is then 168 hashed again as part of the signing operation. 170 5. rsa1024-sha1 172 The "rsa1024-sha1" method specifies RSA key exchange as described 173 above with the following parameters: 175 HASH SHA-1, as defined in [RFC3174] 176 HLEN 160 177 MINKLEN 1024 179 6. rsa2048-sha256 181 The "rsa2048-sha256" method specifies RSA key exchange as described 182 above with the following parameters: 184 HASH SHA-256, as defined in [FIPS-180-2] 185 HLEN 256 186 MINKLEN 2048 188 7. Message numbers 190 The following message numbers are defined: 192 SSH_MSG_KEXRSA_PUBKEY 30 193 SSH_MSG_KEXRSA_SECRET 31 194 SSH_MSG_KEXRSA_DONE 32 196 8. Security Considerations 198 The security considerations in [I-D.ietf-secsh-architecture] apply. 200 If the RSA private key generated by the server is revealed then the 201 session key is revealed. The server should thus arrange to erase 202 this from memory as soon as it is no longer required. If the same 203 RSA key is used for multiple SSH connections, an attacker who can 204 find the private key (either by factorising the public key or by 205 other means) will gain access to all of the sessions which used that 206 key. As a result, servers SHOULD use each RSA key for as few key 207 exchanges as possible. 209 [RFC3447] recommends that RSA keys used with RSAES-OAEP not be used 210 with other schemes, or with RSAES-OAEP using a different hash 211 function. In particular, this means that K_T should not be used as a 212 host key, or as a server key in earlier versions of the SSH protocol. 214 Like all key-exchange mechanisms, this one depends for its security 215 on the randomness of the secrets generated by the client (the random 216 number K) and the server (the transient RSA private key). In 217 particular, it is essential that the client use a high-quality 218 cryptographic pseudo-random number generator to generate K. Using a 219 bad random number generator will allow an attacker to break all the 220 encryption and integrity protection of the Secure Shell transport 221 layer. See [RFC4086] for recommendations on random-number generation 223 The size of transient key used should be sufficient to protect the 224 encryption and integrity keys generated by the key exchange method. 226 For recommendations on this, see [RFC3766]. The strength of RSAES- 227 OAEP is in part dependent on the hash function it uses. [RFC3447] 228 suggests using a hash with an output length of twice the security 229 level required, so SHA-1 is appropriate for applications requiring up 230 to 80 bits of security, and SHA-256 for those requiring up to 128 231 bits. 233 Unlike the Diffie-Hellman key exchange method defined by [I-D.ietf- 234 secsh-transport], this method allows the client to fully determine 235 the shared secret, K. This is believed not to be significant, since K 236 is only ever used when hashed with data provided in part by the 237 server (usually in the form of the exchange hash, H). If an 238 extension to SSH were to use K directly and to assume that it had 239 been generated by Diffie-Hellman key exchange, this could produce a 240 security weakness. Protocol extensions using K directly should be 241 viewed with extreme suspicion. 243 This key-exchange method is designed to be resistant to collision 244 attacks on the exchange hash, by ensuring that neither side is able 245 to freely choose its input to the hash after seeing all of the other 246 side's input. The server's last input is in SSH_MSG_KEXRSA_PUBKEY, 247 before it has seen the client's choice of K. The client's last input 248 is K and its RSA encryption, and the one-way nature of RSA encryption 249 should ensure that the client cannot choose K so as to cause a 250 collision. 252 9. IANA Considerations 254 IANA should assign the names "rsa1024-sha1" and "rsa2048-sha256" as 255 Key Exchange Method Names in accordance with [I-D.ietf-secsh- 256 assignednumbers]. 258 10. Acknowledgments 260 The author acknowledges the assistance of Simon Tatham with the 261 design of this key exchange method. 263 The text of this document is derived in part from [I-D.ietf-secsh- 264 transport]. 266 11. References 267 11.1. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 273 (SHA1)", RFC 3174, September 2001. 275 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 276 Standards (PKCS) #1: RSA Cryptography Specifications 277 Version 2.1", RFC 3447, February 2003. 279 [I-D.ietf-secsh-architecture] 280 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 281 draft-ietf-secsh-architecture-22 (work in progress), 282 March 2005. 284 [I-D.ietf-secsh-transport] 285 Lonvick, C., "SSH Transport Layer Protocol", 286 draft-ietf-secsh-transport-24 (work in progress), 287 March 2005. 289 [I-D.ietf-secsh-assignednumbers] 290 Lehtinen, S. and C. Lonvick, "SSH Protocol Assigned 291 Numbers", draft-ietf-secsh-assignednumbers-12 (work in 292 progress), March 2005. 294 [FIPS-180-2] 295 National Institute of Standards and Technology (NIST), 296 "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002. 298 11.2. Informative References 300 [SSH1] Ylonen, T., "SSH -- Secure Login Connections over the 301 Internet", 6th USENIX Security Symposium, pp. 37-42, 302 July 1996. 304 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 305 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 306 RFC 3766, April 2004. 308 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 309 Requirements for Security", BCP 106, RFC 4086, June 2005. 311 Appendix A. On the size of K 313 The requirements on the size of K are intended to ensure that it is 314 always possible to encrypt it under K_T. The mpint encoding of K 315 requires a leading zero bit, padding to a whole number of bytes, and 316 a four-byte length field, giving a maximum length in bytes, 317 B = (KLEN-2*HLEN-49+1+7)/8 + 4 = (KLEN-2*HLEN-9)/8 (where "/" 318 represents integer division rounding down). 320 The maximum length of message that can be encrypted using RSAEP-OAEP 321 is defined by [RFC3447] in terms of the key length in bytes, which is 322 (KLEN+7)/8. The maximum length is thus L = (KLEN+7-2*HLEN-16)/8 = 323 (KLEN-2*HLEN-9)/8. Thus, the encoded version of K is always small 324 enough to be encrypted under K_T. 326 Trademark Notice 328 "SSH" is a registered trademark in the United States. 330 Author's Address 332 Ben Harris 333 2a Eachard Road 334 CAMBRIDGE CB4 1XA 335 GB 337 Email: a7250@bjh21.me.uk 339 Intellectual Property Statement 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed to 343 pertain to the implementation or use of the technology described in 344 this document or the extent to which any license under such rights 345 might or might not be available; nor does it represent that it has 346 made any independent effort to identify any such rights. Information 347 on the procedures with respect to rights in RFC documents can be 348 found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use of 353 such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository at 355 http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention any 358 copyrights, patents or patent applications, or other proprietary 359 rights that may cover technology that may be required to implement 360 this standard. Please address the information to the IETF at 361 ietf-ipr@ietf.org. 363 Disclaimer of Validity 365 This document and the information contained herein are provided on an 366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 368 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 369 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 370 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 373 Copyright Statement 375 Copyright (C) The Internet Society (2005). This document is subject 376 to the rights, licenses and restrictions contained in BCP 78, and 377 except as set forth therein, the authors retain all their rights. 379 Acknowledgment 381 Funding for the RFC Editor function is currently provided by the 382 Internet Society.