[要約] RFC 6631は、IKEv2を使用したパスワード認証付きの接続確立に関する仕様です。その目的は、IKEv2プロトコルを使用してセキュアな接続を確立する際に、パスワード認証をサポートすることです。
Internet Engineering Task Force (IETF) D. Kuegler
Request for Comments: 6631 BSI
Category: Experimental Y. Sheffer
ISSN: 2070-1721 Porticor
June 2012
Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)
Internet Key Exchange Protocolバージョン2（IKEv2）によるパスワード認証接続の確立
Abstract
概要
The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password-authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration.
Internet Key Exchangeプロトコルバージョン2（IKEv2）では、短い認証情報文字列、つまりパスワードを使用する場合、安全なピア認証は許可されません。パスワード認証プロトコルをIKEに統合するためのいくつかの提案が行われています。このドキュメントでは、IKEv2の設定に対するパスワード認証接続確立（PACE）の適応について説明し、この統合の利点を示します。
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コミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（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/rfc6631.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6631で入手できます。
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. Terminology ................................................4
2. Overview ........................................................5
3. Protocol Sequence ...............................................6
3.1. The IKE_SA_INIT Exchange ...................................6
3.2. The IKE_AUTH Exchange, Round #1 ............................7
3.3. The IKE_AUTH Exchange, Round #2 ............................7
3.4. Public Key Validation ......................................8
3.5. Creating a Long-Term Shared Secret .........................9
3.6. Using the Long-Term Shared Secret .........................11
4. Encrypting and Mapping the Nonce ...............................11
4.1. Encrypting the Nonce ......................................11
4.2. Mapping the Nonce .........................................12
4.2.1. Modular Diffie-Hellman .............................13
4.2.2. Elliptic Curve Diffie-Hellman ......................13
5. Protocol Details ...............................................13
5.1. Password Processing .......................................13
5.2. The SECURE_PASSWORD_METHODS Notification ..................14
5.3. The PSK_PERSIST Notification ..............................15
5.4. The PSK_CONFIRM Notification ..............................15
5.5. The GSPM(ENONCE) Payload ..................................15
5.6. The KE (KEi2/KEr2) Payloads in PACE .......................16
5.7. PACE and Session Resumption ...............................16
6. Security Considerations ........................................16
6.1. Credential Security Assumptions ...........................16
6.2. Vulnerability to Passive and Active Attacks ...............16
6.3. Perfect Forward Secrecy ...................................17
6.4. Randomness ................................................17
6.5. Identity Protection .......................................17
6.6. Denial of Service .........................................17
6.7. Choice of Encryption Algorithms ...........................17
6.8. Security Model and Security Proof .........................18
6.9. Long-Term Credential Storage ..............................18
7. IANA Considerations ............................................19
8. Acknowledgments ................................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Appendix A. Protocol Selection Criteria ...........................22
A.1. Security Criteria ..........................................22
A.2. Intellectual Property Criteria .............................22
A.3. Miscellaneous Criteria .....................................22
Appendix B. Password Salting ......................................23
B.1. Solving the Asymmetric Case with Symmetric Cryptography ....24
B.2. Solving the Fully Symmetric Case with Asymmetric
Cryptography ...............................................25
B.3. Generation of a Strong, Long-Term, Shared Secret ...........26
PACE [TR03110] is a security protocol that establishes a mutually authenticated (and encrypted) channel between two parties based on weak (short) passwords. PACE provides strong session keys that are independent of the strength of the password. PACE belongs to a family of protocols often referred to as Zero-Knowledge Password Proof (ZKPP) protocols, all of which amplify weak passwords into strong session keys. This document describes the integration of PACE into IKEv2 [RFC5996] as a new authentication mode, analogous to the existing certificate and Pre-Shared Key (PSK) authentication modes.
PACE [TR03110]は、弱い（短い）パスワードに基づいて2つのパーティ間で相互認証（および暗号化）チャネルを確立するセキュリティプロトコルです。 PACEは、パスワードの強度に依存しない強力なセッションキーを提供します。 PACEは、Zero-Knowledge Password Proof（ZKPP）プロトコルと呼ばれることが多いプロトコルファミリーに属しています。これらのプロトコルはすべて、弱いパスワードを強力なセッションキーに増幅します。このドキュメントでは、PACEをIKEv2 [RFC5996]に新しい認証モードとして統合する方法について説明します。これは、既存の証明書および事前共有キー（PSK）認証モードに類似しています。
Some of the advantages of our approach, compared to the existing IKEv2, include the following:
既存のIKEv2と比較して、このアプローチの利点には次のようなものがあります。
o The current best practice to implement password authentication in IKE involves certificate-based authentication of the server plus some Extensible Authentication Protocol (EAP) method to authenticate the client. This involves two non-trivial infrastructure components (PKI and EAP/AAA). Moreover, certificate authentication is hard to get right and often depends on unreliable user behavior for its security.
o IKEにパスワード認証を実装するための現在のベストプラクティスには、サーバーの証明書ベースの認証と、クライアントを認証するためのいくつかの拡張認証プロトコル（EAP）メソッドが含まれます。これには、2つの重要なインフラストラクチャコンポーネント（PKIおよびEAP / AAA）が含まれます。さらに、証明書認証は正しく行うのが難しく、そのセキュリティは信頼できないユーザーの動作に依存することがよくあります。
o Alternatively, native IKEv2 shared secret authentication can be used with passwords. However, this usage is insecure; specifically, it is vulnerable to active attackers.
o または、ネイティブIKEv2共有秘密認証をパスワードとともに使用できます。ただし、この使用法は安全ではありません。具体的には、アクティブな攻撃者に対して脆弱です。
o Some newer EAP methods can be used for mutual authentication and, combined with [RFC5998], can be well integrated into IKEv2. This is certainly an option in some cases, but the current proposal may be simpler to implement.
o いくつかの新しいEAP方式は相互認証に使用でき、[RFC5998]と組み合わせると、IKEv2にうまく統合できます。これは確かに場合によってはオプションですが、現在の提案は実装が簡単な場合があります。
Compared to other protocols aiming at similar goals, PACE has several advantages. PACE was designed to allow for a high level of flexibility with respect to cryptographic algorithms; e.g., it can be implemented based on Modular Diffie-Hellman as well as Elliptic Curve Diffie-Hellman without any restrictions on the mathematical group to be used, other than the requirement that the group be cryptographically secure. The protocol itself is also proven to be cryptographically secure [PACEsec]. The PACE protocol is currently used in an international standard for digital travel documents [ICAO].
同様の目標を目指す他のプロトコルと比較して、PACEにはいくつかの利点があります。 PACEは、暗号化アルゴリズムに関して高度な柔軟性を可能にするように設計されています。例えば、それは、モジュラーDiffie-Hellmanと楕円曲線Diffie-Hellmanに基づいて、グループが暗号的に安全であるという要件以外に、使用する数学グループに制限なしに実装できます。プロトコル自体も暗号的に安全であることが証明されています[PACEsec]。 PACEプロトコルは現在、デジタル旅行文書の国際標準で使用されています[ICAO]。
The integration aims at keeping IKEv2 unchanged as much as possible; e.g., the mechanisms used to establish Child security associations (SAs) as provided by IKEv2 would be maintained with no change.
この統合は、IKEv2をできるだけ変更しないことを目的としています。たとえば、IKEv2によって提供される子セキュリティアソシエーション（SA）を確立するために使用されるメカニズムは、変更されることなく維持されます。
The Password-Authenticated Key Exchange (PAKE) framework document [RFC6467] defines a set of payloads for different types of PAKE methods within IKEv2. This document reuses this framework. Note that the current document is self-contained; i.e., all relevant payloads and semantics are redefined here.
パスワード認証鍵交換（PAKE）フレームワークドキュメント[RFC6467]は、IKEv2内のさまざまなタイプのPAKEメソッドのペイロードのセットを定義しています。このドキュメントでは、このフレームワークを再利用しています。現在のドキュメントは自己完結型であることに注意してください。つまり、関連するすべてのペイロードとセマンティクスがここで再定義されます。
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]で説明されているように解釈されます。
The following notation is used in this document:
このドキュメントでは、次の表記法を使用しています。
E() Symmetric encryption D() Symmetric decryption KA() Key agreement Map() Mapping function Pwd Shared password SPwd Stored password KPwd Symmetric key derived from a password Pwd G Static group generator GE Ephemeral group generator ENONCE Encrypted nonce PKEi Ephemeral public key of the initiator SKEi Ephemeral secret key of the initiator PKEr Ephemeral public key of the responder SKEr Ephemeral secret key of the responder AUTH Authentication payload
E()対称暗号化D()対称復号KA()鍵合意Map()マッピング関数Pwd共有パスワードSPwd保存されたパスワードKPwdパスワードから派生した対称鍵Pwd G静的グループジェネレーターGEエフェメラルグループジェネレーターENONCE暗号化されたナンスPKEiエフェメラル公開鍵イニシエータのイニシエータSKEi Ephemeral秘密鍵レスポンダのPKEr Ephemeral公開鍵レスポンダのSKEr Ephemeral秘密鍵AUTH認証ペイロード
Any other notation used here is defined in [RFC5996].
ここで使用されているその他の表記法は、[RFC5996]で定義されています。
At a high level, the following steps are performed by the initiator and the responder. They result in a two-round IKE_AUTH exchange, described in Section 3 below.
高レベルでは、次の手順はイニシエーターとレスポンダーによって実行されます。その結果、以下のセクション3で説明する2ラウンドのIKE_AUTH交換が行われます。
1. The initiator randomly and uniformly chooses a nonce s, encrypts the nonce using the password, and sends the ciphertext
1. イニシエーターは、ランダムかつ均一にナンスを選択し、パスワードを使用してナンスを暗号化し、暗号文を送信します
ENONCE = E(KPwd, s)
ENONCE = E（KPwd、s）
to the responder. The responder recovers the plaintext nonce s with the help of the shared password Pwd.
レスポンダーに。レスポンダは、共有パスワードPwdの助けを借りて、平文のナンスを回復します。
2. The nonce s is mapped to an ephemeral generator
2. nonceは一時的なジェネレータにマッピングされます
GE = G^s * SASharedSecret,
To = G ^ s * sacreddecret、
where G is the generator of the selected Modular Exponential (MODP) group and SASharedSecret is a shared secret that has been generated in the IKE_SA_INIT step.
ここで、Gは選択されたModular Exponential（MODP）グループのジェネレーターであり、SASharedSecretはIKE_SA_INITステップで生成された共有秘密です。
3. Both the initiator and the responder each calculate an ephemeral key pair
3. イニシエーターとレスポンダーの両方がそれぞれ一時キーペアを計算します
(SKEi, PKEi = GE^SKEi) and (SKEr, PKEr=GE^SKEr),
（SKEi、PKEi = GE ^ SKEi）および（SKEr、PKEr = GE ^ SKEr）、
respectively, based on the ephemeral generator GE, and exchange the public keys.
それぞれ、短命ジェネレータGEに基づいて、公開鍵を交換します。
4. Finally, they compute the shared secret
4. 最後に、彼らは共有秘密を計算します
PACESharedSecret = PKEi^SKEr = PKEr^SKEi
and generate, exchange, and verify the IKE authentication token AUTH using the shared secret PACESharedSecret.
共有シークレットPACESharedSecretを使用して、IKE認証トークンAUTHを生成、交換、および検証します。
The encryption function E() must be carefully chosen to prevent dictionary attacks that would otherwise allow an attacker to recover the password. Those restrictions are described in Section 4.1. Details on the mapping function, including the elliptic curve variant, can be found in Section 4.2.
暗号化関数E()は、攻撃者がパスワードを回復できるようにする辞書攻撃を防ぐために慎重に選択する必要があります。これらの制限については、セクション4.1で説明します。楕円曲線バリアントを含むマッピング関数の詳細については、セクション4.2を参照してください。
To avoid the risks inherent in storing a short password (e.g., the fact that passwords are often reused for different applications), this protocol allows the peers to jointly convert the password into a cryptographically stronger shared secret. This shared secret can then be stored by both peers, in lieu of the original password or its salted variants.
短いパスワードの保存に固有のリスク（たとえば、パスワードがさまざまなアプリケーションで再利用されることが多いという事実）を回避するために、このプロトコルでは、ピアが共同でパスワードを暗号化により強力な共有シークレットに変換できます。この共有シークレットは、元のパスワードまたはそのソルトバリアントの代わりに、両方のピアで保存できます。
The protocol consists of three round trips -- an IKE_SA_INIT exchange and a 2-round IKE_AUTH exchange -- as shown in the next figure. An optional Informational exchange may follow (see Section 3.5).
次の図に示すように、プロトコルは3つのラウンドトリップ（IKE_SA_INIT交換と2ラウンドのIKE_AUTH交換）で構成されています。オプションの情報交換が続く場合があります（セクション3.5を参照）。
Initiator Responder
--------- ---------
IKE_SA_INIT:
IKE_SA_INIT：
HDR, SAi1, KEi, Ni, N(SECURE_PASSWORD_METHODS) ->
<- HDR, SAr1, KEr, Nr, N(SECURE_PASSWORD_METHODS)
<-HDR、SAr1、KEr、Nr、N（SECURE_PASSWORD_METHODS）
IKE_AUTH round #1:
IKE_AUTHラウンド＃1：
HDR, SK{IDi, [IDr,], SAi2,
TSi, TSr, GSPM(ENONCE), KEi2} ->
<- HDR, SK{IDr, KEr2}
IKE_AUTH round #2:
IKE_AUTHラウンド＃2：
HDR, SK{AUTH [, N(PSK_PERSIST)] } ->
<- HDR, SK{AUTH, SAr2, TSi, TSr [, N(PSK_PERSIST)] }
Figure 1: IKE SA Setup with PACE
図1：PACEを使用したIKE SAのセットアップ
The initiator sends a SECURE_PASSWORD_METHODS notification that indicates its support of this extension and its wish to authenticate using a password. The following text assumes that the responder sent back a SECURE_PASSWORD_METHODS notification that indicates its preference for PACE.
イニシエーターは、この拡張機能のサポートとパスワードを使用して認証したいことを示すSECURE_PASSWORD_METHODS通知を送信します。次のテキストは、レスポンダがPACEの設定を示すSECURE_PASSWORD_METHODS通知を返信したことを前提としています。
If PACE was chosen, the algorithms negotiated in SAi1 and SAr1 are also used for the execution of PACE, i.e., the key agreement protocol (Modular Diffie-Hellman or Elliptic Curve Diffie-Hellman), the group to be used, and the encryption algorithm.
PACEが選択された場合、SAi1およびSAr1でネゴシエートされたアルゴリズム、つまり、鍵合意プロトコル（Modular Diffie-HellmanまたはElliptic Curve Diffie-Hellman）、使用されるグループ、および暗号化アルゴリズムもPACEの実行に使用されます。 。
This is the first part of the PACE authentication of the peers. This exchange MUST NOT be used unless both peers indicated support of this protocol.
これは、ピアのPACE認証の最初の部分です。この交換は、両方のピアがこのプロトコルのサポートを示さない限り、使用してはなりません（MUST NOT）。
The initiator selects a random nonce s and encrypts it to form ENONCE using the password Pwd, as described in Section 4.1. Then, the initiator maps the nonce to an ephemeral generator GE of the group as described in Section 4.2, chooses randomly and uniformly an ephemeral key pair (SKEi,PKEi) based on the ephemeral generator, and finally generates the payloads GSPM(ENONCE) containing the encrypted nonce and KEi2 containing the ephemeral public key.
セクション4.1で説明されているように、イニシエーターはランダムなナンスを選択し、暗号化してパスワードPwdを使用してENONCEを形成します。次に、イニシエーターは、セクション4.2で説明されているように、ノンスをグループのエフェメラルジェネレーターGEにマップし、エフェメラルジェネレーターに基づいてエフェメラルキーペア（SKEi、PKEi）をランダムかつ均一に選択し、最終的に、暗号化されたナンスと一時的な公開鍵を含むKEi2
The responder decrypts the received encrypted nonce s = D(KPwd, ENONCE), performs the mapping, and randomly and uniformly chooses an ephemeral key pair (SKEr,PKEr) based on the ephemeral generator GE. The responder generates the KEr2 payload containing the ephemeral public key.
レスポンダは、受信した暗号化されたナンスs = D（KPwd、ENONCE）を復号化し、マッピングを実行し、エフェメラルジェネレータGEに基づいてエフェメラルキーペア（SKEr、PKEr）をランダムかつ均一に選択します。レスポンダは、一時的な公開鍵を含むKEr2ペイロードを生成します。
The request is equivalent to the IKE_AUTH request in a normal IKEv2 exchange; i.e., any payload that is valid in an IKE_AUTH request is valid (with the same semantics) in this round's request. In particular, certificate-related payloads are allowed, even though their use may not be practical within this mode.
この要求は、通常のIKEv2交換におけるIKE_AUTH要求と同等です。つまり、IKE_AUTHリクエストで有効なペイロードは、このラウンドのリクエストでも（同じセマンティクスで）有効です。特に、証明書関連のペイロードは、このモードでは実際に使用できない場合でも許可されます。
This is the second part of the PACE authentication of the peers.
これは、ピアのPACE認証の2番目の部分です。
The initiator and the responder calculate the shared secret PACESharedSecret
イニシエーターとレスポンダーは共有秘密PACESharedSecretを計算します
PACESharedSecret = KA(SKEi, PKEr, GE) = KA(SKEr, PKEi, GE),
PACESharedSecret = KA（SKEi、PKEr、GE）= KA（SKEr、PKEi、GE）、
where KA denotes the Diffie-Hellman key agreement, e.g., (for MODP groups), modular exponentiation. Then, they calculate the authentication tokens AUTHi and AUTHr.
ここで、KAはDiffie-Hellman鍵合意、たとえば（MODPグループの場合）、モジュラ指数を示します。次に、認証トークンAUTHiおよびAUTHrを計算します。
The initiator calculates
イニシエーターは計算します
AUTHi = prf(prf+(Ni | Nr, PACESharedSecret),
<InitiatorSignedOctets> | PKEr)
See Section 2.15 of [RFC5996] for the definition of signed octets.
署名付きオクテットの定義については、[RFC5996]のセクション2.15を参照してください。
The responder calculates
レスポンダは計算します
AUTHr = prf(prf+(Ni | Nr, PACESharedSecret),
<ResponderSignedOctets> | PKEi)
Both AUTH payloads MUST indicate as their authentication method the Generic Secure Password Authentication Method [RFC6467], whose value is 12. The authentication tokens are exchanged, and each of them MUST be verified by the other party. The behavior when this verification fails is unchanged from [RFC5996].
両方のAUTHペイロードは、その認証方法として、値が12のGeneric Secure Password Authentication Method [RFC6467]を示さなければなりません（MUST）。認証トークンは交換され、それらのそれぞれは相手によって検証されなければなりません。この検証が失敗したときの動作は[RFC5996]から変更されていません。
Each of the peers MAY generate a long-term credential at this point, after it has verified the opposite peer's identity. The shared secret is
各ピアは、反対のピアのIDを確認した後、この時点で長期間の資格情報を生成できます（MAY）。共有秘密は
LongTermSecret = prf(Ni | Nr, "PACE Generated PSK" | PACESharedSecret),
LongTermSecret = prf（Ni | Nr、 "PACE Generated PSK" | PACESharedSecret）、
where the literal string is ASCII-encoded, with no zero terminator. The generated secret MUST be persisted to stable memory before sending the response. See Section 3.5 for more details about this facility.
ここで、リテラル文字列はゼロターミネータなしのASCIIエンコードです。生成されたシークレットは、応答を送信する前に安定したメモリに永続化する必要があります。この機能の詳細については、セクション3.5を参照してください。
This round's response is equivalent to the IKE_AUTH response in a normal IKEv2 exchange; i.e., any payload that is valid in an IKE_AUTH response is valid (with the same semantics) in the second round's response.
このラウンドの応答は、通常のIKEv2交換でのIKE_AUTH応答に相当します。つまり、IKE_AUTH応答で有効なペイロードは、2番目のラウンドの応答でも（同じセマンティクスで）有効です。
Following authentication, all temporary values MUST be deleted by the peers, including in particular s, the ephemeral generator, the ephemeral key pairs, and PACESharedSecret.
認証に続いて、すべての一時的な値は、特にs、エフェメラルジェネレーター、エフェメラルキーペア、およびPACESharedSecretを含むピアによって削除される必要があります。
The security of the protocol relies on the entanglement of a weak password with cryptographically strong shared secrets, SASharedSecret and PACESharedSecret, mutually and randomly generated by the initiator and the responder. If an attacker can influence the randomness of those shared secrets, the confidentiality of the password may be directly affected.
プロトコルのセキュリティは、弱いパスワードと暗号化された強力な共有シークレットSASharedSecretおよびPACESharedSecretの絡み合いに依存しており、SASharedSecretおよびPACESharedSecretは、イニシエーターとレスポンダーによって相互にランダムに生成されます。攻撃者がこれらの共有シークレットのランダム性に影響を与えることができる場合、パスワードの機密性が直接影響を受ける可能性があります。
Implementations MUST therefore verify that the shared secrets SASharedSecret and PACESharedSecret are random elements of the group generated by G to prevent small subgroup attacks. This can be achieved by a validation of the public keys (i.e., KEi, PKEi, and KEr, PKEr).
したがって、実装では、共有シークレットSASharedSecretおよびPACESharedSecretがGによって生成されたグループのランダムな要素であることを確認して、小さなサブグループ攻撃を防ぐ必要があります。これは、公開鍵（つまり、KEi、PKEi、およびKEr、PKEr）の検証によって実現できます。
First of all, each party MUST check that the public keys PKEi, PKEr, KEi, and KEr differ. Otherwise, it MUST abort the protocol.
まず、各当事者は、公開鍵PKEi、PKEr、KEi、およびKErが異なることを確認する必要があります。それ以外の場合は、プロトコルを中止する必要があります。
For each received public key PK, the following tests SHOULD be performed. Any failure in the validation MUST be interpreted as an attack, and the protocol SHALL be aborted.
受信した公開鍵PKごとに、次のテストを実行する必要があります（SHOULD）。検証の失敗は攻撃として解釈されなければならず（MUST）、プロトコルは中止されるべきです（SHALL）。
o Verify that PK is an element of the Diffie-Hellman Group.
o PKがDiffie-Hellmanグループの要素であることを確認します。
* For Modular Diffie-Hellman, check that PK lies within the interval [2,p-2].
* Modular Diffie-Hellmanの場合、PKが区間[2、p-2]内にあることを確認します。
* For Elliptic Curve Diffie-Hellman, check that PK is a point on the Elliptic Curve and not the point at infinity.
* 楕円曲線Diffie-Hellmanの場合、PKが楕円曲線上の点であり、無限遠の点ではないことを確認してください。
o Verify that PK is an element of the cryptographic subgroup of order q.
o PKが次数qの暗号サブグループの要素であることを確認します。
* For Modular Diffie-Hellman, check that PK^q = 1 (mod p).
* Modular Diffie-Hellmanの場合、PK ^ q = 1（mod p）であることを確認します。
* For Elliptic Curve Diffie-Hellman, check that q * PK = 0.
* 楕円曲線Diffie-Hellmanの場合、q * PK = 0であることを確認します。
Note that for most of the MODP groups, the order q = (p-1)/2. This
applies in particular to the standard groups #2, #5, and #14,
commonly used in IKE. For ECP and MODP groups not based on safe
primes, the order q is explictly stated in the parameters.
As an alternative to the public key validation, the compatible cofactor exponentiation/multiplication may be used, which is often more efficient but requires changes to the implementation of the key agreement. Details on the implementation can be found in [RFC2785] and in [TR03111] for Modular Diffie-Hellman and Elliptic Curve Diffie-Hellman, respectively.
公開鍵の検証の代わりに、互換性のある補因子の累乗/乗算を使用できます。これは多くの場合より効率的ですが、鍵協定の実装に変更を加える必要があります。実装の詳細は、[RFC2785]と[TR03111]で、それぞれモジュラーDiffie-Hellmanと楕円曲線Diffie-Hellmanについて説明されています。
To reduce the time that the peers store a hashed password, it is RECOMMENDED that the password be replaced by a dedicated shared secret, according to the method described in this section. See Appendix B for more discussion of the security threats involved.
ピアがハッシュされたパスワードを保存する時間を短縮するために、このセクションで説明する方法に従って、パスワードを専用の共有シークレットに置き換えることをお勧めします。関連するセキュリティ脅威の詳細については、付録Bを参照してください。
Both peers generate the value LongTermSecret during round #2 of IKE_AUTH, as shown above. Later on, they exchange a PERSIST_PSK notification. Assume that both peers support this mechanism (e.g., the IKE implementation is able to modify its own credential store). Then, each of the peers, when receiving the notification, permanently deletes the stored password and replaces it with LongTermSecret. These credentials are stored in the Peer Authorization Database (PAD) [RFC4301] and are associated with the identity of the opposite peer.
上記のように、両方のピアがIKE_AUTHのラウンド2中に値LongTermSecretを生成します。その後、PERSIST_PSK通知を交換します。両方のピアがこのメカニズムをサポートしていると仮定します（たとえば、IKE実装は、独自の資格情報ストアを変更できます）。次に、各ピアは通知を受信すると、保存されているパスワードを完全に削除し、LongTermSecretに置き換えます。これらの資格情報は、ピア認証データベース（PAD）[RFC4301]に格納され、反対側のピアのIDに関連付けられます。
This solution is designed as a two-phase commitment, so that failure at any time cannot result in the peers not having any shared secret.
このソリューションは2フェーズコミットメントとして設計されているため、いつでも障害が発生しても、ピアは共有シークレットを保持できません。
Initiator Responder
--------- ---------
IKE_AUTH round #2:
IKE_AUTHラウンド＃2：
HDR, SK{..., N(PSK_PERSIST)} ---------->
Responder computes and stores PSK
<------- HDR, SK{..., N(PSK_PERSIST)}
Initiator computes and stores PSK
イニシエーターはPSKを計算して保存します
HDR, SK{N(PSK_CONFIRM)} -------------->
Responder deletes the short password
レスポンダは短いパスワードを削除します
<-------------- HDR, SK{N(PSK_CONFIRM)}
Initiator deletes the short password
イニシエーターは短いパスワードを削除します
Figure 2: IKE SA Setup with PACE and PSK Generation
図2：PACEおよびPSK生成を使用したIKE SAセットアップ
In the second round of IKE_AUTH, the initiator MAY send a PSK_PERSIST notification if it wishes to use this mechanism. If the responder agrees, and only after it has authenticated the initiator, it MUST generate a new PSK, save it to stable storage (e.g., to disk), and MUST respond with a PSK_PERSIST notification. Otherwise, it simply does not include the notification in its reply. When receiving the reply, and after authenticating the responder, the initiator MUST also generate the PSK and save it in stable storage.
IKE_AUTHの2番目のラウンドでは、イニシエーターがこのメカニズムを使用したい場合は、PSK_PERSIST通知を送信できます（MAY）。レスポンダが同意し、イニシエータを認証した後にのみ、新しいPSKを生成し、それを安定したストレージ（ディスクなど）に保存し、PSK_PERSIST通知で応答する必要があります。それ以外の場合は、応答に通知が含まれません。応答を受信したとき、およびレスポンダを認証した後、イニシエータはPSKも生成して安定したストレージに保存する必要があります。
If the peers have negotiated this mechanism, the initiator MUST send the PSK_CONFIRM notification in an Informational exchange shortly after the IKE SA has been set up. When the responder receives it, it MUST delete the stored short password from its credential database and respond with a PSK_CONFIRM notification. Upon receiving this notification, the initiator deletes its copy of the short password.
ピアがこのメカニズムをネゴシエートした場合、イニシエーターは、IKE SAがセットアップされた直後に、情報交換でPSK_CONFIRM通知を送信する必要があります。レスポンダはそれを受信すると、格納されている短いパスワードを資格データベースから削除し、PSK_CONFIRM通知で応答する必要があります。この通知を受信すると、イニシエーターは短いパスワードのコピーを削除します。
If not saved to persistent storage, the LongTermSecret MUST be deleted when the IKE SA is rekeyed or when it is torn down. It SHOULD be deleted 1 hour after the initial IKE SA has been set up.
永続的なストレージに保存されていない場合、IKE SAのキーが再生成されたとき、または破棄されたときに、LongTermSecretを削除する必要があります。最初のIKE SAがセットアップされてから1時間後に削除する必要があります。
The LongTermSecret MUST be used as a regular IKE Pre-Shared Key (PSK), rather than with PACE or any other password-based authentication method.
LongTermSecretは、PACEまたはその他のパスワードベースの認証方法ではなく、通常のIKE事前共有キー（PSK）として使用する必要があります。
Normally, at the completion of this protocol, both peers will have either a shared password or a shared PSK. The protocol is designed so that the peers will have a shared credential, regardless of any protocol failures. However, in some failure cases, the initiator may find itself with both a short password and a PSK for a particular peer. In that case, it MUST first try to authenticate with a password and, upon success, MUST attempt to convert it to a PSK. If password authentication fails, it MUST use the PSK and upon successful setup of the IKE SA MUST permanently delete the password.
通常、このプロトコルの完了時に、両方のピアは共有パスワードまたは共有PSKのいずれかを持ちます。プロトコルは、プロトコルの障害に関係なく、ピアが共有の資格情報を持つように設計されています。ただし、失敗した場合には、イニシエーターは特定のピアの短いパスワードとPSKの両方を使用して自分自身を見つけることがあります。その場合、それは最初にパスワードで認証を試みなければならず、成功したら、それをPSKに変換しようと試みなければなりません（MUST）。パスワード認証が失敗した場合は、PSKを使用する必要があり、IKE SAのセットアップが成功したら、パスワードを完全に削除する必要があります。
The shared password is not used as is. Instead, it SHOULD be converted into a "stored password" SPwd, so that the plaintext password does not need to be stored for long periods. SPwd is defined as
共有パスワードはそのままでは使用されません。代わりに、「保存されたパスワード」のSPwdに変換する必要があるため、プレーンテキストのパスワードを長期間保存する必要はありません。 SPwdは次のように定義されます
SPwd = prf("IKE with PACE", Pwd),
SPwd = prf（ "IKE with PACE"、Pwd）、
where the literal string consists of ASCII characters with no zero terminator. If the negotiated pseudorandom function (prf) requires a fixed-size key, the literal string is either truncated or padded with zero octets on the right, as needed. Multiple copies of SPwd MAY be stored, if the prf function is not known in advance.
ここで、リテラル文字列は、ゼロターミネータのないASCII文字で構成されています。ネゴシエートされた疑似ランダム関数（prf）で固定サイズのキーが必要な場合、リテラル文字列は切り捨てられるか、必要に応じて右側にゼロオクテットが埋め込まれます。 prf関数が事前にわからない場合は、SPwdの複数のコピーを保存できます。
KPwd = prf+(Ni | Nr, SPwd),
ＫＰｗｄ ＝ ｐｒｆ＋（に ｜ んｒ、 ＳＰｗｄ）、
where Ni and Nr are the regular IKE nonces, stripped of any headers. If the negotiated prf takes a fixed-length key and the lengths of Ni and Nr do not add up to that length, half the bits must come from Ni and half from Nr, taking the first bits of each. "prf+" is defined in Section 2.13 of [RFC5996]. The length of KPwd is determined by the key length of the negotiated encryption algorithm.
ここで、NiおよびNrは、ヘッダーを取り除いた通常のIKEナンスです。ネゴシエートされたprfが固定長のキーを取り、NiとNrの長さがその長さに合わない場合、ビットの半分はNiから、半分はNrから、それぞれの最初のビットを取得する必要があります。 「prf +」は、[RFC5996]のセクション2.13で定義されています。 KPwdの長さは、ネゴシエートされた暗号化アルゴリズムのキーの長さによって決まります。
A nonce s is randomly selected by the initiator (see Section 6.4 for additional considerations). The length of s MUST be exactly 32 octets.
nonceはイニシエーターによってランダムに選択されます（追加の考慮事項については、セクション6.4を参照してください）。 sの長さは正確に32オクテットでなければなりません。
KPwd is now used with the encryption transform to encrypt the nonce:
KPwdがnonceを暗号化する暗号化トランスフォームで使用されるようになりました。
ENONCE = E(KPwd, s)
ENONCE = E（KPwd、s）
If an Initialization Vector (IV) is required by the cipher, it MUST be included in the GSPM(ENONCE) payload. It is RECOMMENDED that the IV be chosen both randomly and uniformly distributed, even though this condition is not necessary for the cryptographic security of the protocol.
暗号で初期化ベクトル（IV）が必要な場合は、それをGSPM（ENONCE）ペイロードに含める必要があります。プロトコルの暗号化セキュリティにはこの条件は必要ではありませんが、IVはランダムかつ均一に分散して選択することをお勧めします。
Note: Padding MUST NOT be used when encrypting the nonce. The size of the nonce has been chosen such that it can be encrypted with block ciphers having block sizes of 32, 64, and 128 bits without any padding.
注：nonceを暗号化するときは、パディングを使用してはなりません（MUST NOT）。 nonceのサイズは、32、64、および128ビットのブロックサイズを持つブロック暗号でパディングなしに暗号化できるように選択されています。
If an authenticated encryption cipher [RFC5282] has been negotiated for the IKE SA, it MUST NOT be used as is because such use would be vulnerable to dictionary attacks. Instead, the corresponding unauthenticated mode MUST be used. All Galois/Counter Mode (GCM) and all Counter with CBC-MAC (CCM) encryption algorithms are mapped to the corresponding counter-mode algorithm. For example, if the negotiated encryption algorithm (Transform Type 1) is "AES-GCM with an 8-octet Integrity Check Value (ICV)", then ENCR_AES_CTR (with the same key length) is used to encrypt the nonce. If such a mapping does not exist for a particular cipher, then it MUST NOT be used within the current protocol.
認証された暗号化暗号[RFC5282]がIKE SAについてネゴシエートされている場合、そのような使用は辞書攻撃に対して脆弱であるため、そのまま使用してはなりません（MUST NOT）。代わりに、対応する非認証モードを使用する必要があります。すべてのGalois / Counter Mode（GCM）およびすべてのCounter with CBC-MAC（CCM）暗号化アルゴリズムは、対応するCounter-modeアルゴリズムにマッピングされます。たとえば、ネゴシエートされた暗号化アルゴリズム（変換タイプ1）が「8オクテットの整合性チェック値（ICV）を使用するAES-GCM」である場合、ナンスの暗号化にはENCR_AES_CTR（同じキー長）が使用されます。特定の暗号に対してそのようなマッピングが存在しない場合は、現在のプロトコル内で使用してはなりません（MUST NOT）。
The mapping is based on a second anonymous Diffie-Hellman key agreement protocol to create a shared secret that is used together with the exchanged nonce to calculate a common secret generator of the group.
マッピングは、2番目の匿名Diffie-Hellman鍵合意プロトコルに基づいており、共有秘密を作成します。これは、交換されたナンスと一緒に使用され、グループの共通秘密ジェネレーターを計算します。
While in [TR03110] the generation of the shared secret is part of the mapping, in the setting of IKEv2, a shared secret SASharedSecret has already been generated as part of the IKE_SA_INIT step. Using the notation of [RFC5996],
[TR03110]では、共有シークレットの生成はマッピングの一部ですが、IKEv2の設定では、共有シークレットSASharedSecretがIKE_SA_INITステップの一部としてすでに生成されています。 [RFC5996]の表記を使用して、
SASharedSecret = g^ir
Sashredsecret = g ^ er
Let G and GE be the generator of the negotiated Diffie-Hellman group, and the calculated ephemeral generator, respectively. The following subsections describe the mapping for different Diffie-Hellman variants.
GとGEを、交渉されたDiffie-Hellmanグループのジェネレーター、および計算された一時的なジェネレーターとする。以下のサブセクションでは、さまざまなDiffie-Hellmanバリアントのマッピングについて説明します。
The function Map:G->GE is defined as GE = G^s * SASharedSecret.
関数Map：G-> GEは、GE = G ^ s * SASharedSecretとして定義されます。
Note that the protocol will fail if G^s = 1/SASharedSecret. If s is chosen randomly, this event occurs with negligible probability. In implementations that detect such a failure, the initiator SHOULD choose s again.
G ^ s = 1 / SASharedSecretの場合、プロトコルは失敗することに注意してください。 sがランダムに選択された場合、このイベントはごくわずかな確率で発生します。このような障害を検出する実装では、イニシエーターは再度を選択する必要があります（SHOULD）。
The function Map:G->GE is defined as GE = s*G + SASharedSecret.
関数Map：G-> GEは、GE = s * G + SASharedSecretとして定義されます。
Note that the protocol will fail if s*G = -SharedSecret. If s is chosen randomly, this event occurs with negligible probability. In implementations that detect such a failure, the initiator SHOULD choose s again.
s * G = -SharedSecretの場合、プロトコルは失敗することに注意してください。 sがランダムに選択された場合、このイベントはごくわずかな確率で発生します。このような障害を検出する実装では、イニシエーターは再度を選択する必要があります（SHOULD）。
The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHOULD be considered a "stored string" per [RFC3454]; therefore, unassigned code points are prohibited. The output is the binary representation of the processed UTF-8 character string. Prohibited output and unassigned codepoints encountered in SASLprep preprocessing SHOULD cause a preprocessing failure, and the output SHOULD NOT be used. A compliant implementation MUST NOT apply any other form of processing to the input password, other than as described in this section.
入力パスワード文字列は、[RFC3454]の[RFC4013]プロファイルのルールに従って処理する必要があります（SHOULD）。 [RFC3454]によると、パスワードは「格納された文字列」と見なされるべきです。したがって、割り当てられていないコードポイントは禁止されています。出力は、処理されたUTF-8文字列のバイナリ表現です。 SASLprepの前処理で禁止された出力と割り当てられていないコードポイントが発生すると、前処理が失敗し、出力は使用されるべきではありません（SHOULD）。準拠した実装では、このセクションで説明されている以外の処理を入力パスワードに適用してはなりません（MUST NOT）。
See Section 3 of [RFC4013] for examples of SASLprep processing.
SASLprep処理の例については、[RFC4013]のセクション3を参照してください。
[RFC6467] defines a new type of Notify payload to indicate support for Secure Password Methods (SPMs) in the IKE_SA_INIT exchange. The SPM Notify payload is defined as follows:
[RFC6467]は、IKE_SA_INIT交換でのセキュアパスワードメソッド（SPM）のサポートを示す新しいタイプの通知ペイロードを定義します。 SPM通知ペイロードは次のように定義されます。
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: SECURE_PASSWORD_METHODS Payload Structure
図3：SECURE_PASSWORD_METHODSペイロード構造
The Protocol ID is zero, and the SPI Size is also zero, indicating that the SPI field is empty. The Notify Message Type is SECURE_PASSWORD_METHODS (value 16424).
プロトコルIDはゼロであり、SPIサイズもゼロであり、SPIフィールドが空であることを示します。通知メッセージタイプはSECURE_PASSWORD_METHODS（値16424）です。
The Notification Data contains the list of the 16-bit secure password method numbers:
通知データには、16ビットの安全なパスワード方式番号のリストが含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #1 | Secure Password Method #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SECURE_PASSWORD_METHODS Payload Data
図4：SECURE_PASSWORD_METHODSペイロードデータ
For the current method, the list of proposed methods MUST include the value PACE (1).
現在の方法では、提案された方法のリストに値PACE（1）を含める必要があります。
This document defines the PSK_PERSIST notification type, whose value is 16425. This notification MUST be sent with no data. However, for future extensibility, the receiver MUST ignore any notification data if such data is present.
このドキュメントは、値が16425であるPSK_PERSIST通知タイプを定義します。この通知は、データなしで送信する必要があります。しかし、将来の拡張性のために、そのようなデータが存在する場合、受信者は通知データを無視しなければなりません（MUST）。
This document defines the PSK_CONFIRM notification type, whose value is 16426. This notification MUST be sent with no data. However, for future extensibility, the receiver MUST ignore any notification data if such data is present.
このドキュメントは、値が16426であるPSK_CONFIRM通知タイプを定義します。この通知は、データなしで送信する必要があります。ただし、将来の拡張性のために、そのようなデータが存在する場合、受信者は通知データを無視する必要があります。
This protocol defines the ENONCE (encrypted nonce) payload, which reuses the Generic SPM (GSPM) payload type [RFC6467] (value 49). Its format is as follows:
このプロトコルは、ENONCE（暗号化ナンス）ペイロードを定義します。これは、Generic SPM（GSPM）ペイロードタイプ[RFC6467]（値49）を再利用します。その形式は次のとおりです。
0 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACE-RESERVED | Initialization Vector |
+-+-+-+-+-+-+-+-+ +
| (optional, length depends on the encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: ENONCE Payload Structure
図5：ENONCEペイロード構造
See Section 4.1 for further details about the encrypted nonce. Note that the protocol -- and in particular this payload's format -- does not support any padding of the encrypted data.
暗号化されたナンスの詳細については、セクション4.1を参照してください。プロトコル、特にこのペイロードのフォーマットは、暗号化されたデータのパディングをサポートしていないことに注意してください。
The PACE-RESERVED field must be sent as zero, and it must be rejected by the receiver if it is not 0.
PACE-RESERVEDフィールドはゼロとして送信する必要があり、0でない場合はレシーバーによって拒否される必要があります。
PACE reuses the Key Exchange (KE) payload for its Diffie-Hellman exchange, with the new payloads being sent within the IKE_AUTH exchange. Since only one Diffie-Hellman group is negotiated, the group denoted by these payloads MUST be identical to the one used in the "regular" KE payloads in IKE_SA_INIT.
PACEは、キー交換（KE）ペイロードをDiffie-Hellman交換に再利用し、新しいペイロードはIKE_AUTH交換内で送信されます。 1つのDiffie-Hellmanグループのみがネゴシエートされるため、これらのペイロードによって示されるグループは、IKE_SA_INITの「通常の」KEペイロードで使用されるものと同一である必要があります。
A session resumption [RFC5723] ticket may be requested during the IKE_AUTH exchange. The request MUST be sent in the request of the first round, and any response MUST be sent in the response of the second one.
セッション再開[RFC5723]チケットは、IKE_AUTH交換中に要求される場合があります。リクエストは最初のラウンドのリクエストで送信する必要があり、すべてのレスポンスは2番目のラウンドのレスポンスで送信する必要があります。
PACE should be considered an "authentication method", in the sense of Section 5 of [RFC5723], which means that its use MUST be noted in the protected ticket. The format of the ticket is not standardized; however, it is RECOMMENDED that this indication distinguish between the different secure password authentication methods defined for IKE.
[RFC5723]のセクション5の意味では、PACEは「認証方法」と考える必要があります。これは、その使用が保護されたチケットに記載されている必要があることを意味します。チケットのフォーマットは標準化されていません。ただし、この表示は、IKEに定義されたさまざまなセキュアパスワード認証方式を区別することをお勧めします。
Note that even if the initial authentication used PACE and its extended IKE_AUTH, session resumption will still include the normal IKE_AUTH exchange.
最初の認証でPACEとその拡張IKE_AUTHを使用した場合でも、セッションの再開には通常のIKE_AUTH交換が含まれることに注意してください。
A major goal of this protocol has been to maintain the level of security provided by IKEv2. What follows is an analysis of this protocol. The reader is referred to [RFC5996] for the generic IKEv2 security considerations.
このプロトコルの主要な目標は、IKEv2によって提供されるセキュリティのレベルを維持することでした。以下は、このプロトコルの分析です。一般的なIKEv2セキュリティの考慮事項については、[RFC5996]を参照してください。
This protocol makes no assumption on the strength of the shared credential. Best common practices regarding minimal password length, use of multiple character classes, etc. SHOULD be followed.
このプロトコルは、共有資格情報の強度を想定していません。パスワードの長さの最小化、複数の文字クラスの使用などに関する一般的なベストプラクティスに従ってください。
The protocol is secure against both passive and active attackers. See Section 6.8 for a security proof.
このプロトコルは、パッシブ攻撃者とアクティブ攻撃者の両方に対して安全です。セキュリティの証明については、セクション6.8を参照してください。
While not attacking the cryptography, an attacker can still perform a standard password-guessing attack. To mitigate such attacks, an implementation MUST include standard protections, such as rate-limiting the number of allowed password-guessing attempts, possibly locking identities out after a certain number of failed attempts, etc. Note that the protocol is symmetric; therefore, this guidance applies to client-side implementations as well.
暗号を攻撃していなくても、攻撃者は標準のパスワード推測攻撃を実行できます。このような攻撃を緩和するために、実装には、許可されるパスワード推測試行の数をレート制限したり、特定の回数の試行が失敗した後にIDをロックアウトしたりするなど、標準的な保護を含める必要があります。プロトコルは対称であることに注意してください。したがって、このガイダンスはクライアント側の実装にも適用されます。
The key derivation for the IKE SA and any Child SAs is performed as part of IKEv2 and remains unchanged. It directly follows that perfect forward security is provided independent of the authentication additionally performed by PACE.
IKE SAおよびすべての子SAの鍵の派生は、IKEv2の一部として実行され、変更されません。これは、PACEによって追加で実行される認証とは関係なく、完全な転送セキュリティが提供されるということです。
The security of this protocol depends on the quality generation of random quantities; see Section 5 of [RFC5996] for more details. Specifically, any deviation from randomness of the nonce s might compromise the password. Therefore, it is strongly RECOMMENDED that the initiator pass the raw random material through a strong prf to ensure the statistical qualities of the nonce.
このプロトコルのセキュリティは、乱数の品質生成に依存します。詳細については、[RFC5996]のセクション5を参照してください。具体的には、ナンスのランダム性からの逸脱はパスワードを危険にさらす可能性があります。したがって、ノンスの統計的品質を保証するために、開始者が強力なprfを介して生のランダムな材料を渡すことを強くお勧めします。
This protocol is identical to IKEv2 in the quality of identity protection it provides. Both peers' identities are secure from passive attackers, and both peers' identities are exposed to active, man-in-the-middle attackers.
このプロトコルは、提供するID保護の品質においてIKEv2と同じです。両方のピアのIDはパッシブな攻撃者から保護されており、両方のピアのIDはアクティブな中間者攻撃にさらされています。
We are not aware of any new denial-of-service attack vector enabled by this protocol.
このプロトコルによって可能になる新しいサービス拒否攻撃の方法については認識していません。
Any transforms negotiated for IKEv2 may be used by this protocol. Please refer to Section 4.1 for the considerations regarding authenticated encryption ("combined mode") algorithms.
IKEv2用にネゴシエートされたすべての変換は、このプロトコルで使用できます。認証された暗号化（「複合モード」）アルゴリズムに関する考慮事項については、セクション4.1を参照してください。
PACE is cryptographically proven secure in [PACEsec] in the model of Bellare, Pointcheval, and Rogaway [BPRmodel]. The setting in which PACE is proven secure is, however, slightly different from the setting used in IKEv2. The differences are described in the following:
PACEは、Bellare、Pointcheval、およびRogawayのモデル[BPRmodel]の[PACEsec]で暗号的に安全であることが証明されています。ただし、PACEが安全であることが証明されている設定は、IKEv2で使用されている設定とは少し異なります。違いは次のとおりです。
o Part of the mapping is already performed within IKEv2 before PACE is started. This rearrangement does not affect the proof, as the resulting PACESharedSecret remains close to uniformly distributed in the group generated by G.
o マッピングの一部は、PACEが開始される前にIKEv2内ですでに実行されています。結果のPACESharedSecretは、Gによって生成されたグループに均一に分散された状態に近いままなので、この再配置は証明に影響しません。
o The keys for the IKE SA and any Child SAs are already generated within IKEv2 before PACE is started. While those session keys could also be derived in PACE, only the keys for the authentication token are considered in the proof, which explicitly recommends a separate key for this purpose.
o IKE SAおよびすべての子SAのキーは、PACEが開始される前に、IKEv2内ですでに生成されています。これらのセッションキーはPACEでも生成できますが、証明では認証トークンのキーのみが考慮されます。証明では、この目的のために別のキーを明示的に推奨しています。
o IKEv2 allows the negotiation of a stream cipher for PACE, while the proven variant always uses a block cipher. The ideal cipher is replaced in the proof by a lazy-sampling technique that is similarly applicable to the stream-cipher-based construction.
o IKEv2はPACEのストリーム暗号のネゴシエーションを可能にしますが、実績のあるバリアントは常にブロック暗号を使用します。理想的な暗号は、ストリーム暗号ベースの構築に同様に適用できるレイジーサンプリング技術によって証明で置き換えられます。
The differences in the setting therefore have no impact on the validity of the proof.
したがって、設定の違いは証明の有効性に影響を与えません。
This protocol does not require that peers store the plaintext password. Instead, the value SPwd SHOULD be stored by both peers.
このプロトコルでは、ピアがプレーンテキストのパスワードを保存する必要はありません。代わりに、値SPwdは両方のピアによって格納される必要があります（SHOULD）。
In addition, the protocol allows both peers to replace the password by a crypto-strength shared secret. This solution improves the system's security (since passwords are often used for multiple applications), but at the cost of implementation complexity. In particular, if this optional mechanism is to be used, the credential database would need to be writable by the key management subsystem.
さらに、このプロトコルでは、両方のピアがパスワードを暗号強度の共有秘密に置き換えることができます。このソリューションは、システムのセキュリティを向上させます（パスワードは複数のアプリケーションで使用されることが多いため）が、実装の複雑さが犠牲になります。特に、このオプションのメカニズムを使用する場合、資格情報データベースは、キー管理サブシステムによって書き込み可能である必要があります。
See Appendix B for alternatives to this approach.
このアプローチの代替案については、付録Bを参照してください。
IANA has allocated the following values:
IANAは次の値を割り当てました。
o A PACE value of 1 from the "IKEv2 Secure Password Methods" registry [RFC6467].
o 「IKEv2セキュアパスワードメソッド」レジストリ[RFC6467]のPACE値1。
o A PSK_PERSIST value of 16425 and a PSK_CONFIRM value of 16426 from the "IKEv2 Notify Message Types - Status Types" registry. We note that these notification types are generic and that other password authentication methods may also choose to use them.
o 「IKEv2通知メッセージタイプ-ステータスタイプ」レジストリからのPSK_PERSIST値16425およびPSK_CONFIRM値16426。これらの通知タイプは一般的なものであり、他のパスワード認証方法でもこれらの使用を選択する場合があることに注意してください。
We would like to thank Dan Harkins for pointing out a security issue with our use of combined-mode algorithms in a previous version of the protocol. We thank Tero Kivinen for his generic framework document, and for a thorough and fruitful review. Hugo Krawczyk proposed that the password be amplified into a persistent shared secret.
以前のバージョンのプロトコルでの結合モードアルゴリズムの使用によるセキュリティの問題を指摘してくれたDan Harkinsに感謝します。 Tero Kivinenの一般的なフレームワークドキュメントと、綿密で実りのあるレビューに感謝します。 Hugo Krawczykさんは、パスワードを永続的な共有シークレットに増幅することを提案しました。
[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月。
[RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.
[RFC2785] Zuccherato、R。、「S / MIMEのDiffie-Hellman鍵合意方法に対する「小サブグループ」攻撃を回避する方法」、RFC 2785、2000年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月。
[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月。
[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月。
[BPRmodel] Bellare, M., Pointcheval, D., and P. Rogaway, "Authenticated Key Exchange Secure against Dictionary Attacks", EUROCRYPT 2000, LNCS 1807, pp. 139-155, Springer-Verlag, 2000, <http://www.iacr.org/cryptodb/ archive/2000/EUROCRYPT/18070139.pdf>.
[BPRモデル] Bellare、M.、Pointcheval、D。、およびP. Rogaway、「認証された鍵交換は辞書攻撃に対して安全」、EUROCRYPT 2000、LNCS 1807、pp。139-155、Springer-Verlag、2000、<http：/ /www.iacr.org/cryptodb/archive/2000/EUROCRYPT/18070139.pdf>。
[ICAO] ISO/IEC JTC1 SC17 WG3/TF5 for the International Civil Aviation Organization (ICAO), "Supplemental Access Control for Machine Readable Travel Documents", Version 1.01, November 2010.
[ICAO] ISO / IEC JTC1 SC17 WG3 / TF5 for the International Civil Aviation Organization（ICAO）、「Supplemental Access Control for Machine Readable Travel Documents」、バージョン1.01、2010年11月。
[IKEv2-CONS] Harkins, D., "Password-Based Authentication in IKEv2: Selection Criteria and Considerations", Work in Progress, October 2010.
[IKEv2-CONS] Harkins、D。、「IKEv2でのパスワードベースの認証：選択基準と考慮事項」、Work in Progress、2010年10月。
[PACEsec] Bender, J., Fischlin, M., and D. Kuegler, "Security Analysis of the PACE Key-Agreement Protocol", LNCS 5735, pp. 33-48, Springer-Verlag (the extended abstract appeared in Information Security Conference (ISC) 2009), December 2009, <http://eprint.iacr.org/2009/624>.
[PACEsec] Bender、J.、Fischlin、M。、およびD. Kuegler、「PACE Key-Agreement Protocolのセキュリティ分析」、LNCS 5735、pp。33-48、Springer-Verlag（拡張要約は情報セキュリティに登場会議（ISC）2009）、2009年12月、<http://eprint.iacr.org/2009/624>。
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008.
[RFC5282] Black、D。、およびD. McGrew、「Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2（IKEv2）Protocol」、RFC 5282、2008年8月。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[RFC5723] Sheffer、Y。およびH. Tschofenig、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）セッションの再開」、RFC 5723、2010年1月。
[RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010.
[RFC5998] Eronen、P.、Tschofenig、H。、およびY. Sheffer、「An an Extension for EAP-Only Authentication in IKEv2」、RFC 5998、2010年9月。
[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月。
[TR03110] BSI, "TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents, Part 2 - Extended Access Control Version 2 (EACv2), Password Authenticated Connection Establishment (PACE), and Restricted Identification (RI)", Version 2.10, March 2012.
[TR03110] BSI、「TR-03110、機械読み取り可能な旅行ドキュメントの高度なセキュリティメカニズム、パート2-拡張アクセスコントロールバージョン2（EACv2）、パスワード認証接続確立（PACE）、および制限付き識別（RI）」、バージョン2.10、 2012年3月。
[TR03111] BSI, "TR-03111, Elliptic Curve Cryptography", Version 1.11, April 2009.
[TR03111] BSI、「TR-03111、楕円曲線暗号」、バージョン1.11、2009年4月。
To support the selection of a password-based protocol for inclusion in IKEv2, a number of criteria are provided in [IKEv2-CONS]. In the following sections, those criteria are applied to the PACE protocol.
IKEv2に含めるパスワードベースのプロトコルの選択をサポートするために、[IKEv2-CONS]にはいくつかの基準が用意されています。次のセクションでは、これらの基準がPACEプロトコルに適用されます。
SEC1: PACE is a zero-knowledge protocol.
SEC1：PACEはゼロ知識プロトコルです。
SEC2: The protocol supports perfect forward secrecy and is resistant to replay attacks.
SEC2：プロトコルは完全転送秘密をサポートし、リプレイ攻撃に対して耐性があります。
SEC3: The identity protection provided by IKEv2 remains unchanged.
SEC3：IKEv2によって提供されるID保護は変更されていません。
SEC4: Any cryptographically secure Diffie-Hellman group can be used.
SEC4：暗号的に安全なDiffie-Hellmanグループを使用できます。
SEC5: The protocol is proven secure in the Bellare-Pointcheval-Rogaway model.
SEC5：Bellare-Pointcheval-Rogawayモデルでプロトコルが安全であることが証明されています。
SEC6: Strong session keys are generated.
SEC6：強力なセッションキーが生成されます。
SEC7: A transform of the password can be used instead of the password itself.
SEC7：パスワード自体の代わりに、パスワードの変換を使用できます。
IPR1: The first version of [TR03110] was published on May 21, 2007.
IPR1：[TR03110]の最初のバージョンは2007年5月21日に公開されました。
IPR2: BSI has developed PACE aiming to be free of patents. BSI has not applied for a patent on PACE.
IPR2：BSIは、特許がないことを目的としたPACEを開発しました。 BSIはPACEに関する特許を申請していません。
IPR3: The protocol itself is believed to be free of IPR.
IPR3：プロトコル自体にはIPRがないと考えられています。
MISC1: One additional exchange is required.
MISC1：追加の交換が1つ必要です。
MISC2: The protocol requires the following operations per entity:
MISC2：プロトコルでは、エンティティごとに次の操作が必要です。
* one key derivation from the password,
* パスワードからの1つのキー派生
* one symmetric encryption or decryption,
* 1つの対称暗号化または復号化、
* one multi-exponentiation for the mapping,
* マッピング用の1つの多重指数、
* one exponentiation for the key pair generation,
* 鍵ペア生成のための1つの指数
* one exponentiation for the shared secret calculation, and
* 共有秘密計算のための1つのべき乗、および
* two symmetric authentications (generation and verification).
* 2つの対称認証（生成と検証）。
MISC3: The performance is independent of the type/size of password.
MISC3：パフォーマンスは、パスワードのタイプ/サイズに依存しません。
MISC4: Internationalization of character-based passwords is supported.
MISC4：文字ベースのパスワードの国際化がサポートされています。
MISC5: The protocol uses the same group as that negotiated for IKEv2.
MISC5：プロトコルは、IKEv2用にネゴシエートされたものと同じグループを使用します。
MISC6: The protocol fits into the request/response nature of IKE.
MISC6：プロトコルは、IKEの要求/応答の性質に適合します。
MISC7: The password-based symmetric encryption must be additionally negotiated.
MISC7：パスワードベースの対称暗号化は、さらにネゴシエートする必要があります。
MISC8: Neither trusted third parties nor clock synchronization are required.
MISC8：信頼できるサードパーティもクロック同期も必要ありません。
MISC9: Only general cryptographic primitives are required.
MISC9：一般的な暗号プリミティブのみが必要です。
MISC10: Any secure variant of Diffie-Hellman (e.g., Modular or Elliptic Curve) can be used.
MISC10：Diffie-Hellmanの安全なバリアント（モジュラーカーブや楕円カーブなど）を使用できます。
MISC11: The protocol can be implemented easily based on existing cryptographic primitives.
MISC11：プロトコルは、既存の暗号プリミティブに基づいて簡単に実装できます。
This protocol requires that passwords not be stored in plaintext. Instead, we store a hash of the password with a fixed hash. This value is then used in the ZKPP protocol, replacing the original password and acting as a "password equivalent". The main benefit of this solution is that a system administrator or an undetermined attacker does not get immediate access to the passwords. We believe this is sufficiently secure for the main usage scenario of the protocol.
このプロトコルでは、パスワードがプレーンテキストで保存されていないことが必要です。代わりに、固定ハッシュでパスワードのハッシュを保存します。この値はZKPPプロトコルで使用され、元のパスワードを置き換え、「同等のパスワード」として機能します。このソリューションの主な利点は、システム管理者または未確認の攻撃者がパスワードにすぐにアクセスできないことです。これは、プロトコルの主な使用シナリオに対して十分に安全であると信じています。
However, the common practice of password salting is clearly more powerful, and this appendix presents a few ideas on how password salting can be applied and/or adapted to fit into a symmetric protocol such as IKE. First, let us list the threats that we expect salting to handle, as well as the non-threats:
ただし、パスワードソルティングの一般的な方法は明らかにより強力であり、この付録では、IKEなどの対称プロトコルにパスワードソルティングを適用および/または適合させる方法についていくつかのアイデアを示します。最初に、ソルティングが処理すると予想される脅威と、脅威以外をリストします。
o The plain password should not be visible to a casual onlooker, as noted above. It is assumed that very often the same password is used for multiple applications, and so a password exposed allows an attacker a starting point for further attacks.
o 上記のように、プレーンなパスワードは一般の見物人には見えないはずです。多くの場合、同じパスワードが複数のアプリケーションに使用されることが想定されているため、公開されたパスワードは、攻撃者がさらなる攻撃の開始点となることを可能にします。
o An attacker must not be able to construct lookup tables (such as the famous "rainbow tables") that enable her to discover the plain password.
o 攻撃者は、プレーンなパスワードを発見できるようにするルックアップテーブル（有名な "レインボーテーブル"など）を構築することはできません。
o IKE is a symmetric protocol, in the sense that any of the peers might initiate an IKE exchange to another peer. As a result, all peers must have stored credentials (passwords or password equivalents) that would enable them to set up an IKE exchange. So, an attacker that reaches the credential store would in fact be able to impersonate IKE to another peer. We believe that this reduces, but does not invalidate, the importance of salting, because of the other threats that remain.
o IKEは、いずれかのピアが別のピアとのIKE交換を開始する可能性があるという意味で、対称プロトコルです。その結果、すべてのピアには、IKE交換をセットアップできる資格情報（パスワードまたは同等のパスワード）が格納されている必要があります。したがって、資格情報ストアに到達した攻撃者は、実際にはIKEを別のピアに偽装することができます。これにより、他の脅威が残っているため、ソルティングの重要性が減少するが無効にはならないと考えています。
Below we present different scenarios and solutions that support password salting in this setting.
以下に、この設定でパスワードソルティングをサポートするさまざまなシナリオとソリューションを示します。
We assume that each credential is used to authenticate exactly two peers to one another; i.e., (as per the best practice), group credentials are not allowed.
各クレデンシャルは、相互に正確に2つのピアを認証するために使用されると想定しています。つまり、（ベストプラクティスに従って）グループの認証情報は許可されていません。
Despite the protocol's symmetry, there are use cases that are somewhat asymmetric. Consider the case of an organization that consists of a headquarters and branches, using a hub-and-spoke architecture. Communication sessions can be initiated by the center or by any of the branches, but only the center holds a large credential database.
プロトコルの対称性にもかかわらず、やや非対称のユースケースがあります。ハブアンドスポークアーキテクチャを使用して、本社と支社で構成される組織の場合を考えてみます。通信セッションはセンターまたは任意のブランチによって開始できますが、センターだけが大きなクレデンシャルデータベースを保持しています。
Here it would be possible to use traditional password salting,
ここでは、従来のパスワードソルティングを使用することが可能です。
stored password = hash(salt, password),
保存されたパスワード= hash（salt、password）、
where the hash function is a symmetric hash (e.g., HMAC-SHA-256, using the salt as its key), and the salt is picked at random for each password. The salt would need to be sent in the first exchange of the protocol, regardless of which side initiates the session. Unlike the normal use of salted passwords, here it is the stored password, rather than the original password, that is used by the follow-on ZKPP protocol.
ここで、ハッシュ関数は対称ハッシュ（たとえば、HMAC-SHA-256、saltをキーとして使用）であり、ソルトはパスワードごとにランダムに選択されます。ソルトは、どちらの側がセッションを開始するかに関係なく、プロトコルの最初の交換で送信する必要があります。ソルト付きパスワードの通常の使用とは異なり、これは、後続のZKPPプロトコルで使用される元のパスワードではなく、保存されたパスワードです。
For the fully symmetric case, we propose a salting method based on a commutative one-way function. This is essentially a novel variant of the RSA protocol. Using this solution, all protocol peers can store the password in a salted form.
完全に対称なケースでは、可換一方向関数に基づくソルティング手法を提案します。これは本質的に、RSAプロトコルの新しい変種です。このソリューションを使用すると、すべてのプロトコルピアがソルト形式でパスワードを保存できます。
The implementation proposed here requires a composite number n that is common to all peers. The composite number n can be generated by a trusted (third) party as n = p * q, where p and q are strong primes (i.e., p = 2 * p' + 1 and q = 2 * q' + 1, where p' and q' are also primes), and the trusted party promises not to retain a copy of the primes. Alternatively, n can be chosen randomly and tested for "small" prime factors. In the latter case, it is certainly not guaranteed that n is composed of only two primes. While this has the advantage that no one knows the factorization of n, the disadvantage is that n is likely to be significantly easier to factor.
ここで提案する実装では、すべてのピアに共通の合成数nが必要です。合成数nは、信頼できる（サード）パーティがn = p * qとして生成できます。ここで、pおよびqは強い素数です（つまり、p = 2 * p '+ 1およびq = 2 * q' + 1、ここでp 'とq'も素数です）。信頼できる当事者は素数のコピーを保持しないことを約束します。あるいは、nをランダムに選択して、「小さな」素因数をテストすることもできます。後者の場合、nが2つの素数のみで構成されるとは限りません。これには、nの因数分解を誰も知らないという利点がありますが、nの因数分解が大幅に容易になる可能性があるという欠点があります。
Each peer then chooses a public encryption key "e". In a simple implementation, the encryption key is generated randomly by each peer, picking a different value for each of the passwords that it stores.
次に、各ピアは公開暗号化キー「e」を選択します。単純な実装では、暗号化キーは各ピアによってランダムに生成され、格納するパスワードごとに異なる値を選択します。
Note that although the pair (n,e) is similar to an RSA public key, the usual rules for generating "e" for the RSA protocol do not apply here, and a random "e" is sufficient. The password is hashed by a symmetric hash function H (e.g., SHA-256). Each peer i stores the two values
ペア（n、e）はRSA公開鍵に似ていますが、RSAプロトコルの「e」を生成するための通常の規則はここでは適用されず、ランダムな「e」で十分です。パスワードは、対称ハッシュ関数H（SHA-256など）によってハッシュされます。各ピアiは2つの値を保存します
e_i, H(P)^e_i (mod n),
e_i、H（P）^ e_i（mod n）、
where P is the original password. The values e_i are exchanged by the peers before the ZKPP protocol commences (in IKEv2-PACE, this would be in IKE_SA_INIT), and the following value is used in the ZKPP protocol run that follows, in lieu of the original password:
ここで、Pは元のパスワードです。値e_iは、ZKPPプロトコルが開始する前にピアによって交換され（IKEv2-PACEでは、これはIKE_SA_INITにあります）、次の値は、元のパスワードの代わりに、次のZKPPプロトコルの実行で使用されます。
H(P) ^ (e_i * e_j) (mod n).
H（P）^（e_i * e_j）（mod n）。
This transformation is used as a salting mechanism only, and the salted values themselves are never sent on the wire.
この変換はソルトメカニズムとしてのみ使用され、ソルトされた値自体がネットワーク上で送信されることはありません。
This scheme can be enhanced by basing the value "e" on each peer's identity (IDi, IDr), e.g., making it a simple hash of the identity. This eliminates the need to send "e" explicitly and additionally binds the identity of the peer with its secret.
このスキームは、各ピアのID（IDi、IDr）に基づいて値「e」を基にすることで拡張できます。たとえば、IDの単純なハッシュにします。これにより、「e」を明示的に送信する必要がなくなり、さらに、ピアのIDをそのシークレットにバインドします。
An alternative to salting is to store the plain passwords, but only for a short while. As soon as the first IKE SA is set up between two peers, the peers exchange nonces and generate a strong shared secret, based on IKE's SK_d. They now destroy the short password and replace it with the new secret.
ソルトの代わりに、プレーンなパスワードを保存することもできますが、それはしばらくの間です。 2つのピア間に最初のIKE SAがセットアップされるとすぐに、ピアはナンスを交換し、IKEのSK_dに基づいて強力な共有秘密を生成します。彼らは今短いパスワードを破壊し、それを新しい秘密に置き換えます。
This method has been added to the current protocol as an optional mechanism.
このメソッドは、オプションのメカニズムとして現在のプロトコルに追加されました。
Authors' Addresses
著者のアドレス
Dennis Kuegler Bundesamt fuer Sicherheit in der Informationstechnik (BSI) Postfach 200363 Bonn 53133 Germany
Dennis Kuegler連邦情報セキュリティ局（BSI）Postfach 200363 Bonn 53133 Germany
EMail: dennis.kuegler@bsi.bund.de
Yaron Sheffer Porticor
Yaron Sheffer Porticor
EMail: yaronf.ietf@gmail.com