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)
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）は、複数の認証方法をサポートする認証フレームワークです。主な目的は、ネットワークアクセス認証であり、下層がアクセス制御を実行したい場合、キー生成方法が用いられます。マスターセッションキー（MSK）及び拡張MSK（EMSK）：EAPキーイング階層は、すべてのキー生成EAPメソッドによって導出される2つのキーを定義します。最も一般的な展開シナリオでは、EAPピアとEAPサーバは、EAP認証として知られている第三者を介して相互に認証します。 EAP認証またはEAP認証によって制御エンティティは、アクセス制御を実施します。認証が成功した後、EAPサーバは、EAP認証にMSKを輸送します。 EAP認証とEAPピアは認証キー、キー派生キー、またはキートランスポートキーとしてMSKを用いた一過セッションキー（TSKs）を確立し、パケットごとのアクセス施行に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.
ピアは別のオーセンティケータから移動すると、高速ハンドオーバをサポートするために、完全な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のピア開始性質に対応するためにEAPメッセージを搬送できるように修正される必要があるかもしれません。具体的には、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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の認証 - このドキュメントで説明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サーバは論理エンティティです。ホーム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 - 机やDARK由来再認証ルートキー、。
rIK - re-authentication Integrity Key, derived from the rRK.
RIK - RRK由来再認証キー整合性、。
rMSK - re-authentication MSK. This is a per-authenticator key, derived from the rRK.
rMSK - 再認証MSK。これは、RRK由来ごとのオーセンティケータキー、です。
keyName-NAI - ERP messages are integrity protected with the rIK or the DS-rIK. The use of rIK or DS-rIK for integrity protection of ERP messages is indicated by the EMSKname [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メソッドの実行からキーイングマテリアルの所有の証拠を確認すると、ピアとオーセンティケータとの間のセキュリティアソシエーションを確立することを可能にします。オーセンティケータは、RFC 3748に記載EAP認証と同様に、再認証プロトコルのための通過エンティティとして作用する[2]。 ERPは、ピアとサーバ間の単一往復の交換です。それは、下部層と完全EAP交換中に使用されるEAPメソッドとは無関係です。 ERサーバは、ホームドメインまたはピアとオーセンティケータと同じ（訪問）ドメインであってもよいです。
Figure 2 shows the protocol exchange. The first time the peer attaches to any network, it performs a full EAP exchange (shown in Figure 1) with the EAP server; as a result, an MSK is distributed to the EAP authenticator. The MSK is then used by the authenticator and the peer to establish TSKs as needed. At the time of the initial EAP exchange, the peer and the server also derive an EMSK, which is used to derive a re-authentication Root Key (rRK). More precisely, a re-authentication Root Key is derived from the EMSK or from a Domain-Specific Root Key (DSRK), which itself is derived from the EMSK. The rRK is only available to the peer and the ER server and is never handed out to any other entity. Further, a re-authentication Integrity Key (rIK) is derived from the rRK; the peer and the ER server use the rIK to provide proof of possession while performing an ERP exchange. The rIK is also never handed out to any entity and is only available to the peer and server.
図2は、プロトコル交換を示します。ピアが任意のネットワークに接続する最初の時間は、それはEAPサーバとの（図1に示す）完全EAP交換を行います。結果として、MSKは、EAP認証に分配されます。 MSKは、その後、必要に応じてTSKsを確立するために、オーセンティケータとピアで使用されています。初期EAP交換時に、ピア及びサーバは、再認証ルートキー（RRK）を導出するために使用されるEMSKを導き出します。より正確には、再認証ルートキーは、EMSKから又はそれ自体がEMSKから導出されるドメイン固有のルートキー（DSRK）に由来します。 RRKは、ピアとERサーバにのみ使用可能で、他のエンティティに配布されることはありません。さらに、再認証インテグリティキー（RIK）はRRKから誘導されます。ピアとERサーバは、ERPの交換を行いながら所有の証拠を提供するためにRIKを使用します。 RIKはまた、任意のエンティティに配っていないと、ピアとサーバにのみ使用可能ですありません。
When the ER server is in the home domain, the peer and the server use the rIK and rRK derived from the EMSK; and when the ER server is not in the home domain, they use the DS-rIK and DS-rRK corresponding to the local domain. The domain of the ER server is identified by the realm portion of the keyname-NAI in ERP messages.
ERサーバがホームドメインにある場合には、ピアとサーバはEMSKから派生RIKとRRKを使用します。 ERサーバがホームドメイン内にない場合、それらはローカルドメインに対応するDS-RIKとDS-RRKを使用します。 ERサーバのドメインは、ERPメッセージでキー名-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コードは、EAP-開始し、EAP-仕上げ、EAPの再認証の目的のために、この文書で指定されています。ピアがEAP再認証をサポートするターゲット認証子を識別すると、図2に示すように、それは、ERPの交換を行います。ピアがEAP再認証、または添付ファイルの前に支持新しいオーセンティケータに取り付けられたときに交換自体が起こり得ます。ピアは、それ自体でERPを開始します。それはまた、新しいオーセンティケータからEAP-開始/再-AUTH-Startメッセージに応じて、そうすることができます。 EAP-開始/再-AUTH-Startメッセージは、オーセンティケータは、ERP交換をトリガすることができます。
It is plausible that the authenticator does not know whether the peer supports ERP and whether the peer has performed a full EAP authentication through another authenticator. The authenticator MAY initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start message, and if there is no response, it will send the EAP-Request/ Identity message. Note that this avoids having two EAP messages in flight at the same time [2]. The authenticator may send the EAP-Initiate/Re-auth-Start message and wait for a short, locally configured amount of time. If the peer does not already know, this message indicates to the peer that the authenticator supports ERP. In response to this trigger from the authenticator, the peer can initiate the ERP exchange by sending an EAP-Initiate/Re-auth message. If there is no response from the peer after the necessary retransmissions (see Section 6), the authenticator MUST initiate EAP by sending an EAP-Request message, typically the EAP-Request/Identity message. Note that the authenticator may receive an EAP-Initiate/ Re-auth message after it has sent an EAP-Request/Identity message. If the authenticator supports ERP, it MUST proceed with the ERP exchange. When the EAP-Request/Identity times out, the authenticator MUST NOT close the connection if an ERP exchange is in progress or has already succeeded in establishing a re-authentication MSK.
オーセンティケータは、ピアがERPをサポートし、ピアは別のオーセンティケータを通じて完全なEAP認証を行っているかどうかかどうか知らないもっともらしいです。オーセンティケータはEAP-開始/再-AUTH-Startメッセージを送信することにより、ERPの交換を開始することができ、かつ応答がない場合、それはEAP-Request / Identityメッセージを送信します。これは、同時に飛行中の2つのEAPメッセージを有する[2]回避することに留意されたいです。オーセンティケータはEAP-開始/再-AUTH-Startメッセージを送信し、時間の短い、ローカルに設定された金額を待つことができます。ピアがすでに知っているしない場合は、このメッセージがオーセンティケータは、ERPをサポートしてピアに示します。オーセンティケータからこのトリガに応答して、ピアはEAP-開始/再認証メッセージを送信することにより、ERPの交換を開始することができます。必要に応じて再送信（セクション6を参照）の後、ピアからの応答がない場合、オーセンティケータはEAP-Requestメッセージ、典型的には、EAP-Request / Identityメッセージを送信することによりEAPを開始しなければなりません。オーセンティケータは、それがEAP-Request / Identityメッセージを送信した後にEAP-開始/再認証メッセージを受け取ることがあります。オーセンティケータは、ERPをサポートしている場合、それは、ERP交換を進めなければなりません。アウトするときに、EAP-Request / Identity回ERP交換が進行中であるか、すでに再認証MSKを確立することに成功した場合、オーセンティケータは、接続を閉じてはなりません。
If the authenticator does not support ERP, it drops EAP-Initiate/ Re-auth messages [2] as the EAP code of those packets is greater than 4. An ERP-capable peer will exhaust the EAP-Initiate/Re-auth message retransmissions and fall back to EAP authentication by responding to EAP Request/Identity messages from the authenticator. If the peer does not support ERP or if it does not have unexpired key material from a previous EAP authentication, it drops EAP-Initiate/ Re-auth-Start messages. If there is no response to the EAP-Initiate/ Re-auth-Start message, the authenticator SHALL send an EAP Request message (typically EAP Request/Identity) to start EAP authentication. From this stage onwards, RFC 3748 rules apply. Note that this may introduce some delay in starting EAP. In some lower layers, the delay can be minimized or even avoided by the peer initiating EAP by sending messages such as EAPoL-Start in the IEEE 802.1X specification [10].
オーセンティケータは、ERPをサポートしていない場合、それはEAP-開始/再認証メッセージをドロップし、それらのパケットのEAPコードが4よりも大きいように[2] ERP対応ピアはEAP-開始/再認証メッセージの再送を排出しますオーセンティケータからEAP要求/アイデンティティメッセージに対応することによって、バックEAP認証に分類されます。ピアは、ERPをサポートしていないか、それが以前のEAP認証から有効期限内のキーマテリアルを持っていない場合、それはEAPは、開始/再認証スタートメッセージを削除します。場合EAP-開始/再認証開始メッセージに対する応答がない場合は、オーセンティケータはEAP認証を開始するためにEAP Requestメッセージ（通常はEAP要求/アイデンティティ）を送付しなければなりません。以降、この段階から、RFC 3748の規則が適用されます。これは、EAPを開始するには、いくつかの遅延を導入することができることに注意してください。 [10] IEEE 802.1X仕様でそのようなEAPOL開始などのメッセージを送信することによって、いくつかの下位層において、遅延を最小限に抑えることができ、あるいはEAPを開始するピアによって避けます。
The peer sends an EAP-Initiate/Re-auth message that contains the keyName-NAI to identify the ER server's domain and the rIK used to protect the message, and a sequence number for replay protection. The EAP-Initiate/Re-auth message is integrity protected with the rIK. The authenticator uses the realm in the keyName-NAI [4] field to send
ピアはERサーバのドメインを識別するためのkeyName-NAIが含まれており、RIKは、メッセージ、および再生保護のためのシーケンス番号を保護するために使用するEAP-開始/再認証メッセージを送信します。 EAP-開始/再認証メッセージがRIKで保護整合性です。オーセンティケータは、送信するのkeyName-NAI [4]にレルムを使用します
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を使用しています。サーバは、RIKの所有、及びメッセージの新しさの証拠を確認した後、鍵導出への入力としてシーケンス番号を使用して、RRKから再認証MSK（rMSK）を導出します。サーバは、受信したシーケンス番号を加えたものに期待されるシーケンス番号を更新します。
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-開始/再認証メッセージに応答して、サーバは、EAP-仕上げ/再認証メッセージを送信します。このメッセージは、RIKで保護整合性です。サーバがオーセンティケータに、このメッセージと一緒にrMSKを輸送します。 rMSKは、完全EAP交換にEAP-Successメッセージと共にMSKと同様に搬送されます。 [11]で進行中の作業は、EAPサーバとの信頼関係を共有し、多くの異なるERのサーバの1つにEAPサーバからRRKを輸送するために使用することができ、追加の鍵配布プロトコルを記述します。
The peer MAY request the server for the rMSK lifetime. If so, the ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message.
ピアはrMSK寿命のためにサーバーを要求することができます。もしそうなら、ERサーバは、EAP-フィニッシュでrMSK寿命/再認証メッセージを送信します。
In an ERP bootstrap exchange, the peer MAY request the server for the rRK lifetime. If so, the ER server sends the rRK lifetime in the EAP-Finish/Re-auth message.
ERPのブートストラップ交換では、ピアはRRK寿命のためにサーバーを要求することができます。もしそうなら、ERサーバは、EAP-フィニッシュでRRK寿命/再認証メッセージを送信します。
The peer verifies the replay protection and the integrity of the message. It then uses the sequence number in the EAP-Finish/Re-auth message to compute the rMSK. The lower-layer security association protocol is ready to be triggered after this point.
ピアは再生保護とメッセージの整合性を検証します。次にrMSKを計算するためにEAP-終了/再認証メッセージにシーケンス番号を使用します。下層セキュリティアソシエーションプロトコルでは、この点の後にトリガされる準備ができています。
The defined ER extensions allow executing the ERP with an ER server in the local domain (access network). The local ER server may be co-located with a local AAA server. The peer may learn about the presence of a local ER server in the network and the local domain name (or ER server name) either via the lower layer or by means of ERP bootstrapping. The peer uses the domain name and the EMSK to compute the DSRK and from that key, the DS-rRK; the peer also uses the domain name in the realm portion of the keyName-NAI for using ERP in the local domain. Figure 3 shows the full EAP and subsequent local ERP exchange; Figure 4 shows it with a local ER server.
定義されたERの拡張は、ローカルドメイン（アクセスネットワーク）におけるERサーバでERPを実行することができます。ローカルERサーバは、ローカルAAAサーバと同じ場所に配置することができます。ピアは下位層を介して、またはERPブートストラップの手段のいずれかによって、ネットワーク内のローカルERサーバの存在およびローカルドメイン名（またはERサーバ名）について学習することができます。ピアは、ドメイン名とDSRKとそのキーから、DS-RRKを計算するEMSKを使用しています。ピアは、ローカルドメイン内のERPを使用するためのkeyName-NAIのレルム部分にドメイン名を使用します。図3は、完全なEAPおよびその後のローカルERP交換を示す図です。図4は、ローカルERサーバでそれを示しています。
Peer EAP Authenticator Local ER Server Home EAP Server
==== ================= =============== ===============
<-- EAP-Request/ -- Identity
< - EAP要求/ - アイデンティティ
-- EAP Response/--> Identity --AAA(EAP Response/--> Identity) --AAA(EAP Response/ --> Identity, [DSRK Request, domain name])
- EAP応答/ - >アイデンティティ--AAA（EAP応答/ - >アイデンティティ）--AAA（EAP応答/ - >アイデンティティ、[DSRK要求、ドメイン名]）
<------------------------ 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交換（例えば、これはオーセンティケータとホームEAPサーバの間の経路に、そのようなAAAプロキシとしてAAAエンティティ、のいずれであってもよいのパスに存在してもよいですピア）。その場合には、ERサーバがEAPサーバにドメイン名を送信することにより、DSRKを要求します。応答では、EAPサーバは、[3]で指定された手順に従ってDSRKを計算し、主張し、ドメイン内のERサーバに、DSRKとキー名、EMSKnameを送信します。ローカルドメインは、ピアへの下位層を介して、同じドメイン名を発表する責任があります。
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.
ピアは、ドメイン名を知らない場合は、それが持つERPのブートストラップ交換を開始すべきである（これは逃した発表や、特定の下層のドメイン名の発表のためのサポートの欠如に、下層の発表を経て、ドメイン名を受信しませんでした）ホームERサーバは、ドメイン名を取得します。ローカルERサーバがEAP-開始/再認証のブートストラップメッセージを運ぶAAAメッセージでドメイン名を送信することにより、DSRKのホームAAAサーバを要求するものとします。ローカルERサーバは、ホームERサーバへのピアからのパスでなければなりません。そうでない場合、それはDSRKを要求することはできません。
After receiving the DSRK and the EMSKname, the local ER server computes the DS-rRK and the DS-rIK from the DSRK as defined in Sections 4.1 and 4.3 below. After receiving the domain name, the peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys are referred to by a keyName-NAI formed as follows: the username part of the NAI is the EMSKname, the realm portion of the NAI is the domain name. Both parties also maintain a sequence number (initialized to zero) corresponding to the specific keyName-NAI.
セクション4.1及び4.3以下で定義されるようDSRKとEMSKnameを受信した後、ローカルERサーバがDS-RRKとDSRKからDS-RIKを計算します。ドメイン名を受信した後、ピアはまたDSRK、DS-RRK、およびDS-RIKを導出します。 NAIのユーザ名一部はEMSKname、NAIのレルム部分は、ドメイン名である：これらのキーは、以下のようkeyNameの-NAIを形成することにより参照されます。両当事者は、特定のkeyName-NAIに対応する（ゼロに初期設定）シーケンス番号を維持します。
Subsequently, when the peer attaches to an authenticator within the local domain, it may perform an ERP exchange with the local ER server to obtain an rMSK for the new authenticator.
ピアは、ローカルドメイン内のオーセンティケータに接続する際に続いて、それは新しいオーセンティケータのためrMSKを得るために、ローカルERサーバとERP交換を行うことができます。
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.
セクション4.1で指定されるようにRRKは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は、一の以上のオーセンティケータのためRIK、およびrMSKsを導出するために使用されます。下の図は、RRK、RIK、およびrMSKsとキー階層を示しています。
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
KIM KまたはK =暗く
S = rRK Label | "\0" | length
S = RRKラベル| "\ 0" |長さ
The rRK Label is an IANA-assigned 8-bit ASCII string:
RRKラベルは、IANAによって割り当てられた8ビットのASCII文字列です。
EAP Re-authentication Root Key@ietf.org
EAP再認証ルートKey@ietf.org
assigned from the "USRK key labels" name space in accordance with [3].
「USRKキーラベル」名前空間から割り当てられた[3]。
The KDF and algorithm agility for the KDF are as defined in [3].
[3]で定義されるようKDFためKDFアルゴリズムアジリティです。
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.
DARK由来RRKは、文書の残りの部分でDS-RRKと呼ばれています。すべてのキーを導出し、このセクションで指定されたプロパティは同じまま。
The rRK has the following properties. These properties apply to the rRK regardless of the parent key used to derive it.
RRKは、次のプロパティがあります。これらのプロパティは関係なく、それを導き出すために使用する親キーのRRKに適用されます。
o The length of the rRK MUST be equal to the length of the parent key used to derive it.
O RRKの長さは、それを導出するために使用される親キーの長さに等しくなければなりません。
o The rRK is to be used only as a root key for re-authentication and never used to directly protect any data.
O RRKは再認証のためのルートキーとしてのみ使用し、直接任意のデータを保護するために使用されることはありませんすることがあります。
o The rRK is only used for 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
K = RRKと
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のcryptosuiteと長さが異なるメッセージ認証コード（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サーバのドメイン名です。ホーム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の寿命は、その親キーのそれより大きくなることはありません。 RIKはEMSKが期限切れになったときに期限切れにする必要があり、その時点での使用から削除する必要があります。
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-開始/再認証メッセージ上の完全性チェックサムを計算することによってRIKの所有を証明します。ピアが初めてRIKを使用する場合、それはRIKで使用する整合性アルゴリズムを選択することができます。ピアおよびサーバは、そのキーで保護されているすべてのERPメッセージに指定されたRIKと同じ整合性アルゴリズムを使用しなければなりません。ピアとサーバストアアルゴリズム情報最初の使用後、それらはそのRIKのすべての後続の使用のために同じアルゴリズムを使用します。
If the server's policy does not allow the use of the cryptosuite selected by the peer, the server SHALL reject the EAP-Initiate/ Re-auth message and SHOULD send a list of acceptable cryptosuites in the EAP-Finish/Re-auth message.
サーバーのポリシーがピアで選択されたcryptosuiteの使用を許可しない場合は、サーバがEAP-開始/再認証メッセージを却下すると、EAP-仕上げに許容cryptosuitesのリストを送るべきである/再認証メッセージ。
The rIK length may be different from the key length required by an integrity algorithm. In case of hash-based MAC algorithms, the key is first hashed to the required key length as specified in [5]. In case of cipher-based MAC algorithms, if the required key length is less than 32 octets, the rIK is hashed using HMAC-SHA256 and the first k octets of the output are used, where k is the key length required by the algorithm. If the required key length is more than 32 octets, the first k octets of the rIK are used by the cipher-based MAC algorithm.
RIK長は、整合性アルゴリズムで必要とされるキーの長さは異なる場合があります。ハッシュベースのMACアルゴリズムの場合、キーは、最初の[5]で指定されるように必要な鍵の長さにハッシュされます。暗号ベースのMACアルゴリズムの場合に必要な鍵長未満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再認証プロトコル交換以下導出されます。
The rMSK is derived as follows.
次のようにrMSKが導出されます。
rMSK = KDF (K, S), where
rMSK = KDF（K、S）、
K = rRK and
K = RRKと
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-開始/再認証メッセージ中にピアによって送信されたシーケンス番号です。このフィールドは、ネットワークバイト順（セクション5.3.2を参照）の16ビット数として符号化されます。
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.
新しいRRKが導出されている場合は、O、後続rMSKs新しいRRKから誘導されなければなりません。以前に配信rMSKsは、まだ寿命が満了するまで使用されるかもしれません。
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サーバは、そのドメイン名を含める必要があり、ピアによって送信された第1のEAP応答メッセージをカプセル化するAAAメッセージでは、初期のEAP交換の際にホームAAAサーバからDSRKを要求すべきです。 EAP交換が成功した場合、サーバーは、EAP-Successメッセージと一緒に、EMSKname、およびDSRK寿命（EMSK、[3]で指定されたドメイン名を使用して導出）ローカルERサーバのDSRKを送信します。 [12]で指定されるように、ローカルERサーバは、ピアにEAP-Successメッセージを転送する前に、（存在する場合）DSRK、EMSKname、及びDSRK寿命を抽出する必要があります。 MSKは、いつものようにEAP認証によって抽出される（また、EAP成功メッセージと一緒に存在する）ことに留意されたいです。ピアはEAP-開始/再AUTHスタートメッセージを介して、または下層のアナウンスを介してドメイン名を学習します。ドメイン名は、完全な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のブートストラップ交換を開始すべきである（これは逃した発表や、特定の下層のドメイン名の発表のためのサポートの欠如に、下層の発表を経て、ドメイン名を受信しませんでした）ブートストラップフラグを持つERP交換は、ドメイン名を取得するためにホームERサーバで）オン。ローカルERサーバの動作は、上記と同じです。ピアはまた、AAAサーバからRRK寿命などの情報を取得するためにブートストラップを開始することができます。
The following steps describe the ERP explicit bootstrapping process:
次の手順は、ERP、明示的なブートストラッププロセスを説明します。
o The peer sends the EAP-Initiate/Re-auth message with the bootstrapping flag turned on. The bootstrap message is always sent to the home AAA server, and the keyname-NAI attribute in the bootstrap message is constructed as follows: the username portion of the NAI contains the EMSKname, and the realm portion contains the home domain name.
Oピアは、ブートストラップフラグとEAP-開始/再認証メッセージがオンに送信します。ブートストラップメッセージは常にホームAAAサーバに送信され、次のようにブートストラップメッセージでキー名-NAI属性が構築される：NAIのユーザ名部分がEMSKname含まれており、分野の部分は、ホームドメイン名が含まれています。
o In addition, the message MUST contain a sequence number for replay protection, a cryptosuite, and an integrity checksum. The cryptosuite indicates the authentication algorithm. The integrity checksum indicates that the message originated at the claimed entity, the peer indicated by the Peer-ID, or the rIKname.
Oまた、メッセージは、再生保護、cryptosuite、および整合性チェックサムのシーケンス番号を含まなければなりません。 cryptosuiteは、認証アルゴリズムを示します。完全性チェックサムは、ピアがピアID、またはrIKnameによって示される、メッセージが主張エンティティにおいて発信することを示しています。
o The peer MAY additionally set the lifetime flag to request the key lifetimes.
Oピアはさらにキー寿命を要求する寿命フラグを設定してもよいです。
o When an ERP-capable authenticator receives the EAP-Initiate/ Re-auth message from a peer, it copies the contents of the keyName-NAI into the User-Name attribute of RADIUS [13]. The rest of the process is similar to that described in [14] and [12].
O ERP対応オーセンティケータがピアからのEAP-開始/再認証メッセージを受信すると、コピーRADIUSのUser-Name属性にkeyNameの-NAIの内容[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.
ローカルERサーバが存在する場合にO、ローカルERサーバは、ピアによって送信されたEAP-開始/再認証メッセージをカプセル化AAAメッセージ内DSRK要求とそのドメイン名を含まなければなりません。
o Upon receipt of an EAP-Initiate/Re-auth message, the server verifies whether the message is fresh or is a replay by evaluating whether the received sequence number is equal to or greater than the expected sequence number for that rIK. The server then verifies to ensure that the cryptosuite used by the peer is acceptable. Next, it verifies the origin authentication of the message by looking up the rIK. If any of the checks fail, the server sends an EAP-Finish/Re-auth message with the Result flag set to '1'. Please refer to Section 5.2.2 for details on failure handling. This error MUST NOT have any correlation to any EAP-Success message that may have been received by the EAP authenticator and the peer earlier. If the EAP-Initiate/Re-auth message is well-formed and valid, the server prepares the EAP-Finish/Re-auth message. The bootstrap flag MUST be set to indicate that this is a bootstrapping exchange. The message contains the following fields:
O EAP-開始/再認証メッセージを受信すると、サーバは、メッセージが新鮮であるか、または受信されたシーケンス番号がそのRIKの予想されるシーケンス番号以上であるか否かを評価することによって再生であるか否かを検証します。サーバは、ピアによって使用cryptosuiteが許容可能であることを保証するために検証します。次に、RIKを検索することで、メッセージの発信元の認証を検証します。チェックのいずれかが失敗した場合、サーバは、「1」に設定結果フラグとEAP-仕上げ/再認証メッセージを送信します。障害処理の詳細については、セクション5.2.2を参照してください。このエラーは、以前のEAP認証およびピアによって受信された可能性のあるEAP-Successメッセージに任意の相関関係を持ってはいけません。 EAP-開始/再認証メッセージが整形式と有効な場合、サーバーは、EAP-仕上げ/再認証メッセージを準備します。ブートストラップフラグは、これはブートストラップ交換であることを示すように設定されなければなりません。メッセージには、次のフィールドがあります。
* A sequence number for replay protection.
*リプレイ保護のためのシーケンス番号。
* The same keyName-NAI as in the EAP-Initiate/Re-auth message.
* EAP-開始/再認証メッセージと同様のkeyName-NAI。
* If the lifetime flag was set in the EAP-Initiate/Re-auth message, the ER server SHOULD include the rRK lifetime and the rMSK lifetime in the EAP-Finish/Re-auth message. The server may have a local policy for the network to maintain and enforce lifetime unilaterally. In such cases, the server need not respond to the peer's request for the lifetime.
*寿命フラグがEAP-開始/再認証メッセージに設定された場合、ERサーバはRRK寿命とEAP-仕上げrMSK寿命/再認証メッセージを含むべきです。サーバが一方的に寿命を維持し、執行するネットワークのためのローカルポリシーを有することができます。このような場合には、サーバーは、生涯のためのピアの要求に応答する必要はありません。
* If the bootstrap flag is set and a DSRK request is received, the server MUST include the domain name to which the DSRK is being sent.
*ブートストラップフラグが設定されているとDARK要求を受信した場合、サーバはDARKが送信されているドメイン名を含まなければなりません。
* If the home ER server verifies the authorization of a local domain server, it MAY include the Authorization Indication TLV to indicate to the peer that the server (that received the DSRK and that is advertising the domain included in the domain name TLV) is authorized.
*ホームERサーバがローカルドメインサーバーの認証を検証する場合は、サーバが（それがDSRKを受信し、そのドメイン名TLVに含まれるドメインを広告している）許可されていることを相手に知らせるために承認適応症TLVを含んでもよい（MAY） 。
* 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-仕上げ/再認証メッセージが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.
ERP交換が成功すると、ローカルERサーバがDSRK要求を送信した場合、O、ホームERサーバがローカルERサーバのDSRKを含まなければならない（に指定されているEMSKとドメイン名を使用して導出[3]）、EMSKname、 EAP-仕上げ/再認証メッセージと一緒にとDSRK寿命。
o In addition, the rMSK is sent along with the EAP-Finish/Re-auth message, in a AAA attribute [12].
Oまた、rMSKは、[12] AAA属性で、EAP-終了/再認証メッセージとともに送信されます。
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].
[12]で指定されるようにOローカルERサーバは、ピアにEAP-仕上げ/再認証メッセージを転送する前に、DARK、EMSKname、暗寿命を（存在する場合）、抽出する必要があります。
o The authenticator receives the rMSK.
OオーセンティケータはrMSKを受けます。
o When the peer receives an EAP-Finish/Re-auth message with the bootstrap flag set, if a local domain name is present, it MUST use that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName-NAI, and initialize the replay counter for the DS-rIK. If not, the peer SHOULD derive the domain-specific keys using the domain name it learned via the lower layer or from the EAP-Initiate/ Re-auth-Start message. If the peer does not know the domain name, it must assume that there is no local ER server available.
ピアは、ブートストラップフラグが設定されたEAP-仕上げ/再認証メッセージを受信すると、ローカルドメイン名が存在する場合にO、それは適切なDSRKを導出するためにそれを使用しなければならない、DS-RRK、DS-RIK、およびkeyNameの-NAI 、およびDS-RIKのためのリプレイカウンタを初期化します。そうでない場合、ピアは、それが下位層を介して、またはEAP-開始/再-AUTH-スタートメッセージから学んだドメイン名を使用して、ドメイン固有の鍵を導出すべきです。ピアは、ドメイン名を知らない場合には、利用可能なローカル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.
RADIUSおよび直径を使用して、関連するキーをERPをカプセル化し、取得するための手順oをそれぞれ、[12]及び[15]で指定されています。
Since the ER bootstrapping exchange is typically done immediately following the full EAP exchange, it is feasible that the process is completed through the same entity that served as the EAP authenticator for the full EAP exchange. In this case, the lower layer may already have established TSKs based on the MSK received earlier. The lower layer may then choose to ignore the rMSK that was received with the ER bootstrapping exchange. Alternatively, the lower layer may choose to establish a new TSK using the rMSK. In either case, the authenticator and the peer know which key is used based on whether or not a TSK establishment exchange is initiated. The bootstrapping exchange may also be carried out via a new authenticator, in which case, the rMSK received SHOULD trigger a lower layer TSK establishment exchange.
ERブートストラップ交換は通常、完全なEAP交換の直後に行われているので、プロセスは、完全なEAP交換のためのEAP認証を務め同じエンティティを経て完成されていることを実現可能です。この場合、下層は既にMSKは、先に受信に基づいて、TSKsを確立してもよいです。下の層は、ERのブートストラップ交換で受け取ったrMSKを無視することもできます。また、下位層はrMSKを使用して新しいTSKを確立することもできます。いずれの場合においても、オーセンティケータとピアはTSK確立交換が開始されたか否かに基づいて使用されるキーを知っています。ブートストラップ交換はまた、rMSK下層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.
ERPをサポートする新しいオーセンティケータとのアクティブRRKとRIK仲間を持っている場合、ピアは、そのオーセンティケータとのERP交換を行うことができます。 ERPは、EAP-開始/再authおよびEAP-仕上げ/再認証メッセージからなる、典型的ピア開始交換です。または元のEAPサーバとの（存在する場合）ERP交換はローカルERサーバで実行されてもよいです。
It is plausible for the network to trigger the EAP re-authentication process, however. An ERP-capable authenticator SHOULD send an EAP-Initiate/Re-auth-Start message to indicate support for ERP. The peer may or may not wait for these messages to arrive to initiate the EAP-Initiate/Re-auth message.
ネットワークは、EAP再認証プロセスをトリガーすることはしかし、もっともらしいです。 ERP対応のオーセンティケータは、ERPのサポートを示すために、EAP-開始/再-AUTH-Startメッセージを送るべきです。ピアは、または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-開始/再AUTHスタートメッセージがERP対応オーセンティケータによって送信されるべきです。それはピアから応答EAP-開始/再認証メッセージを受信するまで、オーセンティケータは、それを数回再送信することができます。 EAPは、開始/ピアは、オーセンティケータからEAP要求/アイデンティティまたはEAP-開始/再AUTHスタートメッセージのいずれかを受信する前に、ピアからの再認証メッセージが発信していることができます。したがって、EAP-開始/再認証メッセージ内の識別子の値は、EAP-開始/再AUTH-StartまたはEAP要求/アイデンティティメッセージ内の識別子の値とは無関係です。
Operational Considerations at the Peer:
ピアでの運用に関する注意事項：
ERP requires that the peer maintain retransmission timers for reliable transport of EAP re-authentication messages. The reliability considerations of Section 4.3 of RFC 3748 apply with the peer as the retransmitting entity.
ERPは、ピアがEAP再認証メッセージの信頼性の輸送のための再送信タイマーを維持することが必要です。 RFC 3748のセクション4.3の信頼性に関する考慮事項は、再送信エンティティとしてピアと適用されます。
The EAP Re-auth Protocol has the following steps:
EAP再認証プロトコルは、以下のステップがあります。
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を使用しなければなりません。ピアは、サーバからのキーの有効期間を要求するために寿命フラグを設定する必要があります。別のERPの交換をトリガするときに知っているEAPメソッド交換とrMSK寿命をトリガする場合、ピアは知ることがRRK寿命を使用することができます。
The authenticator copies the contents of the value field of the keyName-NAI TLV into the User-Name RADIUS attribute in the AAA message to the ER server.
オーセンティケータコピーERサーバへのAAAのメッセージ内のUser-名RADIUSアトリビュートへのkeyName-NAI TLVの値フィールドの内容。
The server uses the keyName-NAI to look up the rIK. It MUST first verify whether the sequence number is equal to or greater than the expected sequence number. If the server supports a sequence number window size greater than 1, it MUST verify whether the sequence number falls within the window and has not been received before. The server MUST then verify to ensure that the cryptosuite used by the peer is acceptable. The server then proceeds to verify the integrity of the message using the rIK, thereby verifying proof of possession of that key by the peer. If any of these verifications fail, the server MUST send an EAP-Finish/Re-auth message with the Result flag set to '1' (Failure). Please refer to Section 5.2.2 for details on failure handling. Otherwise, it MUST compute an rMSK from the rRK using the sequence number as the additional input to the key derivation.
サーバーは、RIKをルックアップするためのkeyName-NAIを使用しています。これは、最初のシーケンス番号が期待シーケンス番号以上であるか否かを確認しなければなりません。サーバが1よりも大きいシーケンス番号のウィンドウサイズをサポートしている場合、それはシーケンス番号がウィンドウ内に収まると、以前に受信されていないかどうかを確かめなければなりません。サーバは、ピアによって使用cryptosuiteが許容可能であることを保証するために確認しなければなりません。次に、サーバは、それによって、ピアによってそのキーの所有の証拠を確認する、RIKを使用してメッセージの完全性を検証するために進みます。これらの検証のいずれかが失敗した場合、サーバは「1」（失敗）に設定結果フラグとEAP-仕上げ/再認証メッセージを送らなければなりません。障害処理の詳細については、セクション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再認証に応答して/メッセージを開始し、サーバは、次の考慮事項とEAP-仕上げ/再認証メッセージを送信しなければなりません。
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交換をサポートしている場合、それは代わりにシーケンス番号ウィンドウを更新しなければならない1だけインクリメントされなければなりません。
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.
寿命フラグがEAP-開始/再認証メッセージに設定された場合は、ERサーバはRRK寿命とrMSK寿命を含むべきです。
The server transports the rMSK along with this message to the authenticator. The rMSK is transported in a manner similar to the MSK transport along with the EAP-Success message in a regular EAP exchange.
サーバがオーセンティケータに、このメッセージと一緒にrMSKを輸送します。 rMSKは、通常のEAP交換にEAP-Successメッセージと共にMSK輸送と同様に搬送されます。
The peer looks up the sequence number to verify whether it is expecting an EAP-Finish/Re-auth message with that sequence number protected by the keyName-NAI. It then verifies the integrity of the message. If the verifications fail, the peer logs an error and stops the process; otherwise, it proceeds to the next step.
ピアは、keyNameの-NAIによって保護そのシーケンス番号を持つEAP-仕上げ/再認証メッセージを予期しているかどうかを確認するためにシーケンス番号をルックアップします。これは、メッセージの整合性を検証します。検証が失敗した場合、ピアはエラーをログに記録し、プロセスを停止します。それ以外の場合は、次のステップに進みます。
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メッセージが正当なEAP-開始/再認証メッセージを拒否ERサーバで、その結果、順不同で到着することが妥当です。
To facilitate such operation, an ER server MAY allow multiple simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth messages with SEQ number values within a window of allowed values. Recall that the SEQ number allows replay protection. Replay window maintenance mechanisms are a local matter.
このような動作を容易にするために、ERサーバは、許容値のウィンドウ内SEQ番号値を持つすべてのEAP-開始/再認証メッセージを受け入れることによって、複数の同時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-開始/再認証メッセージの結果の処理は、ERサーバが「1」に設定結果フラグとEAP-完了再認証メッセージを送信する必要がある場合。サーバは、ピアに対して有効RIKを持っている場合、それは整合性EAP-仕上げ/再認証失敗メッセージを保護する必要があります。故障が許容できないcryptosuiteによるものである場合、サーバはEAP-仕上げ/再認証メッセージとともに（タイプ5のTLVに）許容されるcryptosuitesのリストを送ります。この場合、サーバはcryptosuiteにEAP-終了/再認証メッセージを保護するために使用cryptosuiteを示さなければなりません。 RIK新しいcryptosuiteを使用して、セクション4.3で指定されるように、この場合におけるEAP-仕上げ/再認証メッセージが計算されなければならないと共に使用しました。サーバは、ピアに対する有効なRIKを持っていない場合は、失敗を示すEAP-仕上げ/再認証メッセージが認証されていないだろう。サーバーはメッセージで許容cryptosuitesのリストを含むことができます。
The peer, upon receiving an EAP-Finish/Re-auth message with the Result flag set to '1', MUST verify the sequence number and the Authentication Tag to determine the validity of the message. If the peer supports the cryptosuite, it MUST verify the integrity of the received EAP-Finish/Re-auth message. If the EAP-Finish message contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with a cryptosuite picked from the list included by the server. The peer MUST use the appropriate rIK for the subsequent ERP exchange, by computing it with the corresponding cryptosuite, as specified in Section 4.3. If the PRF in the chosen cryptosuite is different from the PRF originally used by the peer, it MUST derive a new DSRK (if required), rRK, and rIK before proceeding with the subsequent ERP exchange.
ピアは、「1」に設定結果フラグとEAP-仕上げ/再認証メッセージを受信すると、メッセージの有効性を決定するために、シーケンス番号と認証タグを検証しなければなりません。ピアがcryptosuiteをサポートしている場合、受信したEAP-仕上げ/再認証メッセージの整合性を検証しなければなりません。 EAP-完了メッセージがタイプ5のTLVが含まれている場合、ピアは、サーバが含まリストから選択cryptosuiteとERP交換を再試行する必要があります。ピアは、セクション4.3で指定されるように、対応するcryptosuiteでそれを計算することによって、その後のERP交換のために適切なRIKを使用しなければなりません。選択されたcryptosuiteにおけるPRFが元々ピアによって使用されるPRFと異なる場合、それは新しいDSRKを導出しなければならない（必要な場合）、RRK、及びRIK後続ERP交換と進みます。
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でcryptosuitesの一つとERP交換を再試行することを選択するかもしれません。
If the replay or integrity checks fail, the failure message may have been sent by an attacker. It may also imply that the server and peer do not support the same cryptosuites; however, the peer cannot determine if that is the case. Hence, the peer SHOULD continue the ERP exchange per the retransmission timers before declaring a failure.
リプレイや整合性チェックが失敗した場合、エラーメッセージは、攻撃者によって送信された可能性があります。また、サーバーとピアが同じcryptosuitesをサポートしていないことを意味し得ます。その場合はしかしながら、ピアは判断できません。したがって、ピアは失敗を宣言する前に再送タイマーあたり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サーバは、しかし、ER認証にrMSKを送り、ピアはいつものように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].
二つの新しいEAPコードは、ERPの目的のために定義されています：EAP-開始し、EAP-フィニッシュ。これらのメッセージのパケットフォーマットは、RFC 3748で定義されたEAPパケットフォーマットを以下[2]。
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の目的のために定義されています。
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秒後にオーセンティケータ明確なEAP再認証状態ことが推奨されます。
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の交換であることを示しています。二つのタイプの値は、この目的のため、この文書で定義されている - 再AUTHスタート（割り当てタイプ1）と再認証（割り当てタイプ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-開始/再認証開始パケットは、図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-開始/再認証スタートパケット
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.
一つ以上のテレビまたはのTLVは、ピアに情報を伝えるために使用されています。例えば、オーセンティケータは、ピアにドメイン名を送信してもよいです。
TVs or TLVs: In the TV payloads, there is a 1-octet type payload and a value with type-specific length. In the TLV payloads, there is a 1-octet type payload and a 1-octet length payload. The length field indicates the length of the value expressed in number of octets.
テレビまたはのTLV：TVのペイロードに、1オクテットのタイプのペイロードとタイプ固有の長さの値が存在します。 TLVのペイロードに、1オクテットのタイプのペイロード及び1オクテットの長さのペイロードがあります。長さフィールドは、オクテットの数で表される値の長さを示します。
Domain-Name: This is a TLV payload. The Type is 4. The domain name is to be used as the realm in an NAI [4]. The Domain-Name attribute SHOULD be present in an EAP-Initiate/Re-auth-Start message.
ドメイン名：これはTLVペイロードです。タイプは、ドメイン名がNAIレルムとして使用される4である[4]。ドメイン名の属性は、EAP-開始/再-AUTH-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.
オーセンティケータは、ピアへのERPのサポートを示すために、ピアがすでに完全なEAP認証を行い、有効期限内のキーマテリアルを持っている場合はERPを開始するためにEAP-開始/再-AUTH-Startメッセージを送信することができます。オーセンティケータは、ピアが下層サポートやERPのブートストラップ交換せずにそれを学ぶことができるように、ドメイン名TLVを含むべきです。
The authenticator MAY include channel binding information so that the peer can send the information to the server in the EAP-Initiate/ Re-auth message so that the server can verify whether the authenticator is claiming the same identity to both parties.
サーバは、オーセンティケータは、双方に同一のアイデンティティを主張されているかどうかを確認できるように、ピアはEAP-開始/再認証メッセージでサーバに情報を送信できるように、オーセンティケータはチャネルバインディング情報を含むことができます。
The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start message a few times for reliable transport.
オーセンティケータは、信頼性の高い輸送用EAP-開始/再-AUTH-スタートメッセージを数回再送信してもよいです。
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.
ピアは、オーセンティケータからEAP-開始/再-AUTH-Startメッセージに応答して、EAP-開始/再認証メッセージを送信する必要があります。ピアが開始コード値を認識しない場合、それは静かにメッセージを破棄します。ピアがすでにERP交換を開始するためにEAP-開始/再認証メッセージを送信した場合、それは静かにメッセージを破棄します。
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は-開始した場合/再-AUTH-Startメッセージは、ドメイン名が含まれており、ピアがすでにドメイン情報を持っていない場合、ピアはDSRKを計算して送信するために、対応するDS-RIKを使用するドメイン名を使用する必要がありますEAP-開始/再認証ローカルERサーバとERPの交換を開始するためのメッセージ。ピアがすでにホームERサーバでERP交換を開始した場合、それはローカルERサーバとERPの交換を開始しないことを選択するかもしれません。
The EAP-Initiate/Re-auth packet contains the parameters shown in Figure 8.
EAP-開始/再認証パケットは、図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-開始/再認証パケット
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ビットのシーケンス番号は、リプレイ保護のために使用されます。 SEQ番号フィールドが0に新しいRRKが導出されるたびに初期化されます。
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.
テレビまたはのTLV：TVのペイロードに、1オクテットのタイプのペイロードとタイプ固有の長さの値が存在します。 TLVのペイロードに、1オクテットのタイプのペイロード及び1オクテットの長さのペイロードがあります。長さフィールドは、オクテットの数で表される値の長さを示します。
keyName-NAI: This is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. The EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64 bits in length and so the username portion takes up 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]。正確に一つのkeyName-NAI属性は、EAP-開始/再認証パケット内に存在しなければなりません。
In addition, channel binding information MAY be included; see Section 5.5 for discussion. See Figure 11 for parameter specification.
また、チャネルバインディング情報が含まれていてもよいです。議論のためのセクション5.5を参照してください。パラメータの指定については、図11を参照してください。
Cryptosuite: This field indicates the integrity algorithm used for ERP. Key lengths and output lengths are either indicated or are obvious from the cryptosuite name. We specify some cryptosuites below:
Cryptosuite：このフィールドは、ERPに使用整合性アルゴリズムを示しています。キーの長さと出力の長さは、いずれか、示されているかcryptosuite名前から明らかです。私たちは、以下のいくつかのcryptosuitesを指定します。
* 0 RESERVED
* 0 RESERVED
* 1 HMAC-SHA256-64
* 1 HMAC-SHA256-64
* 2 HMAC-SHA256-128
* 2 HMAC-SHA256-128
* 3 HMAC-SHA256-256
* 3 HMAC-SHA256-256
HMAC-SHA256-128 is mandatory to implement and should be enabled in the default configuration.
HMAC-SHA256-128は実装が必須であり、デフォルトの設定で有効にする必要があります。
Authentication Tag: This field contains the integrity checksum over the ERP packet, excluding the authentication tag field itself. The length of the field is indicated by the Cryptosuite.
認証タグ：このフィールドには、認証タグフィールド自体を除くERPパケットオーバー整合性チェックサムを、含まれています。フィールドの長さはCryptosuiteで示されています。
The EAP-Finish/Re-auth packet contains the parameters shown in Figure 9.
EAP-仕上げ/再認証パケットは、図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-仕上げ/再認証パケット
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ビットのシーケンス番号は、リプレイ保護のために使用されます。 SEQ番号フィールドが0に新しいRRKが導出されるたびに初期化されます。
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.
テレビまたはのTLV：TVのペイロードに、1オクテットのタイプのペイロードとタイプ固有の長さの値が存在します。 TLVのペイロードに、1オクテットのタイプのペイロード及び1オクテットの長さのペイロードがあります。長さフィールドは、オクテットの数で表される値の長さを示します。
keyName-NAI: This is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. EMSKname is in the username part of the NAI and is encoded in hexadecimal values. The EMSKname is 64 bits in length and so the username portion takes up 16 octets. If the rIK is derived from the EMSK, the realm part of the NAI is the home domain name, and if the rIK is derived from a DSRK, the realm part of the NAI is the domain name used in the derivation of the DSRK. The NAI syntax 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-仕上げ/再認証メッセージ中に存在しなければなりません。
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寿命：これはテレビのペイロードです。値フィールドは、32ビットのフィールドであり、秒単位でRRKの寿命が含ま2.です。 「L」フラグが設定されている場合は、RRK生涯属性が存在しなければなりません。
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寿命：これはテレビのペイロードです。値フィールドは、32ビットのフィールドであり、秒単位でrMSKの寿命が含ま3.です。 「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ペイロードです。タイプは、ドメイン名がNAIレルムとして使用される4である[4]。ローカルERサーバはDSRK要求を送信した場合、ブートストラップフラグが設定されている場合、ドメイン名属性は、EAP-仕上げ/再認証メッセージ中に存在しなければなりません。
List of cryptosuites: This is a TLV payload. The Type is 5. The value field contains a list of cryptosuites, each of size 1 octet. The cryptosuite values are as specified in Figure 8. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Re-auth message was not acceptable and the message is being rejected. The server MAY include this attribute in other cases. The server MAY use this attribute to signal to the peer about its cryptographic algorithm capabilities.
cryptosuitesのリスト：これはTLVペイロードです。タイプ値フィールドは、サイズのそれぞれ1つのオクテットcryptosuites、のリストを含む5です。 cryptosuite値は、図8に指定されるようにEAP-開始/再認証メッセージで使用cryptosuiteが許容可能ではなかったとのメッセージが拒否されている場合、サーバは、この属性を含むべきです。サーバーは、他のケースでは、この属性を含むかもしれません。サーバーは、その暗号アルゴリズムの機能に関するピアに知らせるために、この属性を使用するかもしれません。
Authorization Indication: This is a TLV payload. The Type is 6. This attribute MAY be included in the EAP-Finish/Re-auth message when a DSRK is delivered to a local ER server and if the home 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ペイロードです。タイプはDSRKがローカルERサーバーに配信され、ホームERサーバがローカルERサーバの許可を確認することができます場合は、ドメイン名を宣伝する場合は、この属性は、EAP-仕上げ/再認証メッセージに含まれるかもしれ6です。同じメッセージ内のドメインTLVに含まれています。 TLVの値フィールドは、計算のためにすべて0で満たされた許可指示TLVの値フィールドで、コード・フィールドの最初のビットからcryptosuiteフィールドの最後のビットに開始、パケット全体にわたって計算された認証タグが含まれています。計算に使用される鍵は、鍵ラベルとEMSKから導出されなければならないとDSRKがために導出されている鍵管理ドメインを表すASCII文字列を含む任意のデータ「DSRK配達Key@ietf.orgを承認しました」。
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：このフィールドは、整合性アルゴリズムを示し、PRFは、ERPを使用しました。キーの長さと出力の長さは、いずれか、示されているかcryptosuite名前から明らかです。
Authentication Tag: This field contains the integrity checksum over the ERP packet, excluding the authentication tag field itself. The length of the field is indicated by the Cryptosuite.
認証タグ：このフィールドには、認証タグフィールド自体を除くERPパケットオーバー整合性チェックサムを、含まれています。フィールドの長さはCryptosuiteで示されています。
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:
TLVは、それが中に存在し得る属性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 | 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寿命：これはテレビのペイロードです。
'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' - -ステーション-IDと呼ばれる[13]
'129' - Calling-Station-Id [13]
'129' - 発呼ステーション-ID [13]
'130' - NAS-Identifier [13]
'130' - NAS-識別子[13]
'131' - NAS-IP-Address [13]
'131' - NAS-IPアドレス[13]
'132' - NAS-IPv6-Address [16]
'132' - NAS-のIPv6アドレス[16]
The length field indicates the length of the value part of the attribute in octets.
長さフィールドは、オクテットで、属性の値部分の長さを示します。
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-開始/再認証メッセージでは、ピアは、シーケンス番号ゼロ以上を使用します。シーケンス番号が回転すると、RIKはEAP認証を実行することによって変更しなければならないことに留意されたいです。サーバーは、ゼロ以上のシーケンス番号を期待しています。サーバはEAP-開始/再認証メッセージを受信すると、EAP-仕上げ/再認証メッセージ中の同じシーケンス番号を使用します。次に、サーバは、サーバが期待シーケンス番号より大きいか等しいシーケンス番号を受け付け、受信したシーケンス番号+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は、セクション7.15のガイドラインによれば、チャネル結合（CB）情報を運ぶために保護機能を提供する[2]。 128から191のTLVのタイプの範囲は、EAP-開始/再authおよびEAP-仕上げ/再認証メッセージ中のCB情報を搬送するために予約されています。呼び出され-駅-ID、呼び出し-駅-ID、NAS-識別子、NAS-IP-アドレス、およびNAS-IPv6にアドレスはRFC 3748に記載されているチャネルバインディング情報のいくつかの例であり、それらは値128-132が割り当てられています。追加の値はIETFコンセンサス[17]に基づいて、IANAで管理されています。
The authenticator MAY provide CB information to the peer via the EAP-Initiate/Re-auth-Start message. The peer sends the information to the server in the EAP-Initiate/Re-auth message; the server verifies whether the authenticator identity available via AAA attributes is the same as the identity provided to the peer.
オーセンティケータはEAP-開始/再AUTH-Startメッセージを介してピアにCBの情報を提供することができます。ピアはEAP-開始/再認証メッセージでサーバに情報を送信します。サーバは、AAA属性を介して利用可能な認証者IDがピアに提供されたIDと同一であるか否かを検証します。
If the peer does not include the CB information in the EAP-Initiate/ Re-auth message, and if the local ER server's policy requires channel binding support, it SHALL send the CB attributes for the peer's verification. The peer attempts to verify the CB information if the authenticator has sent the CB parameters, and it proceeds with the lower-layer security association establishment if the attributes match. Otherwise, the peer SHALL NOT proceed with the lower-layer security association establishment.
ピアは、EAP-開始/再認証メッセージ中の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.
オーセンティケータはEAP-開始/再認証スタートメッセージの再送信を担当しています。オーセンティケータはメッセージを数回再送信することができるか、それがピアからのEAP-開始/再認証メッセージを受信するまで。オーセンティケータは、ピアが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-開始/再認証パケット内の識別子の値は、EAP-開始/再認証開始パケット内の識別子の値とは無関係です。
The peer is responsible for retransmission of EAP-Initiate/Re-auth messages.
ピアは、EAP-開始/再認証メッセージの再送信を担当しています。
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層で発生しないように、再送タイマは、無限の値に設定する必要があります。タイマーの設定に関する追加のガイダンスのために[2] RFC 3748を参照してください。
The Identifier value in the EAP-Finish/Re-auth packet is the same as the Identifier value in the EAP-Initiate/Re-auth packet.
EAP-仕上げ/再認証パケット内の識別子の値は、EAP-開始/再認証パケット内の識別子値と同じです。
If an authenticator receives a valid duplicate EAP-Initiate/Re-auth message for which it has already sent an EAP-Finish/Re-auth message, it MUST resend the EAP-Finish/Re-auth message without reprocessing the EAP-Initiate/Re-auth message. To facilitate this, the authenticator SHALL store a copy of the EAP-Finish/Re-auth message for a finite amount of time. The actual value of time is a local matter; this specification recommends a value of 100 milliseconds.
オーセンティケータは、それがすでにEAP-仕上げ/再認証メッセージを送った、それは/ EAPは-開始再処理せずにEAP-仕上げ/再認証メッセージを再送信しなければならないため、有効な複製EAP-開始/再認証メッセージを受信した場合再認証メッセージ。これを容易にするために、オーセンティケータは、有限の時間のためのEAP-仕上げ/再認証メッセージのコピーを保存するものとします。時間の実際の値は、ローカルの問題です。この仕様は、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をサポートすることに注意してください。具体的には、IEEE802.1xに仕様は、ERPをサポートするために、この文書で定義された新しいコードのEAPメッセージを運ぶ許可するように改訂されなければなりません。同様に、RFC 4306には、EAPコードがインターネット鍵交換プロトコルバージョン2（IKEv2の）とERPを使用するために、4よりも高い値が含まれるように更新する必要があります。 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実装ではなく、静かにコードでEAPパケットをドロップすることでRFC 3748に準拠しが4よりも高い値が、彼らはそれ誤り考えるかもしれないことを示しています。このような非準拠のEAPの実装に対応するため、追加的なガイダンスを以下に提供されています。さらに、いくつかの例では、すべてのピアをアップグレードすることは容易ではないかもしれません。このような場合、オーセンティケータはEAP-開始/再AUTHスタートを送信しないように構成することができます。ピアは、オーセンティケータは、下層に広告から、構成を介して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再認証プロトコルは、この要件を満たします。 MAC生成のためのピアによって選択されたアルゴリズムは、EAP-開始/再認証メッセージ中に示されています。選択されたアルゴリズムが許容できない場合、EAPサーバは障害表示とEAP-仕上げ/再認証メッセージを返します。 KDFのためのアルゴリズムの俊敏性は、[3]で指定されています。使用されるアルゴリズムは、許容可能である場合にのみ、サーバは、ピアによって、関連するキーイングマテリアルの所有の証明の鍵の導出と検証と進みます。アルゴリズムの本格的な交渉は、単一の往復プロトコルで提供することができません。プロトコルは、アルゴリズムの俊敏性を提供しながら、したがって、それは真の交渉を提供していません。
Strong, fresh session keys
強力な、新鮮なセッションキー
ERP results in the derivation of strong, fresh keys that are unique for the given session. An rMSK is always derived on-demand when the peer requires a key with a new authenticator. The derivation ensures that the compromise of one rMSK does not result in the compromise of a different rMSK at any time.
ERPは、与えられたセッションのためのユニークで強力な、新鮮な鍵の導出につながります。ピアが新しいオーセンティケータとキーを必要とするときrMSKは常にオンデマンドで導出されます。導出は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メッセージを送信した後、ピアは一つのシーケンス番号をインクリメントします。サーバは、受信したメッセージの有効性を確認した後に受信したシーケンス番号を加えたものに期待されるシーケンス番号を設定し、メッセージに応答します。
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再認証プロトコルは、ピアとサーバの相互認証を提供します。両当事者が正常に必要な鍵を導出するために、以前の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プロトコルを介して対応するローカルERサーバにドメインのDSRKを送信します。同様に、ERサーバは、AAAプロトコルを介してオーセンティケータにrMSKを送信します。
Note that compromise of the DSRK results in compromise of all keys derived from it. Moreover, there is no forward secrecy within ERP. Thus, compromise of an DSRK retroactively compromises all ERP keys.
そこから派生したすべてのキーの妥協でDSRK結果の妥協点に注意してください。また、ERP内には転送秘密はありません。このように、DSRKの妥協は遡及すべてのERPキーを損ないます。
It is RECOMMENDED that the AAA protocol be protected using IPsec or TLS so that the keys are protected in transit. Note, however, that keys may be exposed to AAA proxies along the way and compromise of any of those proxies may result in compromise of keys being transported through them.
キーが輸送中に保護されるように、AAAプロトコルはIPSecまたはTLSを使用して保護されることが推奨されます。キーはそれらを介して搬送されるキーの妥協をもたらすことができる方法及びそれらのプロキシのいずれかの妥協に沿って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.
それはそれは、もともとDSRKを受け取ったとして、最初の時間の後にDSRKを受信エンティティが同じであることを確認できない限り、ホームERサーバは、複数回のローカルドメインのサーバーに与えられたDSRKを配るてはなりません。ホームERサーバがローカルドメインサーバーの認証を検証している場合、そのドメイン回以上にDSRKを配るかもしれません。この場合、ホームERサーバはDSRKの配信が安全であるピアを保証する許可表示TLVを含んでいます。
Confirm cryptosuite selection
cryptosuite選択を確認
Crypto algorithms for integrity and key derivation in the context of ERP MAY be the same as that used by the EAP method. In that case, the EAP method is responsible for confirming the cryptosuite selection. Furthermore, the cryptosuite is included in the ERP exchange by the peer and confirmed by the server. The protocol allows the server to reject the cryptosuite selected by the peer and provide alternatives. When a suitable rIK is not available for the peer, the alternatives may be sent in an unprotected fashion. The peer is allowed to retry the exchange using one of the allowed cryptosuites. However, in this case, any en route modifications to the list sent by the server will go undetected. If the server does have an rIK available for the peer, the list will be provided in a protected manner and this issue does not apply.
ERPの文脈における完全性および鍵導出のための暗号化アルゴリズムは、EAPメソッドによって使用されるものと同じであってもよいです。その場合には、EAPメソッドはcryptosuite選択を確認する責任があります。さらに、cryptosuiteはピアによってERP交換に含まれるサーバによって確認されます。プロトコルは、サーバがピアによって選択cryptosuiteを拒否し、代替案を提供することを可能にします。適当RIKピアのために利用できない場合、代替が保護されていない方法で送信することができます。ピアは許可cryptosuitesのいずれかを使用して交換を再試行させることができます。しかし、この場合には、サーバーから送信されたリストへのエンルートの変更が検出されないままになります。サーバは、ピアのために利用できる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.
一方のピアの妥協は、システム内の他のピアによって保持された鍵材料の妥協を生じません。また、rMSKは、単一のオーセンティケータのためのものであり、他のオーセンティケータと共有されません。したがって、ある認証者の妥協は、システム内の他のオーセンティケータによって保持されるセッションまたはキーの妥協にはつながりません。したがって、EAP再認証プロトコルを適切にキー範囲を定義することにより、ドミノ効果を防止することができます。
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.
プライバシーが心配ルートERPメッセージにrIKname-NAIの使用を見出すことができるでの展開は、彼らのプライバシー要件を提供しています。 rIKnameは、ERPプロトコルの一部として変更されていないので、ERPメッセージの複数の実行を関連付けるためにもっともらしいであることに注意してください。この仕様の開発時にその要件のためのコンセンサスはありませんでした。 rIKnameが使用されず、ピアIDが代わりに使用される場合、ERP交換はワイヤ上ピア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を使用する場合、ピアにサービス拒否（DoS）攻撃を可能とすることができる開始/再認証メッセージ。攻撃者は、サーバにRADIUSアクセス - 要求内のオーセンティケータによって実施することができる偽のEAP-開始/再認証メッセージを送信することができます。応答して、サーバはEAP-完了を送信すること/再認証RADIUSアクセス拒否メッセージで失敗表示と。このような攻撃は、EAPOL開始他のリンク層におけるIEEE 802.11および他の同様の設備の能力及び場所ピアは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）を可能にするメカニズムを定義することができますキーの再生成中。これらのメカニズムは、再認証手続きが原因偽のEAP-開始/再認証メッセージに失敗したときに終了されることから、リンク層の接続を防止します。
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は、ローカルドメインのサーバーにホームERサーバから送信された場合やrMSKは、キーとエンティティを送信しているエンティティ間のエンドツーエンドのセキュリティが存在しない場合には、オーセンティケータにERサーバから送信されたとき他のエンティティが別のドメイン内のERサーバに送信されているキーへのアクセスを取得するための鍵を受け取ると、それはもっともらしいです。キー輸送のこのモードでは、EAP認証のコンテキストでMSK輸送の場合と同様です。私たちは、さらにERPは、アクセス認証のためのものであり、エンドツーエンドのデータセキュリティをサポートしていないことを確認します。典型的な実装では、トラフィックは、アクセス制御実施ポイント（オーセンティケータまたはアクセス制御を施行するためのオーセンティケータによって委任エンティティ）を超えて明らかです。モデルは、アクセスネットワークからサービスを盗むために他の当事者を対象としたキーを使用していないネットワークの途中で実体限り動作します。それが達成できない場合は、鍵配送は、エンド・ツー・エンドで保護されなければなりません。
This document specifies IANA registration of two new 'Packet Codes' from the EAP registry:
この文書では、EAPレジストリから2新しい「パケットコード」のIANA登録を指定します。
o 5 (Initiate)
お ５ （いにちあて）
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)
1 O（再認証スタート、コードを開始するためにのみ適用）
o 2 (Re-auth, applies to Initiate and Finish Codes)
O 2（RE-AUTH、開始及び終了コードに適用されます）
o 3-191 IANA managed and assigned based on IETF Consensus [17]
O 3から191 IANAが管理し、IETFコンセンサス[17]に基づいて割り当て
o 192-255 Private use
192から255私的使用O
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
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寿命：これはテレビのペイロードです。タイプは2です。
o rMSK Lifetime: This is a TV payload. The Type is 3.
O rMSK寿命：これはテレビのペイロードです。タイプは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].
7から127 O：他の非チャネル結合関連の属性を運ぶために使用されます。 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のタイプの範囲がでCB情報を搬送するために予約されているEAP-開始/再authおよびEAP-仕上げ/再認証メッセージ。以下は、現在の割り当ては、（それらのすべてがTLVをしている）、次のとおりです。
* Called-Station-Id: 128
*呼び出され-駅-ID：128
* Calling-Station-Id: 129
*呼び出し-駅-ID：129
* NAS-Identifier: 130
* NAS-識別子：130
* NAS-IP-Address: 131
* NAS-IP-住所：131
* NAS-IPv6-Address: 132
* NAS-IPv6の-住所：132
133-191: Used to carry other channel-binding-related attributes. IANA managed and assigned based on IETF Consensus [17].
133から191：他のチャネル結合関連の属性を運ぶために使用されます。 IANAが管理し、IETFコンセンサス[17]に基づいて割り当てられます。
o 192-255: Reserved for Private use.
192から255 O：私的使用のために予約されています。
We specify creation of another registry, 'Re-authentication Cryptosuites', with the following assigned numbers:
我々は、次の割り当てられた番号で、「再認証Cryptosuites」、別のレジストリの作成を指定します。
o 0: Reserved
0：予約済み
o 1: HMAC-SHA256-64
約1：HMAC-SHA256-64
o 2: HMAC-SHA256-128
約2：HMAC-SHA256-128
o 3: HMAC-SHA256-256
約3：HMAC-SHA256-256
o 4-191: IANA managed and assigned based on IETF consensus [17]
4から191 O：IANAが管理し、IETFコンセンサスに基づいて割り当てられた[17]
o 192-255: Reserved for Private use.
192から255 O：私的使用のために予約されています。
Further, this document registers a Re-auth usage label from the "USRK Key Labels" name space with a value
さらに、このドキュメントでは、値で名前空間を「USRKキーがラベル」からの再認証の使用ラベルを登録します
EAP Re-authentication Root Key@ietf.org
EAP再認証ルートKey@ietf.org
and DSRK-authorized delivery key from the "USRK Key Labels" name space
「USERキーラベル」名前空間からとDARK-認可配信キー
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.
この文書を書くには、我々はバーナードAboba、ヤリArkko、サム・ハートマン、ラスHousley、ジョーSalowey、ジェシーウォーカー、チャールズ・クランシー、ミカエラVANDERVEEN、ケダルGaonkar、Parag含めた人々の数の問題空間とプロトコル自体を議論の恩恵を受けAgashe、ディネッシュDharmaraju、パシEronen、ダンハーキンズ、ヨシ大場、グレン・ソーン、アランDeKok、カトリンHoeper、およびHOKEYワーキンググループの他の参加者。 EAPは、開始/再-AUTH-Startを使用するという考えのためのクレジットは、チャールズ・クランシーに移行し、DoS攻撃を軽減するために、複数のリンク層のSAのアイデアはヨッシー大場に行きます。カトリンHoeperは、複数の同時ER交換を処理するために、ウィンドウ技術を使用することを示唆しました。 keyNameの-NAIフィールドの一部として送信される場合rIKnameため進符号化を使用するように提案するためのパシEronenに感謝。 ERPメッセージのAAA輸送を指定する際に助けのためのEAPロックステップ動作を明確にする提案のためのバーナードAbobaのおかげで、ジョーSaloweyとグレンツォルン。 DSRK許可表示のメカニズムのためのサム・ハートマンに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[2] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、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.、ナラヤナン、V.、およびM. Nakhjiri、RFC 5295、2008年8月 "拡張マスタセッションキー（EMSK）からルート鍵の導出のための仕様"。
[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.、ベラー、M.、およびR.カネッティ、 "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]ロペス、R.、SkarmetaのA.、Bournelle、J.、ローランMaknavicus、M.、およびJ. Combesの、 "セキュアモビリティ・アクセス・サービスのための改善されたEAPキーイングフレームワーク"、IWCMC '06、プロシーディングス2006無線通信に関する国際会議やモバイルコンピューティング、ニューヨーク、NY、USA、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]クランシー、T.、Nakhjiri、M.、ナラヤナン、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 802.1X STD-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.大場、「ハンドオーバーおよび再認証のための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.、ナラヤナン、V.、およびG.ツォルン、 "EAP再認証プロトコルのためのRADIUSのサポート"、進歩、2008年2月に作業。
[13] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤルイン" [13] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン。
[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.カルフーン、 "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.、ゾルン、G.、およびD.ミットン、 "RADIUSと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。およびB. Aboba、 "認証、許可、アカウンティング（AAA）キー管理のための指針"、BCP 132、RFC 4962、2007年7月。
Appendix A. Example ERP Exchange
付録A.例ERP取引所
1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,Auth-tag*)
1.ピア - >認証：EAPは、開始/ RE-AUTH（SEQ、keyNameの-NAI、cryptosuite、認証タグ*）
1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, EAP Initiate/Re-auth(SEQ,keyName-NAI, cryptosuite,Auth-tag*)
図1a。オーセンティケータ - >再認証サーバー：AAA-要求{認証-ID、EAPは、開始/再認証（SEQ、keyNameの-NAI、cryptosuite、認証タグ*）
2. ER-Server --> Authenticator: AAA-Response{rMSK, EAP-Finish/Re-auth(SEQ,keyName-NAI, cryptosuite,[CB-Info],Auth-tag*)
2. ER-サーバ - >認証：AAA-応答{rMSK、EAP-終了/再認証（SEQ、keyNameの-NAI、cryptosuite、[CB-INFO]、認証タグ*）
2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, cryptosuite,[CB-Info],Auth-tag*)
図2b。オーセンティケータ - >ピア：EAP-仕上げ/再認証（SEQ、keyNameの-NAI、cryptosuite、[CB-INFO]、認証タグ*）
* Auth-tag computation is over the entire EAP Initiate/Finish message; the code values for Initiate and Finish are different and thus reflection attacks are mitigated.
*認証タグ計算は全体のEAP開始/終了メッセージを超えています。開始および終了のためのコード値は異なるので、反射攻撃が軽減されています。
Authors' Addresses
著者のアドレス
Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr. San Diego, CA 92121 USA
Vidyaナラヤナンクアルコム社5775モアハウス博士サンディエゴ、CA 92121 USA
Phone: +1 858-845-2483 EMail: vidyan@qualcomm.com
電話：+1 858-845-2483電子メール：vidyan@qualcomm.com
Lakshminath Dondeti Qualcomm, Inc. 5775 Morehouse Dr. San Diego, CA 92121 USA
Lakshminath Dandetiクアルコム、これ。 5775 Morehuse博士サンディエゴ、92121それ
Phone: +1 858-845-1267 EMail: ldondeti@qualcomm.com
電話：+1 858-845-1267電子メール：ldondeti@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。