idnits 2.17.00 (12 Aug 2021) /tmp/idnits5236/draft-harris-ssh-rsa-kex-01.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages 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 128 has weird spacing: '... string ser...' == Line 129 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 (March 17, 2005) is 6273 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: 7 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Harris 2 Internet-Draft March 17, 2005 3 Expires: September 18, 2005 5 RSA key exchange for the SSH Transport Layer Protocol 6 draft-harris-ssh-rsa-kex-01.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 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 20 Internet-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 September 18, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This memo describes an RSA-based key-exchange method for the SSH 42 protocol. It uses much less client CPU time than the Diffie-Hellman 43 algorithm specified as part of the core protocol, and hence is 44 particularly suitable for slow client systems. 46 1. Introduction 48 Secure Shell (SSH) [I-D.ietf-secsh-architecture] is a secure 49 remote-login protocol. The core protocol uses Diffie-Hellman key 50 exchange. On slow CPUs, this key exchange can take tens of seconds 51 to complete, which can be irritating for the user. A previous 52 version of the SSH protocol, described in [SSH1] uses an RSA-based 53 key exchange method, which consumes an order of magnitude less CPU 54 time on the client, and hence is particularly suitable for slow 55 client systems such as mobile devices. This memo describes a 56 key-exchange mechanism for the version of SSH described in 57 [I-D.ietf-secsh-architecture] which is similar to that used by the 58 older version, and about as fast, while retaining the security 59 advantages of the newer protocol. 61 2. Conventions Used in this Document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 3. Overview 69 The RSA key-exchange method consists of three messages. First, the 70 server sends to the client an RSA public key, K_T, to which the 71 server holds the private key. This may be a transient key generated 72 solely for this SSH connection, or it may be re-used for several 73 connections. The client generates a string of random bytes, K, 74 encrypts it using K_T, and sends the result back to the server, which 75 decrypts it. The client and server each hash K, K_T, and the various 76 key-exchange parameters to generate the exchange hash, H, which is 77 used to generate the encryption keys for the session, and the server 78 signs H with its host key and sends the signature to the client. The 79 client then verifies the host key as described in 80 [I-D.ietf-secsh-transport]. 82 This method provides explicit server identification as defined in 83 section 7 of [I-D.ietf-secsh-transport]. It requires a 84 signature-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 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 104 "ssh-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 The server decrypts K. If a decryption error occurs, the server 123 SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of 124 SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect. Otherwise, 125 the server responds with: 127 byte SSH_MSG_KEXRSA_DONE 128 string server public host key and certificates (K_S) 129 string signature of H 131 The hash H is computed as the HASH hash of the concatenation of the 132 following: 134 string V_C, the client's version string (CR and NL excluded) 135 string V_S, the server's version string (CR and NL excluded) 136 string I_C, the payload of the client's SSH_MSG_KEXINIT 137 string I_S, the payload of the server's SSH_MSG_KEXINIT 138 string K_S, the host key 139 string K_T, the transient RSA key 140 mpint K, the shared secret 142 This value is called the exchange hash, and it is used to 143 authenticate the key exchange. The exchange hash SHOULD be kept 144 secret. 146 The signature algorithm MUST be applied over H, not the original 147 data. Most signature algorithms include hashing and additional 148 padding - for example, "ssh-dss" specifies SHA-1 hashing. In that 149 case, the data is first hashed with HASH to compute H, and H is then 150 hashed with SHA-1 as part of the signing operation. 152 5. rsa1024-sha1-draft-01@putty.projects.tartarus.org 154 The "rsa1024-sha1-draft-01@putty.projects.tartarus.org" method 155 specifies RSA key exchange as described above with the following 156 parameters: 158 HASH SHA-1, as defined in [RFC3174] 159 HLEN 160 160 MINKLEN 1024 162 6. rsa2048-sha256-draft-01@putty.projects.tartarus.org 164 The "rsa1024-sha256-draft-01@putty.projects.tartarus.org" method 165 specifies RSA key exchange as described above with the following 166 parameters: 168 HASH SHA-256, as defined in [FIPS-180-2] 169 HLEN 256 170 MINKLEN 2048 172 7. Message numbers 174 The following message numbers are defined: 176 SSH_MSG_KEXRSA_PUBKEY 30 177 SSH_MSG_KEXRSA_SECRET 31 178 SSH_MSG_KEXRSA_DONE 32 180 Note that Numbers 30-49 are used for kex packets. Different kex 181 methods may reuse message numbers in this range. 183 8. Security Considerations 185 The security considerations in [I-D.ietf-secsh-architecture] apply. 187 If the RSA private key generated by the server is revealed then the 188 session key is revealed. The server should thus arrange to erase 189 this from memory as soon as it is no longer required. If the same 190 RSA key is used for multiple SSH connections, an attacker who can 191 find the private key (either by factorising the public key or by 192 other means) will gain access to all of the sessions which used that 193 key. 195 [RFC3447] recommends that RSA keys used with RSAES-OAEP not be used 196 with other schemes, or with RSAES-OAEP using a different hash 197 function. In particular, this means that K_T should not be used as a 198 host key, or as a server key in earlier versions of the SSH protocol. 200 The random data, K, generated by the client, is the only secret 201 shared by client and server, so its entropy directly determines the 202 security of the session against eavesdropping. 204 The size of transient key used should be sufficient to protect the 205 encryption and integrity keys generated by the key exchange method. 206 For recommendations on this, see [RFC3766]. The strength of 207 RSAES-OAEP is in part dependent on the hash function it uses. 208 [RFC3447] suggests using a hash with an output length of twice the 209 security level required, so SHA-1 is appropriate for applications 210 requiring up to 80 bits of security, and SHA-256 for those requiring 211 up to 128 bits. 213 Unlike the Diffie-Hellman key exchange method defined by 214 [I-D.ietf-secsh-transport], this method allows the client to fully 215 determine the shared secret, K. This is believed not to be 216 significant, since K is only ever used when hashed with data provided 217 in part by the server (usually in the form of the exchange hash, H). 218 If an extension to SSH were to use K directly and to assume that it 219 had been generated by Diffie-Hellman key exchange, this could produce 220 a security weakness. Protocol extensions using K directly should be 221 viewed with extreme suspicion. 223 9. IANA Considerations 225 This document has no actions for IANA. 227 10. Acknowledgments 229 The author acknowledges the assistance of Simon Tatham with the 230 design of this key exchange method. 232 The text of this document is derived in part from 233 [I-D.ietf-secsh-transport]. 235 11. References 237 11.1 Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 243 (SHA1)", RFC 3174, September 2001. 245 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 246 Standards (PKCS) #1: RSA Cryptography Specifications 247 Version 2.1", RFC 3447, February 2003. 249 [I-D.ietf-secsh-architecture] 250 Lonvick, C., "SSH Protocol Architecture", 251 Internet-Draft draft-ietf-secsh-architecture-22, March 252 2005. 254 [I-D.ietf-secsh-transport] 255 Lonvick, C., "SSH Transport Layer Protocol", 256 Internet-Draft draft-ietf-secsh-transport-24, March 2005. 258 [FIPS-180-2] 259 National Institute of Standards and Technology (NIST), 260 "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002. 262 11.2 Informative References 264 [SSH1] Ylonen, T., "SSH -- Secure Login Connections over the 265 Internet", 6th USENIX Security Symposium, p. 37-42, July 266 1996. 268 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 269 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 270 RFC 3766, April 2004. 272 Author's Address 274 Ben Harris 275 37 Milton Road 276 CAMBRIDGE CB4 1XA 277 GB 279 Email: bjh21@bjh21.me.uk 281 Appendix A. On the size of K 283 The requirements on the size of K are intended to ensure that it's 284 always possible to encrypt it under K_T. The mpint encoding of K 285 requires a leading zero bit, padding to a whole number of bytes, and 286 a four-byte length field, giving a maximum length in bytes, 287 B = (KLEN-2HLEN-49+1+7)/8 + 4 = (KLEN-2HLEN-9)/8 (where "/" 288 represents integer division rounding down). 290 The maximum length of message that can be encrypted using RSAEP-OAEP 291 is defined by [RFC3447] in terms of the key length in bytes, which is 292 (KLEN+7)/8. The maximum length is thus L = (KLEN+7-2HLEN-16)/8 = 293 (KLEN-2HLEN-9)/8. Thus, the encoded version of K is always small 294 enough to be encrypted under K_T. 296 Intellectual Property Statement 298 The IETF takes no position regarding the validity or scope of any 299 Intellectual Property Rights or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; nor does it represent that it has 303 made any independent effort to identify any such rights. Information 304 on the procedures with respect to rights in RFC documents can be 305 found in BCP 78 and BCP 79. 307 Copies of IPR disclosures made to the IETF Secretariat and any 308 assurances of licenses to be made available, or the result of an 309 attempt made to obtain a general license or permission for the use of 310 such proprietary rights by implementers or users of this 311 specification can be obtained from the IETF on-line IPR repository at 312 http://www.ietf.org/ipr. 314 The IETF invites any interested party to bring to its attention any 315 copyrights, patents or patent applications, or other proprietary 316 rights that may cover technology that may be required to implement 317 this standard. Please address the information to the IETF at 318 ietf-ipr@ietf.org. 320 Disclaimer of Validity 322 This document and the information contained herein are provided on an 323 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 324 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 325 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 326 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 327 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 330 Copyright Statement 332 Copyright (C) The Internet Society (2005). This document is subject 333 to the rights, licenses and restrictions contained in BCP 78, and 334 except as set forth therein, the authors retain all their rights. 336 Acknowledgment 338 Funding for the RFC Editor function is currently provided by the 339 Internet Society.