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