[要約] RFC 5106は、EAP-IKEv2メソッドに関する仕様であり、IKEv2プロトコルと統合した認証プロトコルを提供します。目的は、IKEv2セッションの認証を拡張し、セキュアな通信を確保することです。
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-kikev2）メソッド
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
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.
このドキュメントは、インターネットキーエクスチェンジ（IKEV2）プロトコルに基づいた拡張可能な認証プロトコル（EAP）メソッドであるEAP-kikev2を指定します。EAP-kikev2は、EAPピアとEAPサーバーの間で相互認証とセッションキーの確立を提供します。パスワード、高エントロピー共有キー、および公開キー証明書に基づいた認証技術をサポートしています。EAP-kikev2は、暗号化の暗号化された交渉、ハッシュ関数の俊敏性、アイデンティティの機密性（特定の動作モード）、断片化、およびオプションの「高速再接続」モードのサポートをさらに提供します。
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:
このドキュメントは、インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）[1]に基づくEAPメソッドであるEAP-kikev2を指定します。EAP-kikev2は、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クライアントは対称キーを使用して自分自身を認証することができます。特に、実際には次の組み合わせが使用されると予想されます。これらは、このドキュメントの残りの部分で「ユースケース」または「モード」と呼ばれます。
1. EAP server: asymmetric key pair, EAP peer: asymmetric key pair
1. EAPサーバー：非対称キーペア、EAPピア：非対称キーペア
2. EAP server: asymmetric key pair, EAP peer: symmetric key
2. EAPサーバー：非対称キーペア、EAPピア：対称キー
3. EAP server: asymmetric key pair, EAP peer: password
3. EAPサーバー：非対称キーペア、EAPピア：パスワード
4. EAP server: symmetric key, EAP peer: symmetric key
4. 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-kikev2のキーパッド」）にアクセスする必要があることに注意してください。（以下のセクション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-kikev2はこの機能を継承しません。つまり、EAP-kikev2内のEAPメソッドをトンネルすることはできません。また、EAP-kikev2によって提供される機能のセットは、たとえばEAP-TLS [6]などの他のEAPメソッドによって提供されるものと同一ではありませんが、同一ではないことに注意してください。
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-kikev2交換の概要を説明し、プロトコルメッセージ構成を指定します。
o Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode of operation.
o セクション4では、オプションのEAP-akev2 "fast reconnect"操作モードを指定します。
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では、Session-ID、Peer-ID、およびServer-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-kikev2データフィールドの形式を指定します。セクション8.1では、EAP-kikev2で断片化がどのように処理されるかについて説明します。
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]で定義されている用語を使用しています。さらに、キーワードは、[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:
証明書：
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-kikev2ヘッダー。
I:
私：
Initiator, the party that sends the first message of an EAP-IKEv2 protocol run. This is always the EAP server.
イニシエーター、EAP-kikev2プロトコルの実行の最初のメッセージを送信するパーティー。これは常に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.
Responder、EAP-kikev2プロトコルの実行の2番目のメッセージを送信するパーティー。これは常にEAPピアです。
SA:
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-kikev2プロトコルの実行内で使用される暗号化アルゴリズムの交渉に使用されるペイロードの種類を示します。具体的には、SAIはイニシエーターによって受け入れられる一連の選択肢を示し、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-kikev2内部キーを使用して整合性保護されていることを示します。これらのキーは、それぞれの方向で異なります。
SK_xx:
sk_xx：
EAP-IKEv2 internal key, defined in Section 2.14 of [1].
[1]のセクション2.14で定義されているEAP-aikv2内部キー。
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-kikev2プロトコルの実行を指定します。すべてのメッセージは、EAPピアとEAPサーバー、つまり2つのパーティ間で送信されます。EAP-kikev2では、EAPサーバーは常にイニシエーター（i）の役割を想定し、EAPは交換のレスポンダー（R）の役割を想定しています。
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.
EAP-kikev2メッセージのセマンティクスとフォーマットは、IKEセキュリティ協会の設立のためにIKEV2 [1]で指定されたものと同一ではありませんが、同一ではありません。完全なEAP-kikev2プロトコルの実行は、2つのラウンドトリップで構成され、その後にEAP-SUCASSまたはEAPフェイルメッセージのいずれかが続きます。EAPアイデンティティを交換するためのオプションの往復は、2つの交換に先行する場合があります。
1. R<-I: EAP-Request/Identity
1. R <-i：EAP-Request/ID
2. R->I: EAP-Response/Identity(Id)
2. r-> i：EAP-Response/ID（ID）
3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
3. r <-i：eap-req（hdr、sai、kei、ni）
4. R->I: EAP-Res (HDR, SAr, KEr, Nr, [CERTREQ], [SK{IDr}])
4. r-> i：eap-res（hdr、sar、ker、nr、[certreq]、[sk {idr}]）
5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH})
5. r <-i：eap-req（hdr、sk {idi、[cert]、[certreq]、[nfid]、auth}）
6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH})
6. r-> i：eap-res（hdr、sk {idr、[cert]、auth}）
7. R<-I: EAP-Success
7. r <-i：eap-success
Figure 1: EAP-IKEv2 Full, Successful Protocol Run
図1：EAP-kikev2フル、成功したプロトコルの実行
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-aikv2プロトコルの実行を示しています。メッセージ構成の詳細な仕様が続きます。
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).
メッセージ1と2は、[2]で定義されているように、標準のEAP IDリクエストと応答です。メッセージ3は、最初のEAP-akev2固有のメッセージです。これにより、サーバーは実際のEAP認証交換を開始します。EAP-kikev2ヘッダー（HDR）のイニシエーターセキュリティパラメーターインデックス（SPI）が含まれています（HDR）（イニシエーターは各プロトコル実行の新しいSPIを選択します）、暗号化アルゴリズムのセットサーバーは、EAP-kikev22の保護に受け入れます。トラフィック（暗号化と整合性保護）、およびセッションキーの導出。このセットは、セキュリティ協会のペイロード（SAI）にエンコードされています。また、Diffie-Hellmanペイロード（KEI）とNonCeペイロード（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が許容可能なグループに属していると想定されています。ピアは、このプロトコル実行のゼロ以外のレスポンダーSPI値、独自のdiffie-hellman値（ker）およびnonce（nr）を生成し、skeyseed、sk_d、sk_ai、sk_ar、sk_ei、sk_er、sk_pi、およびkeys skeyseed、sk_ai、sk_pi、[1]のセクション2.14によると、SK_PR。ピアはメッセージ4を構築します。ユースケース1、2、および3のコンテキストで、ピアのローカルポリシーは、そのメッセージにオプションのcertreqペイロードを含めることを決定する可能性があります。次のメッセージの公開鍵。ユースケース4のコンテキストでは、ピアには、暗号化されたペイロード内で暗号化され、整合性保護されたEAP-kikev2識別子を含むオプションのsk {idr}ペイロードを含める必要があります。この暗号化されたペイロードを構築するために使用されるキーは、SK_ER（暗号化用）と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]。ResponderのEAP-kikev2識別子（IDR）は、メッセージ5の認証ペイロードの構築のために正しい対称キーまたはパスワードを選択するために、サーバーによるこれらのユースケースで必要になる可能性があります。
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に従って、SKESEED、SK_D、SK_AI、SK_AR、SK_EI、SK_ER、SK_PI、およびSK_PRも計算します。SK {IDR}ペイロードが含まれている場合、サーバーはそれを復号化し、対応するキーとの完全性を確認します。この概要では、復号化と検証が成功すると想定されています。次に、サーバーはメッセージ5を構築します。これには、EAP-kikev2ヘッダーのみが含まれ、その後単一の暗号化されたペイロードが含まれます。暗号化されたペイロードを生成するために使用されるキーは、[1]に従って、SK_EI（暗号化用）およびSK_AI（整合性保護用）でなければなりません。イニシエーターは、次のように、暗号化されたペイロードに少なくとも2つのペイロードを埋め込む必要があります。イニシエーターのEAP-kikev2識別子を使用した識別ペイロードは、暗号化されたペイロードに埋め込む必要があります。認証ペイロードは、暗号化されたペイロードに埋め込む必要があります。証明書のペイロード、および/または証明書リクエストのペイロードも、暗号化されたペイロードに埋め込むことができます。さらに、次の高速再接続識別子ペイロードを暗号化されたペイロードに埋め込むこともできます。メッセージ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]で指定されています。これらのチェックには、暗号化されたペイロードを復号化し、その整合性を確認し、認証ペイロードに期待値が含まれていることをチェックする（ただし、これらに限定されない）が含まれます。すべてのチェックが成功した場合（この概要で想定されています）、Responderはメッセージ6を構築します。そのメッセージは、EAP-kikev2ヘッダーを含む必要があります。その後、単一の暗号化されたペイロードが含まれます。図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のIDRペイロードと同じであることを確認する必要があります。
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-SUCSESSメッセージがメッセージ7としてレスポンダーに送信されます。EAPサーバーとEAPピアは、EAP-kikev2プロトコルの実行に成功した後、マスターセッションキー（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-kikev2の「高速再接続」動作モードを指定します。このモードは実装するのに必須ですが、オプションで使用できます。迅速な再接続の目的は、新鮮なMSKとEMSKをもたらす効率的な再認証手順を有効にすることです。「高速再接続」モードは、サーバーとピアの両方にEAP-kikev2セキュリティコンテキストが既に存在する場合にのみ使用でき、その使用はローカルポリシーの対象となります。言い換えれば、以前のEAP-kirv2プロトコルの実行で相互認証を既に実行している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識別子」を使用します。アイデアは、サーバーが「FAST RECONNECT」プロトコルの実行に従事する意欲を示していることを示しています。オプションの「次のFast-ID」（NFID）ペイロードを「完全な」プロトコルの実行のメッセージ5に含めることにより、将来的に実行されます（図1を参照）、または「高速再接続」プロトコルの実行のメッセージ3では（図2を参照）。このNFIDペイロードには、EAP応答/IDメッセージのネットワークアクセス識別子（NAI）として高速再接続ID（FRID）が示される特別なEAP IDが含まれています。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サーバーのみが、仮名ユーザー名を永続的なIDにマッピングできる必要があります。
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-kikev2には、仮名ユーザー名が使用されている場合、認証交換で仮名ユーザー名を生成した同じEAPサーバーが使用されることを保証するための規定は含まれていません。EAPサーバーは、ホームオペレーターのすべてのEAPサーバーが他のセバーによって生成された仮名を永続的なアイデンティティにマッピングできるようにするためのいくつかの集中メカニズムを実装することをお勧めします。そのようなメカニズムが利用できない場合、EAPサーバーは、別のサーバーによって発行された仮名を理解できないため、パーアに永続的なIDを送信するよう要求できます。
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はNAI文法に準拠する必要があります[4]。オペレーターのサブスクライバーを使用できるEAPサーバーは、生成するフリッドのユーザー名部分が一意であることを確認する必要があります。
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 IDの応答は、「高速再接続」プロトコルの実行の先頭に送信する必要があります。以前の成功した「Full」（RESP。「高速再接続」）EAP-AIKV2プロトコル実行で、サーバーはメッセージ5（Resp。3）にNFIDペイロードを含めていなかった場合、ピアは高速再接続プロトコルを起動してはなりません走る。FRIDを受信すると、サーバーは既存のEAP-kikev2セキュリティコンテキストにマッピングします。ローカルポリシーに応じて、サーバーは「高速再接続」プロトコルの実行を進めるか、「完全な」プロトコル実行のメッセージ3で進行します。サーバーが以前のEAP-akev2プロトコル実行でFRIDを宣伝していた場合、「高速再接続」プロトコルの実行を続行する必要があります。ピアは、EAP IDの応答に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-kikev2高速再接続交換は、[1]のセクション2.18で指定されているように、IKE-SAの再キーイング手順に似ています。したがって、create_child_saリクエストと応答を使用します。これらの2つのメッセージのSPIは、以前の交換で交渉されたSPISです。高速再接続中、サーバーとピアは、新鮮なdiffie-hellman値を交換する場合があります。
1. R<-I: EAP-Request/Identity
1. R <-i：EAP-Request/ID
2. R->I: EAP-Response/Identity(FRID)
2. r-> i：eap-response/ited（frid）
3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi], [NFID]})
3. r <-i：eap-req（hdr、sk {sa、ni、[kei]、[nfid]}）
4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]})
4. r-> i：eap-res（hdr、sk {sa、nr、[ker]}）
5. R<-I: EAP-Success
5. r <-i：eap-success
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-kikev2高速再接続モードのメッセージ交換を示しています。フルモードのように、EAPサーバーはイニシエーターであり、EAPピアはレスポンダーです。最初の2つのメッセージは、標準のEAP ID交換を構成します。「高速再接続」モードを使用するには、メッセージ2を送信する必要があることに注意してください。これは、ピアがメッセージ2でその「高速再接続」IDフリッドを示すことを可能にするためです。
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を既存のEAP-AKEV2コンテキストにマッピングできる場合、メッセージ3で進行します。このメッセージでは、サーバーがNFIDペイロードを暗号化されたペイロードに埋め込み、ピアに新しいFRIDを提供できることに注意してください。サーバーは、完全なEAP-kikev2実行を実行することを選択できます。その場合、図1のメッセージ3の形式に準拠するメッセージで応答します。
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-kikev2セキュリティコンテキストを確立します。メッセージ3では、イニシエーターは、SAペイロードの各提案の下部構造のSPIフィールドの新しい（非ゼロ）値を選択する必要があります（[1]のセクション3.3を参照）。HDRにおけるIKE_SAレスポンダーのSPIフィールドの値は、以前のEAP-kikev2プロトコルの実行からの値でなければなりません。NonCe Payload（Ni）内のNonCeは新鮮でなければならず、Diffie-Hellmanペイロード内のDiffie-Hellman値（存在する場合、KEI）も新鮮でなければなりません。存在する場合、diffie-hellman値は、以前の成功した完全なEAP-kikev2プロトコルの実行で、Diffie-hellman値と同じグループから描画する必要があります。メッセージ3で暗号化されたペイロードを構築するために使用されるアルゴリズムとキーは、以前の成功したEAP-kikev2プロトコルの実行と同じであることに注意してください。
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で想定されているように）、メッセージ4の構築3と同様の方法でメッセージ4を構築します。応答者は、各提案の下部構造のSPIフィールドの新しい（非ゼロ）値を選択する必要があります。メッセージ4を受信すると、イニシエーター（EAPサーバー）が暗号化されたペイロードを復号化および検証します。正しいメッセージ4を受信した場合、このプロトコルの実行は成功し、サーバーはEAP-SUCSESSメッセージで応答します（メッセージ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-kikev2の高速再接続プロトコルの実行が成功した後、イニシエーターとレスポンダーの両方が、その後のEAP-akev2トラフィックの保護に使用される新鮮なキーイング材料を生成します。さらに、イニシエーターとレスポンダーの両方が新鮮な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-kikev2固有のキーイング材料は、完全なEAP-kikev2プロトコルの実行と同じ方法で計算され、[1]のセクション2.18に従って計算されます。つまり、skeyseedはskeyseed = prf（sk_d（old）、[g^ir（new）] | ni | nr）として計算されます。ここで、sk_d（old）は以前に成功したEAP-kikev2プロトコル実行のキーSK_Dです。NRは、メッセージ3と4で交換されたNONCES（非CEペイロードヘッダーなし）であり、g^ir（new）は新しく計算されたdiffie-hellmanキーです。4.残りのEAP-kikev2固有のキー（sk_d、sk_ai、sk_ar、sk_ei、sk_er、sk_pi、sk_pr）は、完全なEAP-kikev2プロトコルの実行と同様に生成されます。
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-kikev2固有のキーの生成に続き、セクション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-kikev2では、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-kikev2高速再接続操作モードに対するリプレイ攻撃を開始しようとすることが考えられます。特に、敵は、以前にキャプチャされたメッセージ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-AikV2でどのように導出されるかについて説明します。MSKとEMSKはEAP-kikev2プロセスによってエクスポートされ、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+.
EAP-kikev2プロトコルの実行中、イニシエーターとレスポンダーは、上記のように[1]のセクション2.14に従って、多くのキーを生成します。これらのキーの生成は、両当事者が使用することに同意しており、反復的な方法で適用される擬似ランダム関数（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.
特に、EAP-kikev2プロトコルの実行が成功した後、両当事者はキーマットを示す128オクテットのキーマットを生成します。図1に示すメッセージ3と4（完全なEAP-kikev2プロトコルの実行のコンテキストで）または図2（高速再接続EAP-kikev2プロトコルの実行のコンテキスト）。Noncesのみが使用されること、つまり、それらを含む非CEペイロード全体ではないことに注意してください。
The first 64 octets of KEYMAT are exported as the EAP MSK, and the second 64 octets are exported as the EMSK.
キーマットの最初の64オクテットはEAP MSKとしてエクスポートされ、2番目の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-kikev2プロトコルの実行が正常に完了しない限り、MSKとEMSKを生成してはなりません。EAP-kikev2メソッドは初期化ベクトルを生成しないことに注意してください[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メソッドがセッションID、Peer-ID、およびサーバーIDと呼ばれる3つの情報要素をエクスポートする必要があります。EAP-kikev2では、これらの要素は次のように導き出されます。
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つの要素の連結として構築およびエクスポートされます。メッセージ3からのNonCeペイロードNiの（c）メッセージ4からのNonCe Payload NRのNonCEデータフィールドの内容。
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-kikev2プロトコルの実行の場合、Peer-IDは、メッセージ6からの識別データフィールドのコンテンツのコンテンツとして構築およびエクスポートされます。ペイロード長フィールド。識別データフィールドにパディングが含まれている場合、このパディングは無視されます。「高速な再接続」プロトコルの実行の場合、Peer-IDフィールドはまったく同じ方法で構築されます。メッセージ6は、EAPピアサーバーとEAPサーバーの間のセキュリティコンテキストを最初に確立した完全なEAP-kikev2プロトコルの実行を指します。
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-kikev2プロトコルの実行の場合、server-idは、メッセージ5からの識別ペイロードIDIの識別データフィールドのコンテンツの内容として構築およびエクスポートされます。ペイロード長フィールド。識別データフィールドにパディングが含まれている場合、このパディングは無視されます。「高速再接続」プロトコルの実行の場合、Server-IDフィールドはまったく同じ方法で構築されます。メッセージ5は、EAPピアサーバーとEAPサーバーの間でセキュリティコンテキストを最初に確立した完全なEAP-kikev2プロトコルの実行を指します。
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-kikev2内でエラーが処理される方法を指定します。ある当事者から別の当事者にエラー情報を伝えるために、通知のペイロードが定義され、使用されます（セクション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-kikev2プロトコルの実行で、認証が失敗した場合（つまり、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-kikev2プロトコルの実行のメッセージ3（図1を参照）で、レスポンダーがサポートされていない（および他のエラーがない場合）グループに属するdiffie-hellman値（KEI）を受信した場合、レスポンダーは、図3に示す形式のメッセージをイニシエーターに送信する必要があります。これは、完全なプロトコル実行で効果的にメッセージ4になります。
1. R<-I: EAP-Request/Identity
1. R <-i：EAP-Request/ID
2. R->I: EAP-Response/Identity(Id)
2. r-> i：EAP-Response/ID（ID）
3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
3. r <-i：eap-req（hdr、sai、kei、ni）
4. R->I: EAP-Res (HDR, N(INVALID_KE_PAYLOAD))
4. r-> i：eap-res（hdr、n（invalid_ke_payload））
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-kikev2ヘッダーと、notifyメッセージタイプフィールド値の値が17に設定された値を持つ通知ペイロードで構成されています（invalid_ke_payload）。[1]のセクション3.10.1で指定されているように、この通知に関連付けられた2オクタート値：選択したDHグループの数。この数値は、イニシエーターとレスポンダーの両方によってサポートされる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-kikev2プロトコルの実行中（図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-kikev2プロトコルの実行中（図1を参照）、イニシエーターはメッセージ4で、存在しないまたは不正なEAP-akev2に復号化するSK {idr}ペイロードを受信します。Responder Identifier IDR*、次に、メッセージ5の形式に準拠したメッセージを使用して、サーバーはプロトコルを継続する必要があります。そのメッセージのAUTHペイロードには、iDR*が有効である場合に含まれる値と計算的に区別できない値を含める必要があります。許可。これは、たとえば、ランダムキーを生成し、通常どおりに認証を計算することで実現できます（ただし、このドキュメントは特定のメカニズムを義務付けません）。メッセージ6を受信した後にのみ、サーバーは認証障害通知、つまり図10にメッセージ6に準拠したメッセージで応答する必要があります。この動作の目的は、敵がEAP-kikev2ピア識別子スペースを調査するのを防ぐことです。
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-kikev2プロトコルの実行中（図1を参照）、イニシエーターはメッセージ4で、EAP-kikev2に復号化するSK {idr}ペイロードを受信します。レスポンダー識別子idr*、サーバーは通常どおりプロトコルを継続する必要があります（これらのユースケースではそのようなペイロードは必要ないことに注意してください）。サーバーは、メッセージ6で受信したIDR*と比較する必要があり、ミスマッチの場合、認証障害通知、つまり図6にメッセージ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-kikev2パケットを静かに破棄する必要があります）。これには、着信EAP-kikev2パケットに関して、次の条件の少なくとも1つが満たされている状況が含まれます。
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 パケットのフィールドには、無効な値が含まれています（たとえば、フラグの無効な組み合わせ、フィールドまたはパケットの実際の長さと矛盾する長さフィールド、または暗号化アルゴリズムのレスポンダーの選択は、それらのいずれかとは異なります。それはイニシエーターによって提供されました）。
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値を持つ2つ以上の変換サブ構造が含まれています）。
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ピアが提供するIDは、確立されたセキュリティコンテキスト（速い再接続の場合）または実際のユーザーアカウント（完全なプロトコル交換の場合）のいずれかに関連付けることはできません。その場合、パケットは静かに破棄されます。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-kikev2データフィールドと該当する処理ルールの形式を指定します。図4は、EAP-kikev2メッセージの一般的なパケット形式と、EAP-kikev2のEAPへの埋め込みを示しています。EAP-kikev2メッセージは、標準の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-kikev2の一般的なパケット形式
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-kayv2メッセージの構成に従って、EAP-kikev2ヘッダー（セクション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-akev2で使用されるプロトコルフィールドを指定します。この仕様は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-kikev2の断片化について説明し、図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-kikev2の断片化サポートは、図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 =より多くのフラグメントi =整合性チェックサムデータが含まれています
Figure 5: Flags Field
図5：フラグフィールド
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.
フラグフィールドは図5に定義されています。最初の3ビット（0-2）のみが使用されます。残りのビットはすべてゼロに設定し、受領時に無視する必要があります。Lフラグは、メッセージの長さフィールドの存在を示し、Mフラグは現在のEAPメッセージにより多くのフラグメントがあるかどうかを示します。特に、図4に示すように、Lビットが設定されている場合、メッセージの長さのフィールドはEAPメッセージに存在する必要があります。メッセージの長さフィールドは4オクテットで、メッセージ全体の長さが含まれています（つまり、長さは長さです。EAPデータフィールドの。）。対照的に、図4に示す長さフィールドには、電流フラグメントの長さのみが含まれていることに注意してください。（長さに関連する2つのフィールドが存在することに注意してください。一般的なEAPフィールドである長さフィールドと、EAP-kikev2固有のフィールドであるメッセージ長のフィールドがあります。）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フラグは、最後のフラグメントを除くすべてのフラグメントに設定する必要があります。最後のフラグメントでは、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-kikev2ピアがMビットセットを使用してEAP-Requestパケットを受け取った場合、EAP-Type = EAP-kikev2を使用した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-Type = EAP-kikev2を使用してEAP-Requestで応答する必要があり、データはありません。これは、フラグメントACKとして機能します。EAPピアは、別のフラグメントを送信する前に、EAP-Requestを受信するまで待つ必要があります。フラグメントの処理のエラーを防ぐために、EAPサーバーはEAP-Request内に含まれる各フラグメント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.
可能な限り、EAP-kikev2メッセージ全体が単一のフラグメントで運ばれる場合を含む、各フラグメントに整合性チェックサムデータフィールドが存在する必要があります（およびiビットセット）。整合性チェックサムデータフィールドの計算に使用されるアルゴリズムとキーは、暗号化されたペイロードの整合性チェックサムデータフィールドを計算するために使用されるものと同一でなければなりません（セクション8.9を参照）。つまり、このEAP-kikev2プロトコルの実行中に交渉および確立されたアルゴリズムとキーが使用されます。これは、各方向の整合性チェックサムデータフィールドを計算するために異なるキーを使用することを意味することに注意してください。また、このアルゴリズムとキーがまだ確立されていないメッセージの場合、整合性チェックサムデータフィールドは計算できないため、含まれていないことに注意してください。これは、たとえば、図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.
断片化されたパケットに対するサービス拒否攻撃への露出を最小限に抑えるために、整合性チェックサムデータフィールドで保護されていないメッセージを断片化してはなりません。ただし、これらのパケットは、証明書を持っていないため、とにかく断片化される可能性が低いことに注意してください。
The EAP-IKEv2 header, denoted HDR in this specification, is constructed and formatted according to the rules specified in Section 3.1 of [1].
この仕様でHDRと表示されたEAP-kikev2ヘッダーは、[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-AikV2メッセージでは、IKE_SA ResponderのSPIフィールドはゼロに設定されています。これは、この時点で、イニシエーターがこのプロトコルの実行に対してレスポンダーが選択するSPI値を知らないためです。他のすべてのメッセージでは、両方のSPIフィールドには、イニシエーターおよびレスポンダーが選択した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-kikev2については、ヘッダーのMJVer（メジャーバージョン）およびMNVER（マイナーバージョン）フィールドはそれぞれ2と0でなければなりません。Exchangeタイプフィールドの値は、メッセージ3および4で34（IKE_SA_INIT）に設定する必要があり、図5および6のメッセージ3および6で35（IKE_SA_AUTH）に設定する必要があります。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-kikev2ヘッダーのフラグフィールドは、[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を運ぶ必要があります0。完全なプロトコルの実行（図1を参照）のメッセージ5および6はメッセージID値を運ぶ必要があります。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-kikev2では、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].
キーエクスチェンジペイロードは、イニシエーターによって構築された場合にkeiを示し、レスポンダーによって構築された場合に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].
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].
識別ペイロードは、イニシエーターの識別子が含まれている場合にIDIを示し、Responderの識別子が含まれている場合は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.
証明書のペイロードは、証明書を示しており、[1]のセクション3.6で指定されたルールに従って構築およびフォーマットされます。EAPサーバー証明書の特定の証明書エンコーディング、たとえば、別のネットワークプロトコルを介して解決する必要があるものは、いくつかの典型的なEAP-kikev2展開シナリオでは使用できないことに注意してください。たとえば、ネットワークアクセスを取得するためにEAP-kikev2を使用して自分自身を認証するユーザーは、EAP-kikev2プロトコルの実行時にサーバー証明書を解決できません。
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].
認証ペイロードは、認証と表現され、[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-kikev2メソッドの場合、パディングストリングが「EAP-kikev2のキーパッド」として再定義されるという点で、このルールがオーバーライドされています。後者のパディングストリングは、EAP-kikev2のコンテキストで共有された秘密からMACキーの導出に使用する必要があります。これは、同じ共有秘密が両方で使用されるシナリオで、IKEV2とEAP-kikev2の両方に使用される同じMACキーを回避するために行われます。コンテキストで共有された秘密（パスワードなど）を使用すると、別のコンテキスト（IKEV2を含む）で使用される共有シークレットと同一または類似したeAP-aikv2を使用することは推奨されません。
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:
次のFast-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].
次のFast-IDペイロードであるNFIDと表示されているのは、IKEV2に相当するものではありません。それにもかかわらず、[1]のセクション3.2に従って、次のペイロードc、予約済み、およびペイロード長のフィールドが構築されます。ペイロードIDはセクション11に登録されています。Fast-Reconnect-IDフィールドには、セクション4で説明されているように、ピアが次の高速再接続プロトコル実行で使用できる高速再接続識別子が含まれています。-reconnect-idには、ユーザー名部分とレルム名部分の両方が含まれます。Fast-Reconnect-IDには、終了したnull文字を含めてはなりません。Fast-Reconnect-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.
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.
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).
セクション3で述べたように、EAP-kikev2では、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-kikev2実装が相互運用可能であるためには、少なくとも1つの共通の暗号化アルゴリズムセットをサポートする必要があります。相互運用性を促進するために、EAP-kikev2の実装は、[5]に示されている「必須/必須」推奨事項に基づいて、次のアルゴリズムをサポートする必要があります。
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アルゴリズム：ENCR_3DES IKEV2変換タイプ2アルゴリズム：PRF_HMAC_SHA1 IKEV2変換タイプ3アルゴリズム：auth_hmac_sha1_96
All other options of [5] MAY be implemented.
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-kikev2について説明します。議論は、セクション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-kikev2プロトコルの実行で受け入れたいと思う一連のcifersuitesを提供します。したがって、サーバーはCiphersuiteを制御しています。指定された暗号網のいずれをサポートしていないEAPピアは、認証できません。ピアのローカルセキュリティポリシーは、ピアが受け入れるシファースーツのセットを指定する必要があります。サーバーは、メッセージ4のピアによって選択されていることとして示されているciphersuiteが、メッセージ3で提供されたciphersuitesのセットに属していることを確認する必要があります。
EAP-IKEv2 supports mutual authentication.
EAP-kikev2は相互認証をサポートします。
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-kikev2は、EAP-kikev2トラフィックの整合性保護を提供します。この保護は、認証が完了した後に提供され、2つの整合性チェックサムデータフィールドを含めることにより促進されます。1つはEAPパケットの最後（図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-kikev2は、さまざまな手段でリプレイ攻撃に対する保護を提供します。これには、認証ペイロードが、とりわけサーバーが提供するノンセとピアが提供する非CEの関数として計算されるという要件が含まれます。これらの非能力は、敵が実質的に予測不可能である必要があります。認証ペイロードの計算に使用されるアルゴリズムには暗号化の弱点が含まれていないと仮定すると、特定のプロトコルの実行で有効な認証ペイロードが後続の実行でも有効である可能性は無視できます。
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-kikev2は、特定のEAP-kikev2フィールド、つまり暗号化されたペイロードに含まれるものの機密性を提供します。アイデンティティの機密性に関して、次の主張がなされます。アイデンティティの機密性は、EAPピアのEAP-aikv2アイデンティティを指すことに注意してください。
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.
IDの機密性は、受動的な敵、つまり輸送中にトラフィックを変更しない敵に直面して提供されます。完全なEAP-kikev2プロトコルのメッセージ4のオプションのsk {idr}ペイロード（図1を参照）が含まれていない場合はいつでも、アクティブな敵に直面して身元の機密性も提供されます。このペイロードは、ユースケース1、2、および3に含めてはなりません。ユースケース4では、このペイロードを含める必要があります。したがって、ユースケース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ピアは、ClearTextの図1のメッセージ2にそのアイデンティティを提供することに注意してください。前の段落で説明したようにアイデンティティの機密性を提供するには、アイデンティティのユーザー名部分を難読化する必要があります（認証、承認、会計（AAA）インフラストラクチャ（AAA）インフラストラクチャによって正しいメッセージルーティングを許可するために、レルム部分は無傷のままでなければなりません）。EAPサーバーは、メッセージ4のID情報を使用します。たとえば、EAP-TTL [8]など、アイデンティティの機密性を提供するために、他のEAPメソッドでも同じメカニズムが使用されます。
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-kikev2は、さまざまなキー強度のセッションキー（MSKおよびEMSK）の確立をサポートし、キーごとに512ビットの理論的最大値（これはMSKとEMSKのサイズであるため）。ただし、実際には、効果的なキー強度は大幅に低くなる可能性が高く、使用される認証資格情報、交渉済みのciphersuite（擬似ランダム関数の出力サイズを含む）、使用された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-kikev2の展開の責任者は、この環境がさらされる可能性のある脅威を考慮し、EAP-kikev2サーバーとピアポリシーと認証資格を構成する必要があります。効果的な重要な強さ。
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.
EAP-kikev2は、セクション1で説明されているように、さまざまなユースケースで使用できます。これらの使用ケースの一部、つまり、パスワードが使用されないため、辞書攻撃は起動できません。
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-kikev2は、パスワードを含む操作がサーバー自体を認証した後にのみ実行されるため、オフラインの辞書攻撃に対する保護を提供します（パスワード以外の資格に基づいて）。
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では、オンライン辞書攻撃に対する露出を減らすために、サーバーは故障したピア認証イベントをログに記録する機能を提供し、短期間で連続した故障したピア認証の試みの場合に適切なポリシーを実装する必要があります（そのような場合（そのような」提案された時間のために、メッセージ5の代わりにEAPフェイルで応答するように）。
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]:
[1]のセクション8で説明されているように、方法4でパスワードを使用する場合（高いエントロピーでキーを使用する代わりに）、辞書攻撃が可能です。
"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.
EAP-kikev2は、セクション4で説明されているように、「高速再接続」動作モードをサポートしています。
EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding does not apply to EAP-IKEv2.
EAP-kikev2はトンネルEAPメソッドではありません。したがって、暗号化結合はEAP-kikev2には適用されません。
EAP-IKEv2 provides session independence in a number of ways, as follows:
EAP-kikev2は、次のように、さまざまな方法でセッションの独立性を提供します。
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-kikev2の会話の知識（すなわち、受動的敵が得る可能性のある情報）では、敵がこれらの会話に起因するマスターセッションキー（MSK）と拡張マスターセッションキー（EMSK）を計算することはできません。これは、敵が後にサーバーおよび/またはこれらの会話で使用されたピアの長期認証資格情報へのアクセスを取得する場合でも保持されます。つまり、EAP-kikev2は「完全なフォワードの秘密」をサポートしています。ただし、このサポートが特定のEAP-kikev2プロトコルの実行で使用されているかどうかは、ピアとサーバーがその実行で使用したdiffie-hellman値を削除する時期と、新鮮なdiffieを使用するかどうかに依存します。 - 各プロトコル実行のヘルマン値。[1]のセクション2.12の議論が適用されます。
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.
第二に、ピアとサーバーの長期認証資格情報がわからないアクティブな敵は、EAP-kikev2の特定のプロトコル実行で確立されたMSKとEMSKを学習できません。他のプロトコルでは、EAP-kikev2の実行。これは、MSKとEMSKが、特に、各プロトコルの実行でランダムに生成されると想定されるデータ項目の関数であるためです。
EAP-IKEv2 provides support for fragmentation, as described in Section 8.1.
EAP-kikev2は、セクション8.1で説明されているように、断片化のサポートを提供します。
Channel binding is not supported in EAP-IKEv2.
チャネル結合は、EAP-kikev2ではサポートされていません。
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-kikev2のセキュリティ請求は次のとおりです。
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-kikev2を示すEAPメソッドタイプに値49を割り当てました。EAP-kikev2は、IANAの割り当てにRFC 3748が義務付けているように、以前に指定された専門家のレビューに合格したことに成功しています。
In addition, IANA has created a new registry for "EAP-IKEv2 Payloads", and populated it with the following initial entries listed below.
さらに、IANAは「EAP-kikev2ペイロード」の新しいレジストリを作成し、以下にリストした以下の初期エントリを入力しました。
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-12は、IKEV2 IANAレジストリの対応するペイロードと一致します。つまり、1〜120の範囲にタイプ値が割り当てられているEAP-kikev2ペイロードには、IKEV2の意味的に同等のペイロードタイプがあり、同一のペイロードタイプ値があります。ただし、IKEV2には、EAP-kikev2に意味的に同等のペイロードを持たないペイロードタイプが存在します。これは、ペイロードタイプの値42、44、および45がEAP-kikev2で割り当てられていないという事実を説明しています。これらの値は、このバージョンのEAP-kikev2のために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-kikev2固有のペイロード、つまりikev2に意味的に同等のペイロードを持たないペイロードに使用されます。この範囲は、IKEV2 IANAレジストリでもこの目的のために予約されていることに注意してください。これは、IKEV2およびEAP-AIKV2プロトコルの異なるものに同じペイロードタイプの値が使用されないことを意味します。
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-kikev2固有のペイロードへの将来の割り当てのために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）に記載されており、必要に応じてIKEV2（1-120）を参照してください。
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-kikev2の実装中に、Krzysztof rzecki、Rafal Mijal、Piotr Marnik、およびPawel Matejskiに感謝しています（http://eap-ikev2.sourceforge.net/を参照）。このドキュメントの以前のバージョンのエラーの。
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ワーキンググループの椅子Jari ArkkoとBernard Abobaによって割り当てられた専門家のレビュアーとしての貴重なコメントについて、Pasi Eronenに感謝します。著者はまた、Guenther Horn、Thomas Otto、Paulo Pagliusi、およびJohn Vollbrechtの洞察に満ちたコメントと提案に感謝したいと思います。パナデザインチームのメンバー。特に、D。ForsbergとA. Yeginも、このドキュメントの初期バージョンに関するコメントを提供しました。パスワードベースの認証の使用に関するフィードバックについて、Hugo 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.
Jari Arkkoのサポートと彼のコメントに感謝したいと思います。最後に、IETFの最後の電話でのコメントについて、チャーリーカウフマン、バーナードアボバ、ポールホフマンに感謝します。
[1] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[1] Kaufman、C.、ed。、「Internet Key Exchange（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.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、ed。、「Extensible認証プロトコル（EAP）」、RFC 3748、2004年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためのRFCで使用するためのキーワード」、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] Schiller、J。、「インターネットで使用する暗号化アルゴリズムバージョン2（IKEV2）（IKEV2）」、RFC 4307、2005年12月。
[6] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[6] Aboba、B。およびD. Simon、「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月、Work in Progress。
[8] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol (EAP-TTLS)", Work in Progress, July 2004.
[8] Funk、P。and S. Blake-Wilson、「Eap Tunneled TLS認証プロトコル（EAP-TTLS）」、2004年7月、進行中の作業。
This appendix illustrates how authentication failures are handled within EAP-IKEv2. Note that authentication failures only occur in full EAP-IKEv2 protocol runs.
この付録は、EAP-kikev2内で認証障害がどのように処理されるかを示しています。認証障害は、完全なEAP-kikev2プロトコルの実行でのみ発生することに注意してください。
Figure 10 shows the message flow in case the EAP peer fails to authenticate the EAP server.
図10は、EAPピアがEAPサーバーの認証に失敗した場合のメッセージフローを示しています。
1. R<-I: EAP-Request/Identity
1. R <-i：EAP-Request/ID
2. R->I: EAP-Response/Identity(Id)
2. r-> i：EAP-Response/ID（ID）
3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
3. r <-i：eap-req（hdr、sai1、kei、ni）
4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
4. r-> i：eap-res（hdr、sar1、ker、nr、[certreq]、[sk {idr}]）
5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH})
5. r <-i：eap-req（hdr、sk {idi、[cert]、[certreq]、[idr]、auth}）
6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)})
6. r-> i：eap-res（hdr、sk {n（authentication_failed）}）
7. R<-I: EAP-Failure
7. r <-i：eap-failure
Figure 10: EAP-IKEv2 with Failed Server Authentication
図10：サーバー認証に失敗したEAP-kikev2
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-kikev2ヘッダー（HDR）のメッセージIDフィールドは、メッセージID値2を運ぶ必要があります。メッセージ7では、EAPフェイルメッセージをEAPサーバーで返す必要があります。
Figure 11 shows the message flow in case the EAP server fails to authenticate the EAP peer.
図11は、EAPサーバーがEAPピアの認証に失敗した場合のメッセージフローを示しています。
1. R<-I: EAP-Request/Identity
1. R <-i：EAP-Request/ID
2. R->I: EAP-Response/Identity(Id)
2. r-> i：EAP-Response/ID（ID）
3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)
3. r <-i：eap-req（hdr、sai1、kei、ni）
4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])
4. r-> i：eap-res（hdr、sar1、ker、nr、[certreq]、[sk {idr}]）
5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH})
5. r <-i：eap-req（hdr、sk {idi、[cert]、[certreq]、auth}）
6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH})
6. r-> i：eap-res（hdr、sk {idr、[cert]、auth}）
7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)})
7. r <-i：eap-req（hdr、sk {n（authentication_failed）}）
8. R->I: EAP-Res (HDR, SK {})
8. r-> i：eap-res（hdr、sk {}）
9. R<-I: EAP-Failure
9. r <-i：eap-failure
Figure 11: EAP-IKEv2 with Failed Peer Authentication
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.
完全に成功した交換と比較して、1つの追加の往復が必要です。メッセージ7では、EAPサーバーは、EAPサクセスメッセージを送信する代わりに、Notifyメッセージタイプ値を24（Authentication_Failed）に設定した通知ペイロードを含む暗号化されたペイロードを含むEAP要求を送信する必要があります。メッセージ7を受信すると、EAPピアは、メッセージ8に示すように、EAPサーバーのエラー表示に応じて空のEAP-kikev2（情報）メッセージを送信する必要があります。メッセージ7および8に、EAP-kikev2のメッセージIDフィールドヘッダー（HDR）はメッセージID値2を運ぶ必要があります。最後に、メッセージ9を使用して、EAPサーバーはEAPフェイルで回答します。
Authors' Addresses
著者のアドレス
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ
EMail: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Dirk Kroeselberg Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Dirk Kroeselberg Nokia Siemens Networks Otto-Hahn-Ring 6 Munich、Bavaria 81739ドイツ
EMail: Dirk.Kroeselberg@nsn.com
Andreas Pashalidis NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Andreas Pashalidis Nec Kurfuersten-Anlage 36 Heidelberg 69115ドイツ
EMail: pashalidis@nw.neclab.eu
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
ヨシヒロ・オバ・トーバ・アメリカ・リサーチ、Inc。1 Telcordia Drive Piscataway、NJ 08854 USA
EMail: yohba@tari.toshiba.com
Florent Bersani France Telecom R&D 38, rue du General Leclerc Issy-Les-Moulineaux, Cedex 92794 France
Florent Bersani France Telecom R＆D 38、Rue du General Leclerc Issy-Les-Moulineaux、Cedex 92794 France
EMail: florent.ftrd@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。