idnits 2.17.00 (12 Aug 2021) /tmp/idnits4622/draft-harris-ssh-rsa-kex-02.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 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 330. ** 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 136 has weird spacing: '... string ser...' == Line 137 has weird spacing: '... string sig...' -- 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 (July 4, 2005) is 6164 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 (~~), 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 July 4, 2005 4 Expires: January 5, 2006 6 Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH) 7 Transport Layer Protocol 8 draft-harris-ssh-rsa-kex-02 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 January 5, 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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 3. Overview 70 The RSA key-exchange method consists of three messages. First, the 71 server sends to the client an RSA public key, K_T, to which the 72 server holds the private key. This may be a transient key generated 73 solely for this SSH connection, or it may be re-used for several 74 connections. The client generates a string of random bytes, K, 75 encrypts it using K_T, and sends the result back to the server, which 76 decrypts it. The client and server each hash K, K_T, and the various 77 key-exchange parameters to generate the exchange hash, H, which is 78 used to generate the encryption keys for the session, and the server 79 signs H with its host key and sends the signature to the client. The 80 client then verifies the host key as described in [I-D.ietf-secsh- 81 transport]. 83 This method provides explicit server identification as defined in 84 section 7 of [I-D.ietf-secsh-transport]. It requires a signature- 85 capable host key. 87 4. Details 89 The RSA key exchange method has the following parameters, which are 90 defined by the method name: 92 HASH hash algorithm for calculating exchange hash etc. 93 HLEN output length of HASH in bits 94 MINKLEN minimum transient RSA modulus length in bits 96 The method uses the following messages. 98 First, the server sends: 100 byte SSH_MSG_KEXRSA_PUBKEY 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 server public host key and certificates (K_S) 137 string signature of H 139 The hash H is computed as the HASH hash of the concatenation of the 140 following: 142 string V_C, the client's version string (CR and NL excluded) 143 string V_S, the server's version string (CR and NL excluded) 144 string I_C, the payload of the client's SSH_MSG_KEXINIT 145 string I_S, the payload of the server's SSH_MSG_KEXINIT 146 string K_S, the host key 147 string K_T, the transient RSA key 148 string RSAES_OAEP_ENCRYPT(K_T, K), the encrypted secret 149 mpint K, the shared secret 151 This value is called the exchange hash, and it is used to 152 authenticate the key exchange. The exchange hash SHOULD be kept 153 secret. 155 The signature algorithm MUST be applied over H, not the original 156 data. Most signature algorithms include hashing and additional 157 padding - for example, "ssh-dss" specifies SHA-1 hashing. In that 158 case, the data is first hashed with HASH to compute H, and H is then 159 hashed with SHA-1 as part of the signing operation. 161 5. rsa1024-sha1-draft-02@putty.projects.tartarus.org 163 The "rsa1024-sha1-draft-02@putty.projects.tartarus.org" method 164 specifies RSA key exchange as described above with the following 165 parameters: 167 HASH SHA-1, as defined in [RFC3174] 168 HLEN 160 169 MINKLEN 1024 171 6. rsa2048-sha512-draft-02@putty.projects.tartarus.org 173 The "rsa2048-sha512-draft-02@putty.projects.tartarus.org" method 174 specifies RSA key exchange as described above with the following 175 parameters: 177 HASH SHA-512, as defined in [FIPS-180-2] 178 HLEN 512 179 MINKLEN 2048 181 7. Message numbers 183 The following message numbers are defined: 185 SSH_MSG_KEXRSA_PUBKEY 30 186 SSH_MSG_KEXRSA_SECRET 31 187 SSH_MSG_KEXRSA_DONE 32 189 8. Security Considerations 191 The security considerations in [I-D.ietf-secsh-architecture] apply. 193 If the RSA private key generated by the server is revealed then the 194 session key is revealed. The server should thus arrange to erase 195 this from memory as soon as it is no longer required. If the same 196 RSA key is used for multiple SSH connections, an attacker who can 197 find the private key (either by factorising the public key or by 198 other means) will gain access to all of the sessions which used that 199 key. As a result, servers SHOULD use each RSA key for as few key 200 exchanges as possible. 202 [RFC3447] recommends that RSA keys used with RSAES-OAEP not be used 203 with other schemes, or with RSAES-OAEP using a different hash 204 function. In particular, this means that K_T should not be used as a 205 host key, or as a server key in earlier versions of the SSH protocol. 207 The random data, K, generated by the client, is the only secret 208 shared by client and server, so its entropy directly determines the 209 security of the session against eavesdropping. 211 The size of transient key used should be sufficient to protect the 212 encryption and integrity keys generated by the key exchange method. 213 For recommendations on this, see [RFC3766]. The strength of RSAES- 214 OAEP is in part dependent on the hash function it uses. [RFC3447] 215 suggests using a hash with an output length of twice the security 216 level required, so SHA-1 is appropriate for applications requiring up 217 to 80 bits of security, and SHA-512 for those requiring up to 256 218 bits. 220 Unlike the Diffie-Hellman key exchange method defined by [I-D.ietf- 221 secsh-transport], this method allows the client to fully determine 222 the shared secret, K. This is believed not to be significant, since K 223 is only ever used when hashed with data provided in part by the 224 server (usually in the form of the exchange hash, H). If an 225 extension to SSH were to use K directly and to assume that it had 226 been generated by Diffie-Hellman key exchange, this could produce a 227 security weakness. Protocol extensions using K directly should be 228 viewed with extreme suspicion. 230 9. IANA Considerations 232 This document has no actions for IANA. 234 10. Acknowledgments 236 The author acknowledges the assistance of Simon Tatham with the 237 design of this key exchange method. 239 The text of this document is derived in part from [I-D.ietf-secsh- 240 transport]. 242 11. References 244 11.1 Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, March 1997. 249 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 250 (SHA1)", RFC 3174, September 2001. 252 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 253 Standards (PKCS) #1: RSA Cryptography Specifications 254 Version 2.1", RFC 3447, February 2003. 256 [I-D.ietf-secsh-architecture] 257 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 258 draft-ietf-secsh-architecture-22 (work in progress), 259 March 2005. 261 [I-D.ietf-secsh-transport] 262 Lonvick, C., "SSH Transport Layer Protocol", 263 draft-ietf-secsh-transport-24 (work in progress), 264 March 2005. 266 [FIPS-180-2] 267 National Institute of Standards and Technology (NIST), 268 "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002. 270 11.2 Informative References 272 [SSH1] Ylonen, T., "SSH -- Secure Login Connections over the 273 Internet", 6th USENIX Security Symposium, pp. 37-42, 274 July 1996. 276 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 277 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 278 RFC 3766, April 2004. 280 Author's Address 282 Ben Harris 283 37 Milton Road 284 CAMBRIDGE CB4 1XA 285 GB 287 Email: bjh21@bjh21.me.uk 289 Appendix A. On the size of K 291 The requirements on the size of K are intended to ensure that it's 292 always possible to encrypt it under K_T. The mpint encoding of K 293 requires a leading zero bit, padding to a whole number of bytes, and 294 a four-byte length field, giving a maximum length in bytes, 295 B = (KLEN-2HLEN-49+1+7)/8 + 4 = (KLEN-2HLEN-9)/8 (where "/" 296 represents integer division rounding down). 298 The maximum length of message that can be encrypted using RSAEP-OAEP 299 is defined by [RFC3447] in terms of the key length in bytes, which is 300 (KLEN+7)/8. The maximum length is thus L = (KLEN+7-2HLEN-16)/8 = 301 (KLEN-2HLEN-9)/8. Thus, the encoded version of K is always small 302 enough to be encrypted under K_T. 304 Trademark Notice 306 "SSH" is a registered trademark in the United States. 308 Intellectual Property Statement 310 The IETF takes no position regarding the validity or scope of any 311 Intellectual Property Rights or other rights that might be claimed to 312 pertain to the implementation or use of the technology described in 313 this document or the extent to which any license under such rights 314 might or might not be available; nor does it represent that it has 315 made any independent effort to identify any such rights. Information 316 on the procedures with respect to rights in RFC documents can be 317 found in BCP 78 and BCP 79. 319 Copies of IPR disclosures made to the IETF Secretariat and any 320 assurances of licenses to be made available, or the result of an 321 attempt made to obtain a general license or permission for the use of 322 such proprietary rights by implementers or users of this 323 specification can be obtained from the IETF on-line IPR repository at 324 http://www.ietf.org/ipr. 326 The IETF invites any interested party to bring to its attention any 327 copyrights, patents or patent applications, or other proprietary 328 rights that may cover technology that may be required to implement 329 this standard. Please address the information to the IETF at 330 ietf-ipr@ietf.org. 332 Disclaimer of Validity 334 This document and the information contained herein are provided on an 335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 337 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 338 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 339 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 342 Copyright Statement 344 Copyright (C) The Internet Society (2005). This document is subject 345 to the rights, licenses and restrictions contained in BCP 78, and 346 except as set forth therein, the authors retain all their rights. 348 Acknowledgment 350 Funding for the RFC Editor function is currently provided by the 351 Internet Society.