idnits 2.17.00 (12 Aug 2021) /tmp/idnits3943/draft-harris-ssh-rsa-kex-05.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 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 342. ** 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 99 has weird spacing: '... string ser...' == Line 135 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 (August 25, 2005) is 6112 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 273, 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) == Outdated reference: draft-ietf-secsh-architecture has been published as RFC 4251 == Outdated reference: draft-ietf-secsh-transport has been published as RFC 4253 == Outdated reference: draft-ietf-secsh-assignednumbers has been published as RFC 4250 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2' Summary: 5 errors (**), 0 flaws (~~), 9 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 August 25, 2005 4 Expires: February 26, 2006 6 Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH) 7 Transport Layer Protocol 8 draft-harris-ssh-rsa-kex-05 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 February 26, 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 3. Overview 69 The RSA key-exchange method consists of three messages. The server 70 sends to the client an RSA public key, K_T, to which the server holds 71 the private key. This may be a transient key generated solely for 72 this SSH connection, or it may be re-used for several connections. 73 The client generates a string of random bytes, K, encrypts it using 74 K_T, and sends the result back to the server, which decrypts it. The 75 client and server each hash K, K_T, and the various key-exchange 76 parameters to generate the exchange hash, H, which is used to 77 generate the encryption keys for the session, and the server signs H 78 with its host key and sends the signature to the client. The client 79 then verifies the host key as described in [I-D.ietf-secsh- 80 transport]. 82 This method provides explicit server identification as defined in 83 section 7 of [I-D.ietf-secsh-transport]. It requires a signature- 84 capable host key. 86 4. Details 87 The RSA key exchange method has the following parameters, which are 88 defined by the method name: 90 HASH hash algorithm for calculating exchange hash etc. 91 HLEN output length of HASH in bits 92 MINKLEN minimum transient RSA modulus length in bits 94 The method uses the following messages. 96 First, the server sends: 98 byte SSH_MSG_KEXRSA_PUBKEY 99 string server public host key and certificates (K_S) 100 string K_T, transient RSA public key 102 The key K_T is encoded according to the "ssh-rsa" scheme described in 103 section 6.6 of [I-D.ietf-secsh-transport]. Note that unlike an "ssh- 104 rsa" host key, K_T is only used for encryption, and not for 105 signature. The modulus of K_T MUST be at least MINKLEN bits long. 107 The client generates a random integer, K, in the range 108 0 <= K < 2^(KLEN-2HLEN-49), where KLEN is the length of the modulus 109 of K_T, in bits. The client then uses K_T to encrypt: 111 mpint K, the shared secret 113 The encryption is performed according to the RSAES-OAEP scheme of 114 [RFC3447], with a mask generation function of MGF1-with-HASH, a hash 115 of HASH, and an empty label. See Appendix A for a proof that the 116 encoding of K is always short enough to be thus encrypted. Having 117 performed the encryption, the client sends: 119 byte SSH_MSG_KEXRSA_SECRET 120 string RSAES-OAEP-ENCRYPT(K_T, K) 122 Note that the last stage of RSAES-OAEP-ENCRYPT is to encode an 123 integer as an octet-string using the I2OSP primitive of [RFC3447]. 124 This, combined with encoding the result as an SSH "string", gives a 125 result which is similar, but not identical, to the SSH "mpint" 126 encoding applied to that integer. This is the same encoding as is 127 used by "ssh-rsa" signatures in [I-D.ietf-secsh-transport]. 129 The server decrypts K. If a decryption error occurs, the server 130 SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of 131 SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect. Otherwise, 132 the server responds with: 134 byte SSH_MSG_KEXRSA_DONE 135 string signature of H with host key 137 The hash H is computed as the HASH hash of the concatenation of the 138 following: 140 string V_C, the client's version string (CR and NL excluded) 141 string V_S, the server's version string (CR and NL excluded) 142 string I_C, the payload of the client's SSH_MSG_KEXINIT 143 string I_S, the payload of the server's SSH_MSG_KEXINIT 144 string K_S, the host key 145 string K_T, the transient RSA key 146 string RSAES_OAEP_ENCRYPT(K_T, K), the encrypted secret 147 mpint K, the shared secret 149 This value is called the exchange hash, and it is used to 150 authenticate the key exchange. The exchange hash SHOULD be kept 151 secret. 153 The signature algorithm MUST be applied over H, not the original 154 data. Most signature algorithms include hashing and additional 155 padding. For example, "ssh-dss" specifies SHA-1 hashing. In such 156 cases, the data is first hashed with HASH to compute H, and H is then 157 hashed again as part of the signing operation. 159 5. rsa1024-sha1 161 The "rsa1024-sha1" method specifies RSA key exchange as described 162 above with the following parameters: 164 HASH SHA-1, as defined in [RFC3174] 165 HLEN 160 166 MINKLEN 1024 168 6. rsa2048-sha256 170 The "rsa2048-sha256" method specifies RSA key exchange as described 171 above with the following parameters: 173 HASH SHA-256, as defined in [FIPS-180-2] 174 HLEN 256 175 MINKLEN 2048 177 7. Message numbers 179 The following message numbers are defined: 181 SSH_MSG_KEXRSA_PUBKEY 30 182 SSH_MSG_KEXRSA_SECRET 31 183 SSH_MSG_KEXRSA_DONE 32 185 8. Security Considerations 187 The security considerations in [I-D.ietf-secsh-architecture] apply. 189 If the RSA private key generated by the server is revealed then the 190 session key is revealed. The server should thus arrange to erase 191 this from memory as soon as it is no longer required. If the same 192 RSA key is used for multiple SSH connections, an attacker who can 193 find the private key (either by factorising the public key or by 194 other means) will gain access to all of the sessions which used that 195 key. As a result, servers SHOULD use each RSA key for as few key 196 exchanges as possible. 198 [RFC3447] recommends that RSA keys used with RSAES-OAEP not be used 199 with other schemes, or with RSAES-OAEP using a different hash 200 function. In particular, this means that K_T should not be used as a 201 host key, or as a server key in earlier versions of the SSH protocol. 203 K, the random integer generated by the client, is the only secret 204 shared by client and server. Thus its entropy directly determines 205 the security of the session against eavesdropping. 207 The size of transient key used should be sufficient to protect the 208 encryption and integrity keys generated by the key exchange method. 209 For recommendations on this, see [RFC3766]. The strength of RSAES- 210 OAEP is in part dependent on the hash function it uses. [RFC3447] 211 suggests using a hash with an output length of twice the security 212 level required, so SHA-1 is appropriate for applications requiring up 213 to 80 bits of security, and SHA-512 for those requiring up to 256 214 bits. 216 Unlike the Diffie-Hellman key exchange method defined by [I-D.ietf- 217 secsh-transport], this method allows the client to fully determine 218 the shared secret, K. This is believed not to be significant, since K 219 is only ever used when hashed with data provided in part by the 220 server (usually in the form of the exchange hash, H). If an 221 extension to SSH were to use K directly and to assume that it had 222 been generated by Diffie-Hellman key exchange, this could produce a 223 security weakness. Protocol extensions using K directly should be 224 viewed with extreme suspicion. 226 This key-exchange method is designed to be resistant to collision 227 attacks on the exchange hash, by ensuring that neither side is able 228 to freely choose its input to the hash after seeing all of the other 229 side's input. The server's last input is in SSH_MSG_KEXRSA_PUBKEY, 230 before it has seen the client's choice of K. The client's last input 231 is K and its RSA encryption, and the one-way nature of RSA encryption 232 should ensure that the client cannot choose K so as to cause a 233 collision. 235 9. IANA Considerations 237 IANA should assign the names "rsa1024-sha1" and "rsa2048-sha256" as 238 Key Exchange Method Names in accordance with [I-D.ietf-secsh- 239 assignednumbers]. 241 10. Acknowledgments 243 The author acknowledges the assistance of Simon Tatham with the 244 design of this key exchange method. 246 The text of this document is derived in part from [I-D.ietf-secsh- 247 transport]. 249 11. References 251 11.1. Normative References 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 257 (SHA1)", RFC 3174, September 2001. 259 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 260 Standards (PKCS) #1: RSA Cryptography Specifications 261 Version 2.1", RFC 3447, February 2003. 263 [I-D.ietf-secsh-architecture] 264 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 265 draft-ietf-secsh-architecture-22 (work in progress), 266 March 2005. 268 [I-D.ietf-secsh-transport] 269 Lonvick, C., "SSH Transport Layer Protocol", 270 draft-ietf-secsh-transport-24 (work in progress), 271 March 2005. 273 [I-D.ietf-secsh-assignednumbers] 274 Lehtinen, S. and C. Lonvick, "SSH Protocol Assigned 275 Numbers", draft-ietf-secsh-assignednumbers-12 (work in 276 progress), March 2005. 278 [FIPS-180-2] 279 National Institute of Standards and Technology (NIST), 280 "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002. 282 11.2. Informative References 284 [SSH1] Ylonen, T., "SSH -- Secure Login Connections over the 285 Internet", 6th USENIX Security Symposium, pp. 37-42, 286 July 1996. 288 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 289 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 290 RFC 3766, April 2004. 292 Appendix A. On the size of K 294 The requirements on the size of K are intended to ensure that it is 295 always possible to encrypt it under K_T. The mpint encoding of K 296 requires a leading zero bit, padding to a whole number of bytes, and 297 a four-byte length field, giving a maximum length in bytes, 298 B = (KLEN-2HLEN-49+1+7)/8 + 4 = (KLEN-2HLEN-9)/8 (where "/" 299 represents integer division rounding down). 301 The maximum length of message that can be encrypted using RSAEP-OAEP 302 is defined by [RFC3447] in terms of the key length in bytes, which is 303 (KLEN+7)/8. The maximum length is thus L = (KLEN+7-2HLEN-16)/8 = 304 (KLEN-2HLEN-9)/8. Thus, the encoded version of K is always small 305 enough to be encrypted under K_T. 307 Trademark Notice 309 "SSH" is a registered trademark in the United States. 311 Author's Address 313 Ben Harris 314 37 Milton Road 315 CAMBRIDGE CB4 1XA 316 GB 318 Email: bjh21@bjh21.me.uk 320 Intellectual Property Statement 322 The IETF takes no position regarding the validity or scope of any 323 Intellectual Property Rights or other rights that might be claimed to 324 pertain to the implementation or use of the technology described in 325 this document or the extent to which any license under such rights 326 might or might not be available; nor does it represent that it has 327 made any independent effort to identify any such rights. Information 328 on the procedures with respect to rights in RFC documents can be 329 found in BCP 78 and BCP 79. 331 Copies of IPR disclosures made to the IETF Secretariat and any 332 assurances of licenses to be made available, or the result of an 333 attempt made to obtain a general license or permission for the use of 334 such proprietary rights by implementers or users of this 335 specification can be obtained from the IETF on-line IPR repository at 336 http://www.ietf.org/ipr. 338 The IETF invites any interested party to bring to its attention any 339 copyrights, patents or patent applications, or other proprietary 340 rights that may cover technology that may be required to implement 341 this standard. Please address the information to the IETF at 342 ietf-ipr@ietf.org. 344 Disclaimer of Validity 346 This document and the information contained herein are provided on an 347 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 348 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 349 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 350 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 351 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 352 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 354 Copyright Statement 356 Copyright (C) The Internet Society (2005). This document is subject 357 to the rights, licenses and restrictions contained in BCP 78, and 358 except as set forth therein, the authors retain all their rights. 360 Acknowledgment 362 Funding for the RFC Editor function is currently provided by the 363 Internet Society.