Network Working Group B. Harris
Request for Comments: 4432 March 2006
Category: Standards Track
Network Working Group B. Harris
Request for Comments: 4432 March 2006
Category: Standards Track
RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
安全外壳（SSH）传输层协议的RSA密钥交换
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems.
本备忘录描述了基于Rivest Shamir Adleman（RSA）公钥加密的Secure Shell（SSH）协议的密钥交换方法。它使用的客户端CPU时间比作为核心协议一部分指定的Diffie-Hellman算法少得多，因此特别适用于速度较慢的客户端系统。
Secure Shell (SSH) [RFC4251] is a secure remote-login protocol. The core protocol uses Diffie-Hellman key exchange. On slow CPUs, this key exchange can take tens of seconds to complete, which can be irritating for the user. A previous version of the SSH protocol, described in [SSH1], uses a key-exchange method based on Rivest-Shamir-Adleman (RSA) public-key encryption, which consumes an order of magnitude less CPU time on the client, and hence is particularly suitable for slow client systems such as mobile devices. This memo describes a key-exchange mechanism for the version of SSH described in [RFC4251] that is similar to that used by the older version, and about as fast, while retaining the security advantages of the newer protocol.
Secure Shell（SSH）[RFC4251]是一种安全的远程登录协议。核心协议使用Diffie-Hellman密钥交换。在速度较慢的CPU上，此密钥交换可能需要数十秒才能完成，这可能会激怒用户。[SSH1]中描述的SSH协议的早期版本使用基于Rivest-Shamir-Adleman（RSA）公钥加密的密钥交换方法，该方法在客户端上消耗的CPU时间减少了一个数量级，因此特别适用于移动设备等低速客户端系统。此备忘录描述了[RFC4251]中描述的SSH版本的密钥交换机制，该机制类似于旧版本所使用的密钥交换机制，速度大致相同，同时保留了新协议的安全优势。
The key words "MUST" and "SHOULD" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”和“应该”应按照[RFC2119]中所述进行解释。
The data types "byte", "string", and "mpint" are defined in Section 5 of [RFC4251].
[RFC4251]第5节定义了数据类型“字节”、“字符串”和“mpint”。
Other terminology and symbols have the same meaning as in [RFC4253].
其他术语和符号的含义与[RFC4253]中的相同。
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 the private key. This may be a transient key generated solely for this SSH connection, or it may be re-used for several connections. 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 client and server each hash K, K_T, and the various key-exchange parameters to generate the exchange hash, H, which is used to 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 then verifies the host key as described in Section 8 of [RFC4253].
RSA密钥交换方法由三条消息组成。服务器向客户端发送一个RSA公钥K_T，服务器持有该公钥。这可能是一个仅为此SSH连接生成的临时密钥，也可能被重新用于多个连接。客户端生成一个随机字节串K，使用K_T对其进行加密，并将结果发送回服务器，服务器对其进行解密。客户端和服务器分别使用散列K、K_T和各种密钥交换参数来生成交换散列H，该散列H用于生成会话的加密密钥，服务器使用其主机密钥对H进行签名，并将签名发送给客户端。然后，客户机按照[RFC4253]第8节所述验证主机密钥。
This method provides explicit server identification as defined in Section 7 of [RFC4253]. It requires a signature-capable host key.
该方法提供了[RFC4253]第7节中定义的明确的服务器标识。它需要具有签名功能的主机密钥。
The RSA key-exchange method has the following parameters:
RSA密钥交换方法具有以下参数：
HASH hash algorithm for calculating exchange hash, etc. HLEN output length of HASH in bits MINKLEN minimum transient RSA modulus length in bits
用于计算交换哈希等的哈希哈希算法。HLEN哈希的输出长度（以位为单位）MINKLEN最小瞬态RSA模长度（以位为单位）
Their values are defined in Section 5 and Section 6 for the two methods defined by this document.
第5节和第6节对本文件定义的两种方法定义了它们的值。
The method uses the following messages.
该方法使用以下消息。
First, the server sends:
首先，服务器发送：
byte SSH_MSG_KEXRSA_PUBKEY string server public host key and certificates (K_S) string K_T, transient RSA public key
字节SSH_MSG_KEXRSA_公钥字符串服务器公钥和证书（K_S）字符串K_T，临时RSA公钥
The key K_T is encoded according to the "ssh-rsa" scheme described in Section 6.6 of [RFC4253]. Note that unlike an "ssh-rsa" host key, K_T is used only for encryption, and not for signature. The modulus of K_T MUST be at least MINKLEN bits long.
密钥K_T根据[RFC4253]第6.6节中描述的“ssh rsa”方案进行编码。请注意，与“ssh rsa”主机密钥不同，K_T仅用于加密，而不用于签名。K_T的模数必须至少为MINKLEN位长。
The client generates a random integer, K, in the range 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:
客户端生成范围为0<=K<2^（KLEN-2*HLEN-49）的随机整数K，其中KLEN是K_T的模的长度，单位为位。然后，客户端使用K_T加密：
mpint K, the shared secret
mpint K，共享秘密
The encryption is performed according to the RSAES-OAEP scheme of [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 encoding of K is always short enough to be thus encrypted. Having performed the encryption, the client sends:
加密根据[RFC3447]的RSAES-OAEP方案执行，使用带哈希的MGF1掩码生成函数、哈希的哈希和空标签。参见附录A，以获得K的编码总是足够短从而可以加密的证明。执行加密后，客户端发送：
byte SSH_MSG_KEXRSA_SECRET string RSAES-OAEP-ENCRYPT(K_T, K)
字节SSH_MSG_KEXRSA_秘密字符串RSAES-OAEP-ENCRYPT（K_T，K）
Note that the last stage of RSAES-OAEP-ENCRYPT is to encode an integer as an octet string using the I2OSP primitive of [RFC3447]. This, combined with encoding the result as an SSH "string", gives a result that is similar, but not identical, to the SSH "mpint" encoding applied to that integer. This is the same encoding as is used by "ssh-rsa" signatures in [RFC4253].
请注意，RSAES-OAEP-ENCRYPT的最后一个阶段是使用[RFC3447]的I2OSP原语将整数编码为八位字节字符串。这与将结果编码为SSH“字符串”相结合，得到的结果与应用于该整数的SSH“mpint”编码类似，但不完全相同。这与[RFC4253]中的“ssh rsa”签名使用的编码相同。
The server decrypts K. If a decryption error occurs, the server SHOULD send SSH_MESSAGE_DISCONNECT with a reason code of SSH_DISCONNECT_KEY_EXCHANGE_FAILED and MUST disconnect. Otherwise, the server responds with:
服务器解密K。如果发生解密错误，服务器应发送SSH\u消息\u DISCONNECT，原因代码为SSH\u DISCONNECT\u KEY\u EXCHANGE\u失败，必须断开连接。否则，服务器将响应：
byte SSH_MSG_KEXRSA_DONE string signature of H with host key
字节SSH_MSG_KEXRSA_带有主机密钥的H的已完成字符串签名
The hash H is computed as the HASH hash of the concatenation of the following:
散列H被计算为以下各项的串联的散列：
string V_C, the client's identification string (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_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key string K_T, the transient RSA key string RSAES_OAEP_ENCRYPT(K_T, K), the encrypted secret mpint K, the shared secret
字符串V_C、客户端的标识字符串（CR和LF除外）字符串V_s、服务器的标识字符串（CR和LF除外）字符串I_C、客户端的SSH_MSG_KEXINIT字符串I_s的有效负载、服务器的SSH_MSG_KEXINIT字符串K_s的有效负载、主机密钥字符串K_T、临时RSA密钥字符串RSAES_OAEP_ENCRYPT（K_T，K），加密的秘密mpint K，共享的秘密
This value is called the exchange hash, and it is used to authenticate the key exchange. The exchange hash SHOULD be kept secret.
此值称为交换哈希，用于验证密钥交换。交换哈希应该保密。
The signature algorithm MUST be applied over H, not the original data. Most signature algorithms include hashing and additional padding. For example, "ssh-dss" specifies SHA-1 hashing. In such cases, the data is first hashed with HASH to compute H, and H is then hashed again as part of the signing operation.
签名算法必须应用于H，而不是原始数据。大多数签名算法包括散列和附加填充。例如，“ssh dss”指定SHA-1哈希。在这种情况下，首先使用散列对数据进行散列以计算H，然后作为签名操作的一部分再次对H进行散列。
The "rsa1024-sha1" method specifies RSA key exchange as described above with the following parameters:
“rsa1024-sha1”方法使用以下参数指定如上所述的RSA密钥交换：
HASH SHA-1, as defined in [RFC3174] HLEN 160 MINKLEN 1024
散列SHA-1，如[RFC3174]HLEN 160 MINKLEN 1024中所定义
The "rsa2048-sha256" method specifies RSA key exchange as described above with the following parameters:
“rsa2048-sha256”方法使用以下参数指定如上所述的RSA密钥交换：
HASH SHA-256, as defined in [FIPS-180-2] HLEN 256 MINKLEN 2048
哈希SHA-256，如[FIPS-180-2]HLEN 256 MINKLEN 2048中所定义
The following message numbers are defined:
定义了以下消息编号：
SSH_MSG_KEXRSA_PUBKEY 30 SSH_MSG_KEXRSA_SECRET 31 SSH_MSG_KEXRSA_DONE 32
SSH_MSG_KEXRSA_publikey 30 SSH_MSG_KEXRSA_SECRET 31 SSH_MSG_KEXRSA_DONE 32
The security considerations in [RFC4251] apply.
[RFC4251]中的安全注意事项适用。
If the RSA private key generated by the server is revealed, then the session key is revealed. The server should thus arrange to erase this from memory as soon as it is no longer required. If the same RSA key is used for multiple SSH connections, an attacker who can find the private key (either by factorising the public key or by other means) will gain access to all of the sessions that used that key. As a result, servers SHOULD use each RSA key for as few key exchanges as possible.
如果显示服务器生成的RSA私钥，则会显示会话密钥。因此，一旦不再需要，服务器应安排将其从内存中删除。如果相同的RSA密钥用于多个SSH连接，则能够找到私钥（通过分解公钥或其他方式）的攻击者将获得对使用该密钥的所有会话的访问权。因此，服务器应该使用每个RSA密钥进行尽可能少的密钥交换。
[RFC3447] recommends that RSA keys used with RSAES-OAEP not be used 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 host key, or as a server key in earlier versions of the SSH protocol.
[RFC3447]建议与RSAES-OAEP一起使用的RSA密钥不得与其他方案一起使用，或与使用不同哈希函数的RSAES-OAEP一起使用。特别是，这意味着在SSH协议的早期版本中，K_T不应用作主机密钥或服务器密钥。
Like all key-exchange mechanisms, this one depends for its security on the randomness of the secrets generated by the client (the random 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.
与所有密钥交换机制一样，这种机制的安全性取决于客户端（随机数K）和服务器（瞬时RSA私钥）生成的秘密的随机性。特别是，客户端必须使用高质量的加密伪随机数生成器生成K。使用坏随机数生成器将允许攻击者破坏安全外壳传输层的所有加密和完整性保护。有关随机数生成的建议，请参见[RFC4086]。
The size of transient key used should be sufficient to protect the encryption and integrity keys generated by the key-exchange method. For recommendations on this, see [RFC3766]. The strength of RSAES-OAEP is in part dependent on the hash function it uses. [RFC3447] suggests using a hash with an output length of twice the security level required, so SHA-1 is appropriate for applications requiring up to 80 bits of security, and SHA-256 for those requiring up to 128 bits.
使用的临时密钥的大小应足以保护密钥交换方法生成的加密密钥和完整性密钥。有关这方面的建议，请参见[RFC3766]。RSAES-OAEP的强度部分取决于它使用的哈希函数。[RFC3447]建议使用输出长度为所需安全级别两倍的哈希，因此SHA-1适用于需要80位安全性的应用程序，而SHA-256适用于需要128位安全性的应用程序。
Unlike the Diffie-Hellman key-exchange method defined by [RFC4253], this method allows the client to fully determine 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 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 been generated by Diffie-Hellman key exchange, this could produce a security weakness. Protocol extensions using K directly should be viewed with extreme suspicion.
与[RFC4253]定义的Diffie-Hellman密钥交换方法不同，该方法允许客户机完全确定共享密钥K。这被认为不重要，因为K仅在与服务器部分提供的数据进行散列时使用（通常以交换散列H的形式）。如果SSH的扩展直接使用K，并假设它是由Diffie-Hellman密钥交换生成的，那么这可能会产生安全漏洞。直接使用K的协议扩展应该以极大的怀疑来看待。
This key-exchange method is designed to be resistant to collision attacks on the exchange hash, by ensuring that neither side is able to freely choose its input to the hash after seeing all of the other side's input. The server's last input is in SSH_MSG_KEXRSA_PUBKEY, before it has seen the client's choice of K. The client's last input is K and its RSA encryption, and the one-way nature of RSA encryption should ensure that the client cannot choose K so as to cause a collision.
This key-exchange method is designed to be resistant to collision attacks on the exchange hash, by ensuring that neither side is able to freely choose its input to the hash after seeing all of the other side's input. The server's last input is in SSH_MSG_KEXRSA_PUBKEY, before it has seen the client's choice of K. The client's last input is K and its RSA encryption, and the one-way nature of RSA encryption should ensure that the client cannot choose K so as to cause a collision.translate error, please retry
IANA has assigned the names "rsa1024-sha1" and "rsa2048-sha256" as Key Exchange Method Names in accordance with [RFC4250].
IANA已根据[RFC4250]将名称“rsa1024-sha1”和“rsa2048-sha256”指定为密钥交换方法名称。
The author acknowledges the assistance of Simon Tatham with the design of this key exchange method.
作者感谢Simon Tatham在设计此密钥交换方法方面提供的帮助。
The text of this document is derived in part from [RFC4253].
本文件的部分内容源自[RFC4253]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253]Ylonen，T.和C.Lonvick，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250]Lehtinen，S.和C.Lonvick，“安全外壳（SSH）协议分配编号”，RFC 4250，2006年1月。
[FIPS-180-2] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002.
[FIPS-180-2]国家标准与技术研究所（NIST），“安全哈希标准（SHS）”，FIPS PUB 180-22002，2002年8月。
[SSH1] Ylonen, T., "SSH -- Secure Login Connections over the Internet", 6th USENIX Security Symposium, pp. 37-42, July 1996.
[SSH1]Ylonen，T.，“SSH——互联网上的安全登录连接”，第六届USENIX安全研讨会，第37-42页，1996年7月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
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
requires a leading zero bit, padding to a whole number of bytes, and
a four-byte length field, giving a maximum length in bytes,
B = (KLEN-2*HLEN-49+1+7)/8 + 4 = (KLEN-2*HLEN-9)/8 (where "/" denotes
integer division rounding down).
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
requires a leading zero bit, padding to a whole number of bytes, and
a four-byte length field, giving a maximum length in bytes,
B = (KLEN-2*HLEN-49+1+7)/8 + 4 = (KLEN-2*HLEN-9)/8 (where "/" denotes
integer division rounding down).
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
(KLEN+7)/8. The maximum length is thus L = (KLEN+7-2*HLEN-16)/8 =
(KLEN-2*HLEN-9)/8. Thus, the encoded version of K is always small
enough to be encrypted under K_T.
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
(KLEN+7)/8. The maximum length is thus L = (KLEN+7-2*HLEN-16)/8 =
(KLEN-2*HLEN-9)/8. Thus, the encoded version of K is always small
enough to be encrypted under K_T.
Author's Address
作者地址
Ben Harris 2a Eachard Road CAMBRIDGE CB4 1XA UNITED KINGDOM
英国剑桥CB4 1XA伊查德路2a号本哈里斯酒店
EMail: bjh21@bjh21.me.uk
EMail: bjh21@bjh21.me.uk
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。