[要約] RFC 5296は、EAP再認証プロトコル（ERP）のためのEAP拡張機能に関する規格です。このRFCの目的は、EAP再認証プロトコルのセキュリティと効率を向上させるための拡張機能を提供することです。
Network Working Group V. Narayanan
Request for Comments: 5296 L. Dondeti
Category: Standards Track Qualcomm, Inc.
August 2008
EAP Extensions for EAP Re-authentication Protocol (ERP)
EAP再認証プロトコルのEAP拡張機能（ERP）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting.
拡張可能な認証プロトコル（EAP）は、複数のタイプの認証方法をサポートする一般的なフレームワークです。EAPが認証に使用されるシステムでは、EAP交換全体を別の認証装置と繰り返さないことが望ましいです。このドキュメントは、EAPおよびEAPキーイング階層への拡張機能を指定して、ピアとEAPの再認証サーバーの間の効率的な再認証のためのEAPメソッド非依存性プロトコルをサポートします。再認証サーバーは、ホームネットワークまたはピアが接続しているローカルネットワークにある場合があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 6
3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 8
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 11
4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 12
4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 12
4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 13
4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 14
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 15
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 15
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 20
5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 21
5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 22
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 23
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 25
5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 26
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 29
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 31
7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Example ERP Exchange . . . . . . . . . . . . . . . . 42
The Extensible Authentication Protocol (EAP) is a an authentication framework that supports multiple authentication methods. The primary purpose is network access authentication, and a key-generating method is used when the lower layer wants to enforce access control. The EAP keying hierarchy defines two keys to be derived by all key-generating EAP methods: the Master Session Key (MSK) and the Extended MSK (EMSK). In the most common deployment scenario, an EAP peer and an EAP server authenticate each other through a third party known as the EAP authenticator. The EAP authenticator or an entity controlled by the EAP authenticator enforces access control. After successful authentication, the EAP server transports the MSK to the EAP authenticator; the EAP authenticator and the EAP peer establish transient session keys (TSKs) using the MSK as the authentication key, key derivation key, or a key transport key, and use the TSK for per-packet access enforcement.
拡張可能な認証プロトコル（EAP）は、複数の認証方法をサポートする認証フレームワークです。主な目的はネットワークアクセス認証であり、下層がアクセス制御を実施したい場合にキー生成方法が使用されます。EAPキーイング階層は、すべてのキー生成EAPメソッド（マスターセッションキー（MSK）と拡張MSK（EMSK））によって導出される2つのキーを定義します。最も一般的な展開シナリオでは、EAPピアとEAPサーバーがEAP認証器として知られる第三者を介して互いに認証されます。EAP AuthenticatorまたはEAP Authenticatorによって制御されるエンティティは、アクセス制御を実施します。認証が成功した後、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 delays in handover times. Some EAP methods specify the use of state from the initial authentication to optimize re-authentications by reducing the computational overhead, but method-specific re-authentication takes at least 2 round trips with the original EAP server in most cases (e.g., [6]). It is also important to note that several methods do not offer support for re-authentication.
ピアが1つの認証機から別の認証機に移動する場合、高速の携帯電話をサポートするための完全なEAP認証を避けることが望ましいです。EAPメソッドの別の実行との完全なEAP交換は、数回の往復旅行と完了までにかなりの時間をかけることができ、引き継ぎ時間に遅延を引き起こす可能性があります。一部のEAPメソッドは、計算オーバーヘッドを削減することにより再認証を最適化するための初期認証からの状態の使用を指定しますが、メソッド固有の再認証は、ほとんどの場合、元のEAPサーバーで少なくとも2回のラウンド旅行をします（例：[6]）。また、いくつかの方法では再認証のサポートを提供していないことに注意することも重要です。
Key sharing across authenticators is sometimes used as a practical solution to lower handover times. In that case, compromise of an authenticator results in compromise of keying material established via other authenticators. Other solutions for fast re-authentication exist in the literature [7] [8].
認証者間のキー共有は、引き渡し時間を下回る実用的なソリューションとして使用される場合があります。その場合、認証者の妥協は、他の認証器を介して確立されたキーイング素材の妥協をもたらします。高速な再認証のための他の解決策は文献に存在します[7] [8]。
In conclusion, to achieve low latency handovers, there is a need for a method-independent re-authentication protocol that completes in less than 2 round trips, preferably with a local server. The EAP re-authentication problem statement is described in detail in [9].
結論として、低レイテンシの携帯電話を実現するには、できればローカルサーバーを使用して、2回未満のラウンド旅行で完了する方法に依存しない再認証プロトコルが必要です。EAPの再認証問題ステートメントについては、[9]で詳細に説明されています。
This document specifies EAP Re-authentication Extensions (ERXs) for efficient re-authentication using EAP. The protocol that uses these extensions itself is referred to as the EAP Re-authentication Protocol (ERP). It supports EAP method-independent re-authentication for a peer that has valid, unexpired key material from a previously performed EAP authentication. The protocol and the key hierarchy required for EAP re-authentication are described in this document.
このドキュメントは、EAPを使用した効率的な再認証のために、EAP再認証拡張機能（ERXS）を指定します。これらの拡張機能自体を使用するプロトコルは、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 IEEE802.1x specification must be revised and RFC 4306 must be updated to carry ERP messages.
ERPをサポートするには、コード値が4を超え、ERPのピアによって開始された性質に対応するために、低層仕様を修正する必要がある場合があります。具体的には、IEEE802.1x仕様を改訂し、RFC 4306を更新してERPメッセージを伝達する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
This document uses the basic EAP terminology [2] and EMSK keying hierarchy terminology [3]. In addition, this document uses the following terms:
このドキュメントでは、基本的なEAP用語[2]およびEMSKキーイング階層の用語[3]を使用しています。さらに、このドキュメントでは、次の用語を使用しています。
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; the home ER server is located on the same backend authentication server as the EAP server in the home domain. The local ER server may not necessarily be a full EAP server.
ERサーバー - ここで説明するERPのサーバー部分を実行するエンティティ。このエンティティは、EAPサーバーである場合とそうでない場合があります。このドキュメントの「サーバー」への参照はすべて、特に明記しない限り、ERサーバーを意味します。ERサーバーは論理的なエンティティです。Home ERサーバーは、ホームドメインのEAPサーバーと同じバックエンド認証サーバーにあります。ローカルERサーバーは、必ずしも完全なEAPサーバーではない場合があります。
ERX - EAP re-authentication extensions.
ERX -EAP再認証拡張。
ERP - EAP Re-authentication Protocol that uses the re-authentication extensions.
ERP-再認証拡張機能を使用するEAP再認証プロトコル。
rRK - re-authentication Root Key, derived from the EMSK or DSRK.
RRK-デスクまたはダークから派生した再認証ルートキー。
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 -ReAuthentication MSK。これは、RRKから派生したauthenticatorごとのキーです。
keyName-NAI - ERP messages are integrity protected with the rIK or the DS-rIK. The use of rIK or DS-rIK for integrity protection of ERP messages is indicated by the EMSKname [3]; the protocol, which is ERP; and the realm, which indicates the domain name of the ER server. The EMSKname is copied into the username part of the NAI.
keyname-nai-erpメッセージは、rikまたはds-rikで整合性保護されています。ERPメッセージの整合性保護のためのRIKまたはDS-RIKの使用は、EMSKNAME [3]によって示されています。ERPであるプロトコル。ERサーバーのドメイン名を示すレルム。emsknameは、NAIのユーザー名部分にコピーされます。
Domain - Refers to a "key management domain" as defined in [3]. For simplicity, it is referred to as "domain" in this document. The terms "home domain" and "local domain" are used to differentiate between the originating key management domain that performs the full EAP exchange with the peer and the local domain to which a peer may be attached at a given time.
ドメイン - [3]で定義されている「キー管理ドメイン」を指します。簡単にするために、このドキュメントでは「ドメイン」と呼ばれます。「ホームドメイン」と「ローカルドメイン」という用語は、ピアとの完全なEAP交換を実行する発信元の主要な管理ドメインと、特定の時間にピアが添付される可能性のあるローカルドメインを区別するために使用されます。
ERP allows a peer and server to mutually verify proof of possession of keying material from an earlier EAP method run and to establish a security association between the peer and the authenticator. The authenticator acts as a pass-through entity for the Re-authentication Protocol in a manner similar to that of an EAP authenticator described in RFC 3748 [2]. ERP is a single round-trip exchange between the peer and the server; it is independent of the lower layer and the EAP method used during the full EAP exchange. The ER server may be in the home domain or in the same (visited) domain as the peer and the authenticator.
ERPにより、ピアとサーバーは、以前のEAPメソッドの実行からキーイング素材の所持の証明を相互に検証し、ピアと認証者の間のセキュリティ関連を確立することができます。Authenticatorは、RFC 3748 [2]に記載されているEAP認証器と同様の方法で、再認証プロトコルのパススルーエンティティとして機能します。ERPは、ピアとサーバーの間の単一の往復交換です。これは、下層と完全なEAP交換中に使用されるEAPメソッドとは無関係です。ERサーバーは、ホームドメインまたは同じ（訪問された）ドメインに、ピアおよび認証装置と同じ（訪問された）ドメインにあります。
Figure 2 shows the protocol exchange. The first time the peer attaches to any network, it performs a full EAP exchange (shown in Figure 1) with the EAP server; as a result, an MSK is distributed to the EAP authenticator. The MSK is then used by the authenticator and the peer to establish TSKs as needed. At the time of the initial EAP exchange, the peer and the server also derive an EMSK, which is used to derive a re-authentication Root Key (rRK). More precisely, a re-authentication Root Key is derived from the EMSK or from a Domain-Specific Root Key (DSRK), which itself is derived from the EMSK. The rRK is only available to the peer and the ER server and is never handed out to any other entity. Further, a re-authentication Integrity Key (rIK) is derived from the rRK; the peer and the ER server use the rIK to provide proof of possession while performing an ERP exchange. The rIK is also never handed out to any entity and is only available to the peer and server.
図2は、プロトコル交換を示しています。ピアが任意のネットワークに初めて接続すると、EAPサーバーを使用して完全なEAP交換（図1に示す）を実行します。その結果、MSKはEAP認証器に配布されます。その後、MSKは認証機とピアによって使用され、必要に応じてTSKを確立します。最初のEAP交換の時点で、ピアとサーバーはEMSKも導出されます。これは、再認証ルートキー（RRK）を導出するために使用されます。より正確には、再認証ルートキーは、EMSKまたはそれ自体がEMSKから派生したドメイン固有のルートキー（DSRK）から派生します。RRKは、ピアとERサーバーでのみ利用可能であり、他のエンティティに配られることはありません。さらに、再認証整合性キー（RIK）はRRKから派生しています。ピアとERサーバーは、RIKを使用して、ERP交換の実行中に所有の証明を提供します。RIKはまた、どのエンティティにも配られず、ピアとサーバーのみが利用できます。
When the ER server is in the home domain, the peer and the server use the rIK and rRK derived from the EMSK; and when the ER server is not in the home domain, they use the DS-rIK and DS-rRK corresponding to the local domain. The domain of the ER server is identified by the realm portion of the keyname-NAI in ERP messages.
ERサーバーがホームドメインにあるとき、ピアとサーバーはEMSKから派生したRIKとRRKを使用します。また、ERサーバーがホームドメインにない場合、ローカルドメインに対応するDS-RIKとDS-RRKを使用します。ERサーバーのドメインは、ERPメッセージのKeyName-NAIのレルム部分によって識別されます。
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 1: EAP Authentication
図1：EAP認証
Peer Authenticator 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 2: ERP Exchange
図2：ERP交換
Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this document for the purpose of EAP re-authentication. When the peer identifies a target authenticator that supports EAP re-authentication, it performs an ERP exchange, as shown in Figure 2; the exchange itself may happen when the peer attaches to a new authenticator supporting EAP re-authentication, or prior to 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.
EAP InitiateとEAP-Finishの2つの新しいEAPコードが、EAPの再認証を目的としてこのドキュメントで指定されています。ピアがEAPの再認証をサポートするターゲット認証器を識別すると、図2に示すように、ERP交換を実行します。交換自体は、ピアがEAPの再認証をサポートする新しい認証機に接続するとき、または添付ファイルの前に発生する場合があります。ピアはERPを単独で開始します。また、新しいAuthenticatorからのEAPイテリア/ReAuth-Startメッセージに応じてそうすることもできます。EAP Initiate/Reauth-Startメッセージにより、AuthenticatorはERP Exchangeをトリガーできます。
It is plausible that the authenticator does not know whether the peer supports ERP and whether the peer has performed a full EAP authentication through another authenticator. The authenticator MAY initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start message, and if there is no response, it will send the EAP-Request/ Identity message. Note that this avoids having two EAP messages in flight at the same time [2]. The authenticator may send the EAP-Initiate/Re-auth-Start message and wait for a short, locally configured amount of time. If the peer does not already know, this message indicates to the peer that the authenticator supports ERP. In response to this trigger from the authenticator, the peer can initiate the ERP exchange by sending an EAP-Initiate/Re-auth message. If there is no response from the peer after the necessary retransmissions (see Section 6), the authenticator MUST initiate EAP by sending an EAP-Request message, typically the EAP-Request/Identity message. Note that the authenticator may receive an EAP-Initiate/ Re-auth message after it has sent an EAP-Request/Identity message. If the authenticator supports ERP, it MUST proceed with the ERP exchange. When the EAP-Request/Identity times out, the authenticator MUST NOT close the connection if an ERP exchange is in progress or has already succeeded in establishing a re-authentication MSK.
認証者は、ピアがERPをサポートしているかどうか、およびピアが別の認証機を通じて完全なEAP認証を実行したかどうかを知らないことはもっともらしいです。Authenticatorは、EAP Initiate/ Reauth-Startメッセージを送信することによりERP Exchangeを開始できます。応答がない場合は、EAP-Request/ Identityメッセージを送信します。これにより、飛行中に2つのEAPメッセージがあることを避けることに注意してください[2]。Authenticatorは、EAP Initiate/Reauth-Startメッセージを送信し、短い局所的に構成された時間を待つことができます。ピアがまだわからない場合、このメッセージはピアに、認証者がERPをサポートしていることを示しています。Authenticatorからのこのトリガーに応じて、PeerはEAPイテリア/ReAuthメッセージを送信することによりERP交換を開始できます。必要な再送信後にピアからの応答がない場合（セクション6を参照）、認証者はEAP-Requestメッセージ、通常はEAP-Request/Identityメッセージを送信してEAPを開始する必要があります。Authenticatorは、EAP-Initiate/ ReauthメッセージをEAP-Request/ IDメッセージを送信した後に受信する場合があることに注意してください。AuthenticatorがERPをサポートする場合、ERP Exchangeを進める必要があります。EAP-Request/Identityがタイムアウトする場合、AuthenticatorはERP交換が進行中である場合、またはすでに再認証MSKの確立に成功している場合、接続を閉じてはなりません。
If the authenticator does not support ERP, it drops EAP-Initiate/ Re-auth messages [2] as the EAP code of those packets is greater than 4. An ERP-capable peer will exhaust the EAP-Initiate/Re-auth message retransmissions and fall back to EAP authentication by responding to EAP Request/Identity messages from the authenticator. If the peer does not support ERP or if it does not have unexpired key material from a previous EAP authentication, it drops EAP-Initiate/ Re-auth-Start messages. If there is no response to the EAP-Initiate/ Re-auth-Start message, the authenticator SHALL send an EAP Request message (typically EAP Request/Identity) to start EAP authentication. From this stage onwards, RFC 3748 rules apply. Note that this may introduce some delay in starting EAP. In some lower layers, the delay can be minimized or even avoided by the peer initiating EAP by sending messages such as EAPoL-Start in the IEEE 802.1X specification [10].
AuthenticatorがERPをサポートしていない場合、それらのパケットのEAPCODEが4より大きいため、EAPイテリア/ ReAuthメッセージ[2]をドロップします[2]AuthenticatorからのEAP要求/IDメッセージに応答することにより、EAP認証に戻ります。ピアがERPをサポートしていない場合、または以前のEAP認証から期限が切れていないキーマテリアルがない場合、EAP Initiate/ Reauth-Startメッセージをドロップします。EAP Initiate/ Reauth-Startメッセージへの応答がない場合、AuthenticatorはEAP認証を開始するためにEAP要求メッセージ（通常はEAP要求/ ID）を送信するものとします。この段階から、RFC 3748ルールが適用されます。これにより、EAPの開始にある程度の遅延が発生する可能性があることに注意してください。いくつかの下層では、IEEE 802.1x仕様[10]でEapol-Startなどのメッセージを送信することにより、PeerがEAPを開始することによって遅延を最小限に抑えるか、回避することさえできます。
The peer sends an EAP-Initiate/Re-auth message that contains the keyName-NAI to identify the ER server's domain and the rIK used to protect the message, and a sequence number for replay protection. The EAP-Initiate/Re-auth message is integrity protected with the rIK. The authenticator uses the realm in the keyName-NAI [4] field to send the message to the appropriate ER server. The server uses the keyName to look up the rIK. The server, after verifying proof of possession of the rIK, and freshness of the message, derives a re-authentication MSK (rMSK) from the rRK using the sequence number as an input to the key derivation. The server updates the expected sequence number to the received sequence number plus one.
ピアは、ERサーバーのドメインとメッセージを保護するために使用されるRIKを識別するためにKeyName-NAIを含むEAPイテリア/ReAuthメッセージを送信し、リプレイ保護のためのシーケンス番号。EAP Initiate/Reauthメッセージは、RIKで整合性保護されています。Authenticatorは、KeyName-NAI [4]フィールドの領域を使用して、適切なERサーバーにメッセージを送信します。サーバーはキーネームを使用してRIKを検索します。サーバーは、RIKの所有の証明とメッセージの新鮮さを確認した後、キー派生への入力としてシーケンス番号を使用して、RRKから再認証MSK（RMSK）を導き出します。サーバーは、予想されるシーケンス番号を受信したシーケンス番号と1に更新します。
In response to the EAP-Initiate/Re-auth message, the server sends an EAP-Finish/Re-auth message; this message is integrity protected with the rIK. The server transports the rMSK along with this message to the authenticator. The rMSK is transported in a manner similar to that of the MSK along with the EAP-Success message in a full EAP exchange. Ongoing work in [11] describes an additional key distribution protocol that can be used to transport the rRK from an EAP server to one of many different ER servers that share a trust relationship with the EAP server.
EAP Initiate/ReAuthメッセージに応じて、サーバーはEAP-Finish/ReAuthメッセージを送信します。このメッセージは、Rikで保護されている整合性です。サーバーは、このメッセージとともにRMSKを認証機に輸送します。RMSKは、完全なEAP交換でのEAPサクセスメッセージとともに、MSKと同様の方法で輸送されます。[11]で進行中の作業では、RRKをEAPサーバーからEAPサーバーと信頼関係を共有する多くの異なるERサーバーの1つに輸送するために使用できる追加のキーディストリビューションプロトコルについて説明しています。
The peer MAY request the server for the rMSK lifetime. If so, the ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message.
ピアは、RMSKライフタイムのサーバーを要求する場合があります。その場合、ERサーバーはEAP-Finish/ReAuthメッセージでRMSK寿命を送信します。
In an ERP bootstrap exchange, the peer MAY request the server for the rRK lifetime. If so, the ER server sends the rRK lifetime in the EAP-Finish/Re-auth message.
ERP Bootstrap Exchangeでは、ピアはRRKの寿命をサーバーに要求する場合があります。その場合、ERサーバーはRRK寿命をEAP-Finish/ReAuthメッセージで送信します。
The peer verifies the replay protection and the integrity of the message. It then uses the sequence number in the EAP-Finish/Re-auth message to compute the rMSK. The lower-layer security association protocol is ready to be triggered after this point.
ピアは、リプレイ保護とメッセージの完全性を確認します。次に、EAP-Finish/ReAuthメッセージのシーケンス番号を使用してRMSKを計算します。低層セキュリティ協会のプロトコルは、この時点の後にトリガーする準備ができています。
The defined ER extensions allow executing the ERP with an ER server in the local domain (access network). The local ER server may be co-located with a local AAA server. The peer may learn about the presence of a local ER server in the network and the local domain name (or ER server name) either via the lower layer or by means of ERP bootstrapping. The peer uses the domain name and the EMSK to compute the DSRK and from that key, the DS-rRK; the peer also uses the domain name in the realm portion of the keyName-NAI for using ERP in the local domain. Figure 3 shows the full EAP and subsequent local ERP exchange; Figure 4 shows it with a local ER server.
定義されたER拡張機能により、ローカルドメイン（アクセスネットワーク）にERサーバーを使用してERPを実行できます。ローカルERサーバーは、ローカルAAAサーバーと共同で開催される場合があります。ピアは、ネットワーク内のローカルERサーバーの存在と、下層またはERPブートストラップのいずれかを介してローカルドメイン名（またはERサーバー名）について学ぶことができます。ピアはドメイン名とEMSKを使用してDSRKを計算し、そのキーからDS-RRKを計算します。ピアはまた、キーネーム-NAIのレルム部分のドメイン名を使用して、ローカルドメインでERPを使用します。図3は、完全なEAPおよびその後のローカルERP交換を示しています。図4は、ローカルERサーバーでそれを示しています。
Peer EAP Authenticator Local ER Server Home EAP Server
==== ================= =============== ===============
<-- EAP-Request/ -- Identity
<-eap-request/ - アイデンティティ
-- EAP Response/-->
Identity --AAA(EAP Response/-->
Identity) --AAA(EAP Response/ -->
Identity,
[DSRK Request,
domain name])
<------------------------ EAP Method exchange------------------>
<---AAA(MSK, DSRK, ----
EMSKname,
EAP-Success)
<--- AAA(MSK, -----
EAP-Success)
<---EAP-Success-----
Figure 3: Local ERP Exchange, Initial EAP Exchange
図3：ローカルERP交換、初期EAP交換
Peer ER Authenticator Local ER Server
==== ================ ===============
[<-- EAP-Initiate/ --------
Re-auth-Start]
[<-- EAP-Request/ ---------
Identity]
---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ -------->
Re-auth Re-auth)
<--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
Re-auth Re-auth)
Figure 4: Local ERP Exchange
図4：ローカル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 authenticator and the home EAP server of the peer). In that case, the ER server requests the DSRK by sending the domain name to the EAP server. In response, the EAP server computes the DSRK by following the procedure specified in [3] and sends the DSRK and the key name, EMSKname, to the ER server in the claimed domain. The local domain is responsible for announcing that same domain name via the lower layer to the peer.
図4に示すように、ローカルERサーバーは完全なEAP交換のパスに存在する可能性があります（たとえば、これはAAAプロキシなどのAAAエンティティの1つであり、認証機とホームEAPサーバーの間のパスにあります。ピア）。その場合、ERサーバーは、ドメイン名をEAPサーバーに送信してDSRKを要求します。これに応じて、EAPサーバーは[3]で指定された手順に従ってDSRKを計算し、請求ドメインのDSRKとキー名、EMSKNAMEをERサーバーに送信します。ローカルドメインは、ピアへの下層層を介して同じドメイン名を発表する責任があります。
If the peer does not know the domain name (did not receive the domain name via the lower-layer announcement, due to a missed announcement or lack of support for domain name announcements in a specific lower layer), it SHOULD initiate ERP bootstrap exchange with the home ER server to obtain the domain name. The local ER server SHALL request the home AAA server for the DSRK by sending the domain name in the AAA message that carries the EAP-Initiate/Re-auth bootstrap message. The local ER server MUST be in the path from the peer to the home ER server. If it is not, it cannot request the DSRK.
ピアがドメイン名を知らない場合（特定の下層層でのドメイン名アナウンスのサポートの欠落またはサポートの欠如のために、下層の発表を介してドメイン名を受信しなかった場合）ドメイン名を取得するホームERサーバー。ローカルERサーバーは、EAP Initiate/ReAuth Bootstrapメッセージを伝達するAAAメッセージにドメイン名を送信することにより、DSRKのHome AAAサーバーを要求するものとします。ローカルERサーバーは、ピアからホームERサーバーへのパスにある必要があります。そうでない場合、DSRKを要求することはできません。
After receiving the DSRK and the EMSKname, the local ER server computes the DS-rRK and the DS-rIK from the DSRK as defined in Sections 4.1 and 4.3 below. After receiving the domain name, the peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys are referred to by a keyName-NAI formed as follows: the username part of the NAI is the EMSKname, the realm portion of the NAI is the domain name. Both parties also maintain a sequence number (initialized to zero) corresponding to the specific keyName-NAI.
DSRKとEMSKNAMEを受信した後、ローカルERサーバーは、以下のセクション4.1および4.3で定義されているように、DSRKからDS-RRKとDS-RIKを計算します。ドメイン名を受け取った後、ピアはDSRK、DS-RRK、およびDS-RIKも導き出します。これらのキーは、次のように形成されたキーネーム-NAIによって参照されます。NAIのユーザー名部分はemskname、naiの領域部分はドメイン名です。どちらの当事者も、特定のKeyName-NAIに対応するシーケンス番号（初期化されたゼロ）を維持しています。
Subsequently, when the peer attaches to an authenticator within the local domain, it may perform an ERP exchange with the local ER server to obtain an rMSK for the new authenticator.
その後、ピアがローカルドメイン内の認証器に接続すると、ローカルERサーバーとERP交換を実行して、新しい認証器用のRMSKを取得できます。
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) in accordance with [3] for re-authentication. The USRK designated for re-authentication is the re-authentication root key (rRK). A DSUSRK designated for re-authentication is the DS- rRK available to a local ER server in a particular domain. For simplicity, the keys are referred to without the DS label in the rest of the document. However, the scope of the various keys is limited to just the respective domains they are derived for, in the case of the domain specific keys. Based on the ER server with which the peer performs the ERP exchange, it knows the corresponding keys that must be used.
RRKは、セクション4.1で指定されているように、EMSKまたはDSRKから派生しています。RRK派生の目的のために、このドキュメントは、再認証のために[3]に従って、使用法固有のルートキー（USRK）またはドメイン固有のUSRK（DSUSRK）の導出を指定します。再認証のために指定された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 5: Re-authentication Key Hierarchy
図5：再認証キー階層
The derivations in this document are according to [3]. Key derivations and field encodings, where unspecified, default to that document.
このドキュメントの派生は[3]に従ってです。主要な派生とフィールドエンコーディングは、不特定の場合、その文書にデフォルトです。
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 [3].
RRKは[3]で指定されているように導出されます。
rRK = KDF (K, S), where
rrk = kdf（k、s）、ここで
K = EMSK or K = DSRK and
k = emskまたはk = dsrkおよび
S = rRK Label | "\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 reauthentication root key@ietf.org
assigned from the "USRK key labels" name space in accordance with [3].
[3]に従って「USRKキーラベル」という名前のスペースから割り当てられています。
The KDF and algorithm agility for the KDF are as defined in [3].
KDFおよびKDFのアルゴリズムの俊敏性は、[3]で定義されているとおりです。
An rRK derived from the DSRK is referred to as a DS-rRK in the rest of the document. All the key derivation and properties specified in this section remain the same.
暗闇から派生した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 derivation of rIK and rMSK as specified in this document.
o RRKは、このドキュメントで指定されているRIKとRMSKの導出にのみ使用されます。
o The rRK MUST remain on the peer and the server that derived it and MUST NOT be transported to any other entity.
o RRKは、それを導き出したピアとサーバーに留まり、他のエンティティに輸送してはなりません。
o The lifetime of the rRK is never greater than that of its parent key. The rRK is expired when the parent key expires and MUST be removed from use at that time.
o RRKの寿命は、その親キーの寿命よりも大きくなることはありません。RRKは、親キーが期限切れになると期限切れになり、その時点で使用から削除する必要があります。
The re-authentication Integrity Key (rIK) is used for integrity protecting the ERP exchange. This serves as the proof of possession of valid keying material from a previous full EAP exchange by the peer to the server.
再認証整合性キー（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" |CryptoSuite |長さ
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 encoded as specified in [3].
長さフィールドは、[3]で指定されているようにエンコードされたオクテットのRIKの長さを指します。
The cryptosuite and length of the rIK are part of the input to the key derivation function to ensure cryptographic separation of keys if different rIKs of different lengths for use with different Message Authentication Code (MAC) algorithms are derived from the same rRK. The cryptosuite is encoded as an 8-bit number; see Section 5.3.2 for the cryptosuite specification.
RIKの暗号化物と長さは、異なるメッセージ認証コード（MAC）アルゴリズムで使用する異なる長さの異なるRiksが同じRRKから派生した場合、キーの派生関数への入力の一部です。CryptoSuiteは8ビット番号としてエンコードされています。CryptoSuiteの仕様については、セクション5.3.2を参照してください。
The rIK is referred to by EMSKname-NAI within the context of ERP messages. The username part of EMSKname-NAI is the EMSKname; the realm is the domain name of the ER server. In case of ERP with the home ER server, the peer uses the realm from its original NAI; in case of a local ER server, the peer uses the domain name received at the lower layer or through an ERP bootstrapping exchange.
RIKは、ERPメッセージのコンテキスト内でEMSKNAME-NAIによって言及されています。emskname-naiのユーザー名の部分はemsknameです。レルムは、ERサーバーのドメイン名です。Home ERサーバーのERPの場合、ピアは元のNAIの領域を使用します。ローカルERサーバーの場合、ピアは下層で受信したドメイン名またはERPブートストラップ交換を介して使用します。
An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest of the document. All the key derivation and properties specified in this section remain the same.
DS-RRKから派生したRIKは、文書の残りの部分でDS-RIKと呼ばれます。このセクションで指定されているすべての重要な派生とプロパティは同じままです。
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の寿命は、その親キーの寿命よりも大きくなることはありません。EMSKの有効期限が切れたときにRIKは期限切れになり、その時点で使用から削除する必要があります。
The rIK is the key whose possession is demonstrated by the peer and the ERP server to the other party. The peer demonstrates possession of the rIK by computing the integrity checksum over the EAP-Initiate/ Re-auth message. When the peer uses the rIK for the first time, it can choose the integrity algorithm to use with the rIK. The peer and the server MUST use the same integrity algorithm with a given rIK for 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/ ReAuthメッセージを介して整合性チェックサムを計算することにより、RIKの所有を示します。ピアが初めてRIKを使用する場合、RIKで使用するIntegrityアルゴリズムを選択できます。ピアとサーバーは、そのキーで保護されているすべての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イテリア/再オーースメッセージを拒否し、EAP-Finish/ ReAuthメッセージに許容可能なクリプトスーツのリストを送信する必要があります。
The rIK length may be different from the key length required by an integrity algorithm. In case of hash-based MAC algorithms, the key is first hashed to the required key length as specified in [5]. In case of cipher-based MAC algorithms, if the required key length is less than 32 octets, the rIK is hashed using HMAC-SHA256 and the first k octets of the output are used, where k is the key length required by the algorithm. If the required key length is more than 32 octets, the first k octets of the rIK are used by the cipher-based MAC algorithm.
RIKの長さは、整合性アルゴリズムで必要なキー長とは異なる場合があります。ハッシュベースのMACアルゴリズムの場合、キーは[5]で指定されているように、必要なキー長に最初にハッシュされます。CipherベースのMACアルゴリズムの場合、必要なキー長が32オクテット未満の場合、RIKは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 EAP Re-auth Protocol exchange.
RMSKはピアとサーバーで導出され、認証機に配信されます。RMSKは、EAP ReAuthプロトコル交換に続いて導出されます。
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. The length field is encoded as specified in [3].
長さフィールドは、オクテットのRMSKの長さを指します。長さフィールドは、[3]で指定されているようにエンコードされています。
SEQ is the sequence number sent by the peer in the EAP-Initiate/ Re-auth message. This field is encoded as a 16-bit number in network byte order (see Section 5.3.2).
seqは、EAP Initiate/ reauthメッセージでピアが送信したシーケンス番号です。このフィールドは、ネットワークバイトの順序で16ビット数としてエンコードされています（セクション5.3.2を参照）。
An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest of the document. All the key derivation and properties specified in this section remain the same.
DS-RRKから派生したRMSKは、文書の残りの部分でDS-RIKと呼ばれます。このセクションで指定されているすべての重要な派生とプロパティは同じままです。
The rMSK has the following properties:
RMSKには次のプロパティがあります。
o The length of the rMSK MUST be equal to the length of the rRK.
o RMSKの長さは、RRKの長さに等しくなければなりません。
o The rMSK is delivered to the authenticator and is used for the same purposes that an MSK is used at an authenticator.
o RMSKは認証機に配信され、MSKが認証器で使用されるのと同じ目的で使用されます。
o The rMSK is cryptographically separate from any other keys derived from the rRK.
o RMSKは、RRKから派生した他のキーと暗号化的に分離されています。
o The lifetime of the rMSK is less than or equal to that of the rRK. It MUST NOT be greater than the lifetime of the rRK.
o RMSKの寿命は、RRKの寿命以下です。RRKの寿命よりも大きくてはなりません。
o If a new rRK is derived, subsequent rMSKs MUST be derived from the new rRK. Previously delivered rMSKs MAY still be used until the expiry of the lifetime.
o 新しいRRKが導出されている場合、その後の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 bootstrapping. In implicit bootstrapping, the local ER server SHOULD include its domain name and SHOULD request the DSRK from the home AAA server during the initial EAP exchange, in the AAA message encapsulating the first EAP Response message sent by the peer. If the EAP exchange is successful, the server sends the DSRK for the local ER server (derived using the EMSK and the domain name as specified in [3]), EMSKname, and DSRK lifetime along with the EAP-Success message. The local ER server MUST extract the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding the EAP-Success message to the peer, as specified in [12]. Note that the MSK (also present along with the EAP Success message) is extracted by the EAP authenticator as usual. The peer learns the domain name through the EAP-Initiate/Re-auth-Start message or via lower-layer announcements. When the domain name is available to the peer during or after the full EAP authentication, it attempts to use ERP when it associates with a new authenticator.
ERPの2種類のブートストラップを特定します：明示的および暗黙的なブートストラップ。暗黙のブートストラップでは、ローカルERサーバーにドメイン名を含める必要があり、ピアが送信した最初のEAP応答メッセージをカプセル化するAAAメッセージで、最初のEAP交換中にホームAAAサーバーからDSRKを要求する必要があります。EAP Exchangeが成功した場合、サーバーはローカルERサーバー（[3]で指定されているEMSKとドメイン名を使用して派生した）、EMSKNAME、およびDSRK LifetimeにDSRKをEAP-SUCSESメッセージとともに送信します。ローカルERサーバーは、[12]で指定されているように、EAPサクセスメッセージをピアに転送する前に、DSRK、EMSKNAME、およびDSRK Lifetime（存在する場合）を抽出する必要があります。MSK（EAP成功メッセージとともに存在する）は、通常どおりEAP認証器によって抽出されることに注意してください。ピアは、EAP Initiate/Reauth-Startメッセージまたは低層の発表を通じてドメイン名を学習します。ドメイン名が完全なEAP認証中または完全なEAP認証後にピアが使用できる場合、新しい認証機と関連するときにERPを使用しようとします。
If the peer does not know the domain name (did not receive the domain name via the lower-layer announcement, due to a missed announcement or lack of support for domain name announcements in a specific lower layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with the bootstrap flag turned on) with the home ER server to obtain the domain name. The local ER server behavior is the same as described above. The peer MAY also initiate bootstrapping to fetch information such as the rRK lifetime from the AAA server.
ピアがドメイン名を知らない場合（特定の下層層でのドメイン名のアナウンスのサポートの欠落またはサポートの欠如により、下層の発表を介してドメイン名を受信しなかった場合）、ERP Bootstrap Exchangeを開始するはずですBootstrapフラグとのERP交換は、Home ERサーバーを使用してドメイン名を取得しました。ローカルERサーバーの動作は、上記と同じです。ピアは、AAAサーバーからRRK Lifetimeなどの情報を取得するためにブートストラップを開始する場合もあります。
The following steps describe the ERP explicit bootstrapping process:
次の手順では、ERPの明示的なブートストラッププロセスについて説明します。
o The peer sends the EAP-Initiate/Re-auth message with the bootstrapping flag turned on. The bootstrap message is always sent to the home AAA server, and the keyname-NAI attribute in the bootstrap message is constructed as follows: the username portion of the NAI contains the EMSKname, and the realm portion contains the home domain name.
o ピアは、ブートストラップフラグをオンにして、EAPイナティエート/リオースメッセージを送信します。ブートストラップメッセージは常にホームAAAサーバーに送信され、ブートストラップメッセージのkeyname-nai属性は次のように構築されます。NAIのユーザー名部分にはemsknameが含まれ、レルム部分にはホームドメイン名が含まれています。
o In addition, the message MUST contain a sequence number for replay protection, a cryptosuite, and an integrity checksum. The cryptosuite indicates the authentication algorithm. The integrity checksum indicates that the message originated at the claimed entity, the peer indicated by the Peer-ID, or the rIKname.
o さらに、メッセージには、リプレイ保護のためのシーケンス番号、クリプトスイート、および整合性チェックサムを含める必要があります。CryptoSuiteは、認証アルゴリズムを示します。整合性チェックサムは、メッセージが請求されたエンティティ、ピアアイド、またはriknameで示されたピアで発生したことを示しています。
o The peer MAY additionally set the lifetime flag to request the key lifetimes.
o ピアはさらに、重要な寿命を要求するために生涯フラグを設定することができます。
o When an ERP-capable authenticator receives the EAP-Initiate/ Re-auth message from a peer, it copies the contents of the keyName-NAI into the User-Name attribute of RADIUS [13]. The rest of the process is similar to that described in [14] and [12].
o ERP対応の認証者がピアからEAPイテオテート/再オーースメッセージを受信すると、KeyName-NAIの内容をRADIUSのユーザー名属性にコピーします[13]。残りのプロセスは、[14]および[12]で説明されているプロセスと似ています。
o If a local ER server is present, the local ER server MUST include the DSRK request and its domain name in the AAA message encapsulating the EAP-Initiate/Re-auth message sent by the peer.
o ローカルERサーバーが存在する場合、ローカルERサーバーには、ピアが送信したEAPイテリア/再オーースメッセージをカプセル化するAAAメッセージにダークリクエストとそのドメイン名を含める必要があります。
o Upon receipt of an EAP-Initiate/Re-auth message, the server verifies whether the message is fresh or is a replay by evaluating whether the received sequence number is equal to or greater than the expected sequence number for that rIK. The server then verifies to ensure that the cryptosuite used by the peer is acceptable. Next, it verifies the origin authentication of the message by looking up the rIK. If any of the checks fail, the server sends an EAP-Finish/Re-auth message with the Result flag set to '1'. Please refer to Section 5.2.2 for details on failure handling. This error MUST NOT have any correlation to any EAP-Success message that may have been received by the EAP authenticator and the peer earlier. If the EAP-Initiate/Re-auth message is well-formed and valid, the server prepares the EAP-Finish/Re-auth message. The bootstrap flag MUST be set to indicate that this is a bootstrapping exchange. The message contains the following fields:
o EAP Initiate/ReAuthメッセージを受信すると、サーバーは、受信したシーケンス番号がそのRIKの予想シーケンス番号以上であるかどうかを評価することにより、メッセージが新鮮か、またはリプレイであるかどうかを確認します。次に、サーバーは検証して、ピアが使用するクリプトスイートが許容できることを確認します。次に、RIKを調べることにより、メッセージの起源認証を検証します。チェックのいずれかが失敗した場合、サーバーは結果フラグが「1」に設定されたEAPフィニッシュ/ReAuthメッセージを送信します。故障処理の詳細については、セクション5.2.2を参照してください。このエラーは、EAP AuthenticatorとPeerが以前に受信した可能性のあるEAP-SUCSESSメッセージとの相関関係を持たないはずです。EAP Initiate/ReAuthメッセージが適切に形成されている場合、サーバーはEAP-Finish/ReAuthメッセージを準備します。ブートストラップフラグは、これがブートストラップ交換であることを示すために設定する必要があります。メッセージには次のフィールドが含まれています。
* A sequence number for replay protection.
* リプレイ保護のシーケンス番号。
* The same keyName-NAI as in the EAP-Initiate/Re-auth message.
* EAPイニティエート/リアースメッセージと同じキーネーム-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.
* LifetimeフラグがEAP Initiate/ReAuthメッセージに設定されている場合、ERサーバーには、EAP-Finish/ReAuthメッセージにRRK LifetimeとRMSK Lifetimeを含める必要があります。サーバーには、ネットワークが一方的に生涯を維持および実施するためのローカルポリシーがある場合があります。そのような場合、サーバーは、生涯のピアの要求に応答する必要はありません。
* If the bootstrap flag is set and a DSRK request is received, the server MUST include the domain name to which the DSRK is being sent.
* ブートストラップフラグが設定され、暗いリクエストが受信された場合、サーバーにはダークが送信されているドメイン名を含める必要があります。
* If the home ER server verifies the authorization of a local domain server, it MAY include the Authorization Indication TLV to indicate to the peer that the server (that received the DSRK and that is advertising the domain included in the domain name TLV) is authorized.
* Home 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/ReAuthメッセージがEMSKNAME-NAIに対応するRIKを持っているサーバーで発生することを証明するために、認証タグを含める必要があります。
o If the ERP exchange is successful, and the local ER server sent a DSRK request, the home ER server MUST include the DSRK for the local ER server (derived using the EMSK and the domain name as specified in [3]), EMSKname, and DSRK lifetime along with the EAP-Finish/Re-auth message.
o ERP Exchangeが成功し、ローカルERサーバーがDSRKリクエストを送信した場合、Home ERサーバーにはローカルERサーバーのDSRK（[3]で指定されているEMSKおよびドメイン名を使用して派生）、EMSKNAME、およびDSRKを含める必要があります。dsrk lifetimeとEAP-finish/reauthメッセージ。
o In addition, the rMSK is sent along with the EAP-Finish/Re-auth message, in a AAA attribute [12].
o さらに、RMSKは、AAA属性[12]で、EAPフィニッシュ/ReAuthメッセージとともに送信されます。
o The local ER server MUST extract the DSRK, EMSKname, and DSRK lifetime (if present), before forwarding the EAP-Finish/Re-auth message to the peer, as specified in [12].
o ローカルERサーバーは、[12]で指定されているように、EAP-finish/reauthメッセージをピアに転送する前に、暗い、emskname、および暗い寿命（存在する場合）を抽出する必要があります。
o The authenticator receives the rMSK.
o AuthenticatorはRMSKを受け取ります。
o When the peer receives an EAP-Finish/Re-auth message with the bootstrap flag set, if a local domain name is present, it MUST use that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName-NAI, and initialize the replay counter for the DS-rIK. If not, the peer SHOULD derive the domain-specific keys using the domain name it learned via the lower layer or from the EAP-Initiate/ Re-auth-Start message. If the peer does not know the domain name, it must assume that there is no local ER server available.
o ピアがブートストラップフラグセットを使用してEAP-finish/reauthメッセージを受信した場合、ローカルドメイン名が存在する場合、それを使用して適切なDSRK、DS-RRK、DS-RIK、およびKeyName-NAIを導き出す必要があります。DS-RIKのリプレイカウンターを初期化します。そうでない場合、ピアは、下層層またはEAPイナティエート/再起動メッセージから学習したドメイン名を使用してドメイン固有のキーを導出する必要があります。ピアがドメイン名を知らない場合、ローカルERサーバーが利用できないと仮定する必要があります。
o The peer MAY also verify the Authorization Indication TLV.
o ピアは、認証表示TLVを確認することもできます。
o The procedures for encapsulating the ERP and obtaining relevant keys using RADIUS and Diameter are specified in [12] and [15], respectively.
o ERPをカプセル化し、半径と直径を使用して関連キーを取得する手順は、それぞれ[12]と[15]で指定されています。
Since the ER bootstrapping exchange is typically done immediately following the full EAP exchange, it is feasible that the process is completed through the same entity that served as the EAP authenticator for the full EAP exchange. In this case, the lower layer may already have established TSKs based on the MSK received earlier. The lower layer may then choose to ignore the rMSK that was received with the ER bootstrapping exchange. Alternatively, the lower layer may choose to establish a new TSK using the rMSK. In either case, the authenticator and the peer know which key is used based on whether or not a TSK establishment exchange is initiated. The bootstrapping exchange may also be carried out via a new authenticator, in which case, the rMSK received SHOULD trigger a lower layer TSK establishment exchange.
ERブートストラップ交換は通常、完全なEAP交換の直後に行われるため、完全なEAP交換のEAP認証器として機能するのと同じエンティティを介してプロセスが完了することが可能です。この場合、下層は、以前に受信したMSKに基づいてすでにTSKを確立している可能性があります。下層は、ERブートストラップ交換で受信されたRMSKを無視することを選択できます。あるいは、下層は、RMSKを使用して新しいTSKを確立することを選択する場合があります。どちらの場合でも、AuthenticatorとPeerは、TSK設立交換が開始されるかどうかに基づいて使用されるキーを知っています。ブートストラップ交換は、新しい認証機を介して実行することもできます。その場合、受信したRMSKは下層TSK確立交換をトリガーするはずです。
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は通常、PEER開始の交換であり、EAPイナティエート/再オーースとEAPフィニッシュ/リアースメッセージで構成されています。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対応認証器は、EAPイテリア/再起動スタートメッセージを送信して、ERPのサポートを示す必要があります。ピアは、これらのメッセージが到着するのを待っている場合と、EAPイテリア/再オーースメッセージを開始する場合があります。
The EAP-Initiate/Re-auth-Start message SHOULD be sent by an ERP-capable authenticator. The authenticator may retransmit it a few times until it receives an EAP-Initiate/Re-auth message in response from the peer. The EAP-Initiate/Re-auth message from the peer may have originated before the peer receives either an EAP-Request/ Identity or an EAP-Initiate/Re-auth-Start message from the authenticator. Hence, the Identifier value in the EAP-Initiate/ Re-auth message is independent of the Identifier value in the EAP-Initiate/Re-auth-Start or the EAP-Request/Identity messages.
EAP Initiate/Reauth-Startメッセージは、ERP対応認証者によって送信される必要があります。Authenticatorは、ピアから応答してEAPイテリア/再オーースメッセージを受信するまで、数回再送信する場合があります。ピアからのEAPイテオテート/リオースメッセージは、ピアがEAP-Request/IdentityまたはAuthenticatorからEAP-Initiate/Reauth-Startメッセージのいずれかを受信する前に発生した可能性があります。したがって、EAP Initiate/ReAuthメッセージの識別子値は、EAPイテリア/ReAuth-StartまたはEAP-Request/IDメッセージの識別子値とは無関係です。
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では、PeerがEAP再認証メッセージの信頼できる輸送のために再送信タイマーを維持することを要求します。RFC 3748のセクション4.3の信頼性に関する考慮事項は、再送信エンティティとしてピアに適用されます。
The EAP Re-auth Protocol has the following steps:
EAP ReAuthプロトコルには次の手順があります。
The peer sends an EAP-Initiate/Re-auth message. At a minimum, the message SHALL include the following fields:
ピアは、EAPイテリア/再オーースメッセージを送信します。少なくとも、メッセージには次のフィールドが含まれます。
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.
TLV属性としてのKeyName-NAIは、メッセージを保護するために使用されるRIKを識別します。
cryptosuite to indicate the authentication algorithm used to compute the integrity checksum.
整合性チェックサムの計算に使用される認証アルゴリズムを示すCryptoSuite。
authentication tag over the message.
メッセージ上の認証タグ。
When the peer is performing ERP with a local ER server, it MUST use the corresponding DS-rIK it shares with the local ER server. The peer SHOULD set the lifetime flag to request the key lifetimes from the server. The peer can use the rRK lifetime to know when to trigger an EAP method exchange and the rMSK lifetime to know when to trigger another ERP exchange.
ピアがローカルERサーバーでERPを実行している場合、ローカルERサーバーと共有する対応するDS-RIKを使用する必要があります。ピアは、サーバーから重要なライフタイムを要求するために生涯フラグを設定する必要があります。ピアは、RRKライフタイムを使用して、EAPメソッド交換をいつトリガーするか、RMSK寿命を把握して、いつ別のERP交換をトリガーするかを知ることができます。
The authenticator copies the contents of the value field of the keyName-NAI TLV into the User-Name RADIUS attribute in the AAA message to the ER server.
Authenticatorは、KeyName-NAI TLVの値フィールドのコンテンツを、ERサーバーへのAAAメッセージのユーザー名RADIUS属性にコピーします。
The server uses the keyName-NAI to look up the rIK. It MUST first verify whether the sequence number is equal to or greater than the expected sequence number. If the server supports a sequence number window size greater than 1, it MUST verify whether the sequence number falls within the window and has not been received before. The server MUST then verify to ensure that the cryptosuite used by the peer is acceptable. The server then proceeds to verify the integrity of the message using the rIK, thereby verifying proof of possession of that key by the peer. If any of these verifications fail, the server MUST send an EAP-Finish/Re-auth message with the Result flag set to '1' (Failure). Please refer to Section 5.2.2 for details on failure handling. Otherwise, it MUST compute an rMSK from the rRK using the sequence number as the additional input to the key derivation.
サーバーはKeyName-NAIを使用してRIKを検索します。最初に、シーケンス番号が予想されるシーケンス番号と等しいかどうかを確認する必要があります。サーバーが1を超えるシーケンス番号ウィンドウサイズをサポートしている場合、シーケンス番号がウィンドウ内に収まるかどうかを確認する必要があり、以前に受信されていません。その後、サーバーは、ピアが使用する暗号化された暗号化が許容できることを確認するために確認する必要があります。次に、サーバーはRIKを使用してメッセージの整合性を検証し、それによりピアによるそのキーの所有の証明を検証します。これらの検証のいずれかが失敗した場合、サーバーは結果フラグが「1」（障害）に設定されたEAP-Finish/ReAuthメッセージを送信する必要があります。故障処理の詳細については、セクション5.2.2を参照してください。それ以外の場合、キー導入への追加の入力としてシーケンス番号を使用して、RRKからRMSKを計算する必要があります。
In response to a well-formed EAP Re-auth/Initiate message, the server MUST send an EAP-Finish/Re-auth message with the following considerations:
よく形成されたEAP reauth/initiateメッセージに応じて、サーバーは次の考慮事項でEAP-finish/reauthメッセージを送信する必要があります。
a 16-bit sequence number for replay protection, which MUST be the same as the received sequence number. The local copy of the sequence number MUST be incremented by 1. If the server supports multiple simultaneous ERP exchanges, it MUST instead update the sequence number window.
リプレイ保護のための16ビットシーケンス番号。これは、受信したシーケンス番号と同じでなければなりません。シーケンス番号のローカルコピーは、サーバーが複数の同時ERP交換をサポートする場合、代わりにシーケンス番号ウィンドウを更新する必要があります。
keyName-NAI as a TLV attribute to identify the rIK used to integrity protect the message.
TLV属性としてのKeyName-NAIは、メッセージを保護するために使用されるRIKを識別します。
cryptosuite to indicate the authentication algorithm used to compute the integrity checksum.
整合性チェックサムの計算に使用される認証アルゴリズムを示すCryptoSuite。
authentication tag over the message.
メッセージ上の認証タグ。
If the lifetime flag was set in the EAP-Initiate/Re-auth message, the ER server SHOULD include the rRK lifetime and the rMSK lifetime.
lifetimeフラグがEAPイテリア/再オーースメッセージに設定されている場合、ERサーバーにはRRK LifetimeとRMSK Lifetimeを含める必要があります。
The server transports the rMSK along with this message to the authenticator. The rMSK is transported in a manner similar to the MSK transport along with the EAP-Success message in a regular EAP exchange.
サーバーは、このメッセージとともにRMSKを認証機に輸送します。RMSKは、MSKトランスポートと同様の方法で輸送され、通常のEAP交換でEAP-SUCSESSメッセージが表示されます。
The peer looks up the sequence number to verify whether it is expecting an EAP-Finish/Re-auth message with that sequence number protected by the keyName-NAI. It then verifies the integrity of the message. If the verifications fail, the peer logs an error and stops the process; otherwise, it proceeds to the next step.
ピアは、シーケンス番号を調べて、KeyName-NAIによって保護されているシーケンス番号を使用してEAP-Finish/Reauthメッセージを期待しているかどうかを確認します。次に、メッセージの完全性を検証します。検証が失敗した場合、ピアはエラーを記録し、プロセスを停止します。それ以外の場合は、次のステップに進みます。
The peer uses the sequence number to compute the rMSK.
ピアはシーケンス番号を使用してRMSKを計算します。
The lower-layer security association protocol can be triggered at this point.
この時点で、低層セキュリティ協会のプロトコルをトリガーできます。
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イテリア/再オーースメッセージを拒否する可能性があることがもっともらしいです。
To facilitate such operation, an ER server MAY allow multiple simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth messages with SEQ number values within a window of allowed values. Recall that the SEQ number allows replay protection. Replay window maintenance mechanisms are a local matter.
このような操作を容易にするために、ERサーバーは、許可された値のウィンドウ内で配列数値を持つすべてのEAPイテリテート/ReAuthメッセージを受け入れることにより、複数の同時ERP交換を許可する場合があります。SEQ番号がリプレイ保護を可能にすることを思い出してください。リプレイウィンドウメンテナンスメカニズムはローカルな問題です。
If the processing of the EAP-Initiate/Re-auth message results in a failure, the ER server MUST send an EAP-Finish Re-auth message with the Result flag set to '1'. If the server has a valid rIK for the peer, it MUST integrity protect the EAP-Finish/Re-auth failure message. If the failure is due to an unacceptable cryptosuite, the server SHOULD send a list of acceptable cryptosuites (in a TLV of Type 5) along with the EAP-Finish/Re-auth message. In this case, the server MUST indicate the cryptosuite used to protect the EAP-Finish/ Re-auth message in the cryptosuite. The rIK used with the EAP-Finish/Re-auth message in this case MUST be computed as specified in Section 4.3 using the new cryptosuite. If the server does not have a valid rIK for the peer, the EAP-Finish/Re-auth message indicating a failure will be unauthenticated; the server MAY include a list of acceptable cryptosuites in the message.
EAP Initiate/ReAuthメッセージの処理が障害になる場合、ERサーバーは結果フラグを「1」に設定してEAP-FINISH REAUTHメッセージを送信する必要があります。サーバーがピアに対して有効なRIKを持っている場合、EAP-Finish/ReAuth障害メッセージを整合性保護する必要があります。障害が容認できない暗号化物によるものである場合、サーバーは、EAPフィニッシュ/ReAuthメッセージとともに、許容可能な暗号症（タイプ5のTLV）のリストを送信する必要があります。この場合、サーバーは、CryptoSuiteのEAPフィニッシュ/ ReAuthメッセージを保護するために使用される暗号化されたものを示す必要があります。この場合、EAP-finish/reauthメッセージで使用されるRIKは、新しいCryptoSuiteを使用してセクション4.3で指定されているように計算する必要があります。サーバーがピアに対して有効なRIKを持っていない場合、障害を示すEAP-FINISH/REAUTHメッセージは認識されません。サーバーには、メッセージに許容可能な暗号訴訟のリストが含まれる場合があります。
The peer, upon receiving an EAP-Finish/Re-auth message with the Result flag set to '1', MUST verify the sequence number and the Authentication Tag to determine the validity of the message. If the peer supports the cryptosuite, it MUST verify the integrity of the received EAP-Finish/Re-auth message. If the EAP-Finish message contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with a cryptosuite picked from the list included by the server. The peer MUST use the appropriate rIK for the subsequent ERP exchange, by computing it with the corresponding cryptosuite, as specified in Section 4.3. If the PRF in the chosen cryptosuite is different from the PRF originally used by the peer, it MUST derive a new DSRK (if required), rRK, and rIK before proceeding with the subsequent ERP exchange.
ピアは、結果フラグが「1」に設定されたEAP-FINISH/REAUTHメッセージを受信すると、メッセージの有効性を決定するためにシーケンス番号と認証タグを検証する必要があります。ピアがクリプトスイートをサポートしている場合、受信したEAPフィニッシュ/リオースメッセージの整合性を検証する必要があります。EAP-Finishメッセージにタイプ5のTLVが含まれている場合、ピアはサーバーに含まれるリストから選ばれたクリプトスイートでERP交換を再試行する必要があります。ピアは、セクション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 TLV of Type 5, after a failure has been clearly determined following the procedure in the next paragraph.
ピアが受信したメッセージの整合性を検証できない場合、次の段落の手順に従って障害が明確に決定された後、タイプ5のTLVの暗号化物の1つとERP交換を再試行することを選択できます。
If the replay or integrity checks fail, the failure message may have been sent by an attacker. It may also imply that the server and peer do not support the same cryptosuites; however, the peer cannot determine if that is the case. Hence, the peer SHOULD continue the ERP exchange per the retransmission timers before declaring a failure.
リプレイまたは整合性のチェックが失敗した場合、攻撃者によって失敗メッセージが送信された可能性があります。また、サーバーとピアが同じ暗号訴訟をサポートしていないことを意味する場合があります。ただし、ピアはそうであるかどうかを判断することはできません。したがって、ピアは、失敗を宣言する前に、再送信タイマーごとに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設立プロトコルを実行するものとします。
Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate and EAP-Finish. The packet format for these messages follows the EAP packet format defined in RFC 3748 [2].
ERPの目的で2つの新しいEAPコードが定義されています。EAPイテリアとEAPフィニッシュ。これらのメッセージのパケット形式は、RFC 3748 [2]で定義されているEAPパケット形式に従います。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: EAP Packet
図6：EAPパケット
Code
コード
5 Initiate
5開始
6 Finish
6フィニッシュ
Two new code values are defined for the purpose of ERP.
ERPの目的で2つの新しいコード値が定義されています。
Identifier
識別子
The Identifier field is one octet. The Identifier field MUST be the same if an EAP-Initiate packet is retransmitted due to a timeout while waiting for a Finish message. Any new (non-retransmission) Initiate message MUST use a new Identifier field.
識別子フィールドは1オクテットです。識別子フィールドは、フィニッシュメッセージを待っている間にタイムアウトのためにEAPイテリアパケットが再送信される場合と同じでなければなりません。新しい（非再送信）開始メッセージは、新しい識別子フィールドを使用する必要があります。
The Identifier field of the Finish message MUST match that of the currently outstanding Initiate message. A peer or authenticator receiving a Finish message whose Identifier value does not match that of the currently outstanding Initiate message MUST silently discard the packet.
フィニッシュメッセージの識別子フィールドは、現在未解決の開始メッセージの識別子と一致する必要があります。識別子値が現在顕著な開始メッセージの値と一致しない仕上げメッセージを受信するピアまたは認証者は、パケットを静かに破棄する必要があります。
In order to avoid confusion between new EAP-Initiate messages and retransmissions, the peer must choose an Identifier value that is different from the previous EAP-Initiate message, especially if that exchange has not finished. It is RECOMMENDED that the authenticator clear EAP Re-auth state after 300 seconds.
新しいEAPイテリアメッセージと再送信との間の混乱を避けるために、ピアは、特にその交換が終了していない場合、以前のEAPイテリアメッセージとは異なる識別子値を選択する必要があります。300秒後にAuthenticatorをクリアすることをお勧めします。
Type
タイプ
This field indicates that this is an ERP exchange. Two type values are defined in this document for this purpose -- Re-auth-Start (assigned Type 1) and Re-auth (assigned Type 2).
このフィールドは、これがERP交換であることを示しています。この目的のために、このドキュメントでは2つのタイプの値が定義されています - reauth-Start（タイプ1の割り当て）とreauth（割り当てられたタイプ2）。
Type-Data
タイプデータ
The Type-Data field varies with the Type of re-authentication packet.
タイプデータフィールドは、再認証パケットのタイプによって異なります。
The EAP-Initiate/Re-auth-Start packet contains the parameters shown in Figure 7.
EAP Initiate/Reauth-Startパケットには、図7に示すパラメーターが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: EAP-Initiate/Re-auth-Start Packet
図7：EAP Initiate/Reauth-Startパケット
Type = 1.
タイプ= 1。
Reserved, MUST be zero. Set to zero on transmission and ignored on reception.
予約されている、ゼロでなければなりません。トランスミッションでゼロに設定され、レセプションで無視されます。
One or more TVs or TLVs are used to convey information to the peer; for instance, the authenticator may send the domain name to the peer.
1つ以上のテレビまたはTLVを使用して、情報をピアに伝えるために使用されます。たとえば、Authenticatorはドメイン名をピアに送信する場合があります。
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.
TVSまたはTLVS：テレビのペイロードには、1オクター型のペイロードと、タイプ固有の長さの値があります。TLVペイロードには、1-OCTETタイプのペイロードと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 [4]. The Domain-Name attribute SHOULD be present in an EAP-Initiate/Re-auth-Start message.
ドメイン名：これはTLVペイロードです。タイプは4です。ドメイン名は、NAI [4]の領域として使用されます。ドメイン名の属性は、EAPイネティエート/ReAuth-Startメッセージに存在する必要があります。
In addition, channel binding information MAY be included; see Section 5.5 for discussion. See Figure 11 for parameter specification.
さらに、チャネル結合情報が含まれる場合があります。ディスカッションについては、セクション5.5を参照してください。パラメーター仕様については、図11を参照してください。
The authenticator MAY send the EAP-Initiate/Re-auth-Start message to indicate support for ERP to the peer and to initiate ERP if the peer has already performed full EAP authentication and has unexpired key material. The authenticator SHOULD include the domain name TLV to allow the peer to learn it without lower-layer support or the ERP bootstrapping exchange.
Authenticatorは、EAP Initiate/Reauth-Startメッセージを送信して、Peerがすでに完全なEAP認証を実行していて、期限切れになっていない重要な資料を持っている場合、ERPのサポートをピアに示し、ERPを開始する場合があります。認証機には、ドメイン名TLVを含めて、ピアが低層サポートまたはERPブートストラップ交換なしでそれを学習できるようにする必要があります。
The authenticator MAY include channel binding information so that the peer can send the information to the server in the EAP-Initiate/ Re-auth message so that the server can verify whether the authenticator is claiming the same identity to both parties.
認証機にはチャネルバインディング情報が含まれているため、ピアがEAP Initiate/ Reauthメッセージのサーバーに情報を送信できるように、サーバーが認証装置が両当事者に同じアイデンティティを主張しているかどうかを確認できるようにします。
The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start message a few times for reliable transport.
認証者は、信頼できる輸送のために、EAPイテリア/再起動スタートメッセージを数回再送信する場合があります。
The peer SHOULD send the EAP-Initiate/Re-auth message in response to the EAP-Initiate/Re-auth-Start message from the authenticator. If the peer does not recognize the Initiate code value, it silently discards the message. If the peer has already sent the EAP-Initiate/ Re-auth message to begin the ERP exchange, it silently discards the message.
ピアは、AuthenticatorからのEAPイテリア/ReAuthスタートメッセージに応じて、EAPイテリア/ReAuthメッセージを送信する必要があります。ピアが開始コード値を認識していない場合、メッセージを静かに破棄します。ピアが既にEAPイナティエート/再オーースメッセージを送信してERP Exchangeを開始している場合、メッセージを静かに破棄します。
If the EAP-Initiate/Re-auth-Start message contains the domain name, and if the peer does not already have the domain information, the peer SHOULD use the domain name to compute the DSRK and use the corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start an ERP exchange with the local ER server. If the peer has already initiated an ERP exchange with the home ER server, it MAY choose to not start an ERP exchange with the local ER server.
EAP Initiate/Reauth-Startメッセージにドメイン名が含まれており、ピアがドメイン情報をまだ持っていない場合、ピアはドメイン名を使用してDSRKを計算し、対応するDS-RIKを使用して使用して送信してローカルERサーバーとのERP交換を開始するためのEAPイテオテート/ReAuthメッセージ。ピアがすでにHome ERサーバーとのERP交換を開始している場合、ローカルERサーバーとのERP交換を開始しないことを選択できます。
The EAP-Initiate/Re-auth packet contains the parameters shown in Figure 8.
EAP Initiate/Reauthパケットには、図8に示すパラメーターが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|B|L| Reserved| SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: EAP-Initiate/Re-auth Packet
図8：EAP Initiate/Reauthパケット
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 rest of the 5 bits are set to 0 and ignored on reception.
5ビットの残りの部分は0に設定されており、レセプションでは無視されます。
SEQ: A 16-bit sequence number is used for replay protection. The SEQ number field is initialized to 0 every time a new rRK is derived.
SEQ：16ビットシーケンス番号は、リプレイ保護に使用されます。新しいRRKが導出されるたびに、SEQ番号フィールドは0に初期化されます。
TVs or TLVs: In the TV payloads, there is a 1-octet type payload and a value with type-specific length. In the TLV payloads, there is a 1-octet type payload and a 1-octet length payload. The length field indicates the length of the value expressed in number of octets.
TVSまたはTLVS：テレビのペイロードには、1オクター型のペイロードと、タイプ固有の長さの値があります。TLVペイロードには、1-OCTETタイプのペイロードと1オクテットの長さのペイロードがあります。長さフィールドは、オクテット数で表される値の長さを示します。
keyName-NAI: This is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. The EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64 bits in length and so the username portion takes up 128 octets. If the rIK is derived from the EMSK, the realm part of the NAI is the home domain name, and if the rIK is derived from a DSRK, the realm part of the NAI is the domain name used in the derivation of the DSRK. The NAI syntax follows [4]. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet.
KeyName-NAI：これはTLVペイロードで運ばれます。タイプは1です。NAIの長さは可変であり、253オクテットを超えていません。EMSKNAMEはNAIのユーザー名部分にあり、16進値でエンコードされています。EMSKNAMEの長さは64ビットなので、ユーザー名の部分は128オクテットを占有します。RIKがEMSKから派生している場合、NAIの領域部分はホームドメイン名であり、RIKがDSRKに由来する場合、NAIの領域部分はDSRKの派生に使用されるドメイン名です。NAI構文は続きます[4]。正確に1つのKeyName-NAI属性がEAPイテリア/ReAuthパケットに存在するものとします。
In addition, channel binding information MAY be included; see Section 5.5 for discussion. See Figure 11 for parameter specification.
さらに、チャネル結合情報が含まれる場合があります。ディスカッションについては、セクション5.5を参照してください。パラメーター仕様については、図11を参照してください。
Cryptosuite: This field indicates the integrity algorithm used for ERP. Key lengths and output lengths are either indicated or are obvious from the cryptosuite name. We specify some cryptosuites below:
CryptoSuite：このフィールドは、ERPに使用される整合性アルゴリズムを示します。キーの長さと出力の長さは、暗号化された名前から表示されるか、明らかです。以下にいくつかのクリプトスーツを指定します。
* 0 RESERVED
* 0予約
* 1 HMAC-SHA256-64
* 1 HMAC-SHA256-64
* 2 HMAC-SHA256-128
* 2 HMAC-SHA256-128
* 3 HMAC-SHA256-256
* 3 HMAC-SHA256-256
HMAC-SHA256-128 is mandatory to implement and should be enabled in the default configuration.
HMAC-SHA256-128は実装に必須であり、デフォルトの構成で有効にする必要があります。
Authentication Tag: This field contains the integrity checksum over the ERP packet, excluding the authentication tag field itself. The length of the field is indicated by the Cryptosuite.
認証タグ：このフィールドには、認証タグフィールド自体を除く、ERPパケット上の整合性チェックサムが含まれています。フィールドの長さは、クリプトスイートによって示されます。
The EAP-Finish/Re-auth packet contains the parameters shown in Figure 9.
EAP-Finish/ReAuthパケットには、図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-Finish/Re-auth Packet
図9：EAP-FINISH/REAUTHパケット
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 rest of the 5 bits are set to 0 and ignored on reception.
5ビットの残りの部分は0に設定されており、レセプションでは無視されます。
SEQ: A 16-bit sequence number is used for replay protection. The SEQ number field is initialized to 0 every time a new rRK is derived.
SEQ：16ビットシーケンス番号は、リプレイ保護に使用されます。新しいRRKが導出されるたびに、SEQ番号フィールドは0に初期化されます。
TVs or TLVs: In the TV payloads, there is a 1-octet type payload and a value with type-specific length. In the TLV payloads, there is a 1-octet type payload and a 1-octet length payload. The length field indicates the length of the value expressed in number of octets.
TVSまたはTLVS：テレビのペイロードには、1オクター型のペイロードと、タイプ固有の長さの値があります。TLVペイロードには、1-OCTETタイプのペイロードと1オクテットの長さのペイロードがあります。長さフィールドは、オクテット数で表される値の長さを示します。
keyName-NAI: This is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64 bits in length and so the username portion takes up 16 octets. If the rIK is derived from the EMSK, the realm part of the NAI is the home domain name, and if the rIK is derived from a DSRK, the realm part of the NAI is the domain name used in the derivation of the DSRK. The NAI syntax follows [4]. Exactly one instance of the keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth message.
KeyName-NAI：これはTLVペイロードで運ばれます。タイプは1です。NAIの長さは可変であり、253オクテットを超えていません。emsknameはNAIのユーザー名部分にあり、16進数でエンコードされています。EMSKNAMEの長さは64ビットなので、ユーザー名部分は16オクテットを占有します。RIKがEMSKから派生している場合、NAIの領域部分はホームドメイン名であり、RIKがDSRKに由来する場合、NAIの領域部分はDSRKの派生に使用されるドメイン名です。NAI構文は続きます[4]。KeyName-NAI属性の1つのインスタンスは、EAP-Finish/Reauthメッセージに存在するものとします。
rRK Lifetime: This is a TV payload. The Type is 2. The value field is a 32-bit field and contains the lifetime of the rRK in seconds. If the 'L' flag is set, the rRK Lifetime attribute SHOULD be present.
RRK Lifetime：これはテレビのペイロードです。タイプは2です。値フィールドは32ビットフィールドで、秒単位でRRKの寿命が含まれています。「L」フラグが設定されている場合、RRK Lifetime属性が存在するはずです。
rMSK Lifetime: This is a TV payload. The Type is 3. The value field is a 32-bit field and contains the lifetime of the rMSK in seconds. If the 'L' flag is set, the rMSK Lifetime attribute SHOULD be present.
rmsk lifetime：これはテレビのペイロードです。タイプは3です。値フィールドは32ビットフィールドで、秒単位でRMSKの寿命が含まれています。「L」フラグが設定されている場合、RMSKライフタイム属性が存在するはずです。
Domain-Name: This is a TLV payload. The Type is 4. The domain name is to be used as the realm in an NAI [4]. Domain-Name attribute MUST be present in an EAP-Finish/Re-auth message if the bootstrapping flag is set and if the local ER server sent a DSRK request.
ドメイン名：これはTLVペイロードです。タイプは4です。ドメイン名は、NAI [4]の領域として使用されます。ブートストラップフラグが設定されている場合、およびローカルERサーバーがDSRKリクエストを送信した場合、ドメイン名属性はEAP-finish/reauthメッセージに存在する必要があります。
List of cryptosuites: This is a TLV payload. The Type is 5. The value field contains a list of cryptosuites, each of size 1 octet. The cryptosuite values are as specified in Figure 8. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Re-auth message was not acceptable and the message is being rejected. The server MAY include this attribute in other cases. The server MAY use this attribute to signal to the peer about its cryptographic algorithm capabilities.
クリプトスイートのリスト：これはTLVペイロードです。タイプは5です。値フィールドには、サイズ1オクテットのそれぞれのクリプトスーツのリストが含まれています。CryptoSuite値は、図8に指定されているとおりです。EAPイナティエート/ReAuthメッセージで使用されている暗号化された装備が受け入れられず、メッセージが拒否されている場合、サーバーにはこの属性を含める必要があります。サーバーには、他の場合にこの属性を含めることができます。サーバーは、この属性を使用して、暗号化アルゴリズム機能についてピアに信号を送ることができます。
Authorization Indication: This is a TLV payload. The Type is 6. This attribute MAY be included in the EAP-Finish/Re-auth message when a DSRK is delivered to a local ER server and if the home ER server can verify the authorization of the local ER server to advertise the domain name included in the domain TLV in the same message. The value field in the TLV contains an authentication tag computed over the entire packet, starting from the first bit of the code field to the last bit of the cryptosuite field, with the value field of the Authorization Indication TLV filled with all 0s for the computation. The key used for the computation MUST be derived from the EMSK with key label "DSRK Delivery Authorized Key@ietf.org" and optional data containing an ASCII string representing the key management domain that the DSRK is being derived for.
承認兆候：これはTLVペイロードです。タイプは6です。この属性は、DSRKがローカルERサーバーに配信され、ホームERサーバーがローカルERサーバーの承認を確認してドメイン名を宣伝できる場合、EAP-finish/reauthメッセージに含めることができます。同じメッセージにドメインTLVに含まれています。TLVの値フィールドには、パケット全体で計算された認証タグが含まれています。コードフィールドの最初のビットからCryptoSuiteフィールドの最後のビットまで、認証表示の値フィールドは、計算のすべての0で満たされています。。計算に使用されるキーは、キーラベル「DSRK配信認定Key@ietf.org」を備えたEMSKから派生し、DSRKが導出されているキー管理ドメインを表すASCII文字列を含むオプションのデータを導き出す必要があります。
In addition, channel binding information MAY be included: see Section 5.5 for discussion. See Figure 11 for parameter specification. The server sends this information so that the peer can verify the information seen at the lower layer, if channel binding is to be supported.
さらに、チャネルバインディング情報を含めることができます。ディスカッションについては、セクション5.5を参照してください。パラメーター仕様については、図11を参照してください。サーバーは、チャネルバインディングがサポートされる場合、ピアが下層で見られる情報を確認できるように、この情報を送信します。
Cryptosuite: This field indicates the integrity algorithm and the PRF used for ERP. Key lengths and output lengths are either indicated or are obvious from the cryptosuite name.
CryptoSuite：このフィールドは、ERPに使用される整合性アルゴリズムとPRFを示します。キーの長さと出力の長さは、暗号化された名前から表示されるか、明らかです。
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イテリアまたはEAPフィニッシュメッセージに存在する可能性のあるテレビ属性は、次の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TV Attribute Format
図10：TV属性形式
The TLV attributes that may be present in the EAP-Initiate or EAP-Finish messages are of the following format:
EAPイテリアまたはEAPフィニッシュメッセージに存在する可能性のあるTLV属性は、次の形式です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TLV Attribute Format
図11：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 Lifetime：これはテレビのペイロードです。
'3' - rMSK Lifetime: This is a TV payload.
'3' -RMSKライフタイム：これはテレビのペイロードです。
'4' - domain name: This is a TLV payload.
'4' - ドメイン名：これはTLVペイロードです。
'5' - cryptosuite list: This is a TLV payload.
'5' -CryptoSuiteリスト：これはTLVペイロードです。
'6' - Authorization Indication: This is a TLV payload.
'6' - 承認指示：これはTLVペイロードです。
The TLV type range of 128-191 is reserved to carry channel binding information in the EAP-Initiate and Finish/Re-auth messages. Below are the current assignments (all of them are TLVs):
128-191のTLVタイプの範囲は、EAPイテリアおよび仕上げ/再オーースメッセージにチャネルバインディング情報を運ぶために予約されています。以下は現在の割り当てです（それらはすべてTLVです）：
'128' - Called-Station-Id [13]
'128 '-Station-idと呼ばれる[13]
'129' - Calling-Station-Id [13]
'129 '-Calling-Station-ID [13]
'130' - NAS-Identifier [13]
'130 ' -Nas -Identifier [13]
'131' - NAS-IP-Address [13]
'131 '-Nas-IP-Address [13]
'132' - NAS-IPv6-Address [16]
'132 '-NAS-IPV6-アドレス[16]
The length field indicates the length of the value part of the attribute in octets.
長さフィールドは、オクテットの属性の値部分の長さを示します。
For replay protection, ERP uses sequence numbers. The sequence number is maintained per rIK and is initialized to zero in both directions. In the first EAP-Initiate/Re-auth message, the peer uses the sequence number zero or higher. Note that the when the sequence number rotates, the rIK MUST be changed by running EAP authentication. The server expects a sequence number of zero or higher. When the server receives an EAP-Initiate/Re-auth message, it uses the same sequence number in the EAP-Finish/Re-auth message. The server then sets the expected sequence number to the received sequence number plus 1. The server accepts sequence numbers greater than or equal to the expected sequence number.
リプレイ保護のために、ERPはシーケンス番号を使用します。シーケンス番号はRIKごとに維持され、両方向でゼロに初期化されます。最初のEAPイテオテート/ReAuthメッセージでは、ピアはシーケンス番号ゼロ以下を使用します。シーケンス番号が回転するとき、EAP認証を実行してRIKを変更する必要があることに注意してください。サーバーは、ゼロ以上のシーケンス数を期待しています。サーバーがEAP Initiate/ReAuthメッセージを受信すると、EAP-Finish/ReAuthメッセージで同じシーケンス番号を使用します。サーバーは、予想されるシーケンス番号を受信したシーケンス番号プラス1に設定します。サーバーは、予想されるシーケンス番号以下のシーケンス番号を受け入れます。
If the peer sends an EAP-Initiate/Re-auth message, but does not receive a response, it retransmits the request (with no changes to the message itself) a pre-configured number of times before giving up. However, it is plausible that the server itself may have responded to the message and it was lost in transit. Thus, the peer MUST increment the sequence number and use the new sequence number to send subsequent EAP re-authentication messages. The peer SHOULD increment the sequence number by 1; however, it may choose to increment by a larger number. When the sequence number rotates, the peer MUST run full EAP authentication.
ピアがEAPイナティエート/再オーースメッセージを送信したが、応答を受け取らない場合、あきらめる前に事前に構成された回数をリクエスト（メッセージ自体に変更なしで）再送信します。ただし、サーバー自体がメッセージに応答した可能性があり、輸送中に失われた可能性があります。したがって、ピアはシーケンス番号を増やし、新しいシーケンス番号を使用して、後続のEAP再認証メッセージを送信する必要があります。ピアは、シーケンス番号を1で増やす必要があります。ただし、より多くの数で増加することを選択できます。シーケンス番号が回転すると、ピアは完全なEAP認証を実行する必要があります。
ERP provides a protected facility to carry channel binding (CB) information, according to the guidelines in Section 7.15 of [2]. The TLV type range of 128-191 is reserved to carry CB information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages. Called-Station-Id, Calling-Station-Id, NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address are some examples of channel binding information listed in RFC 3748, and they are assigned values 128-132. Additional values are IANA managed based on IETF Consensus [17].
ERPは、[2]のセクション7.15のガイドラインに従って、チャネル結合（CB）情報を運ぶための保護された施設を提供します。128-191のTLVタイプの範囲は、EAPイナティエート/ReAuthおよびEAP-FINISH/REAUTHメッセージにCB情報を携帯するために予約されています。Station-ID、Calling-Station-ID、NAS-ID-IDINTIFIER、NAS-IP-ADDRESS、およびNAS-IPV6-ADDRESSと呼ばれることは、RFC 3748にリストされているチャネル結合情報の例であり、値128-132に割り当てられています。追加の値は、IETFコンセンサスに基づいてIANAが管理します[17]。
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.
Authenticatorは、EAP Initiate/ReAuth-Startメッセージを介してCB情報をピアに提供する場合があります。ピアは、EAP Initiate/Reauthメッセージのサーバーに情報を送信します。サーバーは、AAA属性を介して利用可能な認証機のアイデンティティがピアに提供された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/ ReAuthメッセージにCB情報を含めない場合、およびローカルERサーバーのポリシーにチャネルバインディングサポートが必要な場合、ピアの検証にCB属性を送信するものとします。ピアは、認証器がCBパラメーターを送信した場合にCB情報の検証を試み、属性が一致する場合、低層セキュリティ協会の確立で進行します。それ以外の場合、ピアは下層セキュリティ協会の施設を進めてはなりません。
The authenticator is responsible for retransmission of EAP-Initiate/ Re-auth-Start messages. The authenticator MAY retransmit the message a few times or until it receives an EAP-Initiate/Re-auth message from the peer. The authenticator may not know whether the peer supports ERP; in those cases, the peer may be silently dropping the EAP-Initiate/Re-auth-Start packets. Thus, retransmission of these packets should be kept to a minimum. The exact number is up to each lower layer.
Authenticatorは、EAP Initiate/ Reauth-Startメッセージの再送信を担当します。Authenticatorは、メッセージを数回、またはPeerからEAP Initiate/Reauthメッセージを受信するまで再送信する場合があります。認証者は、ピアがERPをサポートするかどうかを知らないかもしれません。そのような場合、ピアは静かにEAPイナティエート/再起動スタートパケットをドロップしている可能性があります。したがって、これらのパケットの再送信は最小限に抑える必要があります。正確な数は、各下層までです。
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/ReAuthパケットの識別子値は、EAPイテリア/ReAuth-Startパケットの識別子値とは無関係です。
The peer is responsible for retransmission of EAP-Initiate/Re-auth messages.
ピアは、EAP Initiate/ReAuthメッセージの再送信を担当します。
Retransmitted packets MUST be sent with the same Identifier value in order to distinguish them from new packets. By default, where the EAP-Initiate message is sent over an unreliable lower layer, the retransmission timer SHOULD be dynamically estimated. A maximum of 3-5 retransmissions is suggested (this is based on the recommendation of [2]). Where the EAP-Initiate message is sent over a reliable lower layer, the retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer. Please refer to RFC 3748 [2] for additional guidance on setting timers.
再送信されたパケットは、新しいパケットと区別するために、同じ識別子値で送信する必要があります。デフォルトでは、EAPイテリアメッセージが信頼できない下層層で送信される場合、再送信タイマーを動的に推定する必要があります。最大3〜5回の再送信が提案されています（これは[2]の推奨に基づいています）。EAPイテリアメッセージが信頼できる下層層で送信される場合、再送信タイマーは無限の値に設定する必要があります。そうすれば、EAP層で再送信が発生しないようにします。タイマーの設定に関する追加ガイダンスについては、RFC 3748 [2]を参照してください。
The Identifier value in the EAP-Finish/Re-auth packet is the same as the Identifier value in the EAP-Initiate/Re-auth packet.
EAP-Finish/ReAuthパケットの識別子値は、EAP Initiate/ReAuthパケットの識別子値と同じです。
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.
Authenticatorが有効な重複したEAP Initiate/ReAuthメッセージを受信している場合、EAP-Finish/ReAuthメッセージを送信した場合、EAPイニティエート/再処理せずにEAP-FINISH/REAUTHメッセージを再送信する必要があります。Reauthメッセージ。これを容易にするために、AuthenticatorはEAP-Finish/Reauthメッセージのコピーを有限の時間で保存するものとします。時間の実際の価値はローカルな問題です。この仕様では、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, the IEEE802.1x specification must be revised to allow carrying EAP messages of the new codes defined in this document in order to support ERP. Similarly, RFC 4306 must be updated to include EAP code values higher than 4 in order to use ERP with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may also be updated to support peer-initiated ERP for optimized operation. Other lower layers may need similar revisions.
ERPをサポートするには、低層の仕様を改訂する必要がある場合があることに注意してください。具体的には、ERPをサポートするために、このドキュメントで定義されている新しいコードのEAPメッセージを運ぶことができるように、IEEE802.1x仕様を修正する必要があります。同様に、RFC 4306を更新して、ERPをインターネットキーエクスチェンジプロトコルバージョン2（IKEV2）で使用するために、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; peers may learn whether an authenticator supports ERP via configuration, from advertisements at the lower layer.
私たちの分析は、一部のEAP実装は、4を超えるコード値でEAPパケットを静かに削除する代わりに、それをエラーと見なすかもしれないという点でRFC 3748に準拠していないことを示しています。このような非準拠EAP実装に対応するために、追加のガイダンスが以下に提供されています。さらに、場合によってはすべてのピアをアップグレードするのは簡単ではないかもしれません。そのような場合、認証器は、EAPイテリア/再起動を送信しないように構成されている場合があります。ピアは、認証機が下層の広告から、構成を介してERPをサポートするかどうかを学ぶことができます。
In order to accommodate implementations that are not compliant to RFC 3748, such lower layers SHOULD ensure that both parties support ERP; this is trivial for an instance when using a lower layer that is known to always support ERP. For lower layers where ERP support is not guaranteed, ERP support may be indicated through signaling (e.g., piggy-backed on a beacon) or through negotiation. Alternatively, clients may recognize environments where ERP is available based on pre-configuration. Other similar mechanisms may also be used. When ERP support cannot be verified, lower layers may mandate falling back to full EAP authentication to accommodate EAP implementations that are not compliant to RFC 3748.
RFC 3748に準拠していない実装に対応するために、このような下層層は、両当事者がERPをサポートすることを保証する必要があります。これは、ERPを常にサポートすることが知られている下層を使用する場合のインスタンスにとって簡単です。ERPサポートが保証されていない下層層の場合、ERPサポートは、シグナリング（たとえば、ビーコンでピギーバック）またはネゴシエーションによって示される場合があります。あるいは、クライアントは、事前構成に基づいてERPが利用可能な環境を認識する場合があります。他の同様のメカニズムも使用できます。ERPサポートを検証できない場合、下層層は、RFC 3748に準拠していないEAP実装に対応するために、完全なEAP認証に戻ることを義務付けている可能性があります。
AAA Transport of ERP messages is specified in [11] and [12].
ERPメッセージのAAA輸送は、[11]および[12]で指定されています。
This section provides an analysis of the protocol in accordance with the AAA key management requirements specified in [18].
このセクションでは、[18]で指定されたAAAキー管理要件に従って、プロトコルの分析を提供します。
Cryptographic algorithm independence
暗号化アルゴリズムの独立性
The EAP Re-auth Protocol satisfies this requirement. The algorithm chosen by the peer for the MAC generation is indicated in the EAP-Initiate/Re-auth message. If the chosen algorithm is unacceptable, the EAP server returns an EAP-Finish/Re-auth message with Failure indication. Algorithm agility for the KDF is specified in [3]. Only when the algorithms used are acceptable, the server proceeds with derivation of keys and verification of the proof of possession of relevant keying material by the peer. A full-blown negotiation of algorithms cannot be provided in a single round trip protocol. Hence, while the protocol provides algorithm agility, it does not provide true negotiation.
EAP ReAuthプロトコルは、この要件を満たしています。MAC世代のピアによって選択されたアルゴリズムは、EAPイテリア/ReAuthメッセージに示されています。選択したアルゴリズムが受け入れられない場合、EAPサーバーは障害指示を伴うEAPフィニッシュ/ReAuthメッセージを返します。KDFのアルゴリズムの俊敏性は[3]で指定されています。使用されたアルゴリズムが許容できる場合にのみ、サーバーはキーの導出と、ピアによる関連キーイングの所持の証明の検証とともに進みます。アルゴリズムの本格的な交渉は、1回の往復プロトコルでは提供できません。したがって、プロトコルはアルゴリズムの俊敏性を提供しますが、真の交渉は提供されません。
Strong, fresh session keys
強く、新鮮なセッションキー
ERP results in the derivation of strong, fresh keys that are unique for the given session. An rMSK is always derived on-demand when the peer requires a key with a new authenticator. The derivation ensures that the compromise of one rMSK does not result in the compromise of a different rMSK at any time.
ERPは、指定されたセッションにユニークな強力で新鮮なキーの導出をもたらします。RMSKは、ピアが新しい認証器を使用してキーを必要とする場合、常にオンデマンドで導出されます。派生により、1つのRMSKの妥協がいつでも異なるRMSKの妥協をもたらさないことが保証されます。
Limit key scope
キースコープを制限します
The scope of all the keys derived by ERP is well defined. The rRK and rIK are never shared with any entity and always remain on the peer and the server. The rMSK is provided only to the authenticator through which the peer performs the ERP exchange. No other authenticator is authorized to use that rMSK.
ERPによって導出されたすべてのキーの範囲は、明確に定義されています。RRKとRIKは、エンティティと共有されることはなく、常にピアとサーバーに留まります。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 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つに設定し、メッセージに応答します。
Authenticate all parties
すべての関係者を認証します
The EAP Re-auth Protocol provides mutual authentication of the peer and the server. Both parties need to possess the keying material that resulted from a previous EAP exchange in order to successfully derive the required keys. Also, both the EAP re-authentication Response and the EAP re-authentication Information messages are integrity protected so that the peer and the server can verify each other. When the ERP exchange is executed with a local ER server, the peer and the local server mutually authenticate each other via that exchange in the same manner. The peer and the authenticator authenticate each other in the secure association protocol executed by the lower layer, just as in the case of a regular EAP exchange.
EAP ReAuthプロトコルは、ピアとサーバーの相互認証を提供します。両当事者は、必要なキーをうまく導き出すために、以前のEAP交換から生じるキーイング材料を所有する必要があります。また、EAPの再認証応答とEAP再認定情報メッセージの両方が整合性保護されているため、ピアとサーバーが互いに検証できるようになります。ERP交換がローカルERサーバーで実行されると、ピアとローカルサーバーは、同じ方法でその交換を介して相互に認証されます。ピアと認証者は、通常のEAP交換の場合と同様に、下層によって実行される安全な関連プロトコルで互いに認証されます。
Peer and authenticator authorization
ピアおよび認証者の承認
The peer and authenticator demonstrate possession of the same key material without disclosing it, as part of the lower-layer secure association protocol. Channel binding with ERP may be used to verify consistency of the identities exchanged, when the identities used in the lower layer differ from that exchanged within the AAA protocol.
ピアと認証者は、低層セキュアーアソシエーションプロトコルの一部として、それを開示せずに同じ重要な資料を所有していることを示しています。ERPとのチャネル結合を使用して、下層で使用されているアイデンティティがAAAプロトコル内で交換されたアイデンティティと異なる場合、交換されるアイデンティティの一貫性を検証することができます。
Keying material confidentiality
キーイングマテリアルの機密性
The peer and the server derive the keys independently using parameters known to each entity. The AAA server sends the DSRK of a domain to the corresponding local ER server via the AAA protocol. Likewise, the ER server sends the rMSK to the authenticator via the AAA protocol.
ピアとサーバーは、各エンティティで既知のパラメーターを使用して、キーを個別に導き出します。AAAサーバーは、AAAプロトコルを介してドメインのDSRKを対応するローカルERサーバーに送信します。同様に、ERサーバーはAAAプロトコルを介してRMSKを認証機に送信します。
Note that compromise of the DSRK results in compromise of all keys derived from it. Moreover, there is no forward secrecy within ERP. Thus, compromise of an DSRK retroactively compromises all ERP keys.
DSRKの妥協は、そこから派生したすべてのキーの妥協をもたらすことに注意してください。さらに、ERP内には前向きな秘密はありません。したがって、DSRKの妥協は、すべてのERPキーを遡及的に損ないます。
It is RECOMMENDED that the AAA protocol be protected using IPsec or TLS so that the keys are protected in transit. Note, however, that keys may be exposed to AAA proxies along the way and compromise of any of those proxies may result in compromise of keys being transported through them.
キーが輸送中に保護されるように、IPSECまたはTLSを使用してAAAプロトコルを保護することをお勧めします。ただし、キーは途中でAAAプロキシにさらされている可能性があり、これらのプロキシのいずれかを妥協する可能性があることに注意してください。
The home ER server MUST NOT hand out a given DSRK to a local domain server more than once, unless it can verify that the entity receiving the DSRK after the first time is the same as that received the DSRK originally. If the home ER server verifies authorization of a local domain server, it MAY hand out the DSRK to that domain more than once. In this case, the home ER server includes the Authorization Indication TLV to assure the peer that DSRK delivery is secure.
Home ERサーバーは、最初にDSRKを受け取った後にDSRKを受信したエンティティが元々DSRKを受け取ったものと同じであることを確認できない限り、特定のDSRKをローカルドメインサーバーに複数回配布してはなりません。Home ERサーバーがローカルドメインサーバーの承認を検証した場合、DSRKをそのドメインに複数回配る可能性があります。この場合、Home ERサーバーには、DSRKの配信が安全であることをピアに保証するための承認表示TLVが含まれています。
Confirm cryptosuite selection
暗号化された選択の選択を確認します
Crypto algorithms for integrity and key derivation in the context of ERP MAY be the same as that used by the EAP method. In that case, the EAP method is responsible for confirming the cryptosuite selection. Furthermore, the cryptosuite is included in the ERP exchange by the peer and confirmed by the server. The protocol allows the server to reject the cryptosuite selected by the peer and provide alternatives. When a suitable rIK is not available for the peer, the alternatives may be sent in an unprotected fashion. The peer is allowed to retry the exchange using one of the allowed cryptosuites. However, in this case, any en route modifications to the list sent by the server will go undetected. If the server does have an rIK available for the peer, the list will be provided in a protected manner and this issue does not apply.
ERPのコンテキストでの整合性とキー導出のための暗号アルゴリズムは、EAPメソッドで使用されているものと同じである場合があります。その場合、EAPメソッドは、暗号化された選択の選択を確認する責任があります。さらに、クリプトスイートはピアによってERP交換に含まれ、サーバーによって確認されます。このプロトコルにより、サーバーはピアによって選択された暗号化物を拒否し、代替案を提供できます。適切なRIKがピアに利用できない場合、代替案は保護されていない方法で送信される場合があります。ピアは、許可された暗号訴訟の1つを使用して交換を再試行することが許可されています。ただし、この場合、サーバーが送信したリストの途中の変更は、検出されません。サーバーにピアが利用できるRIKがある場合、リストは保護された方法で提供され、この問題は適用されません。
Uniquely named keys
ユニークな名前のキー
All keys produced within the ERP context can be referred to uniquely as specified in this document. Also, the key names do not reveal any part of the keying material.
ERPコンテキスト内で生成されたすべてのキーは、このドキュメントで指定されているように一意に参照できます。また、キー名はキーイング素材の一部を明らかにしていません。
Prevent the domino effect
ドミノ効果を防ぎます
The compromise of one peer does not result in the compromise of keying material held by any other peer in the system. Also, the rMSK is meant for a single authenticator and is not shared with any other authenticator. Hence, the compromise of one authenticator does not lead to the compromise of sessions or keys held by any other authenticator in the system. Hence, the EAP Re-auth Protocol allows prevention of the domino effect by appropriately defining key scope.
1つのピアの妥協は、システム内の他のピアが保持するキーイング素材の妥協をもたらさない。また、RMSKは単一の認証機を対象としており、他の認証機と共有されていません。したがって、1つの認証器の妥協は、システム内の他の認証者が保有するセッションやキーの妥協につながることはありません。したがって、EAP ReAuthプロトコルは、キースコープを適切に定義することにより、ドミノ効果の防止を可能にします。
However, if keys are transported using hop-by-hop protection, compromise of a proxy may result in compromise of key material, i.e., the DSRK being sent to a local ER server.
ただし、ホップバイホップ保護を使用してキーが輸送される場合、プロキシの妥協により、キーマテリアル、つまりDSRKがローカルERサーバーに送信される可能性があります。
Bind key to its context
キーをそのコンテキストにバインドします
All the keys derived for ERP are bound to the appropriate context using appropriate key labels. Lifetime of a child key is less than or equal to that of its parent key as specified in RFC 4962 [18]. The key usage, lifetime and the parties that have access to the keys are specified.
ERPのために派生したすべてのキーは、適切なキーラベルを使用して適切なコンテキストにバインドされています。子キーの寿命は、RFC 4962 [18]で指定されている親キーの寿命以下です。キーの使用、生涯、およびキーにアクセスできるパーティーが指定されています。
Confidentiality of identity
アイデンティティの機密性
Deployments where privacy is a concern may find the use of rIKname-NAI to route ERP messages serves their privacy requirements. Note that it is plausible to associate multiple runs of ERP messages since the rIKname is not changed as part of the ERP protocol. There was no consensus for that requirement at the time of development of this specification. If the rIKname is not used and the Peer-ID is used instead, the ERP exchange will reveal the Peer-ID over the wire.
プライバシーが懸念される展開は、rikname-naiを使用してERPメッセージをルーティングすることがプライバシー要件に役立つことがわかります。riknameはERPプロトコルの一部として変更されていないため、ERPメッセージの複数の実行を関連付けることはもっともらしいことに注意してください。この仕様の開発時にその要件についてコンセンサスはありませんでした。Riknameが使用されず、代わりにPeer-IDが使用されている場合、ERP Exchangeはワイヤー上でPeer-IDを明らかにします。
Authorization restriction
許可制限
All the keys derived are limited in lifetime by that of the parent key or by server policy. Any domain-specific keys are further restricted for use only in the domain for which the keys are derived. All the keys specified in this document are meant for use in ERP only. Any other restrictions of session keys may be imposed by the specific lower layer and are out of scope for this specification.
派生したすべてのキーは、親キーのキーまたはサーバーポリシーによって寿命が限られています。ドメイン固有のキーは、キーが導出されるドメインでのみ使用するためにさらに制限されています。このドキュメントで指定されているすべてのキーは、ERPでのみ使用することを目的としています。セッションキーのその他の制限は、特定の下層によって課される場合があり、この仕様の範囲外です。
A denial-of-service (DoS) attack on the peer may be possible when using the EAP Initiate/Re-auth message. An attacker may send a bogus EAP-Initiate/Re-auth message, which may be carried by the authenticator in a RADIUS-Access-Request to the server; in response, the server may send an EAP-Finish/Re-auth with Failure indication in a RADIUS Access-Reject message. Note that such attacks may be plausible with the EAPoL-Start capability of IEEE 802.11 and other similar facilities in other link layers and where the peer can initiate EAP authentication. An attacker may use such messages to start an EAP method run, which fails and may result in the server sending a RADIUS Access-Reject message, thus resulting in the link-layer connections being terminated.
EAP Initiate/ReAuthメッセージを使用する場合、ピアに対するサービス拒否（DOS）攻撃が可能になる場合があります。攻撃者は、aptInitiate/reauthメッセージを送信する場合があります。これは、AuthurticatorがRadius-Access-Requestでサーバーに運ぶことができます。これに応じて、サーバーは、radiusアクセス - リジェクトメッセージに障害表示を伴うEAP-finish/reauthを送信する場合があります。そのような攻撃は、IEEE 802.11のEapol-Start機能と他のリンク層の他の同様の施設、およびピアがEAP認証を開始できる場所でもっともらしい場合があることに注意してください。攻撃者は、そのようなメッセージを使用してEAPメソッドの実行を開始する場合があります。これは失敗し、サーバーがRADIUSアクセス - リジェクトメッセージを送信し、リンク層接続が終了するようになります。
To prevent such DoS attacks, an ERP failure should not result in deletion of any authorization state established by a full EAP exchange. Alternatively, the lower layers and AAA protocols may define mechanisms to allow two link-layer security associations (SAs) derived from different EAP keying materials for the same peer to exist so that smooth migration from the current link layer SA to the new one is possible during rekey. These mechanisms prevent the link layer connections from being terminated when a re-authentication procedure fails due to the bogus EAP-Initiate/Re-auth message.
このようなDOS攻撃を防ぐために、ERPの障害は、完全なEAP交換によって確立された認可状態の削除をもたらさないはずです。あるいは、下層とAAAプロトコルは、現在のリンク層SAから新しいものへのスムーズな移動が可能になるように、同じピアが存在するために、同じピアが存在するための異なるEAPキーイング材料から派生した2つのリンク層セキュリティ協会（SA）を可能にするメカニズムを定義する場合があります。Rekeyの間。これらのメカニズムは、偽のイナチエート/再オーースメッセージのために再認証手順が失敗したときにリンク層接続が終了するのを防ぎます。
When a DSRK is sent from a home ER server to a local domain server or when a rMSK is sent from an ER server to an authenticator, in the absence of end-to-end security between the entity that is sending the key and the entity receiving the key, it is plausible for other entities to get access to keys being sent to an ER server in another domain. This mode of key transport is similar to that of MSK transport in the context of EAP authentication. We further observe that ERP is for access authentication and does not support end-to-end data security. In typical implementations, the traffic is in the clear beyond the access control enforcement point (the authenticator or an entity delegated by the authenticator for access control enforcement). The model works as long as entities in the middle of the network do not use keys intended for other parties to steal service from an access network. If that is not achievable, key delivery must be protected in an end-to-end manner.
DSRKがHome ERサーバーからローカルドメインサーバーに送信された場合、またはキーとエンティティを送信しているエンティティ間でエンドツーエンドのセキュリティがない場合、RMSKがERサーバーから認証機に送信された場合キーを受信すると、他のエンティティが別のドメインのERサーバーに送信されるキーにアクセスできるようになります。この主要な輸送のモードは、EAP認証のコンテキストでのMSK輸送のモードに似ています。さらに、ERPはアクセス認証用であり、エンドツーエンドのデータセキュリティをサポートしていないことを観察します。典型的な実装では、トラフィックはアクセス制御施行ポイント（AuthenticatorまたはAuthenticatorがアクセス制御執行のために委任されたエンティティ）を超えて明確です。ネットワークの中央にあるエンティティが、他の関係者がアクセスネットワークからサービスを盗むために意図されたキーを使用しない限り、モデルは機能します。それが達成できない場合、主要な配信はエンドツーエンドの方法で保護する必要があります。
This document specifies IANA registration of two new 'Packet Codes' from the EAP registry:
このドキュメントは、EAPレジストリからの2つの新しい「パケットコード」のIANA登録を指定します。
o 5 (Initiate)
o 5（開始）
o 6 (Finish)
o 6（仕上げ）
These values are in accordance with [2].
これらの値は[2]に準拠しています。
This document also specifies creation of a new table, Message Types, in the EAP registry with the following assigned numbers:
このドキュメントは、次の割り当てられた番号を使用して、EAPレジストリで新しいテーブル、メッセージタイプの作成も指定しています。
o 0 Reserved
o 0予約
o 1 (Re-auth-Start, applies to Initiate Code only)
o 1（Reauth-Start、コードのみを開始するために適用）
o 2 (Re-auth, applies to Initiate and Finish Codes)
o 2（reauth、コードの開始および終了に適用）
o 3-191 IANA managed and assigned based on IETF Consensus [17]
o 3-191 IANAはIETFコンセンサスに基づいて管理および割り当てられました[17]
o 192-255 Private use
o 192-255私的使用
Next, we specify creation of a new table, EAP Initiate and Finish Attributes, associated with EAP Initiate and Finish messages in the EAP registry with the following assigned numbers.
次に、EAPの開始属性、EAP開始属性、および終了属性の作成を指定します。これは、以下の割り当てられた番号を使用して、EAPレジストリでメッセージを開始し、仕上げます。
o 0: Reserved
o 0：予約済み
o keyName-NAI: This is a TLV payload. The Type is 1.
o KeyName-NAI：これはTLVペイロードです。タイプは1です。
o rRK Lifetime: This is a TV payload. The Type is 2.
o RRK Lifetime：これはテレビのペイロードです。タイプは2です。
o rMSK Lifetime: This is a TV payload. The Type is 3.
o rmsk lifetime：これはテレビのペイロードです。タイプは3です。
o Domain name: This is a TLV payload. The Type is 4.
o ドメイン名：これはTLVペイロードです。タイプは4です。
o Cryptosuite list: This is a TLV payload. The Type is 5.
o CryptoSuiteリスト：これはTLVペイロードです。タイプは5です。
o Authorization Indication: This is a TLV payload. The Type is 6.
o 承認兆候：これはTLVペイロードです。タイプは6です。
o 7-127: Used to carry other non-channel-binding-related attributes. IANA managed and assigned based on IETF Consensus [17].
o 7-127：他の非チャネル結合関連属性を運ぶために使用されます。IANAは、IETFコンセンサス[17]に基づいて管理および割り当てられました。
o The TLV type range of 128-191 is reserved to carry CB information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages. Below are the current assignments (all of them are TLVs):
o 128-191のTLVタイプの範囲は、EAPイナティエート/ReAuthおよびEAP-FINISH/REAUTHメッセージにCB情報を携帯するために予約されています。以下は現在の割り当てです（それらはすべてTLVです）：
* Called-Station-Id: 128
* Station-IDと呼ばれる：128
* Calling-Station-Id: 129
* 呼び出しステーション-ID：129
* NAS-Identifier: 130
* Nas-Identifier：130
* NAS-IP-Address: 131
* Nas-IP-Address：131
* NAS-IPv6-Address: 132
* NAS-IPV6-アドレス：132
133-191: Used to carry other channel-binding-related attributes. IANA managed and assigned based on IETF Consensus [17].
133-191：他のチャネル結合関連属性を運ぶために使用されます。IANAは、IETFコンセンサス[17]に基づいて管理および割り当てられました。
o 192-255: Reserved for Private use.
o 192-255：私的使用のために予約されています。
We specify creation of another registry, 'Re-authentication Cryptosuites', with the following assigned numbers:
次の割り当てられた番号を使用して、別のレジストリ「再認証cryptosuites」の作成を指定します。
o 0: Reserved
o 0：予約済み
o 1: HMAC-SHA256-64
o 1：HMAC-SHA256-64
o 2: HMAC-SHA256-128
o 2：HMAC-SHA256-128
o 3: HMAC-SHA256-256
o 3：HMAC-SHA256-256
o 4-191: IANA managed and assigned based on IETF consensus [17] o 192-255: Reserved for Private use.
o 4-191：IANAは、IETFコンセンサス[17] O 192-255に基づいて管理および割り当てられました。
Further, this document registers a Re-auth usage label from the "USRK Key Labels" name space with a value
さらに、このドキュメントは、値のある「USRKキーラベル」名スペースからReAuth使用ラベルを登録します
EAP Re-authentication Root Key@ietf.org
eap reauthentication root key@ietf.org
and DSRK-authorized delivery key from the "USRK Key Labels" name space
および「USRKキーラベル」名スペースからのDSRK認定配信キー
DSRK Delivery Authorized Key@ietf.org
DSRK配信認定key@ietf.org
in accordance with [3].
[3]に従って。
In writing this document, we benefited from discussing the problem space and the protocol itself with a number of folks including Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of the HOKEY working group. The credit for the idea to use EAP-Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link-layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin Hoeper suggested the use of the windowing technique to handle multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for the suggestion to use hexadecimal encoding for rIKname when sent as part of keyName-NAI field. Thanks to Bernard Aboba for suggestions in clarifying the EAP lock-step operation, and Joe Salowey and Glen Zorn for help in specifying AAA transport of ERP messages. Thanks to Sam Hartman for the DSRK Authorization Indication mechanism.
この文書を書く際に、私たちは問題の空間とプロトコル自体について、バーナード・アボバ、ジャリ・アークコ、サム・ハートマン、ラス・ヒューズリー、ジョー・サロウィー、ジェシー・ウォーカー、チャールズ・クランシー、ミカエラ・ヴァンダーブン、ケダー・ゴーンカー、パラグAgashe、Dinesh Dharmaraju、Pasi Eronen、Dan Harkins、Yoshi Ohba、Glen Zorn、Alan Dekok、Katrin Hoeper、およびHokey Working Groupの他の参加者。EAP Initiate/Reauth-Startを使用するというアイデアのクレジットは、Charles Clancyに与えられ、DOS攻撃を緩和する複数のリンク層SASのアイデアはヨッシーオバに行きます。Katrin Hoeperは、複数の同時のER交換を処理するためのウィンドウ剤技術の使用を提案しました。KeyName-NAIフィールドの一部として送信された場合、RikNameの16進コードを使用することを提案してくれたPasi Eronenに感謝します。EAPロックステップ操作を明確にするための提案をしてくれたBernard Abobaと、ERPメッセージのAAA輸送の指定を支援してくれたJoe SaloweyとGlen Zornに感謝します。DSRK認証指示メカニズムについて、Sam Hartmanに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[2] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[3] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008.
[3] Salowey、J.、Dondeti、L.、Narayanan、V。、およびM. Nakhjiri、「拡張マスターセッションキー（EMSK）からのルートキーの派生の仕様」、RFC 5295、2008年8月。
[4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[4] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[5] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[6] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[6] Arkko、J。およびH. Haverinen、「第3世代認証とキー契約（EAP-AKA）のための拡張可能な認証プロトコル法」、RFC 4187、2006年1月。
[7] Lopez, R., Skarmeta, A., Bournelle, J., Laurent-Maknavicus, M., and J. Combes, "Improved EAP keying framework for a secure mobility access service", IWCMC '06, Proceedings of the 2006 International Conference on Wireless Communications and Mobile Computing, New York, NY, USA, 2006.
[7] Lopez、R.、Skarmeta、A.、Bournelle、J.、Laurent-Maknavicus、M.、およびJ. Combes、「安全なモビリティアクセスサービスのためのEAPキーイングフレームワークの改善」、IWCMC '06、2006年の国際会議の議事録ワイヤレス通信およびモバイルコンピューティングについて、ニューヨーク州ニューヨーク、米国、2006年。
[8] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS", Work in Progress, October 2003.
[8] Arbaugh、W。およびB. Aboba、「Radiusへのハンドオフ拡張」、2003年10月、進行中の作業。
[9] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008.
[9] Clancy、T.、Nakhjiri、M.、Narayanan、V。、およびL. Dondeti、「ハンドオーバーキー管理と再認証問題声明」、RFC 5169、2008年3月。
[10] Institute of Electrical and Electronics Engineers, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004", December 2004.
[10] 電気および電子機器エンジニア研究所、「地元および大都市圏ネットワークのIEEE基準：ポートベースのネットワークアクセス制御、IEEE STD 802.1x-2004」、2004年12月。
[11] Nakhjiri, M. and Y. Ohba, "Derivation, delivery and management of EAP based keys for handover and re-authentication", Work in Progress, February 2008.
[11] Nakhjiri、M。およびY. Ohba、「ハンドオーバーと再認証のためのEAPベースのキーの派生、配信、管理」、2008年2月、進行中の作業。
[12] Gaonkar, K., Dondeti, L., Narayanan, V., and G. Zorn, "RADIUS Support for EAP Re-authentication Protocol", Work in Progress, February 2008.
[12] Gaonkar、K.、Dondeti、L.、Narayanan、V。、およびG. Zorn、「EAP再認証プロトコルの半径サポート」、2008年2月の作業進行中。
[13] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[13] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[14] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[14] Aboba、B。およびP. Calhoun、「Radius（リモート認証ダイヤルインユーザーサービス）拡張可能な認証プロトコル（EAP）のサポート」、RFC 3579、2003年9月。
[15] Dondeti, L. and H. Tschofenig, "Diameter Support for EAP Re-authentication Protocol", Work in Progress, November 2007.
[15] Dondeti、L。およびH. Tschofenig、「EAP再認証プロトコルの直径サポート」、2007年11月、進行中の作業。
[16] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[16] Aboba、B.、Zorn、G。、およびD. Mitton、「Radius and IPv6」、RFC 3162、2001年8月。
[17] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[17] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[18] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[18] Housley、R。and B. Aboba、「認証、承認、会計（AAA）主要管理のガイダンス」、BCP 132、RFC 4962、2007年7月。
0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start]
0. Authenticator-> Peer：[eap-initiate/reauth-start]
1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,Auth-tag*)
1. ピア - >認証者：EAP initiate/reauth（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/reauth（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.
* Auth-Tagの計算は、EAP開始/仕上げメッセージ全体にわたってあります。開始と仕上げのコード値は異なるため、反射攻撃が軽減されます。
Authors' Addresses
著者のアドレス
Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr. San Diego, CA 92121 USA
Vidya Narayanan Qualcomm、Inc。5775 Morehouse Dr. San Diego、CA 92121 USA
Phone: +1 858-845-2483
EMail: vidyan@qualcomm.com
Lakshminath Dondeti Qualcomm, Inc. 5775 Morehouse Dr. San Diego, CA 92121 USA
Lakshminath Dondeti Qualcomm、Inc。5775 Morehouse Dr. San Diego、CA 92121 USA
Phone: +1 858-845-1267
EMail: ldondeti@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。