[要約] RFC 5749は、ハンドオーバーや再認証のためのEAPベースのキーの配布に関する標準です。このRFCの目的は、セキュアなキーの配布を通じて、モバイルデバイスのハンドオーバーや再認証のプロセスをサポートすることです。
Internet Engineering Task Force (IETF) K. Hoeper, Ed.
Request for Comments: 5749 M. Nakhjiri
Category: Standards Track Motorola
ISSN: 2070-1721 Y. Ohba, Ed.
Toshiba
March 2010
Distribution of EAP-Based Keys for Handover and Re-Authentication
ハンドオーバーと再認可のためのEAPベースのキーの分布
Abstract
概要
This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage-specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used.
このドキュメントでは、拡張可能な認証プロトコル（EAP）サーバーからルートキーを別のネットワークサーバーに配信するための抽象的なメカニズムについて説明します。これは、再認可などのセキュリティ保護サービスをEAPピアに提供するためのキーを必要とします。分散ルートキーは、使用法固有のルートキー（USRK）、ドメイン固有のルートキー（DSRK）、または拡張マスターセッションキーから導出されたドメイン固有の使用法ルートキー（DSUSRK）のいずれかです。（EMSK）EAPサーバーとEAPピアの間に以前に確立された階層。このドキュメントでは、AAA（認証、承認、および会計）プロトコルを使用してこれらの異なるタイプのルートキーを配布できるキーディストリビューションエクスチェンジ（KDE）プロトコルのテンプレートを定義し、セキュリティ要件について説明します。説明されているプロトコルテンプレートは、メッセージ形式、データエンコード、またはその他の実装の詳細を指定しません。したがって、使用する前に、特定のプロトコル（半径または直径など）にインスタンス化する必要があります。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5749.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5749で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Key Delivery Architecture . . . . . . . . . . . . . . . . . . 5
4. Key Distribution Exchange (KDE) . . . . . . . . . . . . . . . 6
4.1. Context and Scope for Distributed Keys . . . . . . . . . . 7
4.2. Key Distribution Exchange Scenarios . . . . . . . . . . . 8
5. KDE Used in the EAP Re-Authentication Protocol (ERP) . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Requirements on AAA Key Transport Protocols . . . . . . . 9
6.2. Distributing RK without Peer Consent . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
The Extensible Authentication Protocol (EAP) [RFC3748] is an authentication framework supporting authentication methods that are specified in EAP methods. By definition, any key-generating EAP method derives a Master Session Key (MSK) and an Extended Master Session Key (EMSK). [RFC5295] reserves the EMSK for the sole purpose of deriving root keys that can be used for specific purposes called usages. In particular, [RFC5295] defines how to create a usage-specific root key (USRK) for bootstrapping security in a specific application, a domain-specific root key (DSRK) for bootstrapping security of a set of services within a domain, and a usage-specific DSRK (DSUSRK) for a specific application within a domain. [RFC5296] defines a re-authentication root key (rRK) that is a USRK designated for re-authentication.
拡張可能な認証プロトコル（EAP）[RFC3748]は、EAPメソッドで指定された認証方法をサポートする認証フレームワークです。定義上、キー生成EAPメソッドは、マスターセッションキー（MSK）と拡張マスターセッションキー（EMSK）を導き出します。[RFC5295]は、使用法と呼ばれる特定の目的に使用できるルートキーを導出するという唯一の目的のためにEMSKを留保します。特に、[RFC5295]は、特定のアプリケーションでブートストラップセキュリティの使用法固有のルートキー（USRK）を作成する方法、ドメイン内のセットセットのブートストラップセキュリティのドメイン固有のルートキー（DSRK）、およびドメイン内の特定のアプリケーションのための使用法固有のDSRK（DSUSRK）。[RFC5296]は、再認証のために指定されたUSRKである再認証ルートキー（RRK）を定義します。
The MSK and EMSK may be used to derive further keying material for a variety of security mechanisms [RFC5247]. For example, the MSK has been widely used for bootstrapping the wireless link security associations between the peer and the network attachment points. However, performance as well as security issues arise when using the MSK and the current bootstrapping methods in mobile scenarios that require handovers, as described in [RFC5169]. To address handover latencies and other shortcomings, [RFC5296] specifies an EAP re-authentication protocol (ERP) that uses keys derived from the EMSK or DSRK to enable efficient re-authentications in handover scenarios. Neither [RFC5295] nor [RFC5296] specifies how root keys are delivered to the network server requiring the key. Such a key delivery mechanism is essential because the EMSK cannot leave the EAP server ([RFC5295]), but root keys are needed by other network servers disjoint with the EAP server. For example, in order to enable an EAP peer to re-authenticate to a network during a handover, certain root keys need to be made available by the EAP server to the server carrying out the re-authentication.
MSKとEMSKを使用して、さまざまなセキュリティメカニズム[RFC5247]のためにさらにキーイング材料を導き出すことができます。たとえば、MSKは、ピアとネットワーク添付ファイルのポイント間のワイヤレスリンクセキュリティ関連のブートストラップに広く使用されています。ただし、[RFC5169]で説明されているように、ハンドオーバーを必要とするモバイルシナリオでMSKと現在のブートストラップメソッドを使用すると、パフォーマンスとセキュリティの問題が発生します。ハンドオーバーレイテンシやその他の欠点に対処するために、[RFC5296]は、EMSKまたはDSRKから派生したキーを使用して、ハンドオーバーシナリオで効率的な再認知度を可能にするEAP再認証プロトコル（ERP）を指定します。[RFC5295]も[RFC5296]も、キーを必要とするネットワークサーバーにルートキーがどのように配信されるかを指定していません。EMSKはEAPサーバー（[RFC5295]）を離れることができないため、このような重要な配信メカニズムは不可欠ですが、他のネットワークサーバーがEAPサーバーと格差することでルートキーが必要です。たとえば、EAPピアがハンドオーバー中にネットワークに再認証できるようにするには、EAPサーバーがサーバーに再認証を実行するために利用できるようにする必要があります。
This document specifies an abstract mechanism for the delivery of the EMSK child keys from the server holding the EMSK or a root key to another network server that requests a root key for providing protected services (such as re-authentication and other usage and domain-specific services) to EAP peers. In the remainder of this document, a server delivering root keys is referred to as a Key Delivering Server (KDS), and a server authorized to request and receive root keys from a KDS is referred to as a Key Requesting Server (KRS). The Key Distribution Exchange (KDE) mechanism defined in this document runs over a AAA (Authentication, Authorization, and Accounting) protocol, e.g., RADIUS ([RFC2865], [RFC3579]) or Diameter [RFC3588], and has several variants depending on the type of key that is requested and delivered (i.e., DRSK, USRK, or DSUSRK). The presented KDE mechanism is a protocol template that must be instantiated for a particular protocol, such as RADIUS or Diameter, to specify the format and encoding of the abstract protocol messages. Only after such an instantiation can the KDE mechanism described in this document be implemented. This document also describes security requirements for the secure key delivery over AAA.
このドキュメントは、EMSKまたはルートキーを保持しているサーバーからのEMSKチャイルドキーを、保護されたサービスを提供するためのルートキーを要求する別のネットワークサーバーにルートキーを保持している抽象的なメカニズムを指定します（再認証やその他の使用やドメイン固有のルートキーを要求しますサービス）EAPピアへ。このドキュメントの残りの部分では、ルートキーを配信するサーバーはキー配信サーバー（KDS）と呼ばれ、KDSからルートキーを要求および受信することを許可されたサーバーは、キー要求サーバー（KRS）と呼ばれます。このドキュメントで定義されている主要な分布交換（KDE）メカニズムは、AAA（認証、承認、および会計）プロトコルを介して実行されます。要求され、配信されるキーのタイプ（つまり、DRSK、USRK、またはDSUSRK）。提示されたKDEメカニズムは、抽象プロトコルメッセージの形式とエンコードを指定するために、半径や直径などの特定のプロトコルにインスタンス化する必要があるプロトコルテンプレートです。このドキュメントで説明されているKDEメカニズムをそのようなインスタンス化の後にのみ実装できます。このドキュメントでは、AAAを介した安全なキー配信に関するセキュリティ要件についても説明しています。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The following acronyms are used.
次の頭字語が使用されます。
AAA Authentication, Authorization and Accounting. AAA protocols with EAP support include RADIUS ([RFC2865], [RFC3579]) and Diameter [RFC3588].
USRK Usage-Specific Root Key. A root key that is derived from the EMSK; see [RFC5295].
USRKの使用法固有のルートキー。EMSKから派生したルートキー。[RFC5295]を参照してください。
USR-KH USRK Holder. A network server that is authorized to request and receive a USRK from the EAP server. The USR-KH can be a AAA server or dedicated service server.
USR-KH USRKホルダー。EAPサーバーからUSRKを要求して受信することが許可されているネットワークサーバー。USR-KHは、AAAサーバーまたは専用のサービスサーバーにすることができます。
DSRK Domain-Specific Root Key. A root key that is derived from the EMSK; see [RFC5295].
暗いドメイン固有のルートキー。EMSKから派生したルートキー。[RFC 5295]を参照してください。
DSR-KH DSRK Holder. A network server that is authorized to request and receive a DSRK from the EAP server. The most likely implementation of a DSR-KH is a AAA server in a domain, enforcing the policies for the usage of the DSRK within this domain.
DSR-KH DSRKホルダー。EAPサーバーからDSRKを要求して受信することが許可されているネットワークサーバー。DSR-KHの最も可能性の高い実装は、ドメイン内のAAAサーバーであり、このドメイン内のDSRKの使用に関するポリシーを実施します。
DSUSRK Domain-Specific Usage-Specific Root Key. A root key that is derived from the DSRK; see [RFC5295].
DSUSRKドメイン固有の使用率固有のルートキー。DSRKから派生したルートキー。[RFC5295]を参照してください。
DSUSR-KH DSUSRK holder. A network server authorized to request and receive a DSUSRK from the DSR-KH. The most likely implementation of a DSUSR-KH is a AAA server in a domain, responsible for a particular service offered within this domain.
DSUSR-KH DSUSRKホルダー。DSR-KHからDSUSRKを要求して受信することを許可されたネットワークサーバー。DSUSR-KHの最も可能性の高い実装は、ドメイン内のAAAサーバーであり、このドメイン内で提供される特定のサービスを担当しています。
RK Root Key. An EMSK child key, i.e., a USRK, DSRK, or DSUSRK.
RKルートキー。EMSKチャイルドキー、すなわち、USRK、DSRK、またはDSUSRK。
KDS Key Delivering Server. A network server that holds an EMSK or DSRK and delivers root keys to a KRS requesting root keys. The EAP server (together with the AAA server to which it exports the keys for delivery) and the DSR-KH can both act as KDS.
KDSキー配信サーバー。EMSKまたはDSRKを保持し、ルートキーを要求するKRSにルートキーを配信するネットワークサーバー。EAPサーバー（配信のためにキーをエクスポートするAAAサーバーとともに）とDSR-KHは両方ともKDとして機能します。
KRS Key Requesting Server. A network server that shares an interface with a KDS and is authorized to request root keys from the KDS. A USR-KH, DSR-KH, and DSUSR-KH can all act as a KRS.
HOKEY Handover Keying.
Hokey Handover Keying。
An EAP server carries out normal EAP authentications with EAP peers but is typically not involved in potential handovers and re-authentication attempts by the same EAP peer. Other servers are typically in place to offer these requested services. These servers can be AAA servers or other service network servers. Whenever EAP-based keying material is used to protect a requested service, the respective keying material has to be available to the server providing the requested service. For example, the first time a peer requests a service from a network server, this server acts as a KRS. The KRS requests the root keys needed to derive the keys for protecting the requested service from the respective KDS. In subsequent requests from the same peer and as long as the root key has not expired, the KRS can use the same root keys to derive fresh keying material to protect the requested service. These kinds of key requests and distributions are necessary because an EMSK cannot leave the EAP server ([RFC5295]). Hence, any root key that is directly derived from an EMSK can only be derived by the EAP server itself. The EAP server then exports these keys to a server that can distribute the keys to the KRS. In the remainder of this document, the KDS consisting of the EAP server that derives the root keys together with the AAA server that distributes these keys is denoted EAP/AAA server. Root keys derived from EMSK child keys, such as a DSUSRK, can be requested from the respective root key holder. Hence, a KDS can be either the EAP/AAA server or a DSRK holder (DSR-KH), whereas a KRS can be either a USRK holder (USR-KH), a DSR-KH, or a DSUSRK holder (DSUSR-KH).
EAPサーバーは、EAPピアを使用して通常のEAP認証を実行しますが、通常、同じEAPピアによる潜在的なハンドオーバーや再認可の試みには関与していません。他のサーバーは通常、これらの要求されたサービスを提供するために整っています。これらのサーバーは、AAAサーバーまたは他のサービスネットワークサーバーです。EAPベースのキーイング素材を使用して要求されたサービスを保護するときはいつでも、要求されたサービスを提供するサーバーがそれぞれのキーイング素材を利用できるようにする必要があります。たとえば、ピアが初めてネットワークサーバーからサービスを要求したとき、このサーバーはKRSとして機能します。KRSは、要求されたサービスをそれぞれのKDSから保護するためにキーを導出するために必要なルートキーを要求します。同じピアからの後続の要求およびルートキーが期限切れになっていない限り、KRSは同じルートキーを使用して、要求されたサービスを保護するために新鮮なキーイン素材を導き出すことができます。EMSKがEAPサーバーを離れることができないため、これらの種類の重要な要求と分布が必要です（[RFC5295]）。したがって、EMSKから直接導出されるルートキーは、EAPサーバー自体によってのみ導出されます。EAPサーバーは、これらのキーをKRSに配布できるサーバーにエクスポートします。このドキュメントの残りの部分では、これらのキーを配布するAAAサーバーと一緒にルートキーを導出するEAPサーバーで構成されるKDSは、EAP/AAAサーバーと表示されます。DSUSRKなどのEMSKチャイルドキーから派生したルートキーは、それぞれのルートキーホルダーから要求できます。したがって、KDSはEAP/AAAサーバーまたはDSRKホルダー（DSR-KH）のいずれかであり、KRSはUSRKホルダー（USR-KH）、DSR-KH、またはDSUSRKホルダー（DSUSR-KH）になります。）。
The KRS needs to share an interface with the KDS to be able to send all necessary input data to derive the requested key and to receive the requested key. The provided data includes the Key Derivation Function (KDF) that should be used to derive the requested key. The KRS uses the received root key to derive further keying material in order to secure its offered services. Every KDS is responsible for storing and protecting the received root key as well as the derivation and distribution of any child key derived from the root key. An example of a key delivery architecture is illustrated in Figure 1 showing the different types of KRS and their interfaces to the KDS.
KRSは、要求されたキーを導き出し、要求されたキーを受信するために必要なすべての入力データを送信できるように、KDSとインターフェイスを共有する必要があります。提供されたデータには、要求されたキーを導出するために使用する必要があるキー派生関数（KDF）が含まれます。KRSは、受信したルートキーを使用して、提供されたサービスを確保するために、さらにキーイング素材を導き出します。すべてのKDSは、受信したルートキーの保存と保護、およびルートキーから派生した任意の子キーの派生と分布の保存を担当します。重要な配信アーキテクチャの例を図1に示します。さまざまな種類のKRSとそのインターフェイスをKDSに示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP/AAA server |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | | \
/ | | \
/ | | \
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| USR-KH1 | | USR-KH2 | | DSR-KH1 | | DSR-KH2 |
| HOKEY server| | XYZ server| |Domain 1 | | Domain 2|
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
/ |
/ |
/ |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| DSUSR-KH | | DSUSR-KH2 |
| Domain 1 | | Domain 2 |
|Home domain | |Visited domain |
|HOKEY server | |HOKEY server |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 1: Example Key Delivery Architecture for the Different KRS and KDS
図1：さまざまなKRSおよびKDSのキー配信アーキテクチャの例
In this section, a generic mechanism for a key distribution exchange (KDE) over AAA is described in which a root key (RK) is distributed from a KDS to a KRS. It is required that the communication path between the KDS and the KRS is protected by the use of an appropriate AAA transport security mechanism (see Section 6 for security requirements). Here, it is assumed that the KRS and the KDS are separate entities, logically if not physically, and the delivery of the requested RK is specified accordingly.
このセクションでは、AAAを介したキー分布交換（KDE）の一般的なメカニズムについて説明します。このメカニズムでは、ルートキー（RK）がKDSからKRSに分布しています。KDSとKRS間の通信パスは、適切なAAA輸送セキュリティメカニズムを使用することにより保護される必要があります（セキュリティ要件についてはセクション6を参照）。ここでは、KRSとKDSは物理的にはない場合は論理的には別々のエンティティであり、要求されたRKの配信がそれに応じて指定されていると想定されています。
The key distribution exchange consists of one round-trip, i.e., two messages between the KRS and the KDS, as illustrated in Figure 2.
キーディストリビューション交換は、図2に示すように、1回の往復、つまりKRSとKDSの間の2つのメッセージで構成されています。
First, the KRS sends a KDE-Request carrying a Key Request Token (KRT). As a response, the KDS sends a KDE-Response carrying a Key Delivery Token (KDT). Both tokens are encapsulated in AAA messages. The definition of the AAA attributes depends on the implemented AAA protocol and is out of scope of this document. However, the security requirements for AAA messages carrying KDE messages are discussed in Section 6. The contents of KRT and KDT are defined in the following.
まず、KRSはキーリクエストトークン（KRT）を運ぶKDE-Requestを送信します。応答として、KDSはキー配信トークン（KDT）を運ぶKDE応答を送信します。両方のトークンは、AAAメッセージにカプセル化されています。AAA属性の定義は、実装されたAAAプロトコルに依存し、このドキュメントの範囲外です。ただし、KDEメッセージを伝えるAAAメッセージのセキュリティ要件については、セクション6で説明します。KRTとKDTの内容は、以下で定義されています。
KRS KDS
-------- -------
| |
| KDE-Request: AAA{KRT} |
|----------------------------------------->|
| KDE-Response: AAA{KDT} |
|<-----------------------------------------|
Figure 2: KDE Message Flow
図2：KDEメッセージフロー
KRT : (PID, KT, KL)
KRT ：（ PID、KT、KL）
KRT carries the identifiers of the peer (PID), the key type (KT) and the key label (KL). The key type specifies which type of root key is requested, e.g., DSRK, USRK and DSUSRK. The encoding rules for each key type are left to the protocol developers who define the instantiation of the KDE mechanism for a particular protocol. For the specification of key labels and the associated IANA registries, please refer to [RFC5295], which specifies key labels for USRKs and establishes an IANA registry for them. The same specifications can be applied to other root keys.
KRTは、ピア（PID）、キータイプ（KT）、キーラベル（KL）の識別子を運びます。キータイプは、DSRK、USRK、DSUSRKなどのルートキーのタイプを指定します。各キータイプのエンコーディングルールは、特定のプロトコルのKDEメカニズムのインスタンス化を定義するプロトコル開発者に任されます。キーラベルと関連するIANAレジストリの仕様については、[RFC5295]を参照してください。これは、USRKSのキーラベルを指定し、それらのIANAレジストリを確立します。同じ仕様を他のルートキーに適用できます。
KDT : (KT, KL, RK, KN_RK, LT_RK)
KDT ：（ KT、KL、RK、KN_RK、LT_RK）
KDT carries the root key (RK) to be distributed to the KRS, as well as the key type (KT) of the key, the key label (KL), the key name (KN_RK), and the lifetime of RK (LT_RK). The key lifetime of each distributed key MUST NOT be greater than that of its parent key.
KDTは、キーのキータイプ（KT）、キーラベル（KL）、キー名（KN_RK）、およびRK（LT_RK）の寿命（LT_RK）のルートキー（RK）、およびキーのキータイプ（KT）を運びます。。各分散キーのキー寿命は、親キーの寿命よりも大きくなければなりません。
The key context of each distributed key is determined by the sequence of KTs in the key hierarchy. The key scope of each distributed key is determined by the sequence of (PID, KT, KL)-tuples in the key hierarchy and the identifier of the KRS. The KDF used to generate the requested keys includes context and scope information, thus, binding the key to the specific channel [RFC5295].
各分散キーのキーコンテキストは、キー階層内のKTSのシーケンスによって決定されます。各分散キーのキー範囲は、キー階層の（PID、KT、KL）のシーケンスとKRSの識別子のシーケンスによって決定されます。要求されたキーを生成するために使用されるKDFには、コンテキストとスコープ情報が含まれるため、特定のチャネル[RFC5295]にキーを結合します。
Given the three types of KRS, there are three scenarios for the distribution of the EMSK child keys. For all scenarios, the trigger and mechanism for key delivery may involve a specific request from an EAP peer and/or another intermediary (such as an authenticator). For simplicity, it is assumed that USR-KHs reside in the same domain as the EAP server.
3種類のKRSを考えると、EMSKチャイルドキーの分布には3つのシナリオがあります。すべてのシナリオについて、キー配信のトリガーとメカニズムには、EAPピアおよび/または別の仲介者（認証者など）からの特定のリクエストが含まれる場合があります。簡単にするために、USR-KHSはEAPサーバーと同じドメインに存在すると想定されています。
Scenario 1: EAP/AAA server to USR-KH: In this scenario, the EAP/AAA server delivers a USRK to a USR-KH.
シナリオ1：EAP/AAAサーバーからUSR-KH：このシナリオでは、EAP/AAAサーバーはUSRKをUSR-KHに配信します。
Scenario 2: EAP/AAA server to DSR-KH: In this scenario, the EAP/AAA server delivers a DSRK to a DSR-KH.
シナリオ2：EAP/AAAサーバーからDSR-KH：このシナリオでは、EAP/AAAサーバーはDSRKをDSR-KHに配信します。
Scenario 3: DSR-KH to DSUSR-KH: In this scenario, a DSR-KH in a specific domain delivers keying material to a DSUSR-KH in the same domain.
シナリオ3：DSR-KHからDSUSR-KHへ：このシナリオでは、特定のドメインのDSR-KHが同じドメインのDSUSR-KHにキーイング素材を提供します。
The key distribution exchanges for Scenario 3 can be combined with the key distribution exchanges for Scenario 2 into a single round-trip exchange as shown in Figure 3. Here, KDE-Request and KDE-Response are messages for Scenarios 2, whereas KDE-Request' and KDE-Response' are messages for Scenarios 3.
シナリオ3の主要な分布交換は、図3に示すように、シナリオ2のキーディストリビューション交換と単一の往復交換と組み合わせることができます。'およびkde-response'はシナリオ3のメッセージです。
DSUSR-KH DSR-KH EAP/AAA Server
-------- ------ ------------
| KDE-Request'(KRT') | KDE-Request(KRT) |
|------------------------>|-------------------------->|
| KDE-Response'(KDT') | KDE-Response(KDT) |
|<----------------------- |<--------------------------|
| | |
Figure 3: Combined Message Exchange
図3：結合メッセージ交換
This section describes how the presented KDE mechanism should be used to request and deliver the root keys used for re-authentication in the EAP Re-authentication Protocol (ERP) defined in [RFC5296]. ERP supports two forms of bootstrapping, implicit as well as explicit bootstrapping, and KDE is discussed for both cases in the remainder of this section.
このセクションでは、提示されたKDEメカニズムを使用して、[RFC5296]で定義されているEAP再認証プロトコル（ERP）の再認証に使用されるルートキーを要求および配信する方法について説明します。ERPは、2つの形式のブートストラップ、暗黙的および明示的なブートストラップをサポートしており、このセクションの残りの部分でKDEについて説明します。
In implicit bootstrapping, the local EAP Re-authentication (ER) server requests the DSRK from the home AAA server during the initial EAP exchange. Here, the local ER server acts as the KRS and the home AAA server as the KDS. In this case, the local ER server requesting the DSRK includes a KDE-Request in the AAA packet encapsulating the first EAP-Response message from the peer. Here, a AAA User-Name attribute is used as the PID. If the EAP exchange is successful, the home AAA server includes a KDE-Response in the AAA message that carries the EAP-Success message.
暗黙のブートストラップでは、ローカルEAP再認証（ER）サーバーは、最初のEAP交換中にホームAAAサーバーからDSRKを要求します。ここでは、ローカルERサーバーがKRSとして機能し、Home AAAサーバーとしてKDSとして機能します。この場合、DSRKを要求するローカルERサーバーには、ピアからの最初のEAP応答メッセージをカプセル化するAAAパケットにKDE-Requestが含まれています。ここでは、AAAユーザー名属性がPIDとして使用されます。EAP Exchangeが成功した場合、Home AAAサーバーには、AAAメッセージにKDE応答が含まれており、EAP-SUCSESSメッセージが含まれています。
Explicit bootstrapping is initiated by peers that do not know the domain. Here, the peer sends an EAP-Initiate message with the bootstrapping flag turned on. The local ER server (acting as KRS) includes a KDE-Request message in the AAA message that carries the peer's EAP-Initiate message and sends it to the peer's home AAA server. Here, a AAA User-Name attribute is used as the PID. In its response, the home AAA server (acting as KDS) includes a KDE-Response in the AAA message that carries the EAP-Finish message with the bootstrapping flag set.
明示的なブートストラップは、ドメインを知らないピアによって開始されます。ここでは、ピアはブートストラップフラグをオンにしてEAPイテリアメッセージを送信します。ローカルERサーバー（KRSとして機能する）には、AAAメッセージにKDE-Requestメッセージが含まれており、ピアのEAPイテリアメッセージを伝達し、ピアのホームAAAサーバーに送信します。ここでは、AAAユーザー名属性がPIDとして使用されます。その応答では、Home AAAサーバー（KDSとして機能する）には、AAAメッセージにKDE応答が含まれており、ブートストラップフラグセットを使用してEAPフィニッシュメッセージを伝達します。
This section provides security requirements and a discussion of distributing RK without peer consent.
このセクションでは、セキュリティ要件と、ピア同意なしにRKを配布することに関する議論を提供します。
Any KDE attribute that is exchanged as part of a KDE-Request or KDE-Response MUST be integrity-protected and replay-protected by the underlying AAA protocol that is used to encapsulate the attributes. Additionally, a secure key wrap algorithm MUST be used by the AAA protocol to protect the RK in a KDE-Response. Other confidential information as part of the KDE messages (e.g., identifiers if privacy is a requirement) SHOULD be encrypted by the underlying AAA protocol.
KDE-RequestまたはKDE-Responseの一部として交換されるKDE属性は、属性をカプセル化するために使用される基礎となるAAAプロトコルによって整合性保護およびリプレイ保護されている必要があります。さらに、KDE応答でRKを保護するために、AAAプロトコルで安全なキーラップアルゴリズムを使用する必要があります。KDEメッセージの一部としてのその他の機密情報（プライバシーが要件である場合、識別子など）は、基礎となるAAAプロトコルによって暗号化される必要があります。
When there is an intermediary, such as a AAA proxy, on the path between the KRS and the KDS, there will be a series of hop-by-hop security associations along the path. The use of hop-by-hop security associations implies that the intermediary on each hop can access the distributed keying material. Hence, the use of hop-by-hop security SHOULD be limited to an environment where an intermediary is trusted not to abuse the distributed key material. If such a trusted AAA infrastructure does not exist, other means must be applied at a different layer to ensure the end-to-end security (i.e., between KRS and KDS) of the exchanged KDE messages. The security requirements for such a protocol are the same as previously outlined for AAA protocols and MUST hold when encapsulated in AAA messages.
KRSとKDSの間のパスにAAAプロキシなどの仲介者がいる場合、パスに沿って一連のホップバイホップセキュリティ関連があります。ホップバイホップセキュリティ協会の使用は、各ホップの仲介者が分散キーイング素材にアクセスできることを意味します。したがって、ホップバイホップセキュリティの使用は、分散型の主要資料を乱用しないと仲介者が信頼されている環境に限定されるべきです。このような信頼できるAAAインフラストラクチャが存在しない場合、交換されたKDEメッセージのエンドツーエンドセキュリティ（つまり、KRSとKDの間）を確保するために、他の手段を別のレイヤーに適用する必要があります。このようなプロトコルのセキュリティ要件は、AAAプロトコルの以前に概説されたものと同じであり、AAAメッセージにカプセル化されたときに保持する必要があります。
When a KDE-Request is sent as a result of explicit ERP bootstrapping [RFC5296], cryptographic verification of peer consent on distributing an RK is provided by the integrity checksum of the EAP-Initiate message with the bootstrapping flag turned on.
明示的なERPブートストラップ[RFC5296]の結果としてKDE-Requestが送信されると、RKの配布に関するピア同意の暗号化の検証は、ブートストラップフラグがオンになったEAPイテリアメッセージの整合性チェックサムによって提供されます。
On the other hand, when a KDE-Request is sent as a result of implicit ERP bootstrapping [RFC5296], cryptographic verification of peer consent on distributing an RK is not provided. A peer is not involved in the process and, thus, not aware of key delivery requests for root keys derived from its established EAP keying material. Hence, a peer has no control where keys derived from its established EAP keying material are distributed. A possible consequence of this is that a KRS may request and obtain an RK from the home server even if the peer does not support ERP. EAP-Initiate/Re-auth-Start messages send to the peer will be silently dropped by the peer causing further waste of resources.
一方、暗黙のERPブートストラップ[RFC5296]の結果としてKDE-Requestが送信されると、RKの配布に関するピア同意の暗号化の検証は提供されません。ピアはプロセスに関与していないため、確立されたEAPキーイング材料から派生したルートキーの主要な配信要求を認識していません。したがって、ピアには、確立されたEAPキーイング材料から派生したキーが分布している場合は、制御できません。これの考えられる結果は、KRSがピアがERPをサポートしていなくても、ホームサーバーからRKを要求して取得できることです。Peerに送信されるEAP Initiate/Reauth-Startメッセージは、ピアによって静かに落とされ、リソースがさらに無駄になります。
The editors would like to thank Dan Harkins, Chunqiang Li, Rafael Marin Lopez, and Charles Clancy for their valuable comments.
編集者は、貴重なコメントをしてくれたDan Harkins、Chunqiang Li、Rafael Marin Lopez、Charles Clancyに感謝したいと思います。
The following people contributed to this document: Kedar Gaonkar, Lakshminath Dondeti, Vidya Narayanan, and Glen Zorn.
次の人々がこの文書に貢献しました：Kedar Gaonkar、Lakshminath Dondeti、Vidya Narayanan、およびGlen Zorn。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[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再認証プロトコル（ERP）のEAP拡張」、RFC 5296、2008年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（リモート認証ダイヤルインユーザーサービス）拡張可能な認証プロトコル（EAP）のサポート」、RFC 3579、2003年9月。
[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、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008.
[RFC5169] Clancy、T.、Nakhjiri、M.、Narayanan、V。、およびL. Dondeti、「ハンドオーバーキー管理と再認可問題声明」、RFC 5169、2008年3月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247] Aboba、B.、Simon、D。、およびP. Eronen、「拡張可能な認証プロトコル（EAP）キー管理フレームワーク」、RFC 5247、2008年8月。
Authors' Addresses
著者のアドレス
Katrin Hoeper (editor) Motorola, Inc. 1295 E Algonquin Road Schaumburg, IL 60196 USA
Katrin Hoeper（編集者）Motorola、Inc。1295 E Algonquin Road Schaumburg、IL 60196 USA
Phone: +1 847 576 4714
EMail: khoeper@motorola.com
Madjid F. Nakhjiri Motorola, Inc. 6450 Sequence Drive San Diego, CA 92121 USA
Madjid F. Nakhjiri Motorola、Inc。6450 Sequence Drive San Diego、CA 92121 USA
EMail: madjid.nakhjiri@motorola.com
Yoshihiro Ohba (editor) Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
ヨシヒロ・オバ（編集者）東芝コーポレート・リサーチ開発センター1コムカイ・トゥーバ - チョチョ・サイワイ・ク、川崎、川川212-8582日本
Phone: +81 44 549 2230
EMail: yoshihiro.ohba@toshiba.co.jp