RFC5296 日本語訳
5296 EAP Extensions for EAP Re-authentication Protocol (ERP). V.Narayanan, L. Dondeti. August 2008. (Format: TXT=98264 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group V. Narayanan
Request for Comments: 5296 L. Dondeti
Category: Standards Track Qualcomm, Inc.
August 2008
コメントを求めるワーキンググループV.ナラヤナンの要求をネットワークでつないでください: 5296年のL.Dondetiカテゴリ: 標準化過程クアルコムInc.2008年8月
EAP Extensions for EAP Re-authentication Protocol (ERP)
EAP再認証プロトコルのためのEAP拡張子(ERP)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting.
拡張認証プロトコル(EAP)は複数のタイプの認証方法をサポートするジェネリックフレームワークです。 EAPが認証に使用されるシステムでは、別の固有識別文字で全体のEAP交換を繰り返さないのは望ましいです。 このドキュメントは同輩とEAP再認証サーバの間の効率的な再認証のためにどんな固有識別文字を通してもEAPのメソッドから独立しているプロトコルをサポートするために階層構造を合わせるEAPとEAPに拡大を指定します。 ホームネットワークか同輩が接続している企業内情報通信網には再認証サーバがあるかもしれません。
Narayanan & Dondeti Standards Track [Page 1] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 6
3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 8
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 11
4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 12
4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 12
4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 13
4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 14
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 15
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 15
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 20
5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 21
5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 22
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 23
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 25
5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 26
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 29
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 31
7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Example ERP Exchange . . . . . . . . . . . . . . . . 42
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 ERP記述. . . . . . . . . . . . . . . . . . . . . . . 5 3.1。 ホームがあるERP、えー、サーバ. . . . . . . . . . . . . . . 6 3.2 ローカルがいるERP、えー、サーバ. . . . . . . . . . . . . . . . 8 4 えー、主要な階層構造. . . . . . . . . . . . . . . . . . . . . . . 10 4.1rRK。派生. . . . . . . . . . . . . . . . . . . . . . 11 4.2rRKの特性. . . . . . . . . . . . . . . . . . . . . . 12 4.3のrIK派生. . . . . . . . . . . . . . . . . . . . . . 12 4; 4. rIKの特性. . . . . . . . . . . . . . . . . . . . . . 13 4.5のrIK用法. . . . . . . . . . . . . . . . . . . . . . . . 13 4.6rMSK派生. . . . . . . . . . . . . . . . . . . . . 14 4.7rMSKの特性. . . . . . . . . . . . . . . . . . . . . 15 5。 詳細. . . . . . . . . . . . . . . . . . . . . . . 15 5.1について議定書の中で述べてください。 ERPブートストラップ法. . . . . . . . . . . . . . . . . . . . 15 5.2。 ERP. . . . . . . . . . . . . . . . . . . . . . . 18 5.2.1におけるステップ。 ERP. . . . . . . . . . 20 5.2.2の複数の同時の走行。 ERP失敗取り扱. . . . . . . . . . . . . . . . . 21 5.3い。 新しいEAPパケット. . . . . . . . . . . . . . . . . . . . . 22 5.3.1。 authの再EAP-開始/スタートパケット. . . . . . . . . . 23 5.3.2。 再EAP-開始/authパケット. . . . . . . . . . . . . 25 5.3.3。 再EAP-終わり/authパケット. . . . . . . . . . . . . . 26 5.3.4。 テレビとTLV属性. . . . . . . . . . . . . . . . 29 5.4。 保護. . . . . . . . . . . . . . . . . . . . 30 5.5を再演してください。 チャンネル結合. . . . . . . . . . . . . . . . . . . . . 30 6。 下層問題. . . . . . . . . . . . . . . . . . 31 7。 ERPメッセージ. . . . . . . . . . . . . . . . . . 32 8の輸送。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 33 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 37 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 39 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 39 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 39 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 40付録A.例のERP交換. . . . . . . . . . . . . . . . 42
Narayanan & Dondeti Standards Track [Page 2] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[2ページ]。
1. Introduction
1. 序論
The Extensible Authentication Protocol (EAP) is a an authentication framework that supports multiple authentication methods. The primary purpose is network access authentication, and a key-generating method is used when the lower layer wants to enforce access control. The EAP keying hierarchy defines two keys to be derived by all key- generating EAP methods: the Master Session Key (MSK) and the Extended MSK (EMSK). In the most common deployment scenario, an EAP peer and an EAP server authenticate each other through a third party known as the EAP authenticator. The EAP authenticator or an entity controlled by the EAP authenticator enforces access control. After successful authentication, the EAP server transports the MSK to the EAP authenticator; the EAP authenticator and the EAP peer establish transient session keys (TSKs) using the MSK as the authentication key, key derivation key, or a key transport key, and use the TSK for per-packet access enforcement.
拡張認証プロトコル(EAP)はaです。複数の認証がメソッドであるとサポートする認証フレームワーク。 プライマリ目的はネットワークアクセス認証です、そして、アクセスコントロールを実施する下層必需品であるときに、キーを生成するメソッドは使用されています。 階層構造を合わせるEAPはEAPにメソッドを生成しながらすべてのキーによって引き出されるために2個のキーを定義します: マスターセッションキー(MSK)と拡張MSK(EMSK)。 最も一般的な展開シナリオでは、EAP同輩とEAPサーバはEAP固有識別文字として知られている第三者を通して互いを認証します。 EAP固有識別文字によって制御されたEAP固有識別文字か実体がアクセスコントロールを実施します。 うまくいっている認証の後に、EAPサーバはEAP固有識別文字にMSKを輸送します。 EAP固有識別文字とEAP同輩は、認証の主要で、主要な派生キー、または主要な輸送キーとしてMSKを使用することで一時的なセッションキー(TSKs)を設立して、1パケットあたりのアクセス実施にTSKを使用します。
When a peer moves from one authenticator to another, it is desirable to avoid a full EAP authentication to support fast handovers. The full EAP exchange with another run of the EAP method can take several round trips and significant time to complete, causing delays in handover times. Some EAP methods specify the use of state from the initial authentication to optimize re-authentications by reducing the computational overhead, but method-specific re-authentication takes at least 2 round trips with the original EAP server in most cases (e.g., [6]). It is also important to note that several methods do not offer support for re-authentication.
同輩が1つの固有識別文字から別の固有識別文字まで移行するとき、速い身柄の引き渡しをサポートするために完全なEAP認証を避けるのは望ましいです。 EAPメソッドの別の走行による完全なEAP交換は終了する旅行と重要な時間を数個持ち回ることができます、引き渡し時代に遅れをきたして。 いくつかのEAPメソッドがコンピュータのオーバーヘッドを下げることによって再認証を最適化するために初期の認証から状態の使用を指定しますが、多くの場合、メソッド特有の再認証はオリジナルのEAPサーバで少なくとも2つの周遊旅行取ります。(例えば、[6])。 また、いくつかのメソッドが再認証のサポートを提供しないことに注意するのも重要です。
Key sharing across authenticators is sometimes used as a practical solution to lower handover times. In that case, compromise of an authenticator results in compromise of keying material established via other authenticators. Other solutions for fast re-authentication exist in the literature [7] [8].
固有識別文字の向こう側の主要な共有は、引き渡し時間を下ろすのに実際的な解決として時々使用されます。 その場合、固有識別文字の感染は材料が他の固有識別文字で設立した合わせることの感染をもたらします。 速い再認証のための他のソリューションは文学[7][8]に存在しています。
In conclusion, to achieve low latency handovers, there is a need for a method-independent re-authentication protocol that completes in less than 2 round trips, preferably with a local server. The EAP re-authentication problem statement is described in detail in [9].
結論として、低遅延身柄の引き渡しを達成するために、2未満で周遊旅行を終了するメソッドから独立している再認証プロトコルの必要があります、望ましくはローカルサーバで。EAP再認証問題声明は[9]で詳細に説明されます。
This document specifies EAP Re-authentication Extensions (ERXs) for efficient re-authentication using EAP. The protocol that uses these extensions itself is referred to as the EAP Re-authentication Protocol (ERP). It supports EAP method-independent re-authentication for a peer that has valid, unexpired key material from a previously performed EAP authentication. The protocol and the key hierarchy required for EAP re-authentication are described in this document.
このドキュメントは、EAPを使用することでEAP Re-認証Extensions(ERXs)を効率的な再認証に指定します。 これらの拡張子を使用するプロトコル自体はEAP Re-認証プロトコル(ERP)と呼ばれます。 それは、以前に実行されたEAP認証からの有効で、満期になっていない主要な材料を持っている同輩のためにEAPがメソッドから独立している再認証であるとサポートします。 EAP再認証に必要であるプロトコルと主要な階層構造は本書では説明されます。
Narayanan & Dondeti Standards Track [Page 3] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[3ページ]。
Note that to support ERP, lower-layer specifications may need to be revised to allow carrying EAP messages that have a code value higher than 4 and to accommodate the peer-initiated nature of ERP. Specifically, the IEEE802.1x specification must be revised and RFC 4306 must be updated to carry ERP messages.
ERPをサポートするのに、下層仕様が、コード値を4より高くするEAPメッセージを伝えるのを許容して、ERPの同輩によって開始された自然に対応するために改訂される必要であるかもしれないことに注意してください。 明確に、IEEE802.1x仕様を改訂しなければなりません、そして、ERPメッセージを伝えるためにRFC4306をアップデートしなければなりません。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
This document uses the basic EAP terminology [2] and EMSK keying hierarchy terminology [3]. In addition, this document uses the following terms:
このドキュメントは基本的なEAP用語[2]と階層構造用語[3]を合わせるEMSKを使用します。 さらに、このドキュメントは次の用語を使用します:
ER Peer - An EAP peer that supports the EAP Re-authentication
Protocol. All references to "peer" in this document imply an ER
peer, unless specifically noted otherwise.
ER Peer--EAP Re-認証がプロトコルであるとサポートするEAP同輩。 別の方法で明確に注意されない場合、「じっと見る」すべての参照が本書ではER同輩を含意します。
ER Authenticator - An entity that supports the authenticator
functionality for EAP re-authentication described in this
document. All references to "authenticator" in this document
imply an ER authenticator, unless specifically noted otherwise.
ER Authenticator--固有識別文字が本書では説明されたEAP再認証のための機能性であるとサポートする実体。 別の方法で明確に注意されない場合、「固有識別文字」のすべての参照が本書ではER固有識別文字を含意します。
ER Server - An entity that performs the server portion of ERP
described here. This entity may or may not be an EAP server. All
references to "server" in this document imply an ER server, unless
specifically noted otherwise. An ER server is a logical entity;
the home ER server is located on the same backend authentication
server as the EAP server in the home domain. The local ER server
may not necessarily be a full EAP server.
ER Server--ここで説明されたERPのサーバ一部を実行する実体。 この実体はEAPサーバであるかもしれません。「サーバ」のすべての参照が本書ではERサーバを含意します、別の方法で明確に注意されない場合。 ERサーバは論理的な実体です。 ホームERサーバはホームドメインにEAPサーバと同じバックエンド認証サーバに位置しています。 ローカルのERサーバは必ず完全なEAPサーバであるかもしれないというわけではありません。
ERX - EAP re-authentication extensions.
ERX--EAP再認証拡張子。
ERP - EAP Re-authentication Protocol that uses the
re-authentication extensions.
ERP--再認証拡張子を使用するEAP Re-認証プロトコル。
rRK - re-authentication Root Key, derived from the EMSK or DSRK.
rRK--EMSKかDSRKから得られた再認証Root Key。
rIK - re-authentication Integrity Key, derived from the rRK.
rIK--rRKから得られた再認証Integrity Key。
rMSK - re-authentication MSK. This is a per-authenticator key,
derived from the rRK.
rMSK--再認証MSK。 これはrRKから主要で、派生している固有識別文字です。
Narayanan & Dondeti Standards Track [Page 4] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[4ページ]。
keyName-NAI - ERP messages are integrity protected with the rIK or
the DS-rIK. The use of rIK or DS-rIK for integrity protection of
ERP messages is indicated by the EMSKname [3]; the protocol, which
is ERP; and the realm, which indicates the domain name of the ER
server. The EMSKname is copied into the username part of the NAI.
keyName-NAI--ERPメッセージはrIKかDS-rIKと共に保護された保全です。 rIKかDS-rIKのERPメッセージの保全保護の使用はEMSKname[3]によって示されます。 プロトコル(それは、ERPです)。 どれがERサーバのドメイン名を示しますか?そして、分野、EMSKnameはNAIのユーザ名部分にコピーされます。
Domain - Refers to a "key management domain" as defined in [3].
For simplicity, it is referred to as "domain" in this document.
The terms "home domain" and "local domain" are used to
differentiate between the originating key management domain that
performs the full EAP exchange with the peer and the local domain
to which a peer may be attached at a given time.
ドメイン--[3]で定義されるように「かぎ管理ドメイン」を参照します。 簡単さにおいて、それは「ドメイン」と本書では呼ばれます。 用語「ホームドメイン」と「局所領域」は、同輩と共に完全なEAP交換を実行する起因しているかぎ管理ドメインと同輩が一時に付けられるかもしれない局所領域を区別するのに使用されます。
3. ERP Description
3. ERP記述
ERP allows a peer and server to mutually verify proof of possession of keying material from an earlier EAP method run and to establish a security association between the peer and the authenticator. The authenticator acts as a pass-through entity for the Re-authentication Protocol in a manner similar to that of an EAP authenticator described in RFC 3748 [2]. ERP is a single round-trip exchange between the peer and the server; it is independent of the lower layer and the EAP method used during the full EAP exchange. The ER server may be in the home domain or in the same (visited) domain as the peer and the authenticator.
ERPは同輩とサーバに以前のEAPメソッド走行から合わせることの材料の所持の証拠について互いに確かめて、同輩と固有識別文字とのセキュリティ仲間を設立させます。 EAP固有識別文字のものと同様の方法によるRe-認証プロトコルのためのパススルー主体がRFC3748[2]で説明したように固有識別文字は行動します。 ERPは同輩とサーバの間のただ一つの往復の交換です。 それは完全なEAP交換の間に使用される下層とEAPメソッドから独立しています。 ERサーバがホームドメインか同輩と固有識別文字と同じ(訪問されます)ドメインにあるかもしれません。
Figure 2 shows the protocol exchange. The first time the peer attaches to any network, it performs a full EAP exchange (shown in Figure 1) with the EAP server; as a result, an MSK is distributed to the EAP authenticator. The MSK is then used by the authenticator and the peer to establish TSKs as needed. At the time of the initial EAP exchange, the peer and the server also derive an EMSK, which is used to derive a re-authentication Root Key (rRK). More precisely, a re-authentication Root Key is derived from the EMSK or from a Domain-Specific Root Key (DSRK), which itself is derived from the EMSK. The rRK is only available to the peer and the ER server and is never handed out to any other entity. Further, a re-authentication Integrity Key (rIK) is derived from the rRK; the peer and the ER server use the rIK to provide proof of possession while performing an ERP exchange. The rIK is also never handed out to any entity and is only available to the peer and server.
図2はプロトコル交換を示しています。 初めて同輩がどんなネットワークにも付くとき、EAPサーバで完全なEAP交換を実行します(図1では、目立ちます)。 その結果、MSKはEAP固有識別文字に分配されます。 そして、MSKは、必要に応じてTSKsを証明するのに固有識別文字と同輩によって使用されます。 また、初期のEAP交換時点で、同輩とサーバはEMSKを引き出します。(EMSKは、再認証Root Key(rRK)を引き出すのに使用されます)。 より正確に、再認証Root KeyはEMSK、または、Domain特有のRoot Key(DSRK)から引き出されます。Root KeyはEMSKからそれ自体で得られます。 rRKを同輩と単にERサーバに利用可能であり、いかなる他の実体にも決して与えません。 さらに、rRKから再認証Integrity Key(rIK)を得ます。 同輩とERサーバは、ERP交換を実行している間、所有物の証拠を提供するのにrIKを使用します。 rIKはまた、どんな実体にも決して与えられないで、同輩と単にサーバに利用可能です。
When the ER server is in the home domain, the peer and the server use the rIK and rRK derived from the EMSK; and when the ER server is not in the home domain, they use the DS-rIK and DS-rRK corresponding to the local domain. The domain of the ER server is identified by the realm portion of the keyname-NAI in ERP messages.
ERサーバがホームドメインにあるとき、同輩とサーバはEMSKから得られたrIKとrRKを使用します。 そして、ERサーバがホームドメインにないとき、彼らは局所領域に対応するDS-rIKとDS-rRKを使用します。 ERサーバのドメインはERPメッセージでkeyname-NAIの分野の部分によって特定されます。
Narayanan & Dondeti Standards Track [Page 5] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[5ページ]。
3.1. ERP With the Home ER Server
3.1. ホームがあるERP、えー、サーバ
EAP Peer EAP Authenticator EAP Server ======== ================= ==========
EAP同輩EAP固有識別文字EAPサーバ======== ================= ==========
<--- EAP-Request/ ------
Identity
<。--- EAP-要求/------ アイデンティティ
----- EAP Response/ --->
Identity ---AAA(EAP Response/Identity)-->
----- EAP応答/--->のアイデンティティ---AAA(EAPの応答/アイデンティティ)-->。
<--- EAP Method -------> <------ AAA(EAP Method -------->
exchange exchange)
<。--- EAPメソッド-------><。------ AAA(EAP Method、-、-、-、-、-、-、--、>交換交換)
<----AAA(MSK, EAP-Success)------
<。----AAA(MSK、EAP-成功)------
<---EAP-Success---------
<。---EAP-成功---------
Figure 1: EAP Authentication
図1: EAP認証
Peer Authenticator Server ==== ============= ======
同輩固有識別文字サーバ==== ============= ======
[<-- EAP-Initiate/ -----
Re-auth-Start]
[<-- EAP-Request/ ------
Identity]
[<--/をEAP開始してください、-、-、-、--、authの再始め][<--/をEAP要求してください、-、-、-、-、--、アイデンティティ]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
---- EAP-開始/---->。----AAA(EAP-開始/、-、-、-、-、-、-、-、-、-->が/を再authするか、または再authする[独力で進んでください][独力で進んでください)
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
<。--- EAP-終わりの/------><。---AAA(rMSK、EAP-終わりの/、-、-、-、-、-、-、-、--再auth/が/を再authする[独力で進んでください][独力で進んでください)
Note: [] brackets indicate optionality.
以下に注意してください。 [] 括弧はoptionalityを示します。
Figure 2: ERP Exchange
図2: ERP交換
Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this document for the purpose of EAP re-authentication. When the peer identifies a target authenticator that supports EAP re-authentication, it performs an ERP exchange, as shown in Figure 2; the exchange itself may happen when the peer attaches to a new authenticator supporting EAP re-authentication, or prior to
2つの新しいEAPコード(EAP-開始とEAP-終わり)が、本書ではEAP再認証の目的に指定されます。 同輩がEAPが再認証であるとサポートする目標固有識別文字を特定するとき、ERP交換を実行します、図2に示されるように。 または同輩がEAPが再認証であるとサポートする新しい固有識別文字に付くと交換自体が起こるかもしれない。
Narayanan & Dondeti Standards Track [Page 6] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[6ページ]。
attachment. The peer initiates ERP by itself; it may also do so in response to an EAP-Initiate/Re-auth-Start message from the new authenticator. The EAP-Initiate/Re-auth-Start message allows the authenticator to trigger the ERP exchange.
付属。 同輩自身はERPを開始します。 また、それは新しい固有識別文字からのauthの再EAP-開始/開始メッセージに対応してそうするかもしれません。 authの再EAP-開始/開始メッセージで、固有識別文字はERP交換の引き金となることができます。
It is plausible that the authenticator does not know whether the peer supports ERP and whether the peer has performed a full EAP authentication through another authenticator. The authenticator MAY initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start message, and if there is no response, it will send the EAP-Request/ Identity message. Note that this avoids having two EAP messages in flight at the same time [2]. The authenticator may send the EAP- Initiate/Re-auth-Start message and wait for a short, locally configured amount of time. If the peer does not already know, this message indicates to the peer that the authenticator supports ERP. In response to this trigger from the authenticator, the peer can initiate the ERP exchange by sending an EAP-Initiate/Re-auth message. If there is no response from the peer after the necessary retransmissions (see Section 6), the authenticator MUST initiate EAP by sending an EAP-Request message, typically the EAP-Request/Identity message. Note that the authenticator may receive an EAP-Initiate/ Re-auth message after it has sent an EAP-Request/Identity message. If the authenticator supports ERP, it MUST proceed with the ERP exchange. When the EAP-Request/Identity times out, the authenticator MUST NOT close the connection if an ERP exchange is in progress or has already succeeded in establishing a re-authentication MSK.
固有識別文字が、同輩がERPをサポートするかどうかと、同輩が別の固有識別文字を通した完全なEAP認証を実行したかどうかを知らないのは、もっともらしいです。 固有識別文字はauthの再EAP-開始/開始メッセージを送ることによって、ERP交換を起こすかもしれません、そして、応答が全くないと、それはEAP-要求/アイデンティティメッセージを送るでしょう。 これが、同時[2]に飛行での2つのEAPメッセージを持っているのを避けることに注意してください。 固有識別文字は、EAP authの再開始/開始メッセージを送って、短くて、局所的に構成された時間、待つかもしれません。 同輩が既に知らないなら、このメッセージは、固有識別文字がERPをサポートするのを同輩に示します。 固有識別文字からのこの引き金に対応して、同輩は、再EAP-開始/authメッセージを送ることによって、ERP交換を起こすことができます。 同輩からの応答が全く必要な「再-トランスミッション」の後になければ(セクション6を見てください)、固有識別文字は、EAP-要求メッセージ、通常EAP-要求/アイデンティティメッセージを送ることによって、EAPを開始しなければなりません。 EAP-要求/アイデンティティメッセージを送った後に固有識別文字が再EAP-開始/authメッセージを受け取るかもしれないことに注意してください。 固有識別文字がERPをサポートするなら、それはERP交換を続けなければなりません。 EAP-要求/アイデンティティ回のアウトであるときに、ERP交換が、進行中である、または再認証MSKを設立するのに既に成功したなら、固有識別文字は接続を終えてはいけません。
If the authenticator does not support ERP, it drops EAP-Initiate/ Re-auth messages [2] as the EAP code of those packets is greater than 4. An ERP-capable peer will exhaust the EAP-Initiate/Re-auth message retransmissions and fall back to EAP authentication by responding to EAP Request/Identity messages from the authenticator. If the peer does not support ERP or if it does not have unexpired key material from a previous EAP authentication, it drops EAP-Initiate/ Re-auth-Start messages. If there is no response to the EAP-Initiate/ Re-auth-Start message, the authenticator SHALL send an EAP Request message (typically EAP Request/Identity) to start EAP authentication. From this stage onwards, RFC 3748 rules apply. Note that this may introduce some delay in starting EAP. In some lower layers, the delay can be minimized or even avoided by the peer initiating EAP by sending messages such as EAPoL-Start in the IEEE 802.1X specification [10].
固有識別文字がERPをサポートしないなら、それは、[2] それらのパケットのEAPコードが4以上であるので、再EAP-開始/authメッセージを下げます。 ERP有能な同輩は、再EAP-開始/authメッセージ「再-トランスミッション」を消耗させて、固有識別文字からEAP Request/アイデンティティメッセージに応じることによって、EAP認証へ後ろへ下がるでしょう。 同輩がERPをサポートしないか、または前のEAP認証からの満期になっていない主要な材料がないなら、それはauthの再EAP-開始/開始メッセージを下げます。 authの再EAP-開始/開始メッセージへの応答が全くなければ、固有識別文字SHALLはEAP認証を始めるEAP Requestメッセージ(通常EAP Request/アイデンティティ)を送ります。 このステージから、前方へ、RFC3748規則は適用されます。 これが始めのEAPの何らかの遅れを導入するかもしれないことに注意してください。 いくつかの下層では、遅れは、最小にするかIEEE 802.1X仕様[10]に基づくEAPoL-始めなどのメッセージを送ることによってEAPを開始する同輩が避けることさえできます。
The peer sends an EAP-Initiate/Re-auth message that contains the keyName-NAI to identify the ER server's domain and the rIK used to protect the message, and a sequence number for replay protection. The EAP-Initiate/Re-auth message is integrity protected with the rIK. The authenticator uses the realm in the keyName-NAI [4] field to send
同輩はERサーバのドメインを特定するkeyName-NAIと反復操作による保護のためにメッセージ、および一連番号を保護するのに使用されるrIKを含む再EAP-開始/authメッセージを送ります。 再EAP-開始/authメッセージはrIKと共に保護された保全です。 固有識別文字は、発信するのにkeyName-NAI[4]分野で分野を使用します。
Narayanan & Dondeti Standards Track [Page 7] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[7ページ]。
the message to the appropriate ER server. The server uses the keyName to look up the rIK. The server, after verifying proof of possession of the rIK, and freshness of the message, derives a re-authentication MSK (rMSK) from the rRK using the sequence number as an input to the key derivation. The server updates the expected sequence number to the received sequence number plus one.
. サーバがrIKに見えるのにkeyNameを使用する適切なERサーバへのメッセージ。 rIKの所持の証拠、およびメッセージの新しさについて確かめた後に、サーバは入力として一連番号を使用するrRKから主要な派生まで再認証MSK(rMSK)を引き出します。 サーバは容認された一連番号と1つに予想された一連番号をアップデートします。
In response to the EAP-Initiate/Re-auth message, the server sends an EAP-Finish/Re-auth message; this message is integrity protected with the rIK. The server transports the rMSK along with this message to the authenticator. The rMSK is transported in a manner similar to that of the MSK along with the EAP-Success message in a full EAP exchange. Ongoing work in [11] describes an additional key distribution protocol that can be used to transport the rRK from an EAP server to one of many different ER servers that share a trust relationship with the EAP server.
再EAP-開始/authメッセージに対応して、サーバは再EAP-終わり/authメッセージを送ります。 このメッセージはrIKと共に保護された保全です。 サーバはこのメッセージに伴うrMSKを固有識別文字に輸送します。 rMSKは完全なEAP交換におけるEAP-成功メッセージに伴うMSKのものと同様の方法で輸送されます。 [11]での進行中の仕事はEAPサーバからEAPサーバとの信頼関係を共有する多くの異なったERサーバの1つまでrRKを輸送するのに使用できる追加主要な分配プロトコルについて説明します。
The peer MAY request the server for the rMSK lifetime. If so, the ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message.
同輩はrMSK生涯のためのサーバを要求するかもしれません。 そうだとすれば、ERサーバは再EAP-終わり/authメッセージのrMSK生涯を送ります。
In an ERP bootstrap exchange, the peer MAY request the server for the rRK lifetime. If so, the ER server sends the rRK lifetime in the EAP-Finish/Re-auth message.
ERPでは、交換を独力で進んでください、そして、同輩はrRK生涯のためのサーバを要求してもよいです。 そうだとすれば、ERサーバは再EAP-終わり/authメッセージのrRK生涯を送ります。
The peer verifies the replay protection and the integrity of the message. It then uses the sequence number in the EAP-Finish/Re-auth message to compute the rMSK. The lower-layer security association protocol is ready to be triggered after this point.
同輩は反復操作による保護とメッセージの保全について確かめます。 そして、それはrMSKを計算する再EAP-終わり/authメッセージで一連番号を使用します。 下層セキュリティ協会プロトコルはこのポイント後に引き起こされる準備ができています。
3.2. ERP with a Local ER Server
3.2. ローカルがいるERP、えー、サーバ
The defined ER extensions allow executing the ERP with an ER server in the local domain (access network). The local ER server may be co- located with a local AAA server. The peer may learn about the presence of a local ER server in the network and the local domain name (or ER server name) either via the lower layer or by means of ERP bootstrapping. The peer uses the domain name and the EMSK to compute the DSRK and from that key, the DS-rRK; the peer also uses the domain name in the realm portion of the keyName-NAI for using ERP in the local domain. Figure 3 shows the full EAP and subsequent local ERP exchange; Figure 4 shows it with a local ER server.
定義されたER拡張子で、ERサーバが局所領域(アクセスネットワーク)にある状態で、ERPを実行します。 ローカルのERサーバはローカルのAAAサーバで共同見つけられるかもしれません。同輩は下層かERPブートストラップ法によってネットワークと局所領域名(または、ERサーバー名)でのローカルのERサーバの存在に関して学ぶかもしれません。 同輩はDSRK、およびそのキーからのDS-rRKを計算するのにドメイン名とEMSKを使用します。 また、同輩は、局所領域でERPを使用するのにkeyName-NAIの分野の部分でドメイン名を使用します。 図3は完全なEAPとその後の地方のERPに交換を示しています。 図4はローカルのERサーバでそれを示しています。
Narayanan & Dondeti Standards Track [Page 8] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[8ページ]。
Peer EAP Authenticator Local ER Server Home EAP Server ==== ================= =============== ===============
えー、同輩EAP固有識別文字ローカルサーバホームEAP、サーバ==== ================= =============== ===============
<-- EAP-Request/ --
Identity
<--EAP-要求/--アイデンティティ
-- EAP Response/-->
Identity --AAA(EAP Response/-->
Identity) --AAA(EAP Response/ -->
Identity,
[DSRK Request,
domain name])
-- EAP応答/-->のアイデンティティ--AAA(EAP応答/-->のアイデンティティ)--AAA(EAP Response/-->Identity、[DSRK Request、ドメイン名])
<------------------------ EAP Method exchange------------------>
<。------------------------ EAP Method交換------------------>。
<---AAA(MSK, DSRK, ----
EMSKname,
EAP-Success)
<。---AAA(MSK、DSRK、---- EMSKname、EAP-成功)
<--- AAA(MSK, -----
EAP-Success)
<。--- AAA(MSK、----- EAP-成功)
<---EAP-Success-----
<。---EAP-成功-----
Figure 3: Local ERP Exchange, Initial EAP Exchange
図3: 地方のERP交換、初期のEAP交換
Peer ER Authenticator Local ER Server ==== ================ ===============
同輩、えー、固有識別文字ローカル、えー、サーバ==== ================ ===============
[<-- EAP-Initiate/ --------
Re-auth-Start]
[<-- EAP-Request/ ---------
Identity]
[<--/をEAP開始してください、-、-、-、-、-、-、--、authの再始め][<--/をEAP要求してください、-、-、-、-、-、-、-、--、アイデンティティ]
---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ -------->
Re-auth Re-auth)
---- EAP-開始/------->。----AAA(EAP-開始/、-、-、-、-、-、-、--、>再auth再auth)
<--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
Re-auth Re-auth)
<。--- EAP-終わりの/---------- <--AAA(rMSK、EAP-終わりの/、-、-、-、-、-、--、再auth再auth)
Figure 4: Local ERP Exchange
図4: 地方のERP交換
Narayanan & Dondeti Standards Track [Page 9] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[9ページ]。
As shown in Figure 4, the local ER server may be present in the path of the full EAP exchange (e.g., this may be one of the AAA entities, such as AAA proxies, in the path between the authenticator and the home EAP server of the peer). In that case, the ER server requests the DSRK by sending the domain name to the EAP server. In response, the EAP server computes the DSRK by following the procedure specified in [3] and sends the DSRK and the key name, EMSKname, to the ER server in the claimed domain. The local domain is responsible for announcing that same domain name via the lower layer to the peer.
図4に示されるように、ローカルのERサーバは完全なEAP交換の経路に存在しているかもしれません(例えば、これは同輩の固有識別文字とホームEAPサーバの間の経路のAAAプロキシなどのAAA実体の1つであるかもしれません)。 その場合、ERサーバは、EAPサーバにドメイン名を送ることによって、DSRKを要求します。EAPサーバは、応答では、[3]で指定された手順に従うことでDSRKを計算して、DSRKと主要な名前を送ります、EMSKname、要求されたドメインのERサーバに。 局所領域は同輩への下層でその同じドメイン名を発表するのに原因となります。
If the peer does not know the domain name (did not receive the domain name via the lower-layer announcement, due to a missed announcement or lack of support for domain name announcements in a specific lower layer), it SHOULD initiate ERP bootstrap exchange with the home ER server to obtain the domain name. The local ER server SHALL request the home AAA server for the DSRK by sending the domain name in the AAA message that carries the EAP-Initiate/Re-auth bootstrap message. The local ER server MUST be in the path from the peer to the home ER server. If it is not, it cannot request the DSRK.
同輩がそうしないなら、ドメイン名(逃された発表による下層発表か特定の下層におけるドメイン名発表のサポートの不足でドメイン名を受けなかった)を知ってください、それ。SHOULD開始ERPはドメイン名を得るホームERサーバによる交換を独力で進みます。 ローカルのERサーバSHALLは、再EAP-開始/authを運ぶAAAメッセージのドメイン名を送るのによるDSRKのためのホームAAAサーバがメッセージを独力で進むよう要求します。 同輩からホームERサーバまでローカルのERサーバが経路にあるに違いありません。そうでないなら、それはDSRKを要求できません。
After receiving the DSRK and the EMSKname, the local ER server computes the DS-rRK and the DS-rIK from the DSRK as defined in Sections 4.1 and 4.3 below. After receiving the domain name, the peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys are referred to by a keyName-NAI formed as follows: the username part of the NAI is the EMSKname, the realm portion of the NAI is the domain name. Both parties also maintain a sequence number (initialized to zero) corresponding to the specific keyName-NAI.
DSRKとEMSKnameを受けた後に、ローカルのERサーバは以下のセクション4.1と4.3で定義されるようにDSRKからDS-rRKとDS-rIKを計算します。 また、ドメイン名を受けた後に、同輩はDSRK、DS-rRK、およびDS-rIKを引き出します。 これらのキーは以下の通り形成されたkeyName-NAIによって言及されます: NAIのユーザ名部分がEMSKnameである、NAIの分野の部分はドメイン名です。 また、双方は一連番号(ゼロに初期化される)を特定のkeyName-NAIに対応しているのに維持します。
Subsequently, when the peer attaches to an authenticator within the local domain, it may perform an ERP exchange with the local ER server to obtain an rMSK for the new authenticator.
次に、同輩が局所領域の中の固有識別文字に付くと、それは、新しい固有識別文字にrMSKを入手するためにローカルのERサーバによるERP交換を実行するかもしれません。
4. ER Key Hierarchy
4. えー、主要な階層構造
Each time the peer re-authenticates to the network, the peer and the authenticator establish an rMSK. The rMSK serves the same purposes that an MSK, which is the result of full EAP authentication, serves. To prove possession of the rRK, we specify the derivation of another key, the rIK. These keys are derived from the rRK. Together they constitute the ER key hierarchy.
同輩がネットワークに再認証する各回、同輩、および固有識別文字はrMSKを設立します。 rMSKは同じ目的に役立ちます。MSK(完全なEAP認証の結果である)は役立ちます。 rRKの所持を立証するために、私たちは別のキー、rIKの派生を指定します。 rRKからこれらのキーを得ます。 彼らはERの主要な階層構造を一緒に、構成します。
The rRK is derived from either the EMSK or a DSRK as specified in Section 4.1. For the purpose of rRK derivation, this document specifies derivation of a Usage-Specific Root Key (USRK) or a Domain- Specific USRK (DSUSRK) in accordance with [3] for re-authentication. The USRK designated for re-authentication is the re-authentication root key (rRK). A DSUSRK designated for re-authentication is the DS-
セクション4.1における指定されるとしてのEMSKかDSRKのどちらかからrRKを得ます。 rRK派生の目的として、再認証のための[3]によると、このドキュメントはUsage特有のRoot Key(USRK)かDomainの特定のUSRK(DSUSRK)の派生を指定します。 再認証のために指定されたUSRKは再認証ルートキー(rRK)です。 再認証のために指定されたDSUSRKはDSです。
Narayanan & Dondeti Standards Track [Page 10] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[10ページ]。
rRK available to a local ER server in a particular domain. For simplicity, the keys are referred to without the DS label in the rest of the document. However, the scope of the various keys is limited to just the respective domains they are derived for, in the case of the domain specific keys. Based on the ER server with which the peer performs the ERP exchange, it knows the corresponding keys that must be used.
特定のドメインのローカルのERサーバに利用可能なrRK。 簡単さについて、DSラベルなしでドキュメントの残りでキーについて言及します。 しかしながら、様々なキーの範囲はまさしくそれらが引き出されるそれぞれのドメインに制限されます、ドメインの特定のキーの場合で。 同輩がERP交換を実行するERサーバに基づいて、それは使用しなければならない対応するキーを知っています。
The rRK is used to derive an rIK, and rMSKs for one or more authenticators. The figure below shows the key hierarchy with the rRK, rIK, and rMSKs.
rRKは、1つ以上の固有識別文字のためにrIK、およびrMSKsを引き出すのに使用されます。 以下の図はrRK、rIK、およびrMSKsと共に主要な階層構造を示しています。
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
rRK| +--------+--------+ | | | rIK rMSK1…rMSKn
Figure 5: Re-authentication Key Hierarchy
図5: 再認証の主要な階層構造
The derivations in this document are according to [3]. Key derivations and field encodings, where unspecified, default to that document.
[3]によると、派生が本書ではあります。 主要な派生と分野encodingsは不特定であるところでそのドキュメントをデフォルトとします。
4.1. rRK Derivation
4.1. rRK派生
The rRK may be derived from the EMSK or DSRK. This section provides the relevant key derivations for that purpose.
EMSKかDSRKからrRKを得るかもしれません。 このセクションはそのために関連主要な派生を提供します。
The rRK is derived as specified in [3].
rRKは[3]で指定されるように引き出されます。
rRK = KDF (K, S), where
rRKはKDF(K、S)、どこと等しいか。
K = EMSK or K = DSRK and
そしてK=EMSKかKがDSRKと等しい。
S = rRK Label | "%%BODY%%" | length
S=rRKラベル| "%%BODY%%" | 長さ
The rRK Label is an IANA-assigned 8-bit ASCII string:
rRK LabelはIANAによって割り当てられた8ビットのASCIIストリングです:
EAP Re-authentication Root Key@ietf.org
EAP再認証根の Key@ietf.org
assigned from the "USRK key labels" name space in accordance with [3].
「USRKの主要なラベル」から、[3]に従った名前スペースを割り当てました。
The KDF and algorithm agility for the KDF are as defined in [3].
KDFのためのKDFとアルゴリズムの機敏さが[3]で定義されるようにあります。
Narayanan & Dondeti Standards Track [Page 11] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[11ページ]。
An rRK derived from the DSRK is referred to as a DS-rRK in the rest of the document. All the key derivation and properties specified in this section remain the same.
DSRKから得られたrRKはドキュメントの残りでDS-rRKと呼ばれます。 このセクションで指定されたすべての主要な派生と特性が同じままで残っています。
4.2. rRK Properties
4.2. rRKの特性
The rRK has the following properties. These properties apply to the rRK regardless of the parent key used to derive it.
rRKには、以下の特性があります。 これらの特性はそれを引き出すのに使用される親キーにかかわらずrRKに適用されます。
o The length of the rRK MUST be equal to the length of the parent
key used to derive it.
o rRKの長さはそれを引き出すのに使用される親キーの長さと等しいに違いありません。
o The rRK is to be used only as a root key for re-authentication and
never used to directly protect any data.
o 直接どんなデータも保護するのに単に決して使用されないようにrRKは使用されていることになっています。
o The rRK is only used for derivation of rIK and rMSK as specified
in this document.
o rRKはこのドキュメントの指定されるとしてのrIKとrMSKの派生に使用されるだけです。
o The rRK MUST remain on the peer and the server that derived it and
MUST NOT be transported to any other entity.
o rRKはそれを引き出した同輩とサーバに残らなければならなくて、いかなる他の実体にも輸送されてはいけません。
o The lifetime of the rRK is never greater than that of its parent
key. The rRK is expired when the parent key expires and MUST be
removed from use at that time.
o rRKの寿命は親キーのものより決してすばらしくはありません。 rRKを親キーが期限が切れるとき、満期であり、その時、使用から取り外さなければなりません。
4.3. rIK Derivation
4.3. rIK派生
The re-authentication Integrity Key (rIK) is used for integrity protecting the ERP exchange. This serves as the proof of possession of valid keying material from a previous full EAP exchange by the peer to the server.
再認証Integrity Key(rIK)はERP交換を保護する保全に使用されます。 これは同輩による前の完全なEAP交換からサーバまでの有効な合わせることの材料の所持の証拠として機能します。
The rIK is derived as follows.
rIKは以下の通り引き出されます。
rIK = KDF (K, S), where
rIKはKDF(K、S)、どこと等しいか。
K = rRK and
そしてKがrRKと等しい。
S = rIK Label | "%%BODY%%" | cryptosuite | length
S=rIKラベル| "%%BODY%%" | cryptosuite| 長さ
The rIK Label is the 8-bit ASCII string:
rIK Labelは8ビットのASCIIストリングです:
Re-authentication Integrity Key@ietf.org
再認証保全 Key@ietf.org
The length field refers to the length of the rIK in octets encoded as specified in [3].
長さの分野は[3]で指定されるようにコード化された八重奏における、rIKの長さについて言及します。
Narayanan & Dondeti Standards Track [Page 12] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[12ページ]。
The cryptosuite and length of the rIK are part of the input to the key derivation function to ensure cryptographic separation of keys if different rIKs of different lengths for use with different Message Authentication Code (MAC) algorithms are derived from the same rRK. The cryptosuite is encoded as an 8-bit number; see Section 5.3.2 for the cryptosuite specification.
同じrRKから異なったメッセージ立証コード(MAC)アルゴリズムがある使用のための異なった長さの異なったrIKsを得るなら、rIKのcryptosuiteと長さはキーの暗号の分離を確実にする主要な派生機能への入力の一部です。 cryptosuiteは8ビットの数としてコード化されます。 cryptosuite仕様に関してセクション5.3.2を見てください。
The rIK is referred to by EMSKname-NAI within the context of ERP messages. The username part of EMSKname-NAI is the EMSKname; the realm is the domain name of the ER server. In case of ERP with the home ER server, the peer uses the realm from its original NAI; in case of a local ER server, the peer uses the domain name received at the lower layer or through an ERP bootstrapping exchange.
rIKはERPメッセージの文脈の中でEMSKname-NAIによって言及されます。 EMSKname-NAIのユーザ名部分はEMSKnameです。 分野はERサーバのドメイン名です。ホームERサーバがあるERPの場合に、同輩はオリジナルのNAIから分野を使用します。 ローカルのERサーバの場合には、同輩は下層において、または、交換を独力で進むERPを通して受け取られたドメイン名を使用します。
An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest of the document. All the key derivation and properties specified in this section remain the same.
DS-rRKから得られたrIKはドキュメントの残りでDS-rIKと呼ばれます。 このセクションで指定されたすべての主要な派生と特性が同じままで残っています。
4.4. rIK Properties
4.4. rIKの特性
The rIK has the following properties.
rIKには、以下の特性があります。
o The length of the rIK MUST be equal to the length of the rRK.
o rIKの長さはrRKの長さと等しいに違いありません。
o The rIK is only used for authentication of the ERP exchange as
specified in this document.
o rIKはこのドキュメントにおける指定されるとしてのERP交換の認証に使用されるだけです。
o The rIK MUST NOT be used to derive any other keys.
o いかなる他のキーも引き出すのにrIKを使用してはいけません。
o The rIK must remain on the peer and the server and MUST NOT be
transported to any other entity.
o rIKは同輩とサーバに残らなければならなくて、いかなる他の実体にも輸送されてはいけません。
o The rIK is cryptographically separate from any other keys derived
from the rRK.
o rIKはrRKから得られたいかなる他のキーからも暗号で分離することです。
o The lifetime of the rIK is never greater than that of its parent
key. The rIK MUST be expired when the EMSK expires and MUST be
removed from use at that time.
o rIKの寿命は親キーのものより決してすばらしくはありません。 rIKをEMSKが期限が切れるとき、吐き出さなければならなくて、その時、使用から取り外さなければなりません。
4.5. rIK Usage
4.5. rIK用法
The rIK is the key whose possession is demonstrated by the peer and the ERP server to the other party. The peer demonstrates possession of the rIK by computing the integrity checksum over the EAP-Initiate/ Re-auth message. When the peer uses the rIK for the first time, it can choose the integrity algorithm to use with the rIK. The peer and the server MUST use the same integrity algorithm with a given rIK for
rIKは所有物が同輩とERPサーバで相手にデモをするキーです。 同輩は、再EAP-開始/authメッセージに関して保全チェックサムを計算することによって、rIKの所持を示します。 同輩が初めてrIKを使用するとき、それはrIKと共に使用する保全アルゴリズムを選ぶことができます。 同輩とサーバはrIKを与えるaでの同じ保全アルゴリズムを使用しなければなりません。
Narayanan & Dondeti Standards Track [Page 13] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[13ページ]。
all ERP messages protected with that key. The peer and the server store the algorithm information after the first use, and they employ the same algorithm for all subsequent uses of that rIK.
すべてのERPメッセージがそのキーで保護されました。 同輩とサーバは最初の使用の後にアルゴリズム情報を保存します、そして、彼らはそのrIKのすべてのその後の用途のための同じアルゴリズムを使います。
If the server's policy does not allow the use of the cryptosuite selected by the peer, the server SHALL reject the EAP-Initiate/ Re-auth message and SHOULD send a list of acceptable cryptosuites in the EAP-Finish/Re-auth message.
サーバの方針が同輩によって選択されたcryptosuiteの使用を許さないなら、サーバSHALLは再EAP-開始/authメッセージを拒絶します、そして、SHOULDは再EAP-終わり/authメッセージで許容できるcryptosuitesのリストを送ります。
The rIK length may be different from the key length required by an integrity algorithm. In case of hash-based MAC algorithms, the key is first hashed to the required key length as specified in [5]. In case of cipher-based MAC algorithms, if the required key length is less than 32 octets, the rIK is hashed using HMAC-SHA256 and the first k octets of the output are used, where k is the key length required by the algorithm. If the required key length is more than 32 octets, the first k octets of the rIK are used by the cipher-based MAC algorithm.
rIKの長さは保全アルゴリズムによって必要とされたキー長と異なっているかもしれません。 ハッシュベースのMACアルゴリズムの場合には、キーは最初に、[5]の指定されるとしての必要なキー長に論じ尽くされます。 暗号ベースのMACアルゴリズムの場合には、rIKは必要なキー長が32未満の八重奏であるなら、HMAC-SHA256を使用することで論じ尽くされます、そして、出力の最初kの八重奏は使用されています、kがアルゴリズムによって必要とされたキー長であるところで。 必要なキー長が32以上の八重奏であるなら、rIKの最初kの八重奏は暗号ベースのMACアルゴリズムで使用されます。
4.6. rMSK Derivation
4.6. rMSK派生
The rMSK is derived at the peer and server and delivered to the authenticator. The rMSK is derived following an EAP Re-auth Protocol exchange.
rMSKは同輩とサーバで引き出されて、固有識別文字に提供されます。 EAP Re-authプロトコル交換に続いて、rMSKは引き出されます。
The rMSK is derived as follows.
rMSKは以下の通り引き出されます。
rMSK = KDF (K, S), where
rMSKはKDF(K、S)、どこと等しいか。
K = rRK and
そしてKがrRKと等しい。
S = rMSK label | "%%BODY%%" | SEQ | length
S=rMSKラベル| "%%BODY%%" | SEQ| 長さ
The rMSK label is the 8-bit ASCII string:
rMSKラベルは8ビットのASCIIストリングです:
Re-authentication Master Session Key@ietf.org
再認証マスターセッション Key@ietf.org
The length field refers to the length of the rMSK in octets. The length field is encoded as specified in [3].
長さの分野は八重奏における、rMSKの長さについて言及します。 長さの分野は[3]で指定されるようにコード化されます。
SEQ is the sequence number sent by the peer in the EAP-Initiate/ Re-auth message. This field is encoded as a 16-bit number in network byte order (see Section 5.3.2).
SEQは再EAP-開始/authメッセージの同輩によって送られた一連番号です。 この分野はネットワークバイトオーダーにおける16ビットの数としてコード化されます(セクション5.3.2を見てください)。
An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest of the document. All the key derivation and properties specified in this section remain the same.
DS-rRKから得られたrMSKはドキュメントの残りでDS-rIKと呼ばれます。 このセクションで指定されたすべての主要な派生と特性が同じままで残っています。
Narayanan & Dondeti Standards Track [Page 14] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[14ページ]。
4.7. rMSK Properties
4.7. rMSKの特性
The rMSK has the following properties:
rMSKには、以下の特性があります:
o The length of the rMSK MUST be equal to the length of the rRK.
o rMSKの長さはrRKの長さと等しいに違いありません。
o The rMSK is delivered to the authenticator and is used for the
same purposes that an MSK is used at an authenticator.
o rMSKは、固有識別文字に提供されて、同じくらいが、MSKが固有識別文字に使用されるのを目標とするので、使用されています。
o The rMSK is cryptographically separate from any other keys derived
from the rRK.
o rMSKはrRKから得られたいかなる他のキーからも暗号で分離することです。
o The lifetime of the rMSK is less than or equal to that of the rRK.
It MUST NOT be greater than the lifetime of the rRK.
o rMSKの寿命はrRKの、よりもの以下です。 それはrRKの生涯より長いはずがありません。
o If a new rRK is derived, subsequent rMSKs MUST be derived from the
new rRK. Previously delivered rMSKs MAY still be used until the
expiry of the lifetime.
o 新しいrRKを引き出すなら、新しいrRKからその後のrMSKsを得なければなりません。 以前提供されたrMSKsは生涯の満期までまだ使用されているかもしれません。
o A given rMSK MUST NOT be shared by multiple authenticators.
o 与えられたrMSKは複数の固有識別文字によって共有されてはいけません。
5. Protocol Details
5. プロトコルの詳細
5.1. ERP Bootstrapping
5.1. ERPブートストラップ法
We identify two types of bootstrapping for ERP: explicit and implicit bootstrapping. In implicit bootstrapping, the local ER server SHOULD include its domain name and SHOULD request the DSRK from the home AAA server during the initial EAP exchange, in the AAA message encapsulating the first EAP Response message sent by the peer. If the EAP exchange is successful, the server sends the DSRK for the local ER server (derived using the EMSK and the domain name as specified in [3]), EMSKname, and DSRK lifetime along with the EAP- Success message. The local ER server MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding the EAP- Success message to the peer, as specified in [12]. Note that the MSK (also present along with the EAP Success message) is extracted by the EAP authenticator as usual. The peer learns the domain name through the EAP-Initiate/Re-auth-Start message or via lower-layer announcements. When the domain name is available to the peer during or after the full EAP authentication, it attempts to use ERP when it associates with a new authenticator.
私たちはERPのために独力で進む2つのタイプを特定します: 明白で暗黙のブートストラップ法。 暗黙のブートストラップ法では、ローカルのERサーバSHOULDはドメイン名を含んでいます、そして、SHOULDは初期のEAP交換の間、ホームAAAサーバからDSRKを要求します、最初のEAP Responseメッセージが同輩で送ったAAAメッセージ要約で。 EAP交換がうまくいくなら、サーバはローカルのERサーバのためにDSRKを送ります。(EAP成功メッセージに伴う[3])、EMSKname、およびDSRK生涯指定されるとしてEMSKとドメイン名を使用することで、引き出されます。 ローカルのERサーバは[12]のDSRK、EMSKname、および指定されるとしてEAP成功メッセージを同輩に転送する前のDSRK生涯(存在しているなら)を抽出しなければなりません。 MSK(EAP Successメッセージと共に現在のも)が通常通りのEAP固有識別文字によって抽出されることに注意してください。 同輩はauthの再EAP-開始/開始メッセージを通して、または、下層発表でドメイン名を学びます。 同輩にとって、ドメイン名が認証か完全なEAP認証の後に利用可能であるときに、それは、新しい固有識別文字と交際するとき、ERPを使用するのを試みます。
If the peer does not know the domain name (did not receive the domain name via the lower-layer announcement, due to a missed announcement or lack of support for domain name announcements in a specific lower layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with the bootstrap flag turned on) with the home ER server to obtain the
同輩がドメイン名(特定の下層におけるドメイン名発表のサポートの逃された発表か不足による下層発表でドメイン名を受けなかった)を知らないで、それがERPが独力で進むSHOULD開始である、交換、(ERPが交換する、摘み皮、つけられた旗)、得るホームERサーバ
Narayanan & Dondeti Standards Track [Page 15] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[15ページ]。
domain name. The local ER server behavior is the same as described above. The peer MAY also initiate bootstrapping to fetch information such as the rRK lifetime from the AAA server.
ドメイン名。 地方のERサーバの振舞いは上で説明されるのと同じです。 また、同輩は、AAAサーバからのrRK生涯などの情報をとって来るためにブートストラップ法に着手するかもしれません。
The following steps describe the ERP explicit bootstrapping process:
以下のステップはERPの明白なブートストラップ法プロセスについて説明します:
o The peer sends the EAP-Initiate/Re-auth message with the
bootstrapping flag turned on. The bootstrap message is always
sent to the home AAA server, and the keyname-NAI attribute in the
bootstrap message is constructed as follows: the username portion
of the NAI contains the EMSKname, and the realm portion contains
the home domain name.
o ブートストラップ法旗がつけられている状態で、同輩は再EAP-開始/authメッセージを送ります。 独力で進んでください。摘み皮、中でいつもホームAAAサーバ、およびkeyname-NAI属性にメッセージを送る、メッセージは以下の通り構成されます: NAIのユーザ名一部がEMSKnameを含んでいます、そして、分野の部分はホームドメイン名を含んでいます。
o In addition, the message MUST contain a sequence number for replay
protection, a cryptosuite, and an integrity checksum. The
cryptosuite indicates the authentication algorithm. The integrity
checksum indicates that the message originated at the claimed
entity, the peer indicated by the Peer-ID, or the rIKname.
o さらに、メッセージは反復操作による保護、cryptosuite、および保全チェックサムのための一連番号を含まなければなりません。 cryptosuiteは認証アルゴリズムを示します。 保全チェックサムは、メッセージが要求された実体で起因したのを示します、と同輩はPeer-ID、またはrIKnameで示しました。
o The peer MAY additionally set the lifetime flag to request the key
lifetimes.
o 同輩は、生涯旗に主要な生涯を要求するようにさらに、設定するかもしれません。
o When an ERP-capable authenticator receives the EAP-Initiate/
Re-auth message from a peer, it copies the contents of the
keyName-NAI into the User-Name attribute of RADIUS [13]. The rest
of the process is similar to that described in [14] and [12].
o ERPできる固有識別文字が同輩から再EAP-開始/authメッセージを受け取るとき、それはRADIUS[13]のUser-名前属性にkeyName-NAIのコンテンツをコピーします。 プロセスの残りは[14]と[12]で説明されたそれと同様です。
o If a local ER server is present, the local ER server MUST include
the DSRK request and its domain name in the AAA message
encapsulating the EAP-Initiate/Re-auth message sent by the peer.
o ローカルのERサーバが存在しているなら、同輩によって送られた再EAP-開始/authメッセージをカプセル化して、ローカルのERサーバはAAAメッセージにDSRK要求とそのドメイン名を含まなければなりません。
o Upon receipt of an EAP-Initiate/Re-auth message, the server
verifies whether the message is fresh or is a replay by evaluating
whether the received sequence number is equal to or greater than
the expected sequence number for that rIK. The server then
verifies to ensure that the cryptosuite used by the peer is
acceptable. Next, it verifies the origin authentication of the
message by looking up the rIK. If any of the checks fail, the
server sends an EAP-Finish/Re-auth message with the Result flag
set to '1'. Please refer to Section 5.2.2 for details on failure
handling. This error MUST NOT have any correlation to any EAP-
Success message that may have been received by the EAP
authenticator and the peer earlier. If the EAP-Initiate/Re-auth
message is well-formed and valid, the server prepares the EAP-
Finish/Re-auth message. The bootstrap flag MUST be set to
indicate that this is a bootstrapping exchange. The message
contains the following fields:
o 再EAP-開始/authメッセージを受け取り次第、サーバは、容認された一連番号に予想された一連番号よりそのrIKに等しいか、またはすばらしいかどうか評価することによって、メッセージが新鮮であるか、再生であるかを確かめます。 そして、サーバは、同輩によって使用されたcryptosuiteが許容できるのを保証することを確かめます。 次に、それは、rIKを見上げることによって、メッセージの発生源認証について確かめます。 チェックのどれかが失敗するなら、サーバは'1'に設定されたResult旗で再EAP-終わり/authメッセージを送ります。 失敗取り扱いに関する詳細についてセクション5.2.2を参照してください。 この誤りは、より早くEAP固有識別文字と同輩によって受け取られたどんなEAP成功メッセージにも少しの相関関係も持ってはいけません。 再EAP-開始/authメッセージが整形式であって有効であるなら、サーバはEAP再終わり/authメッセージを準備します。 これがブートストラップ法であることを示すセットが交換であったに違いないなら旗を独力で進んでください。 メッセージは以下の分野を含んでいます:
Narayanan & Dondeti Standards Track [Page 16] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[16ページ]。
* A sequence number for replay protection.
* 反復操作による保護のための一連番号。
* The same keyName-NAI as in the EAP-Initiate/Re-auth message.
* 再EAP-開始/authが通信させるコネと同じkeyName-NAI。
* If the lifetime flag was set in the EAP-Initiate/Re-auth
message, the ER server SHOULD include the rRK lifetime and the
rMSK lifetime in the EAP-Finish/Re-auth message. The server
may have a local policy for the network to maintain and enforce
lifetime unilaterally. In such cases, the server need not
respond to the peer's request for the lifetime.
* 生涯旗が再EAP-開始/authメッセージに設定されたなら、ERサーバSHOULDは再EAP-終わり/authメッセージにrRK生涯、rMSK生涯を含んでいます。 サーバには、ネットワークが一方的に生涯を維持して、実施するローカルの方針があるかもしれません。 そのような場合、サーバは生涯を求める同輩の要求に応じる必要はありません。
* If the bootstrap flag is set and a DSRK request is received,
the server MUST include the domain name to which the DSRK is
being sent.
* 独力で進んでください。旗がセットと受け取られたDSRK要求である、サーバはDSRKが送られるドメイン名を含まなければなりません。
* If the home ER server verifies the authorization of a local
domain server, it MAY include the Authorization Indication TLV
to indicate to the peer that the server (that received the DSRK
and that is advertising the domain included in the domain name
TLV) is authorized.
* ホームERサーバが局所領域サーバの承認について確かめるなら、それは、サーバ(DSRKはそれは受けられました、そして、すなわち、ドメインの広告を出すと、ドメイン名では、TLVは含まれていた)が認可されているのを同輩に示すためにAuthorization Indication TLVを含むかもしれません。
* An authentication tag MUST be included to prove that the EAP-
Finish/Re-auth message originates at a server that possesses
the rIK corresponding to the EMSKname-NAI.
* EAP再終わり/authメッセージがEMSKname-NAIに対応するrIKを所有しているサーバで起因すると立証するために認証タグを含まなければなりません。
o If the ERP exchange is successful, and the local ER server sent a
DSRK request, the home ER server MUST include the DSRK for the
local ER server (derived using the EMSK and the domain name as
specified in [3]), EMSKname, and DSRK lifetime along with the EAP-
Finish/Re-auth message.
o ERP交換がうまくいっていて、ローカルのERサーバがDSRK要求を送ったなら、ホームERサーバはローカルのERサーバのためのDSRKを含まなければなりません。(EAP再終わり/authメッセージに伴う[3])、EMSKname、およびDSRK生涯指定されるとしてEMSKとドメイン名を使用することで、引き出されます。
o In addition, the rMSK is sent along with the EAP-Finish/Re-auth
message, in a AAA attribute [12].
o さらに、再EAP-終わり/authメッセージと共にAAA属性[12]でrMSKを送ります。
o The local ER server MUST extract the DSRK, EMSKname, and DSRK
lifetime (if present), before forwarding the EAP-Finish/Re-auth
message to the peer, as specified in [12].
o ローカルのERサーバは[12]のDSRK、EMSKname、および指定されるとして再EAP-終わり/authメッセージを同輩に転送する前のDSRK生涯(存在しているなら)を抽出しなければなりません。
o The authenticator receives the rMSK.
o 固有識別文字はrMSKを受けます。
o When the peer receives an EAP-Finish/Re-auth message with the
bootstrap flag set, if a local domain name is present, it MUST use
that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName-
NAI, and initialize the replay counter for the DS-rIK. If not,
the peer SHOULD derive the domain-specific keys using the domain
name it learned via the lower layer or from the EAP-Initiate/
Re-auth-Start message. If the peer does not know the domain name,
it must assume that there is no local ER server available.
o 同輩がいつで再EAP-終わり/authメッセージを受け取るか、旗のセットを独力で進んでください、局所領域名が存在していて、適切なDSRK、DS-rRK、DS-rIK、およびkeyName- NAIを引き出すのにそれを使用して、DS-rIKのために再生カウンタを初期化しなければならないなら。 そうでなければ、同輩SHOULDは、それが下層かauthの再EAP-開始/開始メッセージから学んだドメイン名を使用することでドメイン特有のキーを引き出します。 同輩がドメイン名を知らないなら、それは、利用可能などんなローカルのERサーバもないと仮定しなければなりません。
Narayanan & Dondeti Standards Track [Page 17] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[17ページ]。
o The peer MAY also verify the Authorization Indication TLV.
o また、同輩はAuthorization Indication TLVについて確かめるかもしれません。
o The procedures for encapsulating the ERP and obtaining relevant
keys using RADIUS and Diameter are specified in [12] and [15],
respectively.
o RADIUSとDiameterを使用することでERPをカプセル化して、関連キーを入手するための手順は[12]と[15]でそれぞれ指定されます。
Since the ER bootstrapping exchange is typically done immediately following the full EAP exchange, it is feasible that the process is completed through the same entity that served as the EAP authenticator for the full EAP exchange. In this case, the lower layer may already have established TSKs based on the MSK received earlier. The lower layer may then choose to ignore the rMSK that was received with the ER bootstrapping exchange. Alternatively, the lower layer may choose to establish a new TSK using the rMSK. In either case, the authenticator and the peer know which key is used based on whether or not a TSK establishment exchange is initiated. The bootstrapping exchange may also be carried out via a new authenticator, in which case, the rMSK received SHOULD trigger a lower layer TSK establishment exchange.
交換を独力で進むERがすぐに完全なEAP交換に続き通常終わっているので、過程が完全なEAP交換のためのEAP固有識別文字として機能したのと同じ実体を通して完了しているのは、可能です。 この場合、下層は既により早く受け取られたMSKに基づくTSKsを設立したかもしれません。 そして、下層は、ERが交換を独力で進んでいて受け取られたrMSKを無視するのを選ぶかもしれません。 あるいはまた、下層は、rMSKを使用することで新しいTSKを設立するのを選ぶかもしれません。 どちらの場合ではも、固有識別文字と同輩は、TSK設立交換が起こされるかどうかに基づいてどのキーが使用されるかを知っています。 また、ブートストラップ法交換が新しい固有識別文字で行われるかもしれません、その場合、rMSKの容認されたSHOULDは下層TSK設立交換の引き金となります。
5.2. Steps in ERP
5.2. ERPのステップ
When a peer that has an active rRK and rIK associates with a new authenticator that supports ERP, it may perform an ERP exchange with that authenticator. ERP is typically a peer-initiated exchange, consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth message. The ERP exchange may be performed with a local ER server (when one is present) or with the original EAP server.
アクティブなrRKとrIKを持っている同輩がERPをサポートする新しい固有識別文字と交際するとき、それはその固有識別文字でERP交換を実行するかもしれません。 ERPは通常同輩によって開始された交換と、再EAP-開始/authから成って、再EAP-終わり/authメッセージです。 ERP交換はローカルのERサーバ(1つが存在しているとき)かオリジナルのEAPサーバで実行されるかもしれません。
It is plausible for the network to trigger the EAP re-authentication process, however. An ERP-capable authenticator SHOULD send an EAP- Initiate/Re-auth-Start message to indicate support for ERP. The peer may or may not wait for these messages to arrive to initiate the EAP- Initiate/Re-auth message.
ネットワークが. しかしながら、EAP再認証過程、SHOULDがERPのサポートを示すためにEAP authの再開始/開始メッセージを送るERPできる固有識別文字の引き金となるのは、もっともらしいです。 同輩は、EAP再開始/authメッセージを開始するのを到着するこれらのメッセージを待つかもしれません。
The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP- capable authenticator. The authenticator may retransmit it a few times until it receives an EAP-Initiate/Re-auth message in response from the peer. The EAP-Initiate/Re-auth message from the peer may have originated before the peer receives either an EAP-Request/ Identity or an EAP-Initiate/Re-auth-Start message from the authenticator. Hence, the Identifier value in the EAP-Initiate/ Re-auth message is independent of the Identifier value in the EAP- Initiate/Re-auth-Start or the EAP-Request/Identity messages.
/auth再開始メッセージSHOULDをEAP開始してください。ERPできる固有識別文字で、送ってください。 同輩から応答における再EAP-開始/authメッセージを受け取るまで、固有識別文字はそれを数回再送するかもしれません。 同輩が固有識別文字からEAP-要求/アイデンティティかauthの再EAP-開始/開始メッセージのどちらかを受け取る前に同輩からの再EAP-開始/authメッセージは起因したかもしれません。 したがって、再EAP-開始/authメッセージのIdentifier値はEAP authの再開始/始めかEAP-要求/アイデンティティメッセージのIdentifier価値から独立しています。
Narayanan & Dondeti Standards Track [Page 18] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[18ページ]。
Operational Considerations at the Peer:
同輩の操作上の問題:
ERP requires that the peer maintain retransmission timers for reliable transport of EAP re-authentication messages. The reliability considerations of Section 4.3 of RFC 3748 apply with the peer as the retransmitting entity.
ERPは、同輩がEAP再認証メッセージの信頼できる輸送のための再送信タイマーを維持するのを必要とします。 RFC3748のセクション4.3の信頼性の問題は同輩と共に再送実体として適用されます。
The EAP Re-auth Protocol has the following steps:
EAP Re-authプロトコルには、以下のステップがあります:
The peer sends an EAP-Initiate/Re-auth message. At a minimum, the
message SHALL include the following fields:
同輩は再EAP-開始/authメッセージを送ります。 最小限では、メッセージSHALLは以下の分野を含んでいます:
a 16-bit sequence number for replay protection
反復操作による保護のための16ビットの一連番号
keyName-NAI as a TLV attribute to identify the rIK used to
integrity protect the message.
保全に使用されるrIKを特定するTLV属性としてのkeyName-NAIはメッセージを保護します。
cryptosuite to indicate the authentication algorithm used to
compute the integrity checksum.
認証アルゴリズムを示すcryptosuiteは以前はよく保全チェックサムを計算していました。
authentication tag over the message.
メッセージの上の認証タグ。
When the peer is performing ERP with a local ER server, it MUST
use the corresponding DS-rIK it shares with the local ER server.
The peer SHOULD set the lifetime flag to request the key lifetimes
from the server. The peer can use the rRK lifetime to know when
to trigger an EAP method exchange and the rMSK lifetime to know
when to trigger another ERP exchange.
同輩がローカルのERサーバでERPを実行しているとき、それはローカルのERサーバと共有する対応するDS-rIKを使用しなければなりません。同輩SHOULDは、サーバから主要な生涯を要求するように生涯旗に決めます。同輩は、いつ別のERP交換の引き金となるかを知るためにいつEAPメソッド交換とrMSK生涯の引き金となるかを知るためにrRK生涯を費やすことができます。
The authenticator copies the contents of the value field of the
keyName-NAI TLV into the User-Name RADIUS attribute in the AAA
message to the ER server.
固有識別文字はERサーバへのAAAメッセージのUser-名前RADIUS属性にkeyName-NAI TLVの値の分野のコンテンツをコピーします。
The server uses the keyName-NAI to look up the rIK. It MUST first
verify whether the sequence number is equal to or greater than the
expected sequence number. If the server supports a sequence
number window size greater than 1, it MUST verify whether the
sequence number falls within the window and has not been received
before. The server MUST then verify to ensure that the
cryptosuite used by the peer is acceptable. The server then
proceeds to verify the integrity of the message using the rIK,
thereby verifying proof of possession of that key by the peer. If
any of these verifications fail, the server MUST send an EAP-
Finish/Re-auth message with the Result flag set to '1' (Failure).
Please refer to Section 5.2.2 for details on failure handling.
Otherwise, it MUST compute an rMSK from the rRK using the sequence
number as the additional input to the key derivation.
サーバは、rIKを見上げるのにkeyName-NAIを使用します。 それは、最初に、一連番号が予想された一連番号より等しいか、または大きいかどうか確かめなければなりません。 サーバが、一連番号ウィンドウサイズが1以上であるとサポートするなら、それを一連番号が窓の中に下がるかどうか確かめなければならなくて、以前、受け取ったことがありません。 そして、サーバは、同輩によって使用されたcryptosuiteが許容できるのを保証することを確かめなければなりません。 次に、サーバはrIKを使用することでメッセージの保全について確かめかけます、その結果、同輩はそのキーの所持の証拠について確かめます。 これらの検証のどれかが失敗するなら、サーバは'1'(失敗)に設定されたResult旗でEAP再終わり/authメッセージを送らなければなりません。 失敗取り扱いに関する詳細についてセクション5.2.2を参照してください。 さもなければ、それは追加入力として一連番号を使用するrRKから主要な派生までrMSKを計算しなければなりません。
Narayanan & Dondeti Standards Track [Page 19] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[19ページ]。
In response to a well-formed EAP Re-auth/Initiate message, the
server MUST send an EAP-Finish/Re-auth message with the following
considerations:
整形式のEAP Re-auth/開始メッセージに対応して、サーバは以下の問題がある再EAP-終わり/authメッセージを送らなければなりません:
a 16-bit sequence number for replay protection, which MUST be
the same as the received sequence number. The local copy of
the sequence number MUST be incremented by 1. If the server
supports multiple simultaneous ERP exchanges, it MUST instead
update the sequence number window.
反復操作による保護のための16ビットの一連番号。(それは、容認された一連番号と同じであるに違いありません)。 一連番号の地方のコピーを1つ増加しなければなりません。 サーバが複数の同時のERP交換をサポートするなら、それは代わりに一連番号ウィンドウをアップデートしなければなりません。
keyName-NAI as a TLV attribute to identify the rIK used to
integrity protect the message.
保全に使用されるrIKを特定するTLV属性としてのkeyName-NAIはメッセージを保護します。
cryptosuite to indicate the authentication algorithm used to
compute the integrity checksum.
認証アルゴリズムを示すcryptosuiteは以前はよく保全チェックサムを計算していました。
authentication tag over the message.
メッセージの上の認証タグ。
If the lifetime flag was set in the EAP-Initiate/Re-auth
message, the ER server SHOULD include the rRK lifetime and the
rMSK lifetime.
生涯旗が再EAP-開始/authメッセージに設定されたなら、ERサーバSHOULDはrRK生涯、rMSK生涯を含んでいます。
The server transports the rMSK along with this message to the
authenticator. The rMSK is transported in a manner similar to the
MSK transport along with the EAP-Success message in a regular EAP
exchange.
サーバはこのメッセージに伴うrMSKを固有識別文字に輸送します。 rMSKは定期的なEAP交換におけるEAP-成功メッセージに伴うMSK輸送と同様の方法で輸送されます。
The peer looks up the sequence number to verify whether it is
expecting an EAP-Finish/Re-auth message with that sequence number
protected by the keyName-NAI. It then verifies the integrity of
the message. If the verifications fail, the peer logs an error
and stops the process; otherwise, it proceeds to the next step.
同輩は、それがその一連番号がkeyName-NAIによって保護されている再EAP-終わり/authメッセージを予想しているかどうか確かめるために一連番号を見上げます。 そして、それはメッセージの保全について確かめます。 検証が失敗するなら、同輩は、誤りを登録して、プロセスを止めます。 さもなければ、それは次のステップに進みます。
The peer uses the sequence number to compute the rMSK.
同輩は、rMSKを計算するのに一連番号を使用します。
The lower-layer security association protocol can be triggered at
this point.
ここに下層セキュリティ協会プロトコルを引き起こすことができます。
5.2.1. Multiple Simultaneous Runs of ERP
5.2.1. ERPの複数の同時の走行
When a peer is within the range of multiple authenticators, it may choose to run ERP via all of them simultaneously to the same ER server. In that case, it is plausible that the ERP messages may arrive out of order, resulting in the ER server rejecting legitimate EAP-Initiate/Re-auth messages.
同輩が複数の固有識別文字の範囲の中にいるとき、それは、同時にそれらのすべてを通して同じERサーバにERPを実行するのを選ぶかもしれません。その場合、ERPメッセージが故障していた状態で到着するのは、もっともらしいです、再正統のEAP-開始/authメッセージを拒絶するERサーバをもたらして。
Narayanan & Dondeti Standards Track [Page 20] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[20ページ]。
To facilitate such operation, an ER server MAY allow multiple simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth messages with SEQ number values within a window of allowed values. Recall that the SEQ number allows replay protection. Replay window maintenance mechanisms are a local matter.
そのような操作を容易にするために、ERサーバは許容値の窓の中にSEQ数の値がある状態ですべての再EAP-開始/authメッセージを受け入れることによって、複数の同時のERP交換を許容するかもしれません。 SEQ番号が反復操作による保護を許容すると思い出してください。 再生ウィンドウメインテナンスメカニズムは地域にかかわる事柄です。
5.2.2. ERP Failure Handling
5.2.2. ERP失敗取り扱い
If the processing of the EAP-Initiate/Re-auth message results in a failure, the ER server MUST send an EAP-Finish Re-auth message with the Result flag set to '1'. If the server has a valid rIK for the peer, it MUST integrity protect the EAP-Finish/Re-auth failure message. If the failure is due to an unacceptable cryptosuite, the server SHOULD send a list of acceptable cryptosuites (in a TLV of Type 5) along with the EAP-Finish/Re-auth message. In this case, the server MUST indicate the cryptosuite used to protect the EAP-Finish/ Re-auth message in the cryptosuite. The rIK used with the EAP- Finish/Re-auth message in this case MUST be computed as specified in Section 4.3 using the new cryptosuite. If the server does not have a valid rIK for the peer, the EAP-Finish/Re-auth message indicating a failure will be unauthenticated; the server MAY include a list of acceptable cryptosuites in the message.
再EAP-開始/authメッセージの処理が失敗をもたらすなら、ERサーバは'1'に設定されたResult旗でEAP-終わりのRe-authメッセージを送らなければなりません。 サーバに同輩のための有効なrIKがあるなら、それは持たなければなりません。保全は再EAP-終わり/auth失敗メッセージを保護します。 失敗が容認できないcryptosuiteのためであるなら、サーバSHOULDは再EAP-終わり/authメッセージと共に許容できるcryptosuitesのリストを送ります(Type5のTLVで)。 この場合、サーバは、cryptosuiteが以前はよくcryptosuiteの再EAP-終わり/authメッセージを保護していたのを示さなければなりません。 この場合EAP再終わり/authメッセージと共に使用されているrIKとして、新しいcryptosuiteを使用して、セクション4.3で指定されていた状態で計算しなければなりません。 サーバに同輩のための有効なrIKがないと、失敗を示す再EAP-終わり/authメッセージは非認証されるでしょう。 サーバはメッセージに許容できるcryptosuitesのリストを含むかもしれません。
The peer, upon receiving an EAP-Finish/Re-auth message with the Result flag set to '1', MUST verify the sequence number and the Authentication Tag to determine the validity of the message. If the peer supports the cryptosuite, it MUST verify the integrity of the received EAP-Finish/Re-auth message. If the EAP-Finish message contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with a cryptosuite picked from the list included by the server. The peer MUST use the appropriate rIK for the subsequent ERP exchange, by computing it with the corresponding cryptosuite, as specified in Section 4.3. If the PRF in the chosen cryptosuite is different from the PRF originally used by the peer, it MUST derive a new DSRK (if required), rRK, and rIK before proceeding with the subsequent ERP exchange.
Result旗のセットで再EAP-終わり/authメッセージを'1'に受け取るとき、同輩は、メッセージの正当性を決定するために一連番号とAuthentication Tagについて確かめなければなりません。 同輩がcryptosuiteをサポートするなら、それは再容認されたEAP-終わり/authメッセージの保全について確かめなければなりません。 EAP-終わりのメッセージがType5のTLVを含んでいるなら、サーバでcryptosuiteがリストから選ばれているERP交換を含んでいて、同輩SHOULDは再試行します。同輩はその後のERP交換に適切なrIKを使用しなければなりません、対応するcryptosuiteでそれを計算することによって、セクション4.3で指定されるように。 選ばれたcryptosuiteのPRFが元々同輩によって使用されたPRFと異なるなら、その後のERP交換を続ける前に、それは新しいDSRK(必要なら)、rRK、およびrIKを引き出さなければなりません。
If the peer cannot verify the integrity of the received message, it MAY choose to retry the ERP exchange with one of the cryptosuites in the TLV of Type 5, after a failure has been clearly determined following the procedure in the next paragraph.
同輩が受信されたメッセージの保全について確かめることができないなら、Type5のTLVのcryptosuitesの1つでERP交換を再試行するのを選ぶかもしれません、失敗が次のパラグラフで手順に従いながら明確に決定した後に。
If the replay or integrity checks fail, the failure message may have been sent by an attacker. It may also imply that the server and peer do not support the same cryptosuites; however, the peer cannot determine if that is the case. Hence, the peer SHOULD continue the ERP exchange per the retransmission timers before declaring a failure.
再生か保全チェックが失敗するなら、失敗メッセージは攻撃者によって送られたかもしれません。 また、それは、サーバと同輩が同じcryptosuitesをサポートしないのを含意するかもしれません。 しかしながら、同輩は、それがそうであるかどうかと決心できません。 したがって、失敗を宣言する前に、同輩SHOULDは1再送信タイマーあたりのERP交換を続けています。
Narayanan & Dondeti Standards Track [Page 21] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[21ページ]。
When the peer runs explicit bootstrapping (ERP with the bootstrapping flag on), there may not be a local ER server available to send a DSRK Request and the domain name. In that case, the server cannot send the DSRK and MUST NOT include the domain name TLV. When the peer receives a response in the bootstrapping exchange without a domain name TLV, it assumes that there is no local ER server. The home ER server sends an rMSK to the ER authenticator, however, and the peer SHALL run the TSK establishment protocol as usual.
同輩が明白なブートストラップ法(ブートストラップ法旗がオンのERP)を実行するとき、DSRK Requestとドメイン名を送るために利用可能なローカルのERサーバがないかもしれません。 その場合、サーバは、DSRKを送ることができないで、ドメイン名TLVを含んではいけません。 どんなローカルのERサーバもありません。しかしながら、ホームERサーバがER固有識別文字にrMSKを送ると仮定します、そして、同輩がブートストラップ法で応答を受けたらドメイン名なしでTLVを交換してください、そして、同輩SHALLはいつものようにTSK設立プロトコルを述べます。
5.3. New EAP Packets
5.3. 新しいEAPパケット
Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate and EAP-Finish. The packet format for these messages follows the EAP packet format defined in RFC 3748 [2].
2新しいEAP CodesがERPの目的のために定義されます: EAP-開始とEAP-終わり。 これらのメッセージのためのパケット・フォーマットはRFC3748[2]で定義されたEAPパケット・フォーマットに続きます。
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 | Type-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| タイプデータ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: EAP Packet
図6: EAPパケット
Code
コード
5 Initiate
5開始
6 Finish
6 終わり
Two new code values are defined for the purpose of ERP.
2つの新法値がERPの目的のために定義されます。
Identifier
識別子
The Identifier field is one octet. The Identifier field MUST
be the same if an EAP-Initiate packet is retransmitted due to a
timeout while waiting for a Finish message. Any new
(non-retransmission) Initiate message MUST use a new Identifier
field.
Identifier分野は1つの八重奏です。 EAP-開始パケットがタイムアウトのためFinishメッセージを待っている間、再送されるなら、Identifier分野は同じであるに違いありません。 どんな新しい(非「再-トランスミッション」の)開始メッセージも新しいIdentifier分野を使用しなければなりません。
The Identifier field of the Finish message MUST match that of
the currently outstanding Initiate message. A peer or
authenticator receiving a Finish message whose Identifier value
does not match that of the currently outstanding Initiate
message MUST silently discard the packet.
FinishメッセージのIdentifier分野は現在傑出しているInitiateメッセージのものに合わなければなりません。 Identifier値が現在傑出しているInitiateメッセージのものに合っていないFinishメッセージを受け取る同輩か固有識別文字が静かにパケットを捨てなければなりません。
Narayanan & Dondeti Standards Track [Page 22] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[22ページ]。
In order to avoid confusion between new EAP-Initiate messages
and retransmissions, the peer must choose an Identifier value
that is different from the previous EAP-Initiate message,
especially if that exchange has not finished. It is
RECOMMENDED that the authenticator clear EAP Re-auth state
after 300 seconds.
新しいEAP-開始メッセージと「再-トランスミッション」の間の混乱を避けるために、同輩は前のEAP-開始メッセージと異なったIdentifier値を選ばなければなりません、特にその交換が終わっていないなら。 それは固有識別文字の明確なEAP Re-authが300秒以降述べるRECOMMENDEDです。
Type
タイプ
This field indicates that this is an ERP exchange. Two type
values are defined in this document for this purpose --
Re-auth-Start (assigned Type 1) and Re-auth (assigned Type 2).
この分野は、これがERP交換であると暗示します。 2つのタイプ値が本書ではこのために定義されます--authの再始め(Type1を割り当てる)とRe-auth(Type2を割り当てます)。
Type-Data
タイプデータ
The Type-Data field varies with the Type of re-authentication
packet.
Type-データ・フィールドは再認証パケットのTypeと共に異なります。
5.3.1. EAP-Initiate/Re-auth-Start Packet
5.3.1. authの再EAP-開始/スタートパケット
The EAP-Initiate/Re-auth-Start packet contains the parameters shown in Figure 7.
authの再EAP-開始/スタートパケットは図7に示されたパラメタを含んでいます。
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 | Reserved | 1 or more TVs or TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 予約されます。| 1テレビかTLVs~+++++++++++++++++++++++++++++++++
Figure 7: EAP-Initiate/Re-auth-Start Packet
図7: authの再EAP-開始/スタートパケット
Type = 1.
=1をタイプしてください。
Reserved, MUST be zero. Set to zero on transmission and ignored
on reception.
予約されて、ゼロでなければなりません。 トランスミッションのときにゼロに設定されて、レセプションで無視されます。
One or more TVs or TLVs are used to convey information to the
peer; for instance, the authenticator may send the domain name to
the peer.
1テレビかTLVsが同輩に情報を伝達するのに使用されます。 例えば、固有識別文字はドメイン名を同輩に送るかもしれません。
TVs or TLVs: In the TV payloads, there is a 1-octet type payload
and a value with type-specific length. In the TLV payloads, there
is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number
of octets.
テレビかTLVs: テレビのペイロードには、1八重奏のタイプペイロードとタイプ特有の長さがある値があります。 TLVペイロードには、1八重奏のタイプペイロードと1八重奏の長さのペイロードがあります。 長さの分野は八重奏の数で言い表された値の長さを示します。
Narayanan & Dondeti Standards Track [Page 23] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[23ページ]。
Domain-Name: This is a TLV payload. The Type is 4. The domain
name is to be used as the realm in an NAI [4]. The Domain-Name
attribute SHOULD be present in an EAP-Initiate/Re-auth-Start
message.
ドメイン名: これはTLVペイロードです。 Typeは4歳です。 ドメイン名は分野としてNAI[4]で使用されることです。 Domain-名前はEAP-開始でのプレゼントが/auth再開始メッセージであったならSHOULDを結果と考えます。
In addition, channel binding information MAY be included; see
Section 5.5 for discussion. See Figure 11 for parameter
specification.
さらに、情報を縛るチャンネルは含まれるかもしれません。 議論に関してセクション5.5を見てください。 パラメタ仕様に関して図11を見てください。
5.3.1.1. Authenticator Operation
5.3.1.1. 固有識別文字操作
The authenticator MAY send the EAP-Initiate/Re-auth-Start message to indicate support for ERP to the peer and to initiate ERP if the peer has already performed full EAP authentication and has unexpired key material. The authenticator SHOULD include the domain name TLV to allow the peer to learn it without lower-layer support or the ERP bootstrapping exchange.
同輩が既に完全なEAP認証を実行して、満期になっていない主要な材料を持っているなら、固有識別文字は、ERPのサポートを同輩に示して、ERPを開始するためにauthの再EAP-開始/開始メッセージを送るかもしれません。 固有識別文字SHOULDは、同輩が下層サポートも交換を独力で進むERPなしでそれを学ぶのを許容するためにドメイン名TLVを含んでいます。
The authenticator MAY include channel binding information so that the peer can send the information to the server in the EAP-Initiate/ Re-auth message so that the server can verify whether the authenticator is claiming the same identity to both parties.
固有識別文字はサーバが、固有識別文字が双方への同じアイデンティティを要求しているかどうか確かめることができるように同輩が再EAP-開始/authメッセージのサーバに情報を送ることができるように情報を縛るチャンネルを含むかもしれません。
The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start message a few times for reliable transport.
固有識別文字は信頼できる輸送のために数回authの再EAP-開始/開始メッセージを再送するかもしれません。
5.3.1.2. Peer Operation
5.3.1.2. 同輩操作
The peer SHOULD send the EAP-Initiate/Re-auth message in response to the EAP-Initiate/Re-auth-Start message from the authenticator. If the peer does not recognize the Initiate code value, it silently discards the message. If the peer has already sent the EAP-Initiate/ Re-auth message to begin the ERP exchange, it silently discards the message.
同輩SHOULDは固有識別文字からのauthの再EAP-開始/開始メッセージに対応して再EAP-開始/authメッセージを送ります。 同輩がInitiateコード値を認めないなら、それは静かにメッセージを捨てます。 同輩が既にERP交換を始める再EAP-開始/authメッセージを送ったなら、それは静かにメッセージを捨てます。
If the EAP-Initiate/Re-auth-Start message contains the domain name, and if the peer does not already have the domain information, the peer SHOULD use the domain name to compute the DSRK and use the corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start an ERP exchange with the local ER server. If the peer has already initiated an ERP exchange with the home ER server, it MAY choose to not start an ERP exchange with the local ER server.
同輩にドメイン情報が既にないならauthの再EAP-開始/開始メッセージがドメイン名を含んでいるなら、同輩SHOULDは、ローカルのERサーバからERP交換を始める再EAP-開始/authメッセージを送るのにDSRKを計算して、対応するDS-rIKを使用するのにドメイン名を使用します。同輩がホームERサーバで既にERP交換を起こしたなら、それは、ローカルのERサーバからERP交換を始めないのを選ぶかもしれません。
Narayanan & Dondeti Standards Track [Page 24] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[24ページ]。
5.3.2. EAP-Initiate/Re-auth Packet
5.3.2. 再EAP-開始/authパケット
The EAP-Initiate/Re-auth packet contains the parameters shown in Figure 8.
再EAP-開始/authパケットは図8に示されたパラメタを含んでいます。
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 |R|B|L| Reserved| SEQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 or more TVs or TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cryptosuite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|R|B|L| 予約されます。| SEQ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1テレビかTLVs~+++++++++++++++++++++++++++++++++| cryptosuite| 認証タグ~+++++++++++++++++++++++++++++++++
Figure 8: EAP-Initiate/Re-auth Packet
エイト環: 再EAP-開始/authパケット
Type = 2.
=2をタイプしてください。
Flags
旗
'R' - The R flag is set to 0 and ignored upon reception.
'R'--R旗は、0に設定されて、レセプションで無視されます。
'B' - The B flag is used as the bootstrapping flag. If the
flag is turned on, the message is a bootstrap message.
'B'--B旗はブートストラップ法旗として使用されます。 旗がつけられているなら、メッセージはaがメッセージを独力で進むということです。
'L' - The L flag is used to request the key lifetimes from the
server.
'L'--L旗は、サーバから主要な生涯を要求するのに使用されます。
The rest of the 5 bits are set to 0 and ignored on reception.
5ビットの残りは、0に設定されて、レセプションで無視されます。
SEQ: A 16-bit sequence number is used for replay protection. The
SEQ number field is initialized to 0 every time a new rRK is
derived.
SEQ: 16ビットの一連番号は反復操作による保護に使用されます。 新しいrRKが引き出されるときはいつも、SEQナンバーフィールドは0に初期化されます。
TVs or TLVs: In the TV payloads, there is a 1-octet type payload
and a value with type-specific length. In the TLV payloads, there
is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number
of octets.
テレビかTLVs: テレビのペイロードには、1八重奏のタイプペイロードとタイプ特有の長さがある値があります。 TLVペイロードには、1八重奏のタイプペイロードと1八重奏の長さのペイロードがあります。 長さの分野は八重奏の数で言い表された値の長さを示します。
keyName-NAI: This is carried in a TLV payload. The Type is 1.
The NAI is variable in length, not exceeding 253 octets. The
EMSKname is in the username part of the NAI and is encoded in
hexadecimal values. The EMSKname is 64 bits in length and so
the username portion takes up 128 octets. If the rIK is
keyName-NAI: これはTLVペイロードで運ばれます。 Typeは1歳です。 NAIは253の八重奏を超えているのではなく、長さで可変です。 EMSKnameはNAIのユーザ名部分にあって、16進値でコード化されます。 EMSKnameは長さが64ビットであるので、ユーザ名部分は128の八重奏を始めます。 rIKがそうなら
Narayanan & Dondeti Standards Track [Page 25] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[25ページ]。
derived from the EMSK, the realm part of the NAI is the home
domain name, and if the rIK is derived from a DSRK, the realm
part of the NAI is the domain name used in the derivation of
the DSRK. The NAI syntax follows [4]. Exactly one keyName-NAI
attribute SHALL be present in an EAP-Initiate/Re-auth packet.
EMSKから派生しています、NAIの分野の部分はホームドメイン名であり、DSRKからrIKを得るなら、NAIの分野の部分はDSRKの派生に使用されるドメイン名です。 NAI構文は[4]に続きます。 ちょうど1keyName-NAIが再EAP-開始/authでのプレゼントがパケットであったならSHALLを結果と考えます。
In addition, channel binding information MAY be included; see
Section 5.5 for discussion. See Figure 11 for parameter
specification.
さらに、情報を縛るチャンネルは含まれるかもしれません。 議論に関してセクション5.5を見てください。 パラメタ仕様に関して図11を見てください。
Cryptosuite: This field indicates the integrity algorithm used for
ERP. Key lengths and output lengths are either indicated or are
obvious from the cryptosuite name. We specify some cryptosuites
below:
Cryptosuite: この分野はERPに使用される保全アルゴリズムを示します。 キー長と出力の長さは、示されるか、またはcryptosuite名から明白です。 私たちは以下のいくらかのcryptosuitesを指定します:
* 0 RESERVED
* 予約された0
* 1 HMAC-SHA256-64
* 1 HMAC-SHA256-64
* 2 HMAC-SHA256-128
* 2 HMAC-SHA256-128
* 3 HMAC-SHA256-256
* 3 HMAC-SHA256-256
HMAC-SHA256-128 is mandatory to implement and should be enabled in
the default configuration.
HMAC-SHA256-128は実装するために義務的であり、デフォルト設定で有効にされるべきです。
Authentication Tag: This field contains the integrity checksum
over the ERP packet, excluding the authentication tag field
itself. The length of the field is indicated by the Cryptosuite.
認証タグ: 認証タグ・フィールド自体を除いて、この分野はERPパケットの上に保全チェックサムを含んでいます。 分野の長さはCryptosuiteによって示されます。
5.3.3. EAP-Finish/Re-auth Packet
5.3.3. 再EAP-終わり/authパケット
The EAP-Finish/Re-auth packet contains the parameters shown in Figure 9.
再EAP-終わり/authパケットは図9に示されたパラメタを含んでいます。
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 |R|B|L| Reserved | SEQ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 or more TVs or TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cryptosuite | Authentication Tag ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ|R|B|L| 予約されます。| SEQ~+++++++++++++++++++++++++++++++++| 1テレビかTLVs~+++++++++++++++++++++++++++++++++| cryptosuite| 認証タグ~+++++++++++++++++++++++++++++++++
Figure 9: EAP-Finish/Re-auth Packet
図9: 再EAP-終わり/authパケット
Narayanan & Dondeti Standards Track [Page 26] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[26ページ]。
Type = 2.
=2をタイプしてください。
Flags
旗
'R' - The R flag is used as the Result flag. When set to 0, it
indicates success, and when set to '1', it indicates a failure.
'R'--Resultが弛むとき、R旗は使用されています。 0に設定されると、成功を示します、そして、'1'に設定されると、失敗を示します。
'B' - The B flag is used as the bootstrapping flag. If the
flag is turned on, the message is a bootstrap message.
'B'--B旗はブートストラップ法旗として使用されます。 旗がつけられているなら、メッセージはaがメッセージを独力で進むということです。
'L' - The L flag is used to indicate the presence of the rRK
lifetime TLV.
'L'--L旗は、rRK生涯TLVの存在を示すのに使用されます。
The rest of the 5 bits are set to 0 and ignored on reception.
5ビットの残りは、0に設定されて、レセプションで無視されます。
SEQ: A 16-bit sequence number is used for replay protection. The
SEQ number field is initialized to 0 every time a new rRK is
derived.
SEQ: 16ビットの一連番号は反復操作による保護に使用されます。 新しいrRKが引き出されるときはいつも、SEQナンバーフィールドは0に初期化されます。
TVs or TLVs: In the TV payloads, there is a 1-octet type payload
and a value with type-specific length. In the TLV payloads, there
is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number
of octets.
テレビかTLVs: テレビのペイロードには、1八重奏のタイプペイロードとタイプ特有の長さがある値があります。 TLVペイロードには、1八重奏のタイプペイロードと1八重奏の長さのペイロードがあります。 長さの分野は八重奏の数で言い表された値の長さを示します。
keyName-NAI: This is carried in a TLV payload. The Type is 1.
The NAI is variable in length, not exceeding 253 octets.
EMSKname is in the username part of the NAI and is encoded in
hexadecimal values. The EMSKname is 64 bits in length and so
the username portion takes up 16 octets. If the rIK is derived
from the EMSK, the realm part of the NAI is the home domain
name, and if the rIK is derived from a DSRK, the realm part of
the NAI is the domain name used in the derivation of the DSRK.
The NAI syntax follows [4]. Exactly one instance of the
keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth
message.
keyName-NAI: これはTLVペイロードで運ばれます。 Typeは1歳です。 NAIは253の八重奏を超えているのではなく、長さで可変です。 EMSKnameはNAIのユーザ名部分にあって、16進値でコード化されます。 EMSKnameは長さが64ビットであるので、ユーザ名部分は16の八重奏を始めます。 EMSKからrIKを得るなら、NAIの分野の部分はホームドメイン名です、そして、DSRKからrIKを得るなら、NAIの分野の部分はDSRKの派生に使用されるドメイン名です。 NAI構文は[4]に続きます。 まさにkeyName-NAIの1つのインスタンスが再EAP-終わり/authでのプレゼントがメッセージであったならSHALLを結果と考えます。
rRK Lifetime: This is a TV payload. The Type is 2. The value
field is a 32-bit field and contains the lifetime of the rRK in
seconds. If the 'L' flag is set, the rRK Lifetime attribute
SHOULD be present.
rRK生涯: これはテレビのペイロードです。 Typeは2歳です。 値の分野は、32ビットの分野であり、秒にrRKの生涯を含みます。 'L'旗が設定されるなら、rRK LifetimeはSHOULDを結果と考えます。存在してください。
rMSK Lifetime: This is a TV payload. The Type is 3. The value
field is a 32-bit field and contains the lifetime of the rMSK
in seconds. If the 'L' flag is set, the rMSK Lifetime
attribute SHOULD be present.
rMSK生涯: これはテレビのペイロードです。 Typeは3歳です。 値の分野は、32ビットの分野であり、秒にrMSKの生涯を含みます。 'L'旗が設定されるなら、rMSK LifetimeはSHOULDを結果と考えます。存在してください。
Narayanan & Dondeti Standards Track [Page 27] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[27ページ]。
Domain-Name: This is a TLV payload. The Type is 4. The domain
name is to be used as the realm in an NAI [4]. Domain-Name
attribute MUST be present in an EAP-Finish/Re-auth message if
the bootstrapping flag is set and if the local ER server sent a
DSRK request.
ドメイン名: これはTLVペイロードです。 Typeは4歳です。 ドメイン名は分野としてNAI[4]で使用されることです。 ブートストラップ法旗が設定されて、ローカルのERサーバがDSRK要求を送ったなら、ドメイン名の属性は再EAP-終わり/authメッセージに存在していなければなりません。
List of cryptosuites: This is a TLV payload. The Type is 5.
The value field contains a list of cryptosuites, each of size 1
octet. The cryptosuite values are as specified in Figure 8.
The server SHOULD include this attribute if the cryptosuite
used in the EAP-Initiate/Re-auth message was not acceptable and
the message is being rejected. The server MAY include this
attribute in other cases. The server MAY use this attribute to
signal to the peer about its cryptographic algorithm
capabilities.
cryptosuitesのリスト: これはTLVペイロードです。 Typeは5歳です。 値の分野はcryptosuitesのリスト、それぞれのサイズ1八重奏を含んでいます。 cryptosuite値が図8で指定されるようにあります。 再EAP-開始/authメッセージで使用されるcryptosuiteが許容できないで、メッセージが拒絶されているなら、サーバSHOULDはこの属性を含んでいます。 サーバは他のケースにこの属性を含むかもしれません。 サーバは、暗号アルゴリズム能力に関して同輩に合図するのにこの属性を使用するかもしれません。
Authorization Indication: This is a TLV payload. The Type is
6. This attribute MAY be included in the EAP-Finish/Re-auth
message when a DSRK is delivered to a local ER server and if
the home ER server can verify the authorization of the local ER
server to advertise the domain name included in the domain TLV
in the same message. The value field in the TLV contains an
authentication tag computed over the entire packet, starting
from the first bit of the code field to the last bit of the
cryptosuite field, with the value field of the Authorization
Indication TLV filled with all 0s for the computation. The key
used for the computation MUST be derived from the EMSK with key
label "DSRK Delivery Authorized Key@ietf.org" and optional data
containing an ASCII string representing the key management
domain that the DSRK is being derived for.
承認指示: これはTLVペイロードです。 Typeは6歳です。 DSRKがローカルのERサーバに提供されるとき、この属性は再EAP-終わり/authメッセージに含まれたかもしれません、そして、ホームERサーバが広告を出すためにローカルのERサーバの承認について確かめることができるなら、ドメイン名は同じメッセージにそのドメインにTLVを含んでいました。 TLVの値の分野は全体のパケットの上で計算された認証タグを含んでいます、コード分野の最初のビットからcryptosuite分野の最後のビットまで始まって、Authorization Indication TLVの値の分野が計算のためにすべての0でいっぱいにされている状態で。 主要なラベル「DSRKの配送認可された Key@ietf.org 」と任意のデータがDSRKが引き出されているかぎ管理ドメインを表すASCIIストリングを含んでいて、EMSKから計算に使用されるキーを得なければなりません。
In addition, channel binding information MAY be included: see
Section 5.5 for discussion. See Figure 11 for parameter
specification. The server sends this information so that the
peer can verify the information seen at the lower layer, if
channel binding is to be supported.
さらに、情報を縛るチャンネルは含まれるかもしれません: 議論に関してセクション5.5を見てください。 パラメタ仕様に関して図11を見てください。 サーバは同輩が下層で見られた情報について確かめることができるように、この情報を送ります、チャンネル結合がサポートされることであるなら。
Cryptosuite: This field indicates the integrity algorithm and the
PRF used for ERP. Key lengths and output lengths are either
indicated or are obvious from the cryptosuite name.
Cryptosuite: この分野は保全アルゴリズムとERPに使用されるPRFを示します。 キー長と出力の長さは、示されるか、またはcryptosuite名から明白です。
Authentication Tag: This field contains the integrity checksum
over the ERP packet, excluding the authentication tag field
itself. The length of the field is indicated by the Cryptosuite.
認証タグ: 認証タグ・フィールド自体を除いて、この分野はERPパケットの上に保全チェックサムを含んでいます。 分野の長さはCryptosuiteによって示されます。
Narayanan & Dondeti Standards Track [Page 28] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[28ページ]。
5.3.4. TV and TLV Attributes
5.3.4. テレビとTLV属性
The TV attributes that may be present in the EAP-Initiate or EAP- Finish messages are of the following format:
EAP-開始かEAP終わりのメッセージに存在するかもしれないテレビの属性は以下の形式のものです:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TV Attribute Format
図10: テレビの属性形式
The TLV attributes that may be present in the EAP-Initiate or EAP- Finish messages are of the following format:
EAP-開始かEAP終わりのメッセージに存在するかもしれないTLV属性は以下の形式のものです:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TLV Attribute Format
図11: TLV属性形式
The following Types are defined in this document:
以下のTypesは本書では定義されます:
'1' - keyName-NAI: This is a TLV payload.
'1'--keyName-NAI、: これはTLVペイロードです。
'2' - rRK Lifetime: This is a TV payload.
'2'--rRK生涯: これはテレビのペイロードです。
'3' - rMSK Lifetime: This is a TV payload.
'3'--rMSK生涯: これはテレビのペイロードです。
'4' - domain name: This is a TLV payload.
'4'--ドメイン名: これはTLVペイロードです。
'5' - cryptosuite list: This is a TLV payload.
'5'--cryptosuiteリスト: これはTLVペイロードです。
'6' - Authorization Indication: This is a TLV payload.
'6'--承認指示: これはTLVペイロードです。
The TLV type range of 128-191 is reserved to carry channel binding
information in the EAP-Initiate and Finish/Re-auth messages.
Below are the current assignments (all of them are TLVs):
128-191のTLVタイプ範囲は、EAP-開始で情報を縛るチャンネルと再Finish/authメッセージを伝えるために予約されます。 以下に、現在の課題があります(それらは皆、TLVsです):
'128' - Called-Station-Id [13]
'128'--呼ばれた駅のイド[13]
'129' - Calling-Station-Id [13]
'129'--呼んでいる駅のイド[13]
'130' - NAS-Identifier [13]
'130'--NAS-識別子[13]
Narayanan & Dondeti Standards Track [Page 29] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[29ページ]。
'131' - NAS-IP-Address [13]
'131'--NAS IPアドレス[13]
'132' - NAS-IPv6-Address [16]
'132'--NAS-IPv6-アドレス[16]
The length field indicates the length of the value part of the attribute in octets.
長さの分野は八重奏における、属性の値の部の長さを示します。
5.4. Replay Protection
5.4. 反復操作による保護
For replay protection, ERP uses sequence numbers. The sequence number is maintained per rIK and is initialized to zero in both directions. In the first EAP-Initiate/Re-auth message, the peer uses the sequence number zero or higher. Note that the when the sequence number rotates, the rIK MUST be changed by running EAP authentication. The server expects a sequence number of zero or higher. When the server receives an EAP-Initiate/Re-auth message, it uses the same sequence number in the EAP-Finish/Re-auth message. The server then sets the expected sequence number to the received sequence number plus 1. The server accepts sequence numbers greater than or equal to the expected sequence number.
反復操作による保護のために、ERPは一連番号を使用します。 一連番号は、rIK単位で維持されて、両方の方向でゼロに初期化されます。 再最初のEAP-開始/authメッセージでは、同輩は一連番号ゼロ以上を使用します。 それに注意してください、一連番号が回転するとき、EAP認証を実行することによって、rIKを変えなければなりません。 サーバはゼロ以上の一連番号を予想します。 サーバが再EAP-開始/authメッセージを受け取るとき、それは再EAP-終わり/authメッセージで同じ一連番号を使用します。 そして、サーバは容認された一連番号と1に予想された一連番号を設定します。 サーバは一連番号をより受け入れます。予想された一連番号。
If the peer sends an EAP-Initiate/Re-auth message, but does not receive a response, it retransmits the request (with no changes to the message itself) a pre-configured number of times before giving up. However, it is plausible that the server itself may have responded to the message and it was lost in transit. Thus, the peer MUST increment the sequence number and use the new sequence number to send subsequent EAP re-authentication messages. The peer SHOULD increment the sequence number by 1; however, it may choose to increment by a larger number. When the sequence number rotates, the peer MUST run full EAP authentication.
同輩が再EAP-開始/authメッセージを送りますが、応答を受けないなら、それはあきらめる前のあらかじめ設定された数の回要求(メッセージ自体への変化のない)を再送します。 しかしながら、サーバ自体がメッセージに反応したのが、もっともらしく、それはトランジットで失われました。 したがって、同輩は、その後のEAP再認証にメッセージを送るのに一連番号を増加して、新しい一連番号を使用しなければなりません。 同輩SHOULDは一連番号を1つ増加します。 しかしながら、それは、より大きい数によって増分に選ばれるかもしれません。 一連番号が回転すると、同輩は完全なEAP認証を実行しなければなりません。
5.5. Channel Binding
5.5. チャンネル結合
ERP provides a protected facility to carry channel binding (CB) information, according to the guidelines in Section 7.15 of [2]. The TLV type range of 128-191 is reserved to carry CB information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages. Called- Station-Id, Calling-Station-Id, NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address are some examples of channel binding information listed in RFC 3748, and they are assigned values 128-132. Additional values are IANA managed based on IETF Consensus [17].
ERPは、[2]のセクション7.15のガイドラインによると、チャンネル結合(CB)情報を運ぶために保護された施設を提供します。 128-191のTLVタイプ範囲は、再EAP-開始/authと再EAP-終わり/authメッセージのCB情報を運ぶために予約されます。 駅イド、Calling駅のイド、NAS-識別子、NAS IPアドレス、およびNAS-IPv6-アドレスと呼ばれているのが、RFC3748にリストアップされた情報を縛るチャンネルに関するいくつかの例であり、それらは割り当てられた値128-132です。 加算値はIETF Consensus[17]に基づいて管理されたIANAです。
The authenticator MAY provide CB information to the peer via the EAP- Initiate/Re-auth-Start message. The peer sends the information to the server in the EAP-Initiate/Re-auth message; the server verifies whether the authenticator identity available via AAA attributes is the same as the identity provided to the peer.
固有識別文字はEAP authの再開始/開始メッセージで同輩への情報をCBに供給するかもしれません。 同輩は再EAP-開始/authメッセージのサーバに情報を送ります。 アイデンティティが同輩に提供されたので、サーバは、AAA属性を通して利用可能な固有識別文字のアイデンティティが同じであるかどうか確かめます。
Narayanan & Dondeti Standards Track [Page 30] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[30ページ]。
If the peer does not include the CB information in the EAP-Initiate/ Re-auth message, and if the local ER server's policy requires channel binding support, it SHALL send the CB attributes for the peer's verification. The peer attempts to verify the CB information if the authenticator has sent the CB parameters, and it proceeds with the lower-layer security association establishment if the attributes match. Otherwise, the peer SHALL NOT proceed with the lower-layer security association establishment.
同輩がそうしないなら、再EAP-開始/authメッセージのCB情報とローカルのERサーバの方針がサポートを縛るチャンネルを必要とするかどうかを含めてください、それ。SHALLは同輩の検証のためにCB属性を送ります。 固有識別文字がCBパラメタを送ったなら、同輩は、CB情報について確かめるのを試みます、そして、属性が合うなら、それは下層セキュリティ協会設立を続けます。 さもなければ、同輩SHALL NOTは下層セキュリティ協会設立を続けます。
6. Lower-Layer Considerations
6. 下層問題
The authenticator is responsible for retransmission of EAP-Initiate/ Re-auth-Start messages. The authenticator MAY retransmit the message a few times or until it receives an EAP-Initiate/Re-auth message from the peer. The authenticator may not know whether the peer supports ERP; in those cases, the peer may be silently dropping the EAP- Initiate/Re-auth-Start packets. Thus, retransmission of these packets should be kept to a minimum. The exact number is up to each lower layer.
固有識別文字はauthの再EAP-開始/開始メッセージの「再-トランスミッション」に原因となります。 数回か同輩から再EAP-開始/authメッセージを受け取るまで、固有識別文字はメッセージを再送するかもしれません。 固有識別文字は、同輩がERPをサポートするかどうかを知らないかもしれません。 それらの場合では、同輩は静かにEAP authの再開始/スタートパケットを下げているかもしれません。 したがって、これらのパケットの「再-トランスミッション」は最小限に保たれるべきです。 はっきりした数は各下層まで達しています。
The Identifier value in the EAP-Initiate/Re-auth packet is independent of the Identifier value in the EAP-Initiate/Re-auth-Start packet.
再EAP-開始/authパケットのIdentifier値はauthの再EAP-開始/スタートパケットのIdentifier価値から独立しています。
The peer is responsible for retransmission of EAP-Initiate/Re-auth messages.
同輩は再EAP-開始/authメッセージの「再-トランスミッション」に責任があります。
Retransmitted packets MUST be sent with the same Identifier value in order to distinguish them from new packets. By default, where the EAP-Initiate message is sent over an unreliable lower layer, the retransmission timer SHOULD be dynamically estimated. A maximum of 3-5 retransmissions is suggested (this is based on the recommendation of [2]). Where the EAP-Initiate message is sent over a reliable lower layer, the retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. Please refer to RFC 3748 [2] for additional guidance on setting timers.
新しいパケットとそれらを区別するために同じIdentifier値と共に再送されたパケットを送らなければなりません。 デフォルトで、EAP-開始メッセージがどこにあるかが頼り無い下層、再送信タイマーSHOULDを移動しました。ダイナミックに見積もられています。 最大3-5「再-トランスミッション」は示されます。(これは[2])の推薦に基づいています。 再送信タイマーSHOULDが無限の値に用意ができていて、その「再-トランスミッション」がEAP-開始メッセージを信頼できる下層の上に送るのでEAPに現れないところでは、層にしてください。 タイマを設定するときの追加指導のためのRFC3748[2]を参照してください。
The Identifier value in the EAP-Finish/Re-auth packet is the same as the Identifier value in the EAP-Initiate/Re-auth packet.
再EAP-終わり/authパケットのIdentifier値はIdentifierが再EAP-開始/authパケットで評価するのと同じです。
If an authenticator receives a valid duplicate EAP-Initiate/Re-auth message for which it has already sent an EAP-Finish/Re-auth message, it MUST resend the EAP-Finish/Re-auth message without reprocessing the EAP-Initiate/Re-auth message. To facilitate this, the authenticator SHALL store a copy of the EAP-Finish/Re-auth message for a finite amount of time. The actual value of time is a local matter; this specification recommends a value of 100 milliseconds.
固有識別文字がそれが既に再EAP-終わり/authメッセージを送った再有効な写しEAP-開始/authメッセージを受け取るなら、それは再処理のない再EAP-終わり/authメッセージに再EAP-開始/authメッセージを再送しなければなりません。 これを容易にするために、固有識別文字SHALLは有限時間への再EAP-終わり/authメッセージのコピーを保存します。 時間の実価は地域にかかわる事柄です。 この仕様は100ミリセカンドの値を推薦します。
Narayanan & Dondeti Standards Track [Page 31] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[31ページ]。
The lower layer may provide facilities for exchanging information between the peer and the authenticator about support for ERP, for the authenticator to send the domain name information and channel binding information to the peer
下層は、ドメイン名情報とチャンネルが固有識別文字で同輩に情報を縛るようにERPのサポートに関する同輩と固有識別文字の間で情報交換するために便宜を与えるかもしれません。
Note that to support ERP, lower-layer specifications may need to be revised. Specifically, the IEEE802.1x specification must be revised to allow carrying EAP messages of the new codes defined in this document in order to support ERP. Similarly, RFC 4306 must be updated to include EAP code values higher than 4 in order to use ERP with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may also be updated to support peer-initiated ERP for optimized operation. Other lower layers may need similar revisions.
ERPをサポートするのに、下層仕様が、改訂される必要であるかもしれないことに注意してください。 明確に、ERPをサポートするために本書では定義された新法に関するEAPメッセージを伝えるのを許容するためにIEEE802.1x仕様を改訂しなければなりません。 同様に、インターネット・キー・エクスチェンジプロトコルバージョン2(IKEv2)があるERPを使用するために4より高いEAPコード値を含むようにRFC4306をアップデートしなければなりません。 また、最適化された操作のために同輩によって開始されたERPをサポートするためにIKEv2をアップデートするかもしれません。 他の下層は同様の改正を必要とするかもしれません。
Our analysis indicates that some EAP implementations are not RFC 3748 compliant in that instead of silently dropping EAP packets with code values higher than 4, they may consider it an error. To accommodate such non-compliant EAP implementations, additional guidance has been provided below. Furthermore, it may not be easy to upgrade all the peers in some cases. In such cases, authenticators may be configured to not send EAP-Initiate/Re-auth-Start; peers may learn whether an authenticator supports ERP via configuration, from advertisements at the lower layer.
コード値が4より高い状態で静かにEAPパケットを下げることの代わりにそれが誤りであると考えるかもしれないので、私たちの分析は、いくつかのEAP実装がRFC3748対応でないことを示します。 そのような不従順なEAP実装を収容するために、追加指導を以下に提供しました。 その上、いくつかの場合、すべての同輩をアップグレードさせるのは簡単でないかもしれません。 そのような場合、固有識別文字はauthの再EAP-開始/始めを送らないように構成されるかもしれません。 同輩は、固有識別文字が広告から下層で構成でERPをサポートするかどうか学ぶかもしれません。
In order to accommodate implementations that are not compliant to RFC 3748, such lower layers SHOULD ensure that both parties support ERP; this is trivial for an instance when using a lower layer that is known to always support ERP. For lower layers where ERP support is not guaranteed, ERP support may be indicated through signaling (e.g., piggy-backed on a beacon) or through negotiation. Alternatively, clients may recognize environments where ERP is available based on pre-configuration. Other similar mechanisms may also be used. When ERP support cannot be verified, lower layers may mandate falling back to full EAP authentication to accommodate EAP implementations that are not compliant to RFC 3748.
RFC3748に対応でない実装を収容するために、そのような下層SHOULDは、双方がERPをサポートするのを確実にします。 いつもERPをサポートするのが知られている下層を使用するとき、インスタンスに、これは些細です。 ERPサポートが保証されない低級層において、ERPサポートはシグナリング(例えば、標識の上で背負われる)を通して、または、交渉を通して示されるかもしれません。 あるいはまた、クライアントはERPがプレ構成に基づいて利用可能である環境を認めるかもしれません。 また、他の同様のメカニズムは使用されるかもしれません。 ERPサポートについて確かめることができないとき、下層は、RFC3748に対応でないEAP実装を収容するために完全なEAP認証への落下を強制するかもしれません。
7. Transport of ERP Messages
7. ERPメッセージの輸送
AAA Transport of ERP messages is specified in [11] and [12].
ERPメッセージのAAA Transportは[11]と[12]で指定されます。
Narayanan & Dondeti Standards Track [Page 32] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[32ページ]。
8. Security Considerations
8. セキュリティ問題
This section provides an analysis of the protocol in accordance with the AAA key management requirements specified in [18].
[18]で指定されたAAAかぎ管理要件に応じて、このセクションはプロトコルの分析を提供します。
Cryptographic algorithm independence
暗号アルゴリズム独立
The EAP Re-auth Protocol satisfies this requirement. The
algorithm chosen by the peer for the MAC generation is
indicated in the EAP-Initiate/Re-auth message. If the chosen
algorithm is unacceptable, the EAP server returns an EAP-
Finish/Re-auth message with Failure indication. Algorithm
agility for the KDF is specified in [3]. Only when the
algorithms used are acceptable, the server proceeds with
derivation of keys and verification of the proof of possession
of relevant keying material by the peer. A full-blown
negotiation of algorithms cannot be provided in a single round
trip protocol. Hence, while the protocol provides algorithm
agility, it does not provide true negotiation.
EAP Re-authプロトコルはこの要件を満たします。 MAC世代のために同輩によって選ばれたアルゴリズムは再EAP-開始/authメッセージで示されます。 選ばれたアルゴリズムが容認できないなら、EAPサーバはFailure指示と共にEAP再終わり/authメッセージを返します。 KDFのためのアルゴリズムの機敏さは[3]で指定されます。 使用されるアルゴリズムが許容できるときだけ、サーバはキーの派生と同輩による関連合わせることの材料の所持の証拠の検証を続けます。 単発旅行プロトコルにアルゴリズムの本交渉を提供できません。 したがって、プロトコルがアルゴリズムの機敏さを提供している間、それは本当の交渉を提供しません。
Strong, fresh session keys
強くて、新鮮なセッションキー
ERP results in the derivation of strong, fresh keys that are
unique for the given session. An rMSK is always derived
on-demand when the peer requires a key with a new
authenticator. The derivation ensures that the compromise of
one rMSK does not result in the compromise of a different rMSK
at any time.
ERPは与えられたセッションのためにユニークな強くて、新鮮なキーの派生をもたらします。 同輩が新しい固有識別文字があるキーを必要とするとき、rMSKはいつも要求次第で引き出されます。 派生は、1rMSKの感染がいつでも異なったrMSKの感染をもたらさないのを確実にします。
Limit key scope
限界キー範囲
The scope of all the keys derived by ERP is well defined. The
rRK and rIK are never shared with any entity and always remain
on the peer and the server. The rMSK is provided only to the
authenticator through which the peer performs the ERP exchange.
No other authenticator is authorized to use that rMSK.
ERPによって引き出されたすべてのキーの範囲はよく定義されます。 rRKとrIKはどんな実体とも決して共有されないで、同輩とサーバにいつも残っています。同輩がERP交換を実行する固有識別文字だけにrMSKを提供します。 他の固有識別文字が全くそのrMSKを使用するのが認可されません。
Replay detection mechanism
再生検出メカニズム
For replay protection of ERP messages, a sequence number
associated with the rIK is used. The sequence number is
maintained by the peer and the server, and initialized to zero
when the rIK is generated. The peer increments the sequence
number by one after it sends an ERP message. The server sets
the expected sequence number to the received sequence number
plus one after verifying the validity of the received message
and responds to the message.
ERPメッセージの反復操作による保護において、rIKに関連している一連番号は使用されています。 rIKが発生しているとき、一連番号は、同輩とサーバによって維持されて、ゼロに初期化されます。 ERPメッセージを送った後に同輩は一連番号を1つ増加します。 サーバは、受信されたメッセージの正当性について確かめた後に、容認された一連番号と1つに予想された一連番号を設定して、メッセージに反応します。
Narayanan & Dondeti Standards Track [Page 33] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[33ページ]。
Authenticate all parties
すべてのパーティーを認証してください。
The EAP Re-auth Protocol provides mutual authentication of the
peer and the server. Both parties need to possess the keying
material that resulted from a previous EAP exchange in order to
successfully derive the required keys. Also, both the EAP
re-authentication Response and the EAP re-authentication
Information messages are integrity protected so that the peer
and the server can verify each other. When the ERP exchange is
executed with a local ER server, the peer and the local server
mutually authenticate each other via that exchange in the same
manner. The peer and the authenticator authenticate each other
in the secure association protocol executed by the lower layer,
just as in the case of a regular EAP exchange.
EAP Re-authプロトコルは同輩とサーバの互いの認証を前提とします。双方は、首尾よく必要なキーを引き出すために前のEAP交換から生じた合わせることの材料を持つ必要があります。 また、EAP再認証ResponseとEAP再認証情報メッセージの両方は同輩とサーバが互いについて確かめることができるように保護された保全です。 ERP交換がローカルのERサーバで実行されるとき、同輩とローカルサーバは同じ方法におけるその交換で互いに互いを認証します。 同輩と固有識別文字は下層によって実行された安全な協会プロトコルで互いを認証します、ちょうど定期的なEAP交換に関するケースのように。
Peer and authenticator authorization
同輩と固有識別文字承認
The peer and authenticator demonstrate possession of the same
key material without disclosing it, as part of the lower-layer
secure association protocol. Channel binding with ERP may be
used to verify consistency of the identities exchanged, when
the identities used in the lower layer differ from that
exchanged within the AAA protocol.
それを明らかにしないで、同輩と固有識別文字は同じ主要な材料の所持を示します、下層の安全な協会プロトコルの一部として。 ERPとのチャンネル結合は、下層に使用されるアイデンティティがAAAプロトコルの中で交換されたそれと異なっているとき交換されたアイデンティティの一貫性について確かめるのに使用されるかもしれません。
Keying material confidentiality
物質的な秘密性を合わせます。
The peer and the server derive the keys independently using
parameters known to each entity. The AAA server sends the DSRK
of a domain to the corresponding local ER server via the AAA
protocol. Likewise, the ER server sends the rMSK to the
authenticator via the AAA protocol.
同輩とサーバは、独自に各実体に知られているパラメタを使用することでキーを引き出します。 AAAサーバはAAAプロトコルで対応するローカルのERサーバにドメインのDSRKを送ります。 同様に、ERサーバはAAAプロトコルでrMSKを固有識別文字に送ります。
Note that compromise of the DSRK results in compromise of all
keys derived from it. Moreover, there is no forward secrecy
within ERP. Thus, compromise of an DSRK retroactively
compromises all ERP keys.
それから得られたすべてのキーの感染におけるDSRK結果のその感染に注意してください。 そのうえ、ERPの中にどんな前進の秘密保持もありません。 したがって、DSRKの感染はすべてのERPキーに遡及して感染します。
It is RECOMMENDED that the AAA protocol be protected using
IPsec or TLS so that the keys are protected in transit. Note,
however, that keys may be exposed to AAA proxies along the way
and compromise of any of those proxies may result in compromise
of keys being transported through them.
AAAプロトコルがIPsecかTLSを使用することで保護されるのが、RECOMMENDEDであるので、キーはトランジットで保護されます。 しかしながら、キーが道に沿ってAAAプロキシに暴露されるかもしれなくて、それらのプロキシのどれかの感染がそれらを通して輸送されるキーの感染をもたらすかもしれないことに注意してください。
The home ER server MUST NOT hand out a given DSRK to a local
domain server more than once, unless it can verify that the
entity receiving the DSRK after the first time is the same as
that received the DSRK originally. If the home ER server
verifies authorization of a local domain server, it MAY hand
ホームERサーバは一度より多くの局所領域サーバに与えられたDSRKを与えてはいけません、それが元々DSRKを受けたので1回目の後にDSRKを受ける実体が同じであることを確かめることができないなら。 ホームERサーバが局所領域サーバの承認について確かめるなら、それは手で確かめます。
Narayanan & Dondeti Standards Track [Page 34] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[34ページ]。
out the DSRK to that domain more than once. In this case, the
home ER server includes the Authorization Indication TLV to
assure the peer that DSRK delivery is secure.
一度より多くのそのドメインへのDSRKから。 この場合、ホームERサーバは、DSRK配送が安全であることを同輩に知らせるためにAuthorization Indication TLVを含んでいます。
Confirm cryptosuite selection
cryptosuite選択を確認してください。
Crypto algorithms for integrity and key derivation in the
context of ERP MAY be the same as that used by the EAP method.
In that case, the EAP method is responsible for confirming the
cryptosuite selection. Furthermore, the cryptosuite is
included in the ERP exchange by the peer and confirmed by the
server. The protocol allows the server to reject the
cryptosuite selected by the peer and provide alternatives.
When a suitable rIK is not available for the peer, the
alternatives may be sent in an unprotected fashion. The peer
is allowed to retry the exchange using one of the allowed
cryptosuites. However, in this case, any en route
modifications to the list sent by the server will go
undetected. If the server does have an rIK available for the
peer, the list will be provided in a protected manner and this
issue does not apply.
暗号アルゴリズム、ERP MAYの文脈における保全と主要な派生において、EAPメソッドで使用されるそれと同じにしてください。 その場合、EAPメソッドはcryptosuite選択を確認するのに原因となります。 その上、cryptosuiteはERP交換で同輩によって入れられていて、サーバによって確認されます。プロトコルで、サーバは、同輩によって選択されたcryptosuiteを拒絶して、代替手段を提供します。 適当なrIKが同輩に利用可能でないときに、保護のないファッションで代替手段を送るかもしれません。 同輩は、許容cryptosuitesの1つを使用することで交換を再試行できます。 しかしながら、この場合、途中で、サーバによって送られたリストへの変更は察知されずにいるでしょう。 サーバに同輩に利用可能なrIKがあると、保護された方法でリストを提供するでしょう、そして、この問題は適用されません。
Uniquely named keys
唯一キーと命名されます。
All keys produced within the ERP context can be referred to
uniquely as specified in this document. Also, the key names do
not reveal any part of the keying material.
本書では指定されるように唯一ERP文脈の中で生産されたすべてのキーは参照できます。 また、主要な名前は、合わせることのどんな部分も物質的であることを明らかにしません。
Prevent the domino effect
ドミノ効果を防いでください。
The compromise of one peer does not result in the compromise of
keying material held by any other peer in the system. Also,
the rMSK is meant for a single authenticator and is not shared
with any other authenticator. Hence, the compromise of one
authenticator does not lead to the compromise of sessions or
keys held by any other authenticator in the system. Hence, the
EAP Re-auth Protocol allows prevention of the domino effect by
appropriately defining key scope.
1人の同輩の感染は材料がシステムのいかなる他の同輩でも握ったかぎの感染をもたらしません。 また、rMSKはただ一つの固有識別文字のために意味されて、いかなる他の固有識別文字とも共有されません。 したがって、1つの固有識別文字の感染はシステムのいかなる他の固有識別文字によっても握られるセッションかかぎの感染につながりません。 したがって、EAP Re-authプロトコルは、適切に主要な範囲を定義することによって、ドミノ効果の防止を許します。
However, if keys are transported using hop-by-hop protection,
compromise of a proxy may result in compromise of key material,
i.e., the DSRK being sent to a local ER server.
しかしながら、キーがホップごとの保護を使用することで輸送されるなら、プロキシの感染は主要な材料(すなわち、ローカルのERサーバに送られるDSRK)の感染をもたらすかもしれません。
Narayanan & Dondeti Standards Track [Page 35] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[35ページ]。
Bind key to its context
文脈に主要なひも
All the keys derived for ERP are bound to the appropriate
context using appropriate key labels. Lifetime of a child key
is less than or equal to that of its parent key as specified in
RFC 4962 [18]. The key usage, lifetime and the parties that
have access to the keys are specified.
ERPのために引き出されたすべてのキーが適切な主要なラベルを使用する適切な関係に縛られます。 子供キーの寿命はRFC4962[18]の指定されるとしての親キーの、よりもの以下です。 キーに近づく手段を持っている主要な用法、生涯、およびパーティーは指定されます。
Confidentiality of identity
アイデンティティの秘密性
Deployments where privacy is a concern may find the use of
rIKname-NAI to route ERP messages serves their privacy
requirements. Note that it is plausible to associate multiple
runs of ERP messages since the rIKname is not changed as part
of the ERP protocol. There was no consensus for that
requirement at the time of development of this specification.
If the rIKname is not used and the Peer-ID is used instead, the
ERP exchange will reveal the Peer-ID over the wire.
展開によって、プライバシーが関心であるところでERPメッセージを発送するrIKname-NAIの使用がそれらのプライバシー要件に役立つのがわかるかもしれません。 rIKnameがERPプロトコルの一部として変えられないので、ERPメッセージの複数の走行を関連づけるのがもっともらしいことに注意してください。 この仕様の開発時点で、その要件に関するコンセンサスが全くありませんでした。 rIKnameが使用されていなくて、Peer-IDが代わりに使用されると、ERP交換はワイヤの上にPeer-IDを明らかにするでしょう。
Authorization restriction
承認制限
All the keys derived are limited in lifetime by that of the
parent key or by server policy. Any domain-specific keys are
further restricted for use only in the domain for which the
keys are derived. All the keys specified in this document are
meant for use in ERP only. Any other restrictions of session
keys may be imposed by the specific lower layer and are out of
scope for this specification.
キーが引き出したすべてが生涯、親キーのものかサーバ方針で制限されます。 どんなドメイン特有のキーもキーが引き出されるドメインだけでの使用のためにさらに制限されます。 本書では指定されたすべてのキーがERPだけにおける使用のために意味されます。 セッションキーのいかなる他の制限も、特定の下層によって課されるかもしれなくて、この仕様のための範囲の外にあります。
A denial-of-service (DoS) attack on the peer may be possible when using the EAP Initiate/Re-auth message. An attacker may send a bogus EAP-Initiate/Re-auth message, which may be carried by the authenticator in a RADIUS-Access-Request to the server; in response, the server may send an EAP-Finish/Re-auth with Failure indication in a RADIUS Access-Reject message. Note that such attacks may be plausible with the EAPoL-Start capability of IEEE 802.11 and other similar facilities in other link layers and where the peer can initiate EAP authentication. An attacker may use such messages to start an EAP method run, which fails and may result in the server sending a RADIUS Access-Reject message, thus resulting in the link- layer connections being terminated.
再EAP Initiate/authメッセージを使用するとき、同輩に対するサービスの否定(DoS)攻撃は可能であるかもしれません。 攻撃者はRADIUSアクセス要求における固有識別文字によってサーバに伝えられるかもしれない再にせのEAP-開始/authメッセージを送るかもしれません。 応答では、サーバはRADIUS Access-廃棄物メッセージにおけるFailure指示と共に再EAP-終わり/authを送るかもしれません。 IEEE802.11と他の同様の施設のEAPoL-スタート能力は他のリンクレイヤ、そして、同輩がEAP認証を開始できるところにある状態でそのような攻撃がもっともらしいかもしれないことに注意してください。 攻撃者は、失敗するEAPメソッド走行を始めるそのようなメッセージを使用して、RADIUS Access-廃棄物メッセージを送るサーバをもたらすかもしれません、その結果、リンク層の接続をもたらして、終えられます。
To prevent such DoS attacks, an ERP failure should not result in deletion of any authorization state established by a full EAP exchange. Alternatively, the lower layers and AAA protocols may define mechanisms to allow two link-layer security associations (SAs) derived from different EAP keying materials for the same peer to exist so that smooth migration from the current link layer SA to the
そのようなDoS攻撃を防ぐために、ERPの故障は完全なEAP交換で設置されたどんな承認状態の削除ももたらすべきではありません。 あるいはまた、下層とAAAプロトコルは、電流からの滑らかな移行がリンクされて、同じ同輩が存在するように材料を合わせる異なったEAPから引き出しているセキュリティ協会(SAs)がSAを層にする2リンクレイヤを許容するためにメカニズムを定義するかもしれません。
Narayanan & Dondeti Standards Track [Page 36] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[36ページ]。
new one is possible during rekey. These mechanisms prevent the link layer connections from being terminated when a re-authentication procedure fails due to the bogus EAP-Initiate/Re-auth message.
新しい1つはrekeyの間、可能です。 これらのメカニズムは、再認証手順が再にせのEAP-開始/authメッセージのため失敗するとリンクレイヤ接続が終えられるのを防ぎます。
When a DSRK is sent from a home ER server to a local domain server or when a rMSK is sent from an ER server to an authenticator, in the absence of end-to-end security between the entity that is sending the key and the entity receiving the key, it is plausible for other entities to get access to keys being sent to an ER server in another domain. This mode of key transport is similar to that of MSK transport in the context of EAP authentication. We further observe that ERP is for access authentication and does not support end-to-end data security. In typical implementations, the traffic is in the clear beyond the access control enforcement point (the authenticator or an entity delegated by the authenticator for access control enforcement). The model works as long as entities in the middle of the network do not use keys intended for other parties to steal service from an access network. If that is not achievable, key delivery must be protected in an end-to-end manner.
ホームERサーバから局所領域サーバにDSRKを送るか、またはキーを送る実体とキーを受ける実体の間の終わりから終わりへのセキュリティがないときERサーバから固有識別文字にrMSKを送るとき、他の実体が別のドメインのERサーバに送られるキーに近づく手段を得るのは、もっともらしいです。 主要な輸送のこの方法はEAP認証の文脈におけるMSK輸送のものと同様です。 私たちは、ERPがアクセス認証のためにあって、終わりから終わりへのデータ機密保護をサポートしないのをさらに観測します。 典型的な実装には、トラフィックがアクセス制御実施ポイント(アクセス制御実施のために固有識別文字によって代表として派遣された固有識別文字か実体)を超えた明確にあります。 ネットワークの中央の実体が相手がアクセスネットワークからサービスを横取りすることを意図するキーを使用しない限り、モデルは働いています。 それが達成可能でないなら、終わりから終わりへの方法で主要な配送を保護しなければなりません。
9. IANA Considerations
9. IANA問題
This document specifies IANA registration of two new 'Packet Codes' from the EAP registry:
このドキュメントはEAP登録から2新しい'パケットCodes'のIANA登録を指定します:
o 5 (Initiate)
o 5 (開始)
o 6 (Finish)
o 6 (終わり)
These values are in accordance with [2].
[2]によると、これらの値があります。
This document also specifies creation of a new table, Message Types, in the EAP registry with the following assigned numbers:
また、このドキュメントはEAP登録で以下の規定番号で新しいテーブル、Message Typesの作成を指定します:
o 0 Reserved
o 予約された0
o 1 (Re-auth-Start, applies to Initiate Code only)
o 1 (authの再始め、Initiate Codeだけに適用する、)
o 2 (Re-auth, applies to Initiate and Finish Codes)
o 2 (再authして、InitiateとFinish Codesに適用します)
o 3-191 IANA managed and assigned based on IETF Consensus [17]
o 3-191 IETF Consensusに基づいて管理されて、割り当てられたIANA[17]
o 192-255 Private use
o 192-255 私用
Next, we specify creation of a new table, EAP Initiate and Finish Attributes, associated with EAP Initiate and Finish messages in the EAP registry with the following assigned numbers.
次に、私たちは新しいテーブル、EAP Initiate、およびFinish Attributesの作成を指定します、EAP登録で以下の規定番号でEAP InitiateとFinishメッセージに関連しています。
Narayanan & Dondeti Standards Track [Page 37] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[37ページ]。
o 0: Reserved
o 0: 予約されます。
o keyName-NAI: This is a TLV payload. The Type is 1.
o keyName-NAI: これはTLVペイロードです。 Typeは1歳です。
o rRK Lifetime: This is a TV payload. The Type is 2.
o rRK生涯: これはテレビのペイロードです。 Typeは2歳です。
o rMSK Lifetime: This is a TV payload. The Type is 3.
o rMSK生涯: これはテレビのペイロードです。 Typeは3歳です。
o Domain name: This is a TLV payload. The Type is 4.
o ドメイン名: これはTLVペイロードです。 Typeは4歳です。
o Cryptosuite list: This is a TLV payload. The Type is 5.
o Cryptosuiteは記載します: これはTLVペイロードです。 Typeは5歳です。
o Authorization Indication: This is a TLV payload. The Type is 6.
o 承認指示: これはTLVペイロードです。 Typeは6歳です。
o 7-127: Used to carry other non-channel-binding-related attributes.
IANA managed and assigned based on IETF Consensus [17].
o 7-127: 以前はよく別に運んだ、非チャンネルの結合、関連、属性。 IETF Consensus[17]に基づいて管理されて、割り当てられたIANA。
o The TLV type range of 128-191 is reserved to carry CB information
in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages.
Below are the current assignments (all of them are TLVs):
o 128-191のTLVタイプ範囲は、再EAP-開始/authと再EAP-終わり/authメッセージのCB情報を運ぶために予約されます。 以下に、現在の課題があります(それらは皆、TLVsです):
* Called-Station-Id: 128
* 呼ばれた駅のイド: 128
* Calling-Station-Id: 129
* 駅のイドと呼びます: 129
* NAS-Identifier: 130
* NAS-識別子: 130
* NAS-IP-Address: 131
* NAS IPアドレス: 131
* NAS-IPv6-Address: 132
* NAS-IPv6-アドレス: 132
133-191: Used to carry other channel-binding-related attributes.
IANA managed and assigned based on IETF Consensus [17].
133-191: 以前はよく別に運んだ、チャンネル、結合関連、属性。 IETF Consensus[17]に基づいて管理されて、割り当てられたIANA。
o 192-255: Reserved for Private use.
o 192-255: 兵士の使用のために、予約されます。
We specify creation of another registry, 'Re-authentication Cryptosuites', with the following assigned numbers:
私たちは以下の規定番号で別の登録の作成、'再認証Cryptosuites'を指定します:
o 0: Reserved
o 0: 予約されます。
o 1: HMAC-SHA256-64
o 1: HMAC-SHA256-64
o 2: HMAC-SHA256-128
o 2: HMAC-SHA256-128
o 3: HMAC-SHA256-256
o 3: HMAC-SHA256-256
o 4-191: IANA managed and assigned based on IETF consensus [17]
o 4-191: IETFコンセンサスに基づいて管理されて、割り当てられたIANA[17]
Narayanan & Dondeti Standards Track [Page 38] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[38ページ]。
o 192-255: Reserved for Private use.
o 192-255: 兵士の使用のために、予約されます。
Further, this document registers a Re-auth usage label from the "USRK Key Labels" name space with a value
さらに、このドキュメントは「USRKの主要なラベル」名前スペースから値にRe-auth用法ラベルを登録します。
EAP Re-authentication Root Key@ietf.org
EAP再認証根の Key@ietf.org
and DSRK-authorized delivery key from the "USRK Key Labels" name space
そして、「USRKの主要なラベル」名前スペースから主要なDSRKによって認可された配送
DSRK Delivery Authorized Key@ietf.org
DSRK配送は Key@ietf.org を認可しました。
in accordance with [3].
[3]によると。
10. Acknowledgments
10. 承認
In writing this document, we benefited from discussing the problem space and the protocol itself with a number of folks including Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of the HOKEY working group. The credit for the idea to use EAP- Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link- layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin Hoeper suggested the use of the windowing technique to handle multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for the suggestion to use hexadecimal encoding for rIKname when sent as part of keyName-NAI field. Thanks to Bernard Aboba for suggestions in clarifying the EAP lock-step operation, and Joe Salowey and Glen Zorn for help in specifying AAA transport of ERP messages. Thanks to Sam Hartman for the DSRK Authorization Indication mechanism.
このドキュメントを書く際に、私たちは問題スペースについて議論して、多くの人々がHOKEYワーキンググループのバーナードAboba、ヤリArkko、サム・ハートマン、ラスHousley、ジョーSalowey、ジェシー・ウォーカー、チャールズClancy、ミカエラ・バンダビーン、Kedar Gaonkar、Parag Agashe、Dinesh Dharmaraju、パシEronen、ダン・ハーキンズ、Yoshiオオバ、Glenゾルン、アランDeKok、Katrin Hoeper、および他の関係者を入れているプロトコル自体の利益を得ました。 考えがEAP authの再開始/始めを使用するクレジットはチャールズClancyに行きます、そして、DoS攻撃を緩和する複数のリンク層のSAs考えがYoshiオオバに行きます。 Katrin Hoeperは、複数の同時のER交換を扱うためにウインドーのテクニックの使用を勧めました。 keyName-NAI分野の一部として送ったら、提案のためのパシEronenにrIKnameのための16進コード化を使用しなさいといってくださってありがとうございます。 提案を助けのためにERPメッセージのAAA輸送を指定する際にEAPの堅苦しい操作、ジョーSalowey、およびGlenゾルンをはっきりさせるのにおいてバーナードAbobaをありがとうございます。 DSRK Authorization Indicationメカニズムをサム・ハートマンをありがとうございます。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[2]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[3] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an Extended
Master Session Key (EMSK)", RFC 5295, August 2008.
[3]Salowey、J.、Dondeti、L.、ナラヤナン、V.、およびM.Nakhjiri、「拡張マスターセッションキー(EMSK)からのルートキーの派生のための仕様」、RFC5295(2008年8月)。
Narayanan & Dondeti Standards Track [Page 39] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[39ページ]。
[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] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[5]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
11.2. Informative References
11.2. 有益な参照
[6] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol
Method for 3rd Generation Authentication and Key Agreement
(EAP-AKA)", RFC 4187, January 2006.
[6] Arkko、J.、およびH.Haverinen、「広げることができる認証は第3世代認証のためのメソッドと主要な協定(EAP-別名)について議定書の中で述べます」、RFC4187、2006年1月。
[7] Lopez, R., Skarmeta, A., Bournelle, J., Laurent-Maknavicus, M.,
and J. Combes, "Improved EAP keying framework for a secure
mobility access service", IWCMC '06, Proceedings of the 2006
International Conference on Wireless Communications and Mobile
Computing, New York, NY, USA, 2006.
[7] ロペス、R.、Skarmeta、A.、Bournelle、J.、ローラン-Maknavicus、M.、およびJ.コンブ、「安全な移動性アクセス・サービスのためにフレームワークを合わせる改良されたEAP」、Wireless CommunicationsとモバイルComputingの上の2006年の国際コンファレンスのProceedings、ニューヨーク(ニューヨーク)米国2006年の'IWCMC'06。
[8] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Work
in Progress, October 2003.
[8] 「半径への移管拡大」というArbaugh、W.、およびB.Abobaは進歩、2003年10月に働いています。
[9] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-Authentication Problem
Statement", RFC 5169, March 2008.
[9] クランシー、T.、Nakhjiri、M.、ナラヤナン、V.、およびL.Dondeti、「引き渡しKey Managementと再認証問題声明」、RFC5169(2008年3月)。
[10] Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Port based
Network Access Control, IEEE Std 802.1X-2004", December 2004.
[10] 米国電気電子技術者学会、「地方とメトロポリタンエリアネットワークのIEEE規格:」 2004年12月に「ポートはNetwork Access Control、IEEE Std 802.1X-2004を基礎づけました」。
[11] Nakhjiri, M. and Y. Ohba, "Derivation, delivery and management
of EAP based keys for handover and re-authentication", Work
in Progress, February 2008.
[11] Nakhjiri、M.、およびY.オオバ、「EAPの派生、配送、および経営者側は引き渡しと再認証のためのキーを基礎づけました」、ProgressのWork、2008年2月。
[12] Gaonkar, K., Dondeti, L., Narayanan, V., and G. Zorn, "RADIUS
Support for EAP Re-authentication Protocol", Work in Progress,
February 2008.
[12] K.、Dondeti、L.、ナラヤナン、V.、およびG.ゾルン、「EAP再認証プロトコルの半径サポート」というGaonkarは進行中(2008年2月)で働いています。
[13] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[13]Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[14] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003.
[14]Aboba、B.とP.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。
[15] Dondeti, L. and H. Tschofenig, "Diameter Support for EAP Re-
authentication Protocol", Work in Progress, November 2007.
Progress、2007年11月の[15]DondetiとL.とH.Tschofenig、「EAP Re認証プロトコルのための直径Support」Work。
Narayanan & Dondeti Standards Track [Page 40] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[40ページ]。
[16] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[16]AbobaとB.とゾルン、G.とD.ミットンと「半径とIPv6"、RFC3162、2001年8月。」
[17] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[17] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
[18] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", BCP 132,
RFC 4962, July 2007.
[18]Housley、R.とB.Aboba、「認証、承認、および会計(AAA)Key Managementのための指導」BCP132、RFC4962(2007年7月)。
Narayanan & Dondeti Standards Track [Page 41] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[41ページ]。
Appendix A. Example ERP Exchange
付録A.例のERP交換
0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start]
0. 固有識別文字-->同輩: [authの再EAP-開始/始め]
1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI,
cryptosuite,Auth-tag*)
1. 同輩-->固有識別文字: EAP再開始/auth(SEQ、keyName-NAI、cryptosuite、Authタグ*)
1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id,
EAP Initiate/Re-auth(SEQ,keyName-NAI,
cryptosuite,Auth-tag*)
1a。 固有識別文字-->authの再サーバ: AAA要求、固有識別文字イド、EAP再開始/auth(SEQ、keyName-NAI、cryptosuite、Authタグ*)
2. ER-Server --> Authenticator: AAA-Response{rMSK,
EAP-Finish/Re-auth(SEQ,keyName-NAI,
cryptosuite,[CB-Info],Auth-tag*)
2. えー、-、サーバ、-->固有識別文字: AAA応答、rMSK、再EAP-終わり/auth(SEQ、keyName-NAI、cryptosuite、[CB-インフォメーション]、Authタグ*)
2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI,
cryptosuite,[CB-Info],Auth-tag*)
2b。 固有識別文字-->同輩: 再EAP-終わり/auth(SEQ、keyName-NAI、cryptosuite、[CB-インフォメーション]、Authタグ*)
* Auth-tag computation is over the entire EAP Initiate/Finish
message; the code values for Initiate and Finish are different and
thus reflection attacks are mitigated.
* 全体のEAP Initiate/終わりのメッセージの上にAuth-タグ計算があります。 InitiateとFinishのためのコード値は異なっています、そして、その結果、反射攻撃は緩和されます。
Authors' Addresses
作者のアドレス
Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr. San Diego, CA 92121 USA
VidyaナラヤナンクアルコムInc.5775モアハウスサンディエゴ博士、カリフォルニア92121米国
Phone: +1 858-845-2483 EMail: vidyan@qualcomm.com
以下に電話をしてください。 +1 858-845-2483 メールしてください: vidyan@qualcomm.com
Lakshminath Dondeti Qualcomm, Inc. 5775 Morehouse Dr. San Diego, CA 92121 USA
Lakshminath DondetiクアルコムInc.5775モアハウスサンディエゴ博士、カリフォルニア92121米国
Phone: +1 858-845-1267 EMail: ldondeti@qualcomm.com
以下に電話をしてください。 +1 858-845-1267 メールしてください: ldondeti@qualcomm.com
Narayanan & Dondeti Standards Track [Page 42] RFC 5296 ERP August 2008
ナラヤナンとDondeti規格はERP2008年8月にRFC5296を追跡します[42ページ]。
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に情報を扱ってください。
Narayanan & Dondeti Standards Track [Page 43]
ナラヤナンとDondeti標準化過程[43ページ]
一覧
スポンサーリンク
