[要約] RFC 6617は、IKEプロトコルのための安全な事前共有鍵（PSK）認証に関する規格です。その目的は、IKEセッションのセキュリティを向上させ、認証プロセスを強化することです。
Internet Engineering Task Force (IETF) D. Harkins
Request for Comments: 6617 Aruba Networks
Category: Experimental June 2012
ISSN: 2070-1721
Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE)
インターネットキー交換プロトコル（IKE）のセキュアな事前共有キー（PSK）認証
Abstract
概要
This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE). It is resistant to dictionary attack and retains security even when used with weak pre-shared keys.
このメモは、インターネットキー交換プロトコル（IKE）の安全な事前共有キー（PSK）認証方法について説明しています。辞書攻撃に耐性があり、弱い事前共有キーで使用した場合でもセキュリティを保持します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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/rfc6617.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6617で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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
1.1. Keyword Definitions ........................................3
2. Usage Scenarios .................................................3
3. Terms and Notation ..............................................4
4. Discrete Logarithm Cryptography .................................5
4.1. Elliptic Curve Cryptography (ECP) Groups ...................5
4.2. Finite Field Cryptography (MODP) Groups ....................7
5. Random Numbers ..................................................8
6. Using Passwords and Raw Keys For Authentication .................8
7. Assumptions .....................................................9
8. Secure PSK Authentication Message Exchange ......................9
8.1. Negotiation of Secure PSK Authentication ..................10
8.2. Fixing the Secret Element, SKE ............................11
8.2.1. ECP Operation to Select SKE ........................12
8.2.2. MODP Operation to Select SKE .......................13
8.3. Encoding and Decoding of Group Elements and Scalars .......14
8.3.1. Encoding and Decoding of Scalars ...................14
8.3.2. Encoding and Decoding of ECP Elements ..............15
8.3.3. Encoding and Decoding of MODP Elements .............15
8.4. Message Generation and Processing .........................16
8.4.1. Generation of a Commit .............................16
8.4.2. Processing of a Commit .............................16
8.4.2.1. Validation of an ECP Element ..............16
8.4.2.2. Validation of a MODP Element ..............16
8.4.2.3. Commit Processing Steps ...................17
8.4.3. Authentication of the Exchange .....................17
8.5. Payload Format ............................................18
8.5.1. Commit Payload .....................................18
8.6. IKEv2 Messaging ...........................................19
9. IANA Considerations ............................................20
10. Security Considerations .......................................20
11. Acknowledgements ..............................................22
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................23
[RFC5996] allows for authentication of the IKE peers using a pre-shared key. This exchange, though, is susceptible to dictionary attack and is therefore insecure when used with weak pre-shared keys, such as human-memorizable passwords. To address the security issue, [RFC5996] recommends that the pre-shared key used for authentication "contain as much unpredictability as the strongest key being negotiated". That means any non-hexadecimal key would require over 100 characters to provide enough strength to generate a 128-bit key suitable for AES. This is an unrealistic requirement because humans have a hard time entering a string over 20 characters without error. Consequently, pre-shared key authentication in [RFC5996] is used insecurely today.
[RFC5996]では、事前共有キーを使用してIKEピアの認証が可能です。ただし、この交換は辞書攻撃の影響を受けやすいため、人間が記憶できるパスワードなどの弱い事前共有キーを使用すると安全ではありません。セキュリティ問題に対処するため、[RFC5996]は、認証に使用される事前共有鍵に「ネゴシエートされる最強の鍵と同じくらい多くの予測不能性を含める」ことを推奨しています。つまり、AESに適した128ビットのキーを生成するために十分な強度を提供するには、16進法以外のキーでは100文字以上が必要になります。人間が20文字を超える文字列をエラーなしで入力するのは難しいため、これは非現実的な要件です。その結果、[RFC5996]の事前共有キー認証は、今日では安全に使用されていません。
A pre-shared key authentication method built on top of a zero-knowledge proof will provide resistance to dictionary attack and still allow for security when used with weak pre-shared keys, such as user-chosen passwords. Such an authentication method is described in this memo.
ゼロ知識証明の上に構築された事前共有キー認証方式は、辞書攻撃への耐性を提供し、ユーザーが選択したパスワードなどの弱い事前共有キーで使用した場合でもセキュリティを確保します。このような認証方法は、このメモに記載されています。
Resistance to dictionary attack is achieved when an adversary gets one, and only one, guess at the secret per active attack (see, for example, [BM92], [BMP00], and [BPR00]). Another way of putting this is that any advantage the adversary can realize is through interaction and not through computation. This is demonstrably different than the technique from [RFC5996] of using a large, random number as the pre-shared key. That can only make a dictionary attack less likely to succeed; it does not prevent a dictionary attack. Furthermore, as [RFC5996] notes, it is completely insecure when used with weak keys like user-generated passwords.
辞書攻撃への耐性は、攻撃者がアクティブな攻撃ごとにシークレットを推測するときに1つ（1つだけ）推測したときに達成されます（たとえば、[BM92]、[BMP00]、および[BPR00]を参照）。これを説明する別の方法は、攻撃者が実現できる利点は、計算ではなく相互作用によるということです。これは、事前共有鍵として大きな乱数を使用する[RFC5996]の手法とは明らかに異なります。これにより、辞書攻撃が成功する可能性が低くなるだけです。辞書攻撃を防ぐことはできません。さらに、[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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
[RFC5996] describes usage scenarios for IKEv2. These are:
[RFC5996]は、IKEv2の使用シナリオを説明しています。これらは：
1. "Security Gateway to Security Gateway Tunnel": The endpoints of the IKE (and IPsec) communication are network nodes that protect traffic on behalf of connected networks. Protected traffic is between devices on the respective protected networks.
1. 「Security Gateway to Security Gateway Tunnel」：IKE（およびIPsec）通信のエンドポイントは、接続されたネットワークに代わってトラフィックを保護するネットワークノードです。保護されたトラフィックは、それぞれの保護されたネットワーク上のデバイス間です。
2. "Endpoint-to-Endpoint Transport": The endpoints of the IKE (and IPsec) communication are hosts according to [RFC4301]. Protected traffic is between the two endpoints.
2. 「エンドポイントからエンドポイントへのトランスポート」：IKE（およびIPsec）通信のエンドポイントは、[RFC4301]によるホストです。保護されたトラフィックは2つのエンドポイント間です。
3. "Endpoint to Security Gateway Tunnel": One endpoint connects to a protected network through a network node. The endpoints of the IKE (and IPsec) communication are the endpoint and network node, but the protected traffic is between the endpoint and another device on the protected network behind the node.
3. 「エンドポイントからSecurity Gatewayへのトンネル」：1つのエンドポイントは、ネットワークノードを介して保護されたネットワークに接続します。 IKE（およびIPsec）通信のエンドポイントはエンドポイントとネットワークノードですが、保護されたトラフィックはエンドポイントとノードの背後にある保護されたネットワーク上の別のデバイスとの間です。
The authentication and key exchange process described in this memo is suitable for all the usage scenarios described in [RFC5996]. In the "Security Gateway to Security Gateway Tunnel" scenario and the "Endpoint-to-Endpoint Transport" scenario, it provides a secure method of authentication without requiring a certificate. For the "Endpoint to Security Gateway Tunnel" scenario, it provides for secure username+password authentication that is popular in remote-access VPN situations.
このメモで説明されている認証と鍵交換プロセスは、[RFC5996]で説明されているすべての使用シナリオに適しています。 「Security Gateway to Security Gateway Tunnel」シナリオおよび「Endpoint-to-Endpoint Transport」シナリオでは、証明書を必要としない安全な認証方法を提供します。 「エンドポイントからセキュリティゲートウェイトンネルへ」のシナリオでは、リモートアクセスVPNの状況で一般的な安全なユーザー名+パスワード認証を提供します。
The following terms and notations are used in this memo:
このメモでは、次の用語と表記が使用されています。
PSK A shared, secret, and potentially low-entropy word, phrase, code, or key used as a credential to mutually authenticate the peers.
PSKピアを相互認証するための資格情報として使用される、共有された、秘密の、潜在的に低エントロピーの単語、フレーズ、コード、またはキー。
a = prf(b, c) The string "b" and "c" are given to a pseudo-random function (prf) to produce a fixed-length output "a".
a = prf（b、c）文字列 "b"と "c"が疑似ランダム関数（prf）に渡され、固定長の出力 "a"が生成されます。
a | b denotes concatenation of string "a" with string "b".
a | bは、文字列 "a"と文字列 "b"の連結を示します。
[a]b indicates a string consisting of the single bit "a" repeated "b" times.
[a] bは、単一ビット「a」が「b」回繰り返された文字列を示します。
len(a) indicates the length in bits of the string "a".
len（a）は、文字列 "a"のビット単位の長さを示します。
LSB(a) returns the least-significant bit of the bitstring "a".
LSB（a）は、ビット文字列 "a"の最下位ビットを返します。
element one member of a finite cyclic group.
有限循環グループの1つの要素。
scalar a quantity that can multiply an element.
要素を乗算できる量をスカラーします。
The convention for this memo to represent an element in a finite cyclic group is to use an upper-case letter or acronym, while a scalar is indicated with a lowercase letter or acronym.
このメモが有限循環グループの要素を表すための規則は、大文字または頭字語を使用することですが、スカラーは小文字または頭字語で示されます。
This protocol uses Discrete Logarithm Cryptography to achieve authentication. Each party to the exchange derives ephemeral public and private keys with respect to a particular set of domain parameters (referred to here as a "group"). Groups can be either based on finite field cryptography (modular exponentiation (MODP) groups) or elliptic curve cryptography (ECP groups).
このプロトコルは、離散対数暗号を使用して認証を実現します。取引所の各当事者は、特定のドメインパラメータセット（ここでは「グループ」と呼びます）に関して一時的な公開鍵と秘密鍵を導出します。グループは、有限体暗号（モジュラ指数（MODP）グループ）または楕円曲線暗号（ECPグループ）のいずれかに基づくことができます。
This protocol uses the same group as the IKE exchange in which it is being used for authentication, with the exception of characteristic-two elliptic curve groups (EC2N). Use of such groups is undefined for this authentication method, and an IKE exchange that negotiates one of these groups MUST NOT use this method of authentication.
このプロトコルは、特性2の楕円曲線グループ（EC2N）を除いて、認証に使用されているIKE交換と同じグループを使用します。そのようなグループの使用はこの認証方法では定義されておらず、これらのグループの1つをネゴシエートするIKE交換はこの認証方法を使用してはなりません（MUST NOT）。
For each group, the following operations are defined:
グループごとに、次の操作が定義されています。
o "scalar operation" -- takes a scalar and an element in the group to produce another element -- Z = scalar-op(x, Y).
o 「スカラー演算」-グループ内のスカラーと要素を取り、別の要素を生成します-Z = scalar-op（x、Y）。
o "element operation" -- takes two elements in the group to produce a third -- Z = element-op(X, Y).
o 「要素演算」-グループ内の2つの要素を使用して、3番目の要素を生成します-Z = element-op（X、Y）。
o "inverse operation" -- takes an element and returns another element such that the element operation on the two produces the identity element of the group -- Y = inverse(X).
o 「逆演算」-要素を受け取り、2つの要素の演算がグループの単位要素を生成するように別の要素を返します-Y = reverse（X）。
The key exchange defined in this memo uses fundamental algorithms of ECP groups as described in [RFC6090].
このメモで定義された鍵交換は、[RFC6090]で説明されているECPグループの基本的なアルゴリズムを使用します。
Domain parameters for ECP elliptic curves used for Secure PSK Authentication include:
セキュアPSK認証に使用されるECP楕円曲線のドメインパラメータには、次のものがあります。
o A prime, p, determining a prime field GF(p). The cryptographic group will be a subgroup of the full elliptic curve group that consists of points on an elliptic curve -- elements from GF(p) that satisfy the curve's equation -- together with the "point at infinity" (denoted here as "0") that serves as the identity element.
o 素数pは、素体GF（p）を決定します。暗号グループは、楕円曲線上の点（曲線の方程式を満たすGF（p）の要素）と「無限遠点」（ここでは「0」と表記）で構成される完全な楕円曲線グループのサブグループになります。 "）アイデンティティ要素として機能します。
o Elements a and b from GF(p) that define the curve's equation. The point (x,y) is on the elliptic curve if and only if y^2 = x^3 + a*x + b.
o 曲線の方程式を定義するGF（p）の要素aおよびb。点（x、y）は、y ^ 2 = x ^ 3 + a * x + bの場合に限り、楕円曲線上にあります。
o A prime, r, which is the order of, or number of elements in, a subgroup generated by an element G.
o 素数rは、要素Gによって生成されたサブグループ内の要素の順序または数です。
The scalar operation is multiplication of a point on the curve by itself a number of times. The point Y is multiplied x-times to produce another point Z:
スカラー演算は、曲線上の点をそれ自体で何度も乗算することです。点Yはx倍され、別の点Zを生成します。
Z = scalar-op(x, Y) = x*Y
The element operation is addition of two points on the curve. Points X and Y are summed to produce another point Z:
要素の操作は、曲線上の2点の加算です。ポイントXとYを合計して、別のポイントZを生成します。
Z = element-op(X, Y) = X + Y
The inverse function is defined such that the sum of an element and its inverse is "0", the point-at-infinity of an elliptic curve group:
逆関数は、要素とその逆の和が「0」、つまり楕円曲線グループの無限遠点になるように定義されています。
Q + inverse(Q) = "0"
Elliptic curve groups require a mapping function, q = F(Q), to convert a group element to an integer. The mapping function used in this memo returns the x-coordinate of the point it is passed.
楕円曲線グループには、グループ要素を整数に変換するためのマッピング関数q = F（Q）が必要です。このメモで使用されているマッピング関数は、渡された点のx座標を返します。
scalar-op(x, Y) can be viewed as x iterations of element-op() by defining:
scalar-op（x、Y）は、以下を定義することにより、element-op()のx回の反復と見なすことができます。
Y = scalar-op(1, Y)
Y =スカラー演算（1、Y）
Y = scalar-op(x, Y) = element-op(Y, scalar-op(x-1, Y)), for x > 1
A definition of how to add two points on an elliptic curve (i.e., element-op(X, Y)) can be found in [RFC6090].
楕円曲線に2つの点を追加する方法の定義（つまり、element-op（X、Y））は、[RFC6090]にあります。
Note: There is another ECP domain parameter, a cofactor, h, that is defined by the requirement that the size of the full elliptic curve group (including "0") be the product of h and r. ECP groups used for Secure PSK Authentication MUST have a cofactor of one (1). At the time of publication of this memo, all ECP groups in [IKEV2-IANA] had a cofactor of one (1).
注：別のECPドメインパラメーター、補因子hがあります。これは、完全な楕円曲線グループ（「0」を含む）のサイズがhとrの積であるという要件によって定義されます。セキュアPSK認証に使用されるECPグループには、補因子1が必要です。このメモの発行時点では、[IKEV2-IANA]のすべてのECPグループの補因子は1でした。
Domain parameters for MODP groups used for Secure PSK Authentication include:
セキュアPSK認証に使用されるMODPグループのドメインパラメータは次のとおりです。
o A prime, p, determining a prime field GF(p), the integers modulo p.
o 素数p、素数体GF（p）、pを法とする整数を決定します。
o A prime, r, which is the multiplicative order, and thus also the size, of the cryptographic subgroup of GF(p)* that is generated by an element G.
o 要素Gによって生成されるGF（p）*の暗号サブグループの乗法次数であり、したがってサイズでもある素数r
The scalar operation is exponentiation of a generator modulo a prime. An element Y is taken to the x-th power modulo the prime, thereby returning another element, Z:
スカラー演算は、素数を法とするジェネレータの累乗です。要素Yは、素数を法としてx乗され、それによって別の要素Zを返します。
Z = scalar-op(x, Y) = Y^x mod p
The element operation is modular multiplication. Two elements, X and Y, are multiplied modulo the prime, thereby returning another element, Z:
要素演算はモジュラー乗算です。 2つの要素XとYは素数を法として乗算され、それによって別の要素Zを返します。
Z = element-op(X, Y) = (X * Y) mod p
The inverse function for a MODP group is defined such that the product of an element and its inverse modulo the group prime equals one (1). In other words,
MODPグループの逆関数は、要素の素数とグループの素数を法とするその逆の積が1になるように定義されています。言い換えると、
(Q * inverse(Q)) mod p = 1
Unlike ECP groups, MODP groups do not require a mapping function to convert an element into an integer. However, for the purposes of notation in protocol definition, the function F, when used below, shall just return the value that was passed to it, i.e., F(i) = i.
ECPグループとは異なり、MODPグループは、要素を整数に変換するためのマッピング関数を必要としません。ただし、プロトコル定義での表記のために、関数Fは、以下で使用される場合、渡された値を返すだけです。つまり、F（i）= iです。
Some MODP groups in [IKEV2-IANA] are based on safe primes, and the order is not included in the group's domain parameter set. In this case only, the order, r, MUST be computed as the prime minus one divided by two -- (p-1)/2. If an order is included in the group's domain parameter set, that value MUST be used in this exchange when an order is called for. If a MODP group does not include an order in its domain parameter set and is not based on a safe prime, it MUST NOT be used with this exchange.
[IKEV2-IANA]の一部のMODPグループは安全な素数に基づいており、順序はグループのドメインパラメータセットに含まれていません。この場合のみ、次数rは、素数から1を2で割った値-（p-1）/ 2として計算する必要があります。注文がグループのドメインパラメータセットに含まれている場合、注文が呼び出されたときに、この交換でその値を使用する必要があります。 MODPグループのドメインパラメータセットに順序が含まれておらず、安全な素数に基づいていない場合は、この交換で使用してはなりません（MUST NOT）。
As with IKE itself, the security of the Secure PSK Authentication method relies upon each participant in the protocol producing quality secret random numbers. A poor random number chosen by either side in a single exchange can compromise the shared secret from that exchange and open up the possibility of a dictionary attack.
IKE自体と同様に、Secure PSK認証方式のセキュリティは、高品質の秘密の乱数を生成するプロトコルの各参加者に依存しています。 1回の交換でどちらかの側で選択された貧弱な乱数は、その交換からの共有秘密を危険にさらし、辞書攻撃の可能性を開く可能性があります。
Producing quality random numbers without specialized hardware entails using a cryptographic mixing function (like a strong hash function) to mix entropy from multiple, uncorrelated sources of information and events. A very good discussion of this can be found in [RFC4086].
特殊なハードウェアなしで高品質の乱数を生成するには、暗号ミキシング関数（強力なハッシュ関数など）を使用して、相関のない複数の情報およびイベントのソースからのエントロピーを混合する必要があります。これに関する非常に良い議論は[RFC4086]で見つけることができます。
The PSK used as an authentication credential with this protocol can be either a character-based password or passphrase, or it could be a binary or hexadecimal string. Regardless, however, this protocol requires both the Initiator and Responder to have identical binary representations of the shared credential.
このプロトコルで認証資格情報として使用されるPSKは、文字ベースのパスワードまたはパスフレーズのいずれかであるか、2進数または16進数の文字列である可能性があります。ただし、これに関係なく、このプロトコルでは、イニシエーターとレスポンダーの両方が共有資格情報の同一のバイナリ表現を持つ必要があります。
If the PSK is a character-based password or passphrase, there are two types of pre-processing that SHALL be employed to convert the password or passphrase into a hexadecimal string suitable for use with Secure PSK Authentication. If a PSK is already a hexadecimal or binary string, it SHALL be used directly as the shared credential without any pre-processing.
PSKが文字ベースのパスワードまたはパスフレーズである場合、2つのタイプの前処理を使用して、パスワードまたはパスフレーズをセキュアPSK認証での使用に適した16進文字列に変換する必要があります（SHALL）。 PSKがすでに16進数または2進数の文字列である場合、事前処理なしで共有資格情報として直接使用する必要があります。
The first step of pre-processing is to remove ambiguities that may arise due to internationalization. Each character-based password or passphrase MUST be pre-processed to remove that ambiguity by processing the character-based password or passphrase according to the rules of the SASLprep [RFC4013] profile of [RFC3454]. The password or passphrase SHALL be considered a "stored string" per [RFC3454], and unassigned code points are therefore prohibited. The output SHALL be the binary representation of the processed UTF-8 character string. Prohibited output and unassigned codepoints encountered in SASLprep pre-processing SHALL cause a failure of pre-processing, and the output SHALL NOT be used with Secure PSK Authentication.
前処理の最初のステップは、国際化によって生じる可能性のある曖昧さを取り除くことです。各文字ベースのパスワードまたはパスフレーズは、[RFC3454]のSASLprep [RFC4013]プロファイルのルールに従って文字ベースのパスワードまたはパスフレーズを処理することにより、あいまいさを取り除くために前処理する必要があります。パスワードまたはパスフレーズは[RFC3454]に従って「格納された文字列」と見なされる必要があり、したがって、割り当てられていないコードポイントは禁止されています。出力は、処理されたUTF-8文字列のバイナリ表現である必要があります。 SASLprep前処理で発生する禁止された出力と割り当てられていないコードポイントは、前処理の失敗の原因となり、出力はセキュアPSK認証で使用されないものとします（SHALL）。
The next pre-processing step for character-based passwords or passphrases is to effectively obfuscate the string. This is done in an attempt to reduce exposure of stored passwords in the event of server compromise, or compromise of a server's database of stored passwords. The step involves taking the output of the SASLprep [RFC4013] profile of [RFC3454] and passing it, as the key, with the ASCII string "IKE Secure PSK Authentication", as the data, to HMAC-SHA256(). The output of this obfuscation step SHALL become the shared credential used with Secure PSK Authentication.
文字ベースのパスワードまたはパスフレーズの次の前処理手順は、文字列を効果的に難読化することです。これは、サーバーが侵害された場合、またはサーバーの保存されたパスワードのデータベースが侵害された場合に、保存されたパスワードの漏洩を減らすために行われます。このステップでは、[RFC3454]のSASLprep [RFC4013]プロファイルの出力を取得し、それをキーとして、ASCII文字列「IKE Secure PSK Authentication」とともにデータとしてHMAC-SHA256()に渡します。この難読化ステップの出力は、セキュアPSK認証で使用される共有資格情報になります。
Note: Passwords tend to be shared for multiple purposes, and compromise of a server or database of stored plaintext passwords can be used, in that event, to mount multiple attacks. The obfuscation step is merely to hide the password in the event of server compromise or compromise of the database of stored passwords. Advances in distributed computing power have diminished the effectiveness of performing multiple prf iterations as a technique to prevent dictionary attacks, so no such behavior is proscribed here. Mutually consenting implementations can agree to use a different password obfuscation method; the one described here is for interoperability purposes only.
注：パスワードは複数の目的で共有される傾向があり、保存されたプレーンテキストパスワードのサーバーまたはデータベースの侵害は、その場合、複数の攻撃を仕掛けるために使用できます。難読化の手順は、サーバーが侵害された場合、または保存されているパスワードのデータベースが侵害された場合に、パスワードを隠すことだけです。分散コンピューティング能力の進歩により、辞書攻撃を防止する手法として複数のprf反復を実行する効果が低下しているため、ここではそのような動作は禁止されています。相互に同意する実装は、別のパスワード難読化方法を使用することに同意できます。ここで説明するものは、相互運用性のみを目的としています。
If a device stores passwords for use at a later time, it SHOULD pre-process the password prior to storage. If a user enters a password into a device at authentication time, it MUST be pre-processed upon entry and prior to use with Secure PSK Authentication.
デバイスが後で使用するためにパスワードを保存する場合、保存する前にパスワードを前処理する必要があります。ユーザーが認証時にデバイスにパスワードを入力する場合、入力時およびセキュアPSK認証で使用する前に、事前に処理する必要があります。
The security of the protocol relies on certain assumptions. They are:
プロトコルのセキュリティは、特定の前提に依存しています。彼らです：
1. The pseudo-random function, prf, defined in [RFC5996], acts as an "extractor" (see [RFC5869]) by distilling the entropy from a secret input into a short, fixed string. The output of prf is indistinguishable from a random source.
1. [RFC5996]で定義されている疑似ランダム関数prfは、秘密の入力からエントロピーを短い固定文字列に抽出することにより、「抽出器」（[RFC5869]を参照）として機能します。 prfの出力は、ランダムなソースと区別できません。
2. The discrete logarithm problem for the chosen finite cyclic group is hard. That is, given G, p and Y = G^x mod p, it is computationally infeasible to determine x. Similarly, for an elliptic curve group given the curve definition, a generator G, and Y = x * G, it is computationally infeasible to determine x.
2. 選択した有限巡回グループの離散対数問題は困難です。つまり、G、p、Y = G ^ x mod pの場合、xを決定することは計算上不可能です。同様に、曲線の定義、ジェネレーターG、およびY = x * Gが指定された楕円曲線グループの場合、xを決定することは計算上実行不可能です。
3. The pre-shared key is drawn from a finite pool of potential keys. Each possible key in the pool has equal probability of being the shared key. All potential adversaries have access to this pool of keys.
3. 事前共有キーは、潜在的なキーの有限プールから取得されます。プール内の可能な各キーは、共有キーである確率が同じです。潜在的な敵はすべて、このキーのプールにアクセスできます。
The key exchange described in this memo is based on the "Dragonfly" key exchange, which has also been defined for use in 802.11 wireless networks (see [SAE]) and as an Extensible Authentication Protocol (EAP) method (see [RFC5931]). "Dragonfly" is patent-free and royalty-free. It SHALL use the same pseudo-random function (prf) and the same Diffie-Hellman group that are negotiated for use in the IKE exchange that "Dragonfly" is authenticating.
このメモで説明されているキー交換は、「Dragonfly」キー交換に基づいています。これは、802.11ワイヤレスネットワーク（[SAE]を参照）での使用と、Extensible Authentication Protocol（EAP）メソッドとしても定義されています（[RFC5931]を参照）。 。 「Dragonfly」は特許と著作権使用料なしです。 「Dragonfly」が認証しているIKE交換で使用するためにネゴシエートされたものと同じ擬似ランダム関数（prf）と同じDiffie-Hellmanグループを使用する必要があります。
A pseudo-random function that uses a block cipher is NOT RECOMMENDED for use with Secure PSK Authentication due to its poor job operating as an "extractor" (see Section 7). Pseudo-random functions based on hash functions using the HMAC construct from [RFC2104] SHOULD be used.
ブロック暗号を使用する疑似ランダム関数は、「抽出器」として機能するジョブが不十分であるため、セキュアPSK認証での使用は推奨されません（セクション7を参照）。 [RFC2104]のHMACコンストラクトを使用したハッシュ関数に基づく擬似ランダム関数を使用する必要があります（SHOULD）。
To perform Secure PSK Authentication, each side must generate a shared and secret element in the chosen group based on the pre-shared key. This element, called the Secret Key Element, or SKE, is then used in the "Dragonfly" authentication and key exchange protocol. "Dragonfly" consists of each side exchanging a Commit payload and then proving knowledge of the resulting shared secret.
セキュアなPSK認証を実行するには、事前共有キーに基づいて、選択したグループで共有要素と秘密要素を生成する必要があります。秘密鍵要素（SKE）と呼ばれるこの要素は、「Dragonfly」認証および鍵交換プロトコルで使用されます。 「Dragonfly」は、Commitペイロードを交換し、結果として得られる共有秘密の知識を証明する両側で構成されます。
The Commit payload contributes ephemeral information to the exchange and binds the sender to a single value of the pre-shared key from the pool of potential pre-shared keys. An authentication payload (AUTH) proves that the pre-shared key is known and completes the zero-knowledge proof.
Commitペイロードは、一時的な情報を交換に提供し、送信者を潜在的な事前共有キーのプールからの事前共有キーの単一の値にバインドします。認証ペイロード（AUTH）は、事前共有鍵が既知であることを証明し、ゼロ知識証明を完了します。
The Initiator indicates its desire to use Secure PSK Authentication by adding a Notify payload of type SECURE_PASSWORD_METHODS (see [RFC6467]) to the first message of the IKE_SA_INIT exchange and by including 3 in the notification data field of the Notify payload, indicating Secure PSK Authentication.
イニシエーターは、IKE_SA_INIT交換の最初のメッセージにタイプSECURE_PASSWORD_METHODS（[RFC6467]を参照）のNotifyペイロードを追加し、Notifyペイロードの通知データフィールドに3を含めることで、セキュアPSK認証を使用することを示し、セキュアPSK認証を示します。 。
The Responder indicates its acceptance to perform Secure PSK Authentication by adding a Notify payload of type SECURE_PASSWORD_METHODS to its response in the IKE_SA_INIT exchange and by adding the sole value of 3 to the notification data field of the Notify payload.
Responderは、IKE_SA_INIT交換の応答にSECURE_PASSWORD_METHODSタイプのNotifyペイロードを追加し、Notifyペイロードの通知データフィールドに唯一の値3を追加することにより、セキュアPSK認証の実行の受け入れを示します。
If the Responder does not include a Notify payload of type SECURE_PASSWORD_METHODS in its IKE_SA_INIT response, the Initiator MUST terminate the exchange, and it MUST NOT fall back to the PSK authentication method of [RFC5996]. If the Initiator only indicated its support for Secure PSK Authentication (i.e., if the Notify data field only contained 3) and the Responder replies with a Notify payload of type SECURE_PASSWORD_METHODS and a different value in the Notify data field, the Initiator MUST terminate the exchange.
ResponderがIKE_SA_INIT応答にタイプSECURE_PASSWORD_METHODSのNotifyペイロードを含めない場合、イニシエーターは交換を終了しなければならず（MUST）、[RFC5996]のPSK認証方式にフォールバックしてはならない（MUST NOT）。イニシエーターがセキュアPSK認証のサポートのみを示した場合（つまり、通知データフィールドに3のみが含まれていた場合）、レスポンダは、タイプSECURE_PASSWORD_METHODSの通知ペイロードと、通知データフィールドの異なる値で応答する場合、イニシエーターは交換を終了する必要があります。 。
The method of fixing SKE depends on the type of group, either MODP or ECP. The function "prf+" from [RFC5996] is used as a key derivation function.
SKEの修正方法は、グループのタイプ（MODPまたはECP）によって異なります。 [RFC5996]の関数「prf +」は、鍵導出関数として使用されます。
Fixing SKE involves an iterative hunting-and-pecking technique using the prime from the negotiated group's domain parameter set and an ECP- or MODP-specific operation depending on the negotiated group. This technique requires the pre-shared key to be a binary string; therefore, any pre-processing transformation (see Section 6) MUST be performed on the pre-shared key prior to fixing SKE.
SKEの修正には、ネゴシエートされたグループのドメインパラメータセットの素数と、ネゴシエートされたグループに応じたECPまたはMODP固有の操作を使用した、反復的なハンティングアンドペッキング技術が含まれます。この手法では、事前共有キーがバイナリ文字列である必要があります。したがって、SKEを修正する前に、事前共有キーに対して前処理変換（セクション6を参照）を実行する必要があります。
To thwart side-channel attacks that attempt to determine the number of iterations of the hunting-and-pecking loop that are used to find SKE for a given password, a security parameter, k, is used to ensure that at least k iterations are always performed.
特定のパスワードのSKEを見つけるために使用されるハンティング/ペッキングループの反復回数を決定しようとするサイドチャネル攻撃を阻止するために、セキュリティパラメータkを使用して、少なくともk回の反復が常に行われるようにします。実行されました。
Prior to beginning the hunting-and-pecking loop, an 8-bit counter is set to the value one (1). Then the loop begins. First, the pseudo-random function is used to generate a secret seed using the counter, the pre-shared key, and two nonces (without the fixed headers) exchanged by the Initiator and the Responder (see Section 8.6):
ハンティングアンドペッキングループを開始する前に、8ビットカウンターが値1に設定されます。その後、ループが始まります。最初に、疑似ランダム関数を使用して、カウンター、事前共有キー、およびイニシエーターとレスポンダーによって交換される2つのナンス（固定ヘッダーなし）を使用してシークレットシードを生成します（セクション8.6を参照）。
ske-seed = prf(Ni | Nr, psk | counter)
ske-seed = prf（Ni | Nr、psk | counter）
Then, the ske-seed is expanded using prf+ to create an ske-value:
次に、prf +を使用してske-seedを展開し、ske-valueを作成します。
ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking")
ske-value = prf +（ske-seed、「IKE SKE Hunting And Pecking」）
where len(ske-value) is the same as len(p), the length of the prime from the domain parameter set of the negotiated group.
ここで、len（ske-value）は、交渉されたグループのドメインパラメータセットからの素数の長さlen（p）と同じです。
If the ske-seed is greater than or equal to the prime, p, the counter is incremented, a new ske-seed is generated, and the hunting-and-pecking continues. If ske-seed is less than the prime, p, it is passed to the group-specific operation to select the SKE or fail. If the group-specific operation fails, the counter is incremented, a new ske-seed is generated, and the hunting-and-pecking continues. This process continues until the group-specific operation returns the password element. After the password element has been chosen, a random number is used in place of the password in the ske-seed calculation, and the hunting-and-pecking continues until the counter is greater than the security parameter, k.
スケシードが素数p以上の場合、カウンターがインクリメントされ、新しいスケシードが生成され、ハンティングとペッキングが続行されます。 ske-seedが素数pより小さい場合は、SKEをグループ固有の操作に渡して、SKEを選択するか、失敗します。グループ固有の操作が失敗すると、カウンターが増加し、新しいske-seedが生成され、ハンティングアンドペッキングが続行されます。このプロセスは、グループ固有の操作がパスワード要素を返すまで続きます。パスワード要素が選択された後、ske-seedの計算ではパスワードの代わりに乱数が使用され、カウンターがセキュリティパラメータkを超えるまでハンティングアンドペッキングが続行されます。
The group-specific operation for ECP groups uses ske-value, ske-seed, and the equation of the curve to produce SKE. First, ske-value is used directly as the x-coordinate, x, with the equation of the elliptic curve, with parameters a and b from the domain parameter set of the curve, to solve for a y-coordinate, y.
ECPグループのグループ固有の操作では、ske-value、ske-seed、および曲線の方程式を使用してSKEを生成します。最初に、ske-valueが楕円座標の方程式でx座標xとして直接使用され、曲線のドメインパラメーターセットからのパラメーターaおよびbを使用して、y座標yを解決します。
Note: A method of checking whether a solution to the equation of the elliptic curve is to see whether the Legendre symbol of (x^3 + ax + b) equals one (1). If it does, then a solution exists; if it does not, then there is no solution.
注：楕円曲線の方程式の解がどうかをチェックする方法は、（x ^ 3 + ax + b）のルジャンドル記号が1に等しいかどうかを確認することです。存在する場合、解決策が存在します。そうでない場合、解決策はありません。
If there is no solution to the equation of the elliptic curve, then the operation fails, the counter is incremented, a new ske-value and ske-seed are selected, and the hunting-and-pecking continues. If there is a solution then, y is calculated as the square root of (x^3 + ax + b) using the equation of the elliptic curve. In this case, an ambiguity exists as there are technically two solutions to the equation, and ske-seed is used to unambiguously select one of them. If the low-order bit of ske-seed is equal to the low-order bit of y, then a candidate SKE is defined as the point (x,y); if the low-order bit of ske-seed differs from the low-order bit of y then a candidate SKE is defined as the point (x, p-y) where p is the prime from the negotiated group's domain parameter set. The candidate SKE becomes the SKE, and the ECP-specific operation completes successfully.
楕円曲線の方程式に対する解がない場合、操作は失敗し、カウンターがインクリメントされ、新しいske値とske-seedが選択され、ハンティングとペッキングが続行されます。解がある場合、yは楕円曲線の方程式を使用して、（x ^ 3 + ax + b）の平方根として計算されます。この場合、方程式には技術的に2つのソリューションがあり、ske-seedを使用してそれらの1つを明確に選択するため、あいまいさが存在します。 ske-seedの下位ビットがyの下位ビットと等しい場合、候補SKEは点（x、y）として定義されます。 ske-seedの下位ビットがyの下位ビットと異なる場合、候補SKEは点（x、p-y）として定義されます。ここで、pは交渉されたグループのドメインパラメーターセットの素数です。候補のSKEがSKEになり、ECP固有の操作が正常に完了します。
Algorithmically, the process looks like this:
アルゴリズム的には、プロセスは次のようになります。
found = 0
counter = 1
v = psk
do {
ske-seed = prf(Ni | Nr, v | counter)
ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking")
if (ske-value < p)
then
x = ske-value
if ( (y = sqrt(x^3 + ax + b)) != FAIL)
then
if (found == 0)
then
if (LSB(y) == LSB(ske-seed))
then
SKE = (x,y)
else
SKE = (x, p-y)
fi
found = 1
v = random()
fi
fi
fi
counter = counter + 1
} while ((found == 0) || (counter <= k))
where FAIL indicates that there is no solution to sqrt(x^3 + ax + b).
ここで、FAILはsqrt（x ^ 3 + ax + b）の解がないことを示しています。
Figure 1: Fixing SKE for ECP Groups
図1：ECPグループのSKEの修正
Note: For ECP groups, the probability that more than "n" iterations of the hunting-and-pecking loop are required to find SKE is roughly (1-(r/2p))^n, which rapidly approaches zero (0) as "n" increases.
注：ECPグループの場合、SKEを見つけるためにハンティングとペッキングループの "n"回以上の反復が必要になる確率は、およそ（1-（r / 2p））^ nであり、次のように急速にゼロ（0）に近づきます。 「n」が増加します。
The group-specific operation for MODP groups takes ske-value, the prime, p, and order, r, from the group's domain parameter set to directly produce a candidate SKE by exponentiating the ske-value to the value ((p-1)/r) modulo the prime. If the candidate SKE is greater than one (1), the candidate SKE becomes the SKE, and the MODP-specific operation completes successfully. Otherwise, the MODP-specific operation fails (and the hunting-and-pecking continues).
MODPグループのグループ固有の操作は、グループのドメインパラメータセットからske-value、素数、p、および順序rを取得し、ske-valueを値（（p-1） / r）素数を法として候補のSKEが1より大きい場合、候補のSKEがSKEになり、MODP固有の操作が正常に完了します。それ以外の場合、MODP固有の操作は失敗します（そして、ハンティングアンドペッキングが続行されます）。
Algorithmically, the process looks like this:
アルゴリズム的には、プロセスは次のようになります。
found = 0
counter = 1
v = psk
do {
ske-seed = prf(Ni | Nr, v | counter)
ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking")
if (ske-value < p)
then
ELE = ske-value ^ ((p-1)/r) mod p
if (ELE > 1)
then
if (found == 0)
SKE = ELE
found = 1
v = random()
fi
fi
fi
counter = counter + 1
} while ((found == 0) || (counter <= k))
Figure 2: Fixing SKE for MODP Groups
図2：MODPグループのSKEの修正
Note: For MODP groups, the probability that more than "n" iterations of the hunting-and-pecking loop are required to find SKE is roughly ((m-p)/p)^n, where m is the largest unsigned number that can be expressed in len(p) bits, which rapidly approaches zero (0) as "n" increases.
注：MODPグループの場合、SKEを見つけるためにハンティングとペッキングループの「n」回以上の反復が必要になる確率は、およそ（（mp）/ p）^ nです。ここで、mは、 len（p）ビットで表され、「n」が増加するにつれて、ゼロ（0）に急速に近づきます。
The payloads used in the Secure PSK Authentication method contain elements from the negotiated group and scalar values. To ensure interoperability, scalars and field elements MUST be represented in payloads in accordance with the requirements in this section.
セキュアPSK認証方式で使用されるペイロードには、ネゴシエートされたグループの要素とスカラー値が含まれています。相互運用性を確保するには、このセクションの要件に従って、スカラーとフィールド要素をペイロードで表現する必要があります。
Scalars MUST be represented (in binary form) as unsigned integers that are strictly less than r, the order of the generator of the agreed-upon cryptographic group. The binary representation of each scalar MUST have a bit length equal to the bit length of the binary representation of r. This requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved.
スカラーは、合意された暗号グループの生成元の順序であるrよりも厳密に小さい符号なし整数として（バイナリ形式で）表現する必要があります。各スカラーのバイナリ表現は、rのバイナリ表現のビット長と等しいビット長を持つ必要があります。この要件は、必要に応じて、必要な長さが達成されるまで整数のバイナリ表現にゼロを付加することによって適用されます。
Scalars in the form of unsigned integers are converted into octet strings and back again using the technique described in [RFC6090].
符号なし整数の形式のスカラーはオクテット文字列に変換され、[RFC6090]で説明されている手法を使用して再び戻されます。
Elements in ECP groups are points on the negotiated elliptic curve. Each such element MUST be represented by the concatenation of two components, an x-coordinate and a y-coordinate.
ECPグループの要素は、交渉された楕円曲線上の点です。このような各要素は、x座標とy座標の2つのコンポーネントの連結で表現する必要があります。
Each of the two components, the x-coordinate and the y-coordinate, MUST be represented (in binary form) as an unsigned integer that is strictly less than the prime, p, from the group's domain parameter set. The binary representation of each component MUST have a bit length equal to the bit length of the binary representation of p. This length requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved.
x座標とy座標の2つのコンポーネントはそれぞれ、グループのドメインパラメータセットからの素数pよりも厳密に小さい符号なし整数として（バイナリ形式で）表現する必要があります。各コンポーネントのバイナリ表現は、pのバイナリ表現のビット長と等しいビット長を持つ必要があります。この長さの要件は、必要に応じて、必要な長さが達成されるまで整数のバイナリ表現にゼロを付加することによって適用されます。
The unsigned integers that represent the coordinates of the point are converted into octet strings and back again using the technique described in [RFC6090].
ポイントの座標を表す符号なし整数は、オクテット文字列に変換され、[RFC6090]で説明されている手法を使用して再び戻されます。
Since the field element is represented in a payload by the x-coordinate followed by the y-coordinate, it follows, then, that the length of the element in the payload MUST be twice the bit length of p.
フィールド要素はペイロードでx座標とそれに続くy座標で表されるので、ペイロードの要素の長さはpのビット長の2倍でなければなりません。
Elements in MODP groups MUST be represented (in binary form) as unsigned integers that are strictly less than the prime, p, from the group's domain parameter set. The binary representation of each group element MUST have a bit length equal to the bit length of the binary representation of p. This length requirement is enforced, if necessary, by prepending the binary representation of the integer with zeros until the required length is achieved.
MODPグループの要素は、グループのドメインパラメータセットからの素数pよりも厳密に小さい符号なし整数として（バイナリ形式で）表現する必要があります。各グループ要素のバイナリ表現は、pのバイナリ表現のビット長と等しいビット長を持つ必要があります。この長さの要件は、必要に応じて、必要な長さが達成されるまで整数のバイナリ表現にゼロを付加することによって適用されます。
The unsigned integer that represents a MODP element is converted into an octet string and back using the technique described in [RFC6090].
MODP要素を表す符号なし整数は、オクテット文字列に変換され、[RFC6090]で説明されている手法を使用して戻されます。
Before a Commit payload can be generated, the SKE must be fixed using the process described in Section 8.2.
コミットペイロードを生成する前に、セクション8.2で説明されているプロセスを使用してSKEを修正する必要があります。
A Commit payload has two components, a scalar and an element. To generate a Commit payload, two random numbers, a "private" value and a "mask" value, are generated (see Section 5). Their sum modulo the order of the group, r, becomes the scalar component:
Commitペイロードには、スカラーと要素の2つのコンポーネントがあります。コミットペイロードを生成するために、「プライベート」値と「マスク」値の2つの乱数が生成されます（セクション5を参照）。グループの次数を法とする和rは、スカラーコンポーネントになります。
scalar = (private + mask) mod r
If the scalar is not greater than one (1), the private and mask values MUST be thrown away, and new values randomly generated. If the scalar is greater than one (1), the inverse of the scalar operation with the mask and SKE becomes the element component.
スカラーが1以下の場合、private値とmask値を破棄し、新しい値をランダムに生成する必要があります。スカラーが1より大きい場合、マスクとSKEを使用したスカラー演算の逆が要素コンポーネントになります。
Element = inverse(scalar-op(mask, SKE))
The Commit payload consists of the scalar followed by the element, and the scalar and element are encoded in the Commit payload according to Section 8.3.
Commitペイロードは、要素が後に続くスカラーで構成され、スカラーと要素は、セクション8.3に従ってCommitペイロードでエンコードされます。
Upon receipt of a peer's Commit payload, the scalar and element MUST be validated. The processing of an element depends on the type, either an ECP element or a MODP element.
ピアのコミットペイロードを受信したら、スカラーと要素を検証する必要があります。要素の処理は、ECP要素またはMODP要素のどちらかのタイプによって異なります。
Validating a received ECP element involves: 1) checking whether the two coordinates, x and y, are both greater than zero (0) and less than the prime defining the underlying field; and 2) checking whether the x- and y-coordinates satisfy the equation of the curve (that is, that they produce a valid point on the curve that is not "0"). If either of these conditions are not met, the received element is invalid; otherwise, the received element is valid.
受信したECP要素の検証には、次のことが含まれます。1）2つの座標xとyの両方がゼロ（0）より大きく、基になるフィールドを定義する素数より小さいかどうかを確認します。 2）x座標とy座標が曲線の方程式を満たすかどうか（つまり、「0」ではない曲線上の有効な点を生成するかどうか）をチェックします。これらの条件のいずれかが満たされない場合、受信した要素は無効です。それ以外の場合、受信した要素は有効です。
A received MODP element is valid if: 1) it is between one (1) and the prime, p, exclusive; and 2) if modular exponentiation of the element by the group order, r, equals one (1). If either of these conditions are not true, the received element is invalid; otherwise, the received element is valid.
受信したMODP要素は、次の場合に有効です。1）1と素数pの間である。 2）グループの次数による要素のモジュラ指数rが1に等しい場合。これらの条件のいずれかが真でない場合、受け取った要素は無効です。それ以外の場合、受信した要素は有効です。
Commit payload validation is accomplished by the following steps:
コミットペイロードの検証は、次の手順で行われます。
1. The length of the Commit payload is checked against its anticipated length (the anticipated length of the scalar plus the anticipated length of the element, for the negotiated group). If it is incorrect, the Commit payload is invalidated; otherwise, processing continues.
1. Commitペイロードの長さは、予想される長さ（スカラーの予想される長さに、ネゴシエートされたグループの要素の予想される長さを加えたもの）に対してチェックされます。正しくない場合、Commitペイロードは無効になります。それ以外の場合、処理は続行されます。
2. The peer's scalar is extracted from the Commit payload according to Section 8.3.1 and checked to ensure it is between one (1) and r, the order of the negotiated group, exclusive. If it is not, the Commit payload is invalidated; otherwise, processing continues.
2. ピアのスカラーは、セクション8.3.1に従ってコミットペイロードから抽出され、ネゴシエートされたグループの順序である1とrの間であることを確認するためにチェックされます。そうでない場合、Commitペイロードは無効になります。それ以外の場合、処理は続行されます。
3. The peer's element is extracted from the Commit payload according to Section 8.3.2 and checked in a manner that depends on the type of group negotiated. If the group is ECP, the element is validated according to Section 8.4.2.1. If the group is MODP, the element is validated according to Section 8.4.2.2. If the element is not valid, then the Commit payload is invalidated; otherwise, the Commit payload is validated.
3. ピアの要素は、セクション8.3.2に従ってCommitペイロードから抽出され、ネゴシエートされたグループのタイプに応じた方法でチェックされます。グループがECPの場合、要素はセクション8.4.2.1に従って検証されます。グループがMODPの場合、要素はセクション8.4.2.2に従って検証されます。要素が有効でない場合、Commitペイロードは無効になります。それ以外の場合は、Commitペイロードが検証されます。
4. The Initiator of the IKE exchange has an added requirement to verify that the received element and scalar from the Commit payload differ from the element and scalar sent to the Responder. If they are identical, it signifies a reflection attack, and the Commit payload is invalidated.
4. IKE交換のイニシエーターには、Commitペイロードから受信した要素とスカラーが、レスポンダに送信された要素とスカラーと異なることを確認するための追加の要件があります。それらが同一の場合は、リフレクション攻撃を意味し、コミットペイロードは無効になります。
If the Commit payload is invalidated, the payload MUST be discarded and the IKE exchange aborted.
Commitペイロードが無効化されている場合、ペイロードは破棄されなければならず、IKE交換は中止されます。
After a Commit payload has been generated and a peer's Commit payload has been processed, a shared secret used to authenticate the peer is derived. Using SKE, the "private" value generated as part of Commit payload generation, and the peer's scalar and element from the peer's Commit payload, named here peer-scalar and Peer-Element, respectively, a preliminary shared secret, skey, is generated as:
Commitペイロードが生成され、ピアのCommitペイロードが処理された後、ピアの認証に使用される共有秘密が導出されます。 SKEを使用して、Commitペイロード生成の一部として生成された「プライベート」値と、ピアのCommitペイロードからのピアのスカラーと要素（それぞれここではpeer-scalarとPeer-Elementという名前）が、予備の共有シークレットskeyとして生成されます。 ：
skey = F(scalar-op(private,
element-op(Peer-Element,
scalar-op(peer-scalar, SKE))))
For the purposes of subsequent computation, the bit length of skey SHALL be equal to the bit length of the prime, p, used in either a MODP or ECP group. This bit length SHALL be enforced, if necessary, by prepending zeros to the value until the required length is achieved.
後続の計算のために、skeyのビット長は、MODPまたはECPグループで使用される素数pのビット長に等しい必要があります。このビット長は、必要に応じて、必要な長さに達するまで値の前にゼロを付加することにより、強制する必要があります。
A shared secret, ss, is then computed from skey and the nonces exchanged by the Initiator (Ni) and Responder (Nr) (without the fixed headers) using prf():
共有シークレットssは、skeyと、prf()を使用して（固定ヘッダーなしで）イニシエーター（Ni）およびレスポンダー（Nr）によって交換されたナンスから計算されます。
ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE")
ss = prf（Ni | Nr、skey | "IKEでのセキュアPSK認証"）
The shared secret, ss, is used in an AUTH authentication payload to prove possession of the shared secret and therefore knowledge of the pre-shared key.
共有シークレットssは、AUTH認証ペイロードで使用され、共有シークレットの所有、したがって事前共有キーの知識を証明します。
[RFC6467] defines a Generic Secure Password Method (GSPM) payload that is used to convey information that is specific to a particular secure password method. This memo uses the GSPM payload as a Commit payload to contain the scalar and element used in the Secure PSK Authentication exchange:
[RFC6467]は、特定のセキュアパスワードメソッドに固有の情報を伝達するために使用されるGeneric Secure Password Method（GSPM）ペイロードを定義しています。このメモでは、GSPMペイロードをCommitペイロードとして使用して、セキュアPSK認証交換で使用されるスカラーと要素を含めています。
The Commit payload is defined as follows:
Commitペイロードは次のように定義されます。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ scalar ~
| |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ Element ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The scalar and element SHALL be encoded in the Commit payload according to Section 8.3.
スカラーと要素は、セクション8.3に従ってCommitペイロードにエンコードする必要があります（SHALL）。
Secure PSK Authentication modifies the IKE_AUTH exchange by adding one additional round trip to exchange Commit payloads to perform the Secure PSK Authentication exchange and by changing the calculation of the AUTH payload data to bind the IKEv2 exchange to the outcome of the Secure PSK Authentication exchange (see Figure 3).
セキュアPSK認証は、コミットペイロードを交換してセキュアPSK認証交換を実行するためにラウンドトリップを1つ追加し、AUTHペイロードデータの計算を変更して、IKEv2交換をセキュアPSK認証交換の結果にバインドすることにより、IKE_AUTH交換を変更します（図3）。
Initiator Responder
----------- -----------
IKE_SA_INIT:
IKE_SA_INIT：
HDR, SAi1, KEi, Ni, N(SPM-SPSK) -->
ＨＤＲ、 さい１、 けい、 に、 ん（ＳＰＭーＳＰＳＫ） ーー＞
<-- HDR, SAr1, KEr, Nr, N(SPM-SPSK)
<-HDR、SAr1、KEr、Nr、N（SPM-SPSK）
IKE_AUTH:
いけ＿あうＴＨ：
HDR, SK {IDi, COMi, [IDr,]
SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, COMr}
HDR, SK {AUTHi} -->
<-- HDR, SK {AUTHr, SAr2, TSi, TSr}
where N(SPM-SPSK) indicates the Secure Password Methods Notify payloads used to negotiate the use of Secure PSK Authentication (see Section 8.1), COMi and AUTHi are the Commit payload and AUTH payload, respectively, sent by the Initiator, and COMr and AUTHr are the Commit payload and AUTH payload, respectively, sent by the Responder.
ここで、N（SPM-SPSK）は、セキュアPSK認証の使用のネゴシエーションに使用されるセキュアパスワードメソッド通知ペイロード（セクション8.1を参照）を示します。COMiとAUTHiは、それぞれイニシエーターによって送信されたコミットペイロードとAUTHペイロードで、COMrとAUTHrは、それぞれレスポンダによって送信されるコミットペイロードとAUTHペイロードです。
Figure 3: Secure PSK in IKEv2
図3：IKEv2のセキュアPSK
When doing Secure PSK Authentication, the AUTH payloads SHALL be computed as
セキュアなPSK認証を行う場合、AUTHペイロードは次のように計算する必要があります。
AUTHi = prf(ss, <InitiatorSignedOctets> | COMi | COMr)
AUTHr = prf(ss, <ResponderSignedOctets> | COMr | COMi)
where "ss" is the shared secret derived in Section 8.4.3, COMi and COMr are the entire Commit payloads (including the fixed headers) sent by the Initiator and Responder, respectively, and <InitiatorSignedOctets> and <ResponderSignedOctets> are defined in
ここで、「ss」はセクション8.4.3で派生した共有シークレットで、COMiとCOMrは、それぞれイニシエーターとレスポンダーによって送信されたコミットペイロード全体（固定ヘッダーを含む）であり、<InitiatorSignedOctets>と<ResponderSignedOctets>は、
[RFC5996]. The Authentication Method indicated in both AUTH payloads SHALL be "Generic Secure Password Authentication Method", value 12, from [IKEV2-IANA].
[RFC5996]。両方のAUTHペイロードで示されている認証方法は、[IKEV2-IANA]の「Generic Secure Password Authentication Method」、値12である必要があります。
IANA has assigned the value 3 for "Secure PSK Authentication" from the Secure Password Authentication Method registry in [IKEV2-IANA].
IANAは、[IKEV2-IANA]のSecure Password Authentication Methodレジストリから「Secure PSK Authentication」の値3を割り当てました。
Both the Initiator and Responder obtain a shared secret, "ss" (see Section 8.4.3), based on a secret group element and their own private values contributed to the exchange. If they do not share the same pre-shared key, they will be unable to derive the same secret group element, and if they do not share the same secret group element, they will be unable to derive the same shared secret.
イニシエータとレスポンダの両方が、シークレットグループ要素と交換に貢献した独自のプライベート値に基づいて、共有シークレット「ss」（セクション8.4.3を参照）を取得します。同じ事前共有キーを共有しない場合、同じシークレットグループ要素を導出できません。同じシークレットグループ要素を共有しない場合、同じ共有シークレットを導出できません。
Resistance to dictionary attack means that the adversary must launch an active attack to make a single guess at the pre-shared key. If the size of the pool from which the key was extracted was d and each key in the pool has an equal probability of being chosen, then the probability of success after a single guess is 1/d. After x guesses, and removal of failed guesses from the pool of possible keys, the probability becomes 1/(d-x). As x grows, so does the probability of success. Therefore, it is possible for an adversary to determine the pre-shared key through repeated brute-force, active, guessing attacks. This authentication method does not presume to be secure against this, and implementations SHOULD ensure the value of d is sufficiently large to prevent this attack. Implementations SHOULD also take countermeasures, for instance, refusing authentication attempts for a certain amount of time after the number of failed authentication attempts reaches a certain threshold. No such threshold or amount of time is recommended in this memo.
辞書攻撃への抵抗とは、攻撃者が事前共有キーを1回推測するためにアクティブな攻撃を開始する必要があることを意味します。キーの抽出元のプールのサイズがdであり、プール内の各キーが選択される確率が等しい場合、1回の推測の後の成功の確率は1 / dです。 x回の推測、および失敗した推測を可能なキーのプールから削除すると、確率は1 /（d-x）になります。 xが大きくなると、成功の確率も大きくなります。したがって、攻撃者は、ブルートフォースのアクティブな推測攻撃を繰り返し行うことで事前共有キーを決定することができます。この認証方法はこれに対して安全であるとは想定しておらず、実装では、この攻撃を防ぐためにdの値が十分に大きいことを保証する必要があります。実装では、たとえば、失敗した認証の試行回数が特定のしきい値に達した後、特定の時間、認証の試行を拒否するなどの対策を講じる必要があります（SHOULD）。このメモでは、そのようなしきい値や時間量は推奨されていません。
An active attacker can impersonate the Responder of the exchange and send a forged Commit payload after receiving the Initiator's Commit payload. The attacker then waits until it receives the authentication payload from the Responder. Now the attacker can attempt to run through all possible values of the pre-shared key, computing SKE (see Section 8.2), computing "ss" (see Section 8.4.3), and attempting to recreate the Confirm payload from the Responder.
アクティブな攻撃者は、交換のレスポンダーになりすまして、イニシエーターのコミットペイロードを受信した後で、偽造されたコミットペイロードを送信できます。攻撃者は、レスポンダーから認証ペイロードを受信するまで待機します。攻撃者は、事前共有キーのすべての可能な値を実行し、SKEを計算し（セクション8.2を参照）、「ss」を計算し（セクション8.4.3を参照）、レスポンダーから確認ペイロードを再作成することができます。
But, by sending a forged Commit payload the attacker commits to a single guess of the pre-shared key. That value was used by the Responder in his computation of "ss", which was used in the authentication payload. Any guess of the pre-shared key that differs from the one used in the forged Commit payload would result in each side using a different secret element in the computation of "ss" and therefore the authentication payload could not be verified as correct, even if a subsequent guess, while running through all possible values, was correct. The attacker gets one guess, and one guess only, per active attack.
しかし、偽造されたコミットペイロードを送信することにより、攻撃者は事前共有キーの単一の推測にコミットします。その値は、認証ペイロードで使用された「ss」の計算でレスポンダによって使用されました。偽造されたコミットペイロードで使用されているものとは異なる事前共有キーの推測は、「ss」の計算で異なる秘密要素を使用することになるため、認証ペイロードを正しく検証できませんでした。可能なすべての値を実行している間の後続の推測は正しかった。攻撃者は、アクティブな攻撃ごとに1つの推測と1つの推測のみを取得します。
An attacker, acting as either the Initiator or Responder, can take the element from the Commit payload received from the other party, reconstruct the random "mask" value used in its construction, and then recover the other party's "private" value from the scalar in the Commit payload. But this requires the attacker to solve the discrete logarithm problem, which we assumed was intractable (Section 7).
イニシエーターまたはレスポンダーのいずれかとして機能する攻撃者は、相手から受信したコミットペイロードから要素を取得し、その構築で使用されたランダムな「マスク」値を再構築してから、スカラーから相手の「プライベート」値を復元できます。コミットペイロード内。しかし、これには攻撃者が離散対数問題を解く必要があります。
Instead of attempting to guess at pre-shared keys, an attacker can attempt to determine SKE and then launch an attack, but SKE is determined by the output of the pseudo-random function, prf, which is assumed to be indistinguishable from a random source (Section 7). Therefore, each element of the finite cyclic group will have an equal probability of being the SKE. The probability of guessing SKE will be 1/r, where r is the order of the group. This is the same probability of guessing the solution to the discrete logarithm, which is assumed to be intractable (Section 7). The attacker would have a better chance of success at guessing the input to prf, i.e., the pre-shared key, since the order of the group will be many orders of magnitude greater than the size of the pool of pre-shared keys.
事前共有キーを推測する代わりに、攻撃者はSKEを決定して攻撃を開始することができますが、SKEは疑似ランダム関数prfの出力によって決定されます。これは、ランダムソースと区別できないと想定されています（セクション7）。したがって、有限循環グループの各要素は、SKEになる確率が等しくなります。 SKEを推測する確率は1 / rです。ここで、rはグループの次数です。これは、難解であると想定される離散対数の解を推測する確率と同じです（セクション7）。グループの順序は事前共有キーのプールのサイズよりも何桁も大きいため、攻撃者はprfへの入力、つまり事前共有キーの推測に成功する可能性が高くなります。
The implications of resistance to dictionary attack are significant. An implementation can provision a pre-shared key in a practical and realistic manner -- i.e., it MAY be a character string, and it MAY be relatively short -- and still maintain security. The nature of the pre-shared key determines the size of the pool, D, and countermeasures can prevent an adversary from determining the secret in the only possible way: repeated, active, guessing attacks. For example, a simple four-character string using lowercase English characters, and assuming random selection of those characters, will result in D of over four hundred thousand. An adversary would need to mount over one hundred thousand active, guessing attacks (which will easily be detected) before gaining any significant advantage in determining the pre-shared key.
辞書攻撃に対する耐性の影響は重要です。実装では、事前共有鍵を実用的かつ現実的な方法でプロビジョニングできます。つまり、文字列であり、比較的短い可能性があり、セキュリティを維持できます。事前共有キーの性質によってプールのサイズDが決まり、対策によって、攻撃者が唯一の可能な方法でシークレットを決定できなくなる可能性があります。それは、繰り返されるアクティブな推測攻撃です。たとえば、小文字の英語の文字を使用し、それらの文字をランダムに選択すると仮定した単純な4文字の文字列は、40万を超えるDになります。攻撃者は、事前共有キーを決定する上で重要な利点を得る前に、10万を超えるアクティブな推測攻撃（簡単に検出される）をマウントする必要があります。
If an attacker knows the number of hunting-and-pecking loops that were required to determine SKE, it is possible to eliminate passwords from the pool of potential passwords and increase the probability of successfully guessing the real password. MODP groups will require more than "n" loops with a probability based on the value of the prime -- if m is the largest unsigned number that can be expressed in len(p) bits, then the probability is ((m-p)/p)^n -- which will typically be very small for the groups defined in [IKEV2-IANA]. ECP
攻撃者がSKEを決定するために必要なハンティングアンドペッキングループの数を知っている場合、潜在的なパスワードのプールからパスワードを排除し、実際のパスワードをうまく推測できる確率を高めることができます。 MODPグループは、素数の値に基づいた確率で「n」を超えるループを必要とします。mがlen（p）ビットで表現できる最大の符号なしの数である場合、確率は（（mp）/ pです。 ）^ n-[IKEV2-IANA]で定義されているグループの場合、通常は非常に小さくなります。 ECP
groups will require more than one "n" loop with a probability of roughly (1-(r/2p))^n. Therefore, a security parameter, k, is defined that will ensure that at least k loops will always be executed regardless of whether SKE is found in less than k loops. There is still a probability that a password would require more than k loops, and a side-channel attacker could use that information to his advantage, so selection of the value of k should be based on a trade-off between the additional workload to always perform k iterations and the potential of providing information to a side-channel attacker. It is important to note that the possibility of a successful side-channel attack is greater against ECP groups than MODP groups, and it might be appropriate to have separate values of k for the two.
グループには、およそ（1-（r / 2p））^ nの確率で複数の「n」ループが必要です。したがって、SKEがk未満のループで検出されるかどうかに関係なく、少なくともkループが常に実行されることを保証するセキュリティパラメーターkが定義されています。パスワードにはk以上のループが必要になる可能性があり、サイドチャネル攻撃者はその情報を有利に利用できるため、kの値の選択は、常に追加のワークロードとのトレードオフに基づいて行う必要があります。 k回の反復を実行し、サイドチャネル攻撃者に情報を提供する可能性があります。サイドチャネル攻撃が成功する可能性はMODPグループよりもECPグループに対して大きく、2つのkに別々の値を設定することが適切であることに注意することが重要です。
For a more detailed discussion of the security of the key exchange underlying this authentication method, see [SAE] and [RFC5931].
この認証方法の基礎となる鍵交換のセキュリティの詳細については、[SAE]および[RFC5931]を参照してください。
The author would like to thank Scott Fluhrer and Hideyuki Suzuki for their insight in discovering flaws in earlier versions of the key exchange that underlies this authentication method and for their helpful suggestions in improving it. Thanks to Lily Chen for useful advice on the hunting-and-pecking technique to "hash into" an element in a group and to Jin-Meng Ho for a discussion on countering a small sub-group attack. Rich Davis suggested several checks on received messages that greatly increase the security of the underlying key exchange. Hugo Krawczyk suggested using the prf as an extractor.
著者は、Scott FluhrerとSuzuki Hideyukiが、この認証方法の基礎となっている以前のバージョンの鍵交換の欠陥を発見する洞察と、その認証方法を改善するための有益な提案に感謝します。グループ内の要素を「ハッシュ化」するための狩猟と狩りの手法に関する有益なアドバイスを提供してくれたLily Chenと、小さなサブグループ攻撃への対抗についての議論を行ったJin-Meng Hoに感謝します。 Rich Davisは、基になる鍵交換のセキュリティを大幅に向上させる受信メッセージのいくつかのチェックを提案しました。 Hugo Krawczykさんは、prfを抽出プログラムとして使用することを提案しました。
[IKEV2-IANA] IANA, "IKEv2 Parameters", <http://www.iana.org/assignments/ikev2-parameters>.
[IKEV2-IANA] IANA、「IKEv2パラメータ」、<http://www.iana.org/assignments/ikev2-parameters>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[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月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P.およびM. Blanchet、「Preparation of Internationalized Strings（ "stringprep"）」、RFC 3454、2002年12月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K。、「SASLprep：Stringprep Profile for User Names and Passwords」、RFC 4013、2005年2月。
[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月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、2011年2月。
[RFC6467] Kivinen, T., "Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)", RFC 6467, December 2011.
[RFC6467] Kivinen、T。、「インターネットキーエクスチェンジバージョン2（IKEv2）のセキュアパスワードフレームワーク」、RFC 6467、2011年12月。
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks", Proceedings of the IEEE Symposium on Security and Privacy, Oakland, 1992.
[BM92] Bellovin、S。およびM. Merritt、「暗号化鍵交換：辞書攻撃に対して安全なパスワードベースのプロトコル」、セキュリティとプライバシーに関するIEEEシンポジウムの議事録、オークランド、1992年。
[BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure Password-Authenticated Key Exchange Using Diffie-Hellman", Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 2000.
[BMP00] Boyko、V.、MacKenzie、P。、およびS. Patel、「Diffie-Hellmanを使用した、おそらく安全なパスワード認証の鍵交換」、Eurocrypt 2000のプロシーディングス、LNCS 1807 Springer-Verlag、2000。
[BPR00] Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated Key Exchange Secure Against Dictionary Attacks", Advances in Cryptology -- Eurocrypt '00, Lecture Notes in Computer Science Springer-Verlag, 2000.
[BPR00] Bellare、M.、Pointcheval、D。、およびP. Rogaway、「辞書攻撃から保護された認証済みの鍵交換」、暗号学の進歩-Eurocrypt '00、コンピュータサイエンスの講義ノートSpringer-Verlag、2000年。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010.
[RFC5869] Krawczyk、H。およびP. Eronen、「HMACベースの抽出および拡張キー導出関数（HKDF）」、RFC 5869、2010年5月。
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, August 2010.
[RFC5931] Harkins、D。およびG. Zorn、「パスワードのみを使用した拡張認証プロトコル（EAP）認証」、RFC 5931、2010年8月。
[SAE] Harkins, D., "Simultaneous Authentication of Equals: A Secure, Password-Based Key Exchange for Mesh Networks", Proceedings of the 2008 Second International Conference on Sensor Technologies and Applications Volume 00, 2008.
[SAE] Harkins、D。、「Equalsの同時認証：メッシュネットワーク用の安全なパスワードベースの鍵交換」、センサー技術とアプリケーションに関する2008年第2回国際会議の議事録、00、2008年。
Author's Address
著者のアドレス
Dan Harkins Aruba Networks 1322 Crossman Avenue Sunnyvale, CA 94089-1113 United States of America
Dan Harkins Aruba Networks 1322 Crossman Avenue Sunnyvale、CA 94089-1113アメリカ合衆国
EMail: dharkins@arubanetworks.com