[要約] RFC 6989は、IKEv2におけるDiffie-Hellmanテストの追加を提案している。目的は、IKEv2のセキュリティと互換性を向上させることである。
Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 6989 Porticor
Updates: 5996 S. Fluhrer
Category: Standards Track Cisco
ISSN: 2070-1721 July 2013
Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)
インターネットキー交換プロトコルバージョン2（IKEv2）用の追加のDiffie-Hellmanテスト
Abstract
概要
This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996.
このドキュメントでは、楕円曲線グループを使用したInternet Key Exchange Protocolバージョン2（IKEv2）の安全な運用に必要な少数の必須テストを追加しています。ほとんど使用されない、いわゆるデジタル署名アルゴリズム（DSA）グループを除いて、モジュラー指数グループを使用するIKE実装を変更する必要はありません。このドキュメントは、IKEv2プロトコル、RFC 5996を更新します。
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/rfc6989.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6989で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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
1.1. Conventions Used in This Document ..........................3
2. Group Membership Tests ..........................................3
2.1. Sophie Germain Prime MODP Groups ...........................3
2.2. MODP Groups with Small Subgroups ...........................3
2.3. Elliptic Curve Groups ......................................4
2.4. Transition .................................................4
2.5. Protocol Behavior ..........................................5
3. Side-Channel Attacks ............................................5
4. Security Considerations .........................................6
4.1. DH Key Reuse and Multiple Peers ............................6
4.2. DH Key Reuse: Variants .....................................7
4.3. Groups Not Covered by This RFC .............................7
4.4. Behavior upon Test Failure .................................7
5. IANA Considerations .............................................8
6. Acknowledgements ................................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
IKEv2 [RFC5996] consists of the establishment of a shared secret using the Diffie-Hellman (DH) protocol, followed by authentication of the two peers. Existing implementations typically use modular exponential (MODP) DH groups, such as those defined in [RFC3526].
IKEv2 [RFC5996]は、Diffie-Hellman（DH）プロトコルを使用した共有秘密の確立と、それに続く2つのピアの認証で構成されます。既存の実装では通常、[RFC3526]で定義されているような、モジュラー指数（MODP）DHグループを使用します。
IKEv2 does not require that any tests be performed by a peer receiving a public Diffie-Hellman key from the other peer. This is fine for the common case of MODP groups. For other DH groups, when peers reuse DH values across multiple IKE sessions, the lack of tests by the recipient results in a potential vulnerability (see Section 4.1 for more details). In particular, this is true for Elliptic Curve (EC) groups, whose use is becoming ever more popular. This document defines such tests for several types of DH groups.
IKEv2では、他のピアからDiffie-Hellman公開鍵を受信するピアがテストを実行する必要はありません。これは、MODPグループの一般的なケースでは問題ありません。他のDHグループの場合、ピアが複数のIKEセッション間でDH値を再利用すると、受信者によるテストがないため、潜在的な脆弱性が発生します（詳細については、セクション4.1を参照）。特に、これは、その使用がますます普及している楕円曲線（EC）グループに当てはまります。このドキュメントでは、いくつかのタイプのDHグループに対してそのようなテストを定義しています。
In addition, this document describes another potential attack related to the reuse of DH keys: a timing attack. This additional material is taken from [RFC2412].
さらに、このドキュメントでは、DHキーの再利用に関連する別の潜在的な攻撃であるタイミング攻撃について説明します。この追加の資料は[RFC2412]から取得されます。
This document updates [RFC5996] by adding security requirements that apply to many of the protocol's implementations.
このドキュメントは、プロトコルの実装の多くに適用されるセキュリティ要件を追加することによって[RFC5996]を更新します。
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 section describes the tests that need to be performed by IKE peers receiving a Key Exchange (KE) payload. The tests are RECOMMENDED for all implementations but only REQUIRED for those that reuse DH private keys (as defined in [RFC5996], Section 2.12). The tests apply to the recipient of a KE payload and describe how it should check the received payload. They are listed here according to the DH group being used.
このセクションでは、鍵交換（KE）ペイロードを受信するIKEピアが実行する必要のあるテストについて説明します。テストはすべての実装に推奨されますが、DH秘密鍵を再利用する実装にのみ必要です（[RFC5996]、セクション2.12で定義）。テストはKEペイロードの受信者に適用され、受信したペイロードを確認する方法を記述します。それらは、使用されているDHグループに従ってここにリストされます。
These are currently the most commonly used groups; all these groups have the property that (p-1)/2 is also prime; this section applies to any such MODP group. Each recipient MUST verify that the peer's public value r is in the legal range (1 < r < p-1). According to [Menezes], Section 2.2, even with this check there remains the possibility of leaking a single bit of the secret exponent when DH keys are reused; this amount of leakage is insignificant.
これらは現在最も一般的に使用されているグループです。これらすべてのグループには、（p-1）/ 2も素数であるという特性があります。このセクションは、そのようなMODPグループに適用されます。各受信者は、ピアのパブリック値rが正当な範囲（1 <r <p-1）であることを確認する必要があります。 [Menezes]のセクション2.2によると、このチェックを行っても、DHキーを再利用すると秘密指数の1ビットが漏洩する可能性があります。この量の漏れはわずかです。
See Section 5 for the specific groups covered by this section.
このセクションの対象となる特定のグループについては、セクション5を参照してください。
[RFC5114] defines modular exponential groups with small subgroups; these are modular exponential groups with comparatively small subgroups, and all have (p-1)/2 composite. Section 2.1 of [Menezes] describes some informational leakage from a small-subgroup attack on these groups if the DH private value is reused.
[RFC5114]は、小さなサブグループを持つモジュラー指数グループを定義しています。これらは、比較的小さなサブグループを持つモジュラー指数グループであり、すべて（p-1）/ 2複合です。 [Menezes]のセクション2.1は、DHプライベート値が再利用された場合の、これらのグループに対する小サブグループ攻撃からの情報漏えいについて説明しています。
This leakage can be prevented if the recipient performs a test on the peer's public value; however, this test is expensive (approximately as expensive as what reusing DH private values saves). In addition, the NIST standard ([NIST-800-56A], Section 5.6.2.4) requires that test; hence, anyone needing to conform to that standard will need to implement the test anyway.
このリークは、受信者がピアのパブリックバリューでテストを実行する場合に防止できます。ただし、このテストはコストがかかります（DHプライベート値を再利用することで節約できるものとほぼ同じくらいのコストがかかります）。さらに、NIST標準（[NIST-800-56A]、セクション5.6.2.4）では、このテストが必要です。したがって、その標準に準拠する必要がある人はとにかくテストを実装する必要があります。
Because of the above, the IKE implementation MUST choose between one of the following two options:
上記のため、IKE実装は、次の2つのオプションのいずれかを選択する必要があります。
o It MUST check both that the peer's public value is in range (1 < r < p-1) and that r^q = 1 mod p (where q is the size of the subgroup, as listed in the RFC defining the group). DH private values MAY then be reused. This option is appropriate if conformance to [NIST-800-56A] is required.
o ピアの公開値が範囲内（1 <r <p-1）であること、およびr ^ q = 1 mod p（qはグループを定義するRFCにリストされているサブグループのサイズ）の両方をチェックする必要があります。その後、DHプライベート値を再利用できます。このオプションは、[NIST-800-56A]への準拠が必要な場合に適しています。
o It MUST NOT reuse DH private values (that is, the DH private value for each DH exchange MUST be generated from a fresh output of a cryptographically secure random number generator), and it MUST check that the peer's public value is in range (1 < r < p-1). This option is more appropriate if conformance to [NIST-800-56A] is not required.
o DHプライベート値を再利用してはならず（つまり、各DH交換のDHプライベート値は、暗号で保護された乱数ジェネレータの新しい出力から生成する必要があります）、ピアのパブリック値が範囲内にあることを確認する必要があります（1 < r <p-1）。このオプションは、[NIST-800-56A]への準拠が不要な場合に適しています。
See Section 5 for the specific groups covered by this section.
このセクションの対象となる特定のグループについては、セクション5を参照してください。
IKEv2 can be used with elliptic curve groups defined over a field GF(p) [RFC5903] [RFC5114]. According to [Menezes], Section 2.3, there is some informational leakage possible. A receiving peer MUST check that its peer's public value is valid; that is, the x and y parameters from the peer's public value satisfy the curve equation, y^2 = x^3 + ax + b mod p (where for groups 19, 20, and 21, a=-3 (mod p), and all other values of a, b, and p for the group are listed in the RFC defining the group).
IKEv2は、フィールドGF（p）で定義された楕円曲線グループで使用できます[RFC5903] [RFC5114]。 [Menezes]のセクション2.3によれば、情報漏えいの可能性があります。受信ピアは、そのピアのパブリック値が有効であることを確認する必要があります。つまり、ピアのパブリック値からのxおよびyパラメータは、曲線方程式y ^ 2 = x ^ 3 + ax + b mod p（グループ19、20、および21の場合、a = -3（mod p））を満たします。 、およびグループの他のすべてのa、b、pの値は、グループを定義するRFCにリストされています。
We note that an additional check to ensure that the public value is not the point at infinity is not needed, because IKE (see Section 7 of [RFC5903]) does not allow for encoding this value.
IKE（[RFC5903]のセクション7を参照）ではこの値をエンコードできないため、パブリック値が無限遠でないことを確認するための追加のチェックは必要ありません。
See Section 5 for the specific groups covered by this section.
このセクションの対象となる特定のグループについては、セクション5を参照してください。
Existing implementations of IKEv2 with Elliptic Curve Diffie-Hellman (ECDH) groups may be modified to include the tests described in the current document, even if they do not reuse DH keys. The tests can be considered as sanity checks and will prevent the code having to handle inputs that it may not have been designed to handle.
楕円曲線Diffie-Hellman（ECDH）グループを使用したIKEv2の既存の実装は、DHキーを再利用しない場合でも、現在のドキュメントで説明されているテストを含めるように変更できます。テストは健全性チェックと見なすことができ、コードが処理するように設計されていない可能性がある入力を処理する必要がなくなります。
ECDH implementations that do reuse DH keys MUST be enhanced to include the above tests.
DHキーを再利用するECDH実装は、上記のテストを含めるように拡張する必要があります。
The recipient of a DH public key that fails one of the above tests must assume that the sender is either truly malicious or has a bug in its implementation. The behavior defined below attempts to balance resistance to attackers that are trying to disrupt the IKE exchange, against the need to help a badly implemented peer by providing useful error indications.
上記のテストの1つに失敗したDH公開鍵の受信者は、送信者が本当に悪意があるか、その実装にバグがあると想定する必要があります。以下に定義する動作は、IKE交換を妨害しようとする攻撃者への耐性と、有用なエラー表示を提供することによって不適切に実装されたピアを支援する必要性とのバランスをとろうとします。
If this error happens during the IKE_SA_INIT exchange, then the recipient MUST drop the message that contains an invalid KE payload and MUST NOT use that message when creating the IKE security association (SA).
このエラーがIKE_SA_INIT交換中に発生した場合、受信者は、無効なKEペイロードを含むメッセージをドロップする必要があり、IKEセキュリティアソシエーション（SA）を作成するときにそのメッセージを使用してはなりません（MUST NOT）。
If the implementation employs the DoS-resistant behavior proposed in Section 2.4 of [RFC5996], it may simply ignore the erroneous request or response message, and continue waiting for a later message containing a legitimate KE payload.
[RFC5996]のセクション2.4で提案されているDoS耐性のある動作を実装が採用している場合、誤った要求または応答メッセージを単に無視し、正当なKEペイロードを含む後続のメッセージを待ち続ける可能性があります。
If DoS-resistant behavior is not implemented and the invalid KE payload was in the IKE_SA_INIT request, the implementation MAY send an INVALID_SYNTAX error notification back and remove the in-progress IKE SA; if the invalid KE payload was in the IKE_SA_INIT response, then the implementation MAY simply delete the half-created IKE SA and re-initiate the exchange.
DoS耐性のある動作が実装されておらず、IKE_SA_INITリクエストに無効なKEペイロードが含まれていた場合、実装はINVALID_SYNTAXエラー通知を送信して、進行中のIKE SAを削除してもよい（MAY）。無効なKEペイロードがIKE_SA_INIT応答に含まれていた場合、実装は、半分作成されたIKE SAを削除して、交換を再び開始することができます（MAY）。
If the invalid KE payload is received during the CREATE_CHILD_SA exchange (or any other exchange after the IKE SA has been established) and the invalid KE payload is in the request message, the Responder MUST reply with an INVALID_SYNTAX error notification and drop the IKE SA. If the invalid KE payload is in a response, the Initiator getting this reply MUST immediately delete the IKE SA by sending an IKE SA Delete notification as a new exchange. In this case, the sender evidently has an implementation bug, and dropping the IKE SA makes it easier to detect.
無効なKEペイロードがCREATE_CHILD_SA交換（またはIKE SAが確立された後の他の交換）中に受信され、無効なKEペイロードが要求メッセージにある場合、レスポンダはINVALID_SYNTAXエラー通知で応答し、IKE SAをドロップする必要があります。無効なKEペイロードが応答にある場合、この応答を受け取ったイニシエーターは、IKE SA削除通知を新しい交換として送信することにより、IKE SAをすぐに削除する必要があります。この場合、送信者には明らかに実装上のバグがあり、IKE SAを削除すると検出が容易になります。
In addition to the small-subgroup attack, there is also a potential timing attack on IKE peers when they are reusing Diffie-Hellman secret values. This is a side-channel attack, which means that it may or may not be a vulnerability in certain cases, depending on implementation details and the threat model.
小サブグループ攻撃に加えて、IKEピアがDiffie-Hellmanシークレット値を再利用しているときに、潜在的なタイミング攻撃もあります。これはサイドチャネル攻撃です。つまり、実装の詳細と脅威モデルに応じて、特定の場合には脆弱性である場合とそうでない場合があります。
The remainder of this section is quoted from [RFC2412], Section 5, with a few minor clarifications. This attack still applies to IKEv2 implementations, and both to MODP groups and ECDH groups. We also note that more efficient countermeasures are available for EC groups represented in projective form, but these are outside the scope of the current document.
このセクションの残りの部分は、[RFC2412]、セクション5から引用され、いくつかのマイナーな説明が含まれています。この攻撃は引き続きIKEv2実装に適用され、MODPグループとECDHグループの両方に適用されます。また、射影形式で表現されたECグループに対してはより効率的な対策が利用可能ですが、これらは現在のドキュメントの範囲外です。
Timing attacks that are capable of recovering the exponent value used in Diffie-Hellman calculations have been described by Paul Kocher [Kocher]. In order to nullify the attack, implementors must take pains to obscure the sequence of operations involved in carrying out modular exponentiations.
Diffie-Hellmanの計算で使用される指数値を回復できるタイミング攻撃は、Paul Kocher [Kocher]によって説明されています。攻撃を無効にするために、実装者はモジュラー指数の実行に関連する一連の操作を不明瞭にするために苦労する必要があります。
One potential method to foil these timing attacks is to use a "blinding factor". In this method, a group element, r, is chosen at random, and its multiplicative inverse modulo p is computed, which we'll call r_inv. r_inv can be computed by the Extended Euclidean Method, using r and p as inputs. When an exponent x is chosen, the value r_inv^x is also calculated. Then, when calculating (g^y)^x, the implementation will calculate this sequence:
これらのタイミング攻撃を無効にする1つの潜在的な方法は、「ブラインドファクター」を使用することです。この方法では、グループ要素rがランダムに選択され、pを法とする乗法逆数が計算されます。これをr_invと呼びます。 r_invは、rおよびpを入力として使用して、拡張ユークリッド法で計算できます。指数xが選択されると、値r_inv ^ xも計算されます。次に、（g ^ y）^ xを計算するときに、実装はこのシーケンスを計算します。
A = r*g^y
B = A^x = (r*g^y)^x = (r^x)(g^(xy))
C = B*r_inv^x = (r^x)(r^(-1*x))(g^(xy)) = g^(xy)
The blinding factor is only necessary if the exponent x is used more than 100 times.
目隠し係数は、指数xが100回以上使用される場合にのみ必要です。
This entire document is concerned with the IKEv2 security protocol and the need to harden it in some cases.
このドキュメント全体は、IKEv2セキュリティプロトコルと、場合によってはそれを強化する必要性に関係しています。
This section describes one variant of the attack prevented by the tests defined above.
このセクションでは、上記で定義したテストによって防止された攻撃の1つのバリアントについて説明します。
Suppose that IKE peer Alice maintains IKE security associations with peers Bob and Eve. Alice uses the same secret ECDH key for both SAs, which is allowed with some restrictions. If Alice does not implement these tests, Eve will be able to send a malformed public key, which would allow her to efficiently determine Alice's private key (as described in Section 2 of [Menezes]). Since the key is shared, Eve will be able to obtain Alice's shared IKE SA key with Bob.
IKEピアのアリスがピアのボブとイブとのIKEセキュリティアソシエーションを維持しているとします。 Aliceは両方のSAに同じ秘密ECDH鍵を使用しますが、これはいくつかの制限付きで許可されています。アリスがこれらのテストを実装しない場合、イブは不正な公開鍵を送信できるため、アリスの秘密鍵を効率的に特定できます（[メネゼス]のセクション2で説明）。キーは共有されているため、イブはボブとアリスの共有IKE SAキーを取得できます。
Private DH keys can be reused in different ways, with subtly different security implications. For example:
プライベートDHキーは、微妙に異なるセキュリティの影響を伴うさまざまな方法で再利用できます。例えば：
1. DH keys are reused for multiple connections (IKE SAs) to the same peer and for connections to different peers.
1. DHキーは、同じピアへの複数の接続（IKE SA）および異なるピアへの接続に再利用されます。
2. DH keys are reused for multiple connections to the same peer (e.g., when the peer is identified by its IP address) but not for different peers.
2. DHキーは、同じピアへの複数の接続に再利用されますが（たとえば、ピアがそのIPアドレスによって識別される場合）、異なるピアには再利用されません。
3. DH keys are reused only when they had not been used to complete an exchange, e.g., when the peer replies with an INVALID_KE_PAYLOAD notification.
3. DHキーは、交換を完了するために使用されていない場合（ピアがINVALID_KE_PAYLOAD通知で応答する場合など）にのみ再利用されます。
Both the small-subgroup attack and the timing attack described in this document apply at least to options #1 and #2.
このドキュメントで説明されているスモールサブグループ攻撃とタイミング攻撃の両方が、少なくともオプション＃1と＃2に適用されます。
There are a number of group types that are not specifically addressed by this RFC. A document that defines such a group MUST describe the tests required by that group.
このRFCでは具体的に取り上げられていないグループタイプがいくつかあります。そのようなグループを定義するドキュメントは、そのグループが必要とするテストを記述しなければなりません。
One specific type of group would be an even-characteristic elliptic curve group. Now, these curves have cofactors greater than 1; this leads to a possibility of some information leakage. There are several ways to address this information leakage, such as performing a test analogous to the test in Section 2.2 or adjusting the ECDH operation to avoid this leakage (such as Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH), where the shared secret really is hxyG). Because the appropriate test depends on how the group is defined, we cannot document it in advance.
特定のタイプのグループの1つは、特性が均一な楕円曲線グループです。現在、これらの曲線には1より大きい補因子があります。これにより、情報が漏洩する可能性があります。この情報漏えいに対処する方法はいくつかあります。たとえば、セクション2.2のテストと同様のテストを実行したり、ECDH操作を調整してこの漏えいを回避したりします（楕円曲線暗号補因子Diffie-Hellman（ECC CDH）など）。本当にhxyGです）。適切なテストはグループの定義方法に依存するため、事前に文書化することはできません。
The behavior recommended in Section 2.5 is in line with generic error treatment during the IKE_SA_INIT exchange, per Section 2.21.1 of [RFC5996]. The sender is not required to send back an error notification, and the recipient cannot depend on this notification because it is unauthenticated and may in fact have been sent by an attacker trying to launch a DoS attack on the connection. Thus, the notification is only useful to debug implementation errors.
[RFC5996]のセクション2.21.1に従って、セクション2.5で推奨されている動作は、IKE_SA_INIT交換中の一般的なエラー処理と一致しています。送信者はエラー通知を送り返す必要はありません。受信者はこの通知を認証することができず、実際に接続に対してDoS攻撃を仕掛けようとする攻撃者から送信された可能性があるため、この通知に依存することはできません。したがって、通知は実装エラーのデバッグにのみ役立ちます。
On the other hand, the error notification is secure in the sense that no secret information is leaked. All IKEv2 Diffie-Hellman groups are publicly known, and none of the tests defined here depend on any private key. In fact, the tests can all be performed by an eavesdropper.
一方、エラー通知は秘密情報が漏洩しないという意味で安全である。すべてのIKEv2 Diffie-Hellmanグループは公開されており、ここで定義されているテストはいずれも秘密鍵に依存していません。実際、テストはすべて盗聴者が実行できます。
The situation when the failure occurs in the CREATE_CHILD_SA exchange is different, since everything is protected by an IKE SA. The peers are authenticated, and error notifications can be relied on. See Section 2.21.3 of [RFC5996] for more details on error handling in this case.
すべてがIKE SAによって保護されているため、CREATE_CHILD_SA交換で障害が発生する状況は異なります。ピアが認証され、エラー通知を信頼できます。この場合のエラー処理の詳細については、[RFC5996]のセクション2.21.3を参照してください。
IANA has added a column named "Recipient Tests" to the Transform Type 4 - Diffie-Hellman Group Transform IDs registry for IKEv2 [IANA-IKEv2-Registry].
IANAは、「Recipient Tests」という名前の列をTransform Type 4-IKEv2のDiffie-Hellmanグループ変換IDレジストリ[IANA-IKEv2-Registry]に追加しました。
This column has been initially populated as follows.
この列は、最初は次のように入力されています。
+------------------------------------+-----------------------+
| Number | Recipient Tests |
+------------------------------------+-----------------------+
| 1, 2, 5, 14, 15, 16, 17, 18 | RFC 6989, Section 2.1 |
| 22, 23, 24 | RFC 6989, Section 2.2 |
| 19, 20, 21, 25, 26, 27, 28, 29, 30 | RFC 6989, Section 2.3 |
+------------------------------------+-----------------------+
Groups 27-30 are defined in [RFC6954].
グループ27-30は[RFC6954]で定義されています。
Future documents that define new DH groups for IKEv2 are REQUIRED to provide this information for each new group, possibly by referring to the current document.
IKEv2の新しいDHグループを定義する将来のドキュメントでは、おそらく現在のドキュメントを参照して、新しいグループごとにこの情報を提供する必要があります。
We would like to thank Dan Harkins, who initially raised this issue on the IPsec mailing list. Thanks to Tero Kivinen and Rene Struik for their useful comments. Much of the text in Section 3 is taken from [RFC2412], and we would like to thank its author, Hilarie Orman.
最初にIPsecメーリングリストでこの問題を提起したDan Harkinsに感謝します。役立つコメントを提供してくれたTero KivinenとRene Struikに感謝します。セクション3のテキストの多くは[RFC2412]からの抜粋であり、その作者であるHilarie Ormanに感謝します。
The document was originally prepared using the lyx2rfc tool, created by Nico Williams.
このドキュメントは、Nico Williamsが作成したlyx2rfcツールを使用して最初に作成されました。
[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月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[IANA-IKEv2-Registry] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters/>.
[IANA-IKEv2-Registry] IANA、「Internet Key Exchange Version 2（IKEv2）Parameters」、<http://www.iana.org/assignments/ikev2-parameters/>。
[Kocher] Kocher, P., "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems", December 1996, <http://www.cryptography.com/timingattack/paper.html>.
[Kocher] Kocher、P。、「Diffie-Hellman、RSA、DSS、およびその他のシステムの実装に対するタイミング攻撃」、1996年12月、<http://www.cryptography.com/timingattack/paper.html>。
[Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In Diffie-Hellman Key Agreement Protocols", December 2008, <http://www.cacr.math.uwaterloo.ca/techreports/2008/ cacr2008-24.pdf>.
[メネゼス] Menezes、A。およびB. Ustaoglu、「Diffie-Hellman鍵合意プロトコルでの短命鍵の再利用について」、2008年12月、<http://www.cacr.math.uwaterloo.ca/techreports/2008/ cacr2008- 24.pdf>。
[NIST-800-56A] National Institute of Standards and Technology (NIST), "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST PUB 800-56A, March 2007.
[NIST-800-56A]国立標準技術研究所（NIST）、「離散対数暗号化を使用したペアワイズキー確立スキームの推奨（改訂）」、NIST PUB 800-56A、2007年3月。
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[RFC2412]オーマン、H。、「The OAKLEY鍵決定プロトコル」、RFC 2412、1998年11月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526] Kivinen、T。、およびM. Kojo、「インターネット鍵交換（IKE）のためのより多くのモジュラー指数（MODP）Diffie-Hellmanグループ」、RFC 3526、2003年5月。
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
[RFC5114] Lepinski、M。およびS. Kent、「IETF標準で使用するための追加のDiffie-Hellmanグループ」、RFC 5114、2008年1月。
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010.
[RFC5903] Fu、D。およびJ. Solinas、「IKEおよびIKEv2のPrimeを法とする楕円曲線グループ（ECPグループ）」、RFC 5903、2010年6月。
[RFC6954] Merkle, J. and M. Lochter, "Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 6954, July 2013.
[RFC6954] Merkle、J。およびM. Lochter、「Using Elliptic Curve Cryptography（ECC）Brainpool Curves for the Internet Key Exchange Protocol Version 2（IKEv2）」、RFC 6954、2013年7月。
Authors' Addresses
著者のアドレス
Yaron Sheffer Porticor
Yaron Sheffer Porticor
EMail: yaronf.ietf@gmail.com
Scott Fluhrer Cisco Systems 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Ｓこっｔ Ｆぅｈれｒ しｓこ Ｓｙｓてｍｓ １４１４ まっさちゅせっｔｓ あゔぇ。 ぼｘぼろうｇｈ、 ま ０１７１９ うさ
EMail: sfluhrer@cisco.com