RFC5106 日本語訳
5106 The Extensible Authentication Protocol-Internet Key ExchangeProtocol version 2 (EAP-IKEv2) Method. H. Tschofenig, D. Kroeselberg,A. Pashalidis, Y. Ohba, F. Bersani. February 2008. (Format: TXT=76645 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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
Tschofenigがコメントのために要求するワーキンググループH.をネットワークでつないでください: 5106年のD.Kroeselbergカテゴリ: 実験的なノキアシーメンスは東芝F.ベルサニフランステレコム2008年2月にA.Pashalidis NEC Y.オオバをネットワークでつなぎます。
The Extensible Authentication Protocol-Internet Key Exchange Protocol
version 2 (EAP-IKEv2) Method
Extensible Authenticationプロトコルインターネット・キー・エクスチェンジプロトコルバージョン2(EAP-IKEv2)メソッド
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This document specifies EAP-IKEv2, an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode.
このドキュメントはEAP-IKEv2、インターネット・キー・エクスチェンジ(IKEv2)プロトコルに基づいている拡張認証プロトコル(EAP)メソッドを指定します。 EAP-IKEv2はEAP同輩とEAPサーバの間に互いの認証とセッションの主要な設立を前提とします。それは、認証がパスワードに基づいているテクニックと、高エントロピーの共有されたキーと、公開鍵証明書であるとサポートします。 EAP-IKEv2はさらに暗号のciphersuite交渉(ハッシュ関数の機敏さ、アイデンティティ秘密性(ある運転モードによる)、断片化、および任意の「速く再接続してください」モード)のサポートを提供します。
Tschofenig, et al. Experimental [Page 1] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [1ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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
1. 序論…3 2. 用語…4 3. 概要について議定書の中で述べてください…6 4. 速く再接続してください…9 5. キー派生…12 6. セッションID、同輩ID、およびServer ID…13 7. エラー処理…13 8. プロトコル分野の仕様…16 8.1. 旗、メッセージ長、および保全チェックサムデータ・フィールド…17 8.2. EAP-IKEv2ヘッダー…19 8.3. セキュリティ協会有効搭載量…19 8.4. 主要な交換有効搭載量…20 8.5. 一回だけの有効搭載量…20 8.6. 識別有効搭載量…20 8.7. 有効搭載量を証明してください…20 8.8. 要求有効搭載量を証明してください…20 8.9. 有効搭載量を暗号化します…20 8.10. 認証有効搭載量…20 8.11. 有効搭載量に通知してください…21 8.12. 次の速いID有効搭載量…21 9. 有効搭載量タイプと伸展性…22 10. セキュリティ問題…22 10.1. Ciphersuite交渉を保護します…23 10.2. 互いの認証…23 10.3. 保全保護…23 10.4. 保護を再演してください…23 10.5. 秘密性…23 10.6. 主要な強さ…24 10.7. 辞書攻撃抵抗…24 10.8. 速く再接続してください…25 10.9. 暗号の結合…25 10.10. セッション独立…25 10.11. 断片化…26 10.12. 拘束力があった状態で、精神を集中してください…26 10.13. 概要…26 11. IANA問題…27 12. 貢献者…28 13. 承認…28 14. 参照…29 14.1. 標準の参照…29 14.2. 有益な参照…29 付録A…30
Tschofenig, et al. Experimental [Page 2] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [2ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
1. Introduction
1. 序論
This document specifies EAP-IKEv2, an EAP method that is based on the Internet Key Exchange Protocol version 2 (IKEv2) [1]. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on the following types of credentials:
このドキュメントはEAP-IKEv2、インターネット・キー・エクスチェンジプロトコルバージョン2(IKEv2)[1]に基づいているEAPメソッドを指定します。 EAP-IKEv2はEAP同輩とEAPサーバの間に互いの認証とセッションの主要な設立を前提とします。認証が以下のタイプの資格証明書に基づいているテクニックであるとサポートします:
o Asymmetric key pairs: these are public/private key pairs where the
public key is embedded into a digital certificate, and the
corresponding private key is known only to a single party.
o 非対称の主要な組: これらは公開鍵がデジタル証明書に埋め込まれていて、対応する秘密鍵が独身のパーティーだけにおいて知られている公衆/秘密鍵組です。
o Passwords: these are low-entropy bit strings that are known to
both the server and the peer.
o パスワード: これらはサーバと同輩の両方に知られている低エントロピービット列です。
o Symmetric keys: these are high-entropy bit strings that are known
to both the server and the peer.
o 対称鍵: これらはサーバと同輩の両方に知られている高エントロピービット列です。
It is possible to use a different authentication credential (and thereby technique) for each direction, e.g., the EAP server may authenticate itself using a public/private key pair and the EAP client may authenticate itself using a symmetric key. In particular, the following combinations are expected to be used in practice; these are referred to as "use cases" or "modes" in the remainder of this document:
例えば、EAPサーバは公衆/秘密鍵組を使用することでそれ自体を認証するかもしれません、そして、各方向に、異なった認証資格証明書(そして、その結果、テクニック)を使用するのが可能であり、EAPクライアントは対称鍵を使用することでそれ自体を認証するかもしれません。 特に、実際には以下の組み合わせによって使用されると予想されます。 「ケースを使用してください」この残りにおける「モード」が以下を記録するとき、これらは参照されます。
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
使用ケース2と4で、対称鍵によって主要なスペースから一様に無作為に選ばれると思われることに注意してください。 したがって、対称鍵がパスワードから得られないと思われます。 交換が辞書攻撃に被害を受け易いのでモード4で使用されると、パスワードから対称鍵を得るのは不安定です、さらに詳細にセクション10.7で説明されるように。 (擬似ランダム機能であるとサポートされる限り、また、それぞれのパスワード店によってまたは、あるいはまた、ケース3、使用中であるEAPサーバが平文におけるすべてのパスワードに近づく手段を持たなければならないことに注意してください、値のprf、(パスワード、「EAP-IKEv2"のための主要なPad)、また」
Tschofenig, et al. Experimental [Page 3] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [3ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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.
[1])のセクション8.10とセクション2.15を見てください。 想像できる他の使用が、使用されないケースが予想されるかぎ管理問題のため練習して、本書では考えられていません。
Note that the IKEv2 protocol is able to carry EAP exchanges. By contrast, EAP-IKEv2 does not inherit this capability. That is, it is not possible to tunnel EAP methods inside EAP-IKEv2. Also note that the set of functionality provided by EAP-IKEv2 is similar, but not identical, to that provided by other EAP methods such as, for example, EAP-TLS [6].
IKEv2プロトコルがEAP交換を運ぶことができることに注意してください。 対照的に、EAP-IKEv2はこの能力を引き継ぎません。 すなわち、それはEAP-IKEv2の中のトンネルEAPメソッドに可能ではありません。 また、EAP-IKEv2によって提供された機能性のセットが同様ですが、同じでないことに例えば、EAP-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-IKEv2交換の概要を提供して、その結果、プロトコルメッセージ構成を指定します。
o Section 4 specifies the optional EAP-IKEv2 "fast reconnect" mode
of operation.
o セクション4は「速く再接続してください」という任意のEAP-IKEv2運転モードを指定します。
o Section 5 specifies how exportable session keys are derived.
o セクション5は輸出向きのセッションキーがどう引き出されるかを指定します。
o Section 6 specifies how the Session-ID, Peer-ID, and Server-ID
elements are derived.
o セクション6はSession-ID(ID)Peer-、および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-IKEv2データ・フィールドの形式を指定します。 セクション8.1は断片化がEAP-IKEv2でどう扱われるかを説明します。
o Section 9 specifies the payload type values and describes protocol
extensibility.
o セクション9は、ペイロードタイプ値を指定して、プロトコル伸展性について説明します。
o Section 10 provides a list of claimed security properties.
o セクション10は要求されたセキュリティの特性のリストを提供します。
2. Terminology
2. 用語
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]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
Tschofenig, et al. Experimental [Page 4] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [4ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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で定義されたAuthenticationペイロードに埋め込まれています。
CERT:
本命:
Public key certificate or similar structure.
公開鍵証明書か類似構造物。
CERTREQ:
CERTREQ:
Certificate Request.
要求を証明してください。
NFID:
NFID:
Next Fast-ID payload (see Sections 4 and 8.12)
次のFast-IDペイロード(セクション4と8.12を見ます)
EMSK:
EMSK:
Extended Master Session Key, defined in [2].
[2]で定義された拡張Master Session Key。
HDR:
HDR:
EAP-IKEv2 header, defined in Section 8.2.
セクション8.2で定義されたEAP-IKEv2ヘッダー。
I:
私:
Initiator, the party that sends the first message of an EAP-IKEv2
protocol run. This is always the EAP server.
創始者、EAP-IKEv2の最初のメッセージを送るパーティーは走行について議定書の中で述べます。 いつもこれはEAPサーバです。
MAC:
Mac:
Message Authentication Code. The result of a cryptographic
operation that involves a symmetric key.
通報認証コード。 対称鍵にかかわる暗号の操作の結果。
MSK:
MSK:
Master Session Key, defined in [2].
[2]で定義されたSession Keyをマスタリングしてください。
prf:
prf:
Pseudorandom function: a cryptographic function whose output is
assumed to be indistinguishable from that of a truly random
function.
擬似ランダム機能: 出力が本当に無作為の機能のものから区別がつかないと思われる暗号の機能。
Tschofenig, et al. Experimental [Page 5] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [5ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
R:
R:
Responder, the party that sends the second message of an EAP-IKEv2
protocol run. This is always the EAP peer.
応答者、EAP-IKEv2に関する2番目のメッセージを送るパーティーは走行について議定書の中で述べます。 いつもこれはEAP同輩です。
SA:
SA:
Security Association. In this document, SA denotes a type of
payload that is used for the negotiation of the cryptographic
algorithms that are to be used within an EAP-IKEv2 protocol run.
Specifically, SAi denotes a set of choices that are accepted by an
initiator, and SAr denotes the choice of the responder.
セキュリティ協会。 本書では、SAはEAP-IKEv2プロトコル走行の中で使用されることになっている暗号アルゴリズムの交渉に使用される一種のペイロードを指示します。 明確に、SAiは創始者によって受け入れられる1セットの選択を指示します、そして、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.
非対称のキーにかかわる暗号の操作の結果。 特に、それは1公衆/秘密鍵組の個人的な部分を伴います。
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がEAP-IKEv2の内部のキーを使用することでxがEncryptedペイロードの中に埋め込まれていて、暗号化されて保全によって保護されているのを指示します。 これらのキーは各方向に異なっています。
SK_xx:
SK_xx:
EAP-IKEv2 internal key, defined in Section 2.14 of [1].
[1]のセクション2.14で定義されたEAP-IKEv2の内部のキー。
SKEYSEED:
SKEYSEED:
Keying material, defined in Section 2.14 of [1].
[1]のセクション2.14で定義された材料を合わせます。
3. Protocol Overview
3. プロトコル概要
In this section, the full EAP-IKEv2 protocol run is specified. All messages are sent between two parties, namely an EAP peer and an EAP server. In EAP-IKEv2, the EAP server always assumes the role of the initiator (I), and the EAP peer that of the responder (R) of an exchange.
このセクションでは、完全なEAP-IKEv2プロトコル走行は指定されます。 すべてのメッセージが、すなわち、2回のパーティー、EAP同輩の間に送ってEAPサーバです。EAP-IKEv2では、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-IKEv2メッセージの意味論と形式は、IKEv2[1]でIKE Security Associationの設立に指定されたものと、同様であって、それにしても、同じではありません。 完全なEAP-IKEv2プロトコル走行はEAP-成功かEAP-失敗メッセージのどちらかがあとに続く2つの往復旅行から成ります。 EAPのアイデンティティを交換するための任意の往復旅行は2回の交換に先行するかもしれません。
Tschofenig, et al. Experimental [Page 6] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [6ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
1. R<-I: EAP-Request/Identity
1. R<-I: EAP-要求/アイデンティティ
2. R->I: EAP-Response/Identity(Id)
2. R>I: EAP-応答/アイデンティティ(イド)
3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
3. R<-I: EAP-Req(HDR、サイ、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、[本命]、[CERTREQ]、[NFID]、AUTH)
6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH})
6. R>I: EAP-Res(HDR、SK、IDr、[本命]、AUTH)
7. R<-I: EAP-Success
7. R<-I: EAP-成功
Figure 1: EAP-IKEv2 Full, Successful Protocol Run
図1: EAP-IKEv2の完全で、うまくいっているプロトコル走行
Figure 1 shows the full EAP-IKEv2 protocol run, including the optional EAP identity exchange (messages 1 and 2). A detailed specification of the message composition follows.
図1は任意のEAPアイデンティティ交換を含んでいて、実行された完全なEAP-IKEv2プロトコル(メッセージ1と2)を示しています。 メッセージ構成の仕様詳細は従います。
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 Identity RequestとResponseです。 メッセージ3は最初のEAP-IKEv2特有のメッセージです。 これから、サーバは実際のEAP認証交換を始めます。 それはEAP- IKEv2ヘッダー(HDR)(創始者はそれぞれのプロトコル走行のために新しいSPIを選択する)という創始者Security Parameter Index(SPI)、サーバがEAP-IKEv2トラフィック(暗号化と保全保護)の保護のために受け入れても構わないと思っている暗号アルゴリズムのセット、およびセッションキーの派生を含んでいます。 このセットはSecurity Associationペイロード(SAi)でコード化されます。 また、それはディフィー-ヘルマンペイロード(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を受け取るとき、それはメッセージで提案されるものから1セットの暗号アルゴリズムを選択します。 この概要では、設定された許容できるそのようなものが存在していて(そして、このようにして選択されます)、ディフィー-ヘルマン値のKEiが許容できるグループのものと思われます。 同輩は、次に、それ自身のこのプロトコル走行、ディフィー-ヘルマン値(KEr)、および一回だけ(Nr)のためにa非ゼロResponder SPIが値であると生成して、キーSKEYSEEDを見込みます、SK、SK_ai、SK_ar、SK_ei、SK_、えー、SK_パイ、および[1]のセクション2.14に従ったSK_pr。 そして、同輩はメッセージ4を構成します。 使用ケース1、2、および3の文脈では、同輩のローカルの方針はそのメッセージでの任意のCERTREQペイロードの包含を決めるかもしれません。(メッセージは、次のメッセージの公開鍵のための証明書を含むようにサーバにちょっとほのめかします)。 使用の文脈では、4をケースに入れてください、そして、同輩はペイロード(EAP-IKEv2識別子を含む)がEncryptedペイロードの中に暗号化して、保全して保護した任意のSK IDrを入れなければなりません。 このEncryptedペイロードを構成するのに使用されるキーがSK_である、えー、(暗号化のための) そして、SK_ar(保全保護のための)
Tschofenig, et al. Experimental [Page 7] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [7ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
[1]. The responder's EAP-IKEv2 identifier (IDr) is likely to be needed in these use cases by the server in order to select the correct symmetric key or password for the construction of the AUTH payload of message 5.
[1]. 応答者のEAP-IKEv2識別子(IDr)はこれらで必要であるのがメッセージ5のAUTHペイロードの構造のための正しい対称鍵かパスワードを選択するのにサーバでケースを使用する傾向があります。
Upon reception of message 4, the server also computes SKEYSEED, SK_d,
SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, according to Section
2.14 of [1]. If an SK{IDr} payload is included, the server decrypts
it and verifies its integrity with the corresponding keys. In this
overview, decryption and verification is assumed to succeed. The
server then constructs message 5, which contains only the EAP-IKEv2
header followed by a single Encrypted payload. The keys used to
generate the encrypted payload MUST be SK_ei (for encryption) and
SK_ai (for integrity protection), in accordance with [1]. The
initiator MUST embed at least two payloads in the Encrypted Payload,
as follows. An Identification payload with the initiator's EAP-IKEv2
identifier MUST be embedded in the Encrypted payload. The
Authentication payload MUST be embedded in the Encrypted payload. A
Certificate payload, and/or a Certificate Request payload, MAY also
be embedded in the Encrypted payload. Moreover, a Next Fast-
Reconnect Identifier payload MAY also be embedded in the Encrypted
payload. Message 5 is sent to the responder.
また、メッセージ4のレセプションでは、サーバはSKEYSEEDを計算します、SK、SK_aiです、SK_ar、SK_ei、SK_、えー、SK_パイ、および[1]のセクション2.14に従ったSK_pr。 ペイロードがSK IDrであるなら含まれていて、サーバは、対応するキーでそれを解読して、保全について確かめます。 この概要では、復号化と検証が成功すると思われます。 そして、サーバはメッセージ5を構成します。(それは、ただ一つのEncryptedペイロードが支えたEAP-IKEv2ヘッダーだけを含みます)。 暗号化されたペイロードを生成するのに使用されるキーは、SK_ei(暗号化のための)とSK_aiであるに違いありません(保全保護のための)、[1]によると。 創始者は少なくとも2個のペイロードを以下のEncrypted有効搭載量に埋め込まなければなりません。 創始者のEAP-IKEv2識別子があるIdentificationペイロードをEncryptedペイロードに埋め込まなければなりません。 AuthenticationペイロードをEncryptedペイロードに埋め込まなければなりません。 また、Certificateペイロード、そして/または、Certificate RequestペイロードはEncryptedペイロードに埋め込まれるかもしれません。 そのうえ、Next Fastは再接続します。Identifierペイロードは埋め込むかもしれません、また、Encryptedペイロードに埋め込まれてください。 メッセージ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]で指定されるチェック。 しかし、これらのチェックが含んでいる、(制限されないかもしれない、)、Encryptedペイロードを解読して、保全について確かめて、Authenticationペイロードが期待値を含むのをチェックします。 すべてのチェックが成功するなら(この概要で想定されます)、応答者はメッセージ6を構成します。 そのメッセージはさらなる少なくとも2個のペイロードを埋め込まなければならないただ一つのEncryptedペイロードが支えたEAP-IKEv2ヘッダーを含まなければなりません、図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はじっと見ます)。 上と実行されて、この終わりまで、ケースは使用によっています、ローカルの方針ということであり、復号化を含まなければならないチェックとAuthenticationペイロードが期待値を含むのをチェックすることと同様にEncryptedペイロードの検証として。 任意のSK IDrであるなら、ペイロードはメッセージ4に含まれていました、また、EAPサーバがメッセージ6のIDrペイロードが確実にメッセージ4がそれと同じになるようにしなければなりません。
If authentication succeeds, an EAP-Success message is sent to the responder as message 7. The EAP server and the EAP peer generate a Master Session Key (MSK) and an Extended Master Session Key (EMSK) after a successful EAP-IKEv2 protocol run, according to Section 5.
認証が成功するなら、メッセージ7としてEAP-成功メッセージを応答者に送ります。 EAPサーバとEAP同輩はセクション5によると、実行されたうまくいっているEAP-IKEv2プロトコルの後にMaster Session Key(MSK)とExtended Master Session Key(EMSK)を生成します。
Tschofenig, et al. Experimental [Page 8] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [8ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
4. Fast Reconnect
4. 速く再接続してください。
This section specifies a "fast reconnect" mode of operation for EAP- IKEv2. This mode is mandatory to implement, but optional to use. The purpose of fast reconnect is to enable an efficient re- authentication procedure that also results in a fresh MSK and EMSK. The "fast reconnect" mode can only be used where an EAP-IKEv2 security context already exists at both the server and the peer, and its usage is subject to the local policies. In other words, it can only be used by an EAP server/EAP peer pair that has already performed mutual authentication in a previous EAP-IKEv2 protocol run.
このセクションは「速く再接続してください」という運転モードをEAP- IKEv2に指定します。 このモードは、実装するために義務的ですが、使用するために任意です。 速いことの目的は再接続されます。また、新鮮なMSKとEMSKをもたらす効率的な再認証手順を可能にすることになっています。 EAP-IKEv2セキュリティ文脈がサーバと同輩の両方に既に存在するところで「速く再接続してください」というモードを使用できるだけです、そして、用法はローカルの方針を受けることがあります。 言い換えれば、前のEAP-IKEv2プロトコルにおける既に実行された互いの認証を実行させるEAPサーバ/EAP同輩組はそれを使用できるだけです。
The fast reconnect mode makes use of dedicated "fast reconnect EAP identifiers". The idea is that the server indicates its willingness to engage in "fast reconnect" protocol runs in the future by including the optional "Next Fast-ID" (NFID) payload in message 5 of a "full" protocol run (see Figure 1), or in message 3 of a "fast reconnect" protocol run (see Figure 2). This NFID payload contains a special EAP identity, denoted Fast Reconnect Identity (FRID) as the Network Access Identifier (NAI) in the EAP-Response/Identity message. The FRID contains an obfuscated username part and a realm part. When generating a FRID, the following aspects should be considered:
断食は造が使用するひたむきな「速くEAP識別子を再接続してください」のモードを再接続します。 考えはサーバが、「速く再接続してください」というプロトコルに従事する意欲が将来「完全な」プロトコル走行(図1を見る)に関するメッセージ5、または「速く再接続してください」というプロトコル走行に関するメッセージ3に任意の「次の速いID」(NFID)ペイロードを含んでいることによって稼働するのを(図2を見てください)示すということです。 このNFIDペイロードは特別なEAPのアイデンティティを含んでいます、とFast Reconnect Identity(FRID)はNetwork Access Identifier(NAI)としてEAP-応答/アイデンティティメッセージで指示しました。 FRIDは困惑させられたユーザ名部分と分野の部分を含んでいます。 FRIDを生成するとき、以下の局面は考えられるべきです:
The FRID and therefore the pseudonym usernames are generated by
the EAP server. The EAP server produces pseudonym usernames in an
implementation-dependent manner. Only the EAP server needs to be
able to map the pseudonym username to the permanent identity.
FRIDとしたがって、匿名ユーザ名はEAPサーバによって生成されます。EAPサーバは実装依存する方法による匿名ユーザ名を作り出します。 EAPサーバだけが、匿名ユーザ名を永久的なアイデンティティに写像できる必要があります。
EAP-IKEv2 includes no provisions to ensure that the same EAP
server that generated a pseudonym username will be used on the
authentication exchange when the pseudonym username is used. It
is recommended that the EAP servers implement some centralized
mechanism to allow all EAP servers of the home operator to map
pseudonyms generated by other severs to the permanent identity.
If no such mechanism is available, then the EAP server, failing to
understand a pseudonym issued by another server, can request the
peer to send the permanent identity.
EAP-IKEv2は、匿名ユーザ名が認証交換のときに使用されているとき、匿名ユーザ名を生成したのと同じEAPサーバが使用されるのを保証するために条項を全く含んでいません。 サーバがホームのオペレータのすべてのEAPサーバが他によって生成された匿名を写像するのを許容するために何らかの集結されたメカニズムを実装するEAPが永久的なアイデンティティに切れるのは、お勧めです。 そのような何かメカニズムが利用可能でないなら、別のサーバによって発行された匿名を理解していなくて、EAPサーバは、永久的なアイデンティティを送るよう同輩に要求できます。
When generating FRIDs, the server SHOULD choose a fresh and unique
FRID that is different from the previous ones that were used after
the same full authentication exchange. The FRID SHOULD include a
random component in the username part. The random component works
as a reference to the security context. Regardless of the
construction method, the pseudonym username MUST conform to the
grammar specified for the username portion of an NAI. Also, the
FRID MUST conform to the NAI grammar [4]. The EAP servers, which
subscribers of an operator can use, MUST ensure that the username
part of a FRIDs that they generate are unique.
FRIDsを生成するとき、サーバSHOULDは同じ完全な認証交換の後に使用された前のものと異なった新鮮でユニークなFRIDを選びます。 FRID SHOULDはユーザ名部分に無作為のコンポーネントを含んでいます。 無作為のコンポーネントはセキュリティ文脈の参照として働いています。 工法にかかわらず、匿名ユーザ名はNAIのユーザ名一部に指定された文法に従わなければなりません。 また、FRID MUSTはNAI文法[4]に従います。 EAPサーバ(オペレータの加入者は使用できる)は彼らが生成するFRIDsのユーザ名部分が確実にユニークになるようにしなければなりません。
Tschofenig, et al. Experimental [Page 9] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [9ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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 Identity Responseを送らなければなりません。 前のうまくいっている「完全」(resp。 「速く再接続してください」) EAP-IKEv2は実行について議定書の中で述べて、サーバはメッセージ5にNFIDペイロードを含んでいませんでした。(resp。 3), スタートa断食ではなく、同輩がそうしなければならないその時がプロトコル走行を再接続します。 FRIDのレセプションでは、サーバは既存のEAP- IKEv2セキュリティ文脈にそれを写像します。 ローカルの方針によって、サーバは、「速く再接続してください」というプロトコル走行を続けるか、または「完全な」プロトコル走行に関するメッセージ3を続けます。 サーバが前のEAP-IKEv2にFRIDの広告を出したなら、実行について議定書の中で述べてください、それ。「速く再接続してください」というプロトコルが稼働した状態で、SHOULDは続きます。 同輩は正しく「完全な」プロトコル走行に関するメッセージ3を扱うことができなければなりません、EAP Identity ResponseでFRIDを示したとしても。
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を取っておかないかもしれないので、SHOULDが最も最近少なくとも維持するEAPサーバは最も最近発行されたFRIDに加えてFRIDを使用しました。 認証交換が首尾よく終了されていないなら、サーバは最新のうまくいっている認証交換の間に発行されたFRIDを上書きしてはいけません。
The EAP-IKEv2 fast reconnect exchange is similar to the IKE-SA rekeying procedure, as specified in Section 2.18 of [1]. Thus, it uses a CREATE_CHILD_SA request and response. The SPIs on those two messages would be the SPIs negotiated on the previous exchange. During fast reconnect, the server and the peer MAY exchange fresh Diffie-Hellman values.
EAP-IKEv2は速く再接続します。交換は指定されるとして[1]のセクション2.18でIKE-SA rekeying手順と同様です。 したがって、それはSAが要求するCREATE_CHILD_と応答を使用します。 それらの2つのメッセージのSPIsは前の交換に関して交渉されたSPIsでしょう。 速い間、再接続してください、そして、サーバと同輩は新鮮なディフィー-ヘルマン値を交換してもよいです。
1. R<-I: EAP-Request/Identity
1. R<-I: EAP-要求/アイデンティティ
2. R->I: EAP-Response/Identity(FRID)
2. R>I: EAP-応答/アイデンティティ(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-成功
Figure 2: Fast Reconnect Protocol Run
図2: 速くプロトコル走行を再接続してください。
Figure 2 shows the message exchange for the EAP-IKEv2 fast reconnect mode. As in the full mode, the EAP server is the initiator and the EAP peer is the responder. The first two messages constitute the standard EAP identity exchange. Note that, in order to use the "fast reconnect" mode, message 2 MUST be sent. This is in order to enable the peer to indicate its "fast reconnect" identity FRID in message 2.
図2は、EAP-IKEv2のための交換処理が速くモードを再接続するのを示します。 完全なモードで、EAPサーバが創始者であり、EAP同輩が応答者であるので。 最初の2つのメッセージが標準のEAPアイデンティティ交換を構成します。 「速く再接続してください」というモードを使用するためにメッセージ2を送らなければならないことに注意してください。 これは、同輩がメッセージ2で「速く再接続してください」アイデンティティFRIDを示すのを可能にするそうです。
Tschofenig, et al. Experimental [Page 10] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [10ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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.
サーバが既存のEAP-IKEv2文脈にFRIDを写像できるなら、それはメッセージ3を続けます。 サーバが新しいFRIDを同輩に提供するためにこのメッセージでNFIDペイロードを暗号化されたペイロードに埋め込むかもしれないことに注意してください。 サーバは、完全なEAP-IKEv2走行を実行するのを選ぶかもしれません、その場合、それが図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-IKEv2セキュリティ関係を確立します。 メッセージ3では、創始者は新しい(非ゼロの)値をSAペイロードのそれぞれの提案基礎におけるSPI分野に選択しなければなりません。([1])のセクション3.3を見てください。 SA ResponderのSPIが前のうまくいっているEAP-IKEv2からの1つがプロトコル走行であったならHDR MUSTでさばくIKE_の値。 Nonceペイロード(Ni)における一回だけは新鮮であるに違いありません、そして、また、ディフィー-ヘルマンペイロード(プレゼント、KEiであるなら)におけるディフィー-ヘルマン値も新鮮であるに違いありません。 存在しているなら、前のうまくいっている完全なEAP-IKEv2プロトコル走行におけるディフィー-ヘルマン値と同じグループからディフィー-ヘルマン値を得なければなりません。 前のうまくいっているEAP- IKEv2プロトコル走行のようにメッセージ3でEncryptedペイロードを構成するのに使用されるアルゴリズムとキーが同じであることに注意してください。
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はじっと見る)は、Encryptedペイロードを解読して、確かめます。 うまくいくなら(図2で想定されるように)、それはメッセージ3の工事と同様のファッションによるメッセージ4を構成します。 応答者はそれぞれの提案基礎におけるSPI分野への新しい(非ゼロの)値を選ばなければなりません。 メッセージ4のレセプションでは、創始者(EAPサーバ)は、Encryptedペイロードを解読して、確かめます。 正しいメッセージ4が受信されているなら、このプロトコル走行はうまくいくと考えられます、そして、サーバはEAP-成功メッセージ(メッセージ5)で反応します。
After successful EAP-IKEv2 fast reconnect protocol run, both the initiator and the responder generate fresh keying material that is used for the protection of subsequent EAP-IKEv2 traffic. Furthermore, both the initiator and the responder MUST generate a fresh MSK and EMSK and export them.
うまくいっているEAP-IKEv2が速くプロトコル走行を再接続した後に、創始者と応答者の両方が、新鮮な合わせるのがその後のEAP-IKEv2トラフィックの保護に使用される材料であると生成します。 その上、創始者と応答者の両方が、新鮮なMSKとEMSKを生成して、それらをエクスポートしなければなりません。
The new EAP-IKEv2-specific keying material is computed in the same way as in the full EAP-IKEv2 protocol run, and in accordance with Section 2.18 of [1]. That is, SKEYSEED is computed as SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr), where SK_d (old) is the key SK_d from the previous successful EAP-IKEv2 protocol run, Ni and Nr are the nonces (without the Nonce payload headers) that were exchanged in messages 3 and 4, and g^ir (new) is the newly computed Diffie-Hellman key, if both the values KEi and KEr were present in messages 3 and 4. The remaining EAP-IKEv2-specific keys (SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr) are generated as in the full EAP-IKEv2 protocol run.
同様に、新しいEAP-IKEv2特有の合わせることの材料は完全なEAP-IKEv2プロトコル走行、および[1]のセクション2.18のように計算されます。 SK(古い)は前のうまくいっているEAP-IKEv2プロトコル走行からの主要なSKです、Ni、NrがNiであるところでメッセージ3と4、およびg^で(新しく不-)交換された一回だけ(Nonceペイロードヘッダーのない)はそうです。SKEYSEEDがprfと等しいときにすなわち、SKEYSEEDが計算される、(SK(古い)、[g^、不-、(新しい]| Ni| Nr、)、新たに計算されたディフィー-ヘルマンキー、両方の値であるなら、KEiとKErはメッセージ3と4に存在していました。 そして、残っているEAP-IKEv2特有のキー、(SK、SK_ai、ar_SK SK_はeiされます、SK_、えー、SK_パイ、SK_pr) 完全なEAP-IKEv2が議定書の中で述べるコネとして、実行されて、生成されます。
Tschofenig, et al. Experimental [Page 11] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [11ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
The generation of a fresh MSK and EMSK follows the generation of the EAP-IKEv2-specific keys and adheres to the rules in Section 5.
新鮮なMSKとEMSKの世代は、EAP-IKEv2特有のキーの世代に続いて、セクション5の規則を固く守ります。
Note 1: In EAP-IKEv2, the EAP server initiates the fast reconnect mode and thereby causes fresh session keys to be established.
注意1: EAP-IKEv2、EAPサーバ開始の速さは、モードを再接続して、その結果、新鮮なセッションキーを設立させます。
Note 2: It is conceivable that an adversary tries to launch a replay attack against the EAP-IKEv2 fast reconnect mode of operation. In particular, the adversary may try to send a previously captured message 3 in a subsequent fast reconnect protocol run. This replay attempt will, however, fail because the keys that the responder will use to verify and decrypt the Encrypted payload are changed with every successful reconnect protocol run.
注意2: 速くEAP-IKEv2に対して反射攻撃を始める敵のトライが運転モードを再接続するのが想像できます。 特に、敵はその後の断食における3がプロトコル走行を再接続するという以前に捕らわれているメッセージを送ろうとするかもしれません。 しかしながら、この再生試みが応答者がEncryptedペイロードを確かめて、解読するのに使用するキーを交換するので失敗する、あらゆる、成功、プロトコル走行を再接続してください。
5. Key Derivation
5. 主要な派生
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].
このセクションはMaster Session Key(MSK)とExtended Master Session Key(EMSK)がEAP-IKEv2でどう引き出されるかを説明します。 MSKとEMSKがEAP-IKEv2プロセスによってエクスポートされて、フレームワーク[7]を合わせるEAPによると、使用されると予想されます。
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-IKEv2プロトコル走行の間、創始者と応答者は多くのキーを生成します、セクションの上と、そして、[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-IKEv2プロトコル走行に続いて、特に、双方は合わせることの材料の128の八重奏を生成して、KEYMATとしての指示されたKEYMAT=prfは+(Ni| SK、Nr)です、NiとNrが図1(完全なEAP-IKEv2プロトコル走行の文脈の)か図2に示されたメッセージ3と4からの一回だけ(まさしくヘッダーのないペイロード)(断食の文脈では、EAP-IKEv2プロトコル走行を再接続する)であるところで。 すなわち、一回だけだけが使用されているというメモ、それらを含む全体のNonceペイロードでない。
The first 64 octets of KEYMAT are exported as the EAP MSK, and the second 64 octets are exported as the EMSK.
KEYMATの最初の64の八重奏がEAP MSKとしてエクスポートされます、そして、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-IKEv2プロトコルが稼働しないなら、生成されてください。MSKとEMSK MUST NOT、首尾よく、完成します。 EAP-IKEv2メソッドが初期化処理ベクトル[7]を生産しないことに注意してください。
Tschofenig, et al. Experimental [Page 12] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [12ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
6. Session ID, Peer ID, and Server ID
6. セッションID、同輩ID、およびServer ID
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:
Session-ID、Peer-ID、およびServer-IDは、EAPかぎ管理フレームワーク[7]が、EAPメソッドが3つの情報要素をエクスポートするのを必要とすると呼びました。 EAP-IKEv2では、これらの要素は以下の通り引き出されます:
o The Session-ID is constructed and exported as the concatenation of
the following three elements, in this order: (a) the EAP Code Type
for EAP-IKEv2 (to be defined by IANA), (b) the contents of the
Nonce Data field of the Nonce Payload Ni from message 3, (c) the
contents of the Nonce Data field of the Nonce Payload Nr from
message 4.
o Session-IDは、このオーダーにおける、以下の3つの要素の連結として組み立てられて、エクスポートされます: (a) (b) EAP-IKEv2(IANAによって定義される)のためのEAP Code Type、(c) メッセージ3、メッセージ4からのNonce有効搭載量NrのNonce Data分野のコンテンツからのNonce有効搭載量NiのNonce Data分野のコンテンツ。
o In case of a full EAP-IKEv2 protocol run, the Peer-ID is
constructed and exported as the content of the Identification Data
field of the Identification Payload IDr from message 6. Note that
only the "actual" identification data is exported, as indicated in
the Payload Length field; if the Identification Data field
contains any padding, this padding is ignored. In case of a "fast
reconnect" protocol run, the Peer-ID field is constructed in
exactly the same manner, where message 6 refers to the full EAP-
IKEv2 protocol run that originally established the security
context between the EAP peer and EAP server.
o 完全なEAP-IKEv2プロトコル走行の場合には、Peer-IDは、Identification有効搭載量IDrのIdentification Data分野の内容としてメッセージ6から組み立てられて、エクスポートされます。 「実際」の識別情報だけが有効搭載量Length分野にみられるようにエクスポートされることに注意してください。 Identification Data分野が何か詰め物を含んでいるなら、この詰め物は無視されます。 「速く再接続してください」というプロトコル走行の場合には、Peer-ID分野はまさにメッセージ6が元々EAP同輩とEAPサーバの間のセキュリティ文脈を確立した完全なEAP- IKEv2プロトコル走行について言及するのと同じ方法で構成されます。
o In case of a full EAP-IKEv2 protocol run, the Server-ID is
constructed and exported as the contents of the Identification
Data field of the Identification Payload IDi from message 5. Note
that only the "actual" identification data is exported, as
indicated in the Payload Length field; if the Identification Data
field contains any padding, this padding is ignored. In case of a
"fast reconnect" protocol run, the Server-ID field is constructed
in exactly the same manner, where message 5 refers to the full
EAP-IKEv2 protocol run that originally established the security
context between the EAP peer and EAP server.
o 完全なEAP-IKEv2プロトコル走行の場合には、Server-IDは、Identification有効搭載量IDiのIdentification Data分野のコンテンツとしてメッセージ5から組み立てられて、エクスポートされます。 「実際」の識別情報だけが有効搭載量Length分野にみられるようにエクスポートされることに注意してください。 Identification Data分野が何か詰め物を含んでいるなら、この詰め物は無視されます。 「速く再接続してください」というプロトコル走行の場合には、Server-ID分野はまさにメッセージ5が元々EAP同輩とEAPサーバの間のセキュリティ文脈を確立した完全なEAP-IKEv2プロトコル走行について言及するのと同じ方法で構成されます。
7. Error Handling
7. エラー処理
This section specifies how errors are handled within EAP-IKEv2. For conveying error information from one party to the other, the Notify payload is defined and used (see Section 8.11).
このセクションは誤りがEAP-IKEv2の中でどう扱われるかを指定します。 1回のパーティーからもう片方までエラー情報を伝えるために、Notifyペイロードは、定義されて、使用されます(セクション8.11を見てください)。
If, in a full EAP-IKEv2 protocol run, authentication fails (i.e., the verification of the AUTH field fails at the server or the peer), but no other errors have occurred, the message flow deviates from that described in Section 3. The message flows in the presence of authentication failures are specified in Appendix A.
完全なEAP-IKEv2プロトコル走行では、認証が失敗しますが(すなわち、AUTH分野の検証はサーバか同輩で失敗します)、他の誤りが全く発生していないなら、メッセージ流動はセクション3で説明されたそれから逸れます。 認証失敗があるときメッセージ流れはAppendix Aで指定されます。
Tschofenig, et al. Experimental [Page 13] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [13ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
If, in message 3 of a full EAP-IKEv2 protocol run (see Figure 1), the responder receives a Diffie-Hellman value (KEi) that belongs to a group that is not supported (and in the absence of other errors), then the responder MUST send a message of the form shown in Figure 3 to the initiator. This effectively becomes message 4 in the full protocol run.
応答者が完全なEAP-IKEv2プロトコル走行(図1を見る)に関するメッセージ3でサポートされない(そして他の誤りがないとき)グループに属すディフィー-ヘルマン値(KEi)を受けるなら、応答者は図3で創始者に見せられたフォームに関するメッセージを送らなければなりません。 事実上、これは完全なプロトコル走行におけるメッセージ4になります。
1. R<-I: EAP-Request/Identity
1. R<-I: EAP-要求/アイデンティティ
2. R->I: EAP-Response/Identity(Id)
2. R>I: EAP-応答/アイデンティティ(イド)
3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)
3. R<-I: EAP-Req(HDR、サイ、KEi、Ni)
4. R->I: EAP-Res (HDR, N(INVALID_KE_PAYLOAD))
4. R>I: EAP-Res(HDR、N(無効の_KE_ペイロード))
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.
上記のメッセージは17(INVALID_KE_有効搭載量)にNotify Message Type分野選択値群の値に従ったEAP-IKEv2ヘッダーとNotificationペイロードから成ります。 この通知に関連している2八重奏の値があります: ビッグエンディアンによる選択されたDH Groupの数は[1]についてセクション3.10.1で指定されるように注文されます。 この数は創始者と応答者の両方によってサポートされるDHグループを代表しなければなりません。
If, during a full EAP-IKEv2 protocol run (see Figure 1), the initiator receives a message conforming to Figure 3 instead of the usual message 4, then it MUST check whether or not the indicated DH group was proposed in message 3. If it was not, then the initiator MUST silently discard the message. Otherwise, the protocol continues with a new message 3 that the initiator sends to the peer. In this new message 3, the initiator MUST use a Diffie-Hellman value that is drawn from the group that is indicated in the Notify payload of message 4 in Figure 3.
創始者が完全なEAP-IKEv2プロトコル走行(図1を見る)の間、普通のメッセージ4の代わりに図3に従うメッセージを受け取るなら、それは、示されたDHグループがメッセージ3で提案されたかどうかチェックしなければなりません。 そして、それがそうでなかったなら、創始者は静かにメッセージを捨てなければなりません。 さもなければ、プロトコルは創始者が同輩に発信するという新しいメッセージ3を続行します。 この新しいメッセージ3では、創始者は図3のメッセージ4のNotifyペイロードで示されるグループから得られるディフィー-ヘルマン値を使用しなければなりません。
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
完全なEAP-IKEv2プロトコル走行(図1を見る)の間、使用の文脈では、4をケースに入れて、創始者がメッセージ4で受信し、SK IDrがIDrが*であると実在しないか権限のないEAP-IKEv2応答者識別子に解読するペイロードであるなら、サーバSHOULDはメッセージがメッセージ5の形式に従っているプロトコルを続けています。 メッセージSHOULDがそれがIDr*であるなら含む値から計算上区別がつかない値を含んでいるので、AUTHペイロードは、有効であって、認可されていました。 例えば、ランダムキーと通常通りの計算のAUTHを生成することによって、これを達成できます(しかしながら、このドキュメントは特定のメカニズムを強制しません)。 単にメッセージ6、SHOULDが応じるサーバを受け取ること。
Tschofenig, et al. Experimental [Page 14] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [14ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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.
認証失敗通知、すなわち、図10のメッセージ6に従うメッセージ。 このふるまいの目的は敵がEAP-IKEv2同輩識別子スペースを調べるのを防ぐことです。
If, in the context of use cases 1, 2, or 3 and during a full EAP-
IKEv2 protocol run (see Figure 1), the initiator receives, in message
4, an SK{IDr} payload that decrypts to an EAP-IKEv2 responder
identifier IDr*, then the server MUST continue the protocol as usual
(note that such a payload would not be required in these use cases).
The server MUST compare IDr* with the IDr received in message 6 and,
in case of a mismatch, MUST respond with an authentication failure
notification, i.e., a message conforming to message 6 in Figure 10.
If no mismatch is detected, normal processing applies.
創始者がメッセージ4、SK IDrにケース1、2、または3と完全なEAP- IKEv2プロトコル走行(図1を見る)の間、役に立つ文脈にIDrが*であるとEAP-IKEv2応答者識別子に解読するペイロードを受け取るなら、サーバは通常通りのプロトコルを続けなければなりません(そのようなペイロードがこれらで必要でないだろうというメモはケースを使用します)。 ミスマッチの場合に、サーバは、メッセージ6に受け取られたIDrとIDr*を比べなければならなくて、認証失敗通知(すなわち、図10のメッセージ6に従うメッセージ)で反応しなければなりません。 ミスマッチが全く検出されないなら、正常処理は適用されます。
Other errors do not trigger messages with Notification payloads to be sent, and MUST be treated as if nothing happened (i.e., the erroneous EAP-IKEv2 packet MUST be silently discarded). This includes situations where at least one of the following conditions is met, with respect to an incoming EAP-IKEv2 packet.
他の誤りの送るためにNotificationペイロードでメッセージの引き金とならないで、まるで何も起こらないかのように(静かにすなわち、誤ったEAP-IKEv2パケットを捨てなければなりません)扱わなければなりません。 これは少なくとも以下の条件の1つが入って来るEAP-IKEv2パケットに関して会われる状況を含んでいます。
o The packet contains an Encrypted payload that, when decrypted with
the appropriate key, yields an invalid decryption.
o パケットは適切なキーで解読されると無効の復号化をもたらすEncryptedペイロードを含んでいます。
o The packet contains an Encrypted payload with a Checksum field
that does not verify with the appropriate key.
o パケットはそれが適切なキーで確かめないChecksum分野があるEncryptedペイロードを含んでいます。
o The packet contains an Integrity Checksum Data field (see *Figure
4) that is incorrect.
o パケットは不正確なIntegrity Checksum Data分野(*図4を参照する)を含んでいます。
o The packet does not contain a compulsory field.
o パケットは強制的な分野を含んでいません。
o A field in the packet contains an invalid value (e.g., an invalid
combination of flags, a length field that is inconsistent with the
real length of the field or packet, or the responder's choice of a
cryptographic algorithm is different to NONE and any of those that
were offered by the initiator).
o パケットの分野は無効の値を含んでいます(例えば、旗の無効の組み合わせ、分野かパケットの本当の長さに反している長さの分野、または応答者の暗号アルゴリズムの選択がNONEと創始者によって提供されたもののどれかに異なっています)。
o The packet contains an invalid combination of fields (e.g., it
contains two or more Notify payloads with the same Notify Message
Type value, or two or more Transform substructures with the same
Transform Type and Transform ID value).
o パケットは分野の無効の組み合わせを含んでいます(例えば、それは、同じNotify Message Type値で2個以上のNotifyペイロードを含んでいるか、または同じTransform TypeとTransform ID価値で2つ以上のTransform基礎を含んでいます)。
o The packet causes a defragmentation error.
o パケットはデフラグメンテーション誤りを引き起こします。
o The format of the packet is invalid.
o パケットの形式は無効です。
Tschofenig, et al. Experimental [Page 15] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [15ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
o The identity provided by the EAP peer in the EAP-Response/Identity
cannot be associated with either an established security context
(in case of a fast reconnect) or with a real user account (in case
of a full protocol exchange). In that case, the packet is
silently discarded. With an outstanding message from the EAP
server, the client may either retransmit the previous request or,
in case of a fast reconnect, assume that state information was
deleted (e.g., due to garbage collection) at the EAP server and
fall back to a previously used FRID or to the full protocol
exchange.
o 確立したセキュリティ関係(断食の場合に、再接続する)かリアル・ユーザアカウント(完全なプロトコル交換の場合の)にEAP-応答/アイデンティティにおけるEAP同輩によって提供されたアイデンティティは関連づけることができません。 その場合、パケットは静かに捨てられます。 EAPサーバからの傑出しているメッセージで、クライアントが前の要求を再送するかもしれませんか、断食の場合に再接続してください、そして、州の情報がEAPサーバで削除された(例えば、ガーベージコレクションのため)と仮定してください、そして、または以前中古のFRID、または、完全なプロトコル交換へ後ろへ下がってください。
If an incoming packet contains an error for which a behaviour is specified in this section, and an error that, in the absence of the former error, would cause the packet to be silently discarded, then the packet MUST be silently discarded.
入って来るパケットがふるまいがこのセクションで指定される誤り、および前の誤りがないとき静かにパケットを捨てる誤りを含んでいるなら、静かにパケットを捨てなければなりません。
8. Specification of Protocol Fields
8. プロトコル分野の仕様
In this section, the format of the EAP-IKEv2 data fields and applicable processing rules are specified. Figure 4 shows the general packet format of EAP-IKEv2 messages, and the embedding of EAP-IKEv2 into EAP. The EAP-IKEv2 messages are embedded in the Data field of the standard EAP Request/Response packets. The Code, Identifier, Length, and Type fields are described in [2]. The EAP Type for this EAP method is 49.
このセクションでは、EAP-IKEv2データ・フィールドと適切な処理規則の形式は指定されています。 図4はEAP-IKEv2メッセージの一般的なパケット・フォーマット、およびEAP-IKEv2の埋め込みをEAPに示しています。 EAP-IKEv2メッセージは標準のEAP Request/応答パケットのData分野に埋め込まれています。 Code、Identifier、Length、およびType分野は[2]で説明されます。 このEAPメソッドのためのEAP Typeは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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 旗| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ長| HDR+ペイロード~+++++++++++++++++++++++++++++++++| 保全チェックサムデータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: General Packet Format of EAP-IKEv2
図4: EAP-IKEv2の一般パケット・フォーマット
The Flags field is always present and is used for fragmentation support, as described in Section 8.1. The Message Length field is not always present; its presence is determined by a certain flag in the Flags field, as described in Section 8.1. The field denoted as "HDR + payloads" in Figure 4 contains the EAP-IKEv2 header (see Section 8.2), followed by the number of payloads, in accordance with the composition of EAP-IKEv2 messages, as described in the previous
Flags分野は、セクション8.1で説明されるようにいつも存在していて、断片化サポートに使用されます。 Message Length分野はいつも存在しているというわけではありません。 存在はセクション8.1で説明されるようにFlags分野のある旗で決定します。 図4の「HDR+ペイロード」がペイロードの数があとに続いたEAP-IKEv2ヘッダー(セクション8.2を見る)を含んでいるのでEAP-IKEv2メッセージの構成に従って前で説明されるように指示された分野
Tschofenig, et al. Experimental [Page 16] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [16ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
sections. Note that each payload begins with a generic payload header that is specified in Section 3.2 of [1].
セクション。 各ペイロードが[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.
Integrity Checksum Data分野はいつも存在しているというわけではありません。 存在はセクション8.1で説明されるようにFlags分野のある旗で決定します。
In the remainder of this section, the protocol fields that are used in EAP-IKEv2 are specified. This specification heavily relies on the IKEv2 specification [1], and many fields are constructed, formatted, and processed in way that is almost identical to that in IKEv2. However, certain deviations from standard IKEv2 formatting and processing exist. These deviations are highlighted in the remainder of this section.
このセクションの残りでは、EAP-IKEv2で使用されるプロトコル分野は指定されます。 この仕様が大いにIKEv2仕様[1]を当てにして、多くの分野が、IKEv2でそれとほとんど同じ方法で、構成されて、フォーマットされて、処理されます。 しかしながら、標準のIKEv2形式と処理からのある逸脱は存在しています。 これらの逸脱はこのセクションの残りで目立ちます。
8.1. The Flags, Message Length, and Integrity Checksum Data Fields
8.1. 旗、メッセージ長、および保全チェックサムデータ・フィールド
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.
このセクションは、図4で見せられたFlags、Message Length、およびIntegrity Checksum Data分野に、EAP-IKEv2断片化について説明して、コード化と処理規則を指定します。
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:
図4で見せられたFlagsとMessage Length分野でEAP-IKEv2での断片化サポートを提供します。 これらは、以下の通りコード化されて、使用されます:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|L M I 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |L M I0 0 0 0 0| +-+-+-+-+-+-+-+-+
L = Length included M = More fragments I = Integrity Checksum Data included
保全私=Checksum Dataを含んでいて、L=長さはM=より多くの断片を含んでいました。
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
Flags分野は図5で定義されます。 最初の3ビット(0-2)だけが使用されています。 すべての残っているビットをゼロに設定されて、領収書の上で無視しなければなりません。 L旗はMessage Length分野の存在を示します、そして、M旗は現在のEAPメッセージには、より多くの断片があるかどうかを示します。 Lビットが設定されるなら、Message Length分野はEAPメッセージに特に、存在していなければなりません、図4に示されるように。 Message Length分野は、長い間の4つの八重奏であり、全体のメッセージ(すなわち、EAP Data分野の長さ)の長さを含んでいます。 対照的に、図4に示されたLength分野が現在の断片だけの長さを含むことに注意してください。 (長さ: Lengthに関連する2つの分野が存在することに注意してください。
Tschofenig, et al. Experimental [Page 17] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [17ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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.
(それは、ジェネリックEAP分野です)。(分野はEAP-IKEv2特有の分野です)。分野、およびMessage Length分野。)。 Lビットが設定されないなら、Message Length分野は存在しているはずがありません。
The M flag MUST be set on all fragments except the last one. In the last fragment, the M flag MUST NOT be set. Reliable fragment delivery is provided by the retransmission mechanism of EAP as described below.
Mは最終以外のすべての断片のセットが1つであったに違いないなら弛みます。 最後の断片、旗がそうしなければならないMでは、設定されないでください。 EAPの「再-トランスミッション」メカニズムは以下で説明されるように信頼できる断片配送を提供します。
When an EAP-IKEv2 peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-IKEv2 and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value.
EAP-IKEv2同輩がMがあるEAP-リクエスト・パケットの噛み付いているセットを受け取るとき、それはEAP-IKEv2にもかかわらず、EAP-タイプ=データがないEAP-応答で応じなければなりません。 これは断片ACKとして機能します。 別の断片を送る前にEAP-応答を受けるまで、EAPサーバは待たなければなりません。 断片の処理における誤りを防いで、EAPサーバはEAP-要求の中に含まれた各断片のためにIdentifier分野を増加しなければなりません、そして、同輩はEAP-応答の中に含まれた断片ACKでこのIdentifier値を入れなければなりません。 再送された断片は同じIdentifier値を含むでしょう。
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-IKEv2にもかかわらず、EAP-タイプ=データがないEAP-要求で応じなければなりません。 これは断片ACKとして機能します。 別の断片を送る前にEAP-要求を受け取るまで、EAP同輩は待たなければなりません。 断片の処理における誤りを防いで、EAPサーバはEAP-要求の中に含まれたそれぞれの断片ACKのためにIdentifier値を増加しなければなりません、そして、同輩はEAP応答の中に含まれたその後の断片でこのIdentifier値を入れなければなりません。
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.
Integrity Checksum Data分野は全体のEAPメッセージをカバーする暗号のチェックサムを含んでいます、Code野原から始まって、EAP Data分野の端で終わって。 IビットがFlags分野に設定される場合にだけ、図4に示されたこの分野は存在しています。 Integrity Checksum Data分野はすぐに、詰め物なしでEAP Data野原に続きます。
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
可能であるときはいつも、Integrity Checksum Data分野は各断片へのプレゼント(Iビットはセットした)、全体のEAP-IKEv2が通信するケースを含んでいるのがただ一つの断片で運ばれるということであるに違いありません。 Integrity Checksum Data分野を計算するのに使用されるアルゴリズムとキーはEncrypted有効搭載量のIntegrity Checksum Data分野を計算するのに使用されるものと同じであるに違いありません(セクション8.9を見てください)。 すなわち、このEAP-IKEv2プロトコル走行の間に交渉されて、確立されたアルゴリズムとキーは使用されています。 これが、異なったキーが各方向にIntegrity Checksum Data分野を計算するのに使用されることを意味することに注意してください。 また、メッセージによってそれに注意してください、どこ、これ
Tschofenig, et al. Experimental [Page 18] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [18ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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.
アルゴリズムとキーがまだ確立されていなくて、Integrity Checksum Data分野は、計算できないで、したがって、含まれていません。 例えば、これは図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.
暴露をサービス不能攻撃に最小にするには、断片化しているパケット、Integrity Checksum Data分野SHOULD NOTと共に保護されないメッセージでは断片化されてください。 しかしながら、証明書を運ばないのでそれらのパケットがとにかく断片化されそうにないことに注意してください。
8.2. EAP-IKEv2 Header
8.2. EAP-IKEv2ヘッダー
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は、この仕様で[1]のセクション3.1で指定された規則に従って、EAP-IKEv2ヘッダーが組み立てられて、フォーマットされるのを指示しました。
In the first EAP-IKEv2 message that is sent by the initiator (message 3 in Figure 1), the IKE_SA Responder's SPI field is set to zero. This is because, at this point in time, the initiator does not know what SPI value the responder will choose for this protocol run. In all other messages, both SPI fields MUST contain non-zero values that reflect the initiator- and responder-chosen SPI values.
創始者(図1のメッセージ3)によって送られる最初のEAP-IKEv2メッセージでは、IKE_SA 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]によると、ヘッダーのMjVer(主要なバージョン)とMnVer(小さい方のバージョン)分野は、それぞれEAP-IKEv2のこのバージョンのための、2と0でなければなりません。 メッセージ3と4の34(イケ_SA_INIT)と、そして、図1のメッセージ5と6の35(イケ_SA_AUTH)にExchange Type分野の値を設定しなければなりません。 図2のメッセージ3と4では、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.
また、[1]のセクション3.1によると、EAP-IKEv2ヘッダーのFlags分野は構成されます。 これが図4に示されたFlags分野と同じ分野でないことに注意してください。
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.
Message ID分野は以下の通り構成されます。 完全なプロトコル走行におけるメッセージ3と4はMessage ID価値0を運ばなければなりません。 完全なプロトコル走行(図1を見る)におけるメッセージ5と6はMessage ID価値1を運ばなければなりません。 断食における3と4がプロトコル走行を再接続するというメッセージはMessage ID価値2を運ばなければなりません。
8.3. Security Association Payload
8.3. セキュリティ協会有効搭載量
The SA payload is used for the negotiation of cryptographic algorithms between the initiator and the responder. The rules for its construction adhere to [1]; in particular, Sections 2.7 and 3.3.
SAペイロードは創始者と応答者の間の暗号アルゴリズムの交渉に使用されます。 工事のための規則は[1]を固く守ります。 特にセクション2.7と3.3。
In EAP-IKEv2, all Proposal Substructures in the SA payload MUST carry Protocol ID value 1 (IKE).
EAP-IKEv2では、SAペイロードのすべてのProposal SubstructuresがプロトコルID価値1(IKE)を運ばなければなりません。
Tschofenig, et al. Experimental [Page 19] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [19ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
8.4. Key Exchange Payload
8.4. 主要な交換有効搭載量
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].
Key Exchangeペイロード、応答者によって組み立てられるなら創始者とKErによって組み立てられるならKEiを指示して、[1]のセクション3.4で指定された規則に従って、フォーマットされます。
8.5. Nonce Payload
8.5. 一回だけの有効搭載量
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].
Nonceペイロード、規則に従って、応答者によって組み立てられるなら創始者とNrによって組み立てられて、組み立てられて、フォーマットされるなら、指示されたNiは[1]のセクション3.9で指定しました。
8.6. Identification Payload
8.6. 識別有効搭載量
The Identification payload, denoted IDi if it contains an identifier for the initiator and IDr if it contains an identifier for the responder, is constructed and formatted according to the rules specified in Section 3.5 of [1].
応答者への識別子を含んでいるなら創始者とIDrのための識別子を含んでいるなら、IDiは、[1]のセクション3.5で指定された規則に従って、Identificationペイロードが構成されて、フォーマットされるのを指示しました。
8.7. Certificate Payload
8.7. 証明書有効搭載量
The Certificate payload, denoted CERT, is constructed and formatted according to the rules specified in Section 3.6 of [1]. Note that certain certificate encodings for the EAP server certificate, e.g., those that need to be resolved via another network protocol, cannot be used in some typical EAP-IKEv2 deployment scenarios. A user, for example, that authenticates himself by means of EAP-IKEv2 in order to obtain network access, cannot resolve the server certificate at the time of EAP-IKEv2 protocol execution.
CERTは、[1]のセクション3.6で指定された規則に従って、Certificateペイロードが構成されて、フォーマットされるのを指示しました。 いくつかの典型的なEAP-IKEv2展開シナリオでEAPサーバ証明書のためのある証明書encodings(例えば、別のネットワーク・プロトコルで決議される必要があるもの)を使用できないことに注意してください。 ユーザ、例えば、それはEAP-IKEv2によってネットワークアクセスを得るために自分を認証します、とEAP-IKEv2プロトコル実行時点のサーバ証明書が決議できません。
8.8. Certificate Request Payload
8.8. 証明書要求有効搭載量
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で指定された規則に従って、Certificate Requestペイロードが構成されて、フォーマットされるのを指示しました。
8.9. Encrypted Payload
8.9. 暗号化された有効搭載量
The Encrypted payload, denoted SK{...}, is constructed and formatted
according to the rules specified in Section 3.14 of [1].
Encryptedペイロード、指示されたSK、中で組み立てられて、規則に従ってフォーマットされた…を[1]のセクション3.14を指定しました。
8.10. Authentication Payload
8.10. 認証有効搭載量
The Authentication payload, denoted AUTH, is constructed and formatted according to the rules specified in Sections 2.15 and 3.8 of [1].
AUTHは、[1]のセクション2.15と3.8で指定された規則に従って、Authenticationペイロードが構成されて、フォーマットされるのを指示しました。
The contents of the Authentication payload depend on which party generates this field, the use case, and the algorithm that
Authenticationペイロードの内容がどのパーティーがこの分野を生成するかによって、使用がケースであり、アルゴリズムはそれです。
Tschofenig, et al. Experimental [Page 20] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [20ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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.
このパーティーがそれ自体を認証するのに使用する資格証明書(非対称のキー、対称鍵、またはパスワード)に対応しています。 Authenticationペイロードは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.
Authenticationペイロードを生成するパーティーが共有秘密キー(すなわち、パスワードか対称鍵)に基づいてそれ自体を認証するなら、AuthenticationペイロードはMACを含まなければなりません。 このMACは、[1]のセクション2.15に応じて共有秘密キーから得られるキーを使用することで計算されます。 そのセクションによると、共有秘密キーはストリング「この主要な派生の一部としてのIKEv2"に、主要なパッド」で水増しされます。 EAP-IKEv2メソッドにおいて、詰め物ストリングが「EAP-IKEv2"に、主要なパッド」と再定義されるので、この規則はくつがえされます。 EAP- IKEv2の文脈の共有秘密キーから主要なMACの派生に後者の詰め物ストリングを使用しなければなりません。 同じ共有秘密キーが両方に使用されるシナリオのIKEv2とEAP-IKEv2の両方に使用されるために同じMACキーを避けるためにこれをします。 それにもかかわらず、別の文脈(IKEv2を含んでいる)で使用される共有秘密キーと同じであるか、または同様の文脈EAP-IKEv2の共有秘密キー(例えば、パスワード)を使用するのが、NOT RECOMMENDEDであることに注意してください。
8.11. Notify Payload
8.11. 有効搭載量に通知してください。
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で指定された規則に従って、Notifyペイロードが構成されて、フォーマットされるのを指示しました。 1(IKE_SA)にこのペイロードのプロトコルID分野を設定しなければなりません。
8.12. Next Fast-ID Payload
8.12. 次の速いID有効搭載量
The Next Fast-ID Payload is defined as follows:
Next 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) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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、+++++++++++++++++++++++++++++++++! 次の有効搭載量!C! 予約..ペイロード長..断食..再接続..ID
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
NFIDは、Next Fast-IDペイロードがIKEv2に同等物を持っていないのを指示しました。 それにもかかわらず、[1]のセクション3.2によると、このペイロードのNext有効搭載量、C、RESERVED、および有効搭載量Length分野は構成されます。 ペイロードIDはセクション11に登録されます。 IDを再接続している分野が含むFast aが速く識別子を再接続する、それ、同輩
Tschofenig, et al. Experimental [Page 21] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [21ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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].
次における使用は速くセクション4で説明されるように実行されたプロトコルを再接続できます。 分野の部分が必要であり、IDを再接続しているFastインクルードがユーザ名部分と分野の名前部分の両方である環境で。 FastがIDを再接続しているのが少しの終端空文字も含んではいけません。 FastがIDを再接続している分野のコード化はNAI形式[4]に続かなければなりません。
9. Payload Types and Extensibility
9. 有効搭載量タイプと伸展性
In EAP-IKEv2, each payload is identified by means of a type field, which, as specified in [1], is indicated in the "Next Payload" field of the preceding payload. However, the identifier space from which EAP-IKEv2 payload types are drawn is independent from the payload type space of IKEv2. This is because EAP-IKEv2 and IKEv2 may evolve in a different way and, as such, payload types that appear in one protocol do not necessary appear in the other. An example of this is the "Next Fast-ID" (NFID) payload, which does not exist in IKEv2.
EAP-IKEv2では、各ペイロードはタイプ分野による特定されます。[1]で指定されるように、分野は前のペイロードの「次の有効搭載量」分野で示されます。 しかしながら、EAP-IKEv2ペイロードタイプが引き出される識別子スペースはIKEv2のペイロードタイプスペースから独立しています。 これがEAP-IKEv2とIKEv2が異なった方法で発展するかもしれないからであるそういうものとして、プロトコルがそうしない1つで必要に見えるペイロードタイプがもう片方に現れます。 この例は「次の速いID」(NFID)ペイロードです。(そのペイロードは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.
本書では定義されたペイロードタイプのための値はセクション11に記載されています。 有効搭載量タイプ値13-127はEAP-IKEv2の将来の課題のためにIANAに予約されます。 有効搭載量タイプ値128-255が私的使用目的で互いに同意しているパーティーにあります。
10. Security Considerations
10. セキュリティ問題
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-IKEv2で言及されるように、EAPサーバはいつも創始者(I)の役割を引き受けます、そして、EAP同輩は交換の応答者(R)の役割を引き受けます。 これは、サーバが首尾よく認証された後にこのパスワードにかかわる操作が同輩がパスワードに基づいてそれ自体を認証する(すなわち、使用で、3をケースに入れてください)シナリオで行われるだけであるのを確実にするそうです。 言い換えれば、創始者と応答者の役割のこの課題はそれ自体を認証するのに同輩によって使用されるパスワードでオフライン辞書攻撃に対する保護をもたらします(セクション10.7を見てください)。
In order for two EAP-IKEv2 implementations to be interoperable, they must support at least one common set of cryptographic algorithms. In order to promote interoperability, EAP-IKEv2 implementations MUST support the following algorithms based on the "MUST/MUST-" recommendations given in [5]:
2つのEAP-IKEv2実装が共同利用できるように、それらは少なくとも1つの一般的な暗号アルゴリズムをサポートしなければなりません。相互運用性を促進するために、EAP-IKEv2実装は[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
ディフィー-ヘルマンは分類します: 1024MODPグループIKEv2はタイプ1アルゴリズムを変えます: ENCR_3DES IKEv2はタイプ2つのアルゴリズムを変えます: PRF_HMAC_SHA1 IKEv2はタイプ3つのアルゴリズムを変えます: AUTH_HMAC_SHA1_96
All other options of [5] MAY be implemented.
[5]のすべての別の選択肢が実装されるかもしれません。
Tschofenig, et al. Experimental [Page 22] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [22ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
The remainder of this section describes EAP-IKEv2 in terms of specific security terminology as required by [2]. The discussion makes reference to the use cases defined in Section 1.
このセクションの残りは必要に応じて[2]で特定のセキュリティ用語でEAP-IKEv2について説明します。 議論はセクション1で定義されたケースを使用を参照します。
10.1. Protected Ciphersuite Negotiation
10.1. 保護されたCiphersuite交渉
In message 3, the EAP server provides the set of ciphersuites it is willing to accept in an EAP-IKEv2 protocol run. Hence, the server is in control of the ciphersuite. An EAP peer that does not support any of the indicated ciphersuites is not able to authenticate. The local security policy of the peer MUST specify the set of ciphersuites that the peer accepts. The server MUST verify that the ciphersuite that is indicated as being chosen by the peer in message 4, belongs to the set of ciphersuites that were offered in message 3. If this verification fails, the server MUST silently discard the packet.
メッセージ3に、EAPサーバはそれがEAP-IKEv2プロトコル走行で受け入れても構わないと思っているciphersuitesのセットを提供します。 したがって、サーバはciphersuiteのコントロール中です。 ciphersuitesが認証できない表示のいずれもサポートしないEAP同輩。 同輩のローカルの安全保障政策は同輩が受け入れるciphersuitesのセットを指定しなければなりません。 サーバは、存在として示されるciphersuiteがメッセージ4で同輩で選んで、メッセージ3で提供されたciphersuitesのセットのものを確かめなければなりません。 この検証が失敗するなら、サーバは静かにパケットを捨てなければなりません。
10.2. Mutual Authentication
10.2. 互いの認証
EAP-IKEv2 supports mutual authentication.
EAP-IKEv2は互いの認証をサポートします。
10.3. Integrity Protection
10.3. 保全保護
EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic. This protection is offered after authentication is completed and it is facilitated by inclusion of two Integrity Checksum Data fields: one at the end of the EAP packet (see Figure 4), and one as part of an Encrypted payload (see Section 8.9).
EAP-IKEv2はEAP-IKEv2トラフィックの保全保護を提供します。 認証を終了した後にこの保護を提供します、そして、2つのIntegrity Checksum Data分野の包含でそれを容易にします: EAPパケットの端の1(図4を見る)、およびEncryptedペイロードの一部としての1(セクション8.9を見ます)。
10.4. Replay Protection
10.4. 反復操作による保護
EAP-IKEv2 provides protection against replay attacks by a variety of means. This includes the requirement that the Authentication payload is computed as a function of, among other things, a server-provided nonce and a peer-provided nonce. These nonces are required to be practically unpredictable by an adversary. Assuming that the algorithm that is used to compute the Authentication payload does not contain cryptographic weaknesses, the probability that an Authentication payload that is valid in a particular protocol run will also be valid in a subsequent run is therefore negligible.
EAP-IKEv2はさまざまな手段で反射攻撃に対する保護を提供します。 これはAuthenticationペイロードが特にサーバで提供された一回だけと同輩によって提供された一回だけの機能として計算されるという要件を含んでいます。 敵が実際に予測できないように、これらの一回だけが必要です。 Authenticationペイロードを計算するのに使用されるアルゴリズムが暗号の弱点を含まないと仮定して、したがって、また、特定のプロトコル走行で有効なAuthenticationペイロードがその後の走行で有効になるという確率は取るにたらないです。
10.5. Confidentiality
10.5. 秘密性
EAP-IKEv2 provides confidentiality of certain EAP-IKEv2 fields, namely those included in Encrypted payloads. With respect to identity confidentiality, the following claims are made. Note that identity confidentiality refers to the EAP-IKEv2 identity of the EAP peer.
EAP-IKEv2はある一定のすなわち、Encryptedペイロードにものを含んでいるEAP-IKEv2分野の秘密性を提供します。 アイデンティティ秘密性に関して、以下のクレームをします。 アイデンティティ秘密性がEAP同輩のEAP-IKEv2のアイデンティティについて言及することに注意してください。
Tschofenig, et al. Experimental [Page 23] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [23ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
Identity confidentiality is provided in the face of a passive
adversary, i.e., an adversary that does not modify traffic as it is
in transit. Whenever the optional SK{IDr} payload in message 4 of a
full EAP-IKEv2 protocol (see Figure 1) is not included, identity
confidentiality is also provided in the face of an active adversary.
This payload MUST NOT be included in use cases 1, 2, and 3. In use
case 4, this payload MUST be included. Therefore, in use case 4,
EAP- IKEv2 does not provide identity confidentiality in the face of
an active adversary.
受け身の敵(すなわち、それがトランジット中であってトラフィックを変更しない敵)に直面してアイデンティティ秘密性を提供します。 また、完全なEAP-IKEv2に関するメッセージ4のペイロードが議定書の中で述べる(図1を見ます)任意のSK IDrが含まれていないときはいつも、活発な敵に直面してアイデンティティ秘密性を提供します。 使用ケース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にアイデンティティを提供することに注意してください。 前のパラグラフで議論するようにアイデンティティ秘密性を提供するために、アイデンティティのユーザ名部分を困惑させるのが必要です(分野の部分はAuthentication、Authorization、およびAccounting(AAA)インフラストラクチャで正しいメッセージルーティングを許容するために完全な状態で残らなければなりません)。 そして、EAPサーバはメッセージ4のアイデンティティ情報を使用します。 また、同じメカニズムはアイデンティティ秘密性を提供する他のEAPメソッド、例えば、EAP-TTLS[8]によって使用されます。
10.6. Key Strength
10.6. 主要な強さ
EAP-IKEv2 supports the establishment of session keys (MSK and EMSK) of a variety of key strengths, with the theoretical maximum at 512 bits per key (since this is the size of the MSK and the EMSK). However, in practice, the effective key strength is likely to be significantly lower, and depends on the authentication credentials used, the negotiated ciphersuite (including the output size of the pseudorandom function), the Diffie-Hellman group used, and on the extent to which the assumptions on which the underlying cryptographic algorithms depend really hold. Of the above mechanisms, the one that offers the lowest key strength can be regarded as a measure of the effective key strength of the resulting session keys. Note that this holds for other EAP methods, too.
EAP-IKEv2はさまざまな主要な強さのセッションキー(MSKとEMSK)の設立をサポートします、理論上の最大が1キーあたり512ビットにある状態で(これがMSKとEMSKのサイズであるので)。 しかしながら、有効な主要な強さは、実際には、かなり低い傾向があって、資格証明書が使用した認証、ディフィー-ヘルマングループが使用した交渉されたciphersuite(擬似ランダム機能の出力サイズを含んでいる)と、そして、基本的な暗号アルゴリズムがよる仮定が本当に成立する範囲に依存します。 上のメカニズムでは、最も低い主要な強さを提供するものを結果として起こるセッションキーの有効な主要な強さの基準と見なすことができます。 これが他のEAPメソッドにも当てはまることに注意してください。
Due to the large variety of possible combinations, no indication of a practical effective key strength for MSK or EMSK is given here. However, those responsible for the deployment of EAP-IKEv2 in a particular environment should consider the threats this environment may be exposed to, and configure the EAP-IKEv2 server and peer policies and authentication credentials such that the established session keys are of a sufficiently high effective key strength.
可能な組み合わせの大型変種のため、実用的な有効なMSKかEMSKに、主要な強さのしるしを全くここに与えません。 しかしながら、特定の環境における、EAP-IKEv2の展開が、脅威がこの環境であると考えるべきであるので、責任があるそれらはEAP-IKEv2サーバ、同輩方針、および認証資格証明書を暴露されて、構成するかもしれないので、確立したセッションキーは十分高い有効な主要な強さのものです。
10.7. Dictionary Attack Resistance
10.7. 辞書攻撃抵抗
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-IKEv2はセクション1で説明されるようにさまざまな使用がケースに入れる中古のコネであるかもしれません。 これらの用途場合のいくつかでは、すなわち、ケース1、2を使用してください。そうすれば、どんなパスワードも使用されていないので、4、辞書攻撃に着手できません。
Tschofenig, et al. Experimental [Page 24] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [24ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
In use case 3, EAP-IKEv2 provides protection against offline dictionary attacks, since operations that involve the password are executed only after the server has authenticated itself (based on a credential other than a password).
使用中であり、3をケースに入れてください、とEAP-IKEv2はオフライン辞書攻撃に対する保護を前提とします、サーバがそれ自体(パスワード以外の資格証明書に基づいている)を認証した後にだけパスワードにかかわる操作が実行されるので。
In order to reduce exposure against online dictionary attacks, in use case 3, the server SHOULD provide the capability to log failed peer authentication events, and SHOULD implement a suitable policy in case of consecutive failed peer authentication attempts within a short period of time (such as responding with an EAP-Failure instead of message 5 for a predetermined amount of time).
サーバSHOULDは失敗した同輩認証イベントを登録する能力を提供します、そして、オンライン辞書攻撃に対して暴露を減少させるには、使用中であり、3をケースに入れてください、そして、SHOULDは短期間(EAP-失敗が予定された時間へのメッセージ5の代わりにある状態で応じなどなどの)以内の連続した失敗した同輩認証試みの場合に適当な政策を実施します。
When passwords are used with method 4 (instead of using a key with high entropy), dictionary attacks are possible, as described in Section 8 of [1]:
メソッド4(高いエントロピーがあるキーを使用することの代わりに)でパスワードが使用されるとき、辞書攻撃は可能です、[1]のセクション8で説明されるように:
"When using pre-shared keys, a critical consideration is how to
assure the randomness of these secrets. The strongest practice is
to ensure that any pre-shared key contain as much randomness as
the strongest key being negotiated. Deriving a shared secret from
a password, name, or other low-entropy source is not secure.
These sources are subject to dictionary and social engineering
attacks, among others."
「あらかじめ共有されたキーを使用するとき、重要な考慮はどうこれらの秘密を偶発性に保証するかということです。」 最も強い習慣は、どんなあらかじめ共有されたキーも交渉される中で最も強いキーと同じくらい多くの偶発性を含むのを保証することになっています。 パスワード、名前、または他の低エントロピーソースから共有秘密キーを得るのは安全ではありません。 「これらのソースは辞書を受けることがあります、そして、ソーシャルエンジニアリングは特に攻撃されます。」
Hence, the usage of passwords with mode 4 where the EAP peer and the EAP server rely on a shared secret that was derived from a password is insecure. It is strongly recommended to use mode 3 when passwords are used by the EAP peer.
したがって、EAP同輩とEAPサーバがパスワードから得られた共有秘密キーを当てにするモード4のパスワードの用法は不安定です。 パスワードがEAP同輩によって使用されるとき、それがモード3を使用することが強く勧められます。
10.8. Fast Reconnect
10.8. 速く再接続してください。
EAP-IKEv2 supports a "fast reconnect" mode of operation, as described in Section 4.
EAP-IKEv2はセクション4で説明されるように「速く再接続してください」という運転モードをサポートします。
10.9. Cryptographic Binding
10.9. 暗号の結合
EAP-IKEv2 is not a tunnel EAP method. Thus, cryptographic binding does not apply to EAP-IKEv2.
EAP-IKEv2はトンネルEAPメソッドではありません。 したがって、暗号の結合はEAP-IKEv2に適用されません。
10.10. Session Independence
10.10. セッション独立
EAP-IKEv2 provides session independence in a number of ways, as follows:
EAP-IKEv2は以下の通り多くの方法でセッション独立を提供します:
Firstly, knowledge of captured EAP-IKEv2 conversations (i.e., the information that a passive adversary may obtain) does not enable the adversary to compute the Master Session Key (MSK) and Extended Master Session Key (EMSK) that resulted from these conversations. This
まず第一に、捕らわれているEAP-IKEv2の会話(すなわち、受け身の敵が得るかもしれない情報)に関する知識は、敵がこれらの会話から生じたMaster Session Key(MSK)とExtended Master Session Key(EMSK)を計算するのを可能にしません。 これ
Tschofenig, et al. Experimental [Page 25] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [25ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
holds even in the case where the adversary later obtains access to the server and/or the peer's long-term authentication credentials that were used in these conversations. That is, EAP-IKEv2 provides support for "perfect forward secrecy". However, whether or not this support is made use of in a particular EAP-IKEv2 protocol run, depends on when the peer and the server delete the Diffie-Hellman values that they used in that run, and on whether or not they use fresh Diffie-Hellman values in each protocol run. The discussion in Section 2.12 of [1] applies.
ケースの中の敵が後でサーバへのアクセスを得る船倉、さえそして/または、これらの会話に使用された同輩の長期の認証資格証明書。 すなわち、EAP-IKEv2は「完全な前進の秘密保持」のサポートを提供します。 しかしながら、このサポートが特定のEAP-IKEv2プロトコルで利用されるかどうかが、同輩とサーバがそれらが実行されるので使用したディフィー-ヘルマン値を削除する時と、そして、それらがそれぞれのプロトコル走行に新鮮なディフィー-ヘルマン値を使用するかどうかに稼働していて、よります。 [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- IKEv2の特定のプロトコル走行に設立されたMSKとEMSKを学ぶことができません、EAP-IKEv2の他のプロトコル走行に設立されたMSKとEMSKへのアクセスを得ても。 これはMSKとEMSKが特にそれぞれのプロトコル走行で独自に無作為に生成されると思われるデータ項目の機能であるからです。
10.11. Fragmentation
10.11. 断片化
EAP-IKEv2 provides support for fragmentation, as described in Section 8.1.
EAP-IKEv2はセクション8.1で説明されるように断片化のサポートを提供します。
10.12. Channel Binding
10.12. チャンネル結合
Channel binding is not supported in EAP-IKEv2.
チャンネル結合はEAP-IKEv2でサポートされません。
10.13. Summary
10.13. 概要
EAP security claims are defined in Section 7.2.1 of [2]. The security claims for EAP-IKEv2 are as follows:
EAPセキュリティクレームは[2]についてセクション7.2.1で定義されます。 EAP-IKEv2のためのセキュリティクレームは以下の通りです:
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes; see Section 5
Key strength: Variable
Dictionary attack prot.: Yes; see Section 10.7
Fast reconnect: Yes; see Section 4
Crypt. binding: N/A
Session independence: Yes; see Section 10.10
Fragmentation: Yes; see Section 10.11
Channel binding: No
Ciphersuite交渉: はいMutual認証: はいIntegrity保護: はいReplay保護: はい秘密性: はいKey派生: はい。 セクション5 Keyの強さを見てください: 可変Dictionaryがprotを攻撃する、: はい。 セクション10.7 Fastが再接続するのを見てください: はい。 セクション4 Crypt結合を見てください: N/A Session独立: はい。 セクション10.10 Fragmentationを見てください: はい。 セクション10.11 Channelが付いているのを見てください: いいえ
Tschofenig, et al. Experimental [Page 26] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [26ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
11. IANA Considerations
11. IANA問題
IANA has allocated value 49 for the EAP method type indicating EAP- IKEv2. EAP-IKEv2 has already earlier successfully passed Designated Expert Review as mandated by RFC 3748 for IANA allocations.
IANAはEAP- IKEv2を示すEAPメソッドタイプのために値49を割り当てました。 IANA配分のためにRFC3748によって強制されるようにEAP-IKEv2は前に既に首尾よくDesignated Expert Reviewを渡しました。
In addition, IANA has created a new registry for "EAP-IKEv2 Payloads", and populated it with the following initial entries listed below.
さらに、IANAは「EAP-IKEv2有効搭載量」のために新しい登録を作成して、以下の初期のエントリーが以下に記載されている状態で、それに居住しました。
The following payload type values are used by this document.
以下のペイロードタイプ値はこのドキュメントによって使用されます。
Next Payload Type | Value
----------------------------------+----------------------------------
No Next payload | 0
Security Association payload | 33
Key Exchange payload | 34
Identification payload |
(when sent by initiator, IDi) | 35
Identification payload |
(when sent by responder, IDr) | 36
Certificate payload | 37
Certificate Request payload | 38
Authentication payload | 39
Nonce payload | 40
Notification payload | 41
Vendor ID payload | 43
Encrypted payload | 46
Next Fast-ID payload | 121
RESERVED TO IANA | 1-32, 42, 44-45, 47-120, 122-127
PRIVATE USE | 128-255
次の有効搭載量タイプ| 値----------------------------------+---------------------------------- Nextペイロードがありません。| 0セキュリティAssociationペイロード| 33の主要なExchangeペイロード| 34識別ペイロード| (創始者、IDiによって送られると) | 35識別ペイロード| (応答者、IDrによって送られると) | 36証明書ペイロード| 37証明書Requestペイロード| 38認証ペイロード| 39の一回だけのペイロード| 40通知ペイロード| 41ベンダーIDペイロード| 43の暗号化されたペイロード| 46 次のFast-IDペイロード| 121 IANAに予約されました。| 1-32 42、44-45、47-120、122-127私用| 128-255
Payload type values 1-120 match the corresponding payloads in the IKEv2 IANA registry. That is, the EAP-IKEv2 payloads that have been assigned a type value in the range 1-120 have a semantically equivalent payload type in IKEv2, with an identical payload type value. However, there exist payloads types in IKEv2 that do not have a semantically equivalent payload in EAP-IKEv2; this explains the fact that the payload type values 42, 44, and 45 have not been assigned in EAP-IKEv2; these values remain RESERVED TO IANA for this version of EAP-IKEv2.
有効搭載量タイプ値1-120はIKEv2 IANA登録で対応するペイロードに合っています。 意味的に同等なペイロードはすなわち、範囲1-120でタイプ値を割り当ててあるEAP-IKEv2ペイロードでIKEv2をタイプします、同じペイロードタイプ価値で。 しかしながら、EAP-IKEv2に意味的に同等なペイロードを持っていないIKEv2のペイロードタイプは存在しています。 これで、ペイロードタイプ値42、44、および45がEAP-IKEv2で割り当てられていないという事実がわかります。 これらの値はEAP-IKEv2のこのバージョンのためにRESERVED TO IANAのままで残っています。
Payload type values 121-127 are used for EAP-IKEv2 specific payloads, i.e., for payloads that do not have a semantically equivalent payload in IKEv2. Note that this range has been reserved for this purpose in the IKEv2 IANA registry too. This means that the same payload type values will not be used for different things in IKEv2 and EAP-IKEv2 protocols.
有効搭載量タイプ値121-127はEAP-IKEv2の特定のペイロードに使用されます、すなわち、IKEv2に意味的に同等なペイロードを持っていないペイロードのために。 この範囲がこのためにIKEv2 IANA登録でも予約されたことに注意してください。 これは、同じペイロードタイプ値がIKEv2の別物とEAP-IKEv2プロトコルに使用されないことを意味します。
Tschofenig, et al. Experimental [Page 27] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [27ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
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は将来の課題のためにIANAにEAP-IKEv2特有のペイロードまで予約されます。 有効搭載量タイプ値128-255が私的使用目的で互いに同意しているパーティーにあります。
The semantics of the above-listed payloads is provided in this document (0-127) and refer to IKEv2 when necessary (1-120).
上で記載されたペイロードの意味論に本書では(0-127)を提供します、そして、必要な(1-120)であるときにはIKEv2を参照してください。
New payload type values with a description of their semantic will be assigned after Expert Review. The expert is chosen by the IESG in consultation with the Security Area Directors and the EMU working group chairs (or the working group chairs of a designated successor working group). Updates can be provided based on expert approval only. A designated expert will be appointed by the Security Area Directors. Based on expert approval it is possible to delete entries from the registry or to mark entries as "deprecated".
彼らの意味意志の記述が割り当てられている状態で、新しいペイロードタイプは後Expert Reviewを評価します。 専門家はSecurity AreaディレクターとEMUワーキンググループいす(または、指定された後継者ワーキンググループのワーキンググループいす)との相談でIESGによって選ばれています。 専門の承認だけに基づいてアップデートを提供できます。 指定された専門家はSecurity Areaディレクターによって任命されるでしょう。 専門の承認に基づいて、登録からエントリーを削除するか、または「推奨しない」としてエントリーを示すのが可能です。
Each registration must include the payload type value and the semantic of the payload.
各登録はペイロードタイプ価値とペイロードの意味を含まなければなりません。
12. Contributors
12. 貢献者
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.
作者はクシシトフRzecki、Rafal Mijal、ピオトルMarnik、およびパベルMatejskiに感謝しています。(Matejskiは彼らのEAP- IKEv2( http://eap-ikev2.sourceforge.net/ を見る)の実装の間、非常に貴重なフィードバックを提供して、このドキュメントについて旧バージョンではエラー回数を特定しました)。
13. Acknowledgements
13. 承認
The authors also thank Pasi Eronen for his invaluable comments as expert reviewer assigned by the EAP working group chairs Jari Arkko and Bernard Aboba. The authors would also like to thank Guenther Horn, Thomas Otto, Paulo Pagliusi, and John Vollbrecht for their insightful comments and suggestions. The members of the PANA design team; in particular, D. Forsberg and A. Yegin, also provided comments on the initial version of this document. We would like to thank Hugo Krawczyk for his feedback regarding the usage of the password-based authentication.
また、EAPワーキンググループによって選任された専門の評論家がヤリArkkoとバーナードAbobaをまとめるとき、作者は彼の非常に貴重なコメントについてパシEronenに感謝します。 また、作者は彼らの洞察に満ちたコメントと提案についてグンサーHorn、トーマス・オットー、パウロPagliusi、およびジョンVollbrechtに感謝したがっています。 パーナデザインのメンバーは組になります。 また、特にD.フォルスバーグとA.Yeginはこのドキュメントの初期のバージョンのコメントを提供しました。 パスワードベースの認証の用法に関する彼のフィードバックについてユーゴーKrawczykに感謝申し上げます。
The authors are grateful to the members of the EAP keying design team for their discussion in the area of the EAP Key Management Framework.
作者はEAP Key Management Frameworkの領域での彼らの議論のためにデザインチームを合わせるEAPのメンバーに感謝しています。
We would like to thank Jari Arkko for his support and for his comments. Finally, we would like to thank Charlie Kaufman, Bernard Aboba, and Paul Hoffman for their comments during IETF Last Call.
彼のサポートと彼のコメントについてヤリArkkoに感謝申し上げます。 最終的に、IETF Last Callの間、彼らのコメントについてチャーリー・カウフマン、バーナードAboba、およびポール・ホフマンに感謝申し上げます。
Tschofenig, et al. Experimental [Page 28] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [28ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[1] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[1] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[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.とカールソン、J.とH.Levkowetz、エド、「拡張認証プロトコル(EAP)」、RFC3748(2004年6月)
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
[4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005.
2005年12月の[4]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[5] Schiller, J., "Cryptographic Algorithms for Use in the Internet
Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[5] シラー、J.、「インターネット・キー・エクスチェンジバージョン2(IKEv2)における使用のための暗号アルゴリズム」、RFC4307、2005年12月。
14.2. Informative References
14.2. 有益な参照
[6] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999.
[6]AbobaとB.とD.サイモン、「ppp EAP TLS認証プロトコル」、RFC2716、1999年10月。
[7] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", Work in Progress, February 2007.
[7] B.、「拡張認証プロトコル(EAP)Key Managementフレームワーク」というAbobaは進歩、2007年2月に働いています。
[8] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
Protocol (EAP-TTLS)", Work in Progress, July 2004.
[8] 「EAPはTLS認証プロトコル(EAP-TTLS)にトンネルを堀った」というファンク、P.、およびS.ブレーク-ウィルソンは進歩、2004年7月に働いています。
Tschofenig, et al. Experimental [Page 29] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [29ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
Appendix A. EAP-IKEv2 Protocol Runs with Failed Authentication
付録A.EAP-IKEv2プロトコルは失敗した認証と共に稼働しています。
This appendix illustrates how authentication failures are handled within EAP-IKEv2. Note that authentication failures only occur in full EAP-IKEv2 protocol runs.
この付録は認証失敗がEAP-IKEv2の中でどう扱われるかを例証します。 認証失敗が完全なEAP-IKEv2プロトコル走行で起こるだけであることに注意してください。
Figure 10 shows the message flow in case the EAP peer fails to authenticate the EAP server.
EAP同輩がEAPサーバを認証しないといけないので、図10はメッセージ流動を示しています。
1. R<-I: EAP-Request/Identity
1. R<-I: EAP-要求/アイデンティティ
2. R->I: EAP-Response/Identity(Id)
2. R>I: EAP-応答/アイデンティティ(イド)
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、[本命]、[CERTREQ]、[IDr]、AUTH)
6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)})
6. R>I: EAP-Res(HDR、SK N(認証_は失敗しました))
7. R<-I: EAP-Failure
7. R<-I: EAP-失敗
Figure 10: EAP-IKEv2 with Failed Server Authentication
図10: 失敗したサーバー証明があるEAP-IKEv2
The difference in the full successful exchange described in Section 3 is that, in message 6, the EAP peer MUST answer the EAP server with an Encrypted payload that contains a Notify payload with the Notify Message Type value set to 24 (AUTHENTICATION_FAILED). In that message, the Message ID field in the EAP-IKEv2 header (HDR) MUST carry Message ID value 2. In message 7, an EAP-Failure message MUST be returned by the EAP server.
セクション3で説明された完全なうまくいっている交換の違いは24(AUTHENTICATION_FAILED)にNotify Message Type選択値群があるNotifyペイロードを含むEncryptedペイロードでEAP同輩がメッセージ6でEAPサーバに答えなければならないということです。 そのメッセージでは、EAP-IKEv2ヘッダー(HDR)のMessage ID分野はMessage ID価値2を運ばなければなりません。 メッセージ7では、EAPサーバはEAP-失敗メッセージを返さなければなりません。
Tschofenig, et al. Experimental [Page 30] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [30ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
Figure 11 shows the message flow in case the EAP server fails to authenticate the EAP peer.
EAPサーバがEAP同輩を認証しないといけないので、図11はメッセージ流動を示しています。
1. R<-I: EAP-Request/Identity
1. R<-I: EAP-要求/アイデンティティ
2. R->I: EAP-Response/Identity(Id)
2. R>I: EAP-応答/アイデンティティ(イド)
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、[本命]、[CERTREQ]、AUTH)
6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH})
6. R>I: EAP-Res(HDR、SK、IDr、[本命]、AUTH)
7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)})
7. R<-I: EAP-Req(HDR、SK N(認証_は失敗しました))
8. R->I: EAP-Res (HDR, SK {})
8. R>I: EAP-Res(HDR、SK、)
9. R<-I: EAP-Failure
9. R<-I: EAP-失敗
Figure 11: EAP-IKEv2 with Failed Peer Authentication
図11: 失敗した同輩認証があるEAP-IKEv2
Compared to the full successful exchange, one additional roundtrip is required. In message 7, the EAP server MUST send an EAP request with Encrypted payload that contains a Notify payload with the Notify Message Type value set to 24 (AUTHENTICATION_FAILED), instead of sending an EAP-Success message. The EAP peer, upon receiving message 7, MUST send an empty EAP-IKEv2 (informational) message in reply to the EAP server's error indication, as shown in message 8. In messages 7 and 8, the Message ID field in the EAP-IKEv2 header (HDR) MUST carry Message ID value 2. Finally, by means of message 9, the EAP server answers with an EAP-Failure.
完全なうまくいっている交換と比べて、1つの追加往復旅行が必要です。 メッセージ7では、EAPサーバは24(AUTHENTICATION_FAILED)にNotify Message Type選択値群があるNotifyペイロードを含むEncryptedペイロードによるEAP要求を送らなければなりません、EAP-成功メッセージを送ることの代わりに。 メッセージ7を受け取るとき、EAP同輩はEAPサーバの誤り表示に対して空のEAP-IKEv2(情報)のメッセージを送らなければなりません、メッセージ8に示されるように。 メッセージ7と8では、EAP-IKEv2ヘッダー(HDR)のMessage ID分野はMessage ID価値2を運ばなければなりません。 最終的に、メッセージ9によって、EAPサーバにEAP-失敗で答えます。
Tschofenig, et al. Experimental [Page 31] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [31ページ]実験的なRFC5106EAP-IKEv2メソッド2008年2月
Authors' Addresses
作者のアドレス
Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
ハンネスTschofenigノキアシーメンスはオットーハーン一味6ミュンヘン、バイエルン81739ドイツをネットワークでつなぎます。
EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com
メール: Hannes.Tschofenig@nsn.com ユリ: http://www.tschofenig.com
Dirk Kroeselberg Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
短剣Kroeselbergノキアジーメンスはオットーハーン一味6ミュンヘン、バイエルン81739ドイツをネットワークでつなぎます。
EMail: Dirk.Kroeselberg@nsn.com
メール: Dirk.Kroeselberg@nsn.com
Andreas Pashalidis NEC Kurfuersten-Anlage 36 Heidelberg 69115 Germany
アンドレアスPashalidis NEC Kurfuersten-原基36ハイデルベルグ69115ドイツ
EMail: pashalidis@nw.neclab.eu
メール: pashalidis@nw.neclab.eu
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
芳広オオバ東芝アメリカ研究Inc.1Telcordia Driveニュージャージー08854ピスキャタウェイ(米国)
EMail: yohba@tari.toshiba.com
メール: yohba@tari.toshiba.com
Florent Bersani France Telecom R&D 38, rue du General Leclerc Issy-Les-Moulineaux, Cedex 92794 France
フローランベルサニフランステレコムR&D38、悔悟du司令官ルクレールIssyレスMoulineaux、Cedex92794フランス
EMail: florent.ftrd@gmail.com
メール: florent.ftrd@gmail.com
Tschofenig, et al. Experimental [Page 32] RFC 5106 EAP-IKEv2 Method February 2008
Tschofenig、他 [32ページ]実験的なRFC5106EAP-IKEv2方法2008年2月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Tschofenig, et al. Experimental [Page 33]
Tschofenig、他 実験的[33ページ]
一覧
スポンサーリンク
