[要約] RFC 6696は、EAP再認証プロトコル（ERP）のためのEAP拡張機能に関する規格です。このRFCの目的は、EAP再認証プロトコルの機能を拡張し、セキュリティと効率性を向上させることです。
Internet Engineering Task Force (IETF) Z. Cao
Request for Comments: 6696 China Mobile
Obsoletes: 5296 B. He
Category: Standards Track CATR
ISSN: 2070-1721 Y. Shi
Q. Wu, Ed.
Huawei
G. Zorn, Ed.
Network Zen
July 2012
EAP Extensions for the EAP Re-authentication Protocol (ERP)
EAP再認証プロトコル（ERP）のEAP拡張機能
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 avoid repeating 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再認証サーバー間の効率的な再認証を行います。再認証サーバーは、ピアが接続しているホームネットワークまたはローカルネットワークにある場合があります。
This memo obsoletes RFC 5296.
このメモはRFC 5296を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6696.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6696で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Changes from RFC 5296 ......................................5
2. Terminology .....................................................5
3. ERP Description .................................................7
3.1. ERP with the Home ER Server ...............................10
3.2. ERP with a Local ER Server ................................11
4. ER Key Hierarchy ...............................................13
4.1. rRK Derivation ............................................13
4.2. rRK Properties ............................................14
4.3. rIK Derivation ............................................14
4.4. rIK Properties ............................................15
4.5. rIK Usage .................................................16
4.6. rMSK Derivation ...........................................16
4.7. rMSK Properties ...........................................17
5. Protocol Details ...............................................17
5.1. ERP Bootstrapping .........................................17
5.2. Steps in ERP ..............................................20
5.2.1. Multiple Simultaneous Runs of ERP ..................23
5.2.2. ERP Failure Handling ...............................23
5.3. EAP Codes .................................................25
5.3.1. EAP-Initiate/Re-auth-Start Packet ..................26
5.3.1.1. Authenticator Operation ...................27
5.3.1.2. Peer Operation ............................27
5.3.2. EAP-Initiate/Re-auth Packet ........................28
5.3.3. EAP-Finish/Re-auth Packet ..........................30
5.3.4. TV and TLV Attributes ..............................32
5.4. Replay Protection .........................................33
5.5. Channel Binding ...........................................34
6. Lower-Layer Considerations .....................................35
7. AAA Transport of ERP Messages ..................................36
8. Security Considerations ........................................36
9. IANA Considerations ............................................41
10. Contributors ..................................................41
11. Acknowledgments ...............................................42
12. References ....................................................42
12.1. Normative References .....................................42
12.2. Informative References ...................................42
Appendix A. RFC 5296 Acknowledgments ..............................45
Appendix B. Sample ERP Exchange ...................................46
The Extensible Authentication Protocol (EAP) is 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）は、複数の認証方法をサポートする認証フレームワークです。主な目的はネットワークアクセス認証であり、キー生成方法は、下位層がアクセス制御を実施したい場合に使用されます。 EAPキーイング階層は、すべてのキー生成EAPメソッドによって派生する2つのキーを定義します。マスターセッションキー（MSK）と拡張MSK（EMSK）です。最も一般的な展開シナリオでは、EAPピアとEAPサーバーは、EAPオーセンティケーターと呼ばれるサードパーティを介して相互に認証します。 EAPオーセンティケーターまたはEAPオーセンティケーターによって制御されるエンティティーがアクセス制御を実施します。認証が成功すると、EAPサーバーはMSKをEAP認証システムに転送します。 EAPオーセンティケーターとEAPピアは、MSKを認証キー、キー派生キー、またはキートランスポートキーとして使用して一時セッションキー（TSK）を確立し、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 increased handover times. Some EAP methods specify the use of state from the initial authentication to optimize re-authentications by reducing the computational overhead (e.g., EAP Authentication and Key Agreement (EAP-AKA) [RFC4187]), but method-specific re-authentication takes at least 2 round trips with the original EAP server in most cases. It is also important to note that several methods do not offer support for re-authentication.
ピアがあるオーセンティケータから別のオーセンティケータに移動する場合、完全なEAP認証を回避して高速なハンドオーバをサポートすることが望まれます。 EAPメソッドの別の実行との完全なEAP交換は、ラウンドトリップに数回かかり、完了までにかなりの時間を要し、ハンドオーバー時間が増加する可能性があります。一部のEAPメソッドは、初期オーバーヘッド認証からの状態の使用を指定して、計算オーバーヘッドを削減することで再認証を最適化します（たとえば、EAP認証とキー合意（EAP-AKA）[RFC4187]）。ただし、メソッド固有の再認証には少なくともほとんどの場合、元のEAPサーバーとの往復が2回。また、いくつかの方法は再認証のサポートを提供しないことに注意することも重要です。
Key sharing across authenticators is sometimes used as a practical solution to lower handover times. In that case, however, the compromise of one authenticator results in the compromise of key material established via other authenticators. Other solutions for fast re-authentication exist in the literature: for example, see Lopez, et al. [MSKHierarchy]; Clancy, et al. have described the EAP re-authentication problem statement in detail [RFC5169].
オーセンティケーター間での鍵共有は、ハンドオーバー時間を短縮するための実用的なソリューションとして使用されることがあります。ただし、その場合、1つの認証システムが侵害されると、他の認証システムを介して確立されたキーマテリアルが侵害されます。高速再認証のための他のソリューションが文献に存在します。たとえば、Lopezなどを参照してください。 [MSKHierarchy];クランシー等。 EAP再認証の問題ステートメントを詳細に説明しています[RFC5169]。
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.
結論として、低レイテンシのハンドオーバーを実現するには、2回未満のラウンドトリップで、できればローカルサーバーで完了する、メソッドに依存しない再認証プロトコルが必要です。
This document specifies EAP Re-authentication Extensions (ERXs) for efficient re-authentication using EAP. The protocol that uses these extensions is itself 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 Reauthentication Extensions（ERX）を指定します。これらの拡張を使用するプロトコル自体は、EAP再認証プロトコル（ERP）と呼ばれます。これは、以前に実行されたEAP認証からの有効な、有効期限が切れていないキーマテリアルを持つピアのEAPメソッドに依存しない再認証をサポートします。 EAP再認証に必要なプロトコルとキー階層については、このドキュメントで説明しています。
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 Internet Key Exchange (IKE) protocol [RFC5996] must be updated to carry ERP messages; work is in progress on this project [IKE-EXT-for-ERP].
ERPをサポートするには、4より大きいコード値を持つEAPメッセージを伝送し、ピアが開始するERPの性質に対応できるように、下位層の仕様を修正する必要がある場合があります。具体的には、Internet Key Exchange（IKE）プロトコル[RFC5996]を更新して、ERPメッセージを伝送する必要があります。このプロジェクト[IKE-EXT-for-ERP]の作業が進行中です。
This document obsoletes RFC 5296 but is fully backward compatible with that document. The changes introduced in this document focus on fixing issues that have surfaced since the publication of the original ERP specification [RFC5296]. An overview of some of the major changes is given below.
このドキュメントはRFC 5296を廃止しますが、そのドキュメントと完全に下位互換性があります。このドキュメントで紹介されている変更は、元のERP仕様[RFC5296]の公開以降に表面化した問題の修正に重点を置いています。主な変更点の概要を以下に示します。
o Co-location of the home EAP Re-authentication (ER) and EAP servers is no longer required (see the "ER Server" entry in Section 2).
o ホームEAP再認証（ER）サーバーとEAPサーバーを同じ場所に配置する必要がなくなりました（セクション2の「ERサーバー」エントリを参照）。
o The behavior of the authenticator and local ER server during the bootstrapping process has been clarified (Section 5.1); in particular, the authenticator and/or local ER server is now required to check for current possession of the root keys.
o ブートストラッププロセス中の認証システムとローカルERサーバーの動作が明確になりました（セクション5.1）。特に、オーセンティケーターやローカルERサーバーは、ルートキーの現在の所持を確認する必要があります。
o The authenticator is now recommended, rather than just allowed, to initiate the ERP conversation by means of the EAP-Initiate/ Re-auth-Start message (Section 5.3.1.1).
o オーセンティケーターは、許可されるだけでなく、EAP-Initiate / Re-auth-Startメッセージ（セクション5.3.1.1）を使用してERP会話を開始することが推奨されるようになりました。
In addition, many editorial changes have been made to improve the clarity of the document and to eliminate perceived ambiguities. A comprehensive list of changes is not given here for practical reasons.
さらに、ドキュメントの明確さを改善し、認識されたあいまいさを排除するために、多くの編集上の変更が行われました。変更の包括的なリストは、実際的な理由のため、ここには記載されていません。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses the basic EAP terminology [RFC3748] and EMSK keying hierarchy terminology [RFC5295]. In addition, this document uses the following terms:
このドキュメントでは、基本的なEAP用語[RFC3748]とEMSKキーイング階層用語[RFC5295]を使用しています。さらに、このドキュメントでは次の用語を使用しています。
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ピア-EAP再認証プロトコルをサポートする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; it may not necessarily be co-located with, or physically part of, a full EAP server.
ERサーバー-ここで説明するERPのサーバー部分を実行するエンティティ。このエンティティは、EAPサーバーである場合とそうでない場合があります。このドキュメントでの「サーバー」への言及はすべて、特に明記されていない限り、ERサーバーを意味します。 ERサーバーは論理エンティティです。必ずしも完全なEAPサーバーと同じ場所に配置されたり、完全にEAPサーバーの物理的に配置されているとは限りません。
ERX - EAP re-authentication extensions.
ERX-EAP再認証拡張。
ERP - EAP Re-authentication Protocol. Uses the re-authentication extensions.
ERP-EAP再認証プロトコル。再認証拡張機能を使用します。
rRK - re-authentication Root Key, derived from the EMSK or the Domain-Specific Root Key (DSRK).
rRK-EMSKまたはドメイン固有のルートキー（DSRK）から派生した再認証ルートキー。
rIK - re-authentication Integrity Key, derived from the rRK.
rIK-rRKから派生した再認証整合性キー。
rMSK - re-authentication MSK. This is a per-authenticator key, derived from the rRK.
rMSK-再認証MSK。これは、認証者ごとのキーであり、rRKから派生します。
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 [RFC5295]; 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 Network Access Identifier (NAI).
keyName-NAI-ERPメッセージは、rIKまたはDS-rIKで整合性が保護されています。 ERPメッセージの整合性保護のためのrIKまたはDS-rIKの使用は、EMSKname [RFC5295]で示されています。 ERPであるプロトコル。 ERサーバーのドメイン名を示すレルム。 EMSKnameは、ネットワークアクセス識別子（NAI）のユーザー名部分にコピーされます。
Domain - Refers to a "key management domain" as defined in Salowey, et al. [RFC5295]. 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.
ドメイン-Saloweyなどで定義されている「鍵管理ドメイン」を指します。 [RFC5295]。簡単にするために、このドキュメントでは「ドメイン」と呼びます。 「ホームドメイン」および「ローカルドメイン」という用語は、ピアとの完全なEAP交換を実行する元のキー管理ドメインと、ピアが所定の時間に接続されるローカルドメインとを区別するために使用されます。
ERP allows a peer and server to mutually verify proof of possession of key 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 as described in Aboba, et al. [RFC3748]. 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 (i.e., the local domain).
ERPにより、ピアとサーバーは、以前に実行されたEAPメソッドからのキーマテリアルの所有証明を相互に検証し、ピアと認証システム間のセキュリティアソシエーションを確立できます。オーセンティケーターは、Aboba et al。に記載されているEAPオーセンティケーターと同様の方法で、再認証プロトコルのパススルーエンティティとして機能します。 [RFC3748]。 ERPは、ピアとサーバー間の単一の往復交換です。これは、下位層と、完全なEAP交換中に使用されるEAP方式には依存しません。 ERサーバーは、ホームドメイン内、またはピアとオーセンティケーターと同じ（アクセス済み）ドメイン内（つまり、ローカルドメイン内）にある場合があります。
Figure 1 shows the protocol exchange. The first time the peer attaches to any network, it performs a full EAP exchange (shown in Figure 2) 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 an rRK. More precisely, an rRK is derived from the EMSK or from a DSRK, which is itself 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, an 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.
図1は、プロトコル交換を示しています。ピアが初めてネットワークに接続するとき、ピアはEAPサーバーと完全なEAP交換（図2に示す）を実行します。その結果、MSKがEAP認証システムに配布されます。次に、MSKはオーセンティケータとピアによって使用され、必要に応じてTSKを確立します。最初のEAP交換時に、ピアとサーバーはEMSKも導出します。EMSKは、rRKの導出に使用されます。より正確には、rRKはEMSKから、またはそれ自体がEMSKから派生したDSRKから派生します。 rRKは、ピアとERサーバーでのみ使用でき、他のエンティティには渡されません。さらに、rIKはrRKから派生します。ピアとERサーバーはrIKを使用して、ERP交換の実行中に所持証明を提供します。 rIKもエンティティに渡されることはなく、ピアとサーバーでのみ使用できます。
Peer ER Authenticator ER Server
==== ================ =========
<-- EAP-Initiate/ -----
Re-auth-Start
[<-- EAP-Request/ ------
Identity]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
Note: [] brackets indicate optionality.
注：[]括弧はオプションであることを示します。
Figure 1: ERP Exchange
図1：ERP交換
EAP Peer EAP Authenticator EAP Server
======== ================= ==========
<--- EAP-Request/ ------
Identity
----- EAP Response/ --->
Identity ---AAA(EAP Response/Identity)-->
<--- EAP Method -------> <------ AAA(EAP Method -------->
exchange exchange)
<----AAA(MSK, EAP-Success)------
<---EAP-Success---------
Figure 2: EAP Authentication
図2：EAP認証
Two 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 1; the exchange itself may happen when the peer attaches to a new authenticator supporting EAP re-authentication, or prior to 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. The EAP-Finish message also can be used by the authenticator to announce the local domain name.
このドキュメントでは、EAP再認証の目的で、EAP-InitiateとEAP-Finishの2つのEAPコードを指定しています。ピアがEAP再認証をサポートするターゲット認証システムを識別すると、図1に示すように、ERP交換を実行します。ピアがEAP再認証をサポートする新しいオーセンティケーターに接続するとき、または接続する前に、交換自体が発生する可能性があります。ピアはそれ自体でERPを開始します。また、新しいオーセンティケーターからのEAP-Initiate / Re-auth-Startメッセージに応答して、そうする場合もあります。 EAP-Initiate / Re-auth-Startメッセージにより、オーセンティケーターはERP交換をトリガーできます。オーセンティケータは、EAP-Finishメッセージを使用して、ローカルドメイン名を通知することもできます。
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 MAY send the EAP-Request/Identity message. Note that this avoids having two EAP messages in flight at the same time [RFC3748]. The authenticator may send the EAP-Initiate/Re-auth-Start message and wait for a short, locally configured amount of time. 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 number of 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認証を実行したかどうかを認識していない可能性があります。オーセンティケーターはEAP-Initiate / Re-auth-Startメッセージを送信することでERP交換を開始してもよいし（MAY）、応答がない場合はEAP-Request / Identityメッセージを送信してもよい（MAY）。これにより、2つのEAPメッセージが同時に送信されるのを回避できることに注意してください[RFC3748]。オーセンティケータはEAP-Initiate / Re-auth-Startメッセージを送信し、ローカルで設定された短い時間待機します。このメッセージは、オーセンティケーターがERPをサポートしていることをピアに示します。オーセンティケーターからのこのトリガーに応答して、ピアはEAP-Initiate / Re-authメッセージを送信してERP交換を開始できます。必要な数の再送信（セクション6を参照）の後でピアからの応答がない場合、オーセンティケーターはEAP-Requestメッセージ（通常はEAP-Request / Identityメッセージ）を送信してEAPを開始する必要があります。オーセンティケータは、EAP-Request / Identityメッセージを送信した後で、EAP-Initiate / Re-authメッセージを受信する場合があることに注意してください。オーセンティケーターがERPをサポートしている場合は、ERP交換を続行する必要があります。 EAP-Request / Identityがタイムアウトした場合、認証者は、ERP交換が進行中の場合、または再認証MSKの確立に既に成功している場合、接続を閉じてはなりません（MUST NOT）。
If the authenticator does not support ERP, it will silently discard EAP-Initiate/Re-auth messages (Section 5.3.2), since the EAP code of those packets is greater than 4 ([RFC3748], Section 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 point onward, 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 [IEEE_802.1X].
オーセンティケーターがERPをサポートしていない場合、これらのパケットのEAPコードは4より大きいため（[RFC3748]、セクション4）、EAP-Initiate / Re-authメッセージ（セクション5.3.2）を警告なしに破棄します。 ERP対応のピアは、EAP-Initiate / Re-authメッセージの再送信を使い果たし、認証者からのEAP-Request / Identityメッセージに応答することで、EAP認証にフォールバックします。ピアがERPをサポートしていない場合、または以前のEAP認証からの有効期限が切れていないキーマテリアルがない場合、ピアはEAP-Initiate / Re-auth-Startメッセージをドロップします。 EAP-Initiate / Re-auth-Startメッセージへの応答がない場合、オーセンティケータはEAP-Requestメッセージ（通常はEAP-Request / Identity）を送信してEAP認証を開始する必要があります（SHALL）。この時点以降、RFC 3748ルールが適用されます。これにより、EAPの開始に遅延が生じる場合があることに注意してください。一部の下位層では、EAPoL-Start [IEEE_802.1X]などのメッセージを送信することにより、ピアが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 field to send 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 an rMSK from the rRK using the sequence number as an input to the key derivation. The server then updates the expected sequence number to the received sequence number plus one.
ピアはEAP-Initiate / Re-authメッセージを送信します。これには、ERサーバーのドメインとメッセージの保護に使用されるrIK、およびリプレイ保護のシーケンス番号を識別するためのkeyName-NAIが含まれています。 EAP-Initiate / Re-authメッセージは、整合性がrIKで保護されています。オーセンティケーターは、keyName-NAIフィールドのレルムを使用して、適切なERサーバーにメッセージを送信します。サーバーは、keyNameを使用してrIKを検索します。サーバーは、rIKの所有の証明とメッセージの鮮度を確認した後、シーケンス番号をキー導出への入力として使用して、rRKから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. Hoeper, et al. [RFC5749] discuss 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-Initiate / Re-authメッセージに応答して、サーバーはEAP-Finish / Re-authメッセージを送信します。このメッセージは、rIKで完全性が保護されています。サーバーは、このメッセージと共にrMSKをオーセンティケーターに転送します。 rMSKは、MSKと同様の方法で、完全なEAP交換でEAP-Successメッセージとともに転送されます。 Hoeper、et al。 [RFC5749]は、rRKをEAPサーバーから、EAPサーバーと信頼関係を共有する多くの異なるERサーバーの1つに転送するために使用できる追加のキー配布プロトコルについて説明します。
The peer MAY request the rMSK lifetime from the server. If so, the ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message.
ピアは、サーバーにrMSKの有効期間を要求する場合があります。その場合、ERサーバーはEAP-Finish / Re-authメッセージでrMSKライフタイムを送信します。
In an ERP bootstrap exchange, the peer MAY ask 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-Finish / Re-authメッセージでrRKライフタイムを送信します。
The peer verifies the sequence number 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.
ピアは、シーケンス番号とメッセージの整合性を確認します。次に、EAP-Finish / Re-authメッセージのシーケンス番号を使用して、rMSKを計算します。この時点で、下位層のセキュリティアソシエーションプロトコルをトリガーする準備が整います。
The ER server is located either in the home domain or in the visited domain. When the ER server is in the home domain and there is no local ER server in the visited domain, the peer and the server use the rIK and rRK derived from the EMSK; and when the ER server is in the local 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サーバーは、ホームドメインまたは訪問先ドメインのいずれかにあります。 ERサーバーがホームドメインにあり、訪問したドメインにローカルERサーバーがない場合、ピアとサーバーはEMSKから派生したrIKとrRKを使用します。 ERサーバーがローカルドメインにある場合は、ローカルドメインに対応するDS-rIKおよびDS-rRKを使用します。 ERサーバーのドメインは、ERPメッセージのkeyName-NAIの領域部分によって識別されます。
If the peer is in the home domain or there is no local server in the same domain as the peer, it SHOULD initiate an ERP bootstrap exchange with the home ER server to obtain the domain name.
ピアがホームドメインにある場合、またはピアと同じドメインにローカルサーバーがない場合は、ホームERサーバーとのERPブートストラップ交換を開始して、ドメイン名を取得する必要があります（SHOULD）。
The defined ER extensions allow executing ERP with an ER server in the home domain. The home ER server may be co-located with a home Authentication, Authorization, and Accounting (AAA) server. ERP with the home ER server is similar to the ERP exchange described in Figure 1.
定義されたER拡張機能により、ホームドメインのERサーバーでERPを実行できます。ホームERサーバーは、ホームの認証、承認、およびアカウンティング（AAA）サーバーと同じ場所に配置できます。ホームERサーバーを使用したERPは、図1で説明したERP交換に似ています。
Peer ER Authenticator Home ER Server
==== ================ ==============
<-- EAP-Initiate/ -----
Re-auth-Start
[<-- EAP-Request/ ------
Identity]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
Bootstrap Bootstrap)
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
Bootstrap Bootstrap)
Figure 3: ER Explicit Bootstrapping Exchange/ERP with the Home ER Server
図3：ホームERサーバーを使用したERの明示的なブートストラップExchange / ERP
The defined ER extensions allow the execution of ERP with an ER server in the local domain (access network) if the peer moves out of the home domain and a local ER server is present in the visited domain. 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 a lower-layer advertisement or by means of an ERP exchange. 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 4 shows the ER implicit bootstrapping exchange through a local ER server; Figure 5 shows ERP with a local ER server.
定義されたER拡張により、ピアがホームドメインの外に移動し、ローカルERサーバーが訪問先ドメインに存在する場合、ローカルドメイン（アクセスネットワーク）のERサーバーでERPを実行できます。ローカルERサーバーは、ローカルAAAサーバーと同じ場所に配置できます。ピアは、ネットワーク内のローカルERサーバーの存在とローカルドメイン名（またはERサーバー名）について、下位層のアドバタイズメントまたはERP交換によって学習できます。ピアはドメイン名とEMSKを使用してDSRKを計算し、そのキーからDS-rRKを計算します。ピアは、ローカルドメインでERPを使用するために、keyName-NAIのレルム部分のドメイン名も使用します。図4は、ローカルERサーバーを介したERの暗黙のブートストラップ交換を示しています。図5は、ローカルERサーバーを使用したERPを示しています。
EAP Authenticator Local AAA Agent
Peer /ER Authenticator /Local ER Server Home EAP Server
==== ================== ================ ===============
<-- EAP-Request/ -- Identity
<-EAP-Request /-アイデンティティ
-- EAP Response/-->
Identity --AAA(EAP Response/-->
Identity, --AAA(EAP Response/ -->
[domain name]) Identity,
[DSRK Request,
domain name])
<------------------------ EAP Method exchange------------------>
<---AAA(MSK, DSRK, ----
EMSKname,
EAP-Success)
<--- AAA(MSK, -----
EAP-Success)
<---EAP-Success-----
Figure 4: Implicit Bootstrapping ERP Exchange, Initial EAP Exchange
図4：暗黙的なブートストラップERP交換、初期EAP交換
Peer ER Authenticator Local ER Server
==== ================ ===============
<-- EAP-Initiate/ --------
Re-auth-Start
[<-- EAP-Request/ ---------
Identity]
---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ -------->
Re-auth Re-auth)
<--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
Re-auth Re-auth)
Figure 5: Local ERP Exchange
図5：ローカルERP交換
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 EAP authenticator and the home EAP server of the peer). In that case, the local ER server requests the DSRK by sending the domain name to the home EAP server by means of a AAA message. In response, the home EAP server computes the DSRK by following the procedure specified in RFC 5295 and sends the DSRK and the key name, EMSKname, to the ER server in the claimed domain (i.e., the local ER server). The local domain is responsible for announcing that same domain name to the peer via a lower layer (for example, through DHCP-based local domain name discovery [RFC6440] or through the EAP-Initiate/Re-auth-Start message with the local ER server).
図4に示すように、ローカルERサーバーは、完全なEAP交換のパスに存在する可能性があります（たとえば、これは、EAP認証システムとホームEAPサーバーの間のパスにあるAAAプロキシなどのAAAエンティティの1つである可能性があります。ピアの）。その場合、ローカルERサーバーは、AAAメッセージを使用してドメイン名をホームEAPサーバーに送信することによってDSRKを要求します。応答として、ホームEAPサーバーは、RFC 5295で指定された手順に従ってDSRKを計算し、DSRKとキー名EMSKnameを要求されたドメインのERサーバー（つまり、ローカルERサーバー）に送信します。ローカルドメインは、下位層を介して（たとえば、DHCPベースのローカルドメイン名検出[RFC6440]を介して、またはEAP-Initiate / Re-auth-Startメッセージを介してローカルERを介して）同じドメイン名をピアに通知しますサーバ）。
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, and 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に対応するシーケンス番号（ゼロに初期化）を保持しています。
If the peer subsequently 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. ERP with the local ER server is similar to the ERP exchange illustrated in Figure 1.
その後、ピアがローカルドメイン内のオーセンティケーターに接続する場合、ピアはローカルERサーバーとのERP交換を実行して、新しいオーセンティケーターのrMSKを取得します。ローカルERサーバーを使用したERPは、図1に示すERP交換に似ています。
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は、完全なEAP認証の結果であるMSKが提供するのと同じ目的を果たします。 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) [RFC5295] for re-authentication. The USRK designated for re-authentication is the rRK. A DSUSRK designated for re-authentication is the DS-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 for which they are derived, 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.
rRKは、セクション4.1で指定されているように、EMSKまたはDSRKから派生します。 rRKの導出のために、このドキュメントでは、再認証のために、Usage-Specific Root Key（USRK）またはDomain-Specific USRK（DSUSRK）[RFC5295]の導出を指定しています。再認証に指定されたUSRKはrRKです。再認証用に指定されたDSUSRKは、特定のドメインのローカルERサーバーで使用可能なDS-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およびrMSKを導出するために使用されます。次の図は、rRK、rIK、およびrMSKのキー階層を示しています。
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
Figure 6: Re-authentication Key Hierarchy
図6：再認証キーの階層
The derivations in this document are from RFC 5295. Key derivations and field encodings, where unspecified, default to that document.
このドキュメントの派生物はRFC 5295に基づいています。キーの派生物とフィールドエンコーディングは、指定されていない場合、デフォルトでそのドキュメントになります。
The rRK may be derived from the EMSK or DSRK. This section provides the relevant key derivations for that purpose.
rRKは、EMSKまたはDSRKから取得できます。このセクションでは、その目的に関連する主要な派生物を提供します。
The rRK is derived as specified in RFC 5295.
rRKは、RFC 5295で指定されているように導出されます。
rRK = KDF (K, S), where
rRK = KDF（K、S）、ここで
K = EMSK or K = DSRK and
K = AND KまたはK = DARKおよび
S = rRK Label | "\0" | length
S = rRKラベル| 「\ 0」|長さ
The rRK Label is an IANA-assigned 8-bit ASCII string:
rRKラベルは、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 the policy stated in RFC 5295.
RFC 5295に記載されているポリシーに従って、「USRK Key Labels」名前空間から割り当てられます。
The Key Derivation Function (KDF) and algorithm agility for the KDF are as defined in RFC 5295.
鍵導出関数（KDF）とKDFのアルゴリズムの俊敏性は、RFC 5295で定義されています。
An rRK derived from the DSRK is referred to as a DS-rRK in the rest of the document. All of the key derivation and properties specified in this section remain the same.
DARKから派生したrRKは、ドキュメントの残りの部分ではDS-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 the derivation of the 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は、ピアとそれを派生させたサーバー上に存在しなければならず（MUST）、他のエンティティに転送してはなりません（MUST NOT）。
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は期限切れになり、その時点で使用から削除する必要があります。
The rIK is used for integrity protecting the ERP exchange. This serves as the proof of possession of valid key material from a previous full EAP exchange by the peer to the server.
rIKは、ERP交換を保護する完全性のために使用されます。これは、ピアによるサーバーへの以前の完全なEAP交換からの有効なキーマテリアルの所有の証明として機能します。
The rIK is derived as follows:
rIKは次のように導出されます。
rIK = KDF (K, S), where
rIK = KDF（K、S）、ここで
K = rRK and
S = rIK Label | "\0" | cryptosuite | length
S = rIKラベル| 「\ 0」|暗号スイート|長さ
The rIK Label is the 8-bit ASCII string:
rIKラベルは8ビットのASCII文字列です。
Re-authentication Integrity Key@ietf.org
再認証の整合性Key@ietf.org
The length field refers to the length of the rIK in octets and is encoded as specified in RFC 5295.
長さフィールドは、オクテット単位のrIKの長さを参照し、RFC 5295で指定されているようにエンコードされます。
The cryptosuite and length of the rIK are part of the input to the KDF to ensure cryptographic separation of keys if different rIKs of different lengths (for example, 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.
異なる長さの異なるrIK（たとえば、異なるメッセージ認証コード（MAC）アルゴリズムで使用するため）が同じrRKから派生する場合、暗号スイートとrIKの長さはKDFへの入力の一部であり、キーの暗号化分離を保証します。暗号スイートは8ビットの数値としてエンコードされます。暗号スイートの仕様については、セクション5.3.2を参照してください。
The rIK is referred to by the EMSKname-NAI within the context of ERP messages. The username part of the EMSKname-NAI is the EMSKname; the realm is the domain name of the ER server. In the case of ERP with the home ER server, the peer uses the realm from its original NAI; in the 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 of the key derivation and properties specified in this section remain the same.
本書では、DS-rRKから派生したrIKをDS-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の有効期限が切れたときに期限切れにする必要があり、その時点で使用から削除する必要があります。
The rIK is the key the possession of which 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 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.
rIKは、その所有がピアおよびERPサーバーによって相手に示される鍵です。ピアは、EAP-Initiate / Re-authメッセージで整合性チェックサムを計算することにより、rIKの所有を示します。ピアが初めてrIKを使用するとき、rIKで使用する整合性アルゴリズムを選択できます。ピアとサーバーは、そのキーで保護されたすべてのERPメッセージに対して、特定のrIKで同じ整合性アルゴリズムを使用する必要があります。ピアとサーバーは最初の使用後にアルゴリズム情報を保存し、それらはその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.
サーバーのポリシーがピアによって選択された暗号スイートの使用を許可しない場合、サーバーはEAP-Initiate / Re-authメッセージを拒否し（SHALL）、EAP-Finish / Re-authメッセージで受け入れ可能な暗号スイートのリストを送信する必要があります（SHOULD）。
The rIK length may be different from the key length required by an integrity algorithm. In the case of hash-based MAC algorithms, the key is first hashed to the required key length using the HMAC algorithm [RFC2104]. In the 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アルゴリズムの場合、HMACアルゴリズム[RFC2104]を使用して、最初にキーが必要なキーの長さにハッシュされます。暗号ベースのMACアルゴリズムの場合、必要なキーの長さが32オクテット未満の場合、rMACはHMAC-SHA256を使用してハッシュされ、出力の最初のkオクテットが使用されます。ここで、kはアルゴリズムで必要なキーの長さです。 。必要なキーの長さが32オクテットを超える場合、rIKの最初のkオクテットが暗号ベースのMACアルゴリズムによって使用されます。
The rMSK is derived at the peer and server and delivered to the authenticator. The rMSK is derived following an ERP exchange.
rMSKはピアとサーバーで生成され、認証システムに配信されます。 rMSKは、ERP交換後に派生します。
The rMSK is derived as follows:
rMSKは次のように導出されます。
rMSK = KDF (K, S), where
rMSK = KDF（K、S）、ここで
K = rRK and
S = rMSK Label | "\0" | SEQ | length
S = rMSKラベル| 「\ 0」| 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 and is encoded as specified in RFC 5295.
長さフィールドは、オクテット単位のrMSKの長さを参照し、RFC 5295で指定されているようにエンコードされます。
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-Initiate / Re-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. The key derivation and properties specified in this section remain the same.
本書では、DS-rRKから派生したrMSKをDS-rIKと呼びます。このセクションで指定されている主要な派生とプロパティは同じままです。
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 serves when the MSK is used at an authenticator.
o rMSKはオーセンティケータに配信され、MSKがオーセンティケータで使用されるときに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が派生する場合、後続のrMSKは新しいrRKから派生する必要があります。以前に提供されたrMSKは、有効期限が切れるまで引き続き使用される場合があります。
o A given rMSK MUST NOT be shared by multiple authenticators.
o 与えられたrMSKは複数の認証者によって共有されてはいけません。
We identify two types of bootstrapping for ERP: explicit and implicit. In implicit bootstrapping, the ER-capable authenticator or local ER server MUST verify whether it has a valid rMSK or rRK corresponding to the peer. If the ER-capable authenticator or the local ER server has the key material corresponding to the peer, it MUST be able to respond directly in the same way as the home AAA server does without forwarding the DSRK Request to the home domain;
ERPのブートストラップには、明示的と暗黙の2つのタイプがあります。暗黙のブートストラップでは、ER対応の認証システムまたはローカルERサーバーは、ピアに対応する有効なrMSKまたはrRKがあるかどうかを確認する必要があります。 ER対応のオーセンティケーターまたはローカルERサーバーがピアに対応するキーマテリアルを持っている場合、DSRK要求をホームドメインに転送せずに、ホームAAAサーバーと同じ方法で直接応答できなければなりません（MUST）。
if not, the ER-capable authenticator or local ER server SHOULD include its domain name in the AAA message encapsulating the first EAP Response message sent by the peer and request the DSRK from the home EAP server during the initial EAP exchange. If such an EAP exchange is successful, the home EAP server sends the DSRK for the specified local AAA client or agent (derived using the EMSK and the domain name as specified in RFC 5295), EMSKname, and DSRK lifetime along with the EAP-Success message. The local AAA client or agent MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding the EAP-Success message to the peer. Note that the MSK (also present 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 by means of a lower-layer announcement (for example, DHCP [RFC6440]). 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.
そうでない場合、ER対応のオーセンティケータまたはローカルERサーバーは、ピアによって送信された最初のEAP応答メッセージをカプセル化するAAAメッセージにドメイン名を含めて、最初のEAP交換中にホームEAPサーバーからDSRKを要求する必要があります。そのようなEAP交換が成功した場合、ホームEAPサーバーは、指定されたローカルAAAクライアントまたはエージェントのDSRK（EMSKおよびRFC 5295で指定されたドメイン名を使用して導出）、EMSKname、およびDSRKライフタイムをEAP-Successとともに送信しますメッセージ。ローカルAAAクライアントまたはエージェントは、EAP-Successメッセージをピアに転送する前に、DSRK、EMSKname、およびDSRKライフタイム（存在する場合）を抽出する必要があります。 MSK（EAP-Successメッセージにも含まれる）は、通常どおりEAPオーセンティケーターによって抽出されることに注意してください。ピアは、EAP-Initiate / Re-auth-Startメッセージを介して、または下位層の通知（たとえば、DHCP [RFC6440]）によってドメイン名を学習します。完全なEAP認証の最中または後にドメイン名がピアで使用できる場合、新しい認証システムと関連付けるときにERPを使用しようとします。
If the peer knows there is no local ER server present in the visited domain, it SHOULD initiate ERP explicit bootstrapping (ERP exchange with the bootstrap flag turned on) with the home ER server to obtain the rRK. The peer MAY also initiate bootstrapping to fetch information such as the rRK lifetime from the AAA server.
ピアが訪問先ドメインにローカルERサーバーがないことを知っている場合、rRKを取得するためにホームERサーバーでERP明示的ブートストラップ（ブートストラップフラグがオンになっているERP交換）を開始する必要があります（SHOULD）。ピアは、AAAサーバーからrRKの有効期間などの情報を取得するために、ブートストラップを開始してもよい（MAY）。
The following steps describe the ERP explicit bootstrapping process:
次の手順では、ERPの明示的なブートストラッププロセスについて説明します。
o The peer sends the EAP-Initiate/Re-auth message with the bootstrapping flag set (1). The bootstrap message is always sent to the home ER 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-Initiate / Re-authメッセージを送信します（1）。ブートストラップメッセージは常にホームERサーバーに送信され、ブートストラップメッセージの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 さらに、メッセージには、リプレイ保護のためのシーケンス番号、暗号スイート、および整合性チェックサムが含まれている必要があります。暗号スイートは認証アルゴリズムを示します。整合性チェックサムは、メッセージが要求されたエンティティ、Peer-IDで示されるピア、またはrIK名で発信されたことを示します。
o The peer MAY additionally set the lifetime flag to request the key lifetimes.
o ピアはさらに、ライフタイムフラグを設定して、キーのライフタイムを要求できます。
o Upon receipt of the EAP-Initiate/Re-auth message from a peer, the ERP-capable authenticator verifies whether it has the local domain name and valid key material corresponding to the peer. If it knows the local domain name and has valid key material corresponding to the peer, it MUST be able to respond directly in the same way as the home ER does, with the local domain name included. If not, it copies the contents of the keyName-NAI into the appropriate AAA attribute and may include its domain name in the AAA message encapsulating the EAP-Initiate/Re-auth message sent by the peer.
oピアからEAP-Initiate / Re-authメッセージを受信すると、ERP対応の認証システムは、ピアに対応するローカルドメイン名と有効なキーマテリアルがあるかどうかを確認します。ローカルドメイン名がわかっていて、ピアに対応する有効なキーマテリアルがある場合、ローカルドメイン名を含めて、ホームERと同じように直接応答できなければなりません（MUST）。そうでない場合は、keyName-NAIの内容を適切なAAA属性にコピーし、ピアから送信されたEAP-Initiate / Re-authメッセージをカプセル化するAAAメッセージにそのドメイン名を含めることができます。
o Upon receipt of an EAP-Initiate/Re-auth message, the home ER 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 home ER server then verifies that the cryptosuite used by the peer is acceptable. Next, it verifies the integrity of the message by looking up the rIK and checking the integrity checksum contained in the Authentication Tag field. If any of the checks fail, the home ER 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-Initiate / Re-authメッセージを受信すると、ホームERサーバーは、受信したシーケンス番号がそのrIKの予期されるシーケンス番号以上であるかどうかを評価することにより、メッセージが新しいか再生であるかを確認します。次に、ホームERサーバーは、ピアが使用する暗号スイートが受け入れ可能であることを確認します。次に、rIKを検索し、[認証タグ]フィールドに含まれる整合性チェックサムをチェックすることにより、メッセージの整合性を検証します。チェックのいずれかが失敗した場合、ホームERサーバーは、結果フラグが「1」に設定されたEAP-Finish / Re-authメッセージを送信します。障害処理の詳細については、セクション5.2.2を参照してください。このエラーは、以前にEAPオーセンティケーターおよびピアによって受信された可能性があるEAP-Successメッセージとの相関があってはなりません。 EAP-Initiate / Re-authメッセージが正しい形式で有効な場合、サーバーはEAP-Finish / Re-authメッセージを準備します。これがブートストラップ交換であることを示すために、ブートストラップフラグを設定する必要があります。メッセージには次のフィールドが含まれます。
* A sequence number for replay protection.
* リプレイ保護のシーケンス番号。
* The same keyName-NAI as in the EAP-Initiate/Re-auth message.
* EAP-Initiate / Re-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-Initiate / Re-authメッセージで設定されている場合、ERサーバーはEAP-Finish / Re-authメッセージにrRKライフタイムとrMSKライフタイムを含める必要があります。サーバーは、ネットワークがローカルでライフタイムを維持および実施するためのローカルポリシーを持つ場合があります。このような場合、サーバーは、存続期間中、ピアの要求に応答する必要はありません。
* If the bootstrap flag is set, the ER server MUST include the domain name to which the DSRK is being sent along with the EAP-Finish/Re-auth message.
* ブートストラップフラグが設定されている場合、ERサーバーは、DSRKの送信先のドメイン名をEAP-Finish / Re-authメッセージと共に含める必要があります。
* If the ER server verifies the authorization of a local ER 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サーバーがローカルERサーバーの承認を検証する場合、DSRKを受信し、ドメイン名TLVに含まれるドメインをアドバタイズしているサーバーが承認されていることをピアに示すために、承認表示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-Finish / Re-authメッセージがEMSKname-NAIに対応するrIKを所有するサーバーから発信されたことを証明するために、認証タグを含める必要があります。
o If the home ER server is involved in the ERP exchange and the ERP exchange is successful, the home ER server SHOULD request the DSRK from the home EAP server; the home EAP server MUST provide the DSRK for the home ER server (derived using the EMSK and the domain name as specified in RFC 5295), EMSKname, and DSRK lifetime for inclusion in the AAA message. The home ER server SHOULD obtain them before sending the EAP-Finish/Re-auth message.
o ホームERサーバーがERP交換に関与し、ERP交換が成功した場合、ホームERサーバーはホームEAPサーバーからDSRKを要求する必要があります（SHOULD）。ホームEAPサーバーは、ホームERサーバーのDSRK（EMSKおよびRFC 5295で指定されているドメイン名を使用して派生）、EMSKname、およびAAAメッセージに含めるためのDSRKライフタイムを提供する必要があります。ホームERサーバーは、EAP-Finish / Re-authメッセージを送信する前にそれらを取得する必要があります（SHOULD）。
o In addition, the rMSK is sent along with the EAP-Finish/Re-auth message in a AAA attribute (for an example, see Bournelle, et al. [DIAMETER-ERP]).
o さらに、rMSKはEAP-Finish / Re-authメッセージと共にAAA属性で送信されます（例については、Bournelleなど[DIAMETER-ERP]を参照）。
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 name 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-Finish / Re-authメッセージを受信するとき、ローカルドメイン名が存在する場合、その名前を使用して適切なDSRK、DS-rRK、DS-rIK、およびkeyName-NAIを導出する必要があります、およびDS-rIKの再生カウンターを初期化します。そうでない場合、ピアは、下位層を介して、またはEAP-Initiate / Re-auth-Startメッセージから学習したドメイン名を使用して、ドメイン固有のキーを導出する必要があります（SHOULD）。ピアがドメイン名を認識していない場合は、使用可能なローカルERサーバーがないと想定する必要があります。
o The peer MAY also verify the Authorization Indication TLV.
o ピアはまた、Authorization Indication TLVを検証してもよい（MAY）。
o The procedures for encapsulating ERP and obtaining relevant keys using Diameter are specified in Bournelle, et al. [DIAMETER-ERP].
o ERPをカプセル化し、Diameterを使用して関連するキーを取得する手順は、Bournelleなどで指定されています。 [DIAMETER-ERP]。
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に基づいて既にTSKを確立している可能性があります。次に、下位層は、ERブートストラップ交換で受信されたrMSKを無視することを選択できます。あるいは、下位層は、rMSKを使用して新しいTSKを確立することを選択できます。どちらの場合も、オーセンティケーターとピアは、TSK確立交換が開始されたかどうかに基づいて、どのキーが使用されるかを認識します。ブートストラップ交換は、新しい認証システムを介して実行することもできます。その場合、受信したrMSKは、下位層のTSK確立交換をトリガーする必要があります（SHOULD）。
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-Initiate / Re-authおよびEAP-Finish / Re-authメッセージで構成されます。 ERP交換は、ローカルERサーバー（存在する場合）または元の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再認証プロセスをトリガーする可能性があります。 ERP対応オーセンティケーターは、ERPのサポートを示すためにEAP-Initiate / Re-auth-Startメッセージを送信する必要があります（SHOULD）。ピアは、これらのメッセージが到着してEAP-Initiate / Re-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 EAP-Request/Identity messages.
EAP-Initiate / Re-auth-Startメッセージは、ERP対応のオーセンティケーターによって送信されるべきです（SHOULD）。オーセンティケーターは、ピアからの応答としてEAP-Initiate / Re-authメッセージを受信するまで、数回再送信する場合があります。ピアがEAP-Request / IdentityまたはEAP-Initiate / Re-auth-Startメッセージをオーセンティケーターから受信する前に、ピアからのEAP-Initiate / Re-authメッセージが発信されている可能性があります。したがって、EAP-Initiate / Re-authメッセージのIdentifier値は、EAP-Initiate / Re-auth-StartまたはEAP-Request / IdentityメッセージのIdentifier値とは無関係です。
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再認証メッセージを確実に転送するために再送信タイマーを維持する必要があります。 RFC 3748のセクション4.3の信頼性に関する考慮事項は、再送信エンティティとしてのピアに適用されます。
ERP has the following steps:
ERPには以下のステップがあります。
o The ERP-capable authenticator sends the EAP-Initiate/Re-auth-Start message to trigger the ERP exchange.
o ERP対応のオーセンティケーターは、EAP-Initiate / Re-auth-Startメッセージを送信して、ERP交換をトリガーします。
o The peer sends an EAP-Initiate/Re-auth message. At a minimum, the message SHALL include the following fields:
o ピアはEAP-Initiate / Re-authメッセージを送信します。少なくとも、メッセージには次のフィールドを含める必要があります。
* 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.
* keyName-NAIをTLV属性として使用して、メッセージの整合性保護に使用されるrIKを識別します。
* cryptosuite to indicate the authentication algorithm used to compute the integrity checksum.
* 完全性チェックサムの計算に使用される認証アルゴリズムを示す暗号スイート。
* authentication tag computed over the message.
* メッセージに対して計算された認証タグ。
o 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.
oピアがローカルERサーバーでERPを実行している場合、ローカルERサーバーと共有する対応するDS-rIKを使用する必要があります。ピアは、サーバーにキーの有効期間を要求する有効期間フラグを設定する必要があります（SHOULD）。ピアは、rRKライフタイムを使用してEAPメソッド交換をいつトリガーするかを知り、rMSKライフタイムを使用して別のERP交換をいつトリガーするかを知ることができます。
o The authenticator copies the contents of the value field of the keyName-NAI TLV into an appropriate attribute (e.g., User-Name [RFC2865]) in the AAA message to the ER server.
o オーセンティケーターは、keyName-NAI TLVの値フィールドの内容を、ERサーバーへのAAAメッセージの適切な属性（例えば、User-Name [RFC2865]）にコピーします。
o The ER 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 ER 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 ER server MUST then verify that the cryptosuite used by the peer is acceptable. The ER 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 ER 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.
o ERサーバーは、keyName-NAIを使用してrIKを検索します。それは最初にシーケンス番号が期待されたシーケンス番号以上であるかどうかを検証しなければなりません。 ERサーバーが1より大きいシーケンス番号ウィンドウサイズをサポートする場合、シーケンス番号がウィンドウ内にあり、以前に受信されていないかどうかを確認する必要があります。次に、ERサーバーは、ピアが使用する暗号スイートが受け入れ可能であることを確認する必要があります。次に、ERサーバーはrIKを使用してメッセージの整合性を検証し、ピアがそのキーを所有していることの証明を検証します。これらの検証のいずれかが失敗した場合、ERサーバーは、結果フラグを「1」（失敗）に設定してEAP-Finish / Re-authメッセージを送信する必要があります。障害処理の詳細については、セクション5.2.2を参照してください。それ以外の場合は、シーケンス番号を鍵導出への追加入力として使用して、rRKからrMSKを計算する必要があります。
o In response to a well-formed EAP-Initiate/Re-auth message, the ER server MUST send an EAP-Finish/Re-auth message with the following contents:
o 整形式のEAP-Initiate / Re-authメッセージに応答して、ERサーバーは次の内容のEAP-Finish / Re-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 ER server supports multiple simultaneous ERP exchanges, it MUST instead update the sequence number window.
* リプレイ保護のための16ビットのシーケンス番号。これは、受信したシーケンス番号と同じでなければなりません。シーケンス番号のローカルコピーは1ずつ増加する必要があります。ERサーバーが複数の同時ERP交換をサポートしている場合は、代わりにシーケンス番号ウィンドウを更新する必要があります。
* keyName-NAI as a TLV attribute to identify the rIK used to integrity protect the message.
* keyName-NAIをTLV属性として使用して、メッセージの整合性保護に使用されるrIKを識別します。
* cryptosuite to indicate the authentication algorithm used to compute the integrity checksum.
* 完全性チェックサムの計算に使用される認証アルゴリズムを示す暗号スイート。
* authentication tag computed 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-Initiate / Re-authメッセージで設定されている場合、ERサーバーはrRKライフタイムとrMSKライフタイムを含める必要があります。
o The ER server causes the rMSK along with this message to be transported to the authenticator. The rMSK is transported in a manner similar to the MSK and the EAP-Success message in a regular EAP exchange.
o ERサーバーは、このメッセージと共にrMSKをオーセンティケーターに転送します。 rMSKは、MSKおよびEAP-Successメッセージと同様の方法で、通常のEAP交換で転送されます。
o 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.
o ピアはシーケンス番号を検索して、keyName-NAIで保護されたシーケンス番号を持つEAP-Finish / Re-authメッセージを予期しているかどうかを確認します。次に、メッセージの整合性を検証します。検証が失敗した場合、ピアはエラーを記録してプロセスを停止します。それ以外の場合は、次のステップに進みます。
o The peer uses the sequence number to compute the rMSK.
o ピアはシーケンス番号を使用してrMSKを計算します。
o The lower-layer security association protocol can be triggered at this point.
o この時点で、下位層のセキュリティアソシエーションプロトコルをトリガーできます。
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メッセージが順不同で到着し、ERサーバーが正当なEAP-Initiate / Re-authメッセージを拒否する可能性があります。
To facilitate such operation, an ER server MAY allow multiple simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth messages with sequence number values within a window of allowed values. Recall that the sequence number allows replay protection. Replay window maintenance mechanisms are a local matter.
そのような操作を容易にするために、ERサーバーは、許可された値のウィンドウ内でシーケンス番号の値を持つすべてのEAP-Initiate / Re-authメッセージを受け入れることにより、複数の同時ERP交換を許可してもよい（MAY）。シーケンス番号はリプレイ保護を可能にすることを思い出してください。再生ウィンドウのメンテナンスメカニズムはローカルな問題です。
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 field of that message. 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-Initiate / Re-authメッセージの処理が失敗した場合、ERサーバーは、結果フラグを「1」に設定してEAP-Finish / Re-authメッセージを送信する必要があります。サーバーがピアに対して有効なrIKを持っている場合、サーバーはEAP-Finish / Re-auth失敗メッセージを完全に保護する必要があります。失敗の原因が許容できない暗号スイートである場合、サーバーは、EAP-Finish / Re-authメッセージと共に、（タイプ5のTLVの）許容暗号スイートのリストを送信する必要があります（SHOULD）。この場合、サーバーは、EAP-Finish / Re-authメッセージを保護するために使用される暗号スイートを、そのメッセージのCryptosuiteフィールドに示す必要があります。この場合、EAP-Finish / Re-authメッセージで使用されるrIKは、新しい暗号スイートを使用して、セクション4.3で指定されているように計算する必要があります。サーバーにピアの有効なrIKがない場合、失敗を示すEAP-Finish / Re-authメッセージは認証されません。サーバーは、メッセージに受け入れ可能な暗号スイートのリストを含めることができます（MAY）。
The peer, upon receiving an EAP-Finish/Re-auth message with the Result flag set to '1', MUST verify the sequence number and, if possible, 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 Pseudo-Random Function (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.
ピアは、結果フラグが「1」に設定されたEAP-Finish / Re-authメッセージを受信すると、メッセージの有効性を判断するためにシーケンス番号と、可能であれば認証タグを検証する必要があります。ピアが暗号スイートをサポートしている場合、受信したEAP-Finish / Re-authメッセージの整合性を検証する必要があります。 EAP-Finishメッセージにタイプ5のTLVが含まれている場合、ピアは、サーバーに含まれているリストから選択された暗号スイートを使用してERP交換を再試行する必要があります（SHOULD）。ピアは、セクション4.3で指定されているように、対応する暗号スイートで計算することにより、後続のERP交換に適切なrIKを使用する必要があります。選択した暗号スイートの疑似ランダム関数（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 list of acceptable cryptosuites (in a TLV of Type 5), after a failure has been clearly determined following the procedure in the next paragraph.
ピアが受信したメッセージの整合性を検証できない場合、手順に従って障害が明確に判別された後、許容可能な暗号スイートのリスト（タイプ5のTLV）にある暗号スイートのいずれかでERP交換を再試行することを選択できます（MAY）。次の段落で。
If the replay or integrity checks fail, the failure message may have been sent by an attacker. It may also mean 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.
再生または整合性チェックが失敗した場合、攻撃者が失敗メッセージを送信した可能性があります。また、サーバーとピアが同じ暗号スイートをサポートしていないことも意味します。ただし、ピアはそれが事実であるかどうかを判断できません。したがって、ピアは、障害を宣言する前に、再送信タイマーごとにERP交換を継続する必要があります。
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要求とドメイン名を送信できるローカルERサーバーがない可能性があります。その場合、サーバーはDSRKを送信できず、ドメイン名TLVを含めることはできません。ピアは、ドメイン名TLVなしでブートストラップ交換で応答を受信すると、ローカルERサーバーがないと想定します。ただし、ホームERサーバーはrMSKをERオーセンティケーターに送信し、ピアは通常どおりTSK確立プロトコルを実行する必要があります（SHALL）。
Two 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 Aboba, et al. [RFC3748].
ERPの目的で、EAP-InitiateとEAP-Finishの2つのEAPコードが定義されています。これらのメッセージのパケット形式は、Abobaなどで定義されたEAPパケット形式に従います。 [RFC3748]。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: EAP Packet
図7：EAPパケット
Code
コード
Two code values are defined for the purpose of ERP:
ERPの目的で2つのコード値が定義されています。
5 Initiate
5開始する
6 Finish
6仕上げ
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 an EAP-Finish message. Any new (non-retransmission) EAP-Initiate message MUST use a new Identifier field.
識別子フィールドは1オクテットです。 EAP-Finishメッセージの待機中にタイムアウトによりEAP-Initiateパケットが再送信される場合、Identifierフィールドは同じである必要があります。新しい（再送信ではない）EAP-Initiateメッセージは、新しい識別子フィールドを使用する必要があります。
The Identifier field of the EAP-Finish message MUST match that of the currently outstanding EAP-Initiate message. A peer or authenticator receiving an EAP-Finish message whose Identifier value does not match that of the currently outstanding EAP-Initiate message MUST silently discard the packet.
EAP-FinishメッセージのIdentifierフィールドは、現在未解決のEAP-InitiateメッセージのIdentifierフィールドと一致する必要があります。識別子の値が現在未解決のEAP-Initiateメッセージの値と一致しないEAP-Finishメッセージを受信するピアまたはオーセンティケーターは、静かにパケットを破棄する必要があります。
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-Initiateメッセージと再送信の間の混乱を避けるために、ピアは以前のEAP-Initiateメッセージとは異なる識別子値を選択する必要があります（特にその交換が完了していない場合）。オーセンティケーターが300秒後にEAP Re-auth状態をクリアすることをお勧めします。
Type
タイプ
This field indicates that this is an ERP exchange. Two type values are defined in this document for this purpose -- Re-auth-Start (Type 1) and Re-auth (Type 2).
このフィールドは、これがERP交換であることを示します。このドキュメントでは、この目的のために2つのタイプの値、Re-auth-Start（タイプ1）とRe-auth（タイプ2）を定義しています。
Type-Data
タイプデータ
The Type-Data field varies according to the value of the Type field in the re-authentication packet.
Type-Dataフィールドは、再認証パケットのTypeフィールドの値によって異なります。
The EAP-Initiate/Re-auth-Start packet contains the fields shown in Figure 8.
EAP-Initiate / Re-auth-Startパケットには、図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 | Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: EAP-Initiate/Re-auth-Start Packet
図8：EAP-Initiate / Re-auth-Startパケット
Type = 1.
タイプ= 1。
Reserved: MUST be zero. Set to zero on transmission and ignored on reception.
予約済み：ゼロでなければなりません。送信時にはゼロに設定され、受信時には無視されます。
One or more Type/Values (TVs) or TLVs are used to convey information to the peer; for instance, the authenticator may send the domain name to the peer.
1つ以上のタイプ/値（TV）またはTLVを使用して、ピアに情報を伝達します。たとえば、オーセンティケータはドメイン名をピアに送信できます。
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.
TVまたはTLV：TVペイロードには、1オクテットタイプのペイロードとタイプ固有の長さの値があります。 TLVペイロードには、1オクテットタイプのペイロードと1オクテット長のペイロードがあります。長さフィールドは、オクテットの数で表される値の長さを示します。
Domain name: This is a TLV payload. The Type is 4. The domain name is to be used as the realm in an NAI [RFC4282]. The Domain name TLV SHOULD be present in an EAP-Initiate/ Re-auth-Start message.
ドメイン名：これはTLVペイロードです。タイプは4です。ドメイン名は、NAI [RFC4282]でレルムとして使用されます。ドメイン名TLVは、EAP-Initiate / Re-auth-Startメッセージに存在する必要があります（SHOULD）。
In addition, channel binding information MAY be included; see Section 5.5 for discussion. See Figure 12 for parameter specification.
さらに、チャネルバインディング情報が含まれる場合があります。議論についてはセクション5.5を参照してください。パラメータの仕様については、図12を参照してください。
In order to minimize ERP failure times, the authenticator SHOULD 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 requiring either lower-layer support or the ERP bootstrapping exchange.
ERPの失敗時間を最小限に抑えるために、オーセンティケータは、EAP-Initiate / Re-auth-Startメッセージを送信して、ピアにERPのサポートを示し、ピアがすでに完全なEAP認証を実行し、有効期限が切れていないキーマテリアルがある場合はERPを開始する必要があります。オーセンティケーターには、下位層のサポートやERPブートストラップ交換を必要とせずにピアがドメイン名TLVを学習できるように、ドメイン名TLVを含める必要があります（SHOULD）。
The authenticator MAY include channel binding information so that the server can verify whether the authenticator is claiming the same identity to both parties.
オーセンティケーターは、サーバーがオーセンティケーターが両方のパーティに同じアイデンティティを要求しているかどうかを確認できるように、チャネルバインディング情報を含めることができます。
The authenticator MAY retransmit the EAP-Initiate/Re-auth-Start message a few times for reliable transport.
オーセンティケーターは、信頼性の高いトランスポートのために、EAP-Initiate / Re-auth-Startメッセージを数回再送信してもよい（MAY）。
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 EAP-Initiate code value or if the peer has already sent the EAP-Initiate/Re-auth message to begin the ERP exchange, it MUST silently discard the EAP-Initiate/Re-auth-Start message.
ピアは、オーセンティケータからのEAP-Initiate / Re-auth-Startメッセージに応答して、EAP-Initiate / Re-authメッセージを送信する必要があります（SHOULD）。ピアがEAP-Initiateコード値を認識しない場合、またはピアがすでにEAP-Initiate / Re-authメッセージを送信してERP交換を開始している場合、ピアはEAP-Initiate / Re-auth-Startメッセージをサイレントに破棄する必要があります。
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 contained in the message 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 there is a local ER server between the peer and the home ER server and the peer has already initiated an ERP exchange with the local ER server, it SHOULD NOT start an ERP exchange with the home ER server.
EAP-Initiate / Re-auth-Startメッセージにドメイン名が含まれていて、ピアがまだドメイン情報を持っていない場合、ピアはメッセージに含まれているドメイン名を使用してDSRKを計算し、対応するDS-ローカルERサーバーとのERP交換を開始するためにEAP-Initiate / Re-authメッセージを送信するためのrIK。ピアとホームERサーバーの間にローカルERサーバーがあり、ピアがローカルERサーバーとのERP交換を既に開始している場合は、ホームERサーバーとのERP交換を開始しないでください。
The EAP-Initiate/Re-auth packet contains the parameters shown in Figure 9.
EAP-Initiate / Re-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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: EAP-Initiate/Re-auth Packet
図9：EAP-Initiate / Re-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フラグはブートストラップフラグとして使用されます。フラグがオンになっている場合、メッセージはブートストラップメッセージです。
'L' - The L flag is used to request the key lifetimes from the server.
'L'-Lフラグは、サーバーにキーの有効期間を要求するために使用されます。
The remaining 5 bits are set to 0 on transmission and ignored on reception.
残りの5ビットは送信時に0に設定され、受信時には無視されます。
SEQ: An unsigned 16-bit sequence number is used for replay protection. The SEQ field is initialized to 0 every time a new rRK is derived. The field is encoded in network byte order.
SEQ：符号なし16ビットシーケンス番号は、再生保護に使用されます。 SEQフィールドは、新しいrRKが導出されるたびに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.
TVまたはTLV：TVペイロードには、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 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 is specified in Aboba, et al. [RFC4282]. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet.
keyName-NAI：これはTLVペイロードで運ばれます。タイプは1です。NAIの長さは可変で、253オクテットを超えません。 EMSKnameはNAIのユーザー名部分にあり、16進値でエンコードされます。 EMSKnameの長さは64ビットであるため、ユーザー名部分は16オクテットを占めます。 rIKがEMSKから派生している場合、NAIのレルム部分はホームドメイン名であり、rIKがDSRKから派生している場合、NAIのレルム部分はDSRKの派生で使用されるドメイン名です。 NAI構文はAbobaなどで指定されています。 [RFC4282]。厳密に1つのkeyName-NAI属性がEAP-Initiate / Re-authパケットに存在する必要があります。
In addition, channel binding information MAY be included; see Section 5.5 for discussion. See Figure 12 for parameter specification.
さらに、チャネルバインディング情報が含まれる場合があります。議論についてはセクション5.5を参照してください。パラメータの仕様については、図12を参照してください。
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:
暗号スイート：このフィールドは、ERPに使用される整合性アルゴリズムを示します。キーの長さと出力の長さが示されているか、cryptosuiteの名前から明らかです。以下にいくつかの暗号スイートを指定します。
* 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は実装に必須であり、デフォルトの構成で有効にする必要があります（SHOULD）。
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パケットの整合性チェックサムが含まれます。フィールドの長さは暗号スイートによって示されます。
The EAP-Finish/Re-auth packet contains the parameters shown in Figure 10.
EAP-Finish / Re-authパケットには、図10に示すパラメータが含まれています。
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: EAP-Finish/Re-auth Packet
図10：EAP-Finish / Re-authパケット
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'-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フラグはブートストラップフラグとして使用されます。フラグがオンになっている場合、メッセージはブートストラップメッセージです。
'L' - The L flag is used to indicate the presence of the rRK lifetime TLV.
「L」-Lフラグは、rRKライフタイムTLVの存在を示すために使用されます。
The remaining 5 bits are set to 0 on transmission and ignored on reception.
残りの5ビットは送信時に0に設定され、受信時には無視されます。
SEQ: An unsigned 16-bit sequence number is used for replay protection. The SEQ field is initialized to 0 every time a new rRK is derived. The field is encoded in network byte order.
SEQ：符号なし16ビットシーケンス番号は、再生保護に使用されます。 SEQフィールドは、新しいrRKが導出されるたびに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.
TVまたはTLV：TVペイロードには、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 is specified in [RFC4282]. Exactly one instance of the keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth message.
keyName-NAI：これはTLVペイロードで運ばれます。タイプは1です。NAIの長さは可変で、253オクテットを超えません。 EMSKnameはNAIのユーザー名部分にあり、16進値でエンコードされます。 EMSKnameの長さは64ビットであるため、ユーザー名部分は16オクテットを占めます。 rIKがEMSKから派生している場合、NAIのレルム部分はホームドメイン名であり、rIKがDSRKから派生している場合、NAIのレルム部分はDSRKの派生で使用されるドメイン名です。 NAI構文は[RFC4282]で指定されています。 keyName-NAI属性の正確に1つのインスタンスがEAP-Finish / Re-authメッセージに存在する必要があります。
rRK Lifetime: This is a TV payload. The Type is 2. The value field contains an unsigned 32-bit integer in network byte order representing the lifetime of the rRK in seconds. If the 'L' flag is set, the rRK Lifetime attribute SHOULD be present.
rRKライフタイム：これはTVペイロードです。タイプは2です。値フィールドには、rRKのライフタイムを秒単位で表すネットワークバイトオーダーの符号なし32ビット整数が含まれています。 「L」フラグが設定されている場合、rRKライフタイム属性が存在する必要があります。
rMSK Lifetime: This is a TV payload. The Type is 3. The value field contains an unsigned 32-bit integer in network byte order representing the lifetime of the rMSK in seconds. If the 'L' flag is set, the rMSK Lifetime attribute SHOULD be present.
rMSKライフタイム：これはTVペイロードです。タイプは3です。値フィールドには、rMSKのライフタイムを秒単位で表すネットワークバイトオーダーの符号なし32ビット整数が含まれています。 'L'フラグが設定されている場合、rMSKライフタイム属性が存在する必要があります（SHOULD）。
Domain name: This is a TLV payload. The Type is 4. The domain name is to be used as the realm in an NAI [RFC4282]. The 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ペイロードです。タイプは4です。ドメイン名は、NAI [RFC4282]でレルムとして使用されます。ドメイン名属性は、ブートストラップフラグが設定されており、ローカルERサーバーがDSRK要求を送信した場合、EAP-Finish / Re-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 9. 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 its cryptographic algorithm capabilities to the peer.
暗号スイートのリスト：これはTLVペイロードです。タイプは5です。値フィールドには、それぞれサイズ1オクテットの暗号スイートのリストが含まれます。 cryptosuiteの値は、図9に指定されているとおりです。EAP-Initiate/ Re-authメッセージで使用されたcryptosuiteが受け入れられず、メッセージが拒否されている場合、サーバーはこの属性を含める必要があります。サーバーは他の場合にこの属性を含めることができます。サーバーはこの属性を使用して、暗号アルゴリズム機能をピアに通知することができます。
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 EAP 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 for which the DSRK is being derived.
許可表示：これはTLVペイロードです。タイプは6です。DSRKがローカルERサーバーに配信され、ホームEAPサーバーがローカルERサーバーの承認を確認してドメイン名をアドバタイズできる場合、この属性はEAP-Finish / Re-authメッセージに含めることができます同じメッセージのドメインTLVに含まれています。 TLVの値フィールドには、コードフィールドの最初のビットから始めて暗号スイートフィールドの最後のビットまでパケット全体で計算された認証タグが含まれ、Authorization Indication TLVの値フィールドには計算のすべて0が入力されます。計算に使用される鍵は、「DSRK Delivery Authorized Key@ietf.org」という鍵ラベルと、DSRKが導出される鍵管理ドメインを表すASCII文字列を含むオプションのデータを使用して、EMSKから導出する必要があります。
In addition, channel binding information MAY be included: see Section 5.5 for discussion. See Figure 12 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を参照してください。パラメータの仕様については、図12を参照してください。サーバーはこの情報を送信して、チャネルバインディングがサポートされている場合に、ピアが下位層に表示される情報を確認できるようにします。
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.
暗号スイート：このフィールドは、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パケットの整合性チェックサムが含まれます。フィールドの長さは暗号スイートによって示されます。
The TV attributes that may be present in the EAP-Initiate or EAP-Finish messages are of the following format:
EAP-InitiateまたはEAP-Finishメッセージに存在する可能性のあるTV属性は、次の形式です。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TV Attribute Format
図11：TV属性フォーマット
The TLV attributes that may be present in the EAP-Initiate or EAP-Finish messages are of the following format:
EAP-InitiateまたはEAP-Finishメッセージに含まれる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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: TLV Attribute Format
図12：TLV属性フォーマット
The following Types are defined in this document:
このドキュメントでは、次のタイプが定義されています。
'1' - keyName-NAI: This is a TLV payload.
'1'-keyName-NAI：これはTLVペイロードです。
'2' - rRK Lifetime: This is a TV payload.
'2'-rRKライフタイム：これはTVペイロードです。
'3' - rMSK Lifetime: This is a TV payload.
'3'-rMSKライフタイム：これはTVペイロードです。
'4' - Domain name: This is a TLV payload.
'4'-ドメイン名：これはTLVペイロードです。
'5' - Cryptosuite list: This is a TLV payload.
「5」-暗号スイートリスト：これは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/Re-auth and EAP-Finish/Re-auth messages. Below are the current assignments (all of them are TLVs):
TLVタイプの範囲である128〜191は、EAP-Initiate / Re-authおよびEAP-Finish / Re-authメッセージでチャネルバインディング情報を伝送するために予約されています。以下は現在の割り当てです（それらはすべてTLVです）：
'128' - Called-Station-Id [RFC2865]
'128'-Called-Station-Id [RFC2865]
'129' - Calling-Station-Id [RFC2865]
'129'-Calling-Station-Id [RFC2865]
'130' - NAS-Identifier [RFC2865]
'130'-NAS識別子[RFC2865]
'131' - NAS-IP-Address [RFC2865]
'131'-NAS-IP-Address [RFC2865]
'132' - NAS-IPv6-Address [RFC3162]
'132'-NAS-IPv6-アドレス[RFC3162]
The length field indicates the length of the value part of the attribute in octets.
長さフィールドは、属性の値の部分の長さをオクテットで示します。
For replay protection, ERP uses sequence numbers. The sequence number is maintained on a per rIK basis and is initialized to zero in both directions. In the first EAP-Initiate/Re-auth message, the peer uses a sequence number value of zero or higher. Note that when the sequence number wraps back to zero, the rIK MUST be changed by running a full 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 MUST accept sequence numbers greater than or equal to the expected sequence number.
再生保護のために、ERPはシーケンス番号を使用します。シーケンス番号は、rIKごとに維持され、両方向でゼロに初期化されます。最初のEAP-Initiate / Re-authメッセージでは、ピアは0以上のシーケンス番号値を使用します。シーケンス番号がゼロに戻った場合、完全なEAP認証を実行してrIKを変更する必要があることに注意してください。サーバーは、0以上のシーケンス番号を予期します。サーバーはEAP-Initiate / Re-authメッセージを受信すると、EAP-Finish / Re-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 preconfigured number of times before giving up. However, it is plausible that the server itself may have responded to the message and the response 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. If the sequence number wraps back to zero, the peer MUST run full EAP authentication.
ピアがEAP-Initiate / Re-authメッセージを送信しても応答を受信しない場合は、あきらめる前に、事前に構成された回数だけ要求を（メッセージ自体に変更を加えずに）再送信します。ただし、サーバー自体がメッセージに応答し、転送中に応答が失われた可能性があります。したがって、ピアはシーケンス番号をインクリメントし、新しいシーケンス番号を使用して、後続のEAP再認証メッセージを送信する必要があります。ピアはシーケンス番号を1だけ増やす必要があります（SHOULD）。ただし、より大きな数で増分することを選択できます。シーケンス番号がゼロに戻る場合、ピアは完全なEAP認証を実行する必要があります。
ERP provides a protected facility to carry channel binding (CB) information, according to the guidelines provided by Aboba, et al. (see Section 7.15 of [RFC3748]). 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 managed by IANA, based on IETF Review (formerly called "IETF Consensus") [RFC5226].
Aboba、et al。が提供するガイドラインによれば、ERPはチャネルバインディング（CB）情報を伝送する保護された機能を提供します。 （[RFC3748]のセクション7.15を参照）。 TLVタイプの範囲である128〜191は、EAP-Initiate / Re-authおよびEAP-Finish / Re-authメッセージでCB情報を伝送するために予約されています。 Called-Station-Id、Calling-Station-Id、NAS-Identifier、NAS-IP-Address、およびNAS-IPv6-Addressは、RFC 3748にリストされているチャネルバインディング情報の例であり、128〜132の値が割り当てられています。追加の値は、IETFレビュー（以前は「IETFコンセンサス」と呼ばれていました）[RFC5226]に基づいて、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-Initiate / Re-auth-Startメッセージを介してピアにCB情報を提供する場合があります。ピアはEAP-Initiate / Re-authメッセージでサーバーに情報を送信します。サーバーは、AAA属性を介して使用できる認証IDが、ピアに提供されたIDと同じかどうかを確認します。
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-Initiate / Re-authメッセージにCB情報を含まず、ローカルERサーバーのポリシーがチャネルバインディングサポートを必要とする場合、ピアの検証のためにCB属性を送信する必要があります（SHALL）。オーセンティケーターがCBパラメーターを送信した場合、ピアはCB情報の検証を試み、属性が一致する場合は、下位層のセキュリティアソシエーションの確立に進みます。それ以外の場合、ピアは下位層のセキュリティアソシエーションの確立を続行してはなりません（SHALL NOT）。
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 might not know if the peer supports ERP; in those cases, the peer could be silently discarding 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.
オーセンティケーターは、EAP-Initiate / Re-auth-Startメッセージの再送信を担当します。オーセンティケーターは、メッセージを数回、またはピアからEAP-Initiate / Re-authメッセージを受信するまで再送信してもよい（MAY）。オーセンティケーターは、ピアがERPをサポートしているかどうかを知らない場合があります。これらの場合、ピアはEAP-Initiate / Re-auth-Startパケットを静かに破棄している可能性があります。したがって、これらのパケットの再送信は最小限に抑える必要があります。正確な数は各下位層までです。
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-Initiate / Re-authパケットの識別子の値は、EAP-Initiate / Re-auth-Startパケットの識別子の値とは無関係です。
The peer is responsible for retransmission of EAP-Initiate/Re-auth messages.
ピアは、EAP-Initiate / Re-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 [RFC3748]. 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 for additional guidance on setting timers.
再送信されたパケットは、新しいパケットと区別するために、同じ識別子の値で送信する必要があります。デフォルトでは、EAP-Initiateメッセージが信頼できない下位層を介して送信される場合、再送信タイマーは動的に推定される必要があります（SHOULD）。最大3-5回の再送信が推奨されます[RFC3748]。 EAP-Initiateメッセージが信頼できる下位層で送信される場合、再送信タイマーは、EAP層で再送信が発生しないように無限値に設定する必要があります（SHOULD）。タイマーの設定に関する追加のガイダンスについては、RFC 3748を参照してください。
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-Finish / Re-authパケットの識別子の値は、EAP-Initiate / Re-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-Finish / Re-authメッセージを送信した有効な重複EAP-Initiate / Re-authメッセージを受信した場合、EAP-Finish / Re-authメッセージを再送信せずに再送信する必要があります。再認証メッセージ。これを容易にするために、認証者はEAP-Finish / Re-authメッセージのコピーを有限時間保存する必要があります（SHALL）。時間の実際の値はローカルな問題です。この仕様では、100ミリ秒の値を推奨しています。
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, RFC 5996 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をInternet Key Exchange Protocolバージョン2（IKEv2）で使用するには、RFC 5996を更新して、4より大きいEAPコード値を含める必要があります。 IKEv2は、最適化された操作のためにピアが開始したERPをサポートするように更新することもできます。他の下位層も同様の修正が必要になる場合があります。
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 messages; peers may learn whether an authenticator supports ERP via configuration or from advertisements at the lower layer.
私たちの分析によると、一部のEAP実装はRFC 3748に準拠しておらず、コード値が4を超えるEAPパケットを暗黙的にドロップする代わりに、エラーと見なす場合があります。このような非準拠のEAP実装に対応するために、以下に追加のガイダンスが提供されています。さらに、場合によっては、すべてのピアをアップグレードするのは簡単ではありません。このような場合、認証者はEAP-Initiate / Re-auth-Startメッセージを送信しないように設定できます。ピアは、オーセンティケータが設定を介して、または下位層でのアドバタイズから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 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., piggybacked on a beacon) or through negotiation. Alternatively, clients may recognize environments where ERP is available based on preconfiguration. 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.
RFC 3748に準拠していない実装に対応するために、そのような下位層は、両方の当事者がERPをサポートすることを保証する必要があります。たとえば、常にERPをサポートすることが知られている下位層を使用する場合、これは簡単です。 ERPサポートが保証されていない下位層の場合、ERPサポートは、シグナリング（たとえば、ビーコンに便乗）によって、またはネゴシエーションを通じて示される場合があります。または、クライアントは、事前構成に基づいてERPが利用可能な環境を認識する場合があります。他の同様のメカニズムも使用できる。 ERPサポートを検証できない場合、下位層は完全なEAP認証にフォールバックして、RFC 3748に準拠していないEAP実装に対応するように要求する場合があります。
AAA transport of ERP messages is specified by Hoeper, et al. [RFC5749] and Bournelle, et al. [DIAMETER-ERP].
ERPメッセージのAAAトランスポートはHoeperらによって指定されています。 [RFC5749]とBournelleなど。 [DIAMETER-ERP]。
This section provides an analysis of the protocol in accordance with the AAA key management guidelines described by Housley & Aboba [RFC4962].
このセクションでは、Housley＆Aboba [RFC4962]によって記述されたAAAキー管理ガイドラインに準拠したプロトコルの分析を提供します。
Cryptographic algorithm independence
暗号アルゴリズムの独立性
ERP 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 indicating a failure. Algorithm agility for the KDF is specified in Salowey, et al. [RFC5295]. Only when the algorithms used are deemed acceptable does the server proceed with the derivation of keys and verification of the proof of possession of relevant key material presented 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.
ERPはこの要件を満たします。ピアがMAC生成のために選択したアルゴリズムは、EAP-Initiate / Re-authメッセージで示されます。選択したアルゴリズムが受け入れられない場合、EAPサーバーは失敗を示すEAP-Finish / Re-authメッセージを返します。 KDFのアルゴリズムの俊敏性は、Saloweyらによって指定されています。 [RFC5295]。使用されているアルゴリズムが許容できると見なされた場合にのみ、サーバーは、キーの導出と、ピアによって提示された関連するキーマテリアルの所有証明の検証を進めます。アルゴリズムの本格的なネゴシエーションは、単一の往復プロトコルでは提供できません。したがって、プロトコルはアルゴリズムの俊敏性を提供しますが、真のネゴシエーションを提供しません。
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 another rMSK at any time.
ERPにより、特定のセッションに固有の強力で新しいキーが導出されます。 rMSKは、ピアが新しいオーセンティケーターのキーを必要とする場合、常にオンデマンドで導出されます。導出により、あるrMSKの侵害がいつでも別のrMSKの侵害につながることはありません。
Limited 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がエンティティと共有されることはなく、常にピアとサーバーに残ります。 rMSKは、ピアがERP交換を実行する認証システムにのみ提供されます。他のオーセンティケーターは、その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 is 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に設定し、メッセージに応答します。
Authenticating all parties
すべての当事者の認証
ERP provides mutual authentication of the peer and the server. Both parties need to possess the key 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.
ERPは、ピアとサーバーの相互認証を提供します。両方の当事者は、必要な鍵を正常に導出するために、以前のEAP交換から得られた鍵素材を所有している必要があります。また、EAP再認証応答メッセージとEAP再認証情報メッセージは両方とも整合性が保護されているため、ピアとサーバーは相互に確認できます。ローカルERサーバーでERP交換が実行されると、ピアとローカルサーバーは、同じ方法でその交換を介して相互に認証します。ピアとオーセンティケータは、通常の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 those exchanged within the AAA protocol.
ピアとオーセンティケータは、下位層の安全なアソシエーションプロトコルの一部として、同じキーマテリアルを開示せずに所有していることを示します。下位層で使用されるIDがAAAプロトコル内で交換されるものと異なる場合、ERPとのチャネルバインディングを使用して、交換されるIDの整合性を検証できます。
Key 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プロトコルを介してドメインのDSRKを対応するローカルERサーバーに送信します。同様に、ERサーバーは、AMSプロトコルを介して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 a DSRK retroactively compromises all ERP keys.
DARKの侵害は、それから派生したすべてのキーの侵害につながることに注意してください。さらに、ERP内には転送秘密はありません。したがって、DARKの侵害は遡及的にすべてのERPキーを侵害します。
It is RECOMMENDED that the AAA protocol be protected using IPsec or Transport Layer Security (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）を使用して保護することをお勧めします。ただし、キーは途中でAAAプロキシに公開される可能性があり、それらのプロキシのいずれかが侵害されると、それらを介して転送されるキーが侵害される可能性があることに注意してください。
The home EAP 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 entity that received the DSRK originally. If the home EAP server verifies authorization of a local domain server, it MAY hand out the DSRK to that domain more than once. In this case, the home EAP server includes the Authorization Indication TLV to assure the peer that DSRK delivery is secure.
ホームEAPサーバーは、最初にDSRKを受信したエンティティがDSRKを最初に受信したエンティティと同じであることを確認できない限り、特定のDSRKをローカルドメインサーバーに複数回渡してはなりません。ホームEAPサーバーがローカルドメインサーバーの承認を確認する場合、そのドメインにDSRKを複数回渡すことができます（MAY）。この場合、ホームEAPサーバーにはAuthorization Indication TLVが含まれており、DSRK配信が安全であることをピアに保証します。
Confirming cryptosuite selection
暗号スイート選択の確認
Cryptographic 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のコンテキストでの整合性と鍵導出の暗号化アルゴリズムは、EAP方式で使用されるものと同じである場合があります。その場合、EAP方式は暗号スイートの選択を確認する責任があります。さらに、暗号スイートはピアによってERP交換に含まれ、サーバーによって確認されます。このプロトコルにより、サーバーはピアが選択した暗号スイートを拒否し、代替を提供できます。ピアに適切なrIKが利用できない場合、代替は保護されていない方法で送信される可能性があります。ピアは、許可された暗号スイートの1つを使用して交換を再試行できます。ただし、この場合、サーバーから送信されたリストへの途中の変更は検出されません。サーバーにピアで使用できるrIKがある場合、リストは保護された方法で提供され、この問題は適用されません。
Uniquely named keys
一意の名前のキー
All keys produced within the context of ERP can be referred to uniquely as specified in this document. Also, the key names do not reveal any part of the key material.
ERPのコンテキスト内で生成されたすべてのキーは、このドキュメントで指定されているように一意に参照できます。また、キー名は、キーマテリアルのどの部分も明らかにしません。
Preventing the domino effect
ドミノ効果の防止
The compromise of one peer does not result in the compromise of key 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, and ERP thereby allows prevention of the domino effect by appropriately defining key scope.
1つのピアが侵害されても、システム内の他のピアが保持するキーマテリアルが侵害されることはありません。また、rMSKは単一の認証システムを対象としており、他の認証システムとは共有されません。したがって、1つの認証システムが侵害されても、システム内の他の認証システムが保持するセッションやキーが侵害されることはありません。ERPにより、キースコープを適切に定義することで、ドミノ効果を防止できます。
However, if keys are transported using hop-by-hop protection, compromise of a proxy may result in compromise of key material, e.g., the DSRK being sent to a local ER server.
ただし、ホップバイホップ保護を使用してキーが転送される場合、プロキシが侵害されると、DSRKがローカルのERサーバーに送信されるなど、キーマテリアルが侵害される可能性があります。
Binding a key to its context
キーをそのコンテキストにバインドする
All the keys derived for ERP are bound to the appropriate context using appropriate key labels. The lifetime of a child key is less than or equal to that of its parent key as specified in RFC 4962 [RFC4962]. The key usage, lifetime, and the parties that have access to the keys are specified.
ERP用に導出されたすべてのキーは、適切なキーラベルを使用して適切なコンテキストにバインドされます。子キーのライフタイムは、RFC 4962 [RFC4962]で指定されているように、親キーのライフタイム以下です。鍵の使用法、有効期間、および鍵にアクセスできる当事者が指定されています。
Confidentiality of identity
アイデンティティの機密性
Deployments where privacy is a concern may find that the use of the 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 ERP. 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.
プライバシーが懸念される展開では、ERKメッセージをルーティングするためにrIKname-NAIを使用すると、プライバシー要件が満たされる場合があります。 rRPの名前はERPの一部として変更されないため、ERPメッセージの複数の実行を関連付けることが妥当であることに注意してください。この仕様の開発時には、その要件についてのコンセンサスはありませんでした。 rIKnameが使用されておらず、代わりにPeer-IDが使用されている場合、ERP交換により、有線でPeer-IDが明らかになります。
Authorization restriction
認可制限
All the derived keys 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. Other restrictions on the use of session keys may be imposed by the specific lower layer but are out of scope for this specification.
すべての派生キーは、親キーの有効期間またはサーバーポリシーによって有効期間が制限されています。ドメイン固有のキーは、キーが派生するドメインでの使用にさらに制限されます。このドキュメントで指定されているすべてのキーは、ERPでの使用のみを目的としています。セッションキーの使用に関するその他の制限は、特定の下位層によって課される場合がありますが、この仕様の範囲外です。
Preventing a DoS attack
DoS攻撃の防止
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 AAA-Request to the server; in response, the server may send in a AAA reply an EAP-Finish/ Re-auth message indicating failure. Note that such attacks may be possible 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 rejection message, thus resulting in the link-layer connections being terminated.
EAP-Initiate / Re-authメッセージを使用すると、ピアでのサービス拒否（DoS）攻撃が可能になる場合があります。攻撃者は偽のEAP-Initiate / Re-authメッセージを送信する可能性があります。このメッセージは、AAA-Requestでオーセンティケータによってサーバーに送信される場合があります。それに応じて、サーバーはAAA応答でEAP-Finish / Re-authメッセージを送信して失敗を示します。このような攻撃は、IEEE 802.11のEAPoL-Start機能や、他のリンクレイヤーにある他の同様の機能で可能であり、ピアがEAP認証を開始できる場合に注意してください。攻撃者はこのようなメッセージを使用してEAPメソッドの実行を開始する可能性があり、失敗してサーバーが拒否メッセージを送信し、リンク層接続が終了する可能性があります。
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 key material for the same peer to exist so that smooth migration from the current link-layer SA to the new one is possible during rekey. These mechanisms prevent the link-layer connections from being terminated when a re-authentication procedure fails due to a bogus EAP-Initiate/Re-auth message.
このようなDoS攻撃を防ぐために、ERP障害が発生しても、完全なEAP交換によって確立された認証状態が削除されることはありません。または、下位層とAAAプロトコルは、同じピアの異なるEAPキーマテリアルから派生した2つのリンク層セキュリティアソシエーション（SA）が存在できるようにするメカニズムを定義して、現在のリンク層SAから新しいものへのスムーズな移行が可能になるようにします。キーの再生成中に可能です。これらのメカニズムは、偽のEAP-Initiate / Re-authメッセージが原因で再認証手順が失敗した場合に、リンク層接続が終了するのを防ぎます。
Key material transport
キーマテリアルの輸送
When a DSRK is sent from the home EAP server to a local domain server or when an 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.
DSRKがホームEAPサーバーからローカルドメインサーバーに送信されるとき、またはrMSKがERサーバーから認証システムに送信されるとき、キーを送信するエンティティとエンティティとの間にエンドツーエンドのセキュリティがない場合キーを受信すると、他のエンティティが別のドメインのERサーバーに送信されているキーにアクセスする可能性があります。このキートランスポートのモードは、EAP認証のコンテキストではMSKトランスポートのモードに似ています。さらに、ERPはアクセス認証用であり、エンドツーエンドのデータセキュリティをサポートしていないことも確認しています。典型的な実装では、トラフィックはアクセス制御実施ポイント（認証システム、またはアクセス制御実施のために認証システムによって委任されたエンティティ）を越えたところにあります。このモデルは、ネットワークの中央にあるエンティティが、アクセスネットワークからサービスを盗むために他の当事者が意図したキーを使用しない限り機能します。それが不可能な場合は、キー配信をエンドツーエンドで保護する必要があります。
The previous version of this document -- [RFC5296] -- performed the following IANA [IANA] actions:
このドキュメントの以前のバージョン-[RFC5296]-は、次のIANA [IANA]アクションを実行しました。
1. It registered Packet Codes "Initiate" and "Finish" in the EAP Registry. Those codes are referred to as "EAP-Initiate" and "EAP-Finish" throughout this document.
1. EAPレジストリにパケットコードの「開始」と「終了」を登録しました。これらのコードは、このドキュメント全体で「EAP-Initiate」および「EAP-Finish」と呼ばれています。
2. It created a Message Types table in the EAP Registry and registered several items in that table. Those items are referred to as "Re-auth-start" and "Re-auth" throughout this document.
2. EAPレジストリにメッセージタイプテーブルを作成し、そのテーブルにいくつかの項目を登録しました。これらの項目は、このドキュメント全体で「Re-auth-start」および「Re-auth」と呼ばれています。
3. It created an EAP-Initiate and Finish Attributes table in the EAP registry and registered several items in that table. Those items are recorded in this document in Section 5.3.4.
3. EAPレジストリにEAP-Initiate and Finish Attributesテーブルを作成し、そのテーブルにいくつかのアイテムを登録しました。これらの項目は、このドキュメントのセクション5.3.4に記録されています。
4. It created a Re-authentication Cryptosuites table in the EAP registry and registered several items in that table. Those items are recorded in this document at the end of Section 5.3.2.
4. EAPレジストリに再認証Cryptosuitesテーブルを作成し、そのテーブルにいくつかのアイテムを登録しました。これらの項目は、セクション5.3.2の最後にあるこのドキュメントに記録されています。
5. It registered two items in the USRK Key Labels registry:
5. USRKキーラベルレジストリに2つのアイテムを登録しました。
* Re-auth usage label "EAP Re-authentication Root Key@ietf.org", recorded in this document in Section 4.1.
* このドキュメントのセクション4.1に記録されている、再認証使用ラベル「EAP Re-authentication Root Key@ietf.org」。
* DSRK-authorized delivery key "DSRK Delivery Authorized Key@ietf.org", recorded in this document in the description of "Authorization Indication" in Section 5.3.3.
* このドキュメントの5.3.3節の「承認表示」の説明に記録されているDARK承認済みの配信キー「DARK Delivery Authorized Key@ietf.org」
Barry Leiba contributed all of the text in Section 9 and, as Applications Area Director, insisted upon its inclusion as a condition of publication.
Barry Leibaは、セクション9のすべてのテキストに貢献し、アプリケーションエリアディレクターとして、それを公開の条件として含めることを主張しました。
This document is largely based upon RFC 5296; thanks to all who participated in that effort (see Appendix A). In addition, thanks to Yaron Sheffer, Sebastien Decugis, Ralph Droms, Stephen Farrell, Charlie Kaufman, and Yoav Nir for (mostly) useful comments and review.
このドキュメントは、主にRFC 5296に基づいています。その取り組みに参加したすべての人に感謝します（付録Aを参照）。さらに、（ほとんど）有用なコメントとレビューを提供してくれたYaron Sheffer、Sebastien Decugis、Ralph Droms、Stephen Farrell、Charlie Kaufman、Yoav Nirに感謝します。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「The Network Access Identifier」、RFC 4282、2005年12月。
[RFC5295] 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.
[RFC5295] Salowey、J.、Dondeti、L.、Narayanan、V。、およびM. Nakhjiri、「拡張マスターセッションキー（EMSK）からのルートキーの派生に関する仕様」、RFC 5295、2008年8月。
[DIAMETER-ERP] Bournelle, J., Morand, L., Decugis, S., Wu, Q., and G. Zorn, "Diameter Support for the EAP Re-authentication Protocol (ERP)", Work in Progress, June 2012.
[DIAMETER-ERP] Bournelle、J.、Morand、L.、Deculis、S.、Wu、Q。、およびG. Zorn、「Diameter Support for the EAP Re-authentication Protocol（ERP）」、Work in Progress、6月2012。
[IANA] "Internet Assigned Numbers Authority", <http://www.iana.org/>.
[IANA] "Internet Assigned Numbers Authority"、<http://www.iana.org/>。
[IEEE_802.1X] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Std 802.1X-2010, February 2010.
[IEEE_802.1X] Institute of Electrical and Electronics Engineers、「IEEE Standard for Local and Metropolitan Area Networks：Port-Based Network Access Control」、IEEE Std 802.1X-2010、2010年2月。
[IKE-EXT-for-ERP] Nir, Y. and Q. Wu, "An IKEv2 Extension for Supporting ERP", Work in Progress, May 2012.
[IKE-EXT-for-ERP] Nir、Y.、Q。Wu、「An IKEv2 Extension for Supporting ERP」、Work in Progress、2012年5月。
[MSKHierarchy] 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.
[MSKHierarchy] Lopez、R.、Skarmeta、A.、Bournelle、J.、Laurent-Maknavicus、M.、J。Combes、「Improved EAP keying framework for a secure mobile access service」、IWCMC '06、Proceedings of the 2006ワイヤレス通信とモバイルコンピューティングに関する国際会議、ニューヨーク、ニューヨーク、米国、2006年。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「RADIUS and IPv6」、RFC 3162、2001年8月。
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4187] Arkko、J。およびH. Haverinen、「Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement（EAP-AKA）」、RFC 4187、2006年1月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley、R。およびB. Aboba、「認証、承認、およびアカウンティング（AAA）キー管理のガイダンス」、BCP 132、RFC 4962、2007年7月。
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008.
[RFC5169] Clancy、T.、Nakhjiri、M.、Narayanan、V。、およびL. Dondeti、「Handover Key Management and Re-Authentication Problem Statement」、RFC 5169、2008年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5296] Narayanan、V.およびL. Dondeti、「EAP Extensions for EAP Re-authentication Protocol（ERP）」、RFC 5296、2008年8月。
[RFC5749] Hoeper, K., Ed., Nakhjiri, M., and Y. Ohba, Ed., "Distribution of EAP-Based Keys for Handover and Re-Authentication", RFC 5749, March 2010.
[RFC5749] Hoeper、K.、Ed。、Nakhjiri、M.、およびY. Ohba、Ed。、「Distribution of EAP-Based Keys for Handover and Re-Authentication」、RFC 5749、2010年3月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキー交換プロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, December 2011.
[RFC6440] Zorn、G.、Wu、Q。、およびY. Wang、「EAP再認証プロトコル（ERP）ローカルドメイン名DHCPv6オプション」、RFC 6440、2011年12月。
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. Credit for the idea to use EAP-Initiate/ Re-auth-Start goes to Charles Clancy, and credit for the idea to use multiple link-layer SAs to mitigate DoS attacks 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 the rIKname when sent as part of the keyName-NAI field. Thanks to Bernard Aboba for suggestions in clarifying the EAP lock-step operation, and to Joe Salowey and Glen Zorn for help in specifying AAA transport of ERP messages. Thanks to Sam Hartman for the DSRK Authorization Indication mechanism.
このドキュメントの執筆では、バーナードアボバ、ヤリアルコ、サムハートマン、ラスハウズリー、ジョーサロウイ、ジェシーウォーカー、チャールズクランシー、ミカエラヴァンダービーン、ケダールガオンカー、パラグなど、多くの人々と問題空間とプロトコル自体について議論することで利益を得ました。 Agashe、Dinesh Dharmaraju、Pasi Eronen、Dan Harkins、Yoshi Ohba、Glen Zorn、Alan DeKok、Katrin Hoeper、およびHOKEYワーキンググループの他の参加者。 EAP-Initiate / Re-auth-Startを使用するアイデアの功績はCharles Clancyに、DoS攻撃を軽減するために複数のリンク層SAを使用するアイデアの功績は、Ohba Ohbaに贈られます。 Katrin Hoeperは、ウィンドウ処理技法を使用して複数の同時ER交換を処理することを提案しました。 keyName-NAIフィールドの一部として送信されるときにrIKnameに16進エンコーディングを使用するよう提案してくれたPasi Eronenに感謝します。 EAPロックステップ操作を明確にするための提案についてはBernard Abobaに、ERPメッセージのAAAトランスポートを指定するための支援についてはJoe SaloweyとGlen Zornに感謝します。 DSRK承認表示メカニズムを提供してくれたSam Hartmanに感謝します。
0. Authenticator --> Peer: EAP-Initiate/Re-auth-Start [Optional]
0. オーセンティケーター->ピア：EAP-Initiate / Re-auth-Start [オプション]
1. Peer --> Authenticator: EAP-Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, Auth-tag*)
1. ピア->オーセンティケーター：EAP-Initiate / Re-auth（SEQ、keyName-NAI、cryptosuite、Auth-tag *）
1a. Authenticator --> Re-auth-Server:
AAA-Request
{
Authenticator-Id,
EAP-Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,
Auth-tag*)
}
2. ER-Server --> Authenticator: AAA-Response { rMSK, EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info], Auth-tag*) }
2. ER-Server-> Authenticator：AAA-Response {rMSK、EAP-Finish / Re-auth（SEQ、keyName-NAI、cryptosuite、[CB-Info]、Auth-tag *）}
2b. Authenticator --> Peer:
EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info],
Auth-tag*)
* 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 / Finishメッセージ全体に対して行われます。 InitiateとFinishのコード値が異なるため、リフレクション攻撃が軽減されます。
Authors' Addresses
著者のアドレス
Zhen Cao China Mobile No. 32, Xuanwumenxi Ave., Xicheng District Beijing 100053 P.R. China EMail: caozhen@chinamobile.com
ZおよびNC AOチャイナモバイル番号32、X u 5つのドアを押してアベニューを誘致します。ξは地区北京になります。100053 P.R.中国メール：曹真@China Mobile.com
Baohong He China Academy of Telecommunication Research Beijing P.R. China Phone: +86 10 62300050 EMail: hebaohong@catr.cn
Baohong He China Academy of Telecommunication Research Beijing P.R. China電話：+86 10 62300050 Eメール：hebaohong@catr.cn
Yang Shi Huawei Technologies Co., Ltd. 156 Beiqing Road, Zhongguancun, Haidian District Beijing P.R. China Phone: +86 10 60614043 EMail: shiyang1@huawei.com
陽市hu Aはテクノロジー株式会社です。156be iqing道路、Zマクロビレッジ、Hショートポイント地区北京P.R.中国電話：+86 10 60614043メール：スタイル1 @ Huawei.com
Qin Wu (editor) Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, JiangSu 210012 China Phone: +86-25-84565892 EMail: bill.wu@huawei.com
Q in W U（編集者）hu Aはテクノロジー株式会社101ソフトウェアアベニュー、Y Uは地区NaN京、江蘇省210012中国電話：+ 86-25-84565892メール：Bill。無@ Huawei.com
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand Phone: +66 (0) 909 201060 EMail: glenzorn@gmail.com
Gelen Joron（編集者）Network Zen 228/356 Thanong Sunfoung Bang Na、Bangkok 10260 Thailand電話：+8（0）909から1080メール：Glenzoron：Gmail.com