[要約] RFC 7427は、インターネットキー交換プロトコルバージョン2（IKEv2）におけるデジタル署名認証のメカニズムを定義しています。この文書の目的は、IKEv2で使用されるデジタル署名の生成と検証のプロセスを標準化することにより、セキュリティを強化することです。利用場面としては、VPN接続やIPsecセキュリティアソシエーションの確立時に、相互認証とデータの完全性保護を提供します。関連するRFCには、RFC 7296（IKEv2の仕様を更新する）やRFC 7427を拡張または参照する後続の文書が含まれます。
Internet Engineering Task Force (IETF) T. Kivinen
Request for Comments: 7427 INSIDE Secure
Updates: 7296 J. Snyder
Category: Standards Track Opus One
ISSN: 2070-1721 January 2015
Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
インターネットキーエクスチェンジバージョン2（IKEv2）での署名認証
Abstract
概要
The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms.
Internet Key Exchange Version 2（IKEv2）プロトコルは、Elliptic Curve Digital Signature Algorithm（ECDSA）のサポートに制限があります。現在のバージョンでは、3つの楕円曲線グループのサポートのみが含まれており、各グループには固定ハッシュアルゴリズムが関連付けられています。このドキュメントでは、IKEv2署名のサポートを一般化して、PKIXでサポートされている任意の署名方法を許可し、署名ハッシュアルゴリズムのネゴシエーションも追加しています。これは一般的なメカニズムであり、ECDSAに限定されません。他の署名アルゴリズムと共に使用することもできます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7427.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7427で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Authentication Payload . . . . . . . . . . . . . . . . . . . 4
4. Hash Algorithm Notification . . . . . . . . . . . . . . . . . 6
5. Selecting the Public Key Algorithm . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Commonly Used ASN.1 Objects . . . . . . . . . . . . 12
A.1. PKCS#1 1.5 RSA Encryption . . . . . . . . . . . . . . . . 12
A.1.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . 12
A.1.2. sha256WithRSAEncryption . . . . . . . . . . . . . . . 12
A.1.3. sha384WithRSAEncryption . . . . . . . . . . . . . . . 13
A.1.4. sha512WithRSAEncryption . . . . . . . . . . . . . . . 13
A.2. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2.1. dsa-with-sha1 . . . . . . . . . . . . . . . . . . . . 13
A.2.2. dsa-with-sha256 . . . . . . . . . . . . . . . . . . . 14
A.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.3.1. ecdsa-with-sha1 . . . . . . . . . . . . . . . . . . . 14
A.3.2. ecdsa-with-sha256 . . . . . . . . . . . . . . . . . . 14
A.3.3. ecdsa-with-sha384 . . . . . . . . . . . . . . . . . . 15
A.3.4. ecdsa-with-sha512 . . . . . . . . . . . . . . . . . . 15
A.4. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . 15
A.4.1. RSASSA-PSS with Empty Parameters . . . . . . . . . . 15
A.4.2. RSASSA-PSS with Default Parameters . . . . . . . . . 16
A.4.3. RSASSA-PSS with SHA-256 . . . . . . . . . . . . . . . 17
Appendix B. IKEv2 Payload Example . . . . . . . . . . . . . . . 17
B.1. sha1WithRSAEncryption . . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
This document adds a new IKEv2 [RFC7296] authentication method to support signature methods in a more general way. The current signature-based authentication methods in IKEv2 are per algorithm, i.e., there is one for RSA digital signatures, one for DSS digital signatures (using SHA-1), and three for different ECDSA curves, each tied to exactly one hash algorithm. This design is cumbersome when more signature algorithms, hash algorithms, and elliptic curves need to be supported: o In IKEv2, authentication using RSA digital signatures calls for padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA-PSS padding method is now recommended. (See Section 5 of "Additional Algorithms and Identifiers for RSA Cryptography for use in PKIX Profile" [RFC4055].)
このドキュメントでは、新しいIKEv2 [RFC7296]認証方式を追加して、より一般的な方法で署名方式をサポートしています。 IKEv2の現在の署名ベースの認証方法はアルゴリズムごとです。つまり、RSAデジタル署名用に1つ、DSSデジタル署名用（SHA-1を使用）用に1つ、異なるECDSA曲線用に3つあり、それぞれ正確に1つのハッシュアルゴリズムに関連付けられています。この設計は、より多くの署名アルゴリズム、ハッシュアルゴリズム、および楕円曲線をサポートする必要がある場合に扱いにくくなります。oIKEv2では、RSASAデジタル署名を使用した認証により、RSASSA-PKCS1-v1_5に基づくパディングが要求されますが、新しいRSASSA-PSSパディング方法が使用されるようになりました。お勧めします。 （「PKIXプロファイルで使用するためのRSA暗号化の追加のアルゴリズムと識別子」[RFC4055]のセクション5を参照してください。）
o With ECDSA and the Digital Signature Standard (DSS), there is no way to extract the hash algorithm from the signature. Thus, for each new hash function to be supported with ECDSA or DSA, new authentication methods would be needed. Support for new hash functions is particularly needed for DSS, because the current restriction to SHA-1 limits its security, meaning there is no point of using long keys with SHA-1.
o ECDSAとデジタル署名標準（DSS）では、署名からハッシュアルゴリズムを抽出する方法はありません。したがって、ECDSAまたはDSAでサポートされる新しいハッシュ関数ごとに、新しい認証方法が必要になります。 SHA-1に対する現在の制限はセキュリティを制限するため、新しいハッシュ関数のサポートは特にDSSに必要です。つまり、SHA-1で長いキーを使用する意味はありません。
o The tying of ECDSA authentication methods to particular elliptic curve groups requires definition of additional methods for each new group. The combination of new ECDSA groups and hash functions will cause the number of required authentication methods to become unmanageable. Furthermore, the restriction of ECDSA authentication to a specific group is inconsistent with the approach taken with DSS.
o ECDSA認証方法を特定の楕円曲線グループに関連付けるには、新しいグループごとに追加の方法を定義する必要があります。新しいECDSAグループとハッシュ関数を組み合わせると、必要な認証方法の数が管理できなくなります。さらに、特定のグループへのECDSA認証の制限は、DSSで採用されたアプローチと一致しません。
With the selection of SHA-3, it might be possible that a signature method can be used with either SHA-3 or SHA-2. This means that a new mechanism for negotiating the hash algorithm for a signature algorithm is needed.
SHA-3を選択すると、SHA-3またはSHA-2のいずれかで署名方式を使用できる可能性があります。これは、署名アルゴリズムのハッシュアルゴリズムをネゴシエートするための新しいメカニズムが必要であることを意味します。
This document specifies two things:
このドキュメントでは、次の2つを指定しています。
1. A new authentication method that includes enough information inside the Authentication payload data so the signature hash algorithm can be extracted (see Section 3).
1. 署名ハッシュアルゴリズムを抽出できるように、認証ペイロードデータ内に十分な情報を含む新しい認証方法（セクション3を参照）。
2. A method to indicate supported signature hash algorithms (see Section 4). This allows the peer to know which hash algorithms are supported by the other end and use one of them (provided one is allowed by policy). There is no requirement to actually negotiate one common hash algorithm, as different hash algorithms can be used in different directions if needed.
2. サポートされている署名ハッシュアルゴリズムを示す方法（セクション4を参照）。これにより、ピアは相手側でどのハッシュアルゴリズムがサポートされているかを把握し、そのうちの1つを使用できます（ポリシーで許可されている場合）。必要に応じて異なる方向で異なるハッシュアルゴリズムを使用できるため、1つの共通ハッシュアルゴリズムを実際にネゴシエートする必要はありません。
The new digital signature method is flexible enough to include all current signature methods (RSA, DSA, ECDSA, RSASSA-PSS, etc.) and add new methods (ECGDSA, ElGamal, etc.) in the future. To support this flexibility, the signature algorithm is specified in the same way that PKIX [RFC5280] specifies the signature of the Digital Certificate, by placing a simple ASN.1 object before the actual signature data. This ASN.1 object contains an OID specifying the algorithm and associated parameters. When an IKEv2 implementation supports a fixed set of signature methods with commonly used parameters, it is acceptable for the implementation to treat the ASN.1 object as a binary blob that can be compared against the fixed set of known values. IKEv2 implementations can also parse the ASN.1 and extract the signature algorithm and associated parameters.
新しいデジタル署名方法は、現在のすべての署名方法（RSA、DSA、ECDSA、RSASSA-PSSなど）を含め、将来新しい方法（ECGDSA、ElGamalなど）を追加できるほど柔軟です。この柔軟性をサポートするために、実際の署名データの前に単純なASN.1オブジェクトを配置することにより、PKIX [RFC5280]がデジタル証明書の署名を指定するのと同じ方法で署名アルゴリズムを指定します。このASN.1オブジェクトには、アルゴリズムと関連パラメーターを指定するOIDが含まれています。 IKEv2実装が、一般的に使用されるパラメーターを持つ一連の署名メソッドの固定セットをサポートする場合、実装は、ASN.1オブジェクトを既知の値の固定セットと比較できるバイナリBLOBとして扱うことは許容されます。 IKEv2実装では、ASN.1を解析し、署名アルゴリズムと関連パラメーターを抽出することもできます。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document specifies a new "Digital Signature" authentication method. This method can be used with any type of signature. As the authentication methods are not negotiated in IKEv2, the peer is only allowed to use this authentication method if the Notify payload of type SIGNATURE_HASH_ALGORITHMS has been sent and received by each peer.
このドキュメントでは、新しい「デジタル署名」認証方法について説明します。このメソッドは、任意のタイプの署名で使用できます。認証方式はIKEv2でネゴシエートされないため、ピアがこの認証方式を使用できるのは、タイプSIGNATURE_HASH_ALGORITHMSの通知ペイロードが各ピアによって送受信された場合のみです。
In this authentication method, the Authentication Data field inside the Authentication payload does not just include the signature value, as do other existing IKEv2 Authentication payloads. Instead, the signature value is prefixed with an ASN.1 object indicating the algorithm used to generate the signature. The ASN.1 object contains the algorithm identification OID, which identifies both the signature algorithm and the hash used when calculating the signature. In addition to the OID, the ASN.1 object can contain optional parameters that might be needed for algorithms such as RSASSA-PSS (see Section 8.1 of [RFC3447]).
この認証方法では、認証ペイロード内の認証データフィールドには、他の既存のIKEv2認証ペイロードと同様に、署名値だけが含まれていません。代わりに、署名値の前に、署名の生成に使用されるアルゴリズムを示すASN.1オブジェクトが付けられます。 ASN.1オブジェクトには、アルゴリズムの識別OIDが含まれています。これは、署名アルゴリズムと、署名の計算時に使用されるハッシュの両方を識別します。 OIDに加えて、ASN.1オブジェクトには、RSASSA-PSSなどのアルゴリズムに必要になる可能性があるオプションのパラメーターを含めることができます（[RFC3447]のセクション8.1を参照）。
To make implementations easier, the ASN.1 object is prefixed by the 8-bit length field. This length field allows simple implementations to know the length of the ASN.1 object without the need to parse it, so they can use it as a binary blob to be compared against known signature algorithm ASN.1 objects. Thus, simple implementations may not need to be able to parse or generate ASN.1 objects. See Appendix A for commonly used ASN.1 objects.
実装を簡単にするために、ASN.1オブジェクトの前には8ビットの長さフィールドが付けられます。この長さフィールドを使用すると、単純な実装で、解析する必要なくASN.1オブジェクトの長さを認識できるため、既知の署名アルゴリズムASN.1オブジェクトと比較するバイナリBLOBとして使用できます。したがって、単純な実装では、ASN.1オブジェクトを解析または生成できる必要はありません。一般的に使用されるASN.1オブジェクトについては、付録Aを参照してください。
The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. The algorithm OID inside the ASN.1 specifies the signature algorithm and the hash function, both of which are needed for signature verification.
ここで使用されるASN.1は、PKIXのAlgorithmIdentifier（[RFC5280]のセクション4.1.1.2を参照）で使用されるASN.1と同じであり、識別符号化規則（DER）[CCITT.X690.2002]を使用して符号化されます。 ASN.1内のアルゴリズムOIDは、署名検証に必要な署名アルゴリズムとハッシュ関数を指定します。
Currently, only the RSASSA-PSS signature algorithm uses the optional parameters. For other signature algorithms, the parameters are either NULL or missing. Note that for some algorithms there are two possible ASN.1 encodings, one with optional parameters included but set to NULL and the other where the optional parameters are omitted. These dual encodings exist because of the way those algorithms are specified. When encoding the ASN.1, implementations SHOULD use the preferred format called for by the algorithm specification. If the algorithm specification says "preferredPresent", then the parameters object needs to be present, although it will be NULL if no parameters are specified. If the algorithm specification says "preferredAbsent", then the entire optional parameters object is missing.
現在、RSASSA-PSS署名アルゴリズムのみがオプションのパラメーターを使用しています。他の署名アルゴリズムの場合、パラメーターはNULLまたは欠落しています。一部のアルゴリズムでは、2つの可能なASN.1エンコーディングが存在することに注意してください。1つはオプションのパラメーターが含まれているがNULLに設定されているもので、もう1つはオプションのパラメーターが省略されているものです。これらのデュアルエンコーディングは、これらのアルゴリズムの指定方法が原因で存在します。 ASN.1をエンコードするとき、実装では、アルゴリズム仕様で呼び出される優先形式を使用する必要があります（SHOULD）。アルゴリズム仕様に「preferredPresent」と記載されている場合、パラメーターオブジェクトが存在する必要がありますが、パラメーターが指定されていない場合はNULLになります。アルゴリズムの仕様に「preferredAbsent」と記載されている場合、オプションのパラメーターオブジェクト全体が欠落しています。
The Authentication payload is defined in IKEv2 as follows:
認証ペイロードは、IKEv2で次のように定義されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Authentication Payload Format
図1：認証ペイロードの形式
o Auth Method (1 octet) - Specifies the method of authentication used.
o Auth Method（1 octet）-使用する認証方法を指定します。
Mechanism Value
-----------------------------------------------------------------
Digital Signature 14
Computed as specified in Section 2.15 of [RFC7296] using a private key associated with the public key sent in the Certificate payload and using one of the hash algorithms sent by the other end in the Notify payload of type SIGNATURE_HASH_ALGORITHMS. If both ends send and receive SIGNATURE_HASH_ALGORITHMS Notify payloads, and signature authentication is to be used, then the authentication method specified in this Authentication payload MUST be used. The format of the Authentication Data field is different from other Authentication methods and is specified below.
[RFC7296]のセクション2.15で指定されているように、証明書ペイロードで送信された公開鍵に関連付けられた秘密鍵を使用し、タイプSIGNATURE_HASH_ALGORITHMSの通知ペイロードで、反対側から送信されたハッシュアルゴリズムの1つを使用して計算されます。両端がSIGNATURE_HASH_ALGORITHMS Notifyペイロードを送受信し、署名認証が使用される場合、この認証ペイロードで指定された認証方法を使用する必要があります。 [認証データ]フィールドの形式は他の認証方法とは異なり、以下に指定されています。
o Authentication Data (variable length) - See Section 2.15 of [RFC7296]. For "Digital Signature" format, the Authentication Data is formatted as follows:
o 認証データ（可変長）-[RFC7296]のセクション2.15を参照してください。 「デジタル署名」フォーマットの場合、認証データは次のようにフォーマットされます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN.1 Length | AlgorithmIdentifier ASN.1 object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ AlgorithmIdentifier ASN.1 object continuing ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Authentication Data Format
図2：認証データ形式
* ASN.1 Length (1 octet) - This field contains the length of the ASN.1-encoded AlgorithmIdentifier object.
* ASN.1長さ（1オクテット）-このフィールドには、ASN.1でエンコードされたAlgorithmIdentifierオブジェクトの長さが含まれます。
* Algorithm Identifier (variable length) - This field contains the AlgorithmIdentifier ASN.1 object.
* アルゴリズム識別子（可変長）-このフィールドには、AlgorithmIdentifier ASN.1オブジェクトが含まれます。
* Signature Value (variable length) - This field contains the actual signature value.
* 署名値（可変長）-このフィールドには、実際の署名値が含まれます。
There is no padding between the ASN.1 object and the signature value. For hash truncation, the method specified in ANSI X9.62:2005 [X9.62] MUST be used.
ASN.1オブジェクトと署名値の間にパディングはありません。ハッシュの切り捨てについては、ANSI X9.62：2005 [X9.62]で指定されている方法を使用する必要があります。
The supported hash algorithms that can be used for the signature algorithms are indicated with a Notify payload of type SIGNATURE_HASH_ALGORITHMS sent inside the IKE_SA_INIT exchange.
署名アルゴリズムに使用できるサポートされているハッシュアルゴリズムは、IKE_SA_INIT交換内で送信されるSIGNATURE_HASH_ALGORITHMSタイプのNotifyペイロードで示されます。
This notification also implicitly indicates support of the new "Digital Signature" algorithm method, as well as the list of hash functions supported by the sending peer.
この通知は、新しい「デジタル署名」アルゴリズムメソッドのサポートと、送信側ピアがサポートするハッシュ関数のリストも暗黙的に示しています。
Both ends send their list of supported hash algorithms. When calculating the digital signature, a peer MUST pick one algorithm sent by the other peer. Note that different algorithms can be used in different directions. The algorithm OID indicating the selected hash algorithm (and signature algorithm) used when calculating the signature is sent inside the Authentication Data field of the Authentication payload (with Auth Method of "Digital Signature" as defined above).
両端はサポートされているハッシュアルゴリズムのリストを送信します。デジタル署名を計算するとき、ピアは他のピアによって送信された1つのアルゴリズムを選択する必要があります。異なるアルゴリズムを異なる方向で使用できることに注意してください。署名の計算時に使用される、選択されたハッシュアルゴリズム（および署名アルゴリズム）を示すアルゴリズムOIDが、認証ペイロードの認証データフィールド内に送信されます（上記で定義された「デジタル署名」の認証方法を使用）。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Notify Payload Format
図3：通知ペイロード形式
The Notify payload format is defined in Section 3.10 of [RFC7296]. When a Notify payload of type SIGNATURE_HASH_ALGORITHMS is sent, the Protocol ID field is set to 0, the SPI Size is set to 0, and the Notify Message Type is set to 16431.
Notifyペイロード形式は、[RFC7296]のセクション3.10で定義されています。タイプSIGNATURE_HASH_ALGORITHMSの通知ペイロードが送信されると、プロトコルIDフィールドは0に設定され、SPIサイズは0に設定され、通知メッセージタイプは16431に設定されます。
The Notification Data field contains the list of 16-bit hash algorithm identifiers from the Hash Algorithm Identifiers of IANA's "Internet Key Exchange Version 2 (IKEv2) Parameters" registry. There is no padding between the hash algorithm identifiers.
通知データフィールドには、IANAの「インターネットキーエクスチェンジバージョン2（IKEv2）パラメータ」レジストリのハッシュアルゴリズム識別子からの16ビットハッシュアルゴリズム識別子のリストが含まれています。ハッシュアルゴリズム識別子の間にパディングはありません。
This specification does not provide a way for the peers to indicate the public/private key pair types they have. This raises the question of how the responder selects a public/private key pair type that the initiator supports. This information can be found by several methods.
この仕様は、ピアが公開/秘密鍵ペアのタイプを示す方法を提供していません。これは、レスポンダがイニシエータがサポートする公開/秘密鍵のペアタイプをどのように選択するかという問題を提起します。この情報はいくつかの方法で見つけることができます。
One method to signal the key the initiator wants the responder to use is to indicate that in the IDr (Identification - Responder) payload of the IKE_AUTH request sent by the initiator. In this case, the initiator indicates that it wants the responder to use a particular public/private key pair by sending an IDr payload that indicates that information. In this case, the responder has different identities configured, with each of those identities associated to a public/ private key or key type.
イニシエーターがレスポンダーに使用してほしいキーを通知する1つの方法は、イニシエーターによって送信されたIKE_AUTH要求のIDr（Identification-Responder）ペイロードでそれを示すことです。この場合、イニシエーターは、その情報を示すIDrペイロードを送信することにより、レスポンダが特定の公開/秘密鍵ペアを使用することを望んでいることを示します。この場合、レスポンダにはさまざまなIDが設定されており、それぞれのIDは公開/秘密キーまたはキータイプに関連付けられています。
Another method to ascertain the key the initiator wants the responder to use is through a Certificate Request payload sent by the initiator. For example, the initiator could indicate in the Certificate Request payload that it trusts a certificate authority certificate signed by an ECDSA key. This indication implies that the initiator can process ECDSA signatures, which means that the responder can safely use ECDSA keys when authenticating.
イニシエーターがレスポンダーに使用してほしいキーを確認する別の方法は、イニシエーターによって送信された証明書要求ペイロードを使用することです。たとえば、イニシエーターは、証明書要求ペイロードで、ECDSA鍵によって署名された認証局証明書を信頼することを示すことができます。この表示は、イニシエーターがECDSA署名を処理できることを意味します。つまり、レスポンダーは認証時にECDSAキーを安全に使用できます。
A third method is for the responder to check the key type used by the initiator and use the same key type that the initiator used. This method does not work if the initiator is using shared secret or Extensible Authentication Protocol (EAP) authentication (i.e., is not using public keys). If the initiator is using public key authentication, this method is the best way for the responder to ascertain the type of key the initiator supports.
3番目の方法は、レスポンダがイニシエータが使用するキータイプを確認し、イニシエータが使用したのと同じキータイプを使用することです。この方法は、イニシエーターが共有シークレットまたは拡張認証プロトコル（EAP）認証を使用している（つまり、公開鍵を使用していない）場合は機能しません。イニシエーターが公開鍵認証を使用している場合、この方法は、イニシエーターがサポートする鍵のタイプを確認するための最良の方法です。
If the initiator uses a public key type that the responder does not support, the responder replies with a Notify message with error type AUTHENTICATION_FAILED. If the initiator has multiple different keys, it may try a different key (and perhaps a different key type) until it finds a key that the other end accepts. The initiator can also use the Certificate Request payload sent by the responder to help decide which public key should be tried. In normal cases, when the initiator has multiple public keys, out-of-band configuration is used to select a public key for each connection.
イニシエーターがレスポンダーがサポートしていない公開鍵タイプを使用する場合、レスポンダーはエラータイプAUTHENTICATION_FAILEDのNotifyメッセージで応答します。イニシエーターが複数の異なるキーを持っている場合、相手側が受け入れるキーが見つかるまで、異なるキー（およびおそらく異なるキータイプ）を試す可能性があります。イニシエーターは、レスポンダーによって送信された証明書要求ペイロードを使用して、どの公開鍵を試すかを決定することもできます。通常の場合、イニシエーターに複数の公開鍵がある場合、アウトオブバンド構成を使用して、各接続の公開鍵を選択します。
Tables 2 and 3 of the "Recommendations for Key Management" [NIST800-57] give recommendations for how to select suitable hash functions for the signature.
「鍵管理の推奨事項」[NIST800-57]の表2および3は、署名に適切なハッシュ関数を選択する方法に関する推奨事項を示しています。
This new digital signature method does not tie the Elliptic Curve to a specific hash function, which was done in the old IKEv2 ECDSA methods. This means it is possible to mix different security levels. For example, it is possible to use a 512-bit Elliptic Curve with SHA1. This means that the security of the authentication method is the security of the weakest component (signature algorithm, hash algorithm, or curve). This complicates the security analysis of the system.
この新しいデジタル署名方式は、楕円曲線を特定のハッシュ関数に結び付けません。これは、古いIKEv2 ECDSA方式で行われていました。つまり、異なるセキュリティレベルを混在させることが可能です。たとえば、SHA1で512ビットの楕円曲線を使用することが可能です。つまり、認証方法のセキュリティは、最も弱いコンポーネント（署名アルゴリズム、ハッシュアルゴリズム、または曲線）のセキュリティです。これは、システムのセキュリティ分析を複雑にします。
IKEv2 peers have a series of policy databases (see Section 4.4 of [RFC4301]) that define which security algorithms and methods should be used during establishment of security associations. To help end users select the desired security levels for communications protected by IPsec, implementers may wish to provide a mechanism in the IKE policy databases to limit the mixing of security levels or to restrict combinations of protocols.
IKEv2ピアには、セキュリティアソシエーションの確立中に使用するセキュリティアルゴリズムとメソッドを定義する一連のポリシーデータベース（[RFC4301]のセクション4.4を参照）があります。エンドユーザーがIPsecで保護された通信に必要なセキュリティレベルを選択できるように、実装者はIKEポリシーデータベースにメカニズムを提供して、セキュリティレベルの混合を制限したり、プロトコルの組み合わせを制限したりできます。
Security downgrade attacks, where more secure methods are deleted or modified from a payload by a man-in-the-middle to force lower levels of security, are not a significant concern in IKEv2 Authentication payloads, as discussed in this RFC. This is because a modified AUTH payload will be detected when the peer computes a signature over the IKE messages.
セキュリティのダウングレード攻撃は、中間者によってペイロードからより安全な方法が削除または変更されて、より低いレベルのセキュリティを強制するものであり、このRFCで説明されているように、IKEv2認証ペイロードでは重要な問題ではありません。これは、ピアがIKEメッセージを介して署名を計算するときに、変更されたAUTHペイロードが検出されるためです。
One specific class of downgrade attacks requires selection of catastrophically weak ciphers. In this type of attack, the man-in-the-middle attacker is able to "break" the cryptography in real time. This type of downgrade attack should be blocked by policy regarding cipher algorithm selection, as discussed above.
ダウングレード攻撃の特定のクラスでは、壊滅的に弱い暗号を選択する必要があります。このタイプの攻撃では、中間者攻撃者がリアルタイムで暗号を「破る」ことができます。このタイプのダウングレード攻撃は、前述のように、暗号アルゴリズムの選択に関するポリシーによってブロックする必要があります。
The hash algorithm registry does not include MD5 as a supported hash algorithm, as it is not considered safe enough for signature use [WY05].
ハッシュアルゴリズムレジストリには、サポートされているハッシュアルゴリズムとしてMD5が含まれていません。署名の使用には十分な安全性がないためです[WY05]。
The current IKEv2 protocol uses RSASSA-PKCS1-v1_5, which has known security vulnerabilities [KA08] [ME01] and does not allow using newer padding methods such as RSASSA-PSS. The new method described in this RFC allows the use of other padding methods.
現在のIKEv2プロトコルはRSASSA-PKCS1-v1_5を使用します。これは既知のセキュリティ脆弱性[KA08] [ME01]を持ち、RSASSA-PSSなどの新しいパディング方法を使用できません。このRFCで説明されている新しい方法では、他のパディング方法を使用できます。
The current IKEv2 protocol only allows use of normal DSA with SHA-1, which means the security of the authentication is limited to the security of SHA-1. This new method allows using longer keys and longer hashes with DSA.
現在のIKEv2プロトコルでは、SHA-1での通常のDSAの使用のみが許可されています。つまり、認証のセキュリティはSHA-1のセキュリティに制限されています。この新しい方法では、DSAで長いキーと長いハッシュを使用できます。
This document creates a new IANA registry for IKEv2 Hash Algorithms. Changes and additions to this registry are by Expert Review [RFC5226].
このドキュメントでは、IKEv2ハッシュアルゴリズム用の新しいIANAレジストリを作成します。このレジストリの変更と追加は、Expert Review [RFC5226]によるものです。
The initial values of this registry are:
このレジストリの初期値は次のとおりです。
Hash Algorithm Value
-------------- -----
RESERVED 0
SHA1 1
SHA2-256 2
SHA2-384 3
SHA2-512 4
MD5 is not included in the hash algorithm list, as it is not considered safe enough for signature hash uses.
MD5は、署名ハッシュの使用に対して十分に安全とは見なされないため、ハッシュアルゴリズムリストには含まれていません。
Values 5-1023 are Unassigned. Values 1024-65535 are reserved for Private Use among mutually consenting parties.
値5〜1023は割り当てられていません。 1024〜65535の値は、相互に同意する当事者間の私的使用のために予約されています。
This specification also adds a new value for SIGNATURE_HASH_ALGORITHMS (16431) to the "IKEv2 Notify Message Types - Status Types" registry and adds a new value for Digital Signature (14) to the "IKEv2 Authentication Method" registry.
この仕様はまた、「IKEv2通知メッセージタイプ-ステータスタイプ」レジストリにSIGNATURE_HASH_ALGORITHMS（16431）の新しい値を追加し、「IKEv2認証方式」レジストリにデジタル署名（14）の新しい値を追加します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、RFC 7296、2014年10月、<http：/ /www.rfc-editor.org/info/rfc7296>。
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee、 "ASN.1 encoding rules：Specification of basic encoding Rules（BER）、Canonical encoding rules（CER）and Distinguished encoding rules（DER）"、CCITT Recommendation X.690 、2002年7月。
[KA08] Kuehn, U., Pyshkin, A., Tews, E., and R. Weinmann, "Variants of Bleichenbacher's Low-Exponent Attack on PKCS#1 RSA Signatures", Proceedings of Sicherheit 2008, pp.97-109, 2008.
[KA08] Uキューン、Pyshkin、A.、Tews、E。、およびR. Weinmann、「PKCS＃1 RSA署名に対するブライヘンバッハーの低指数攻撃の変種」、Sicherheit 2008の議事録、pp.97-109、 2008。
[ME01] Menezes, A., "Evaluation of Security Level of Cryptography: RSA-OAEP, RSA-PSS, RSA Signature", December 2001.
[ME01] Menezes、A。、「暗号化のセキュリティレベルの評価：RSA-OAEP、RSA-PSS、RSA署名」、2001年12月。
[NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, March 2007.
[NIST800-57] Barker、E.、Barker、W.、Burr、W.、Polk、W。、およびM. Smid、「鍵管理の推奨事項-パート1：一般（改訂）」、NIST特別刊行物800- 57、2007年3月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002, <http://www.rfc-editor.org/info/rfc3279>.
[RFC3279] Bassham、L.、Polk、W。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルのアルゴリズムと識別子」、RFC 3279、2002年4月、<http ：//www.rfc-editor.org/info/rfc3279>。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、2003年2月、<http://www.rfc-editor.org/ info / rfc3447>。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005, <http://www.rfc-editor.org/info/rfc4055>.
[RFC4055] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムと識別子」、RFC 4055 、2005年6月、<http://www.rfc-editor.org/info/rfc4055>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs)", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226 >。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009, <http://www.rfc-editor.org/info/rfc5480>.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号サブジェクト公開鍵情報」、RFC 5480、2009年3月、<http：// www .rfc-editor.org / info / rfc5480>。
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", RFC 5758, January 2010, <http://www.rfc-editor.org/info/rfc5758>.
[RFC5758] Dang、Q.、Santesson、S.、Moriarty、K.、Brown、D。、およびT. Polk、「Internet X.509 Public Key Infrastructure：Additional Algorithms and Identifiers for DSA and ECDSA」、RFC 5758、 2010年1月、<http://www.rfc-editor.org/info/rfc5758>。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010, <http://www.rfc-editor.org/info/rfc5912>.
[RFC5912] Hoffman、P。およびJ. Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャ用の新しいASN.1モジュール」、RFC 5912、2010年6月、<http://www.rfc-editor.org / info / rfc5912>。
[WY05] Wang, X. and H. Yu, "How to break MD5 and other hash functions", Proceedings of EuroCrypt 2005, Lecture Notes in Computer Science Vol. 3494, 2005.
[WY05] Wang、X。およびH. Yu、「MD5とその他のハッシュ関数を壊す方法」、EuroCrypt 2005のプロシーディングス、コンピュータサイエンスの講義ノートVol。 3494、2005。
[X9.62] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, November 2005.
[X9.62] American National Standards Institute、「金融サービス業界の公開鍵暗号化：楕円曲線デジタル署名アルゴリズム（ECDSA）」、ANSI X9.62、2005年11月。
This section lists commonly used ASN.1 objects in binary form. This section is not normative, and these values should only be used as examples. If the ASN.1 object listed in Appendix A and the ASN.1 object specified by the algorithm differ, then the algorithm specification must be used. These values are taken from "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)" [RFC5912].
このセクションでは、一般的に使用されるASN.1オブジェクトをバイナリ形式でリストします。このセクションは規範的ではなく、これらの値は例としてのみ使用してください。付録AにリストされているASN.1オブジェクトとアルゴリズムによって指定されたASN.1オブジェクトが異なる場合は、アルゴリズムの仕様を使用する必要があります。これらの値は、「X.509（PKIX）を使用した公開鍵インフラストラクチャの新しいASN.1モジュール」[RFC5912]から取得されます。
The algorithm identifiers here include several different ASN.1 objects with different hash algorithms. This document only includes the commonly used ones, i.e., the ones using SHA-1 or SHA-2 as the hash function. Some other algorithms (such as MD2 and MD5) are not safe enough to be used as signature hash algorithms and are omitted. The IANA registry does not have code points for these other algorithms with RSA Encryption. Note that there are no optional parameters in any of these algorithm identifiers, but all included here need NULL optional parameters present in the ASN.1.
ここでのアルゴリズム識別子には、異なるハッシュアルゴリズムを持ついくつかの異なるASN.1オブジェクトが含まれます。このドキュメントには、一般的に使用されるもの、つまりハッシュ関数としてSHA-1またはSHA-2を使用するもののみが含まれています。他の一部のアルゴリズム（MD2やMD5など）は、署名ハッシュアルゴリズムとして使用するには安全ではないため、省略されています。 IANAレジストリには、RSA暗号化を使用するこれらの他のアルゴリズムのコードポイントがありません。これらのアルゴリズム識別子にはオプションのパラメーターはありませんが、ここに含まれるすべてのパラメーターには、ASN.1にNULLのオプションのパラメーターが必要です。
See "Algorithms and Identifiers for PKIX Profile" [RFC3279] and "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC4055] for more information.
詳細については、「PKIXプロファイルのアルゴリズムと識別子」[RFC3279]および「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するRSA暗号化の追加のアルゴリズムと識別子」[RFC4055]を参照してください。
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
Parameters are required, and they must be NULL.
パラメータは必須であり、NULLである必要があります。
Name = sha1WithRSAEncryption, oid = 1.2.840.113549.1.1.5 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0505 00
名前= sha1WithRSAEncryption、oid = 1.2.840.113549.1.1.5長さ= 15 0000：300d 0609 2a86 4886 f70d 0101 0505 00
sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
Parameters are required, and they must be NULL.
パラメータは必須であり、NULLである必要があります。
Name = sha256WithRSAEncryption, oid = 1.2.840.113549.1.1.11 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0b05 00
名前= sha256WithRSAEncryption、oid = 1.2.840.113549.1.1.11長さ= 15 0000：300d 0609 2a86 4886 f70d 0101 0b05 00
sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
Parameters are required, and they must be NULL.
パラメータは必須であり、NULLである必要があります。
Name = sha384WithRSAEncryption, oid = 1.2.840.113549.1.1.12 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0c05 00
名前= sha384WithRSAEncryption、oid = 1.2.840.113549.1.1.12長さ= 15 0000：300d 0609 2a86 4886 f70d 0101 0c05 00
sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
Parameters are required, and they must be NULL.
パラメータは必須であり、NULLである必要があります。
Name = sha512WithRSAEncryption, oid = 1.2.840.113549.1.1.13 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0d05 00
名前= sha512WithRSAEncryption、oid = 1.2.840.113549.1.1.13長さ= 15 0000：300d 0609 2a86 4886 f70d 0101 0d05 00
With DSA algorithms, optional parameters are always omitted. Only algorithm combinations for DSA that are listed in the IANA registry are included.
DSAアルゴリズムでは、オプションのパラメーターは常に省略されます。 IANAレジストリにリストされているDSAのアルゴリズムの組み合わせのみが含まれます。
See "Algorithms and Identifiers for PKIX Profile" [RFC3279] and "PKIX Additional Algorithms and Identifiers for DSA and ECDSA" [RFC5758] for more information.
詳細については、「PKIXプロファイルのアルゴリズムと識別子」[RFC3279]および「DSAおよびECDSAのPKIX追加のアルゴリズムと識別子」[RFC5758]を参照してください。
dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57(10040) x9algorithm(4) 3 }
Parameters are absent.
パラメータはありません。
Name = dsa-with-sha1, oid = 1.2.840.10040.4.3 Length = 11 0000: 3009 0607 2a86 48ce 3804 03
名前= dsa-with-sha1、oid = 1.2.840.10040.4.3長さ= 11 0000：3009 0607 2a86 48ce 3804 03
dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
id-dsa-with-sha2(3) 2 }
Parameters are absent.
パラメータはありません。
Name = dsa-with-sha256, oid = 2.16.840.1.101.3.4.3.2 Length = 13 0000: 300b 0609 6086 4801 6503 0403 02
名前= dsa-with-sha256、oid = 2.16.840.1.101.3.4.3.2長さ= 13 0000：300b 0609 6086 4801 6503 0403 02
With ECDSA algorithms, the optional parameters are always omitted. Only algorithm combinations for the ECDSA listed in the IANA registry are included.
ECDSAアルゴリズムでは、オプションのパラメーターは常に省略されます。 IANAレジストリにリストされているECDSAのアルゴリズムの組み合わせのみが含まれます。
See "Elliptic Curve Cryptography Subject Public Key Information" [RFC5480], "Algorithms and Identifiers for PKIX Profile" [RFC3279], and "PKIX Additional Algorithms and Identifiers for DSA and ECDSA" [RFC5758] for more information.
詳細については、「楕円曲線暗号サブジェクトの公開鍵情報」[RFC5480]、「PKIXプロファイルのアルゴリズムと識別子」[RFC3279]、「DSAおよびECDSAのPKIX追加のアルゴリズムと識別子」[RFC5758]を参照してください。
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
ansi-X9-62(10045) signatures(4) 1 }
Parameters are absent.
パラメータはありません。
Name = ecdsa-with-sha1, oid = 1.2.840.10045.4.1 Length = 11 0000: 3009 0607 2a86 48ce 3d04 01
名前= ecdsa-with-sha1、oid = 1.2.840.10045.4.1長さ= 11 0000：3009 0607 2a86 48ce 3d04 01
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }
Parameters are absent.
パラメータはありません。
Name = ecdsa-with-sha256, oid = 1.2.840.10045.4.3.2 Length = 12 0000: 300a 0608 2a86 48ce 3d04 0302
名前= ecdsa-with-sha256、oid = 1.2.840.10045.4.3.2長さ= 12 0000：300a 0608 2a86 48ce 3d04 0302
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }
Parameters are absent.
パラメータはありません。
Name = ecdsa-with-sha384, oid = 1.2.840.10045.4.3.3 Length = 12 0000: 300a 0608 2a86 48ce 3d04 0303
名前= ecdsa-with-sha384、oid = 1.2.840.10045.4.3.3長さ= 12 0000：300a 0608 2a86 48ce 3d04 0303
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
Parameters are absent.
パラメータはありません。
Name = ecdsa-with-sha512, oid = 1.2.840.10045.4.3.4 Length = 12 0000: 300a 0608 2a86 48ce 3d04 0304
名前= ecdsa-with-sha512、oid = 1.2.840.10045.4.3.4長さ= 12 0000：300a 0608 2a86 48ce 3d04 0304
With RSASSA-PSS, the algorithm object identifier must always be id-RSASSA-PSS, and the hash function and padding parameters are conveyed in the parameters (which are not optional in this case). See Additional RSA Algorithms and Identifiers [RFC4055] for more information.
RSASSA-PSSでは、アルゴリズムオブジェクト識別子は常にid-RSASSA-PSSである必要があり、ハッシュ関数とパディングパラメーターはパラメーターで伝達されます（この場合はオプションではありません）。詳細については、追加のRSAアルゴリズムと識別子[RFC4055]を参照してください。
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
Parameters are empty, but the ASN.1 part of the sequence must be present. This means default parameters are used.
パラメータは空ですが、シーケンスのASN.1部分が存在する必要があります。つまり、デフォルトのパラメーターが使用されます。
0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE
0000：シーケンス0002：オブジェクトID RSASSA-PSS（1.2.840.113549.1.1.10）000d：シーケンス
Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
長さ= 15 0000：300d 0609 2a86 4886 f70d 0101 0a30 00
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
Here the parameters are present and contain the default parameters, i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField of 1.
ここにパラメータが存在し、デフォルトパラメータが含まれています。つまり、SHA-1のhashAlgorithm、mgf1SHA1のmaskGenAlgorithm、20のsaltLength、および1のtrailerFieldです。
0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 001a : NULL 001c : CONTEXT 1 001e : SEQUENCE 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002b : SEQUENCE 002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 0034 : NULL 0036 : CONTEXT 2 0038 : INTEGER 0x14 (5 bits) 003b : CONTEXT 3 003d : INTEGER 0x1 (1 bits)
0000：シーケンス0002：オブジェクト識別子RSASSA-PSS（1.2.840.113549.1.1.10）000d：シーケンス000f：CONTEXT 0 0011：シーケンス0013：OBJECT IDENTIFIER id-sha1（1.3.14.3.2.26）001a：NULL 001c：CONTEXT 1 001e：SEQUENCE 0020：OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002b：SEQUENCE 002d：OBJECT IDENTIFIER id-sha1（1.3.14.3.2.26）0034：NULL 0036：CONTEXT 2 0038：INTEGER 0x14（5 bits）003b：CONTEXT 3 003d：INTEGER 0x1（1ビット）
Name = RSASSA-PSS with default parameters, oid = 1.2.840.113549.1.1.10 Length = 64 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101
名前= RSASSA-PSS、デフォルトパラメータ、oid = 1.2.840.113549.1.1.10長さ= 64 0000：303e 0609 2a86 4886 f70d 0101 0a30 31a0 0010：0b30 0906 052b 0e03 021a 0500 a118 3016 0020：0609 2a86 4886 f70d 0101 0830 0906 052b 0030：0e03 021a 0500 a203 0201 14a3 0302 0101
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
Here the parameters are present and contain hashAlgorithm of SHA-256, maskGenAlgorithm of SHA-256, saltLength of 32, and trailerField of 1.
ここにパラメーターが存在し、SHA-256のhashAlgorithm、SHA-256のmaskGenAlgorithm、saltLength 32、trailerField 1が含まれています。
0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 001e : NULL 0020 : CONTEXT 1 0022 : SEQUENCE 0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002f : SEQUENCE 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 003c : NULL 003e : CONTEXT 2 0040 : INTEGER 0x20 (6 bits) 0043 : CONTEXT 3 0045 : INTEGER 0x1 (1 bits)
0000：シーケンス0002：オブジェクトIDENTIFIER RSASSA-PSS（1.2.840.113549.1.1.10）000d：シーケンス000f：CONTEXT 0 0011：SEQUENCE 0013：オブジェクトIDENTIFIER id-sha256（2.16.840.1.101.3.4.2.1）001e：NULL 0020：CONTEXT 1 0022：SEQUENCE 0024：OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002f：SEQUENCE 0031：OBJECT IDENTIFIER id-sha256（2.16.840.1.101.3.4.2.1）003c：NULL 003e：CONTEXT 2 0040：INTEGER 0x20 （6ビット）0043：CONTEXT 3 0045：INTEGER 0x1（1ビット）
Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 Length = 72 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 0040: 0201 20a3 0302 0101
名前= RSASSA-PSS、sha-256、oid = 1.2.840.113549.1.1.10長さ= 72 0000：3046 0609 2a86 4886 f70d 0101 0a30 39a0 0010：0f30 0d06 0960 8648 0165 0304 0201 0500 0020：a11c 301a 0609 2a86 4886 f70d 0101 0830 0030：0d06 0960 8648 0165 0304 0201 0500 a203 0040：0201 20a3 0302 0101
The IKEv2 AUTH payload would start like this:
IKEv2 AUTHペイロードは次のように始まります。
00000000: NN00 00LL 0e00 0000 0f30 0d06 092a 8648
00000010: 86f7 0d01 0105 0500 ....
Where the NN will be the next payload type (i.e., the value depends on the next payload after this Authentication payload), the LL will be the length of this payload, and after the sha1WithRSAEncryption ASN.1 block (15 bytes) there will be the actual signature, which is omitted here.
NNが次のペイロードタイプになる場合（つまり、値はこの認証ペイロードの後の次のペイロードに依存します）、LLはこのペイロードの長さであり、sha1WithRSAEncryption ASN.1ブロック（15バイト）の後にあります。ここでは省略されている実際の署名。
Acknowledgements
謝辞
Most of this work was based on the work done in the IPsecME design team for the ECDSA. The design team members were: Dan Harkins, Johannes Merkle, Tero Kivinen, David McGrew, and Yoav Nir.
この作業のほとんどは、ECDSAのIPsecME設計チームで行われた作業に基づいています。設計チームのメンバーは、Dan Harkins、Johannes Merkle、Tero Kivinen、David McGrew、Yoav Nirでした。
Authors' Addresses
著者のアドレス
Tero Kivinen INSIDE Secure Eerikinkatu 28 Helsinki FI-00180 Finland
Tero Kivinen INSIDE Secure Eerikinkatu 28ヘルシンキFI-00180フィンランド
EMail: kivinen@iki.fi
Joel Snyder Opus One 1404 East Lind Road Tucson, AZ 85719
Joel Snyder Opus One 1404 East Lind Road Tucson、AZ 85719
Phone: +1 520 324 0494
EMail: jms@opus1.com