| < draft-harris-ssh-rsa-kex-05.txt | draft-harris-ssh-rsa-kex-06.txt > | |||
|---|---|---|---|---|
| Network Working Group B. Harris | Network Working Group B. Harris | |||
| Internet-Draft August 25, 2005 | Internet-Draft December 19, 2005 | |||
| Expires: February 26, 2006 | Expires: June 22, 2006 | |||
| Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH) | Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH) | |||
| Transport Layer Protocol | Transport Layer Protocol | |||
| draft-harris-ssh-rsa-kex-05 | draft-harris-ssh-rsa-kex-06 | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 34 ¶ | skipping to change at page 1, line 34 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on February 26, 2006. | This Internet-Draft will expire on June 22, 2006. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |||
| Abstract | Abstract | |||
| This memo describes a key-exchange method for the Secure Shell (SSH) | This memo describes a key-exchange method for the Secure Shell (SSH) | |||
| protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. | protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. | |||
| It uses much less client CPU time than the Diffie-Hellman algorithm | It uses much less client CPU time than the Diffie-Hellman algorithm | |||
| skipping to change at page 2, line 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| This memo describes a key-exchange mechanism for the version of SSH | This memo describes a key-exchange mechanism for the version of SSH | |||
| described in [I-D.ietf-secsh-architecture] which is similar to that | described in [I-D.ietf-secsh-architecture] which is similar to that | |||
| used by the older version, and about as fast, while retaining the | used by the older version, and about as fast, while retaining the | |||
| security advantages of the newer protocol. | security advantages of the newer protocol. | |||
| 2. Conventions Used in this Document | 2. Conventions Used in this Document | |||
| The key words "MUST" and "SHOULD" in this document are to be | The key words "MUST" and "SHOULD" in this document are to be | |||
| interpreted as described in [RFC2119]. | interpreted as described in [RFC2119]. | |||
| The data types "byte", "string", and "mpint" are defined in section 5 | ||||
| of [I-D.ietf-secsh-architecture]. | ||||
| Other terminology and symbols have the same meaning as in [I-D.ietf- | ||||
| secsh-transport]. | ||||
| 3. Overview | 3. Overview | |||
| The RSA key-exchange method consists of three messages. The server | The RSA key-exchange method consists of three messages. The server | |||
| sends to the client an RSA public key, K_T, to which the server holds | sends to the client an RSA public key, K_T, to which the server holds | |||
| the private key. This may be a transient key generated solely for | the private key. This may be a transient key generated solely for | |||
| this SSH connection, or it may be re-used for several connections. | this SSH connection, or it may be re-used for several connections. | |||
| The client generates a string of random bytes, K, encrypts it using | The client generates a string of random bytes, K, encrypts it using | |||
| K_T, and sends the result back to the server, which decrypts it. The | K_T, and sends the result back to the server, which decrypts it. The | |||
| client and server each hash K, K_T, and the various key-exchange | client and server each hash K, K_T, and the various key-exchange | |||
| parameters to generate the exchange hash, H, which is used to | parameters to generate the exchange hash, H, which is used to | |||
| generate the encryption keys for the session, and the server signs H | generate the encryption keys for the session, and the server signs H | |||
| with its host key and sends the signature to the client. The client | with its host key and sends the signature to the client. The client | |||
| then verifies the host key as described in [I-D.ietf-secsh- | then verifies the host key as described in section 8 of [I-D.ietf- | |||
| transport]. | secsh-transport]. | |||
| This method provides explicit server identification as defined in | This method provides explicit server identification as defined in | |||
| section 7 of [I-D.ietf-secsh-transport]. It requires a signature- | section 7 of [I-D.ietf-secsh-transport]. It requires a signature- | |||
| capable host key. | capable host key. | |||
| 4. Details | 4. Details | |||
| The RSA key exchange method has the following parameters, which are | ||||
| defined by the method name: | The RSA key exchange method has the following parameters: | |||
| HASH hash algorithm for calculating exchange hash etc. | HASH hash algorithm for calculating exchange hash etc. | |||
| HLEN output length of HASH in bits | HLEN output length of HASH in bits | |||
| MINKLEN minimum transient RSA modulus length in bits | MINKLEN minimum transient RSA modulus length in bits | |||
| Their values are defined in Section 5 and Section 6 for the two | ||||
| methods defined by this document. | ||||
| The method uses the following messages. | The method uses the following messages. | |||
| First, the server sends: | First, the server sends: | |||
| byte SSH_MSG_KEXRSA_PUBKEY | byte SSH_MSG_KEXRSA_PUBKEY | |||
| string server public host key and certificates (K_S) | string server public host key and certificates (K_S) | |||
| string K_T, transient RSA public key | string K_T, transient RSA public key | |||
| The key K_T is encoded according to the "ssh-rsa" scheme described in | The key K_T is encoded according to the "ssh-rsa" scheme described in | |||
| section 6.6 of [I-D.ietf-secsh-transport]. Note that unlike an "ssh- | section 6.6 of [I-D.ietf-secsh-transport]. Note that unlike an "ssh- | |||
| rsa" host key, K_T is only used for encryption, and not for | rsa" host key, K_T is only used for encryption, and not for | |||
| signature. The modulus of K_T MUST be at least MINKLEN bits long. | signature. The modulus of K_T MUST be at least MINKLEN bits long. | |||
| The client generates a random integer, K, in the range | The client generates a random integer, K, in the range | |||
| 0 <= K < 2^(KLEN-2HLEN-49), where KLEN is the length of the modulus | 0 <= K < 2^(KLEN-2*HLEN-49), where KLEN is the length of the modulus | |||
| of K_T, in bits. The client then uses K_T to encrypt: | of K_T, in bits. The client then uses K_T to encrypt: | |||
| mpint K, the shared secret | mpint K, the shared secret | |||
| The encryption is performed according to the RSAES-OAEP scheme of | The encryption is performed according to the RSAES-OAEP scheme of | |||
| [RFC3447], with a mask generation function of MGF1-with-HASH, a hash | [RFC3447], with a mask generation function of MGF1-with-HASH, a hash | |||
| of HASH, and an empty label. See Appendix A for a proof that the | of HASH, and an empty label. See Appendix A for a proof that the | |||
| encoding of K is always short enough to be thus encrypted. Having | encoding of K is always short enough to be thus encrypted. Having | |||
| performed the encryption, the client sends: | performed the encryption, the client sends: | |||
| skipping to change at page 4, line 9 ¶ | skipping to change at page 4, line 16 ¶ | |||
| SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of | SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of | |||
| SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect. Otherwise, | SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect. Otherwise, | |||
| the server responds with: | the server responds with: | |||
| byte SSH_MSG_KEXRSA_DONE | byte SSH_MSG_KEXRSA_DONE | |||
| string signature of H with host key | string signature of H with host key | |||
| The hash H is computed as the HASH hash of the concatenation of the | The hash H is computed as the HASH hash of the concatenation of the | |||
| following: | following: | |||
| string V_C, the client's version string (CR and NL excluded) | string V_C, the client's identification string | |||
| string V_S, the server's version string (CR and NL excluded) | (CR and LF excluded) | |||
| string V_S, the server's identification string | ||||
| (CR and LF excluded) | ||||
| string I_C, the payload of the client's SSH_MSG_KEXINIT | string I_C, the payload of the client's SSH_MSG_KEXINIT | |||
| string I_S, the payload of the server's SSH_MSG_KEXINIT | string I_S, the payload of the server's SSH_MSG_KEXINIT | |||
| string K_S, the host key | string K_S, the host key | |||
| string K_T, the transient RSA key | string K_T, the transient RSA key | |||
| string RSAES_OAEP_ENCRYPT(K_T, K), the encrypted secret | string RSAES_OAEP_ENCRYPT(K_T, K), the encrypted secret | |||
| mpint K, the shared secret | mpint K, the shared secret | |||
| This value is called the exchange hash, and it is used to | This value is called the exchange hash, and it is used to | |||
| authenticate the key exchange. The exchange hash SHOULD be kept | authenticate the key exchange. The exchange hash SHOULD be kept | |||
| secret. | secret. | |||
| skipping to change at page 5, line 31 ¶ | skipping to change at page 5, line 40 ¶ | |||
| find the private key (either by factorising the public key or by | find the private key (either by factorising the public key or by | |||
| other means) will gain access to all of the sessions which used that | other means) will gain access to all of the sessions which used that | |||
| key. As a result, servers SHOULD use each RSA key for as few key | key. As a result, servers SHOULD use each RSA key for as few key | |||
| exchanges as possible. | exchanges as possible. | |||
| [RFC3447] recommends that RSA keys used with RSAES-OAEP not be used | [RFC3447] recommends that RSA keys used with RSAES-OAEP not be used | |||
| with other schemes, or with RSAES-OAEP using a different hash | with other schemes, or with RSAES-OAEP using a different hash | |||
| function. In particular, this means that K_T should not be used as a | function. In particular, this means that K_T should not be used as a | |||
| host key, or as a server key in earlier versions of the SSH protocol. | host key, or as a server key in earlier versions of the SSH protocol. | |||
| K, the random integer generated by the client, is the only secret | Like all key-exchange mechanisms, this one depends for its security | |||
| shared by client and server. Thus its entropy directly determines | on the randomness of the secrets generated by the client (the random | |||
| the security of the session against eavesdropping. | number K) and the server (the transient RSA private key). In | |||
| particular, it is essential that the client use a high-quality | ||||
| cryptographic pseudo-random number generator to generate K. Using a | ||||
| bad random number generator will allow an attacker to break all the | ||||
| encryption and integrity protection of the Secure Shell transport | ||||
| layer. See [RFC4086] for recommendations on random-number generation | ||||
| The size of transient key used should be sufficient to protect the | The size of transient key used should be sufficient to protect the | |||
| encryption and integrity keys generated by the key exchange method. | encryption and integrity keys generated by the key exchange method. | |||
| For recommendations on this, see [RFC3766]. The strength of RSAES- | For recommendations on this, see [RFC3766]. The strength of RSAES- | |||
| OAEP is in part dependent on the hash function it uses. [RFC3447] | OAEP is in part dependent on the hash function it uses. [RFC3447] | |||
| suggests using a hash with an output length of twice the security | suggests using a hash with an output length of twice the security | |||
| level required, so SHA-1 is appropriate for applications requiring up | level required, so SHA-1 is appropriate for applications requiring up | |||
| to 80 bits of security, and SHA-512 for those requiring up to 256 | to 80 bits of security, and SHA-256 for those requiring up to 128 | |||
| bits. | bits. | |||
| Unlike the Diffie-Hellman key exchange method defined by [I-D.ietf- | Unlike the Diffie-Hellman key exchange method defined by [I-D.ietf- | |||
| secsh-transport], this method allows the client to fully determine | secsh-transport], this method allows the client to fully determine | |||
| the shared secret, K. This is believed not to be significant, since K | the shared secret, K. This is believed not to be significant, since K | |||
| is only ever used when hashed with data provided in part by the | is only ever used when hashed with data provided in part by the | |||
| server (usually in the form of the exchange hash, H). If an | server (usually in the form of the exchange hash, H). If an | |||
| extension to SSH were to use K directly and to assume that it had | extension to SSH were to use K directly and to assume that it had | |||
| been generated by Diffie-Hellman key exchange, this could produce a | been generated by Diffie-Hellman key exchange, this could produce a | |||
| security weakness. Protocol extensions using K directly should be | security weakness. Protocol extensions using K directly should be | |||
| skipping to change at page 7, line 27 ¶ | skipping to change at page 7, line 45 ¶ | |||
| 11.2. Informative References | 11.2. Informative References | |||
| [SSH1] Ylonen, T., "SSH -- Secure Login Connections over the | [SSH1] Ylonen, T., "SSH -- Secure Login Connections over the | |||
| Internet", 6th USENIX Security Symposium, pp. 37-42, | Internet", 6th USENIX Security Symposium, pp. 37-42, | |||
| July 1996. | July 1996. | |||
| [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For | [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For | |||
| Public Keys Used For Exchanging Symmetric Keys", BCP 86, | Public Keys Used For Exchanging Symmetric Keys", BCP 86, | |||
| RFC 3766, April 2004. | RFC 3766, April 2004. | |||
| [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness | ||||
| Requirements for Security", BCP 106, RFC 4086, June 2005. | ||||
| Appendix A. On the size of K | Appendix A. On the size of K | |||
| The requirements on the size of K are intended to ensure that it is | The requirements on the size of K are intended to ensure that it is | |||
| always possible to encrypt it under K_T. The mpint encoding of K | always possible to encrypt it under K_T. The mpint encoding of K | |||
| requires a leading zero bit, padding to a whole number of bytes, and | requires a leading zero bit, padding to a whole number of bytes, and | |||
| a four-byte length field, giving a maximum length in bytes, | a four-byte length field, giving a maximum length in bytes, | |||
| B = (KLEN-2HLEN-49+1+7)/8 + 4 = (KLEN-2HLEN-9)/8 (where "/" | B = (KLEN-2*HLEN-49+1+7)/8 + 4 = (KLEN-2*HLEN-9)/8 (where "/" | |||
| represents integer division rounding down). | represents integer division rounding down). | |||
| The maximum length of message that can be encrypted using RSAEP-OAEP | The maximum length of message that can be encrypted using RSAEP-OAEP | |||
| is defined by [RFC3447] in terms of the key length in bytes, which is | is defined by [RFC3447] in terms of the key length in bytes, which is | |||
| (KLEN+7)/8. The maximum length is thus L = (KLEN+7-2HLEN-16)/8 = | (KLEN+7)/8. The maximum length is thus L = (KLEN+7-2*HLEN-16)/8 = | |||
| (KLEN-2HLEN-9)/8. Thus, the encoded version of K is always small | (KLEN-2*HLEN-9)/8. Thus, the encoded version of K is always small | |||
| enough to be encrypted under K_T. | enough to be encrypted under K_T. | |||
| Trademark Notice | Trademark Notice | |||
| "SSH" is a registered trademark in the United States. | "SSH" is a registered trademark in the United States. | |||
| Author's Address | Author's Address | |||
| Ben Harris | Ben Harris | |||
| 37 Milton Road | 2a Eachard Road | |||
| CAMBRIDGE CB4 1XA | CAMBRIDGE CB4 1XA | |||
| GB | GB | |||
| Email: bjh21@bjh21.me.uk | Email: a7250@bjh21.me.uk | |||
| Intellectual Property Statement | Intellectual Property Statement | |||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
| might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
| made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
| on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
| End of changes. 17 change blocks. | ||||
| 20 lines changed or deleted | 40 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||