Internet Engineering Task Force (IETF) K. Igoe
Request for Comments: 6239 National Security Agency
Category: Informational May 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) K. Igoe
Request for Comments: 6239 National Security Agency
Category: Informational May 2011
ISSN: 2070-1721
Suite B Cryptographic Suites for Secure Shell (SSH)
用于安全Shell的套件B加密套件（SSH）
Abstract
摘要
This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates.
本文档描述了安全Shell传输层协议和安全Shell身份验证协议的与套件B兼容的实现的体系结构。Suite B Secure Shell使用椭圆曲线Diffie-Hellman（ECDH）密钥协议、椭圆曲线数字签名算法（ECDSA）、在Galois/计数器模式下运行的高级加密标准（AES-GCM）、SHA-2哈希家族的两个成员（SHA-256和SHA-384）和X.509证书。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6239.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6239.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Suite B and Secure Shell ........................................3
2.1. Minimum Levels of Security (minLOS) ........................4
2.2. Digital Signatures and Certificates ........................4
2.3. Non-Signature Primitives ...................................5
3. Security Mechanism Negotiation and Initialization ...............6
3.1. Algorithm Negotiation: SSH_MSG_KEXINIT .....................7
4. Key Exchange and Server Authentication ..........................8
4.1. SSH_MSG_KEXECDH_INIT .......................................9
4.2. SSH_MSG_KEXECDH_REPLY ......................................9
4.3. Key and Initialization Vector Derivation ..................10
5. User Authentication ............................................10
5.1. First SSH_MSG_USERAUTH_REQUEST Message ....................10
5.2. Second SSH_MSG_USERAUTH_REQUEST Message ...................11
6. Confidentiality and Data Integrity of SSH Binary Packets .......12
6.1. Galois/Counter Mode .......................................12
6.2. Data Integrity ............................................12
7. Rekeying .......................................................12
8. Security Considerations ........................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
1. Introduction ....................................................3
2. Suite B and Secure Shell ........................................3
2.1. Minimum Levels of Security (minLOS) ........................4
2.2. Digital Signatures and Certificates ........................4
2.3. Non-Signature Primitives ...................................5
3. Security Mechanism Negotiation and Initialization ...............6
3.1. Algorithm Negotiation: SSH_MSG_KEXINIT .....................7
4. Key Exchange and Server Authentication ..........................8
4.1. SSH_MSG_KEXECDH_INIT .......................................9
4.2. SSH_MSG_KEXECDH_REPLY ......................................9
4.3. Key and Initialization Vector Derivation ..................10
5. User Authentication ............................................10
5.1. First SSH_MSG_USERAUTH_REQUEST Message ....................10
5.2. Second SSH_MSG_USERAUTH_REQUEST Message ...................11
6. Confidentiality and Data Integrity of SSH Binary Packets .......12
6.1. Galois/Counter Mode .......................................12
6.2. Data Integrity ............................................12
7. Rekeying .......................................................12
8. Security Considerations ........................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................13
This document describes the architecture of a Suite B compliant implementation of the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol. Suite B Secure Shell makes use of the elliptic curve Diffie-Hellman (ECDH) key agreement, the elliptic curve digital signature algorithm (ECDSA), the Advanced Encryption Standard running in Galois/Counter Mode (AES-GCM), two members of the SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 certificates.
本文档描述了安全Shell传输层协议和安全Shell身份验证协议的与套件B兼容的实现的体系结构。Suite B Secure Shell使用椭圆曲线Diffie-Hellman（ECDH）密钥协议、椭圆曲线数字签名算法（ECDSA）、在Galois/计数器模式下运行的高级加密标准（AES-GCM）、SHA-2哈希家族的两个成员（SHA-256和SHA-384）和X.509证书。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Several RFCs have documented how each of the Suite B components are to be integrated into Secure Shell (SSH):
几个RFC记录了如何将每个套件B组件集成到Secure Shell（SSH）中：
kex algorithms ecdh-sha2-nistp256 [SSH-ECC] ecdh-sha2-nistp384 [SSH-ECC]
kex算法ecdh-sha2-nistp256[SSH-ECC]ecdh-sha2-nistp384[SSH-ECC]
server host key algorithms x509v3-ecdsa-sha2-nistp256 [SSH-X509] x509v3-ecdsa-sha2-nistp384 [SSH-X509]
服务器主机密钥算法x509v3-ecdsa-sha2-nistp256[SSH-X509]x509v3-ecdsa-sha2-nistp384[SSH-X509]
encryption algorithms (both client_to_server and server_to_client) AEAD_AES_128_GCM [SSH-GCM] AEAD_AES_256_GCM [SSH-GCM]
加密算法（客户端到服务器和服务器到客户端）AEAD_AES_128_GCM[SSH-GCM]AEAD_AES_256_GCM[SSH-GCM]
MAC algorithms (both client_to_server and server_to_client) AEAD_AES_128_GCM [SSH-GCM] AEAD_AES_256_GCM [SSH-GCM]
MAC算法（客户端到服务器和服务器到客户端）AEAD_AES_128_GCM[SSH-GCM]AEAD_AES_256_GCM[SSH-GCM]
In Suite B, public key certificates used to verify signatures MUST be compliant with the Suite B Certificate Profile specified in RFC 5759 [SUITEBCERT].
在套件B中，用于验证签名的公钥证书必须符合RFC 5759[SUITEBCERT]中指定的套件B证书配置文件。
The purpose of this document is to draw upon all of these documents to provide guidance for Suite B compliant implementations of Secure Shell (hereafter referred to as "SecSh-B"). Note that while SecSh-B MUST follow the guidance in this document, that requirement does not in and of itself imply that a given implementation of Secure Shell is suitable for use in protecting classified data. An implementation of SecSh-B must be validated by the appropriate authority before such usage is permitted.
本文件的目的是利用所有这些文件为符合套件B的Secure Shell（以下简称“SecSh-B”）实施提供指导。请注意，尽管SecSh-B必须遵循本文件中的指南，但该要求本身并不意味着给定的Secure Shell实现适合用于保护机密数据。SecSh-B的实施必须经过相关机构的验证，才能允许使用。
The two elliptic curves used in Suite B appear in the literature under two different names. For the sake of clarity, we list both names below.
套件B中使用的两条椭圆曲线在文献中以两个不同的名称出现。为了清楚起见，我们在下面列出了这两个名字。
Curve NIST name SECG name OID [SEC2]
---------------------------------------------------------------
P-256 nistp256 secp256r1 1.2.840.10045.3.1.7
P-384 nistp384 secp384r1 1.3.132.0.34
Curve NIST name SECG name OID [SEC2]
---------------------------------------------------------------
P-256 nistp256 secp256r1 1.2.840.10045.3.1.7
P-384 nistp384 secp384r1 1.3.132.0.34
A description of these curves can be found in [NIST] or [SEC2].
这些曲线的描述可在[NIST]或[SEC2]中找到。
For the sake of brevity, ECDSA-256 will be used to denote ECDSA on P-256 using SHA-256, and ECDSA-384 will be used to denote ECDSA on P-384 using SHA-384.
为简洁起见，ECDSA-256将使用SHA-256表示P-256上的ECDSA，ECDSA-384将使用SHA-384表示P-384上的ECDSA。
Suite B provides for two levels of cryptographic security, namely a 128-bit minimum level of security (minLOS_128) and a 192-bit minimum level of security (minLOS_192). As we shall see below, the ECDSA-256/384 signature algorithms and corresponding X.509v3 certificates are treated somewhat differently than the non-signature primitives (kex algorithms, encryption algorithms, and Message Authentication Code (MAC) algorithms in Secure Shell parlance).
套件B提供两种加密安全级别，即128位最低安全级别（minLOS_128）和192位最低安全级别（minLOS_192）。正如我们将在下面看到的，ECDSA-256/384签名算法和相应的X.509v3证书与非签名原语（安全外壳术语中的kex算法、加密算法和消息认证码（MAC）算法）的处理方式有所不同。
SecSh-B uses ECDSA-256/384 for server authentication, user authentication, and in X.509 certificates. [SSH-X509] defines two methods, x509v3-ecdsa-sha2-nistp256 and x509v3-ecdsa-sha2-nistp384, that are to be used for server and user authentication. The following conditions must be met:
SecSh-B使用ECDSA-256/384进行服务器身份验证、用户身份验证和X.509证书中的身份验证。[SSH-X509]定义了两种用于服务器和用户身份验证的方法，即x509v3-ecdsa-sha2-nistp256和x509v3-ecdsa-sha2-nistp384。必须满足以下条件：
1) The server MUST share its public key with the host using an X.509v3 certificate as described in [SSH-X509]. This public key MUST be used to authenticate the server to the host using ECDSA-256 or ECDSA-384 as appropriate (see Section 3).
1) 服务器必须使用[SSH-X509]中所述的X.509v3证书与主机共享其公钥。此公钥必须用于使用ECDSA-256或ECDSA-384（视情况而定）向主机验证服务器（见第3节）。
2) User authentication MUST begin with public key authentication using ECDSA-256/384 with X.509v3 certificates (see Section 4). Additional user authentication methods MAY be used, but only after the certificate-based ECDSA authentication has been successfully completed.
2) 用户身份验证必须从使用ECDSA-256/384和X.509v3证书的公钥身份验证开始（参见第4节）。可以使用其他用户身份验证方法，但只能在成功完成基于证书的ECDSA身份验证后使用。
3) The X.509v3 certificates MUST use only the two Suite B digital signatures, ECDSA-256 and ECDSA-384.
3) X.509v3证书必须仅使用两个套件B数字签名ECDSA-256和ECDSA-384。
4) ECDSA-256 MUST NOT be used to sign an ECDSA-384 public key.
4) ECDSA-256不得用于签署ECDSA-384公钥。
5) ECDSA-384 MAY be used to sign an ECDSA-256 public key.
5) ECDSA-384可用于签署ECDSA-256公钥。
6) At minLOS_192, all SecSh-B implementations MUST be able to verify ECDSA-384 signatures.
6) 在minLOS_192，所有SecSh-B实现必须能够验证ECDSA-384签名。
7) At minLOS_128, all SecSh-B implementations MUST be able to verify ECDSA-256 signatures and SHOULD be able to verify ECDSA-384 signatures, unless it is absolutely certain that the implementation will never need to verify certificates originating from an authority that uses an ECDSA-384 signing key.
7) 在minLOS_128，所有SecSh-B实现必须能够验证ECDSA-256签名，并且应该能够验证ECDSA-384签名，除非绝对确定该实现永远不需要验证来自使用ECDSA-384签名密钥的机构的证书。
8) At minLOS_128, each SecSh-B server and each SecSh-B user MUST have either an ECDSA-256 signing key with a corresponding X.509v3 certificate, an ECDSA-384 signing key with a corresponding X.509v3 certificate, or both.
8) 在minLOS_128，每个SecSh-B服务器和每个SecSh-B用户必须具有带有相应X.509v3证书的ECDSA-256签名密钥、带有相应X.509v3证书的ECDSA-384签名密钥，或者两者都具有。
9) At minLOS_192, each SecSh-B server and each SecSh-B user MUST have an ECDSA-384 signing key with a corresponding X.509v3 certificate.
9) 在minLOS_192，每个SecSh-B服务器和每个SecSh-B用户必须拥有一个ECDSA-384签名密钥和一个相应的X.509v3证书。
The selection of the signature algorithm to be used for server authentication is governed by the server_host_key_algorithms name-list in the SSH_MSG_KEXINIT packet (see Section 3.1). The key exchange and server authentication are performed by the SSH_MSG_KEXECDH_REPLY packets (see Section 4). User authentication is done via the SSH_MSG_USERAUTH_REQUEST messages (see Section 5).
用于服务器身份验证的签名算法的选择由SSH_MSG_KEXINIT数据包中的server_host_key_algorithms name列表管理（参见第3.1节）。密钥交换和服务器身份验证由SSH_MSG_KEXECDH_应答包执行（参见第4节）。用户身份验证通过SSH_MSG_USERAUTH_请求消息完成（参见第5节）。
This section covers the constraints that the choice of minimum security level imposes upon the selection of a key agreement protocol (kex algorithm), encryption algorithm, and data integrity algorithm (MAC algorithm). We divide the non-signature algorithms into two families, as shown in Table 1.
本节介绍选择最低安全级别对选择密钥协商协议（kex算法）、加密算法和数据完整性算法（MAC算法）所施加的约束。我们将非签名算法分为两类，如表1所示。
+--------------+----------------------+----------------------+
| Algorithm | Family 1 | Family 2 |
+==============+======================+======================+
| kex | ecdh-sha2-nistp256 | ecdh-sha2-nistp384 |
+--------------+----------------------+----------------------+
| encryption | AEAD_AES_128_GCM | AEAD_AES_256_GCM |
+--------------+----------------------+----------------------+
| MAC | AEAD_AES_128_GCM | AEAD_AES_256_GCM |
+--------------+-----------------------+---------------------+
+--------------+----------------------+----------------------+
| Algorithm | Family 1 | Family 2 |
+==============+======================+======================+
| kex | ecdh-sha2-nistp256 | ecdh-sha2-nistp384 |
+--------------+----------------------+----------------------+
| encryption | AEAD_AES_128_GCM | AEAD_AES_256_GCM |
+--------------+----------------------+----------------------+
| MAC | AEAD_AES_128_GCM | AEAD_AES_256_GCM |
+--------------+-----------------------+---------------------+
Table 1. Families of Non-Signature Algorithms in SecSh-B
表1。SecSh-B中的非签名算法族
At the 128-bit minimum level of security:
在128位最低安全级别：
o The non-signature algorithms MUST either come exclusively from Family 1 or exclusively from Family 2.
o 非签名算法必须完全来自第1族或第2族。
o The selection of Family 1 versus Family 2 is independent of the choice of server host key algorithm.
o 族1与族2的选择与服务器主机密钥算法的选择无关。
At the 192-bit minimum level of security:
在192位最低安全级别：
o The non-signature algorithms MUST all come from Family 2.
o 非签名算法必须全部来自家族2。
Most of the constraints described in this section can be achieved by severely restricting the kex_algorithm, encryption_algorithm, and mac_algorithm name lists offered in the SSH_MSG_KEXINIT packet. See Section 3.1 for details.
通过严格限制SSH_MSG_KEXINIT数据包中提供的kex_算法、encryption_算法和mac_算法名称列表，可以实现本节中描述的大多数约束。详见第3.1节。
As described in [SSH-Tran], the exchange of SSH_MSG_KEXINIT between the server and the client establishes which key agreement algorithm, MAC algorithm, host key algorithm (server authentication algorithm), and encryption algorithm are to be used. This section describes how the Suite B components are to be used in the Secure Shell algorithm negotiation, key agreement, server authentication, and user authentication.
如[SSH Tran]中所述，服务器和客户端之间的SSH_MSG_KEXINIT交换确定了要使用的密钥协商算法、MAC算法、主机密钥算法（服务器身份验证算法）和加密算法。本节介绍如何在Secure Shell算法协商、密钥协议、服务器身份验证和用户身份验证中使用套件B组件。
Negotiation and initialization of a Suite B Secure Shell connection involves the following Secure Shell messages (where C->S denotes a message from the client to the server, and S->C denotes a server-to-client message):
套件B安全Shell连接的协商和初始化涉及以下安全Shell消息（其中C->S表示从客户端到服务器的消息，S->C表示服务器到客户端的消息）：
SSH_MSG_KEXINIT C->S Contains lists of algorithms acceptable to the client.
SSH_MSG_KEXINIT C->S包含客户端可接受的算法列表。
SSH_MSG_KEXINIT S->C Contains lists of algorithms acceptable to the server.
SSH\u MSG\u KEXINIT S->C包含服务器可接受的算法列表。
SSH_MSG_KEXECDH_INIT C->S Contains the client's ephemeral elliptic curve Diffie-Hellman key.
SSH_MSG_KEXECDH_INIT C->S包含客户端的短暂椭圆曲线Diffie-Hellman密钥。
SSH_MSG_KEXECDH_REPLY S->C Contains a certificate with the server's ECDSA public signature key, the server's ephemeral ECDH contribution, and an ECDSA digital signature of the newly formed exchange hash value.
SSH_MSG_KEXECDH_REPLY S->C包含一个证书，其中包含服务器的ECDSA公共签名密钥、服务器的临时ECDH贡献以及新形成的exchange哈希值的ECDSA数字签名。
SSH_MSG_USERAUTH_REQUEST C->S Contains the user's name, the name of the service the user is requesting, the name of the authentication method the client wishes to use, and method-specific fields.
SSH\u MSG\u USERAUTH\u REQUEST C->S包含用户名、用户请求的服务名称、客户端希望使用的身份验证方法的名称以及特定于方法的字段。
When not in the midst of processing a key exchange, either party may initiate a key re-exchange by sending an SSH_MSG_KEXINIT packet. All packets exchanged during the re-exchange are encrypted and authenticated using the current keys until the conclusion of the re-exchange, at which point an SSH_MSG_NEWKEYS initiates a change to the newly established keys. Otherwise, the re-exchange protocol is identical to the initial key exchange protocol. See Section 9 of [SSH-Tran].
当不在处理密钥交换时，任何一方都可以通过发送SSH_MSG_KEXINIT数据包来启动密钥重新交换。在重新交换期间交换的所有数据包都使用当前密钥进行加密和身份验证，直到重新交换结束，此时SSH_MSG_NEWKEYS开始更改新建立的密钥。否则，重新交换协议与初始密钥交换协议相同。参见[SSH Tran]第9节。
The choice of all but the user authentication methods are determined by the exchange of SSH_MSG_KEXINIT between the client and the server. As described in [SSH-Tran], the SSH_MSG_KEXINIT packet has the following structure:
除了用户身份验证方法之外，其他所有身份验证方法的选择都由客户端和服务器之间的SSH_MSG_KEXINIT交换决定。如[SSH Tran]中所述，SSH_MSG_KEXINIT数据包具有以下结构：
byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) name-list kex_algorithms name-list server_host_key_algorithms name-list encryption_algorithms_client_to_server name-list encryption_algorithms_server_to_client name-list mac_algorithms_client_to_server name-list mac_algorithms_server_to_client name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client name-list languages_client_to_server name-list languages_server_to_client boolean first_kex_packet_follows uint32 0 (reserved for future extension)
字节SSH\u MSG\u KEXINIT字节[16]cookie（随机字节）名称列表kex_算法名称列表服务器主机密钥算法名称列表加密算法客户端到服务器名称列表加密算法服务器到客户端名称列表mac_算法客户端到服务器名称列表mac_算法mac_算法mac_到服务器名称列表mac_算法服务器到客户端名称列表压缩算法客户端到服务器名称列表压缩算法服务器到客户端名称列表语言\u客户端\u到服务器名称列表语言\u服务器\u到客户端布尔值第一个\u kex\u数据包\u在uint32 0之后（保留供将来扩展）
The SSH_MSG_KEXINIT name lists can be used to constrain the choice of non-signature and host key algorithms in accordance with the guidance given in Section 2. Table 2 lists three allowable name lists for the non-signature algorithms. One of these options MUST be used.
SSH_MSG_KEXINIT名称列表可用于根据第2节中给出的指导约束非签名和主机密钥算法的选择。表2列出了非签名算法的三个允许名称列表。必须使用其中一个选项。
Family 1 only (min_LOS 128):
kex_algorithm name_list := { ecdh_sha2_nistp256 }
encryption_algorithm name_list := { AEAD_AES_128_GCM }
mac_algorithm name_list := { AEAD_AES_128_GCM }
Family 1 only (min_LOS 128):
kex_algorithm name_list := { ecdh_sha2_nistp256 }
encryption_algorithm name_list := { AEAD_AES_128_GCM }
mac_algorithm name_list := { AEAD_AES_128_GCM }
Family 2 only (min_LOS 128 or 192):
kex_algorithm name_list := { ecdh_sha2_nistp384 }
encryption_algorithm name_list := { AEAD_AES_256_GCM }
mac_algorithm name_list := { AEAD_AES_256_GCM }
Family 2 only (min_LOS 128 or 192):
kex_algorithm name_list := { ecdh_sha2_nistp384 }
encryption_algorithm name_list := { AEAD_AES_256_GCM }
mac_algorithm name_list := { AEAD_AES_256_GCM }
Family 1 or Family 2 (min_LOS 128):
kex_algorithm name_list := { ecdh_sha2_nistp256,
ecdh_sha2_nistp384 }
encryption_algorithm name_list := { AEAD_AES_128_GCM,
AEAD_AES_256_GCM }
mac_algorithm name_list := { AEAD_AES_128_GCM,
AEAD_AES_256_GCM }
Family 1 or Family 2 (min_LOS 128):
kex_algorithm name_list := { ecdh_sha2_nistp256,
ecdh_sha2_nistp384 }
encryption_algorithm name_list := { AEAD_AES_128_GCM,
AEAD_AES_256_GCM }
mac_algorithm name_list := { AEAD_AES_128_GCM,
AEAD_AES_256_GCM }
Table 2. Allowed Non-Signature Algorithm Name Lists
表2。允许的非签名算法名称列表
Table 3 lists three allowable name lists for the server host key algorithms. One of these options MUST be used.
表3列出了服务器主机密钥算法的三个允许名称列表。必须使用其中一个选项。
ECDSA-256 only (min_LOS 128):
server_host_key_algorithms name_list :=
{ x509v3-ecdsa-sha2-nistp256 }
ECDSA-256 only (min_LOS 128):
server_host_key_algorithms name_list :=
{ x509v3-ecdsa-sha2-nistp256 }
ECDSA-384 only (min_LOS 128 or 192):
server_host_key_algorithms name_list :=
{ x509v3-ecdsa-sha2-nistp384 }
ECDSA-384 only (min_LOS 128 or 192):
server_host_key_algorithms name_list :=
{ x509v3-ecdsa-sha2-nistp384 }
ECDSA-256 or ECDSA-384 (min_LOS 128): server_host_key_algorithms name_list := { x509v3-ecdsa-sha2-nistp256, x509v3-ecdsa-sha2-nistp384 }
ECDSA-256或ECDSA-384（最小值128）：服务器主机密钥算法名称列表：={x509v3-ECDSA-sha2-nistp256，x509v3-ECDSA-sha2-nistp384}
Table 3. Allowed Server Host Key Algorithm Name Lists
表3。允许的服务器主机密钥算法名称列表
SecSh-B uses ECDH to establish a shared secret value between the client and the server. An X.509v3 certificate containing the server's public signing ECDSA key and an ECDSA signature on the exchange hash value derived from the newly established shared secret value are used to authenticate the server to the client.
SecSh-B使用ECDH在客户端和服务器之间建立一个共享的秘密值。使用包含服务器的公共签名ECDSA密钥的X.509v3证书和从新建立的共享密钥值派生的exchange哈希值上的ECDSA签名，向客户端验证服务器。
The key exchange to be used in Secure Shell is determined by the name lists exchanged in the SSH_MSG_KEXINIT packets. In Suite B, one of the following key agreement methods MUST be used to generate a shared secret value (SSV):
Secure Shell中使用的密钥交换由SSH_MSG_KEXINIT数据包中交换的名称列表决定。在套件B中，必须使用以下密钥协商方法之一来生成共享秘密值（SSV）：
ecdh-sha2-nistp256 ephemeral-ephemeral elliptic curve Diffie-Hellman on nistp256 with SHA-256
ecdh-sha2-nistp256带有SHA-256的nistp256上的瞬时椭圆曲线Diffie-Hellman
ecdh-sha2-nistp384 ephemeral-ephemeral elliptic curve Diffie-Hellman on nistp384 with SHA-384
ecdh-sha2-nistp384带有SHA-384的nistp384上的瞬时椭圆曲线Diffie-Hellman
and the format of the SSH_MSG_KEXECDH_INIT message is:
SSH_MSG_KEXECDH_INIT消息的格式为：
byte SSH_MSG_KEXDH_INIT
字节SSH\u MSG\u KEXDH\u INIT
string Q_C // the client's ephemeral contribution to the
// ECDH exchange, encoded as an octet string
string Q_C // the client's ephemeral contribution to the
// ECDH exchange, encoded as an octet string
where the encoding of the elliptic curve point Q_C as an octet string is as specified in Section 2.3.3 of [SEC1].
其中，将椭圆曲线点Q_C编码为八位字节字符串，如[SEC1]第2.3.3节所述。
The SSH_MSG_KEXECDH_REPLY contains the server's contribution to the ECDH exchange, the server's public signature key, and a signature of the exchange hash value formed from the newly established shared secret value. As stated in Section 3.1, in SecSh-B, the server host key algorithm MUST be either x509v3-ecdsa-sha2-nistp256 or x509v3-ecdsa-sha2-nistp384.
SSH_MSG_KEXECDH_回复包含服务器对ECDH交换的贡献、服务器的公共签名密钥以及由新建立的共享秘密值形成的交换哈希值的签名。如第3.1节所述，在SecSh-B中，服务器主机密钥算法必须是x509v3-ecdsa-sha2-nistp256或x509v3-ecdsa-sha2-nistp384。
The format of the SSH_MSG_KEXECDH_REPLY is:
SSH_MSG_KEXECDH_回复的格式为：
byte SSH_MSG_KEXECDH_REPLY
字节SSH\u MSG\u KEXECDH\u回复
string K_S // a string encoding an X.509v3 certificate
// containing the server's ECDSA public host key
string K_S // a string encoding an X.509v3 certificate
// containing the server's ECDSA public host key
string Q_S // the server's ephemeral contribution to the
// ECDH exchange, encoded as an octet string
string Q_S // the server's ephemeral contribution to the
// ECDH exchange, encoded as an octet string
string Sig_S // an octet string containing the server's
// signature of the newly established exchange
// hash value
string Sig_S // an octet string containing the server's
// signature of the newly established exchange
// hash value
Details on the structure and encoding of the X.509v3 certificate can be found in Section 2 of [SSH-X509]. The encoding of the elliptic curve point Q_C as an octet string is as specified in Section 2.3.3 of [SEC1], and the encoding of the ECDSA signature Sig_S as an octet string is as described in Section 3.1.2 of [SSH-ECC].
有关X.509v3证书的结构和编码的详细信息，请参见[SSH-X509]的第2节。将椭圆曲线点Q_C编码为八位字符串如[SEC1]第2.3.3节所述，将ECDSA签名Sig_S编码为八位字符串如[SSH-ECC]第3.1.2节所述。
As specified in [SSH-Tran], the encryption keys and initialization vectors needed by Secure Shell are derived directly from the SSV using the hash function specified by the key agreement algorithm (SHA-256 for ecdh-sha2-nistp256 and SHA-384 for ecdh-sha2-nistp384). The client-to-server channel and the server-to-client channel will have independent keys and initialization vectors. These keys will remain constant until a re-exchange results in the formation of a new SSV.
如[SSH Tran]中所述，Secure Shell所需的加密密钥和初始化向量直接来自SSV，使用密钥协商算法（SHA-256用于ecdh-sha2-nistp256，SHA-384用于ecdh-sha2-nistp384）指定的哈希函数。客户端到服务器通道和服务器到客户端通道将具有独立的密钥和初始化向量。这些密钥将保持不变，直到重新交换导致形成新的SSV。
The Secure Shell Transport Layer Protocol authenticates the server to the host but does not authenticate the user (or the user's host) to the server. For this reason, condition (2) of Section 2.2 requires that all users of SecSh-B MUST be authenticated using ECDSA-256/384 signatures and X.509v3 certificates. [SSH-X509] provides two methods, x509v3-ecdsa-sha2-nistp256 and x509v3-ecdsa-sha2-nistp384, that MUST be used to achieve this goal. At minLOS 128, either one of these methods may be used, but at minLOS 192, x509v3-ecdsa-sha2-nistp384 MUST be used.
Secure Shell传输层协议向主机验证服务器，但不向服务器验证用户（或用户的主机）。因此，第2.2节的条件（2）要求所有SecSh-B用户必须使用ECDSA-256/384签名和X.509v3证书进行身份验证。[SSH-X509]提供了实现此目标必须使用的两种方法，即x509v3-ecdsa-sha2-nistp256和x509v3-ecdsa-sha2-nistp384。在minLOS 128，可以使用这些方法中的任何一种，但在minLOS 192，必须使用x509v3-ecdsa-sha2-nistp384。
The user's public key is sent to the server using an SSH_MSG_USERAUTH_REQUEST message. When an x509v3-ecdsa-sha2-* user authentication method is being used, the structure of the SSH_MSG_USERAUTH_REQUEST message should be:
使用SSH_MSG_USERAUTH_请求消息将用户的公钥发送到服务器。使用x509v3-ecdsa-sha2-*用户身份验证方法时，SSH_MSG_USERAUTH_请求消息的结构应为：
byte SSH_MSG_USERAUTH_REQUEST
字节SSH\u MSG\u USERAUTH\u请求
string user_name // in ISO-10646 UTF-8 encoding
字符串用户名//采用ISO-10646 UTF-8编码
string service_name // service name in US-ASCII
字符串服务\ U名称//US-ASCII格式的服务名称
string "publickey"
字符串“公钥”
boolean FALSE
布尔假
string public_key_algorithm_name // x509v3-ecdsa-sha2-nistp256
// or x509v3-ecdsa-sha2-nistp384
string public_key_algorithm_name // x509v3-ecdsa-sha2-nistp256
// or x509v3-ecdsa-sha2-nistp384
string public_key_blob // X.509v3 certificate
字符串公钥\u blob//X.509v3证书
Details on the structure and encoding of the X.509v3 certificate can be found in Section 2 of [SSH-X509].
有关X.509v3证书的结构和编码的详细信息，请参见[SSH-X509]的第2节。
Once the server has responded to the request message with an SSH_MSG_USERAUTH_PK_OK message, the client uses a second SSH_MSG_USERAUTH_REQUEST message to perform the actual authentication:
一旦服务器使用SSH_MSG_USERAUTH_PK_OK消息响应请求消息，客户端将使用第二条SSH_MSG_USERAUTH_请求消息来执行实际身份验证：
byte SSH_MSG_USERAUTH_REQUEST
字节SSH\u MSG\u USERAUTH\u请求
string user_name // in ISO-10646 UTF-8 encoding
字符串用户名//采用ISO-10646 UTF-8编码
string service_name // service name in US-ASCII
字符串服务\ U名称//US-ASCII格式的服务名称
string "publickey"
字符串“公钥”
boolean TRUE
布尔真
string public_key_algorithm_name // x509v3-ecdsa-sha2-nistp256
// or x509v3-ecdsa-sha2-nistp384
string public_key_algorithm_name // x509v3-ecdsa-sha2-nistp256
// or x509v3-ecdsa-sha2-nistp384
string Sig_U
串信号
The signature field Sig_U is an ECDSA signature of the concatenation of several values, including the session identifier, user name, service name, public key algorithm name, and the user's public signing key. The user's public signing key MUST be the signing key conveyed in the X.509v3 certificate sent in the first SSH_MSG_USERAUTH_REQUEST message. The encoding of the ECDSA signature Sig_U as an octet string is as described in Section 3.1.2 of [SSH-ECC].
签名字段Sig_是多个值串联的ECDSA签名，包括会话标识符、用户名、服务名称、公钥算法名称和用户的公钥。用户的公共签名密钥必须是在第一条SSH_MSG_USERAUTH_请求消息中发送的X.509v3证书中传递的签名密钥。ECDSA签名Sig_的编码为八位字节字符串，如[SSH-ECC]第3.1.2节所述。
The server MUST respond with either SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed) or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications are needed).
服务器必须响应SSH_MSG_USERAUTH_SUCCESS（如果不需要更多身份验证）或SSH_MSG_USERAUTH_FAILURE（如果请求失败，或需要更多身份验证）。
Secure Shell transfers data between the client and the server using its own binary packet structure. The SSH binary packet structure is independent of any packet structure on the underlying data channel. The contents of each binary packet and portions of the header are encrypted, and each packet is authenticated with its own message authentication code. AES GCM will both encrypt the packet and form a 16-octet authentication tag to ensure data integrity.
Secure Shell使用自己的二进制数据包结构在客户端和服务器之间传输数据。SSH二进制数据包结构独立于底层数据通道上的任何数据包结构。每个二进制数据包的内容和报头的部分都被加密，每个数据包都用自己的消息认证码进行认证。AES GCM将对数据包进行加密，并形成一个16字节的身份验证标签，以确保数据完整性。
[SSH-GCM] describes how AES Galois/Counter Mode is to be used in Secure Shell. Suite B SSH implementations MUST support AEAD_AES_GCM_128 and SHOULD support AEAD_AES_GCM_256 to both provide confidentiality and ensure data integrity. No other confidentiality or data integrity algorithms are permitted.
[SSH-GCM]描述了如何在安全Shell中使用AES伽罗瓦/计数器模式。套件B SSH实现必须支持AEAD_AES_GCM_128，并应支持AEAD_AES_GCM_256，以提供机密性并确保数据完整性。不允许使用其他保密性或数据完整性算法。
These algorithms rely on two counters:
这些算法依赖于两个计数器：
Invocation Counter: A 64-bit integer, incremented after each call to AES-GCM to process an SSH binary packet. The initial value of the invocation counter is determined by the SSH initialization vector.
调用计数器：一个64位整数，在每次调用AES-GCM以处理SSH二进制数据包后递增。调用计数器的初始值由SSH初始化向量确定。
Block Counter: A 32-bit integer, set to one at the start of each new SSH binary packet and incremented as each 16-octet block of data is processed.
块计数器：一个32位整数，在每个新SSH二进制数据包的开头设置为1，并在处理每个16个八位字节的数据块时递增。
Ensuring that these counters are properly implemented is crucial to the security of the system. The reader is referred to [SSH-GCM] for details on the format, initialization, and usage of these counters and their relationship to the initialization vector and the SSV.
确保正确实施这些计数器对于系统的安全至关重要。读者可参考[SSH-GCM]了解这些计数器的格式、初始化和使用以及它们与初始化向量和SSV的关系的详细信息。
The reader is reminded that, as specified in [SSH-GCM], Suite B requires that all 16 octets of the authentication tag MUST be used as the SSH data integrity value of the SSH binary packet.
提醒读者，如[SSH-GCM]中所述，套件B要求身份验证标签的所有16个八位字节必须用作SSH二进制数据包的SSH数据完整性值。
Secure Shell allows either the server or client to request that the Secure Shell connection be rekeyed. Suite B places no constraints on how frequently this is to be done, but it does require that the cipher suite being employed MUST NOT be changed when a rekey occurs.
Secure Shell允许服务器或客户端请求重新设置Secure Shell连接的密钥。套件B对执行此操作的频率没有限制，但它确实要求在发生重新密钥时不得更改所使用的密码套件。
When using ecdh_sha2_nistp256, each exponent used in the key exchange must have 256 bits of entropy. Similarly, when using ecdh_sha2_nistp384, each exponent used in the key exchange must have 384 bits of entropy. The security considerations of [SSH-Arch] apply.
使用ecdh_sha2_nistp256时，密钥交换中使用的每个指数必须具有256位熵。类似地，当使用ecdh_sha2_nistp384时，密钥交换中使用的每个指数必须具有384位熵。[SSH Arch]的安全注意事项适用。
[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月。
[SUITEBCERT] Solinas, J. and L. Zieglar, "Suite B Certificate and Certificate Revocation List (CRL) Profile", RFC 5759, January 2010.
[SUITEBCERT]Solinas，J.和L.Zieglar，“套件B证书和证书撤销列表（CRL）配置文件”，RFC 5759，2010年1月。
[SSH-Arch] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH Arch]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）协议架构”，RFC 4251，2006年1月。
[SSH-Tran] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH Tran]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[SSH-ECC] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, December 2009.
[SSH-ECC]Stebila，D.和J.Green，“安全外壳传输层中的椭圆曲线算法集成”，RFC 56562009年12月。
[SSH-GCM] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", RFC 5647, August 2009.
[SSH-GCM]Igoe，K.和J.Solinas，“安全外壳传输层协议的AES伽罗瓦计数器模式”，RFC 5647，2009年8月。
[SSH-X509] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, March 2011.
[SSH-X509]Igoe，K.和D.Stebila，“用于安全Shell身份验证的X.509v3证书”，RFC 6187，2011年3月。
[NIST] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication 186-3.
[NIST]国家标准与技术研究所，“数字签名标准（DSS）”，联邦信息处理标准出版物186-3。
[SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1 v2.0, May 2009, <http://www.secg.org/download/aid-780/sec1-v2.pdf>.
[SEC1]高效密码标准组，“椭圆曲线密码术”，第1卷第2.0版，2009年5月<http://www.secg.org/download/aid-780/sec1-v2.pdf>.
[SEC2] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2 v1.0, September 2000. <http://www.secg.org/download/aid-386/ sec2_final.pdf>.
[SEC2]高效密码标准组，“建议的椭圆曲线域参数”，第2卷第1.0版，2000年9月<http://www.secg.org/download/aid-386/ sec2_final.pdf>。
Author's Address
作者地址
Kevin M. Igoe NSA/CSS Commercial Solutions Center National Security Agency
Kevin M.Igoe NSA/CSS商业解决方案中心国家安全局
EMail: kmigoe@nsa.gov
EMail: kmigoe@nsa.gov