[要約] RFC 6630は、認証済みの予測鍵付き再認証プロトコル拡張（ERP/AAK）に関するものであり、EAP再認証プロトコルの拡張を提供します。目的は、再認証プロセスの効率化とセキュリティの向上です。
Internet Engineering Task Force (IETF) Z. Cao
Request for Comments: 6630 H. Deng
Category: Standards Track China Mobile
ISSN: 2070-1721 Q. Wu
Huawei
G. Zorn, Ed.
Network Zen
June 2012
EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)
Authenticated Anticipatory Keying（ERP / AAK）用のEAP再認証プロトコル拡張
Abstract
概要
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.
拡張認証プロトコル（EAP）は、複数のタイプの認証方法をサポートする一般的なフレームワークです。
The EAP Re-authentication Protocol (ERP) 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.
EAP再認証プロトコル（ERP）は、EAPおよびEAPキーイング階層の拡張を指定して、任意の認証システムを介したピアとEAP再認証サーバー間の効率的な再認証のためのEAPメソッドに依存しないプロトコルをサポートします。
Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or more Candidate Attachment Points (CAPs) prior to handover. AAK uses the AAA infrastructure for key transport.
Authenticated Anticipatory Keying（AAK）は、ハンドオーバーの前に1つまたは複数の候補接続点（CAP）で暗号化キーイング資料を確立できる方法です。 AAKはキー転送にAAAインフラストラクチャを使用します。
This document specifies the extensions necessary to enable AAK support in ERP.
このドキュメントでは、ERPでAAKサポートを有効にするために必要な拡張機能を指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6630.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6630で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. ERP/AAK Description . . . . . . . . . . . . . . . . . . . . . 4
4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 7
4.1. Derivation of the pRK and pMSK . . . . . . . . . . . . . . 8
5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 9
5.1. EAP-Initiate/Re-auth-Start Packet and TLV Extension . . . 9
5.2. EAP-Initiate/Re-auth Packet and TLV Extension . . . . . . 10
5.3. EAP-Finish/Re-auth Packet and TLV Extension . . . . . . . 12
5.4. TV and TLV Attributes . . . . . . . . . . . . . . . . . . 14
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 15
7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 19
The Extensible Authentication Protocol (EAP) [RFC3748] is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable not to repeat the entire EAP exchange with another authenticator. The EAP Re-authentication Protocol (ERP) [RFC5296] specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the EAP re-authentication 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 mobile host (i.e., the EAP re-authentication peer) is connecting.
拡張認証プロトコル（EAP）[RFC3748]は、複数のタイプの認証方法をサポートする一般的なフレームワークです。認証にEAPが使用されるシステムでは、別の認証システムとのEAP交換全体を繰り返さないことが望ましいです。 EAP再認証プロトコル（ERP）[RFC5296]は、EAPの拡張機能とEAPキー階層を指定して、EAP方式に依存しないプロトコルをサポートし、EAP再認証ピアとEAP再認証サーバー間の再認証を効率的に行います。オーセンティケーター。再認証サーバは、モバイルホスト（つまり、EAP再認証ピア）が接続しているホームネットワークまたはローカルネットワークにある可能性があります。
Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by which cryptographic keying material may be established upon one or more Candidate Attachment Points (CAPs) prior to handover. AAK utilizes the AAA infrastructure for key transport.
Authenticated Anticipatory Keying（AAK）[RFC5836]は、ハンドオーバーの前に1つ以上の候補接続ポイント（CAP）で暗号化キーイング資料を確立できる方法です。 AAKは、鍵の転送にAAAインフラストラクチャを利用します。
This document specifies the extensions necessary to enable AAK support in ERP.
このドキュメントでは、ERPでAAKサポートを有効にするために必要な拡張機能を指定します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The following acronyms are used in this document; see the references for more details.
このドキュメントでは、次の頭字語を使用しています。詳細については、リファレンスを参照してください。
AAA Authentication, Authorization, and Accounting [RFC3588]
AAA認証、承認、およびアカウンティング[RFC3588]
CAP Candidate Attachment Point [RFC5836]
CAP候補接続ポイント[RFC5836]
DSRK Domain-Specific Root Key [RFC5295]
DARKドメイン固有のルートキー[RFC5295]
EA Abbreviation for "ERP/AAK"
EA「ERP / AAK」の略語
EA Peer An EAP peer that supports the ERP/AAK. Note that all references to "peer" in this document imply an EA peer, unless specifically noted otherwise.
EAピアERP / AAKをサポートするEAPピア。特に明記しない限り、このドキュメントでの「ピア」へのすべての言及はEAピアを意味することに注意してください。
NAI Network Access Identifier [RFC4282]
ない ねとぉｒｋ あっせっｓ いでんちふぃえｒ 「ＲＦＣ４２８２」
pMSK pre-established Master Session Key
pMSKが事前に確立したマスターセッションキー
pRK pre-established Root Key
pRKが事前に確立したルートキー
rIK re-authentication Integrity Key [RFC5296]
rIK再認証整合性キー[RFC5296]
rRK re-authentication Root Key [RFC5296]
rRK再認証ルートキー[RFC5296]
SAP Serving Attachment Point [RFC5836]
SAPサービス接続ポイント[RFC5836]
ERP/AAK is intended to allow (upon request by the peer) the establishment of cryptographic keying materials on a single Candidate Attachment Point prior to the arrival of the peer at the Candidate Access Network (CAN).
ERP / AAKは、ピアが候補アクセスネットワーク（CAN）に到着する前に、単一の候補アタッチメントポイントに暗号化キー情報を（ピアからの要求に応じて）確立できるようにすることを目的としています。
In this document, ERP/AAK support by the peer is assumed. Also, it is assumed that the peer has previously completed full EAP authentication and that either the peer or the SAP knows the identities of neighboring attachment points. Note that the behavior of a peer that does not support the ERP-AAK scheme defined in this specification is out of the scope of this document. Figure 1 shows the general protocol exchange by which the keying material is established on the CAP.
このドキュメントでは、ピアによるERP / AAKサポートを想定しています。また、ピアは以前に完全なEAP認証を完了しており、ピアまたはSAPのいずれかが隣接する接続ポイントのIDを知っていると想定されています。この仕様で定義されているERP-AAKスキームをサポートしないピアの動作は、このドキュメントの範囲外であることに注意してください。図1は、CAPでキー情報が確立される一般的なプロトコル交換を示しています。
+------+ +-----+ +-----+ +-----------+
| Peer | | SAP | | CAP | | EA Server |
+--+---+ +--+--+ +--+--+ +-----+-----+
| | | |
a. | [EAP-Initiate/ | | |
| Re-auth-start | | |
| (E flag)] | | |
|<---------------| | |
| | | |
b. | EAP-Initiate/ | | |
| Re-auth | | |
| (E flag) | | |
|--------------->| | |
c. | | AAA(EAP-Initiate/Re-auth(E flag))|
| |--------------------------------->|
| | | +---------+---------+
| | | | CA authorized & |
d. | | | | and EA Keying |
| | | | Distribution |
| | | +---------+---------+
| | | |
| | | |
f. | | AAA (EAP-Finish/Re-auth(E flag)) |
| |<---------------------------------|
g. | EAP-Finish/ | | |
| Re-auth(E flag)| | |
|<---------------| | |
| | | |
Figure 1: ERP/AAK Exchange
図1：ERP / AAK交換
+-----------+ +---------+
| | | |
| EA Server | | CAP |
| | | |
+-----|-----+ +----|----+
| |
| |
| AAA Request (pMSK) |
e.1|------------------------->|
| |
| |
| |
| AAA Response (Success) |
e.2|<-------------------------|
| |
| |
| |
Figure 2: Key Distribution for ERP/AAK
図2：ERP / AAKのキー配布
ERP/AAK reuses the packet format defined by ERP, but specifies a new flag to differentiate EAP early authentication from EAP re-authentication. The peer initiates ERP/AAK without an external trigger, or initiates ERP/AAK in response to an EAP-Initiate/ Re-Auth-Start message from the SAP.
ERP / AAKは、ERPで定義されたパケット形式を再利用しますが、EAP早期認証とEAP再認証を区別するために新しいフラグを指定します。ピアは、外部トリガーなしでERP / AAKを開始するか、SAPからのEAP-Initiate / Re-Auth-Startメッセージに応答してERP / AAKを開始します。
In the latter case, the SAP MAY send the identity of one or more Candidate Attachment Points to which the SAP is adjacent to the peer in the EAP-Initiate/Re-auth-Start message (see step a in Figure 1). The peer SHOULD override the identity of CAP(s) carried in the EAP-Initiate/Re-auth-Start message by sending EAP-Initiate/Re-auth with the E flag set if it knows to which CAP it will move. If the EAP-Initiate/Re-auth-Start packet is not supported by the peer, it MUST be silently discarded.
後者の場合、SAPは、EAP-Initiate / Re-auth-Startメッセージで、SAPがピアに隣接している1つまたは複数の候補接続ポイントのIDを送信できます（図1のステップaを参照）。ピアは、移動するCAPがわかっている場合、E-フラグを設定してEAP-Initiate / Re-auth-Startを送信することにより、EAP-Initiate / Re-auth-Startメッセージで伝送されるCAPのIDをオーバーライドする必要があります。 EAP-Initiate / Re-auth-Startパケットがピアでサポートされていない場合は、黙って破棄する必要があります。
If the peer initiates ERP/AAK, the peer MAY send an early-authentication request message (EAP-Initiate/Re-auth with the E flag set) containing the keyName-NAI, the CAP-Identifier, rIK, and sequence number (see step b in Figure 1). The realm in the keyName-NAI field is used to locate the peer's ERP/AAK server. The CAP-Identifier is used to identify the CAP. The re-authentication Integrity Key (rIK) is defined by Narayanan & Dondeti in [RFC5296] and is used to protect the integrity of the message. The sequence number is used for replay protection.
ピアがERP / AAKを開始する場合、ピアは、keyName-NAI、CAP-Identifier、rIK、およびシーケンス番号を含む早期認証要求メッセージ（Eフラグが設定されたEAP-Initiate / Re-auth）を送信できます（参照してください）。図1のステップb）。 keyName-NAIフィールドのレルムは、ピアのERP / AAKサーバーを見つけるために使用されます。 CAP-Identifierは、CAPを識別するために使用されます。再認証整合性キー（rIK）は、[RFC5296]でNarayanan＆Dondetiによって定義されており、メッセージの整合性を保護するために使用されます。シーケンス番号は、リプレイ保護に使用されます。
The SAP SHOULD verify the integrity of this message at step b. If this verification fails, the SAP MUST send an EAP-Finish/Re-auth message with the Result flag set to '1' (Failure). If the verification succeeds, the SAP SHOULD encapsulate the early-authentication message into a AAA message and send it to the peer's ERP/AAK server in the realm indicated in the keyName-NAI field (see step c in Figure 1).
SAPは、ステップbでこのメッセージの整合性を検証する必要があります（SHOULD）。この検証が失敗した場合、SAPは、結果フラグを「1」に設定したEAP-Finish / Re-authメッセージを送信する必要があります（失敗）。検証が成功した場合、SAPは早期認証メッセージをAAAメッセージにカプセル化し、それをkeyName-NAIフィールドに示されているレルムのピアのERP / AAKサーバーに送信する必要があります（図1のステップcを参照）。
Upon receiving the message, the ERP/AAK server MUST first use the keyName indicated in the keyName-NAI to look up the rIK and check the integrity and freshness of the message. Then, the ERP/AAK server MUST verify the identity of the peer by checking the username portion of the KeyName-NAI. If any of the checks fail, the server MUST send an early-authentication finish message (EAP-Finish/Re-auth with E flag set) with the Result flag set to '1'. Next, the server MUST authorize the CAP specified in the CAP-Identifier TLV. In the success case, the server MUST derive a pMSK from the pRK for the CAP carried in the CAP-Identifier field using the sequence number associated with CAP-Identifier as an input to the key derivation. (see step d in Figure 1).
メッセージを受信すると、ERP / AAKサーバーは最初にkeyName-NAIに示されているkeyNameを使用してrIKを検索し、メッセージの整合性と鮮度を確認する必要があります。次に、ERP / AAKサーバーは、KeyName-NAIのユーザー名部分をチェックして、ピアのIDを確認する必要があります。いずれかのチェックが失敗した場合、サーバーはResultフラグが「1」に設定された早期認証終了メッセージ（Eフラグが設定されたEAP-Finish / Re-auth）を送信する必要があります。次に、サーバーはCAP-Identifier TLVで指定されたCAPを承認する必要があります。成功した場合、サーバーは、CAP-Identifierに関連付けられたシーケンス番号をキー導出への入力として使用して、CAP-Identifierフィールドに含まれるCAPのpRKからpMSKを導出する必要があります。 （図1のステップdを参照）。
Then, the ERP/AAK server MUST transport the pMSK to the authorized CAP via AAA (see Section 7) as illustrated above (see steps e.1 and e.2 in Figure 2). Note that key distribution in Figure 2 is one part of step d in Figure 1.
次に、ERP / AAKサーバーは、上に示したように（図2のステップe.1およびe.2を参照）、AAA（セクション7を参照）を介して、承認されたCAPにpMSKを転送する必要があります。図2の鍵配布は、図1のステップdの一部であることに注意してください。
Finally, in response to the EAP-Initiate/Re-auth message, the ERP/AAK server SHOULD send the early-authentication finish message (EAP-- -Finish/Re-auth with E flag set) containing the identity of the authorized CAP to the peer via the SAP along with the lifetime of the pMSK. If the peer also requests the rRK Lifetime, the ERP/AAK server SHOULD send the rRK Lifetime in the EAP-Finish/Re-auth message (see steps f and g in Figure 1).
最後に、EAP-Initiate / Re-authメッセージに応答して、ERP / AAKサーバーは、承認済みCAPのIDを含む早期認証終了メッセージ（EAP-- -Finish / Re-auth with Eフラグセット）を送信する必要があります（SHOULD）。 SAPを介してピアに、pMSKのライフタイムとともに。ピアがrRKライフタイムも要求する場合、ERP / AAKサーバーはEAP-Finish / Re-authメッセージでrRKライフタイムを送信する必要があります（図1のステップfおよびgを参照）。
ERP/AAK uses a key hierarchy similar to that of ERP. The ERP/AAK pre-established Root Key (pRK) is derived from either the EMSK or the DSRK as specified below (see Section 4.1). In general, the pRK is derived from the EMSK if the peer is located in the home AAA realm and derived from the DSRK if the peer is in a visited realm. The DSRK is delivered from the EAP server to the ERP/AAK server as specified in [KEYTRAN]. If the peer has previously been authenticated by means of ERP or ERP/AAK, the DSRK SHOULD be directly reused.
ERP / AAKは、ERPと同様のキー階層を使用します。 ERP / AAKの事前に確立されたルートキー（pRK）は、EMSKまたはDSRKのいずれかから導出されます（以下のセクション4.1を参照）。通常、pRKは、ピアがホームAAAレルムにある場合はEMSKから派生し、ピアが訪問済みレルムにある場合はDSRKから派生します。 DSRKは、[KEYTRAN]で指定されているように、EAPサーバーからERP / AAKサーバーに配信されます。ピアが以前にERPまたはERP / AAKによって認証されている場合は、DSRKを直接再利用する必要があります（SHOULD）。
DSRK EMSK
| |
+---+---+---+---+
|
pRK ...
Figure 3: ERP/AAK Root Key Derivation
図3：ERP / AAKルートキーの導出
Similarly, the pre-established Master Session Key (pMSK) is derived from the pRK. The pMSK is established for the CAP when the peer early authenticates to the network. The hierarchy relationship is illustrated Figure 4, below.
同様に、事前に確立されたマスターセッションキー（pMSK）は、pRKから取得されます。ピアがネットワークに対して早期に認証されると、CAPに対してpMSKが確立されます。階層関係を図4に示します。
pRK
|
+--------+--------+
|
pMSK ...
Figure 4: ERP/AAK Key Hierarchy
図4：ERP / AAKキー階層
The rRK is derived as specified in [RFC5295].
rRKは[RFC5295]で指定されているように導出されます。
pRK = KDF (K, S), where
pRK = KDF（K、S）、ここで
K = EMSK or K = DSRK and
K = AND KまたはK = DARKおよび
S = pRK Label | "\0" | length
S = pRKラベル| 「\ 0」|長さ
The pRK Label is an IANA-assigned 8-bit ASCII string:
pRKラベルは、IANAが割り当てた8ビットASCII文字列です。
EAP Early-Authentication Root Key@ietf.org
EAP Early-Authentication Root Key@ietf.org
assigned from the "User Specific Root Keys (USRK) Key Labels" name space in accordance with Salowey, et al. [RFC5295]. The KDF and algorithm agility for the KDF are also defined in RFC 5295. The KDF algorithm is indicated in the cryptosuite field or list of cryptosuites TLV payload as specified in Sections 5.2 and 5.3.
Saloweyらによると、「ユーザー固有のルートキー（USRK）キーラベル」名前空間から割り当てられます。 [RFC5295]。 KDFおよびKDFのアルゴリズムの俊敏性は、RFC 5295でも定義されています。KDFアルゴリズムは、セクション5.2および5.3で指定されているように、cryptosuiteフィールドまたはcryptosuites TLVペイロードのリストに示されています。
The pMSK uses the same KDF as pRK and is derived as follows:
pMSKはpRKと同じKDFを使用し、次のように導出されます。
pMSK = KDF (K, S), where
pMSK = KDF（K、S）、ここで
K = pRK and
S = pMSK label | "\0" | SEQ | length
S = pMSKラベル| 「\ 0」| SEQ |長さ
The pMSK label is the 8-bit ASCII string:
pMSKラベルは8ビットのASCII文字列です。
EAP Early-Authentication Master Session Key@ietf.org
EAP早期認証マスターセッションKey@ietf.org
The length field refers to the length of the pMSK in octets encoded as specified in RFC 5295. SEQ is sent by either the peer or the server in the ERP/AAK message using the SEQ field or the Sequence number TLV. It is encoded as a 16-bit number as specified in Sections 5.2 and 5.3.
長さフィールドは、RFC 5295で指定されているようにエンコードされたオクテットのpMSKの長さを参照します。SEQは、SEQフィールドまたはシーケンス番号TLVを使用して、ERP / AAKメッセージでピアまたはサーバーによって送信されます。セクション5.2および5.3で指定されている16ビットの数値としてエンコードされます。
This section describes the packet and TLV extensions for the ERP/AAK exchange.
このセクションでは、ERP / AAK交換用のパケットおよびTLV拡張について説明します。
Figure 5 shows the new parameters contained in the EAP-Initiate/ Re-auth-Start packet defined in [RFC5296].
図5は、[RFC5296]で定義されているEAP-Initiate / Re-auth-Startパケットに含まれる新しいパラメーターを示しています。
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 |E| Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EAP-Initiate/Re-auth-Start Extension
図5：EAP-Initiate / Re-auth-Start拡張
Flags
旗
'E' - The E flag is used to indicate early authentication. This field MUST be set to '1' if early authentication is in use, and it MUST be set to '0' otherwise.
'E'-Eフラグは、早期認証を示すために使用されます。このフィールドは、早期認証が使用されている場合は「1」に設定する必要があり、そうでない場合は「0」に設定する必要があります。
The rest of the 7 bits (Reserved) MUST be set to 0 and ignored on reception.
残りの7ビット（予約済み）は0に設定し、受信時には無視する必要があります。
Type/Values (TVs) and TLVs
タイプ/値（TV）とTLV
CAP-Identifier: Carried in a TLV payload. The format is identical to that of a DiameterIdentity [RFC3588]. It is used by the SAP to advertise the identity of the CAP to the peer. Exactly one CAP-Identifier TLV MAY be included in the EAP-Initiate/Re-auth-Start packet if the SAP has performed CAP discovery.
CAP-Identifier：TLVペイロードで伝送されます。形式は、DiameterIdentity [RFC3588]の形式と同じです。 SAPはこれを使用して、CAPのIDをピアにアドバタイズします。 SAPがCAPディスカバリーを実行した場合、EAP-Initiate / Re-auth-Startパケットに含まれるCAP-Identifier TLVは1つだけです。
If the EAP-Initiate/Re-auth-Start packet is not supported by the peer, it SHOULD be discarded silently.
EAP-Initiate / Re-auth-Startパケットがピアでサポートされていない場合は、サイレントに破棄する必要があります（SHOULD）。
Figure 6 illustrates the new parameters contained in the EAP-Initiate/Re-auth packet defined in [RFC5296].
図6は、[RFC5296]で定義されているEAP-Initiate / Re-authパケットに含まれる新しいパラメーターを示しています。
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|x|L|E|Resved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: EAP-Initiate/Re-auth Extension
図6：EAP-Initiate / Re-auth拡張
Flags
旗
'x' - The x flag is reserved. It MUST be ignored on receipt.
'x'-xフラグは予約されています。受信時には無視する必要があります。
'L' - As defined in Section 5.3.2 of [RFC5296], this bit is used to request the key lifetimes from the server.
「L」-[RFC5296]のセクション5.3.2で定義されているように、このビットはサーバーにキーの有効期間を要求するために使用されます。
'E' - The E flag is used to indicate early authentication.
'E'-Eフラグは、早期認証を示すために使用されます。
The first bit(R) and final 4 bits (Resved) MUST be set to 0 and ignored on reception.
最初のビット（R）と最後の4ビット（Resved）は0に設定されなければならず、受信時には無視されなければなりません。
SEQ
配列
As defined in Section 5.3.2 of [RFC5296], this field is 16-bit sequence number and used for replay protection.
[RFC5296]のセクション5.3.2で定義されているように、このフィールドは16ビットのシーケンス番号であり、リプレイ保護に使用されます。
TVs and TLVs
TVとTLV
keyName-NAI: As defined in [RFC5296], this is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. The username part of the NAI is the EMSKname used to identify the peer. The realm part of the NAI is the peer's home domain name if the peer communicates with the home EA server or the domain to which the peer is currently attached (i.e., local domain name) if the peer communicates with a local EA server. The SAP knows whether the KeyName-NAI carries the local domain name by comparing the domain name carried in the KeyName-NAI with the local domain name that is associated with the SAP. Exactly one keyName-NAI attribute SHALL be present in an EAP-Initiate/Re-auth packet and the realm part of it SHOULD follow the use of internationalized domain names defined in [RFC5890].
keyName-NAI：[RFC5296]で定義されているように、これはTLVペイロードで伝送されます。タイプは1です。NAIの長さは可変で、253オクテットを超えません。 NAIのユーザー名部分は、ピアを識別するために使用されるEMSKnameです。 NAIのレルム部分は、ピアがホームEAサーバーと通信する場合のピアのホームドメイン名、またはピアがローカルEAサーバーと通信する場合にピアが現在接続されているドメイン（つまり、ローカルドメイン名）です。 SAPは、KeyName-NAIに含まれるドメイン名をSAPに関連付けられているローカルドメイン名と比較することにより、KeyName-NAIにローカルドメイン名が含まれるかどうかを認識します。厳密に1つのkeyName-NAI属性がEAP-Initiate / Re-authパケットに存在する必要があり（SHALL）、そのレルム部分は[RFC5890]で定義されている国際化ドメイン名の使用に従う必要があります。
CAP-Identifier: Carried in a TLV payload. The Type is 11. This field is used to indicate the Fully Qualified Domain Name (FQDN) of a CAP. The value field MUST be encoded as specified in Section 8 of [RFC3315]. Exactly one instance of the CAP-Identifier TLV MUST be present in the ERP/AAK-Key TLV.
CAP-Identifier：TLVペイロードで伝送されます。タイプは11です。このフィールドは、CAPの完全修飾ドメイン名（FQDN）を示すために使用されます。値フィールドは、[RFC3315]のセクション8で指定されているようにエンコードする必要があります。 CAP-Identifier TLVのインスタンスが1つだけERP / AAK-Key TLVに存在している必要があります。
Sequence number: The Type is 7. The value field is a 16-bit field and used in the derivation of the pMSK for a CAP.
シーケンス番号：タイプは7です。値フィールドは16ビットのフィールドで、CAPのpMSKの派生に使用されます。
Cryptosuite
暗号スイート
This field indicates the integrity algorithm used for ERP/AAK. Key lengths and output lengths are either indicated or obvious from the cryptosuite name, e.g., HMAC-SHA256-128 denotes Hashed Message Authentication Code (HMAC) computed using the SHA-256 function [RFC4868] with 256-bit key length and the output truncated to 128 bits [RFC2104]. We specify some cryptosuites below:
このフィールドは、ERP / AAKに使用される整合性アルゴリズムを示します。鍵の長さと出力の長さは、暗号スイート名から示されるか、明らかです。たとえば、HMAC-SHA256-128は、SHA-256関数[RFC4868]を使用して計算され、256ビットの鍵長と出力が切り捨てられたハッシュメッセージ認証コード（HMAC）を示します。 128ビットまで[RFC2104]。以下にいくつかの暗号スイートを指定します。
0-1 RESERVED
0-1予約済み
2 HMAC-SHA256-128
2 HMAC-SHA256-128
3 HMAC-SHA256-256
3 HMAC-SHA256-256
HMAC-SHA256-128 is REQUIRED to implement, and it SHOULD be enabled in the default configuration.
HMAC-SHA256-128の実装は必須であり、デフォルトの構成で有効にする必要があります（SHOULD）。
Authentication Tag
認証タグ
This field contains an integrity checksum over the ERP/AAK packet from the first bit of the Code field to the last bit of the Cryptosuite field, excluding the Authentication Tag field itself. The value field is calculated using the integrity algorithm indicated in the Cryptosuite field and rIK specified in [RFC5296] as the secret key. The length of the field is indicated by the Cryptosuite.
このフィールドには、認証タグフィールド自体を除いて、コードフィールドの最初のビットから暗号スイートフィールドの最後のビットまでのERP / AAKパケットの整合性チェックサムが含まれています。値フィールドは、Cryptosuiteフィールドに示されている整合性アルゴリズムと、[RFC5296]で指定されているrIKを秘密鍵として使用して計算されます。フィールドの長さは、Cryptosuiteによって示されます。
The peer uses the Authentication Tag to determine the validity of the EAP-Finish/Re-auth message from the server.
ピアは認証タグを使用して、サーバーからのEAP-Finish / Re-authメッセージの有効性を判断します。
If the message doesn't pass verification or the Authentication Tag is not included in the message, the message SHOULD be discarded silently.
メッセージが検証に合格しない場合、または認証タグがメッセージに含まれていない場合、メッセージは通知なく破棄されるべきです（SHOULD）。
If the EAP-Initiate/Re-auth packet is not supported by the SAP, it SHOULD be discarded silently. The peer MUST maintain retransmission timers for reliable transport of the EAP-Initiate/Re-auth message. If there is no response to the EAP-Initiate/Re-auth message from the server after the necessary number of retransmissions (see Section 6), the peer MUST assume that ERP/AAK is not supported by the SAP.
EAP-Initiate / Re-authパケットがSAPでサポートされていない場合、サイレントに破棄する必要があります（SHOULD）。ピアは、EAP-Initiate / Re-authメッセージの信頼できるトランスポートのために再送信タイマーを維持する必要があります。必要な数の再送信後（セクション6を参照）、サーバーからのEAP-Initiate / Re-authメッセージへの応答がない場合、ピアはERP / AAKがSAPでサポートされていないと想定しなければなりません（MUST）。
Figure 7 shows the new parameters contained in the EAP-Finish/Re-auth packet defined in [RFC5296].
図7は、[RFC5296]で定義されているEAP-Finish / Re-authパケットに含まれる新しいパラメータを示しています。
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|x|L|E|Resved | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: EAP-Finish/Re-auth Extension
図7：EAP-Finish / Re-auth拡張
Flags
旗
'R' - As defined in Section 5.3.3 of [RFC5296], this bit is used as the Result flag. This field MUST be set to '1' to indicate success, and it MUST be set to '0' otherwise.
'R'-[RFC5296]のセクション5.3.3で定義されているように、このビットは結果フラグとして使用されます。このフィールドは、成功を示すために「1」に設定する必要があり、そうでない場合は「0」に設定する必要があります。
'x' - The x flag is reserved. It MUST be ignored on receipt.
'x'-xフラグは予約されています。受信時には無視する必要があります。
'L' - As defined in Section 5.3.3 of [RFC5296], this bit is used to request the key lifetimes from the server.
'L'-[RFC5296]のセクション5.3.3で定義されているように、このビットはサーバーにキーの有効期間を要求するために使用されます。
'E' - The E flag is used to indicate early authentication.
'E'-Eフラグは、早期認証を示すために使用されます。
The final 4 bits (Resved) MUST be set to 0 and ignored on reception.
最後の4ビット（Resved）は0に設定され、受信時には無視される必要があります。
SEQ
シーケンス
As defined in Section 5.3.3 of [RFC5296], this field is a 16-bit sequence number and is used for replay protection.
[RFC5296]のセクション5.3.3で定義されているように、このフィールドは16ビットのシーケンス番号であり、リプレイ保護に使用されます。
TVs and TLVs
TVとTLV
keyName-NAI: As defined in [RFC5296], this is carried in a TLV payload. The Type is 1. The NAI is variable in length, not exceeding 253 octets. Exactly one keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth packet.
keyName-NAI：[RFC5296]で定義されているように、これはTLVペイロードで伝送されます。タイプは1です。NAIの長さは可変で、253オクテットを超えません。厳密に1つのkeyName-NAI属性がEAP-Finish / Re-authパケットに存在する必要があります。
ERP/AAK-Key: Carried in a TLV payload for the key container. The Type is 8. Exactly one ERP/AAK-key SHALL be present in an EAP-Finish/Re-auth packet.
ERP / AAK-Key：キーコンテナーのTLVペイロードで伝送されます。タイプは8です。EAP-Finish/ Re-authパケットには、1つのERP / AAKキーが必ず存在する必要があります。
ERP/AAK-Key ::=
{ sub-TLV: CAP-Identifier }
{ sub-TLV: pMSK Lifetime }
{ sub-TLV: pRK Lifetime }
{ sub-TLV: Cryptosuites }
CAP-Identifier Carried in a sub-TLV payload. The Type is 11 (less than 128). This field is used to indicate the identifier of the candidate authenticator. The value field MUST be encoded as specified in Section 8 of [RFC3315]. At least one instance of the CAP-Identifier TLV MUST be present in the ERP/AAK-Key TLV.
CAP-IdentifierサブTLVペイロードで伝送されます。タイプは11（128未満）です。このフィールドは、候補認証システムのIDを示すために使用されます。値フィールドは、[RFC3315]のセクション8で指定されているようにエンコードする必要があります。 CAP-Identifier TLVの少なくとも1つのインスタンスがERP / AAK-Key TLVに存在する必要があります。
pMSK Lifetime Carried in a sub-TLV payload of the EAP-Finish/Re-auth message. The Type is 10. The value field is an unsigned 32-bit field and contains the lifetime of the pMSK in seconds. This value is calculated by the server after performing the pRK Lifetime computation upon receiving the EAP-Initiate/Re-auth message. The rIK SHOULD share the same lifetime as the pMSK. If the 'L' flag is set, the pMSK Lifetime attribute MUST be present.
pMSKライフタイムEAP-Finish / Re-authメッセージのサブTLVペイロードで伝送されます。タイプは10です。値フィールドは符号なし32ビットフィールドであり、秒単位のpMSKのライフタイムが含まれます。この値は、EAP-Initiate / Re-authメッセージの受信時にpRK Lifetime計算を実行した後、サーバーによって計算されます。 rIKは、pMSKと同じ存続期間を共有する必要があります（SHOULD）。 「L」フラグが設定されている場合、pMSKライフタイム属性が存在する必要があります。
pRK Lifetime Carried in a sub-TLV payload of EAP-Finish/Re-auth message. The Type is 9. The value field is an unsigned 32-bit field and contains the lifetime of the pRK in seconds. This value is calculated by the server before performing the pMSK Lifetime computation upon receiving a EAP-Initiate/Re-auth message. If the 'L' flag is set, the pRK Lifetime attribute MUST be present.
pRK Lifetime EAP-Finish / Re-authメッセージのサブTLVペイロードで伝送されます。タイプは9です。値フィールドは符号なし32ビットフィールドで、秒単位のpRKのライフタイムが含まれます。この値は、EAP-Initiate / Re-authメッセージの受信時にpMSKライフタイム計算を実行する前にサーバーによって計算されます。 「L」フラグが設定されている場合、pRKライフタイム属性が存在する必要があります。
List of Cryptosuites Carried in a sub-TLV payload. The Type is 5 [RFC5296]. The value field contains a list of cryptosuites (at least one cryptosuite SHOULD be included), each 1 octet in length. The allowed cryptosuite values are as specified in Section 5.2. The server SHOULD include this attribute if the cryptosuite used in the EAP-Initiate/Re-auth message was not acceptable and the message is being rejected. The server MAY include this attribute in other cases. The server MAY use this attribute to signal its cryptographic algorithm capabilities to the peer.
サブTLVペイロードで実行される暗号スイートのリスト。タイプは5 [RFC5296]です。値フィールドには、それぞれ1オクテットの長さの暗号スイート（少なくとも1つの暗号スイートを含める必要があります）のリストが含まれます。許可された暗号スイート値は、セクション5.2で指定されているとおりです。 EAP-Initiate / Re-authメッセージで使用される暗号スイートが受け入れられず、メッセージが拒否される場合、サーバーはこの属性を含める必要があります（SHOULD）。サーバーは他の場合にこの属性を含めることができます。サーバーはこの属性を使用して、暗号アルゴリズム機能をピアに通知することができます。
Cryptosuite
暗号スイート
This field indicates the integrity algorithm and PRF used for ERP/ AAK. HMAC-SHA256-128 is REQUIRED to implement, and it SHOULD be enabled in the default configuration. Key lengths and output lengths are either indicated or obvious from the cryptosuite name.
このフィールドは、ERP / AAKに使用される整合性アルゴリズムとPRFを示します。 HMAC-SHA256-128の実装は必須であり、デフォルトの構成で有効にする必要があります（SHOULD）。鍵の長さと出力の長さは、暗号スイート名から示されるか、明らかです。
Authentication Tag
認証タグ
This field contains the integrity checksum over the ERP/AAK packet from the first bit of the Code field to the last bit of the Cryptosuite field, excluding the Authentication Tag field itself. The value field is calculated using the integrity algorithm indicated in the Cryptosuite field and the rIK [RFC5296] as the integrity key. The length of the field is indicated by the corresponding Cryptosuite.
このフィールドには、認証タグフィールド自体を除いて、コードフィールドの最初のビットから暗号スイートフィールドの最後のビットまでのERP / AAKパケットの整合性チェックサムが含まれています。値フィールドは、Cryptosuiteフィールドに示されている整合性アルゴリズムと整合性キーとしてのrIK [RFC5296]を使用して計算されます。フィールドの長さは、対応する暗号スイートによって示されます。
The peer uses the authentication tag to determine the validity of the EAP-Finish/Re-auth message from a server.
ピアは認証タグを使用して、サーバーからのEAP-Finish / Re-authメッセージの有効性を判断します。
If the message doesn't pass verification or the authentication tag is not included in the message, the message SHOULD be discarded silently.
メッセージが検証に合格しない場合、または認証タグがメッセージに含まれていない場合、メッセージは通知なく破棄されるべきです（SHOULD）。
If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is discarded silently. The peer MUST maintain retransmission timers for reliable transport of the EAP-Initiate/Re-auth message. If there is no response to the EAP-Initiate/Re-auth message from the server after the necessary number of retransmissions (see Section 6), the peer MUST assume that ERP/AAK is not supported by the SAP.
EAP-Initiate / Re-authパケットがSAPでサポートされていない場合、サイレントに破棄されます。ピアは、EAP-Initiate / Re-authメッセージの信頼できるトランスポートのために再送信タイマーを維持する必要があります。必要な数の再送信後（セクション6を参照）、サーバーからのEAP-Initiate / Re-authメッセージへの応答がない場合、ピアはERP / AAKがSAPでサポートされていないと想定しなければなりません（MUST）。
With the exception of the rRK Lifetime and rMSK Lifetime TV payloads, the attributes specified in Section 5.3.4 of [RFC5296] also apply to this document. In this document, new attributes that may be present in the EAP-Initiate and EAP-Finish messages are defined as below: o Sequence number: This is a TV payload. The Type is 7.
rRK LifetimeおよびrMSK Lifetime TVペイロードを除いて、[RFC5296]のセクション5.3.4で指定されている属性もこのドキュメントに適用されます。このドキュメントでは、EAP-InitiateおよびEAP-Finishメッセージに存在する可能性のある新しい属性を以下のように定義しています。oシーケンス番号：これはTVペイロードです。タイプは7です。
o ERP/AAK-Key: This is a TLV payload. The Type is 8.
o ERP / AAK-Key：これはTLVペイロードです。タイプは8です。
o pRK Lifetime: This is a TV payload. The Type is 9.
o pRKライフタイム：これはTVペイロードです。タイプは9です。
o pMSK Lifetime: This is a TV payload. The Type is 10.
o pMSKライフタイム：これはTVペイロードです。タイプは10です。
o CAP-Identifier: This is a TLV payload. The Type is 11.
o CAP-Identifier：これはTLVペイロードです。タイプは11です。
Similar to ERP, some lower-layer specifications may need to be revised to support ERP/AAK; refer to Section 6 of [RFC5296] for additional guidance.
ERPと同様に、一部の下位層仕様は、ERP / AAKをサポートするために改訂が必要になる場合があります。追加のガイダンスについては、[RFC5296]のセクション6を参照してください。
The AAA transport of ERP/AAK messages is the same as that of the ERP message [RFC5296]. In addition, this document requires AAA transport of the ERP/AAK keying materials delivered by the ERP/AAK server to the CAP. Hence, a new AAA message for the ERP/AAK application should be specified to transport the keying materials.
ERP / AAKメッセージのAAAトランスポートは、ERPメッセージ[RFC5296]のそれと同じです。さらに、このドキュメントでは、ERP / AAKサーバーからCAPに配信されるERP / AAKキーイングマテリアルのAAAトランスポートが必要です。したがって、ERP / AAKアプリケーションの新しいAAAメッセージを指定して、キー情報を転送する必要があります。
This section provides an analysis of the protocol in accordance with the AAA key management requirements specified in [RFC4962].
このセクションでは、[RFC4962]で指定されているAAAキー管理要件に従ってプロトコルを分析します。
o Cryptographic algorithm independence: ERP-AAK satisfies this requirement. The algorithm chosen by the peer for calculating the authentication tag 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 a Failure indication.
o 暗号アルゴリズムの独立性：ERP-AAKはこの要件を満たします。認証タグを計算するためにピアが選択したアルゴリズムは、EAP-Initiate / Re-authメッセージに示されます。選択したアルゴリズムが受け入れられない場合、EAPサーバーは、失敗を示すEAP-Finish / Re-authメッセージを返します。
o Strong, fresh session keys: ERP-AAK results in the derivation of strong, fresh keys that are unique for the given CAP. A pMSK is always derived on demand when the peer requires a key with a new CAP. The derivation ensures that the compromise of one pMSK does not result in the compromise of a different pMSK at any time.
o 強力で新鮮なセッションキー：ERP-AAKにより、特定のCAPに固有の強力で新鮮なキーが派生します。 pMSKは、ピアが新しいCAPのキーを必要とする場合、常にオンデマンドで導出されます。派生により、1つのpMSKが侵害されても、いつでも別のpMSKが侵害されることはありません。
o Limit key scope: The scope of all the keys derived by ERP-AAK is well defined. The pRK is used to derive the pMSK for the CAP. Different sequence numbers for each CAP MUST be used to derive a unique pMSK.
o キー範囲の制限：ERP-AAKによって導出されるすべてのキーの範囲は明確に定義されています。 pRKは、CAPのpMSKを導出するために使用されます。 CAPごとに異なるシーケンス番号を使用して、一意のpMSKを導出する必要があります。
o Replay detection mechanism: For replay protection, a sequence number associated with the pMSK is used. The peer increments the sequence number by one after it sends an ERP/AAK message. The server sets the expected sequence number to the received sequence number plus one after verifying the validity of the received message, and it responds to the message.
o リプレイ検出メカニズム：リプレイ保護のために、pMSKに関連付けられたシーケンス番号が使用されます。ピアは、ERP / AAKメッセージを送信した後、シーケンス番号を1つ増やします。サーバーは、受信したメッセージの有効性を確認した後、予期したシーケンス番号を受信したシーケンス番号に1を加えた値に設定し、メッセージに応答します。
o Authenticate all parties: The EAP Re-authentication Protocol provides mutual authentication of the peer and the server. The peer and SAP are authenticated via ERP. The CAP is authenticated and trusted by the SAP.
o すべての当事者の認証：EAP再認証プロトコルは、ピアとサーバーの相互認証を提供します。ピアとSAPはERPを介して認証されます。 CAPは、SAPによって認証および信頼されています。
o Peer and authenticator authorization: The peer and authenticator demonstrate possession of the same keying material without disclosing it, as part of the lower-layer secure authentication protocol.
o ピアとオーセンティケーターの承認：ピアとオーセンティケーターは、下位層の安全な認証プロトコルの一部として、同じ鍵情報を公開せずに所有していることを示します。
o Keying material confidentiality: The peer and the server derive the keys independently using parameters known to each entity.
o キー情報の機密性：ピアとサーバーは、各エンティティに既知のパラメーターを使用して、キーを個別に導出します。
o Uniquely named keys: All keys produced within the ERP context can be referred to uniquely as specified in this document.
o 一意に名前が付けられたキー：ERPコンテキスト内で生成されたすべてのキーは、このドキュメントで指定されているように一意に参照できます。
o Prevent the domino effect: Different sequence numbers for each CAP MUST be used to derive the unique pMSK so that the compromise of one pMSK does not hurt any other CAP.
o ドミノ効果の防止：CAPごとに異なるシーケンス番号を使用して、一意のpMSKを導出する必要があります。これにより、1つのpMSKの侵害によって他のCAPが損なわれることはありません。
o Bind key to its context: The pMSKs are bound to the context in which the sequence numbers are transmitted.
o キーをそのコンテキストにバインドする：pMSKは、シーケンス番号が送信されるコンテキストにバインドされます。
o Confidentiality of identity: This is the same as with ERP [RFC5296].
o アイデンティティの機密性：これはERP [RFC5296]と同じです。
o 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 to be used only in the domain for which the keys are derived. Any other restrictions of session keys may be imposed by the specific lower layer and are out of scope for this specification.
o 許可の制限：派生したすべてのキーは、親キーの有効期間またはサーバーポリシーによって有効期間が制限されます。ドメイン固有のキーは、キーが派生するドメインでのみ使用されるようにさらに制限されます。セッションキーのその他の制限は、特定の下位層によって課される可能性があり、この仕様の範囲外です。
IANA has assigned five TLVs from the registry of EAP Initiate and Finish Attributes maintained at http://www.iana.org/assignments/eap-numbers/ with the following numbers: o Sequence number: This is a TV payload. The Type is 7.
IANAは、http：//www.iana.org/assignments/eap-numbers/で維持されているEAP開始および終了属性のレジストリから5つのTLVを次の番号で割り当てました。oシーケンス番号：これはTVペイロードです。タイプは7です。
o ERP/AAK-Key: This is a TLV payload. The Type is 8.
o ERP / AAK-Key：これはTLVペイロードです。タイプは8です。
o pRK Lifetime: This is a TLV payload. The Type is 9.
o pRKライフタイム：これはTLVペイロードです。タイプは9です。
o pMSK Lifetime: This is a TLV payload. The Type is 10.
o pMSKライフタイム：これはTLVペイロードです。タイプは10です。
o CAP-Identifier: This is a TLV payload. The Type is 11.
o CAP-Identifier：これはTLVペイロードです。タイプは11です。
This document reuses the cryptosuites that were created for "Re-authentication Cryptosuites" in [RFC5296].
このドキュメントは、[RFC5296]の「Re-authentication Cryptosuites」用に作成された暗号スイートを再利用します。
Further, IANA has added a new label in the "User Specific Root Keys (USRK) Key Labels" sub-registry of the "Extended Master Session Key (EMSK) Parameters" registry, as follows:
さらに、IANAは、「拡張マスターセッションキー（EMSK）パラメータ」レジストリの「ユーザー固有のルートキー（USRK）キーラベル」サブレジストリに、次のように新しいラベルを追加しました。
EAP Early-Authentication Root Key@ietf.org
EAP Early-Authentication Root Key@ietf.org
A new registry for the flags in the EAP Initiate/Re-auth-Start message called the "EAP Initiate/Re-auth-Start Flags" has been created and a new flag (E) has been assigned as follows:
「EAP開始/再認証開始フラグ」と呼ばれるEAP開始/再認証開始メッセージ内のフラグ用の新しいレジストリが作成され、新しいフラグ（E）が次のように割り当てられました。
(E) 0x80
（え） ０ｘ８０
The rest of the values in the 8-bit field are reserved. New values can be assigned by Standards Action or IESG Approval [RFC5226].
8ビットフィールドの残りの値は予約されています。新しい値は、Standards ActionまたはIESG Approval [RFC5226]によって割り当てることができます。
A new registry for the flags in the EAP Initiate/Re-auth message called the "EAP Initiate/Re-auth Flags" has also been created. The following flags are reserved:
「EAP開始/再認証フラグ」と呼ばれるEAP開始/再認証メッセージ内のフラグ用の新しいレジストリも作成されました。次のフラグは予約されています。
(R) 0x80 [RFC5296]
（R）0x80 [RFC5296]
(B) 0x40 [RFC5296]
（B）0x40 [RFC5296]
(L) 0x20 [RFC5296]
（L）0x20 [RFC5296]
This document assigns a new flag (E) as follows:
このドキュメントでは、次のように新しいフラグ（E）を割り当てています。
(E) 0x10
（え） ０ｘ１０
The rest of the values in the 8-bit field are reserved. New values can be assigned by Standards Action or IESG Approval.
8ビットフィールドの残りの値は予約されています。新しい値は、標準アクションまたはIESG承認によって割り当てることができます。
Further, this document creates a new registry for the flags in the EAP Finish/Re-auth message called the "EAP Finish/Re-auth Flags". The following values are assigned.
さらに、このドキュメントは、「EAP完了/再認証フラグ」と呼ばれるEAP完了/再認証メッセージ内のフラグ用の新しいレジストリを作成します。次の値が割り当てられます。
(R) 0x80 [RFC5296]
（R）0x80 [RFC5296]
(B) 0x40 [RFC5296]
（B）0x40 [RFC5296]
(L) 0x20 [RFC5296]
（L）0x20 [RFC5296]
This document assigns a new flag (E) as follows:
このドキュメントでは、次のように新しいフラグ（E）を割り当てています。
(E) 0x10
（え） ０ｘ１０
The rest of the values in the 8-bit field are reserved. New values can be assigned by Standards Action or IESG approval.
8ビットフィールドの残りの値は予約されています。新しい値は、標準アクションまたはIESG承認によって割り当てることができます。
In writing this document, Yungui Wang contributed to early versions of this document and we have received reviews from many experts in the IETF, including Tom Taylor, Tena Zou, Tim Polk, Tan Zhang, Semyon Mizikovsky, Stephen Farrell, Radia Perlman, Miguel A. Garcia, and Sujing Zhou. We apologize if we miss some of those who have helped us.
このドキュメントの執筆において、Yungui Wangはこのドキュメントの初期バージョンに寄稿し、トムテイラー、テナゾウ、ティムポーク、タンチャン、セミヨンミジコフスキー、スティーブンファレル、ラディアパールマン、ミゲルAを含むIETFの多くの専門家からレビューを受けましたガルシア、スージン・ジョウ。私たちを助けてくれた人たちの一部がいなくて寂しいです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「The Network Access Identifier」、RFC 4282、2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008.
[RFC5295] Salowey、J.、Dondeti、L.、Narayanan、V。、およびM. Nakhjiri、「拡張マスターセッションキー（EMSK）からのルートキーの派生に関する仕様」、RFC 5295、2008年8月。
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5296] Narayanan、V.およびL. Dondeti、「EAP Extensions for EAP Re-authentication Protocol（ERP）」、RFC 5296、2008年8月。
[KEYTRAN] Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Work in Progress, August 2011.
[KEYTRAN] Zorn、G.、Wu、W。、およびV. Cakulev、「暗号化キートランスポートの直径の属性値ペア」、Work in Progress、2011年8月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「Diameter Base Protocol」、RFC 3588、2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4868]ケリーS.およびS.フランケル、「IPsecでのHMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512の使用」、RFC 4868、2007年5月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley、R。およびB. Aboba、「認証、承認、およびアカウンティング（AAA）キー管理のガイダンス」、BCP 132、RFC 4962、2007年7月。
[RFC5836] Ohba, Y., Wu, Q., and G. Zorn, "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", RFC 5836, April 2010.
[RFC5836] Ohba、Y.、Wu、Q。、およびG. Zorn、「Extensible Authentication Protocol（EAP）Early Authentication Problem Statement」、RFC 5836、2010年4月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月。
Authors' Addresses
著者のアドレス
Zhen Cao China Mobile 53A Xibianmennei Ave., Xuanwu District Beijing, Beijing 100053 P.R. China
ZおよびNC AO China Mobile 53ax i ave。、X UA N地区なし、北京、北京100053 P.R.中国
EMail: zehn.cao@gmail.com
Hui Deng China Mobile 53A Xibianmennei Ave., Xuanwu District Beijing, Beijing 100053 P.R. China
Hui Deng China Mobile 53ax i ave。ave。、X UA N地区なしでアクセス可能北京、北京100053 P.R.中国
EMail: denghui02@gmail.com
Qin Wu Huawei Floor 12, HuiHong Mansion, No. 91 BaiXia Rd. Nanjing, Jiangsu 210001 P.R. China
Wuhu AのQは12階、ホイホンマンション、91号BAイクシアRD。南京、江蘇省210001中国
Phone: +86 25 56623633
EMail: sunseawq@huawei.com
Glen Zorn (editor) Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Geron Joron（編集者）Network Zen 228/356 Thanong Sunfight Bang Na、Bangkok 10260 Thailand
Phone: +66 (0) 87-040-4617
EMail: glenzorn@gmail.com