Network Working Group H. Tschofenig
Request for Comments: 5106 D. Kroeselberg
Category: Experimental Nokia Siemens Networks
A. Pashalidis
NEC
Y. Ohba
Toshiba
F. Bersani
France Telecom
February 2008
The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method
拡張認証プロトコル - インターネット鍵交換プロトコルバージョン2（EAP-IKEv2の）方法
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Abstract
抽象
This document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode.
この文書では、EAP-IKEv2の、インターネット鍵交換（IKEv2の）プロトコルに基づいて拡張認証プロトコル（EAP）メソッドを指定します。 EAP-のIKEv2は、EAPピアとEAPサーバとの間の相互認証およびセッション鍵の確立を提供します。これは、パスワード、高エントロピー共有鍵、および公開鍵証明書に基づいている認証技術をサポートしています。 EAP-のIKEv2はさらに、断片化、および任意の「高速再接続」モード（特定の動作モードで）暗号化暗号スイートネゴシエーション、ハッシュ関数の俊敏性、アイデンティティの機密性のためのサポートを提供します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
4. Fast Reconnect ..................................................9
5. Key Derivation .................................................12
6. Session ID, Peer ID, and Server ID .............................13
7. Error Handling .................................................13
8. Specification of Protocol Fields ...............................16
8.1. The Flags, Message Length, and Integrity Checksum
Data Fields ...............................................17
8.2. EAP-IKEv2 Header ..........................................19
8.3. Security Association Payload ..............................19
8.4. Key Exchange Payload ......................................20
8.5. Nonce Payload .............................................20
8.6. Identification Payload ....................................20
8.7. Certificate Payload .......................................20
8.8. Certificate Request Payload ...............................20
8.9. Encrypted Payload .........................................20
8.10. Authentication Payload ...................................20
8.11. Notify Payload ...........................................21
8.12. Next Fast-ID Payload .....................................21
9. Payload Types and Extensibility ................................22
10. Security Considerations .......................................22
10.1. Protected Ciphersuite Negotiation ........................23
10.2. Mutual Authentication ....................................23
10.3. Integrity Protection .....................................23
10.4. Replay Protection ........................................23
10.5. Confidentiality ..........................................23
10.6. Key Strength .............................................24
10.7. Dictionary Attack Resistance .............................24
10.8. Fast Reconnect ...........................................25
10.9. Cryptographic Binding ....................................25
10.10. Session Independence ....................................25
10.11. Fragmentation ...........................................26
10.12. Channel Binding .........................................26
10.13. Summary .................................................26
11. IANA Considerations ...........................................27
12. Contributors ..................................................28
13. Acknowledgements ..............................................28
14. References ....................................................29
14.1. Normative References .....................................29
14.2. Informative References ...................................29
Appendix A ........................................................30
This document specifies EAP-IKEv2, an EAP method that is based on the Internet Key Exchange Protocol version 2 (IKEv2) [1]. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on the following types of credentials:
この文書では、EAP-IKEv2の、インターネット鍵交換プロトコルバージョン2（IKEv2の）[1]に基づいているEAP方式を指定します。 EAP-のIKEv2は、EAPピアとEAPサーバとの間の相互認証およびセッション鍵の確立を提供します。これは、資格証明書の次のタイプに基づいて認証技術をサポートしています。
o Asymmetric key pairs: these are public/private key pairs where the public key is embedded into a digital certificate, and the corresponding private key is known only to a single party.
非対称鍵ペアO：これらは、公開鍵は、デジタル証明書の中に埋め込まれている公開鍵/秘密鍵のペアがあり、対応する秘密鍵は、単一の当事者に知られています。
o Passwords: these are low-entropy bit strings that are known to both the server and the peer.
Oパスワード：これらはサーバとピアの両方に知られている低エントロピービット列です。
o Symmetric keys: these are high-entropy bit strings that are known to both the server and the peer.
対称キーO：これらはサーバとピアの両方に知られており、高エントロピーのビットストリングです。
It is possible to use a different authentication credential (and thereby technique) for each direction, e.g., the EAP server may authenticate itself using a public/private key pair and the EAP client may authenticate itself using a symmetric key. In particular, the following combinations are expected to be used in practice; these are referred to as "use cases" or "modes" in the remainder of this document:
例えば、EAPサーバは、公開鍵/秘密鍵のペアを使用して自身を認証することができ、EAPクライアントは対称鍵を使用して自身を認証することができる、それぞれの方向に異なる認証証明書（および、それによって技術）を使用することが可能です。具体的には、以下の組み合わせが実際に使用されることが期待されます。これらは、「ユースケース」、またはこの文書の残りで「モード」と呼ばれます。
Note that in use cases 2 and 4, a symmetric key is assumed to be chosen uniformly at random from its key space; it is therefore assumed that symmetric keys are not derived from passwords. Deriving a symmetric key from a password is insecure when used with mode 4 since the exchange is vulnerable to dictionary attacks, as described in more detail in Section 10.7. Also note that in use case 3, the EAP server must either have access to all passwords in plaintext, or, alternatively, for each password store, the value prf(password,"Key Pad for EAP-IKEv2") for all supported pseudorandom functions (also see Section 8.10 below and Section 2.15 of [1]). Other conceivable use cases are not expected to be used in practice due to key management issues, and have not been considered in this document.
ユースケース2及び4に、対称鍵は、その鍵空間から一様にランダムに選択されることを想定していることに留意されたいです。それゆえ、対称鍵はパスワードから導出されていないことが想定されます。交換は辞書攻撃に対して脆弱であるため、セクション10.7でより詳細に説明するように、モード4を使用した場合、パスワードから対称鍵を導出することは安全ではありません。また、ユースケース3には、EAPサーバは、各パスワード・ストアのため、代わりに、すべてのサポートされている擬似乱数関数の値のPRF（パスワード、「EAP-IKEv2のためのキーパッド」）を平文ですべてのパスワードへのアクセス権を持っている、またはしなければならないのいずれかのことに注意してください（下記セクション8.10と[1]のセクション2.15を参照）。その他考えられる使用事例は、鍵管理問題のため、実際に使用されることが期待されていない、と本書では考慮されていません。
Note that the IKEv2 protocol is able to carry EAP exchanges. By contrast, EAP-IKEv2 does not inherit this capability. That is, it is not possible to tunnel EAP methods inside EAP-IKEv2. Also note that the set of functionality provided by EAP-IKEv2 is similar, but not identical, to that provided by other EAP methods such as, for example, EAP-TLS [6].
IKEv2プロトコルはEAP交換を実行することができることに留意されたいです。これとは対照的に、EAP-IKEv2のはこの機能を継承しません。つまり、EAP-IKEv2の内部トンネルEAPメソッドには不可能です。また、EAP-のIKEv2によって提供される機能のセットは、例えば、などの他のEAPメソッドによって提供されるものと、同様の、しかし同一ではないことに注意して、EAP-TLS [6]。
The remainder of this document is structured as follows:
このドキュメントの残りは以下の通り構成されています。
o Section 2 provides an overview of the terminology and the abbreviations used in this document.
O部2は、用語の概要と、この文書で使用された略語を提供します。
o Section 3 provides an overview of the full EAP-IKEv2 exchange and thereby specifies the protocol message composition.
O部3は、完全なEAP-のIKEv2交換の概要を提供し、それによってプロトコルメッセージの構成を指定します。
o Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode of operation.
O部4は、操作のオプションのEAP-IKEv2の「高速再接続」モードを指定します。
o Section 5 specifies how exportable session keys are derived.
O部5は、エクスポートセッションキーが導出されている方法を指定します。
o Section 6 specifies how the Session-ID, Peer-ID, and Server-ID elements are derived.
O部6は、セッションID、ピアID、およびサーバIDの要素が導出されている方法を指定します。
o Section 7 specifies how errors that may potentially occur during protocol execution are handled.
O部7は、潜在的プロトコルの実行中に発生するエラーの処理方法を指定します。
o Section 8 specifies the format of the EAP-IKEv2 data fields. Section 8.1 describes how fragmentation is handled in EAP-IKEv2.
O部8は、EAP-IKEv2のデータフィールドのフォーマットを指定します。 8.1節では、断片化がEAP-IKEv2の中でどのように扱われるかを説明します。
o Section 9 specifies the payload type values and describes protocol extensibility.
O部9は、ペイロードタイプ値を指定し、プロトコルの拡張を記述しています。
o Section 10 provides a list of claimed security properties.
O部10は、特許請求のセキュリティプロパティのリストを提供します。
This document makes use of terms defined in [2] and [1]. In addition, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [3].
この文書は、で定義された用語を使用する[2]、[1]。また、キーワードは、必要ではないしなければならないしなければならない、、、、推奨すべきでないないものSHALL、MAY、およびOPTIONAL、それらは本文書に現れる場合、に記載されているように解釈されるべきである[3]。
A list of abbreviations that are used in this document follows.
このドキュメントで使用されている略語のリストを以下に示します。
AUTH:
AUTH：
Denotes a data field containing either a Message Authentication Code (MAC) or a signature. This field is embedded into an Authentication payload, defined in Section 8.10.
メッセージ認証コード（MAC）または署名のいずれかを含むデータフィールドを表します。このフィールドは、セクション8.10で定義され、認証ペイロードに埋め込まれます。
CERT:
TRUE：
Public key certificate or similar structure.
公開鍵証明書または類似の構造。
CERTREQ:
CERTREQ：
Certificate Request.
証明書要求。
NFID:
NFID：
Next Fast-ID payload (see Sections 4 and 8.12)
次の高速IDペイロード（セクション4および8.12を参照のこと）
EMSK:
EMSK：
Extended Master Session Key, defined in [2].
で定義された拡張マスターセッションキー、[2]。
HDR:
HDR：
EAP-IKEv2 header, defined in Section 8.2.
セクション8.2で定義されたEAP-のIKEv2ヘッダ、。
I:
私：
Initiator, the party that sends the first message of an EAP-IKEv2 protocol run. This is always the EAP server.
イニシエータ、EAP-IKEv2のプロトコルの実行の最初のメッセージを送信パーティー。これは、常にEAPサーバです。
MAC:
マック：
Message Authentication Code. The result of a cryptographic operation that involves a symmetric key.
メッセージ認証コード。対称鍵を必要とする暗号演算の結果。
MSK:
MSK：
Master Session Key, defined in [2].
で定義されたマスターセッションキー、[2]。
prf:
PRF：
Pseudorandom function: a cryptographic function whose output is assumed to be indistinguishable from that of a truly random function.
擬似ランダム関数：その出力は真にランダム関数と区別できないことが想定される暗号化関数。
R:
R：
Responder, the party that sends the second message of an EAP-IKEv2 protocol run. This is always the EAP peer.
レスポンダ、EAP-IKEv2のプロトコル実行の第2のメッセージを送信しますパーティー。これは、常にEAPピアです。
SA:
さ：
Security Association. In this document, SA denotes a type of payload that is used for the negotiation of the cryptographic algorithms that are to be used within an EAP-IKEv2 protocol run. Specifically, SAi denotes a set of choices that are accepted by an initiator, and SAr denotes the choice of the responder.
セキュリティアソシエーション。この文書では、SAは、EAP-のIKEv2プロトコルラン内で使用される暗号アルゴリズムのネゴシエーションに使用されているペイロードのタイプを示します。具体的には、サイイニシエータによって受け入れられる選択肢の集合を表し、SARはレスポンダの選択を表します。
Signature:
署名：
The result of a cryptographic operation that involves an asymmetric key. In particular, it involves the private part of a public/private key pair.
非対称鍵を必要とする暗号演算の結果。特に、それは、公開鍵/秘密鍵のペアの秘密の部分を含んでいます。
SK:
SK：
Session Key. In this document, the notation SK{x} denotes that x is embedded within an Encrypted payload, i.e., that x is encrypted and integrity-protected using EAP-IKEv2 internal keys. These keys are different in each direction.
セッションキー。この文書では、SKは、{x}はxが暗号化されたペイロード内に埋め込まれていることを示す表記は、すなわち、そのXは暗号化と完全性保護EAP-IKEv2の内部キーを使用しています。これらのキーは、各方向で異なっています。
SK_xx:
SK_xx：
EAP-IKEv2 internal key, defined in Section 2.14 of [1].
[1]のセクション2.14で定義されたEAP-IKEv2の内部キー、。
SKEYSEED:
SKEYSEED：
Keying material, defined in Section 2.14 of [1].
[1]のセクション2.14で定義された材料を、キーイング。
In this section, the full EAP-IKEv2 protocol run is specified. All messages are sent between two parties, namely an EAP peer and an EAP server. In EAP-IKEv2, the EAP server always assumes the role of the initiator (I), and the EAP peer that of the responder (R) of an exchange.
このセクションでは、完全なEAP-IKEv2のプロトコルの実行が指定されています。すべてのメッセージは両当事者、すなわち、EAPピアとEAPサーバの間で送信されます。 EAP-のIKEv2では、EAPサーバは常に交換の応答者（R）のことをイニシエータ（I）の役割、及びEAPピアを想定しています。
The semantics and formats of EAP-IKEv2 messages are similar, albeit not identical, to those specified in IKEv2 [1] for the establishment of an IKE Security Association. The full EAP-IKEv2 protocol run consists of two roundtrips that are followed by either an EAP-Success or an EAP-Failure message. An optional roundtrip for exchanging EAP identities may precede the two exchanges.
IKEセキュリティアソシエーションを確立するためのIKEv2 [1]で指定されたものと、同一ではないもののEAP-のIKEv2メッセージの意味とフォーマットは、同様です。フルEAP-IKEv2のプロトコルの実行には、EAP-成功またはEAP-失敗メッセージのいずれかが続いている2回のラウンドトリップで構成されています。 EAPアイデンティティを交換するための任意選択のラウンドトリップは、二つの交換に先行してもよいです。
Figure 1: EAP-IKEv2 Full, Successful Protocol Run
図1：EAP-IKEv2の完全な、成功したプロトコルの実行
Figure 1 shows the full EAP-IKEv2 protocol run, including the optional EAP identity exchange (messages 1 and 2). A detailed specification of the message composition follows.
図1は、オプションのEAPアイデンティティ交換（メッセージ1及び2）を含む、完全なEAP-のIKEv2プロトコルの実行を示しています。メッセージ構成の詳細な仕様は以下の通りです。
Messages 1 and 2 are a standard EAP Identity Request and Response, as defined in [2]. Message 3 is the first EAP-IKEv2-specific message. With this, the server starts the actual EAP authentication exchange. It contains the initiator Security Parameter Index (SPI) in the EAP-IKEv2 header (HDR) (the initiator selects a new SPI for each protocol run), the set of cryptographic algorithms the server is willing to accept for the protection of EAP-IKEv2 traffic (encryption and integrity protection), and the derivation of the session key. This set is encoded in the Security Association payload (SAi). It also contains a Diffie-Hellman payload (KEi), and a Nonce payload (Ni).
[2]で定義されるようにメッセージ1及び2は、標準のEAPアイデンティティリクエストとレスポンスです。メッセージ3は、第1のEAP-IKEv2の固有のメッセージです。これにより、サーバは、実際のEAP認証交換を開始します。それは、イニシエータEAP-IKEv2のヘッダ（HDR）でセキュリティパラメータインデックス（SPI）を（イニシエータは、各プロトコルの実行のために新しいSPIを選択）が含まれ、暗号アルゴリズムのセットサーバがEAP-IKEv2の保護のために受け入れることを望んでいますトラフィック（暗号化および完全性保護）、およびセッションキーの導出。このセットは、セキュリティアソシエーションペイロード（SAiの）でエンコードされています。それはまたのDiffie-Hellmanペイロード（たKEi）、およびノンスペイロードニッケル（Ni）を含みます。
When the peer receives message 3, it selects a set of cryptographic algorithms from the ones that are proposed in the message. In this overview, it is assumed that an acceptable such set exists (and is thus selected), and that the Diffie-Hellman value KEi belongs to an acceptable group. The peer then generates a non-zero Responder SPI value for this protocol run, its own Diffie-Hellman value (KEr) and nonce (Nr), and calculates the keys SKEYSEED, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, according to Section 2.14 of [1]. The peer then constructs message 4. In the context of use cases 1, 2, and 3, the peer's local policy MAY dictate the inclusion of the optional CERTREQ payload in that message, which gives a hint to the server to include a certificate for its public key in its next message. In the context of use case 4, the peer MUST include the optional SK{IDr} payload, which contains its EAP-IKEv2 identifier, encrypted and integrity-protected within an Encrypted payload. The keys used to construct this Encrypted payload are SK_er (for encryption) and SK_ar (for integrity protection), in accordance with
ピアがメッセージ3を受信すると、メッセージ内に提案されているものから暗号アルゴリズムのセットを選択します。この概要では、許容されるようなセットが存在する（従って、選択された）と仮定され、そしてのDiffie-Hellman値たKEiは、許容可能なグループに属していること。ピアは、このプロトコルの実行、独自のDiffie-Hellman値（KER）およびナンス（NR）のための非ゼロレスポンダSPI値を生成し、キーSKEYSEED、SK_d、SK_ai、SK_ar、SK_ei、SK_、えー、SK_piを計算し、そして[1]のセクション2.14に記載SK_pr、。ピアは、その後、ユースケース1の文脈においてメッセージ4を構築2、及び図3を参照すると、ピアのローカルポリシーは、そのための証明書を含むようにサーバにヒントを与えることメッセージ内のオプションCERTREQペイロードを含めることを決定し得ますその次のメッセージで公開鍵。ユースケース4の文脈では、ピアは、暗号化されたペイロード内の暗号化および完全性保護、そのEAP-IKEv2の識別子を含む任意SK {IDR}ペイロードを含まなければなりません。この暗号化されたペイロードを構築するために使用されるキーは、に従って、（暗号化用）SK_、えーとSK_ar（完全性保護のために）しています
[1]. The responder's EAP-IKEv2 identifier (IDr) is likely to be needed in these use cases by the server in order to select the correct symmetric key or password for the construction of the AUTH payload of message 5.
[1]。応答者のEAP-IKEv2の識別子（IDR）は、メッセージ5のAUTHペイロードを構築するための正しい対称鍵やパスワードを選択するために、サーバーによってこれらのユースケースで必要とされる可能性があります。
Upon reception of message 4, the server also computes SKEYSEED, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, according to Section 2.14 of [1]. If an SK{IDr} payload is included, the server decrypts it and verifies its integrity with the corresponding keys. In this overview, decryption and verification is assumed to succeed. The server then constructs message 5, which contains only the EAP-IKEv2 header followed by a single Encrypted payload. The keys used to generate the encrypted payload MUST be SK_ei (for encryption) and SK_ai (for integrity protection), in accordance with [1]. The initiator MUST embed at least two payloads in the Encrypted Payload, as follows. An Identification payload with the initiator's EAP-IKEv2 identifier MUST be embedded in the Encrypted payload. The Authentication payload MUST be embedded in the Encrypted payload. A Certificate payload, and/or a Certificate Request payload, MAY also be embedded in the Encrypted payload. Moreover, a Next Fast-Reconnect Identifier payload MAY also be embedded in the Encrypted payload. Message 5 is sent to the responder.
メッセージ4を受信すると、サーバは、[1]のセクション2.14によれば、SKEYSEED、SK_d、SK_ai、SK_ar、SK_ei、SK_、えー、SK_pi、及びSK_prを計算します。 SK {IDR}ペイロードが含まれている場合、サーバはそれを復号化し、対応するキーとの整合性を検証します。この概要では、復号化および検証が成功すると想定されます。次に、サーバは、単一の暗号化されたペイロードが続くEAP-のIKEv2ヘッダを含むメッセージ5を構成します。暗号化されたペイロードを生成するために使用されるキーは、[1]に応じて、（暗号化）SK_eiとSK_ai（完全性保護のため）でなければなりません。次のように開始剤は、暗号化されたペイロード内の少なくとも2つのペイロードを埋め込む必要があります。イニシエータのEAP-IKEv2の識別子と識別ペイロードが暗号化されたペイロードに埋め込まれなければなりません。認証ペイロードは暗号化されたペイロードに埋め込まれなければなりません。証明書ペイロード、および/または証明書要求ペイロードは、また、暗号化されたペイロードに埋め込まれていてもよいです。また、次の速い再接続識別子ペイロードは、暗号化ペイロードに埋め込んでもよいです。メッセージ5は、レスポンダに送信されます。
Upon reception of message 5, the responder (EAP peer) authenticates the initiator (EAP server). The checks that are performed to this end depend on the use case, local policies, and are specified in [1]. These checks include (but may not be limited to) decrypting the Encrypted payload, verifying its integrity, and checking that the Authentication payload contains the expected value. If all checks succeed (which is assumed in this overview), then the responder constructs message 6. That message MUST contain the EAP-IKEv2 header followed by a single Encrypted payload, in which at least two further payloads MUST be embedded, as shown in Figure 1.
メッセージ5を受信すると、応答（EAPピアは）開始剤（EAPサーバ）を認証します。この目的のために実行されるチェックは、ユースケース、ローカルポリシーに依存して、[1]で指定されています。これらのチェックは、（それだけには限定されない）、暗号化されたペイロードを解読その完全性を検証し、認証ペイロードが期待値が含まれていることをチェックします。すべてのチェックが（この概要に想定される）成功した場合に示されるように、次いでレスポンダは、少なくとも2つの別のペイロードが埋め込まれなければならない単一の暗号化されたペイロードが続くEAP-IKEv2のヘッダを含んでいなければならないことメッセージ6.メッセージを構築します図1。
Upon reception of message 6, the initiator (EAP server) authenticates the responder (EAP peer). As above, the checks that are performed to this end depend on the use case, local policies, and MUST include decryption and verification of the Encrypted payload, as well as checking that the Authentication payload contains the expected value. If the optional SK{IDr} payload was included in message 4, the EAP server MUST also ensure that the IDr payload in message 6 is identical to that in message 4.
メッセージ6を受信すると、イニシエータ（EAPサーバ）がレスポンダ（EAPピア）を認証します。上記のように、この目的のために実行されるチェックは、ユースケース、ローカルポリシーに依存し、復号及び暗号化されたペイロードの検証、ならびに認証・ペイロードが期待値が含まれていることを確認を含まなければなりません。任意SK {IDR}ペイロードをメッセージ4に含まれていた場合、EAPサーバは、メッセージ6でIDRペイロードはメッセージ4のものと同一であることを確認しなければなりません。
If authentication succeeds, an EAP-Success message is sent to the responder as message 7. The EAP server and the EAP peer generate a Master Session Key (MSK) and an Extended Master Session Key (EMSK) after a successful EAP-IKEv2 protocol run, according to Section 5.
認証が成功した場合、EAP-Successメッセージは、EAPサーバ7.メッセージとして応答者に送信され、EAPは、成功したEAP-IKEv2のプロトコルの実行後にマスターセッションキー（MSK）および拡張マスターセッションキー（EMSK）を生成するピアであります、第5節によります。
This section specifies a "fast reconnect" mode of operation for EAP-IKEv2. This mode is mandatory to implement, but optional to use. The purpose of fast reconnect is to enable an efficient re-authentication procedure that also results in a fresh MSK and EMSK. The "fast reconnect" mode can only be used where an EAP-IKEv2 security context already exists at both the server and the peer, and its usage is subject to the local policies. In other words, it can only be used by an EAP server/EAP peer pair that has already performed mutual authentication in a previous EAP-IKEv2 protocol run.
このセクションでは、EAP-IKEv2のための動作の「高速再接続」モードを指定します。このモードでは、実装するために義務はなく、使用するオプションです。高速再接続の目的はまた、新鮮なMSKとEMSKになり、効率的な再認証手順を有効にすることです。 EAP-のIKEv2セキュリティコンテキストが既にサーバとピアの両方に存在し、その使用がローカルポリシーの対象である「高速再接続」モードのみを使用することができます。換言すれば、それだけで既に、以前のEAP-のIKEv2プロトコル実行で相互認証を行ったEAPサーバ/ EAPピア対で使用することができます。
The fast reconnect mode makes use of dedicated "fast reconnect EAP identifiers". The idea is that the server indicates its willingness to engage in "fast reconnect" protocol runs in the future by including the optional "Next Fast-ID" (NFID) payload in message 5 of a "full" protocol run (see Figure 1), or in message 3 of a "fast reconnect" protocol run (see Figure 2). This NFID payload contains a special EAP identity, denoted Fast Reconnect Identity (FRID) as the Network Access Identifier (NAI) in the EAP-Response/Identity message. The FRID contains an obfuscated username part and a realm part. When generating a FRID, the following aspects should be considered:
高速再接続モードは、専用の「高速再接続EAP識別子」を利用します。アイデアは、サーバが「高速再接続」プロトコルは、オプションの「次の速い-ID」「フル」プロトコルの実行のメッセージ5（NFID）ペイロード（図1参照）を含むことにより、将来的に実行に関与するという意思を示すことです、または「高速再接続」プロトコルの実行のメッセージ3（図2参照）。このNFIDペイロードは、EAP-Response / Identityメッセージでのネットワークアクセス識別子（NAI）などの特殊なEAPアイデンティティ、高速再接続アイデンティティ（FRID）で示さが含まれています。 FRIDは、難読化されたユーザー名の一部とレルム部分が含まれています。 FRIDを生成する場合、以下の点を考慮する必要があります。
The FRID and therefore the pseudonym usernames are generated by the EAP server. The EAP server produces pseudonym usernames in an implementation-dependent manner. Only the EAP server needs to be able to map the pseudonym username to the permanent identity.
FRIDため、匿名ユーザ名は、EAPサーバによって生成されます。 EAPサーバは実装依存的に匿名ユーザ名を生成します。唯一のEAPサーバが永久的なアイデンティティへの匿名ユーザ名をマッピングできるようにする必要があります。
EAP-IKEv2 includes no provisions to ensure that the same EAP server that generated a pseudonym username will be used on the authentication exchange when the pseudonym username is used. It is recommended that the EAP servers implement some centralized mechanism to allow all EAP servers of the home operator to map pseudonyms generated by other severs to the permanent identity. If no such mechanism is available, then the EAP server, failing to understand a pseudonym issued by another server, can request the peer to send the permanent identity.
EAP-IKEv2のは、匿名ユーザ名を使用する場合は匿名ユーザ名を生成し、同じEAPサーバが認証交換に使用されることを保証するために、何の条項が含まれていません。 EAPサーバがホームオペレータのすべてのEAPサーバが永久的なアイデンティティに他の切断によって生成された仮名をマッピングできるようにするために、いくつかの集中管理メカニズムを実装することをお勧めします。そのようなメカニズムが利用できない場合は、EAPサーバは、別のサーバによって発行された仮名を理解するために失敗し、永久的なアイデンティティを送信するためにピアを要求することができます。
When generating FRIDs, the server SHOULD choose a fresh and unique FRID that is different from the previous ones that were used after the same full authentication exchange. The FRID SHOULD include a random component in the username part. The random component works as a reference to the security context. Regardless of the construction method, the pseudonym username MUST conform to the grammar specified for the username portion of an NAI. Also, the FRID MUST conform to the NAI grammar [4]. The EAP servers, which subscribers of an operator can use, MUST ensure that the username part of a FRIDs that they generate are unique.
FRIDsを生成する場合、サーバーは同じ完全な認証交換の後に使用された前のものとは異なり、新鮮でユニークなFRIDを選択する必要があります。 FRIDは、ユーザー名の一部でランダム成分を含むべきです。ランダム成分は、セキュリティコンテキストへの参照として機能します。かかわらず、施工方法の、匿名ユーザ名はNAIのユーザ名部分に指定された文法に従わなければなりません。また、FRID [4] NAI文法に従わなければなりません。オペレータの加入者が使用できるEAPサーバは、それらが生成FRIDsのユーザ名部分が一意であることを保証しなければなりません。
The peer MAY use the FRID to indicate to start a "fast reconnect" protocol run. The EAP Identity Response MUST be sent at the beginning of a "fast reconnect" protocol run. If, in the previous successful "full" (resp. "fast reconnect") EAP-IKEv2 protocol execution, the server had not included an NFID payload in message 5 (resp. 3), then the peer MUST NOT start a fast reconnect protocol run. On reception of FRID, the server maps it to an existing EAP-IKEv2 security context. Depending on local policy, the server either proceeds with the "fast reconnect" protocol run, or proceeds with message 3 of a "full" protocol run. If the server had advertised the FRID in the previous EAP-IKEv2 protocol execution, it SHOULD proceed with a "fast reconnect" protocol run. The peer MUST be able to correctly handle a message 3 of a "full" protocol run, even if it indicated a FRID in its EAP Identity Response.
ピアは、「高速再接続」プロトコルの実行を開始することを示すために、FRIDを使用するかもしれません。 EAPアイデンティティ応答は、「高速再接続」プロトコルの実行の開始時に送らなければなりません。 、前回成功した「フル」に（それぞれ、「高速再接続」）EAP-IKEv2のプロトコルの実行、サーバはメッセージ5（それぞれ3）でNFIDペイロードが含まれていなかった場合、ピアは高速再接続プロトコルを開始してはなりません実行します。 FRIDを受信すると、サーバーは既存のEAP-IKEv2のセキュリティコンテキストにマップします。ローカルポリシーに応じて、サーバが「高速再接続」プロトコルの実行、または「フル」プロトコルの実行のメッセージ3で進行して進めるのいずれか。サーバは、前のEAP-IKEv2のプロトコル実行でFRIDを宣伝していた場合、それは「高速再接続」プロトコルの実行を進めるべきです。ピアは、そのEAPアイデンティティ応答でFRIDを示していても、正しく「完全な」プロトコルの実行のメッセージ3を扱うことができなければなりません。
Because the peer may fail to save a FRID that was sent in the NFID payload (for example, due to malfunction), the EAP server SHOULD maintain, at least, the most recently used FRID in addition to the most recently issued FRID. If the authentication exchange is not completed successfully, then the server MUST NOT overwrite the FRID that was issued during the most recent successful authentication exchange.
ピアが（誤動作に、例えば）NFIDペイロードで送信されたFRIDを保存するために失敗することがありますので、EAPサーバは、少なくとも、最も最近発行されたFRIDに加えて、最近使用しFRIDを維持する必要があります。認証交換が正常に完了していない場合、サーバーは、最新の成功した認証交換の際に発行されたFRIDを上書きしてはなりません。
The EAP-IKEv2 fast reconnect exchange is similar to the IKE-SA rekeying procedure, as specified in Section 2.18 of [1]. Thus, it uses a CREATE_CHILD_SA request and response. The SPIs on those two messages would be the SPIs negotiated on the previous exchange. During fast reconnect, the server and the peer MAY exchange fresh Diffie-Hellman values.
EAP-IKEv2の高速再接続交換は、[1]のセクション2.18で指定されるように、IKE-SAのリキー手順と同様です。したがって、それはCREATE_CHILD_SA要求と応答を使用しています。これら二つのメッセージ上のSPIは、前の交換に交渉さのSPIだろう。高速再接続時には、サーバーおよびピアは新鮮なのDiffie-Hellman値を交換してもよいです。
Figure 2: Fast Reconnect Protocol Run
図2：高速再接続プロトコルを実行します
Figure 2 shows the message exchange for the EAP-IKEv2 fast reconnect mode. As in the full mode, the EAP server is the initiator and the EAP peer is the responder. The first two messages constitute the standard EAP identity exchange. Note that, in order to use the "fast reconnect" mode, message 2 MUST be sent. This is in order to enable the peer to indicate its "fast reconnect" identity FRID in message 2.
図2は、EAP-IKEv2の高速再接続モードのためのメッセージ交換を示しています。フルモードのように、EAPサーバが開始され、EAPピアは応答です。最初の2件のメッセージが標準のEAPアイデンティティ交換を構成します。 「高速再接続」モードを使用するためには、メッセージ2を送らなければならない、ということに注意してください。これは、メッセージ2にその「高速再接続」アイデンティティFRIDを示すためにピアを有効にするためにあります。
If the server can map the FRID to an existing EAP-IKEv2 context it proceeds with message 3. Note that, in this message, the server MAY embed an NFID payload into the encrypted payload to provide a new FRID to the peer. The server MAY choose to perform a full EAP-IKEv2 run, in which case, it would respond with a message that conforms to the format of message 3 in Figure 1.
サーバーは、このメッセージでは、サーバは、ピアへの新しいFRIDを提供するために、暗号化されたペイロードにNFIDペイロードを埋め込むことが、メッセージ3.注意して進める既存のEAP-IKEv2のコンテキストにFRIDをマッピングすることができます。サーバは、その場合、それは図1のメッセージ3のフォーマットに準拠したメッセージで応答する、完全なEAP-のIKEv2ランを実行するために選ぶかもしれ。
Messages 3 and 4 establish a new EAP-IKEv2 security context. In message 3, the initiator MUST select a new (non-zero) value for the SPI field in each proposal substructure in the SA payload (see Section 3.3 of [1]). The value of the IKE_SA Responder's SPI field in HDR MUST be the one from the previous successful EAP-IKEv2 protocol run. The nonce inside the Nonce payload (Ni) MUST be fresh, and the Diffie-Hellman value inside the Diffie-Hellman payload (if present, KEi) MUST also be fresh. If present, the Diffie-Hellman value MUST be drawn from the same group as the Diffie-Hellman value in the previous successful full EAP-IKEv2 protocol run. Note that the algorithms and keys that are used to construct the Encrypted payload in message 3 are the same as in the previous successful EAP-IKEv2 protocol run.
メッセージ3と4は、新しいEAP-IKEv2のセキュリティコンテキストを確立します。メッセージ3では、イニシエータは、（[1]のセクション3.3を参照）SAペイロード中の各提案下部にSPIフィールドのための新しい（非ゼロ）値を選択しなければなりません。 HDRでIKE_SAレスポンダのSPIフィールドの値は、前回成功したEAP-IKEv2のプロトコルの実行から1でなければなりません。ノンス、ペイロード（Ni）の内部ナンスは新鮮でなければなりません、とのDiffie-Hellmanペイロード（存在する場合啓）内部のDiffie-Hellman値も新鮮でなければなりません。存在する場合、のDiffie-Hellman値は、前の成功した完全なEAP-のIKEv2プロトコル実行でのDiffie-Hellman値と同じグループから引き出されなければなりません。メッセージ3の暗号化されたペイロードを構築するために使用されるアルゴリズムと鍵は、以前成功したEAP-のIKEv2プロトコルの実行と同じであることに留意されたいです。
Upon reception of message 3, the responder (EAP peer) decrypts and verifies the Encrypted payload. If successful (as assumed in Figure 2), it constructs message 4 in a fashion similar to the construction of message 3. The responder MUST choose a new (non-zero) value for the SPI field in each proposal substructure. Upon reception of message 4, the initiator (EAP server) decrypts and verifies the Encrypted payload. If a correct message 4 is received, then this protocol run is deemed successful, and the server responds with an EAP-Success message (message 5).
メッセージ3を受信すると、応答（EAPピア）を復号化し、暗号化されたペイロードを検証します。 （図2で想定されるように）成功した場合は、応答者がそれぞれ提案下部にSPIフィールドのための新しい（非ゼロ）の値を選択する必要があり、メッセージ3の構成と同様の方法でメッセージ4を構成します。メッセージ4を受信すると、イニシエータ（EAPサーバ）は、復号化および暗号化されたペイロードを検証します。正しいメッセージ4を受信した場合、このプロトコルの実行が成功したとみなされ、サーバは、EAP-Successメッセージ（メッセージ5）で応答します。
After successful EAP-IKEv2 fast reconnect protocol run, both the initiator and the responder generate fresh keying material that is used for the protection of subsequent EAP-IKEv2 traffic. Furthermore, both the initiator and the responder MUST generate a fresh MSK and EMSK and export them.
成功したEAP-IKEv2の高速再接続プロトコルの実行後、イニシエータとレスポンダの両方が、その後のEAP-IKEv2のトラフィックの保護のために使用された新鮮な鍵素材を生成します。さらに、イニシエータとレスポンダの両方が新鮮MSKとEMSKを生成し、それらをエクスポートする必要があります。
The new EAP-IKEv2-specific keying material is computed in the same way as in the full EAP-IKEv2 protocol run, and in accordance with Section 2.18 of [1]. That is, SKEYSEED is computed as SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr), where SK_d (old) is the key SK_d from the previous successful EAP-IKEv2 protocol run, Ni and Nr are the nonces (without the Nonce payload headers) that were exchanged in messages 3 and 4, and g^ir (new) is the newly computed Diffie-Hellman key, if both the values KEi and KEr were present in messages 3 and 4. The remaining EAP-IKEv2-specific keys (SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr) are generated as in the full EAP-IKEv2 protocol run.
新しいEAP-IKEv2の固有鍵材料は、完全EAP-のIKEv2プロトコルの実行と同様に計算され、[1]のセクション2.18に従います。これは、SKEYSEEDはSKEYSEED = PRFとして計算される（SK_d（旧）、[G ^ IR（新しい）] |ニッケル| NR）（旧）SK_dは前回成功したEAP-IKEv2のプロトコルの実行、ニッケルからキーSK_dです、値たKEiとKER両方がメッセージ3に存在した場合、Nrがメッセージ3および4に交換した（ノンスペイロードヘッダなし）ナンスであり、G ^ IR（新しい）が新たに計算されたのDiffie-Hellman鍵であると4.残りのEAP-IKEv2の固有キー（SK_d、SK_ai、SK_ar、SK_ei、SK_、えー、SK_pi、及びSK_pr）は、完全なEAP-のIKEv2プロトコルランのように生成されます。
The generation of a fresh MSK and EMSK follows the generation of the EAP-IKEv2-specific keys and adheres to the rules in Section 5.
新鮮MSK及びEMSKの生成はEAP-IKEv2の固有鍵の生成に続き、第5の規則に準拠します。
Note 1: In EAP-IKEv2, the EAP server initiates the fast reconnect mode and thereby causes fresh session keys to be established.
注1：EAP-IKEv2のでは、EAPサーバは、高速再接続モードを開始し、それによって確立される新鮮なセッションキーを発生します。
Note 2: It is conceivable that an adversary tries to launch a replay attack against the EAP-IKEv2 fast reconnect mode of operation. In particular, the adversary may try to send a previously captured message 3 in a subsequent fast reconnect protocol run. This replay attempt will, however, fail because the keys that the responder will use to verify and decrypt the Encrypted payload are changed with every successful reconnect protocol run.
注2：敵対者は、操作のEAP-IKEv2の高速再接続モードに対するリプレイ攻撃を開始しようとすることが考えられます。具体的には、敵は、後続の高速再接続プロトコル実行で以前に捕捉されたメッセージ3を送信することを試みることができます。応答者が確認し、暗号化されたペイロードを復号化するために使用するキーが成功するたびに再接続プロトコルの実行で変更されているので、このリプレイの試みは、しかし、失敗します。
This section describes how the Master Session Key (MSK) and the Extended Master Session Key (EMSK) are derived in EAP-IKEv2. It is expected that the MSK and the EMSK are exported by the EAP-IKEv2 process and be used in accordance with the EAP keying framework [7].
このセクションでは、マスターセッションキー（MSK）および拡張マスターセッションキー（EMSK）はEAP-IKEv2の中で派生する方法を説明します。 MSKおよびEMSKをEAP-IKEv2のプロセスによってエクスポートされ、EAPキーイング・フレームワークに従って使用されることが期待されている[7]。
During an EAP-IKEv2 protocol run, the initiator and the responder generate a number of keys, as described above and in accordance with Section 2.14 of [1]. The generation of these keys is based on a pseudorandom function (prf) that both parties have agreed to use and that is applied in an iterative fashion. This iterative fashion is specified in Section 2.13 of [1] and is denoted by prf+.
上記および[1]のセクション2.14に合わせて記載したようにEAP-のIKEv2プロトコルの実行中に、イニシエータとレスポンダは、キーの数を生成します。これらのキーの生成は、両当事者が使用することに合意したとそれは、反復方式で適用されていることを擬似ランダム機能（PRF）に基づいています。この反復態様[1]のセクション2.13で指定され、PRFの+で示しています。
In particular, following a successful EAP-IKEv2 protocol run, both parties generate 128 octets of keying material, denoted KEYMAT, as KEYMAT = prf+(SK_d, Ni | Nr), where Ni and Nr are the nonces (just payload without headers) from messages 3 and 4 shown in Figure 1 (in the context of a full EAP-IKEv2 protocol run) or Figure 2 (in the context of a fast reconnect EAP-IKEv2 protocol run). Note that only the nonces are used, i.e., not the entire Nonce payload that contains them.
NiとNrがノンス（ヘッダなしでちょうどペイロード）である、から|特に、成功したEAP-のIKEv2プロトコルの実行後に、両当事者はKEYMAT = PRF +（NR SK_d、Ni）のような鍵材料、示さKEYMAT、128個のオクテットを生成します（高速再接続EAP-のIKEv2プロトコル実行のコンテキストで）（完全なEAP-のIKEv2プロトコル実行の文脈において）は、図1または図2に示すメッセージ3と4。唯一ナンスは、それらが含まれ、すなわち、全体ではなくノンス、ペイロードを使用していることに留意されたいです。
The first 64 octets of KEYMAT are exported as the EAP MSK, and the second 64 octets are exported as the EMSK.
KEYMATの最初の64オクテットEAP MSKとしてエクスポートされ、そして第二の64個のオクテットはEMSKとしてエクスポートされます。
The MSK and EMSK MUST NOT be generated unless an EAP-IKEv2 protocol run completes successfully. Note that the EAP-IKEv2 method does not produce an initialisation vector [7].
EAP-IKEv2のプロトコルの実行が正常に完了しない限り、MSKとEMSKを生成してはなりません。 EAP-IKEv2の方法は、初期ベクトルを生成しないことに注意してください[7]。
The EAP key management framework [7] requires that EAP methods export three information elements, called the Session-ID, the Peer-ID, and the Server-ID. In EAP-IKEv2, these elements are derived as follows:
EAPキー管理フレームワークは[7] EAPメソッドは3つの情報要素をエクスポートすることを要求する、セッションID、ピアID、およびサーバIDと呼ばれます。次のようにEAP-IKEv2のでは、これらの要素が導出されます。
o The Session-ID is constructed and exported as the concatenation of the following three elements, in this order: (a) the EAP Code Type for EAP-IKEv2 (to be defined by IANA), (b) the contents of the Nonce Data field of the Nonce Payload Ni from message 3, (c) the contents of the Nonce Data field of the Nonce Payload Nr from message 4.
OセッションIDを構築し、このために、次の3つの要素の連結としてエクスポートされる：（a）は、EAP-のIKEv2（IANAによって定義される）、乱数データの（b）の内容についてEAPコードタイプメッセージ3からノンスペイロードのNiのフィールド、（c）はメッセージ4からノンスペイロードNr個の乱数データフィールドの内容。
o In case of a full EAP-IKEv2 protocol run, the Peer-ID is constructed and exported as the content of the Identification Data field of the Identification Payload IDr from message 6. Note that only the "actual" identification data is exported, as indicated in the Payload Length field; if the Identification Data field contains any padding, this padding is ignored. In case of a "fast reconnect" protocol run, the Peer-ID field is constructed in exactly the same manner, where message 6 refers to the full EAP-IKEv2 protocol run that originally established the security context between the EAP peer and EAP server.
Oとして、完全なEAP-のIKEv2プロトコル実行の場合には、ピアIDが構成され、唯一の「実際の」識別データがエクスポートされたメッセージ6.注から識別ペイロードIDRの識別データフィールドの内容としてエクスポートペイロード長フィールドに示されています。識別データフィールドは任意のパディングが含まれている場合、このパディングは無視されます。 「高速再接続」プロトコル実行の場合には、ピアIDフィールドは、メッセージ6が元々EAPピアとEAPサーバ間のセキュリティコンテキストを確立して完全なEAP-のIKEv2プロトコルの実行を指す全く同様に構成されています。
o In case of a full EAP-IKEv2 protocol run, the Server-ID is constructed and exported as the contents of the Identification Data field of the Identification Payload IDi from message 5. Note that only the "actual" identification data is exported, as indicated in the Payload Length field; if the Identification Data field contains any padding, this padding is ignored. In case of a "fast reconnect" protocol run, the Server-ID field is constructed in exactly the same manner, where message 5 refers to the full EAP-IKEv2 protocol run that originally established the security context between the EAP peer and EAP server.
Oとして、完全なEAP-のIKEv2プロトコル実行の場合には、サーバIDが構成され、唯一の「実際の」識別データがエクスポートされるメッセージ5ノートからの識別ペイロードIDiとの識別データフィールドの内容としてエクスポートペイロード長フィールドに示されています。識別データフィールドは任意のパディングが含まれている場合、このパディングは無視されます。 「高速再接続」プロトコル実行の場合には、サーバIDフィールドは、メッセージ5は、元々EAPピアとEAPサーバ間のセキュリティコンテキストを確立して完全なEAP-のIKEv2プロトコルの実行を指す全く同様に構成されています。
This section specifies how errors are handled within EAP-IKEv2. For conveying error information from one party to the other, the Notify payload is defined and used (see Section 8.11).
このセクションでは、エラーがEAP-IKEv2の中にどのように扱われるかを指定します。他の1つの当事者からのエラー情報を搬送するため、通知ペイロード（セクション8.11を参照）を定義して使用されます。
If, in a full EAP-IKEv2 protocol run, authentication fails (i.e., the verification of the AUTH field fails at the server or the peer), but no other errors have occurred, the message flow deviates from that described in Section 3. The message flows in the presence of authentication failures are specified in Appendix A.
、完全なEAP-IKEv2のプロトコルの実行中に、認証に失敗した場合は、メッセージ・フローは、セクション3.に記載されているものから逸脱し、（つまりは、AUTHフィールドの検証は、サーバまたはピアで失敗した）が、それ以外のエラーが発生していませんメッセージは、付録Aで指定された認証失敗の存在下で流れます
If, in message 3 of a full EAP-IKEv2 protocol run (see Figure 1), the responder receives a Diffie-Hellman value (KEi) that belongs to a group that is not supported (and in the absence of other errors), then the responder MUST send a message of the form shown in Figure 3 to the initiator. This effectively becomes message 4 in the full protocol run.
完全なEAP-のIKEv2プロトコル実行のメッセージ3（図1参照）場合、応答者は、次に、のDiffie-Hellman値がサポートされていないグループに属する（及び他のエラーがない場合）（圭）を受信しますレスポンダは、イニシエータに、図3に示す形式のメッセージを送らなければなりません。これは、効果的に完全なプロトコルの実行中にメッセージ4になります。
Figure 3: Error Handling in Case of Unsupported D-H Value
図3：サポートされていないD-Hの値の場合のエラー処理
The above message consists of the EAP-IKEv2 header and a Notification payload with the value of the Notify Message Type field value set to 17 (INVALID_KE_PAYLOAD). There is a two-octet value associated with this notification: the number of the selected DH Group in big endian order, as specified in Section 3.10.1 of [1]. This number MUST represent a DH group that is supported by both the initiator and the responder.
上記のメッセージは、EAP-のIKEv2ヘッダ及び17（INVALID_KE_PAYLOAD）に設定通知メッセージタイプフィールド値の値と通知ペイロードから成ります。この通知に関連する2つのオクテットの値があります：ビッグエンディアンの順に選択DHグループの数、[1]のセクション3.10.1に指定されています。この数は、イニシエータとレスポンダの両方によってサポートされているDHグループを表現しなければなりません。
If, during a full EAP-IKEv2 protocol run (see Figure 1), the initiator receives a message conforming to Figure 3 instead of the usual message 4, then it MUST check whether or not the indicated DH group was proposed in message 3. If it was not, then the initiator MUST silently discard the message. Otherwise, the protocol continues with a new message 3 that the initiator sends to the peer. In this new message 3, the initiator MUST use a Diffie-Hellman value that is drawn from the group that is indicated in the Notify payload of message 4 in Figure 3.
完全なEAP-のIKEv2プロトコルの実行中に（図1参照）、場合、イニシエータは、代わりに通常のメッセージ4を図3に準拠したメッセージを受信し、それは場合指示DHグループがメッセージ3に提案されたか否かをチェックしなければなりませんそれはその後、イニシエータは静かにメッセージを捨てなければなりません、ありませんでした。そうでない場合は、プロトコルは、イニシエータがピアに送信する新しいメッセージ3に続きます。この新しいメッセージ3では、イニシエータは、図3にメッセージ4の通知ペイロードに示されているグループから引き出されるのDiffie-Hellman値を使用しなければなりません。
If, in the context of use case 4 and during a full EAP-IKEv2 protocol run (see Figure 1), the initiator receives, in message 4, an SK{IDr} payload that decrypts to a non-existent or unauthorised EAP-IKEv2 responder identifier IDr*, then the server SHOULD continue the protocol with a message conforming to the format of message 5. The AUTH payload in that message SHOULD contain a value that is computationally indistinguishable from a value that it would contain if IDr* was valid and authorised. This can be accomplished, for example, by generating a random key and calculating AUTH as usual (however, this document does not mandate a specific mechanism). Only after receiving message 6, the server SHOULD respond with an authentication failure notification, i.e., a message conforming to message 6 in Figure 10. The purpose of this behaviour is to prevent an adversary from probing the EAP-IKEv2 peer identifier space.
ユースケース4との関連で、完全なEAP-のIKEv2プロトコルの実行中に（図1参照）、場合、イニシエータは、メッセージ4で、受信、存在しない、または不正なEAP-のIKEv2に復号SK {IDR}ペイロードレスポンダ識別子IDR *、その後、サーバは、そのメッセージ内のAUTHペイロード5.メッセージのフォーマットに準拠したメッセージでプロトコルを続けるべきことIDR *が有効だった場合、それが含有するであろうその値から計算区別できない値を含むべきであり、承認しました。これは、例えば、ランダム鍵を生成し（但し、この文書は特定のメカニズムを強制しない）通常通りAUTHを計算することによって、達成することができます。のみメッセージ6を受信した後、サーバが認証失敗通知で応答する必要があり、即ち、図10にメッセージ6に、この動作の目的を合致メッセージはEAP-のIKEv2ピア識別子空間をプローブから敵を防止するためです。
If, in the context of use cases 1, 2, or 3 and during a full EAP-IKEv2 protocol run (see Figure 1), the initiator receives, in message 4, an SK{IDr} payload that decrypts to an EAP-IKEv2 responder identifier IDr*, then the server MUST continue the protocol as usual (note that such a payload would not be required in these use cases). The server MUST compare IDr* with the IDr received in message 6 and, in case of a mismatch, MUST respond with an authentication failure notification, i.e., a message conforming to message 6 in Figure 10. If no mismatch is detected, normal processing applies.
、ユースケース1、2、または3の文脈において、完全EAP-のIKEv2プロトコルの実行中に（図1を参照）場合、イニシエータは、メッセージ4で、受信、EAP-のIKEv2に復号SK {IDR}ペイロード応答識別子IDR *は、その後、サーバーは、（ペイロードはこれらのユースケースで必要とされないことに注意してください）いつものようにプロトコルを継続する必要があります。サーバは、メッセージ6で受信されたIDRでIDR *を比較しなければならないと、不一致が検出されない場合、ミスマッチの場合には、認証失敗の通知、すなわち、図10にメッセージ6に準拠したメッセージで応答しなければならない、通常の処理が適用され。
Other errors do not trigger messages with Notification payloads to be sent, and MUST be treated as if nothing happened (i.e., the erroneous EAP-IKEv2 packet MUST be silently discarded). This includes situations where at least one of the following conditions is met, with respect to an incoming EAP-IKEv2 packet.
その他のエラーは通知ペイロードを持つメッセージが送信されるように誘発しない、と何事もなかったかのように（すなわち、誤ったEAP-IKEv2のパケットが静かに捨てなければなりません）を扱わなければなりません。これは、以下の条件の少なくとも一つが着信EAP-IKEv2のパケットに対して、満たされている状況を含みます。
o The packet contains an Encrypted payload that, when decrypted with the appropriate key, yields an invalid decryption.
パケットは適切な鍵で復号、暗号化されたペイロードを含むO、不正な解読を生み出します。
o The packet contains an Encrypted payload with a Checksum field that does not verify with the appropriate key.
Oパケットは、適切なキーを検証していないチェックサムフィールドで暗号化されたペイロードを含みます。
o The packet contains an Integrity Checksum Data field (see *Figure 4) that is incorrect.
パケットが整合性チェックサムデータフィールドが含まれているoを間違っています（*図4を参照）。
o The packet does not contain a compulsory field.
Oパケットは、強制的なフィールドが含まれていません。
o A field in the packet contains an invalid value (e.g., an invalid combination of flags, a length field that is inconsistent with the real length of the field or packet, or the responder's choice of a cryptographic algorithm is different to NONE and any of those that were offered by the initiator).
Oパケット内のフィールドに無効な値（例えば、フラグの無効な組み合わせ、フィールドまたはパケット、または暗号アルゴリズムの応答者の選択の実際の長さと矛盾している長さフィールドにはNONEとのいずれかに異なっているが含まれていますイニシエータによって提供されたもの）。
o The packet contains an invalid combination of fields (e.g., it contains two or more Notify payloads with the same Notify Message Type value, or two or more Transform substructures with the same Transform Type and Transform ID value).
パケットO（例えば、それは、2つまたはそれ以上が同一の通知メッセージタイプ値、または二つ以上の同一の変換タイプのサブ構造を変換し、IDの値を変換してペイロードを通知含有）フィールドの無効な組み合わせを含んでいます。
o The packet causes a defragmentation error.
Oパケットはデフラグエラーが発生します。
o The format of the packet is invalid.
Oパケットのフォーマットが不正です。
o The identity provided by the EAP peer in the EAP-Response/Identity cannot be associated with either an established security context (in case of a fast reconnect) or with a real user account (in case of a full protocol exchange). In that case, the packet is silently discarded. With an outstanding message from the EAP server, the client may either retransmit the previous request or, in case of a fast reconnect, assume that state information was deleted (e.g., due to garbage collection) at the EAP server and fall back to a previously used FRID or to the full protocol exchange.
O EAP応答/アイデンティティにおけるEAPピアによって提供される同一性は（高速再接続の場合）のいずれかで確立されたセキュリティ・コンテキストに関連付けることができない、または実際のユーザーアカウントで（完全なプロトコル交換の場合）。その場合、パケットは黙って破棄されます。 EAPサーバからの優秀なメッセージでは、クライアントが以前の要求を再送信することができるいずれか、または、高速再接続の場合には、EAPサーバでその状態情報（例えば、原因ガベージコレクションに）削除されたと仮定し、以前にフォールバックFRIDを使用したり、完全なプロトコル交換します。
If an incoming packet contains an error for which a behaviour is specified in this section, and an error that, in the absence of the former error, would cause the packet to be silently discarded, then the packet MUST be silently discarded.
着信パケットは、元のエラーが存在しない場合に、パケットは黙って破棄される原因になる、という行動は、このセクションで指定されたエラー、エラーが含まれている場合、パケットは黙って捨てなければなりません。
In this section, the format of the EAP-IKEv2 data fields and applicable processing rules are specified. Figure 4 shows the general packet format of EAP-IKEv2 messages, and the embedding of EAP-IKEv2 into EAP. The EAP-IKEv2 messages are embedded in the Data field of the standard EAP Request/Response packets. The Code, Identifier, Length, and Type fields are described in [2]. The EAP Type for this EAP method is 49.
このセクションでは、EAP-IKEv2のデータフィールドおよび適用可能な処理ルールの形式が指定されています。図4は、EAP-のIKEv2メッセージの一般的なパケットフォーマット、およびEAPにEAP-のIKEv2の埋め込みを示しています。 EAP-IKEv2のメッセージは、標準のEAP要求/応答パケットのデータフィールドに埋め込まれています。コード、識別子、長さ、タイプフィールドは、[2]に記載されています。このEAP方式のためのEAPタイプは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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | HDR + payloads ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Checksum Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: General Packet Format of EAP-IKEv2
図4：EAP-IKEv2のの一般的なパケットフォーマット
The Flags field is always present and is used for fragmentation support, as described in Section 8.1. The Message Length field is not always present; its presence is determined by a certain flag in the Flags field, as described in Section 8.1. The field denoted as "HDR + payloads" in Figure 4 contains the EAP-IKEv2 header (see Section 8.2), followed by the number of payloads, in accordance with the composition of EAP-IKEv2 messages, as described in the previous sections. Note that each payload begins with a generic payload header that is specified in Section 3.2 of [1].
Flagsフィールドは、セクション8.1で説明したように、常に存在し、フラグメンテーションをサポートするために使用されます。メッセージ長フィールドは常に存在していません。 8.1節で説明したようにその存在は、フラグフィールド内の特定のフラグによって決定されます。前のセクションで説明したように、図4の「HDR +ペイロード」として示されるフィールドは、EAP-のIKEv2メッセージの組成に応じてペイロードの数、続いてEAP-のIKEv2ヘッダ（セクション8.2を参照）が含ま。各ペイロードは、[1]のセクション3.2で指定された汎用ペイロードヘッダで始まることに注意してください。
The Integrity Checksum Data field is not always present; its presence is determined by a certain flag in the Flags field, as described in Section 8.1.
整合性チェックサムデータフィールドは常に存在していません。 8.1節で説明したようにその存在は、フラグフィールド内の特定のフラグによって決定されます。
In the remainder of this section, the protocol fields that are used in EAP-IKEv2 are specified. This specification heavily relies on the IKEv2 specification [1], and many fields are constructed, formatted, and processed in way that is almost identical to that in IKEv2. However, certain deviations from standard IKEv2 formatting and processing exist. These deviations are highlighted in the remainder of this section.
このセクションの残りでは、EAP-IKEv2のに使用されるプロトコルフィールドが指定されています。この仕様は、高濃度のIKEv2仕様[1]に依存して、多くのフィールドは、構築フォーマット、およびIKEv2のとほぼ同じであるように処理されます。しかし、標準のIKEv2フォーマット及び処理から一定の偏差が存在します。これらの偏差は、このセクションの残りの部分で強調されています。
This section describes EAP-IKEv2 fragmentation, and specifies the encoding and processing rules for the Flags, Message Length, and Integrity Checksum Data field shown in Figure 4.
このセクションでは、EAP-IKEv2の断片化を記載し、そして図4に示すフラグ、メッセージ長、及び整合性チェックサムデータフィールドの符号化及び処理ルールを指定します。
Fragmentation support in EAP-IKEv2 is provided by the Flags and Message Length fields shown in Figure 4. These are encoded and used as follows:
EAP-のIKEv2におけるフラグメンテーションサポートは次のようにこれらは符号化され、使用されている図4に示すフラグとメッセージ長フィールドによって提供されます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|L M I 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
L = Length included M = More fragments I = Integrity Checksum Data included
L =長さMは、私は=整合性チェックサムデータが含まれる複数の断片を含ま=
Figure 5: Flags Field
図5：Flagsフィールド
The Flags field is defined in Figure 5. Only the first three bits (0-2) are used; all remaining bits MUST be set to zero and ignored on receipt. The L flag indicates the presence of a Message Length field, and the M flag indicates whether or not the current EAP message has more fragments. In particular, if the L bit is set, then a Message Length field MUST be present in the EAP message, as shown in Figure 4. The Message Length field is four octets long and contains the length of the entire message (i.e., the length of the EAP Data field.). Note that, in contrast, the Length field shown in Figure 4 contains the length of only the current fragment. (Note that there exist two fields that are related to length: the Length field, which is a generic EAP field, and the Message Length field, which is an EAP-IKEv2-specific field.) If the L bit is not set, then the Message Length field MUST NOT be present.
フラグフィールドは、最初の3ビット（0-2）が使用されている図5に定義されています。残りのすべてのビットはゼロに設定され、領収書の上で無視しなければなりません。 Lフラグは、メッセージ長フィールドの存在を示し、Mフラグは、現在のEAPメッセージが複数の断片を有するか否かを示します。 Lビットが設定されている場合、図4に示すように、特に、メッセージ長フィールドは、メッセージ長フィールド（すなわち、長さの長い4つのオクテットであり、メッセージ全体の長さを含む、EAPメッセージの中に存在していなければなりませんEAPデータフィールドの。）。対照的に、図4に示すLengthフィールドは、現在の断片の長さを含んでいることに注意してください。 （長さに関係している2つのフィールドが存在することに注意してください。EAP-IKEv2の固有のフィールドである一般的なEAPフィールドの長さフィールドと、メッセージ長フィールド、。）Lビットが設定されていない場合、次いでメッセージの長さフィールドが存在してはなりません。
The M flag MUST be set on all fragments except the last one. In the last fragment, the M flag MUST NOT be set. Reliable fragment delivery is provided by the retransmission mechanism of EAP as described below.
Mフラグは、最後の1を除く全てのフラグメントに設定しなければなりません。最後の断片では、Mフラグを設定してはいけません。後述のように信頼性の高い断片送達は、EAPの再送メカニズムによって提供されます。
When an EAP-IKEv2 peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-IKEv2 and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value.
EAP-のIKEv2ピアはMビットが設定されたEAP-Requestパケットを受信すると、EAPタイプ= EAP-のIKEv2およびデータのないEAP-応答で応答しなければなりません。これは、断片ACKとして機能します。それは別のフラグメントを送る前に、EAP-応答を受信するまで、EAPサーバは待たなければなりません。フラグメントの処理のエラーを防止するために、EAPサーバはEAP-要求内に含まれる各フラグメントの識別子フィールドをインクリメントしなければならない、とピアはEAPレスポンス内に含まれる断片のACKにおけるこの識別子の値を含まなければなりません。再送されたフラグメントは、同じ識別子の値が含まれます。
Similarly, when the EAP server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-IKEv2 and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response.
EAPサーバはMビットセットでEAP-応答を受信すると同様に、それはEAPタイプ= EAP-のIKEv2およびデータのないEAP-要求に応じなければなりません。これは、断片ACKとして機能します。それは別のフラグメントを送る前に、EAP-Requestを受信するまで、EAPピアは待たなければなりません。フラグメントの処理のエラーを防止するために、EAPサーバはEAP-要求内に含まれる各断片ACKのための識別子の値をインクリメントしなければならない、とピアはEAPレスポンス内に含まれる後続の断片におけるこの識別子の値を含まなければなりません。
The Integrity Checksum Data field contains a cryptographic checksum that covers the entire EAP message, starting with the Code field, and ending at the end of the EAP Data field. This field, shown in Figure 4, is present only if the I bit is set in the Flags field. The Integrity Checksum Data field immediately follows the EAP Data field without padding.
整合性チェックサムデータフィールドは、コード・フィールドで始まり、そしてEAPデータフィールドの端で終わる、全体のEAPメッセージをカバーする暗号チェックサムを含んでいます。図4に示されるこのフィールドは、Iビットがフラグフィールドに設定されている場合にのみ存在します。整合性チェックサムデータフィールドは、直ちに、パディングなしでEAPデータフィールドに従います。
Whenever possible, the Integrity Checksum Data field MUST be present (and the I bit set) for each fragment, including the case where the entire EAP-IKEv2 message is carried in a single fragment. The algorithm and keys that are used to compute the Integrity Checksum Data field MUST be identical to those used to compute the Integrity Checksum Data field of the Encrypted Payload (see Section 8.9). That is, the algorithm and keys that were negotiated and established during this EAP-IKEv2 protocol run are used. Note that this means that different keys are used to compute the Integrity Checksum Data field in each direction. Also note that, for messages where this algorithm and the keys are not yet established, the Integrity Checksum Data field cannot be computed and is therefore not included. This applies, for example, to messages 3 and 4 in Figure 1.
可能な限り、整合性チェックサムデータフィールドが存在しなければならない（及びIビットセット）全体EAP-のIKEv2メッセージは単一の断片で運ばれる場合を含む各断片について、。整合性チェックサムデータフィールドを計算するために使用されるアルゴリズムと鍵（セクション8.9を参照）は、暗号化ペイロードの整合性チェックサムデータフィールドを計算するために使用されるものと同じでなければなりません。それは、このEAP-IKEv2のプロトコルの実行中に交渉して設立されたアルゴリズムとキーが使用されています。これは、異なる鍵が各方向に整合性チェックサムデータフィールドを計算するために使用されることを意味することに留意されたいです。また、このアルゴリズムとキーがまだ確立されていないメッセージに対して、整合性チェックサムデータフィールドは計算できないため、含まれていない、ということに注意してください。これは、例えば、図1のメッセージ3及び4に、適用されます。
In order to minimize the exposure to denial-of-service attacks on fragmented packets, messages that are not protected with an Integrity Checksum Data field SHOULD NOT be fragmented. Note, however, that those packets are not likely to be fragmented anyway since they do not carry certificates.
断片化されたパケットのDoS攻撃への露出を最小限にするために、整合性チェックサムデータフィールドで保護されていないメッセージが断片化されるべきではありません。これらのパケットは、彼らが証明書を携帯していないので、とにかく断片化される可能性はないこと、しかし、注意してください。
The EAP-IKEv2 header, denoted HDR in this specification, is constructed and formatted according to the rules specified in Section 3.1 of [1].
EAP-のIKEv2ヘッダ、本明細書ではHDRを付し、[1]のセクション3.1で指定された規則に従って構築されフォーマットされます。
In the first EAP-IKEv2 message that is sent by the initiator (message 3 in Figure 1), the IKE_SA Responder's SPI field is set to zero. This is because, at this point in time, the initiator does not know what SPI value the responder will choose for this protocol run. In all other messages, both SPI fields MUST contain non-zero values that reflect the initiator- and responder-chosen SPI values.
イニシエータ（図1のメッセージ3）によって送信される最初のEAP-のIKEv2メッセージでは、IKE_SAレスポンダのSPIフィールドはゼロに設定されます。この時点で、イニシエータがレスポンダがこのプロトコルの実行のために選択されますどのようなSPI値を知っていないためです。他のすべてのメッセージでは、両方のSPIフィールドはinitiator-とレスポンダに選択されたSPI値を反映する非ゼロ値を含まなければなりません。
In accordance with [1], for this version of EAP-IKEv2, the MjVer (major version) and MnVer (minor version) fields in the header MUST be 2 and 0 respectively. The value of the Exchange Type field MUST be set to 34 (IKE_SA_INIT) in messages 3 and 4, and to 35 (IKE_SA_AUTH) in messages 5 and 6 in Figure 1. In messages 3 and 4 in Figure 2, this value MUST be set to 36 (CREATE_CHILD_SA).
[1]に従って、EAP-IKEv2のこのバージョンのために、ヘッダ内MjVer（メジャーバージョン）とMnVer（マイナーバージョン）のフィールドは、それぞれ、2 0でなければなりません。交換タイプフィールドの値は、メッセージ3および4に34（IKE_SA_INIT）に設定し、この値を設定しなければなりません、メッセージ図2におけるメッセージ3及び4では5と図1の6（IKE_SA_AUTH）35でなければなりません36（CREATE_CHILD_SA）。
The Flags field of the EAP-IKEv2 header is also constructed according to Section 3.1 of [1]. Note that this is not the same field as the Flags field shown in Figure 4.
EAP-IKEv2のヘッダのフラグフィールドは、また、[1]のセクション3.1に従って構成されています。これは、図4に示すフラグフィールドと同じフィールドではないことに留意されたいです。
The Message ID field is constructed as follows. Messages 3 and 4 in a full protocol run MUST carry Message ID value 0. Messages 5 and 6 in a full protocol run (see Figure 1) MUST carry Message ID value 1. Messages 3 and 4 in a fast reconnect protocol run MUST carry Message ID value 2.
次のようにメッセージIDフィールドが構築されます。完全なプロトコルの実行中にメッセージ3および4は完全なプロトコルの実行中にメッセージID値0メッセージ5および6を搬送しなければならない（図1を参照）メッセージを搬送しなければならない、高速再接続プロトコルの実行中にメッセージID値1メッセージ3及び4を搬送しなければなりませんID値2。
The SA payload is used for the negotiation of cryptographic algorithms between the initiator and the responder. The rules for its construction adhere to [1]; in particular, Sections 2.7 and 3.3.
SAペイロードは、イニシエータとレスポンダとの間の暗号アルゴリズムのネゴシエーションに使用されます。その構築のためのルールは、[1]に付着します。特に、セクション2.7および3.3。
In EAP-IKEv2, all Proposal Substructures in the SA payload MUST carry Protocol ID value 1 (IKE).
EAP-のIKEv2において、SAペイロード内のすべての提案部分構造は、プロトコルID値1（IKE）を運ばなければなりません。
The Key Exchange payload, denoted KEi if constructed by the initiator and KEr if constructed by the responder, is formatted according to the rules specified in Section 3.4 of [1].
イニシエータとKERによって構築場合レスポンダによって構築場合に鍵交換ペイロードが圭を付し、[1]のセクション3.4で指定された規則に従ってフォーマットされています。
The Nonce payload, denoted Ni if constructed by the initiator and Nr if constructed by the responder, is constructed and formatted according to the rules specified in Section 3.9 of [1].
イニシエータおよびNRにより構成されている場合、レスポンダによって構築場合ナンスペイロードは、ニッケルを付し、[1]のセクション3.9で指定された規則に従って構築されフォーマットされます。
The Identification payload, denoted IDi if it contains an identifier for the initiator and IDr if it contains an identifier for the responder, is constructed and formatted according to the rules specified in Section 3.5 of [1].
それは応答者の識別子を含む場合、それは、イニシエータとIDRの識別子が含まれている場合、識別ペイロードは、IDIを付し、[1]のセクション3.5で指定された規則に従って構築されフォーマットされます。
The Certificate payload, denoted CERT, is constructed and formatted according to the rules specified in Section 3.6 of [1]. Note that certain certificate encodings for the EAP server certificate, e.g., those that need to be resolved via another network protocol, cannot be used in some typical EAP-IKEv2 deployment scenarios. A user, for example, that authenticates himself by means of EAP-IKEv2 in order to obtain network access, cannot resolve the server certificate at the time of EAP-IKEv2 protocol execution.
CERTで示さ証明書ペイロードは、[1]のセクション3.6で指定された規則に従って構築されフォーマットされます。 EAPサーバ証明書のその特定の証明書のエンコーディングに注意し、例えば、他のネットワークプロトコルを介して解決する必要があるものは、いくつかの典型的なEAP-IKEv2の展開シナリオで使用することができません。ユーザは、例えば、それは、ネットワークへのアクセスを得るためにEAP-のIKEv2を用いて自身を認証EAP-のIKEv2プロトコルの実行時にサーバ証明書を解決できません。
The Certificate Request payload, denoted CERTREQ, is constructed and formatted according to the rules specified in Section 3.7 of [1].
CERTREQで示さ証明書要求ペイロードは、[1]のセクション3.7で指定された規則に従って構築されフォーマットされます。
The Encrypted payload, denoted SK{...}, is constructed and formatted according to the rules specified in Section 3.14 of [1].
暗号化されたペイロードは、SK {...}で表される、[1]のセクション3.14で指定された規則に従って構築されフォーマットされます。
The Authentication payload, denoted AUTH, is constructed and formatted according to the rules specified in Sections 2.15 and 3.8 of [1].
認証ペイロード、示さAUTHは、セクション[1]の2.15と3.8で指定された規則に従って構築されフォーマットされます。
The contents of the Authentication payload depend on which party generates this field, the use case, and the algorithm that corresponds to the credential (asymmetric key, symmetric key, or password) that this party uses to authenticate itself. The Authentication payload contains either a MAC or a signature.
認証ペイロードの内容は、当事者がこのフィールド、ユースケース、この当事者が自身を認証するために使用する資格情報（非対称鍵、対称鍵、またはパスワード）に対応するアルゴリズムを生成するに依存します。認証ペイロードは、MACまたは署名のいずれかを含みます。
If the party that generates the Authentication payload authenticates itself based on a shared secret (i.e., a password or a symmetric key), then the Authentication payload MUST contain a MAC. This MAC is calculated using a key that is derived from the shared secret, according to Section 2.15 of [1]. According to that section, the shared secret is padded with the string "Key Pad for IKEv2" as part of this key derivation. For the EAP-IKEv2 method, this rule is overridden, in that the padding string is redefined as "Key Pad for EAP-IKEv2". The latter padding string MUST be used for the derivation of the MAC key from a shared secret in the context of EAP-IKEv2. This is done in order to avoid the same MAC key to be used for both IKEv2 and EAP-IKEv2 in scenarios where the same shared secret is used for both. Note that using a shared secret (e.g., a password) in the context EAP-IKEv2 that is identical or similar to a shared secret that is used in another context (including IKEv2) is nevertheless NOT RECOMMENDED.
認証ペイロードを生成する当事者が共有秘密（即ち、パスワードまたは対称鍵）に基づいて自身を認証する場合、認証ペイロードは、MACを含まなければなりません。このMACは、[1]のセクション2.15によれば、共有秘密から導出されるキーを使用して計算されます。そのセクションによると、共有秘密は、この鍵導出の一部として文字列「IKEv2のためのキーパッド」で埋められます。 EAP-IKEv2の方法の場合、このルールは、パディングされた文字列を「EAP-IKEv2のためのキーパッド」として再定義されていることで、上書きされます。後者のパディング列は、EAP-のIKEv2の文脈における共有秘密からMAC鍵の導出のために使用されなければなりません。これは、同じ共有秘密は、両方のために使用されているシナリオでのIKEv2およびEAP-IKEv2の両方に使用される同じMACキーを避けるために行われます。同一または（IKEv2を含む）、他の文脈で使用される共有秘密と類似しているコンテキストEAP-のIKEv2で共有秘密鍵を使用して（例えば、パスワード）は、それにもかかわらず推奨されていないことに留意されたいです。
The Notify payload, denoted N(...), is constructed and formatted according to the rules specified in Section 3.10 of [1]. The Protocol ID field of this payload MUST be set to 1 (IKE_SA).
N（...）を付し、ペイロードを通知し、[1]のセクション3.10で指定された規則に従って構築されフォーマットされます。このペイロードのプロトコルIDフィールドが1（IKE_SA）に設定しなければなりません。
The Next Fast-ID Payload is defined as follows:
次のように次の高速-IDペイロードが定義されています。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Fast-Reconnect-ID (FRID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NFID Payload Format
図6：NFIDペイロードフォーマット
The Next Fast-ID payload, denoted NFID, does not have an equivalent in IKEv2. Nevertheless, the Next Payload, C, RESERVED, and Payload Length fields of this payload are constructed according to Section 3.2 of [1]. The payload ID is registered in Section 11. The Fast-Reconnect-ID field contains a fast reconnect identifier that the peer can use in the next fast reconnect protocol run, as described in Section 4. In environments where a realm portion is required, Fast-Reconnect-ID includes both a username portion and a realm name portion. The Fast-Reconnect-ID MUST NOT include any terminating null characters. The encoding of the Fast-Reconnect-ID field MUST follow the NAI format [4].
次の高速-IDペイロードは、NFIDが示され、IKEv2の中に同等のものを持っていません。それにもかかわらず、次にペイロード、C、RESERVED、このペイロードのペイロード長フィールドは、[1]のセクション3.2に従って構成されています。ペイロードIDは、高速再接続-IDフィールドは、高速、レルム部分が必要とされる環境では、セクション4で説明したように、ピアは、次の高速再接続プロトコル実行で使用することができ、高速再接続識別子を含むセクション11に登録されています-Reconnect-IDは、ユーザー名部分及び領域名部分の両方を含みます。高速再接続-IDは、任意の終端のnull文字を含んではいけません。高速再接続-IDフィールドの符号化はNAIフォーマットに従わなければならない[4]。
In EAP-IKEv2, each payload is identified by means of a type field, which, as specified in [1], is indicated in the "Next Payload" field of the preceding payload. However, the identifier space from which EAP-IKEv2 payload types are drawn is independent from the payload type space of IKEv2. This is because EAP-IKEv2 and IKEv2 may evolve in a different way and, as such, payload types that appear in one protocol do not necessary appear in the other. An example of this is the "Next Fast-ID" (NFID) payload, which does not exist in IKEv2.
EAP-のIKEv2において、各ペイロードで指定されるように、タイプフィールドの手段によって識別される、[1]、先行ペイロードの「次ペイロード」フィールドに示されています。しかしながら、EAP-のIKEv2ペイロードタイプが描かれ、そこから識別子空間は、のIKEv2のペイロードタイプスペースから独立しています。あるプロトコルに現れるような、ペイロードタイプが他に必要に表示されないので、EAP-のIKEv2とのIKEv2は、異なる方法で進化してもよいからです。この例は、IKEv2の中に存在しない「次の速い-ID」（NFID）ペイロードです。
The values for the payload types defined in this document are listed in Section 11. Payload type values 13-127 are reserved to IANA for future assignment in EAP-IKEv2. Payload type values 128-255 are for private use among mutually consenting parties.
この文書で定義されたペイロードタイプの値は、13から127は、EAP-IKEv2の将来の割り当てのためのIANAに予約されている第11のペイロードタイプ値に記載されています。ペイロードタイプの値128-255は、互いに同意当事者間の私的使用のためのものです。
As mentioned in Section 3, in EAP-IKEv2, the EAP server always assumes the role of the initiator (I), and the EAP peer takes on the role of the responder (R) of an exchange. This is in order to ensure that, in scenarios where the peer authenticates itself based on a password (i.e., in use case 3), operations that involve this password only take place after the server has been successfully authenticated. In other words, this assignment of initiator and responder roles results in protection against offline dictionary attacks on the password that is used by the peer to authenticate itself (see Section 10.7).
EAP-IKEv2の中で、第3節で述べたように、EAPサーバは、常に、イニシエータ（I）の役割を引き受け、そしてEAPピアは交換の応答者（R）の役割を担います。これは、サーバーが正常に認証された後、ピアがパスワードに基づいて自身を認証シナリオで（すなわち、ユースケース3には）、このパスワードを伴う操作が唯一の場所を取る、ということを確実にするためです。つまり、自分自身を認証するためにピアによって使用されるパスワードでオフライン辞書攻撃に対する保護のイニシエータとレスポンダーの役割結果のこの割り当ては（10.7節を参照してください）。
In order for two EAP-IKEv2 implementations to be interoperable, they must support at least one common set of cryptographic algorithms. In order to promote interoperability, EAP-IKEv2 implementations MUST support the following algorithms based on the "MUST/MUST-" recommendations given in [5]:
相互運用される2つのEAP-IKEv2の実装のために、彼らは、暗号アルゴリズムの少なくとも一つの共通セットをサポートしなければなりません。相互運用性を促進するために、EAP-IKEv2の実装は、[5]に示す「MUST / MUST-」推奨に基づいて、以下のアルゴリズムをサポートしなければなりません。
Diffie-Hellman Groups: 1024 MODP Group IKEv2 Transform Type 1 Algorithms: ENCR_3DES IKEv2 Transform Type 2 Algorithms: PRF_HMAC_SHA1 IKEv2 Transform Type 3 Algorithms: AUTH_HMAC_SHA1_96
Diffie-Hellmanのグループ：1024 MODPグループのIKEv2は、タイプ1の変換アルゴリズム：PRF_HMAC_SHA1のIKEv2は、タイプ3の変換アルゴリズム：AUTH_HMAC_SHA1_96 ENCR_3DESのIKEv2は、タイプ2の変換アルゴリズム
All other options of [5] MAY be implemented.
[5]の他のすべてのオプションが実装されてもよいです。
The remainder of this section describes EAP-IKEv2 in terms of specific security terminology as required by [2]. The discussion makes reference to the use cases defined in Section 1.
[2]によって必要とされるこのセクションの残りの部分は、特定のセキュリティ用語の点でEAP-のIKEv2を記載しています。議論は、第1節で定義されたユースケースを参照します。
In message 3, the EAP server provides the set of ciphersuites it is willing to accept in an EAP-IKEv2 protocol run. Hence, the server is in control of the ciphersuite. An EAP peer that does not support any of the indicated ciphersuites is not able to authenticate. The local security policy of the peer MUST specify the set of ciphersuites that the peer accepts. The server MUST verify that the ciphersuite that is indicated as being chosen by the peer in message 4, belongs to the set of ciphersuites that were offered in message 3. If this verification fails, the server MUST silently discard the packet.
メッセージ3で、EAPサーバは、EAP-のIKEv2プロトコル実行で受け入れても構わないと思っている暗号スイートのセットを提供します。したがって、サーバは、暗号スイートの制御です。示された暗号スイートのいずれかをサポートしていないEAPピアは認証できません。ピアのローカルセキュリティポリシーは、ピアが受け入れる暗号スイートのセットを指定する必要があります。サーバは、メッセージ4内のピアによって選択されたものとして示されている暗号スイートは、この検証が失敗した場合、サーバは静かにパケットを捨てなければなりませんメッセージ3に提供された暗号スイートのセットに属することを確認しなければなりません。
EAP-IKEv2 supports mutual authentication.
EAP-IKEv2のは、相互認証をサポートしています。
EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic. This protection is offered after authentication is completed and it is facilitated by inclusion of two Integrity Checksum Data fields: one at the end of the EAP packet (see Figure 4), and one as part of an Encrypted payload (see Section 8.9).
EAP-IKEv2のは、EAP-IKEv2のトラフィックの完全性保護を提供します。認証が完了した後、この保護が提供され、それは、二つの整合性チェックサムデータフィールドを含めることによって促進される：EAPパケットの最後に1つ（図4参照）、及び暗号化されたペイロードの一部として1（セクション8.9を参照します）。
EAP-IKEv2 provides protection against replay attacks by a variety of means. This includes the requirement that the Authentication payload is computed as a function of, among other things, a server-provided nonce and a peer-provided nonce. These nonces are required to be practically unpredictable by an adversary. Assuming that the algorithm that is used to compute the Authentication payload does not contain cryptographic weaknesses, the probability that an Authentication payload that is valid in a particular protocol run will also be valid in a subsequent run is therefore negligible.
EAP-IKEv2のは、様々な手段によって、リプレイ攻撃に対する保護を提供します。これは、認証ペイロードは、とりわけ機能、サーバが提供するノンス及びピア提供ナンスとして計算される要件を含みます。これらのナンスは敵によって、実質的に予測不可能であることが要求されています。認証ペイロードを計算するために使用されるアルゴリズムは、暗号化の弱点が含まれていないと仮定すると、特定のプロトコル実行で有効な認証ペイロードはまた、後続の実行で有効になる確率は、したがって、無視できます。
EAP-IKEv2 provides confidentiality of certain EAP-IKEv2 fields, namely those included in Encrypted payloads. With respect to identity confidentiality, the following claims are made. Note that identity confidentiality refers to the EAP-IKEv2 identity of the EAP peer.
EAP-IKEv2のは、特定のEAP-IKEv2のフィールド、暗号化されたペイロードに含まれる、すなわち、それらの機密性を提供します。アイデンティティの機密性に関しては、以下の特許請求の範囲が作られています。そのアイデンティティの機密性がEAPピアのEAP-IKEv2のアイデンティティを指します。
Identity confidentiality is provided in the face of a passive adversary, i.e., an adversary that does not modify traffic as it is in transit. Whenever the optional SK{IDr} payload in message 4 of a full EAP-IKEv2 protocol (see Figure 1) is not included, identity confidentiality is also provided in the face of an active adversary. This payload MUST NOT be included in use cases 1, 2, and 3. In use case 4, this payload MUST be included. Therefore, in use case 4, EAP- IKEv2 does not provide identity confidentiality in the face of an active adversary.
同一の機密性は、受動的攻撃、すなわち、それが通過しているように、トラフィックを変更しない敵の面に設けられています。完全なEAP-のIKEv2プロトコルのメッセージ4で任意SK {IDR}ペイロードが含まれていない（図1を参照）ときはいつでも、同一の機密性は、活性敵の面に設けられています。このペイロードは、ユース・ケース4ではユースケース1、2、および3に含まれてはいけません、このペイロードを含まなければなりません。したがって、ユースケース4で、EAP-のIKEv2はアクティブ敵の面で同一の機密性を提供しません。
Note, however, that the EAP peer provides its identity in message 2 in Figure 1 in cleartext. In order to provide identity confidentiality as discussed in the previous paragraphs, it is necessary to obfuscate the username part of the identity (the realm part must stay intact to allow correct message routing by the Authentication, Authorization, and Accounting (AAA) infrastructure). The EAP server then uses the identity information in message 4. The same mechanism is also used by other EAP methods to provide identity confidentiality, for example, EAP-TTLS [8].
EAPピアが平文で図1のメッセージ2でその識別情報を提供すること、しかし、注意してください。前の段落で説明したように同一の機密性を提供するために、それはアイデンティティのユーザ名部分を難読化することが必要である（レルム部分は、認証、許可、アカウンティング（AAA）インフラストラクチャによって正しいメッセージルーティングを可能にするために、無傷のままでなければなりません）。 EAPサーバは、次いで、例えば、メッセージ4も同一の機密性を提供するために、他のEAPメソッドによって使用される同じ機構で識別情報を使用して、EAP-TTLS [8]。
EAP-IKEv2 supports the establishment of session keys (MSK and EMSK) of a variety of key strengths, with the theoretical maximum at 512 bits per key (since this is the size of the MSK and the EMSK). However, in practice, the effective key strength is likely to be significantly lower, and depends on the authentication credentials used, the negotiated ciphersuite (including the output size of the pseudorandom function), the Diffie-Hellman group used, and on the extent to which the assumptions on which the underlying cryptographic algorithms depend really hold. Of the above mechanisms, the one that offers the lowest key strength can be regarded as a measure of the effective key strength of the resulting session keys. Note that this holds for other EAP methods, too.
EAP-のIKEv2（これはMSK及びEMSKのサイズであるので）キー当り512ビットで理論的な最大値と、キー強度の種々のセッションキー（MSK及びEMSK）の確立をサポートします。しかし、実際には、有効鍵強度は著しく低くなる可能性がある、そして使用される認証証明書に依存する、（擬似ランダム関数の出力サイズを含む）をネゴシエート暗号スイートは、のDiffie-Hellmanグループが使用され、どの程度にこれは根本的な暗号化アルゴリズムが実際に保有依存している仮定。上記のメカニズムの、最低のキー強度を提供する一方が得られたセッション鍵の有効鍵強度の尺度とみなすことができます。これは、あまりにも、他のEAPメソッドのために保持していることに注意してください。
Due to the large variety of possible combinations, no indication of a practical effective key strength for MSK or EMSK is given here. However, those responsible for the deployment of EAP-IKEv2 in a particular environment should consider the threats this environment may be exposed to, and configure the EAP-IKEv2 server and peer policies and authentication credentials such that the established session keys are of a sufficiently high effective key strength.
可能な組み合わせの多種多様に、MSK又はEMSKには実用的で有効なキー強度の兆候はここで与えられていません。しかし、特定の環境でのEAP-IKEv2のの展開の責任者は、この環境がさらされる脅威を検討し、そのような確立されたセッション鍵であることを十分に高いのEAP-IKEv2のサーバとピアポリシーおよび認証資格情報を設定する必要があります効果的な強み。
EAP-IKEv2 can be used in a variety of use cases, as explained in Section 1. In some of these uses cases, namely use case 1, 2, and 4, dictionary attacks cannot be launched since no passwords are used.
これらの使用事例のいくつかでは、セクション1で説明したようにEAP-のIKEv2、すなわちケース1、2を使用し、ユースケース様々な使用することができ、およびNOパスワードを使用しないので図4は、辞書攻撃を起動することができません。
In use case 3, EAP-IKEv2 provides protection against offline dictionary attacks, since operations that involve the password are executed only after the server has authenticated itself (based on a credential other than a password).
パスワードを必要とする操作は、サーバーが（パスワード以外の資格その他に基づいて）自分自身を認証した後にのみ実行されますので、ユースケース3では、EAP-IKEv2のは、オフライン辞書攻撃に対する保護を提供します。
In order to reduce exposure against online dictionary attacks, in use case 3, the server SHOULD provide the capability to log failed peer authentication events, and SHOULD implement a suitable policy in case of consecutive failed peer authentication attempts within a short period of time (such as responding with an EAP-Failure instead of message 5 for a predetermined amount of time).
オンライン辞書攻撃に対するエクスポージャーを軽減するためには、ユースケース3には、サーバが失敗したピア認証イベントをログに記録する機能を提供すべきであり、短時間に連続して失敗したピア認証試行の場合は、適切なポリシーを実装する必要があります（たとえば、所定の時間EAP-失敗の代わりにメッセージ5で応答するなど）。
When passwords are used with method 4 (instead of using a key with high entropy), dictionary attacks are possible, as described in Section 8 of [1]:
パスワードは方法4（代わりの高いエントロピーを持つキーを使用して）で使用される場合、[1]のセクション8で説明したように、辞書攻撃が可能です。
"When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets. The strongest practice is to ensure that any pre-shared key contain as much randomness as the strongest key being negotiated. Deriving a shared secret from a password, name, or other low-entropy source is not secure. These sources are subject to dictionary and social engineering attacks, among others."
事前共有キーを使用する場合」、重要な考慮事項は、これらの秘密のランダム性を保証する方法である。最強の練習は、任意の事前共有キーから共有秘密を導出する。交渉中最強のキーと同じくらいランダム性を含んでいることを確認することですパスワード、名前、またはその他の低エントロピー源は安全ではありません。これらのソースは、とりわけ、辞書とソーシャルエンジニアリング攻撃の対象となります。」
Hence, the usage of passwords with mode 4 where the EAP peer and the EAP server rely on a shared secret that was derived from a password is insecure. It is strongly recommended to use mode 3 when passwords are used by the EAP peer.
したがって、EAPピアとEAPサーバがパスワードから導出された共有シークレットに依存しているモード4でパスワードの使用は危険です。強くパスワードがEAPピアによって使用されたときにモード3を使用することをお勧めします。
EAP-IKEv2 supports a "fast reconnect" mode of operation, as described in Section 4.
第4節で説明したようにEAP-IKEv2のは、操作の「高速再接続」モードをサポートしています。
EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding does not apply to EAP-IKEv2.
EAP-のIKEv2トンネルEAP方法ではありません。このように、暗号の結合は、EAP-IKEv2のには適用されません。
EAP-IKEv2 provides session independence in a number of ways, as follows:
次のようにEAP-IKEv2のは、いくつかの方法でセッションの独立性を提供します。
Firstly, knowledge of captured EAP-IKEv2 conversations (i.e., the information that a passive adversary may obtain) does not enable the adversary to compute the Master Session Key (MSK) and Extended Master Session Key (EMSK) that resulted from these conversations. This holds even in the case where the adversary later obtains access to the server and/or the peer's long-term authentication credentials that were used in these conversations. That is, EAP-IKEv2 provides support for "perfect forward secrecy". However, whether or not this support is made use of in a particular EAP-IKEv2 protocol run, depends on when the peer and the server delete the Diffie-Hellman values that they used in that run, and on whether or not they use fresh Diffie-Hellman values in each protocol run. The discussion in Section 2.12 of [1] applies.
まず、捕捉EAP-IKEv2の会話の知識（すなわち、受動的敵対者が得ることができるという情報）は、マスターセッションキー（MSK）と、これらの会話に起因する拡張マスタセッションキー（EMSK）を計算するために敵を可能にしません。これも、敵対者が後でこれらの会話で使用されたサーバーおよび/またはピアの長期的な認証資格情報へのアクセスを取得した場合に成立します。つまり、EAP-IKEv2のは、「完全転送秘密」のためのサポートを提供します。ただし、このサポートは、特定のEAP-IKEv2のプロトコル実行での使用を作られているかどうか、ピアおよびサーバは、彼らがその実行に使用されるのDiffie-Hellman値を削除するときに、彼らは新鮮なディフィーを使用するかどうかに依存します各プロトコルの実行中に-Hellman値。 2.12節での議論は、[1]に適用されます。
Secondly, an active adversary that does not know the peer's and server's long-term authentication credentials cannot learn the MSK and EMSK that were established in a particular protocol run of EAP-IKEv2, even if it obtains access to the MSK and EMSK that were established in other protocol runs of EAP-IKEv2. This is because the MSK and the EMSK are a function of, among other things, data items that are assumed to be generated independently at random in each protocol run.
第二に、ピアの、サーバーの長期的な認証資格情報を知らないアクティブな敵は、それが設立されたMSKとEMSKへのアクセス権を取得した場合でも、EAP-IKEv2のの特定のプロトコル実行で設立されたMSKとEMSKを学ぶことができませんEAP-IKEv2の他のプロトコルを実行しました。 MSK及びEMSKは、とりわけ、各プロトコルの実行中にランダムに独立して生成することが想定されるデータ項目の関数であるからです。
EAP-IKEv2 provides support for fragmentation, as described in Section 8.1.
EAP-IKEv2の8.1節で説明したように、断片化のためのサポートを提供します。
Channel binding is not supported in EAP-IKEv2.
結合チャネルは、EAP-IKEv2のではサポートされていません。
EAP security claims are defined in Section 7.2.1 of [2]. The security claims for EAP-IKEv2 are as follows:
EAPセキュリティ特許請求の範囲は、[2]のセクション7.2.1で定義されています。次のようにEAP-IKEv2のためのセキュリティの主張は以下のとおりです。
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes; see Section 5
Key strength: Variable
Dictionary attack prot.: Yes; see Section 10.7
Fast reconnect: Yes; see Section 4
Crypt. binding: N/A
Session independence: Yes; see Section 10.10
Fragmentation: Yes; see Section 10.11
Channel binding: No
IANA has allocated value 49 for the EAP method type indicating EAP-IKEv2. EAP-IKEv2 has already earlier successfully passed Designated Expert Review as mandated by RFC 3748 for IANA allocations.
IANAはEAP-のIKEv2を示すEAPメソッドタイプに値49を割り当てました。 IANAの割り当てについては、RFC 3748で必須としてEAP-IKEv2のは、すでに以前に成功指定エキスパートレビューに合格しました。
In addition, IANA has created a new registry for "EAP-IKEv2 Payloads", and populated it with the following initial entries listed below.
また、IANAは、「EAP-IKEv2のペイロード」のための新しいレジストリを作成しており、かつ以下のとおり以下の初期のエントリでそれを埋め。
The following payload type values are used by this document.
以下のペイロードタイプの値は、このドキュメントで使用されています。
Next Payload Type | Value
----------------------------------+----------------------------------
No Next payload | 0
Security Association payload | 33
Key Exchange payload | 34
Identification payload |
(when sent by initiator, IDi) | 35
Identification payload |
(when sent by responder, IDr) | 36
Certificate payload | 37
Certificate Request payload | 38
Authentication payload | 39
Nonce payload | 40
Notification payload | 41
Vendor ID payload | 43
Encrypted payload | 46
Next Fast-ID payload | 121
RESERVED TO IANA | 1-32, 42, 44-45, 47-120, 122-127
PRIVATE USE | 128-255
Payload type values 1-120 match the corresponding payloads in the IKEv2 IANA registry. That is, the EAP-IKEv2 payloads that have been assigned a type value in the range 1-120 have a semantically equivalent payload type in IKEv2, with an identical payload type value. However, there exist payloads types in IKEv2 that do not have a semantically equivalent payload in EAP-IKEv2; this explains the fact that the payload type values 42, 44, and 45 have not been assigned in EAP-IKEv2; these values remain RESERVED TO IANA for this version of EAP-IKEv2.
ペイロードタイプは、1から120試合のIKEv2 IANAレジストリに対応するペイロード値。つまり、範囲1-120タイプ値を割り当てられているEAP-のIKEv2ペイロードは、同じペイロードタイプ値とのIKEv2に意味的に等価なペイロードタイプを有します。しかし、EAP-IKEv2の中で意味的に等価ペイロードを持っていないのIKEv2でのペイロードのタイプが存在します。これは、ペイロードタイプ44、42値、および45は、EAP-のIKEv2に割り当てられていないという事実を説明します。これらの値は、EAP-IKEv2のこのバージョンのためにIANAに予約されたまま。
Payload type values 121-127 are used for EAP-IKEv2 specific payloads, i.e., for payloads that do not have a semantically equivalent payload in IKEv2. Note that this range has been reserved for this purpose in the IKEv2 IANA registry too. This means that the same payload type values will not be used for different things in IKEv2 and EAP-IKEv2 protocols.
ペイロードタイプは121-127がEAP-IKEv2の特定のペイロードのための、すなわち、IKEv2のに意味的に等価なペイロードを持っていないペイロードのために使用される値。この範囲があまりにもIKEv2のIANAレジストリにこの目的のために予約されていることに注意してください。これは、同じペイロードタイプ値は、IKEv2のとEAP-IKEv2のプロトコルで異なるもののために使用されないことを意味します。
Payload type values 122-127 are reserved to IANA for future assignment to EAP-IKEv2-specific payloads. Payload type values 128-255 are for private use among mutually consenting parties.
ペイロードタイプ値122から127は、EAP-IKEv2の固有ペイロードへの将来の割り当てのためのIANAに予約されています。ペイロードタイプの値128-255は、互いに同意当事者間の私的使用のためのものです。
The semantics of the above-listed payloads is provided in this document (0-127) and refer to IKEv2 when necessary (1-120).
上記に列挙したペイロードのセマンティクスは、この文書（0〜127）に設けられた場合には（1-120）必要のIKEv2を指しています。
New payload type values with a description of their semantic will be assigned after Expert Review. The expert is chosen by the IESG in consultation with the Security Area Directors and the EMU working group chairs (or the working group chairs of a designated successor working group). Updates can be provided based on expert approval only. A designated expert will be appointed by the Security Area Directors. Based on expert approval it is possible to delete entries from the registry or to mark entries as "deprecated".
彼らのセマンティックの説明を新しいペイロードタイプ値は、専門家レビューの後に割り当てられます。専門家は、セキュリティエリア取締役およびEMUワーキンググループチェア（または指定された後継ワーキンググループのワーキンググループいす）と協議してIESGによって選ばれます。アップデートは、専門家の承認に基づいて提供することができます。指定された専門家は、セキュリティエリアディレクターによって任命されます。専門家の承認に基づいて、レジストリからエントリを削除するか、「非推奨」としてエントリをマークすることが可能です。
Each registration must include the payload type value and the semantic of the payload.
各登録は、ペイロードタイプ値とペイロードの意味が含まれている必要があります。
The authors are grateful to Krzysztof Rzecki, Rafal Mijal, Piotr Marnik, and Pawel Matejski, who, during their implementation of EAP-IKEv2 (see http://eap-ikev2.sourceforge.net/), provided invaluable feedback and identified a number of errors in previous versions of this document.
著者は、EAP-のIKEv2（http://eap-ikev2.sourceforge.net/を参照）のそれらの実装の際に、貴重なフィードバックを提供し、番号を特定し、クシシュトフRzecki、ラファウMijal、ピョートルMarnik、およびパヴェルMatejskiに感謝していますこのドキュメントの以前のバージョンのエラー。
The authors also thank Pasi Eronen for his invaluable comments as expert reviewer assigned by the EAP working group chairs Jari Arkko and Bernard Aboba. The authors would also like to thank Guenther Horn, Thomas Otto, Paulo Pagliusi, and John Vollbrecht for their insightful comments and suggestions. The members of the PANA design team; in particular, D. Forsberg and A. Yegin, also provided comments on the initial version of this document. We would like to thank Hugo Krawczyk for his feedback regarding the usage of the password-based authentication.
EAPワーキンググループによって割り当てられた専門家のレビューアがヤリArkkoとバーナードAbobaを議長として、著者らはまた、彼の貴重なコメントをパシEronenに感謝します。著者はまた、彼らの洞察に満ちたコメントと提案のためのギュンター・ホーン、トーマス・オットー、パウロPagliusi、ジョンVollbrechtに感謝したいと思います。 PANAの設計チームのメンバー。特に、D.フォースバーグとA. Yeginは、また、本文書の最初のバージョンにコメントを提供しました。私たちは、パスワードベースの認証の使用に関する彼のフィードバックのためのヒューゴKrawczykに感謝したいと思います。
The authors are grateful to the members of the EAP keying design team for their discussion in the area of the EAP Key Management Framework.
著者は、EAP鍵管理フレームワークの分野での議論のためのEAPキーイング設計チームのメンバーに感謝しています。
We would like to thank Jari Arkko for his support and for his comments. Finally, we would like to thank Charlie Kaufman, Bernard Aboba, and Paul Hoffman for their comments during IETF Last Call.
私たちは彼のサポートのために、彼のコメントをヤリArkkoに感謝したいと思います。最後に、我々は、IETFラストコール中に彼らのコメントのためにチャーリー・カウフマン、バーナードAboba、そしてポール・ホフマンに感謝したいと思います。
[1] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[1]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[2] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[3]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月を。
[4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[4] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[5] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[5]シラー、J.、 "インターネット鍵交換バージョン2（IKEv2の）での使用のための暗号アルゴリズム"、RFC 4307、2005年12月。
[6] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[6] Aboba、B.及びD.シモン、 "PPP EAP TLS認証プロトコル"、RFC 2716、1999年10月。
[7] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, February 2007.
[7] Aboba、B.、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、進歩、2007年2月の作業を。
[8] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol (EAP-TTLS)", Work in Progress, July 2004.
[8]ファンク、P.およびS.ブレーク - ウィルソン、 "EAPトンネリングTLS認証プロトコル（EAP-TTLS）"、進歩、2004年7月ワーク。
Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication
付録A. EAP-IKEv2のプロトコルは、失敗した認証を実行します。
This appendix illustrates how authentication failures are handled within EAP-IKEv2. Note that authentication failures only occur in full EAP-IKEv2 protocol runs.
この付録では、認証の失敗は、EAP-IKEv2の内で処理されている様子を示しています。その認証の失敗が唯一のフルEAP-IKEv2のプロトコルの実行中に発生に注意してください。
Figure 10 shows the message flow in case the EAP peer fails to authenticate the EAP server.
図10は、EAPピアがEAPサーバの認証に失敗した場合に、メッセージフローを示します。
Figure 10: EAP-IKEv2 with Failed Server Authentication
図10：障害の発生したサーバの認証とEAP-IKEv2の
The difference in the full successful exchange described in Section 3 is that, in message 6, the EAP peer MUST answer the EAP server with an Encrypted payload that contains a Notify payload with the Notify Message Type value set to 24 (AUTHENTICATION_FAILED). In that message, the Message ID field in the EAP-IKEv2 header (HDR) MUST carry Message ID value 2. In message 7, an EAP-Failure message MUST be returned by the EAP server.
セクション3で説明フル成功交換の違いは、メッセージ6で、EAPピアが24（AUTHENTICATION_FAILED）に設定通知メッセージ・タイプ値を有する通知ペイロードを含む暗号化されたペイロードとEAPサーバに答えなければならない、ということです。そのメッセージは、EAP-のIKEv2ヘッダ（HDR）にメッセージIDフィールドは、メッセージ7でメッセージIDの値2を運ばなければなりません、EAP失敗メッセージは、EAPサーバによって返されなければなりません。
Figure 11 shows the message flow in case the EAP server fails to authenticate the EAP peer.
図11は、EAPサーバがEAPピアを認証するために失敗した場合のメッセージフローを示します。
Figure 11: EAP-IKEv2 with Failed Peer Authentication
図11：失敗したピア認証とEAP-IKEv2の
Compared to the full successful exchange, one additional roundtrip is required. In message 7, the EAP server MUST send an EAP request with Encrypted payload that contains a Notify payload with the Notify Message Type value set to 24 (AUTHENTICATION_FAILED), instead of sending an EAP-Success message. The EAP peer, upon receiving message 7, MUST send an empty EAP-IKEv2 (informational) message in reply to the EAP server's error indication, as shown in message 8. In messages 7 and 8, the Message ID field in the EAP-IKEv2 header (HDR) MUST carry Message ID value 2. Finally, by means of message 9, the EAP server answers with an EAP-Failure.
完全な成功の交換と比較すると、一つの追加のラウンドトリップが必要です。メッセージ7では、EAPサーバは代わりにEAP-Successメッセージを送信する、24（AUTHENTICATION_FAILED）に設定通知メッセージ・タイプ値を有する通知ペイロードを含む暗号化されたペイロードとEAP要求を送信しなければなりません。メッセージ7および8にメッセージ8に示すように、メッセージ7を受信すると、EAPピアは、EAPサーバのエラー表示への応答に空EAP-IKEv2の（情報）メッセージを送らなければなりません、EAP-のIKEv2におけるメッセージIDフィールドヘッダ（HDR）は、メッセージ9を用いて、最後のメッセージID値2を運ばなければなりません、EAP-障害とEAPサーバが応答します。
Authors' Addresses
著者のアドレス
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ハンネスTschofenigノキアシーメンスネットワークスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com
電子メール：Hannes.Tschofenig@nsn.com URI：http://www.tschofenig.com
Dirk Kroeselberg Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ディルクKroeselbergノキアシーメンスネットワークスオットー・ハーンリング6ミュンヘン、バイエルン81739ドイツ
EMail: Dirk.Kroeselberg@nsn.com
メールアドレス：Dirk.Kroeselberg@nsn.com
Andreas Pashalidis NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany
アンドレアスPashalidis NEC Kurfuerstenコンディショニング36 69115ハイデルベルクドイツ
EMail: pashalidis@nw.neclab.eu
メールアドレス：pashalidis@nw.neclab.eu
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
義弘大場東芝アメリカリサーチ社1のTelcordiaドライブピスカタウェイ、NJ 08854 USA
EMail: yohba@tari.toshiba.com
メールアドレス：yohba@tari.toshiba.com
Florent Bersani France Telecom R&D 38, rue du General Leclerc Issy-Les-Moulineaux, Cedex 92794 France
フロランBersaniフランステレコムR＆D 38、RUEデュ一般ルクレールイシレムリノーセデックス92794フランス
EMail: florent.ftrd@gmail.com
メールアドレス：florent.ftrd@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。