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）プロトコルのためのテンプレートを定義します。記載されたプロトコルテンプレートは、メッセージ・フォーマット、データ符号化、または他の実装の詳細を指定していません。したがって、それを使用することができる前に、特定のプロトコル（例えば、RADIUSまたはDIAMETER）でインスタンス化される必要があります。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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は広くピアとのネットワーク接続ポイントとの間の無線リンクのセキュリティアソシエーションをブートストラップするために使用されてきました。 MSKとハンドオーバを必要とするモバイルシナリオにおける現在のブートストラップ法を使用する場合、[RFC5169]に記載されているようしかし、性能だけでなく、セキュリティ上の問題が生じます。ハンドオーバ待ち時間及び他の欠点に対処するために、[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（認証、許可、およびアカウンティング）プロトコル、例えば、RADIUS（[RFC2865]、[RFC3579]）または直径[RFC3588]上で動作し、いくつかの変異体は、上で依存しています要求して配信されたキーの種類（すなわち、DRSK、USRK、またはDSUSRK）。提示KDE機構は抽象的なプロトコルメッセージのフォーマットおよびエンコーディングを指定するために、RADIUSまたはDIAMETERなどの特定のプロトコルのためにインスタンス化されなければならないプロトコルテンプレートです。のみ、このようなインスタンス化した後、このドキュメントで説明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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following acronyms are used.
以下の頭字語が使用されています。
AAA Authentication, Authorization and Accounting. AAA protocols with EAP support include RADIUS ([RFC2865], [RFC3579]) and Diameter [RFC3588].
AAA認証、認可およびアカウンティング。 EAPサポートを持つAAAプロトコルは、RADIUS（[RFC2865]、[RFC3579]）とDiameter [RFC3588]を含みます。
USRK Usage-Specific Root Key. A root key that is derived from the EMSK; see [RFC5295].
UARKの使用固有のルートキー。 EMSKから導出されるルート鍵。 [RFC 5295]を参照してください。
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].
DARKドメイン固有ルートキー。 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の最も可能性の高い実装は、このドメイン内のDSRKの利用のための政策を施行する、ドメイン内のAAAサーバです。
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はKDSの両方として作用することができます。
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.
サーバに要求KRSキー。 KDSとインタフェースを共有し、KDSからルートキーを要求することを許可されているネットワークサーバ。 KRSとしてUSR-KH、DSR-KH、およびDSUSR-KHができるすべての行為。
HOKEY Handover Keying.
HOKEYハンドオーバキーイング。
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の子キー、由来ルートキーは、それぞれのルート鍵の所有者から要求することができます。 KRSはUSRKホルダー（USR-KH）のいずれかであり得る一方したがって、KDSはEAP / AAAサーバまたはDSRKホルダー（DSR-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は、受け取ったルートキーだけでなく、ルートキーから派生した子キーの導出と配布を格納し、保護するための責任があります。鍵配信アーキテクチャの例は、KDSにKRSとそのインターフェースの種類を示す、図1に示されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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）はKRSにKDSから分配されます。 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の間、すなわち、二つのメッセージから成ります。
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メッセージのセキュリティ要件は、KRTとKDTの内容は、以下に定義されている第6節で議論されています。
KRS KDS
-------- -------
| |
| KDE-Request: AAA{KRT} |
|----------------------------------------->|
| KDE-Response: AAA{KDT} |
|<-----------------------------------------|
Figure 2: KDE Message Flow
図2：KDEメッセージフロー
KRT : (PID, KT, KL)
CRT：（Peedh、カット、明日）
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レジストリの場合は、USRKsのためのキーラベルを指定し、彼らのためにIANAレジストリを確立[RFC5295]を参照してください。同じ仕様は、他のルートキーに適用することができます。
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はKRSに分配されるルートキー（RK）、ならびにキーのキータイプ（KT）を担持し、キーラベル（KL）、キー名（KN_RK）、およびRKの寿命（LT_RK） 。各分散キーのキーの有効期間は、その親キーのそれよりも大きくすることはできません。
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.
KRSの3種類を考えると、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：-KOHを使用するEAP / AAAサーバは、このシナリオでは、EAP / AAAサーバは、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：DSR-KHにEAP / AAAサーバ：このシナリオでは、EAP / AAAサーバは、DSR-KHにDSRKを送達します。
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-KHをDSUSRする：このシナリオでは、特定のドメインに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リクエストとKDE-応答KDEリクエストに対し、シナリオ2のメッセージであります「とKDE-応答は」シナリオ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は、ブートストラップの二つの形態、暗黙ならびに明示的なブートストラップをサポートしており、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
暗黙のブートストラップでは、ローカルEAPの再認証（ER）サーバが初期EAP交換の際にホームAAAサーバからDSRKを要求します。ここでは、ローカルERサーバはKRSと家として働き
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.
KDSとしてAAAサーバ。この場合、DSRKを要求するローカルERサーバはピアからの最初のEAP-Responseメッセージをカプセル化AAAパケット内KDE-要求を含みます。ここでは、AAA User-Name属性は、PIDとして使用されています。 EAP交換が成功した場合は、ホームAAAサーバは、EAP-Successメッセージを運ぶAAAメッセージでKDE-応答を含んでいます。
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-開始メッセージがオンに送信します。 （KRSとして機能）ローカルERサーバは、ピアのEAP-開始メッセージを運ぶと、ピアのホームAAAサーバに送信し、AAAメッセージでKDE-Requestメッセージを含んでいます。ここでは、AAA User-Name属性は、PIDとして使用されています。その応答において、（KDSとして作用する）ホームAAAサーバは、ブートストラップフラグが設定されたEAP-完了メッセージを運ぶAAAメッセージでKDE-応答を含みます。
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-要求またはKDE-応答の一部として交換されているすべての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.
仲介者は、そのようなAAAプロキシとして、存在する場合に、KRSとKDSとの間の経路上に、経路に沿ったホップバイホップセキュリティアソシエーションのシリーズが存在するであろう。ホップバイホップセキュリティアソシエーションの使用は、各ホップに仲介が分散キーイングマテリアルにアクセスすることができることを意味します。したがって、ホップバイホップセキュリティの使用は仲介は、分散キーマテリアルを乱用しないように、信頼された環境に制限する必要があります。そのような信頼されたAAAインフラストラクチャが存在しない場合、他の手段は、交換KDEメッセージ（すなわち、KRSとKDS間）エンドツーエンドのセキュリティを確保するために、異なる層に適用されなければなりません。そのようなプロトコルのためのセキュリティ要件は、以前に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.
ブートストラップフラグがオンでKDE - 要求が明示的なERPブートストラップ[RFC5296]、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.
一方、KDE-Requestが暗黙ERPブートストラップ[RFC5296]、RKを分配するのピア同意の暗号検証の結果として送信されたときに提供されていません。ピアは、その確立されたEAPキーイング材料に由来するルートキーのキー配信リクエストを認識していない、従って、プロセスに関与していません。したがって、ピアは、その確立されたEAPキーイング材料に由来するキーが配布される制御できません。このことの可能な結果はKRSが要求し、ピアがERPをサポートしていない場合でも、ホームサーバーからRKを得ることができるということです。 EAP-開始/再-AUTH-スタートメッセージは、ピアに送信は黙っ資源の更なる浪費の原因となるピアによって破棄されます。
The editors would like to thank Dan Harkins, Chunqiang Li, Rafael Marin Lopez, and Charles Clancy for their valuable comments.
編集者は彼らの貴重なコメントのためにダンハーキンズ、Chunqiangリー、ラファエル・マリン・ロペス、そしてチャールズ・クランシーに感謝したいと思います。
The following people contributed to this document: Kedar Gaonkar, Lakshminath Dondeti, Vidya Narayanan, and Glen Zorn.
ケダルGaonkar、Lakshminath Dondeti、Vidyaナラヤナン、およびグレンツォルン：次の人は、この文書に貢献しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ブルンク、L.、Vollbrecht、J.、カールソン、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.、ナラヤナン、V.、およびM. Nakhjiri、RFC 5295 "拡張マスタセッションキー（EMSK）からルート鍵の導出のための仕様"、2008年8月。
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5296]ナラヤナン、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[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.カルフーン、 "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]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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]クランシー、T.、Nakhjiri、M.、ナラヤナン、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.、サイモン、D.、およびP. Eronen、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、RFC 5247、2008年8月。
Authors' Addresses
著者のアドレス
Katrin Hoeper (editor) Motorola, Inc. 1295 E Algonquin Road Schaumburg, IL 60196 USA
カトリンHoeper（編集者）、モトローラ社1295 Eアルゴンキン道路泡城、IL 60196 USA
Phone: +1 847 576 4714 EMail: khoeper@motorola.com
電話：+1 847 576 4714 Eメール：khoeper@motorola.com
Madjid F. Nakhjiri Motorola, Inc. 6450 Sequence Drive San Diego, CA 92121 USA
マジドF. Nakhjiriモトローラ社6450シーケンスドライブサンディエゴ、CA 92121 USA
EMail: madjid.nakhjiri@motorola.com
メールアドレス：madjid.nakhjiri@motorola.com
Yoshihiro Ohba (editor) Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
よしひろ おｈば （えぢとｒ） としば こｒぽらて れせあｒｃｈ あんｄ でゔぇぉｐめんｔ せんてｒ １ こむかいーとしばーちょ さいわいーく、 かわさき、 かながわ ２１２ー８５８２ じゃぱん
Phone: +81 44 549 2230 EMail: yoshihiro.ohba@toshiba.co.jp
電話：+81 44 549 2230 Eメール：yoshihiro.ohba@toshiba.co.jp