idnits 2.17.00 (12 Aug 2021) /tmp/idnits5657/draft-harris-ssh-rsa-kex-00.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 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 294. ** 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 7 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 125 has weird spacing: '... string ser...' == Line 126 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 (January 6, 2005) is 6343 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) ** 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: 6 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 January 6, 2005 3 Expires: July 7, 2005 5 RSA key exchange for the SSH Transport Layer Protocol 6 draft-harris-ssh-rsa-kex-00.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 July 7, 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) [SSH-ARCH] is a secure remote-login protocol. The 49 core protocol uses Diffie-Hellman key exchange. On slow CPUs, this 50 key exchange can take tens of seconds to complete, which can be 51 irritating for the user. A previous version of the SSH protocol, 52 described in [SSH1] uses an RSA-based key exchange method, which 53 consumes an order of magnitude less CPU time on the client, and hence 54 is particularly suitable for slow client systems such as mobile 55 devices. This memo describes a key-exchange mechanism for the 56 version of SSH described in [SSH-ARCH] which is similar to that used 57 by the older version, and about as fast, while retaining the security 58 advantages of the newer protocol. 60 2. Conventions Used in this Document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 3. Overview 68 The RSA key-exchange method consists of three messages. First, the 69 server sends to the client an RSA public key, K_T, to which the 70 server holds the private key. This may be a transient key generated 71 solely for this SSH connection, or it may be re-used for several 72 connections. The client generates a string of random bytes, K, 73 encrypts it using K_T, and sends the result back to the server, which 74 decrypts it. The client and server each hash K, K_T, and the various 75 key-exchange parameters to generate the exchange hash, H, which is 76 used to generate the encryption keys for the session, and the server 77 signs H with its host key and sends the signature to the client. The 78 client then verifies the host key as described in [SSH-TRANS]. 80 This method provides explicit server identification as defined in 81 section 7 of [SSH-TRANS]. It requires a signature-capable host key. 83 4. Details 85 The RSA key exchange method has the following parameters, which are 86 defined by the method name: 88 HASH hash algorithm for calculating exchange hash etc. 89 HLEN output length of HASH in bits 90 MINKLEN minimum transient RSA modulus length in bits 92 The method uses the following messages. 94 First, the server sends: 96 byte SSH_MSG_KEXRSA_PUBKEY 97 string K_T, transient RSA public key 99 The key K_T is encoded according to the "ssh-rsa" scheme described in 100 section 6.6 of [SSH-TRANS]. Note that unlike an "ssh-rsa" host key, 101 K_T is only used for encryption, and not for signature. The modulus 102 of K_T MUST be at least MINKLEN bits long. 104 The client generates a random integer, K, in the range 105 0 <= K < 2^(KLEN-2HLEN-49), where KLEN is the length of the modulus 106 of K_T, in bits. The client then uses K_T to encrypt: 108 mpint K, the shared secret 110 The encryption is performed according to the RSAES-OAEP scheme of 111 [RFC3447], with a mask generation function of MGF1-with-HASH, a hash 112 of HASH, and an empty label. See Appendix A for a proof that the 113 encoding of K is always short enough to be thus encrypted. Having 114 performed the encryption, the client sends: 116 byte SSH_MSG_KEXRSA_SECRET 117 string RSAES-OAEP-ENCRYPT(K_T, K) 119 The server decrypts K. If a decryption error occurs, the server 120 SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of 121 SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect. Otherwise, 122 the server responds with: 124 byte SSH_MSG_KEXRSA_DONE 125 string server public host key and certificates (K_S) 126 string signature of H 128 The hash H is computed as the HASH hash of the concatenation of the 129 following: 131 string V_C, the client's version string (CR and NL excluded) 132 string V_S, the server's version string (CR and NL excluded) 133 string I_C, the payload of the client's SSH_MSG_KEXINIT 134 string I_S, the payload of the server's SSH_MSG_KEXINIT 135 string K_S, the host key 136 string K_T, the transient RSA key 137 mpint K, the shared secret 139 This value is called the exchange hash, and it is used to 140 authenticate the key exchange. The exchange hash SHOULD be kept 141 secret. 143 The signature algorithm MUST be applied over H, not the original 144 data. Most signature algorithms include hashing and additional 145 padding - for example, "ssh-dss" specifies SHA-1 hashing. In that 146 case, the data is first hashed with HASH to compute H, and H is then 147 hashed with SHA-1 as part of the signing operation. 149 5. rsa-sha1-draft-00@putty.projects.tartarus.org 151 The "rsa-sha1-draft-00@putty.projects.tartarus.org" method specifies 152 RSA key exchange as described above with the following parameters: 154 HASH SHA-1, as defined in [FIPS-180-2] 155 HLEN 160 156 MINKLEN 1024 158 6. Message numbers 160 The following message numbers are defined: 162 SSH_MSG_KEXRSA_PUBKEY 30 163 SSH_MSG_KEXRSA_SECRET 31 164 SSH_MSG_KEXRSA_DONE 32 166 Note that Numbers 30-49 are used for kex packets. Different kex 167 methods may reuse message numbers in this range. 169 7. Security Considerations 171 The security considerations in [SSH-ARCH] apply. 173 If the RSA private key generated by the server is revealed then the 174 session key is revealed. The server should thus arrange to erase 175 this from memory as soon as it is no longer required. If the same 176 RSA key is used for multiple SSH connections, an attacker who can 177 find the private key (either by factorising the public key or by 178 other means) will gain access to all of the sessions which used that 179 key. 181 [RFC3447] recommends that RSA keys used with RSAES-OAEP not be used 182 with other schemes, or with RSAES-OAEP using a different hash 183 function. In particular, this means that K_T should not be used as a 184 host key, or as a server key in earlier versions of the SSH protocol. 186 The random data, K, generated by the client, is the only secret 187 shared by client and server, so its entropy directly determines the 188 security of the session against eavesdropping. 190 The size of transient key used should be sufficient to protect the 191 encryption and integrity keys generated by the key exchange method. 193 For recommendations on this, see [RFC3766]. 195 Unlike the Diffie-Hellman key exchange method defined by [SSH-TRANS], 196 this method allows the client to fully determine the shared secret, 197 K. This is believed not to be significant, since K is only ever used 198 when hashed with data provided in part by the server (usually in the 199 form of the exchange hash, H). If an extension to SSH were to use K 200 directly and to assume that it had been generated by Diffie-Hellman 201 key exchange, this could produce a security weakness. Protocol 202 extensions using K directly should be viewed with extreme suspicion. 204 8. IANA Considerations 206 This document has no actions for IANA. 208 9. Acknowledgments 210 The author acknowledges the assistance of Simon Tatham with the 211 design of this key exchange method. 213 The text of this document is derived in part from [SSH-TRANS]. 215 10. References 217 10.1 Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 223 Standards (PKCS) #1: RSA Cryptography Specifications 224 Version 2.1", RFC 3447, February 2003. 226 [SSH-ARCH] 227 Lonvick, C., Ed., "SSH Protocol Architecture", I-D 228 draft-ietf-secsh-architecture-20.txt, December 2004. 230 [SSH-TRANS] 231 Lonvick, C., Ed., "SSH Transport Layer Protocol", I-D 232 draft-ietf-secsh-transport-22.txt, December 2004. 234 [FIPS-180-2] 235 National Institute of Standards and Technology (NIST), 236 "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002. 238 10.2 Informative References 240 [SSH1] Ylonen, T., "SSH -- Secure Login Connections over the 241 Internet", 6th USENIX Security Symposium, p. 37-42, July 242 1996. 244 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 245 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 246 RFC 3766, April 2004. 248 Author's Address 250 Ben Harris 251 37 Milton Road 252 CAMBRIDGE CB4 1XA 253 GB 255 EMail: bjh21@bjh21.me.uk 257 Appendix A. On the size of K 259 The requirements on the size of K are intended to ensure that it's 260 always possible to encrypt in under K_T. The mpint encoding of K 261 requires a leading zero bit, padding to a whole number of bytes, and 262 a four-byte length field, giving a maximum length in bytes, 263 B = (KLEN-2HLEN-49+1+7)/8 + 4 = (KLEN-2HLEN-9)/8 (where "/" 264 represents integer division rounding down). 266 The maximum length of message that can be encrypted using RSAEP-OAEP 267 is defined by [RFC3447] in terms of the key length in bytes, which is 268 (KLEN+7)/8. The maximum length is thus L = (KLEN+7-2HLEN-16)/8 = 269 (KLEN-2HLEN-9)/8. Thus, the encoded version of K is always small 270 enough to be encrypted under K_T. 272 Intellectual Property Statement 274 The IETF takes no position regarding the validity or scope of any 275 Intellectual Property Rights or other rights that might be claimed to 276 pertain to the implementation or use of the technology described in 277 this document or the extent to which any license under such rights 278 might or might not be available; nor does it represent that it has 279 made any independent effort to identify any such rights. Information 280 on the procedures with respect to rights in RFC documents can be 281 found in BCP 78 and BCP 79. 283 Copies of IPR disclosures made to the IETF Secretariat and any 284 assurances of licenses to be made available, or the result of an 285 attempt made to obtain a general license or permission for the use of 286 such proprietary rights by implementers or users of this 287 specification can be obtained from the IETF on-line IPR repository at 288 http://www.ietf.org/ipr. 290 The IETF invites any interested party to bring to its attention any 291 copyrights, patents or patent applications, or other proprietary 292 rights that may cover technology that may be required to implement 293 this standard. Please address the information to the IETF at 294 ietf-ipr@ietf.org. 296 Disclaimer of Validity 298 This document and the information contained herein are provided on an 299 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 300 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 301 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 302 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 303 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 304 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 306 Copyright Statement 308 Copyright (C) The Internet Society (2005). This document is subject 309 to the rights, licenses and restrictions contained in BCP 78, and 310 except as set forth therein, the authors retain all their rights. 312 Acknowledgment 314 Funding for the RFC Editor function is currently provided by the 315 Internet Society.