[要約] RFC 6239は、Secure Shell (SSH) プロトコルにおけるSuite Bの暗号スイートに関する仕様を定義しています。この文書の目的は、米国国家安全保障局(NSA)によって定義されたSuite Bの暗号アルゴリズムをSSHプロトコルで使用するためのガイドラインを提供することです。これにより、政府機関やセキュリティが重要な環境でのデータの安全な交換が可能になります。RFC 6239は、特に高度なセキュリティ要件を持つシステムでの利用を想定しており、関連するRFCにはRFC 4251（SSHプロトコルアーキテクチャ）、RFC 4253（SSHトランスポート層プロトコル）などがあります。
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)
セキュアシェル（SSH）用のスイートB暗号スイート
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.
このドキュメントでは、Secure Shell Transport Layer ProtocolとSecure Shell Authentication ProtocolのSuite B準拠の実装のアーキテクチャについて説明します。 Suite B Secure Shellは、SHAの2つのメンバーである楕円曲線Diffie-Hellman（ECDH）鍵合意、楕円曲線デジタル署名アルゴリズム（ECDSA）、ガロア/カウンターモード（AES-GCM）で実行されるAdvanced Encryption Standardを利用します。 -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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2011 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
このドキュメントでは、Secure Shell Transport Layer ProtocolとSecure Shell Authentication ProtocolのSuite B準拠の実装のアーキテクチャについて説明します。 Suite B Secure Shellは、SHAの2つのメンバーである楕円曲線Diffie-Hellman（ECDH）鍵合意、楕円曲線デジタル署名アルゴリズム（ECDSA）、ガロア/カウンターモード（AES-GCM）で実行されるAdvanced Encryption Standardを利用します。 -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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Several RFCs have documented how each of the Suite B components are to be integrated into Secure Shell (SSH):
いくつかのRFCは、Suite BコンポーネントのそれぞれをSecure Shell（SSH）に統合する方法を文書化しています。
kex algorithms ecdh-sha2-nistp256 [SSH-ECC] ecdh-sha2-nistp384 [SSH-ECC]
Cux Aljurithems
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]
暗号化アルゴリズム（client_to_serverとserver_to_clientの両方）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アルゴリズム（client_to_serverとserver_to_clientの両方）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.
このドキュメントの目的は、これらすべてのドキュメントを利用して、Secure Shell（以降、「SecSh-B」と呼ぶ）のSuite 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.
Suite Bで使用される2つの楕円曲線は、2つの異なる名前で文献に記載されています。わかりやすくするために、両方の名前を以下に示します。
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).
Suite Bは、128ビットの最小レベルのセキュリティ（minLOS_128）と192ビットの最小レベルのセキュリティ（minLOS_192）の2つのレベルの暗号化セキュリティを提供します。以下で説明するように、ECDSA-256 / 384署名アルゴリズムと対応するX.509v3証明書は、非署名プリミティブ（kexアルゴリズム、暗号化アルゴリズム、Secure Shell用語でのメッセージ認証コード（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は、サーバー認証、ユーザー認証、およびX.509証明書でECDSA-256 / 384を使用します。 [SSH-X509]は、x509v3-ecdsa-sha2-nistp256とx509v3-ecdsa-sha2-nistp384の2つの方法を定義しています。これらは、サーバーとユーザーの認証に使用されます。以下の条件を満たす必要があります。
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）ユーザー認証は、X.509v3証明書でECDSA-256 / 384を使用する公開鍵認証で始まる必要があります（セクション4を参照）。追加のユーザー認証方法が使用される場合がありますが、それは証明書ベースのECDSA認証が正常に完了した後でのみです。
3) The X.509v3 certificates MUST use only the two Suite B digital signatures, ECDSA-256 and ECDSA-384.
3）X.509v3証明書は、2つのSuite 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署名を検証できなければなりません（MUST）。
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署名鍵。
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ユーザーは、対応するX.509v3証明書を持つECDSA-384署名鍵を持っている必要があります。
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名前リストによって制御されます（セクション3.1を参照）。鍵交換とサーバー認証は、SSH_MSG_KEXECDH_REPLYパケットによって実行されます（セクション4を参照）。ユーザー認証は、SSH_MSG_USERAUTH_REQUESTメッセージを介して行われます（セクション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に示すように、非署名アルゴリズムを2つのファミリーに分割します。
+--------------+----------------------+----------------------+
| 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_algorithm、encryption_algorithm、およびmac_algorithmの名前リストを厳しく制限することで達成できます。詳細については、セクション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アルゴリズムネゴシエーション、鍵合意、サーバー認証、およびユーザー認証でSuite 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):
Suite BのSecure Shell接続のネゴシエーションと初期化には、次のSecure 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_MSG_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貢献、および新しく形成された交換ハッシュ値の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_MSG_USERAUTH_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_MSG_KEXINITバイト[16] Cookie（ランダムバイト）名前リストkex_algorithms名前リストserver_host_key_algorithms名前リストencryption_algorithms_client_to_server名前リストencryption_algorithms_server_to_client name-list mac_algorithms_client_to_server name-server_client_to_list_client_to_client_list_client_to_client_list_client_to_client_list_client_to_client_list_client_to_client_to_client_to_server_client_to_client_to_server_client_to_client_to_server_client_to_server_client_to_server_client_to_server_client_to_server_client_to_server_client_to_client_to_list languages_server_to_client boolean first_kex_packet_follows 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に、非署名アルゴリズムに使用できる3つの名前リストを示します。これらのオプションの1つを使用する必要があります。
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 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は、サーバーホストキーアルゴリズムに使用できる3つの名前リストを示しています。これらのオプションの1つを使用する必要があります。
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-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（min_LOS 128）：server_host_key_algorithms name_list：= {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証明書と、新しく確立された共有秘密値から派生した交換ハッシュ値の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 ephemeral-ephemeral楕円曲線Diffie-HellmanとSHA-256を使用したnistp256
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_MSG_KEXDH_INIT
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_REPLYには、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_REPLYの形式は次のとおりです。
byte SSH_MSG_KEXECDH_REPLY
バイトSSH_MSG_KEXECDH_REPLY
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 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で必要な暗号化キーと初期化ベクトルは、鍵合意アルゴリズムで指定されたハッシュ関数（ecdh-sha2-nistp256の場合はSHA-256、 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 Transport Layer Protocolは、サーバーをホストに対して認証しますが、ユーザー（またはユーザーのホスト）をサーバーに対して認証しません。このため、セクション2.2の条件（2）では、SecSh-BのすべてのユーザーがECDSA-256 / 384署名とX.509v3証明書を使用して認証される必要があります。 [SSH-X509]は、x509v3-ecdsa-sha2-nistp256とx509v3-ecdsa-sha2-nistp384の2つのメソッドを提供します。これらは、この目標を達成するために使用する必要があります。 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_REQUESTメッセージを使用してサーバーに送信されます。 x509v3-ecdsa-sha2- *ユーザー認証方式が使用されている場合、SSH_MSG_USERAUTH_REQUESTメッセージの構造は次のようになります。
byte SSH_MSG_USERAUTH_REQUEST
バイトSSH_MSG_USERAUTH_REQUEST
string user_name // in ISO-10646 UTF-8 encoding
string user_name // ISO-10646 UTF-8エンコーディング
string service_name // service name in US-ASCII
string service_name // US-ASCIIのサービス名
string "publickey"
文字列「publickey」
boolean FALSE string public_key_algorithm_name // x509v3-ecdsa-sha2-nistp256 // or x509v3-ecdsa-sha2-nistp384
ブールFALSE文字列public_key_algorithm_name // x509v3-ecdsa-sha2-nistp256 //またはx509v3-ecdsa-sha2-nistp384
string public_key_blob // X.509v3 certificate
string public_key_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メッセージで要求メッセージに応答すると、クライアントは2番目のSSH_MSG_USERAUTH_REQUESTメッセージを使用して実際の認証を実行します。
byte SSH_MSG_USERAUTH_REQUEST
バイトSSH_MSG_USERAUTH_REQUEST
string user_name // in ISO-10646 UTF-8 encoding
string user_name // ISO-10646 UTF-8エンコーディング
string service_name // service name in US-ASCII
string service_name // US-ASCIIのサービス名
string "publickey"
文字列「publickey」
boolean TRUE
ブールTRUE
string public_key_algorithm_name // x509v3-ecdsa-sha2-nistp256
// or x509v3-ecdsa-sha2-nistp384
string Sig_U
文字列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_Uは、セッションID、ユーザー名、サービス名、公開鍵アルゴリズム名、ユーザーの公開署名鍵など、いくつかの値を連結したECDSA署名です。ユーザーの公開署名鍵は、最初のSSH_MSG_USERAUTH_REQUESTメッセージで送信されるX.509v3証明書で伝達される署名鍵でなければなりません。オクテット文字列としてのECDSA署名Sig_Uのエンコードは、[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]は、AES Galois / Counter ModeがSecure Shellでどのように使用されるかを説明しています。スイートBのSSH実装は、機密性を提供し、データの整合性を確保するために、AEAD_AES_GCM_128をサポートする必要があり、AEAD_AES_GCM_256をサポートする必要があります（SHOULD）。他の機密性またはデータ整合性アルゴリズムは許可されていません。
These algorithms rely on two counters:
これらのアルゴリズムは、次の2つのカウンターに依存しています。
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ビット整数。SSHバイナリパケットを処理するためにAES-GCMを呼び出すたびに増加します。呼び出しカウンターの初期値は、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.
これらのカウンタが適切に実装されていることを確認することは、システムのセキュリティにとって重要です。これらのカウンタの形式、初期化、使用方法、および初期化ベクトルとSSVとの関係については、[SSH-GCM]を参照してください。
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]で指定されているように、Suite 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.
セキュアシェルを使用すると、サーバーまたはクライアントのいずれかが、セキュアシェル接続の鍵の再生成を要求できます。スイート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、「Suite B Certificate and Certificate Revocation List（CRL）Profile」、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。、「The Secure Shell（SSH）Protocol Architecture」、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、編、「The Secure Shell（SSH）Transport Layer Protocol」、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、「Secure Shell Transport Layerにおける楕円曲線アルゴリズムの統合」、RFC 5656、2009年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、「Secure Shell Transport Layer ProtocolのAES Galoisカウンターモード」、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、「Secure Shell Authenticationの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] Standards for Efficient Cryptography Group、「Elliptic Curve Cryptography」、SEC 1 v2.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] Standards for Efficient Cryptography Group、「Recommended Elliptic Curve Domain Parameters」、SEC 2 v1.0、September2000。<http://www.secg.org/download/aid-386/sec2_final.pdf>。
Author's Address
著者のアドレス
Kevin M. Igoe NSA/CSS Commercial Solutions Center National Security Agency
ケビンM.イゴエNSA / CSSコマーシャルソリューションセンター国家安全保障局
EMail: kmigoe@nsa.gov