[要約] RFC 5295は、拡張マスターセッションキー（EMSK）からルートキーを派生させるための仕様書です。その目的は、セキュリティプロトコルで使用されるルートキーの生成方法を標準化することです。
Network Working Group J. Salowey
Request for Comments: 5295 Cisco Systems
Updates: 5247 L. Dondeti
Category: Standards Track V. Narayanan
Qualcomm, Inc
M. Nakhjiri
Motorola
August 2008
Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)
拡張マスターセッションキー（EMSK）からのルートキーの派生の仕様
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
概要
The Extensible Authentication Protocol (EAP) defined the Extended Master Session Key (EMSK) generation, but reserved it for unspecified future uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains.
拡張認証プロトコル（EAP）は、拡張マスターセッションキー（EMSK）生成を定義しましたが、将来の不特定の使用のために予約しました。このメモは、ルートキーを取得することのみを目的としてEMSKを予約します。ルートキーは、用途定義によって識別される、複数の目的に使用できるマスターキーです。このドキュメントでは、暗号化による分離を保証する方法でルートキーを導出することにより、ルートキー間の競合を回避するためのメカニズムについても説明しています。最後に、このドキュメントでは、そのようなルートキーの使用方法も1つ定義しています。ドメイン固有のルートキーは、特定のキー管理ドメインで使用可能になり、使用されるルートキーです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicable Usages of Keys Derived from the EMSK . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Separation and Coordinated Key Derivation . . . 6
3. EMSK Key Root Derivation Framework . . . . . . . . . . . . . . 7
3.1. USRK Derivation . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. On the KDFs . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Default KDF . . . . . . . . . . . . . . . . . . . . . 9
3.2. EMSK and USRK Name Derivation . . . . . . . . . . . . . . 10
4. Domain-Specific Root Key Derivation . . . . . . . . . . . . . 11
4.1. Applicability of Multi-Domain Usages . . . . . . . . . . . 12
5. Requirements for Usage Definitions . . . . . . . . . . . . . . 13
5.1. Root Key Management Guidelines . . . . . . . . . . . . . . 13
6. Requirements for EAP System . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Key Strength . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Cryptographic Separation of Keys . . . . . . . . . . . . . 15
7.3. Implementation . . . . . . . . . . . . . . . . . . . . . . 15
7.4. Key Distribution . . . . . . . . . . . . . . . . . . . . . 16
7.5. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 16
7.6. Entropy Consideration . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. Key Labels . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. PRF Numbers . . . . . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
This document deals with keys generated by authenticated key exchange mechanisms defined within the EAP framework [RFC3748]. EAP defines two types of keying material: a Master Session Key (MSK) and an Extended Master Session Key (EMSK). The EAP specification implicitly assumes that the MSK produced by EAP will be used for a single purpose at a single device; however, it does reserve the EMSK for future use. This document defines the EMSK to be used solely for deriving root keys using the key derivation specified. The root keys are meant for specific purposes called usages; a special usage class is the Domain-Specific Root Keys made available to and used within specific key management domains. This document also provides guidelines for creating usage definitions for the various uses of EAP key material and for the management of the root keys. In this document, the terms application and usage (or "usage definition") refer to a specific use case of the EAP keying material.
このドキュメントは、EAPフレームワーク[RFC3748]内で定義された認証済みのキー交換メカニズムによって生成されたキーを扱います。 EAPでは、マスターセッションキー（MSK）と拡張マスターセッションキー（EMSK）の2種類のキー情報が定義されています。 EAP仕様は、EAPによって生成されたMSKが単一のデバイスで単一の目的に使用されることを暗黙的に想定しています。ただし、EMSKは将来使用するために予約されています。このドキュメントは、指定されたキー導出を使用してルートキーを導出するためにのみ使用されるEMSKを定義します。ルートキーは、用途と呼ばれる特定の目的のためのものです。特別な使用クラスは、特定のキー管理ドメインで利用可能になり、その中で使用されるドメイン固有のルートキーです。このドキュメントでは、EAPキーマテリアルのさまざまな用途とルートキーの管理の使用定義を作成するためのガイドラインも提供します。このドキュメントでは、アプリケーションと使用法（または「使用法の定義」）という用語は、EAPキー情報の特定の使用例を指します。
Different uses for keys derived from the EMSK have been proposed. Some examples include hand-off across access points in various mobile technologies, mobile IP authentication, and higher-layer application authentication. In order for a particular usage of EAP key material to make use of this specification, it must specify a so-called usage definition. This document does not define how the derived Usage-Specific Root Keys (USRK) are used; see the following section for discussion of applicable usages. It does define a framework for the derivation of USRKs for different purposes such that different usages can be developed independently from one another. The goal is to have security properties of one usage have minimal or no effect on the security properties of other usages.
EMSKから派生したキーのさまざまな使用法が提案されています。いくつかの例には、さまざまなモバイルテクノロジーのアクセスポイント間のハンドオフ、モバイルIP認証、および上位層のアプリケーション認証が含まれます。 EAPキーマテリアルの特定の使用法がこの仕様を利用するためには、いわゆる使用法定義を指定する必要があります。このドキュメントでは、派生した使用法固有のルートキー（USRK）の使用方法を定義していません。該当する使用法については、次のセクションを参照してください。さまざまな使用法を互いに独立して開発できるように、さまざまな目的でUSRKを導出するためのフレームワークを定義しています。目的は、1つの用途のセキュリティプロパティが他の用途のセキュリティプロパティにほとんどまたはまったく影響を与えないようにすることです。
This document does define a special class of USRK, called a Domain-Specific Root Key (DSRK) for use in deriving keys specific to a key management domain. Each DSRK is a root key used to derive Domain-Specific Usage-Specific Root Keys (DSUSRK). The DSUSRKs are USRKs specific to a particular key management domain.
このドキュメントでは、キー管理ドメインに固有のキーの導出に使用するドメイン固有のルートキー（DSRK）と呼ばれるUSRKの特別なクラスを定義しています。各DSRKは、ドメイン固有の用途固有のルートキー（DSUSRK）を導出するために使用されるルートキーです。 DSUSRKは、特定のキー管理ドメインに固有のUSRKです。
In order to keep root keys for specific purposes separate from one another, two requirements are defined in the following sections. One is coordinated key derivation and another is cryptographic separation.
特定の目的のルートキーを互いに分離するために、次のセクションで2つの要件が定義されています。 1つは調整された鍵導出であり、もう1つは暗号分離です。
The EMSK is typically established as part of network access authentication and authorization. It is expected that keys derived from EMSK will be used in protocols related to network access, such as handover optimizations, and the scope of these protocols is usually restricted to the endpoints of the lower layers over which EAP packets are sent.
EMSKは通常、ネットワークアクセスの認証と承認の一部として確立されます。 EMSKから派生したキーは、ハンドオーバー最適化などのネットワークアクセスに関連するプロトコルで使用されることが予想され、これらのプロトコルの範囲は通常、EAPパケットが送信される下位層のエンドポイントに制限されます。
In particular, it is inappropriate for the security of higher-layer applications to solely rely on keys derived from network access authentication. Even when used together with another, independent security mechanism, the use of these keys needs to be carefully evaluated with regards to the benefits of the optimization and the need to support multiple solutions. Performance optimizations may not warrant the close tie-in that may be required between the layers in order to use EAP-based keys. Such optimizations may be offset by the complexities of managing the validity and usage of key materials. Keys generated from subsequent EAP authentications may be beyond the knowledge and control of applications.
特に、上位層アプリケーションのセキュリティがネットワークアクセス認証から導出されたキーのみに依存することは不適切です。別の独立したセキュリティメカニズムと一緒に使用する場合でも、これらのキーの使用は、最適化の利点と複数のソリューションをサポートする必要性に関して慎重に評価する必要があります。パフォーマンス最適化では、EAPベースのキーを使用するためにレイヤー間で必要となる可能性のある緊密な連携が保証されない場合があります。このような最適化は、主要な資料の有効性と使用法を管理する複雑さによって相殺される可能性があります。後続のEAP認証から生成されたキーは、アプリケーションの知識と制御を超える可能性があります。
From an architectural point of view, applications should not make assumptions about the lower-layer technology (such as network access authentication) used on any particular hop along the path between the application endpoints.
アーキテクチャの観点から、アプリケーションは、アプリケーションエンドポイント間のパスに沿った特定のホップで使用される下位層テクノロジ（ネットワークアクセス認証など）を想定しないでください。
From a practical point of view, making such assumptions would complicate using those applications over lower layers that do not use EAP, and make it more difficult for applications and network access technologies to evolve independently of each other.
実用的な観点からすると、そのような仮定を行うと、EAPを使用しない下位層でのアプリケーションの使用が複雑になり、アプリケーションとネットワークアクセステクノロジーが互いに独立して進化することが難しくなります。
Parties using keys derived from EMSK also need trust relationships with the EAP endpoints, and mechanisms for securely communicating the keys.
EMSKから派生したキーを使用する関係者には、EAPエンドポイントとの信頼関係、およびキーを安全に通信するためのメカニズムも必要です。
For most applications, it is not appropriate to assume that all current and future access networks are trusted to secure the application function. Instead, applications should implement the required security mechanisms in an access-independent manner.
ほとんどのアプリケーションでは、現在および将来のすべてのアクセスネットワークがアプリケーション機能を保護するために信頼されていると想定することは適切ではありません。代わりに、アプリケーションは必要なセキュリティメカニズムをアクセスに依存しない方法で実装する必要があります。
Implementation considerations may also complicate communication of keys to an application from the lower layer. For instance, in many configurations, application protocol endpoints may be different from the EAP endpoints.
実装上の考慮事項により、下位層からアプリケーションへのキーの通信も複雑になる場合があります。たとえば、多くの構成では、アプリケーションプロトコルエンドポイントはEAPエンドポイントと異なる場合があります。
Given all this, it is NOT RECOMMENDED to use keys derived from the EMSK as an exclusive security mechanism, when their usage is not inherently, and by permanent nature, tied to the lower layer where network access authentication was performed.
これらすべてを考慮して、EMSKから派生したキーを排他的なセキュリティメカニズムとして使用することはお勧めできません。キーの使用が本質的に永続的ではなく、ネットワークアクセス認証が実行された下位層に関連付けられている場合です。
Keys derived from EAP are pair-wise by nature and are not directly suitable for multicast or other group usages such as those involved in some routing protocols. It is possible to use keys derived from EAP in protocols that distribute group keys to group participants.
EAPから派生したキーは本質的にペアワイズであり、マルチキャストや一部のルーティングプロトコルに関連するグループなど、他のグループでの使用には直接適していません。グループ参加者にグループキーを配布するプロトコルで、EAPから派生したキーを使用することが可能です。
The definition of these group key distribution protocols is beyond the scope of this document and would require additional specification.
これらのグループキー配布プロトコルの定義は、このドキュメントの範囲外であり、追加の仕様が必要になります。
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 terms are taken from [RFC3748]: EAP Server, peer, authenticator, Master Session Key (MSK), Extended Master Session Key (EMSK), Cryptographic Separation.
次の用語は[RFC3748]から取得されます：EAPサーバー、ピア、オーセンティケーター、マスターセッションキー（MSK）、拡張マスターセッションキー（EMSK）、暗号化分離。
Usage Definition An application of cryptographic key material to provide one or more security functions such as authentication, authorization, encryption, or integrity protection for related applications or services. This document provides guidelines and recommendations for what should be included in usage definitions. This document does not place any constraints on the types of use cases or services that create usage definitions.
使用法の定義関連するアプリケーションまたはサービスの認証、承認、暗号化、整合性保護などの1つ以上のセキュリティ機能を提供するための暗号化キーマテリアルのアプリケーション。このドキュメントは、使用定義に何を含める必要があるかについてのガイドラインと推奨事項を提供します。このドキュメントでは、利用状況の定義を作成するユースケースやサービスのタイプに制限を設けていません。
Usage-Specific Root Key (USRK) Keying material derived from the EMSK for a particular usage definition. It is used to derive child keys in a way defined by its usage definition.
使用法固有のルートキー（USRK）特定の使用法定義のEMSKから派生したキー生成情報。使用法の定義で定義された方法で子キーを派生させるために使用されます。
Key Management Domain A key management domain is specified by the scope of a given root key. The scope is the collection of systems authorized to access key material derived from that key. Systems within a key management domain may be authorized to (1) derive key materials, (2) use key materials, or (3) distribute key materials to other systems in the same domain. A derived key's scope is constrained to a subset of the scope of the key from which it is derived. In this document, the term "domain" refers to a key management domain unless otherwise qualified.
キー管理ドメインキー管理ドメインは、特定のルートキーのスコープによって指定されます。スコープは、そのキーから派生したキーマテリアルへのアクセスを許可されたシステムのコレクションです。鍵管理ドメイン内のシステムは、（1）鍵マテリアルの導出、（2）鍵マテリアルの使用、または（3）鍵マテリアルを同じドメイン内の他のシステムに配布することを許可される場合があります。派生キーのスコープは、派生元のキーのスコープのサブセットに制限されています。このドキュメントでは、「ドメイン」という用語は、特に指定がない限り、キー管理ドメインを指します。
Domain Specific Root Key (DSRK) Keying material derived from the EMSK that is restricted to use in a specific key management domain. It is used to derive child keys for a particular usage definition. The child keys derived from a DSRK are referred to as Domain-Specific Usage-Specific Root Keys (DSUSRKs). A DSUSRK is similar to the USRK, except in the fact that its scope is restricted to the same domain as the parent DSRK from which it is derived.
ドメイン固有のルートキー（DSRK）特定のキー管理ドメインでの使用に制限されている、EMSKから派生したキー関連情報。特定の使用法定義の子キーを取得するために使用されます。 DSRKから派生した子キーは、ドメイン固有の用途固有のルートキー（DSUSRK）と呼ばれます。 DSUSRKはUSRKに似ていますが、その範囲が、派生元の親DSRKと同じドメインに制限されている点が異なります。
The EMSK is used to derive keys for multiple use cases, and thus it is required that the derived keys are cryptographically separate. Cryptographic separation means that when multiple keys are derived from an EMSK, given any derived key, it is computationally infeasible to derive any of the other derived keys. Note that deriving the EMSK from any combinations of the derived keys must also be computationally infeasible. In practice, this means that derivation of an EMSK from a derived key or derivation of one child key from another must require an amount of computation equivalent to that required to, say, reversing a cryptographic hash function.
EMSKは複数のユースケースのキーを導出するために使用されるため、派生キーは暗号的に分離されている必要があります。暗号化分離とは、EMSKから複数のキーが導出された場合、任意の導出キーが与えられた場合、他の導出キーを導出することは計算上不可能であることを意味します。派生キーの任意の組み合わせからEMSKを派生させることも、計算上実行不可能でなければならないことに注意してください。実際には、これは、派生キーからのEMSKの派生または別の子キーからの1つの子キーの派生には、たとえば暗号化ハッシュ関数を逆にするために必要な計算と同等の量の計算が必要であることを意味します。
Cryptographic separation of keys derived from the same key can be achieved in many ways. Two obvious methods are as follows:
同じキーから派生したキーの暗号化分離は、さまざまな方法で実現できます。 2つの明白な方法は次のとおりです。
o Use a Pseudo-Random Function (PRF) on the EMSK and generate a key stream. Keys of various lengths may be provided as required from the key stream for various uses.
o EMSKで疑似ランダム関数（PRF）を使用し、キーストリームを生成します。さまざまな用途のキーストリームから必要に応じて、さまざまな長さのキーを提供できます。
o Derive keys from EMSK by providing different inputs to the PRF.
o PRFにさまざまな入力を提供することにより、EMSKからキーを取得します。
However, it is desirable that derivation of one child key from the EMSK is independent of derivation of another child key. Independent derivation of keys from the EMSK allows child keys to be derived in any order, independent of other keys. Thus, it is desirable to use option 2 from above. Using the second option implies the additional input to the PRF must be different for each child key derivation. This additional input to the PRF must be coordinated properly to meet the requirement of cryptographic separation and to prevent reuse of key material between usages.
ただし、EMSKからの1つの子キーの派生は、別の子キーの派生とは無関係であることが望ましい。 EMSKからのキーの独立した導出により、他のキーとは無関係に、子キーを任意の順序で導出できます。したがって、上記のオプション2を使用することが望ましいです。 2番目のオプションを使用することは、PRFへの追加の入力が子キーの派生ごとに異なる必要があることを意味します。 PRFへのこの追加の入力は、暗号分離の要件を満たし、使用間での鍵マテリアルの再利用を防ぐために適切に調整する必要があります。
If cryptographic separation is not maintained, then the security of one usage depends upon the security of all other usages that use keys derived from the EMSK. If a system does not have this property, then a usage's security depends upon all other usages deriving keys from the same EMSK, which is undesirable. In order to prevent security problems in one usage from interfering with another usage, the following cryptographic separation is required:
暗号の分離が維持されていない場合、1つの使用法のセキュリティは、EMSKから派生したキーを使用する他のすべての使用法のセキュリティに依存します。システムにこのプロパティがない場合、使用法のセキュリティは、同じEMSKからキーを派生する他のすべての使用法に依存するため、望ましくありません。ある用途でのセキュリティの問題が別の用途に干渉するのを防ぐために、次の暗号の分離が必要です。
o It MUST be computationally infeasible to compute the EMSK from any root key derived from it.
o EMSKから派生したルートキーからEMSKを計算することは、計算上実行不可能でなければなりません。
o Any root key MUST be cryptographically separate from any other root key derived from the same EMSK or DSRK.
o すべてのルートキーは、同じEMSKまたはDSRKから派生した他のルートキーと暗号的に分離する必要があります。
o Derivation of USRKs MUST be coordinated so that two separate cryptographic usages do not derive the same key.
o USRKの派生は、2つの別々の暗号使用法が同じ鍵を導出しないように調整する必要があります。
o Derivation of DSRKs MUST be coordinated so that two separate key management domains do not derive the same key.
o 2つの別個の鍵管理ドメインが同じ鍵を導出しないように、DSRKの派生を調整する必要があります。
o Derivation of DSRKs and USRKs MUST be specified such that no domain can obtain a USRK by providing a domain name identical to a Usage Key Label.
o DSRKおよびUSRKの派生は、使用鍵ラベルと同一のドメイン名を提供することによってドメインがUSRKを取得できないように指定する必要があります。
This document provides guidelines for a key derivation mechanism that can be used with existing and new EAP methods to provide cryptographic separation between usages of EMSK. This allows for the development of new usages without cumbersome coordination between different usage definitions.
このドキュメントでは、EMSKの使用法を暗号化して分離するために、既存および新規のEAPメソッドで使用できる鍵導出メカニズムのガイドラインを提供します。これにより、異なる使用法定義間の面倒な調整なしに、新しい使用法を開発できます。
The EMSK key derivation framework provides a coordinated means for generating multiple root keys from an EMSK. Further keys may then be derived from the root key for various purposes, including encryption, integrity protection, entity authentication by way of proof of possession, and subsequent key derivation. A root key is derived from the EMSK for a specific set of uses set forth in a usage definition described in Section 5.
EMSKキー導出フレームワークは、EMSKから複数のルートキーを生成するための調整された手段を提供します。次に、暗号化、完全性保護、所有の証明によるエンティティ認証、およびその後の鍵の導出など、さまざまな目的でルート鍵からさらに鍵を導出できます。ルートキーは、セクション5で説明されている使用法の定義で説明されている特定の使用法のEMSKから派生しています。
The basic EMSK root key hierarchy looks as follows:
基本的なEMSKルートキー階層は次のようになります。
EMSK
/ \
USRK1 USRK2
This document defines how to derive Usage-Specific Root Keys (USRKs) from the EMSK and also defines a specific USRK called a Domain-Specific Root Key (DSRK). DSRKs are root keys restricted to use in a particular key management domain. From the DSRK, Usage-Specific Root Keys for a particular application may be derived (DSUSRKs). The DSUSRKs are equivalent to USRKs that are restricted to use in a particular domain. The details of lower levels of key hierarchy are outside scope of this document. The key hierarchy looks as follows:
このドキュメントでは、EMSKから用途固有のルートキー（USRK）を取得する方法を定義し、ドメイン固有のルートキー（DSRK）と呼ばれる特定のUSRKも定義します。 DSRKは、特定のキー管理ドメインでの使用に制限されたルートキーです。 DSRKから、特定のアプリケーションの用途固有のルートキーを導出できます（DSUSRK）。 DSUSRKは、特定のドメインでの使用に制限されているUSRKと同等です。キー階層の下位レベルの詳細は、このドキュメントの範囲外です。キー階層は次のようになります。
EMSK
/ \
USRK DSRK
/ \
DSUSRK1 DSUSRK2
The EMSK Root Key Derivation Function (KDF) derives a USRK from the EMSK, a key label, optional data, and output length. The KDF is expected to give the same output for the same input. The basic key derivation function is given below.
EMSKルート鍵導出関数（KDF）は、EMSK、鍵ラベル、オプションのデータ、および出力長からUSRKを導出します。 KDFは、同じ入力に対して同じ出力を提供することが期待されています。基本的な鍵導出関数を以下に示します。
USRK = KDF(EMSK, key label | "\0" | optional data | length)
USRK = KDF（EMSK、キーラベル| "\ 0" |オプションのデータ|長さ）
where:
ただし：
| denotes concatenation "\0" is a NULL octet (0x00 in hex) length is a 2-octet unsigned integer in network byte order
|連結を示します "\ 0"はNULLオクテット（16進数で0x00）長さはネットワークバイトオーダーの2オクテットの符号なし整数
The key labels are printable ASCII strings unique for each usage definition and are a maximum of 255 octets. In general, they are of the form label-string@specorg, where specorg is the organization that controls the specification of the usage definition of the Root Key. The key label is intended to provide global uniqueness. Rules for the allocation of these labels are given in Section 8.
キーラベルは、使用法定義ごとに一意の印刷可能なASCII文字列で、最大255オクテットです。一般に、それらはlabel-string @ specorgという形式です。specorgは、ルートキーの使用法定義の仕様を制御する組織です。キーラベルは、グローバルな一意性を提供することを目的としています。これらのラベルの割り当てに関する規則は、セクション8に記載されています。
The NULL octet after the key label is used to avoid collisions if one key label is a prefix of another label (e.g., "foobar" and "foobarExtendedV2"). This is considered a simpler solution than requiring a key label assignment policy that prevents prefixes from occurring.
キーラベルの後のNULLオクテットは、1つのキーラベルが別のラベルの接頭辞（たとえば、「foobar」と「foobarExtendedV2」）の場合の衝突を回避するために使用されます。これは、プレフィックスの発生を防ぐキーラベル割り当てポリシーを必要とするよりも簡単なソリューションと考えられています。
For the optional data, the KDF MUST be capable of processing at least 2048 opaque octets. The optional data must be constant during the execution of the KDF. Usage definitions MAY use the EAP Session-ID [RFC5247] in the specification of the optional data parameter that goes into the KDF function. In this case, the advantage is that data provided into the key derivation is unique to the session that generated the keys.
オプションのデータの場合、KDFは少なくとも2048個の不透明オクテットを処理できる必要があります。オプションのデータは、KDFの実行中は一定でなければなりません。使用法の定義は、KDF関数に入るオプションのデータパラメータの指定でEAPセッションID [RFC5247]を使用する場合があります。この場合の利点は、キーの派生に提供されるデータが、キーを生成したセッションに固有であることです。
The KDF must be able to process input keys of up to 256 bytes. It may do this by providing a mechanism for "hashing" long keys down to a suitable size that can be consumed by the underlying derivation algorithm.
KDFは、最大256バイトの入力キーを処理できる必要があります。これは、基礎となる派生アルゴリズムで使用できる適切なサイズに長いキーを「ハッシュ」するメカニズムを提供することで実現できます。
The length is a 2-octet unsigned integer in network byte order of the output key length in octets. An implementation of the KDF MUST be capable of producing at least 2048 octets of output; however, it is RECOMMENDED that Root Keys be at least 64 octets long.
長さは、オクテット単位の出力キー長のネットワークバイトオーダーの2オクテットの符号なし整数です。 KDFの実装は、少なくとも2048オクテットの出力を生成できる必要があります。ただし、ルートキーの長さは少なくとも64オクテットであることが推奨されます。
A usage definition requiring derivation of a Root Key must specify all the inputs (other than EMSK) to the key derivation function.
ルートキーの派生を必要とする使用法定義では、キー派生関数へのすべての入力（EMSK以外）を指定する必要があります。
USRKs MUST be at least 64 octets in length.
USRKは少なくとも64オクテットの長さでなければなりません。
This specification allows for the use of different KDFs. However, in order to have a coordinated key derivation function, the same KDF function MUST be used for all key derivations for a given EMSK. If no KDF is specified, then the default KDF specified in Section 3.1.2 MUST be used. A system may provide the capability to negotiate additional KDFs. KDFs are assigned numbers through IANA following the policy set in Section 8. The rules for negotiating a KDF are as follows:
この仕様では、さまざまなKDFを使用できます。ただし、キー導出関数を調整するためには、同じKDF関数を、指定されたEMSKのすべてのキー導出に使用する必要があります。 KDFが指定されていない場合は、セクション3.1.2で指定されているデフォルトのKDFを使用する必要があります。システムは、追加のKDFをネゴシエートする機能を提供する場合があります。 KDFには、セクション8で設定されたポリシーに従ってIANAを通じて番号が割り当てられます。KDFのネゴシエーションのルールは次のとおりです。
o If no other KDF is specified, the KDF specified in this document MUST be used. This is the "default" KDF.
o 他のKDFが指定されていない場合は、このドキュメントで指定されているKDFを使用する必要があります。これが「デフォルト」のKDFです。
o The initial authenticated key exchange MAY specify a favored KDF. For example, an EAP method may define a preferred KDF to use in its specification. If the initial authenticated key exchange specifies a KDF, then this MUST override the default KDF.
o 最初に認証された鍵交換は、優先されるKDFを指定してもよい（MAY）。たとえば、EAPメソッドでは、仕様で使用する優先KDFを定義できます。最初に認証された鍵交換がKDFを指定している場合、これはデフォルトのKDFをオーバーライドする必要があります。
Note that usage definitions MUST NOT concern themselves with the details of the KDF construction or the KDF selection, they only need to worry about the inputs specified in Section 3.
使用法の定義は、KDFの構成またはKDFの選択の詳細に関係してはならないことに注意してください。セクション3で指定された入力についてのみ考慮する必要があります。
The default KDF for deriving root keys from an EMSK is taken from the PRF+ key expansion specified in [RFC4306] based on HMAC-SHA-256 [SHA256]. The PRF+ construction was chosen because of its simplicity and efficiency over other mechanisms such as those used in [RFC4346]. The motivation for the design of PRF+ is described in [SIGMA]. The definition of PRF+ from [RFC4306] is given below:
EMSKからルートキーを取得するためのデフォルトのKDFは、HMAC-SHA-256 [SHA256]に基づいて、[RFC4306]で指定されたPRF +キー拡張から取得されます。 [RFC4346]で使用されているような他のメカニズムよりも単純で効率的であるため、PRF +構造が選択されました。 PRF +の設計の動機は[SIGMA]で説明されています。 [RFC4306]のPRF +の定義を以下に示します。
PRF+ (K,S) = T1 | T2 | T3 | T4 | ...
PRF +（K、S）= T1 | T2 | Tz |午後| ...
where:
ただし：
T1 = PRF (K, S | 0x01) T2 = PRF (K, T1 | S | 0x02) T3 = PRF (K, T2 | S | 0x03) T4 = PRF (K, T3 | S | 0x04)
T1 = PRF（K、C | 0x01）T2 = PRF（K、T1 | C | 0x02）Tz = PRF（K、T2 | C | 0x03）Tch = PRF（K、Tz | C | 0x04）
continuing as needed to compute the required length of key material. The key, K, is the EMSK and S is the concatenation of the key label, the NULL octet, optional data, and length defined in Section 3.1. For this specification, the PRF is taken as HMAC-SHA-256 [SHA256]. Since PRF+ is only defined for 255 iterations, it may produce up to 8160 octets of key material.
必要に応じてキーマテリアルの必要な長さを計算し続けます。キーKはEMSKであり、Sは、キーラベル、NULLオクテット、オプションのデータ、およびセクション3.1で定義された長さの連結です。この仕様では、PRFはHMAC-SHA-256 [SHA256]と見なされます。 PRF +は255回の反復に対してのみ定義されているため、最大8160オクテットのキーマテリアルを生成できます。
The EAP keying framework [RFC5247] specifies that the EMSK MUST be named using the EAP Session-ID and a binary or textual indication. Following that requirement, the EMSK name SHALL be derived as follows:
EAPキーイングフレームワーク[RFC5247]は、EMS Session-IDとバイナリまたはテキストの指示を使用してEMSKに名前を付ける必要があることを指定しています。その要件に従って、EMSK名は次のように派生する必要があります。
EMSKname = KDF ( EAP Session-ID, "EMSK" | "\0" | length )
where:
ただし：
| denotes concatenation "EMSK" consists of the 4 ASCII values for the letters "\0" = is a NULL octet (0x00 in hex) length is the 2-octet unsigned integer 8 in network byte order
| "EMSK"は文字の4つのASCII値で構成されていることを示します "\ 0" = NULLオクテット（16進数で0x00）長さは2バイトの符号なし整数8ネットワークバイトオーダー
It is RECOMMENDED that all keys derived from the EMSK are referred to by the EMSKname and the context of the descendant key usage. This is the default behavior. Any exceptions SHALL be signaled by individual usages.
EMSKから派生したすべてのキーは、EMSKnameおよび子孫キーの使用法のコンテキストによって参照されることをお勧めします。これがデフォルトの動作です。例外は、個々の使用法によって通知されるものとします（SHALL）。
USRKs MAY be named explicitly with a name derivation specified as follows:
USRKは、次のように指定された名前の派生を使用して、明示的に名前を付けることができます。
USRKName = KDF(EAP Session-ID, key label|"\0"|optional data|length)
USRKName = KDF（EAPセッションID、キーラベル| "\ 0" |オプションデータ|長さ）
where:
ただし：
key label and optional data MUST be the same as those used in the corresponding USRK derivation length is the 2-octet unsigned integer 8 in network byte order
鍵ラベルとオプションのデータは、対応するUSRK派生で使用されているものと同じでなければなりません。長さは、ネットワークバイトオーダーの2オクテットの符号なし整数8です。
USRKName derivation and usage are applicable when there is ambiguity in referencing the keys using the EMSKname and the associated context of the USRK usage. The usage SHALL signal such an exception in key naming, so both parties know the key name used.
USRKNameの派生と使用法は、EMSKnameとUSRK使用法の関連コンテキストを使用してキーを参照することにあいまいさが存在する場合に適用されます。使用法は、キーの命名におけるそのような例外を通知する必要があるため（SHALL）、両方の当事者は、使用されるキー名を知っています。
A specific USRK called a Domain-Specific Root Key (DSRK) is derived from the EMSK for a specific set of usages in a particular key management domain. Usages derive specific keys for specific services from this DSRK. The DSRK may be distributed to a key management domain for a specific set of usages so that keys can be derived within the key management domain for those usages. DSRK-based usages will follow a key hierarchy similar to the following:
ドメイン固有のルートキー（DSRK）と呼ばれる特定のUSRKは、特定のキー管理ドメインでの特定の使用法のセットのEMSKから派生します。使用法は、このDSRKから特定のサービスの特定のキーを導出します。 DSRKは、特定の使用法のセットの鍵管理ドメインに配布され、それらの使用法の鍵管理ドメイン内で鍵を導出できます。 DSRKベースの使用法は、次のようなキー階層に従います。
EMSK
/ \
/ \
/ \
/ \
DSRK1 DSRK2
/ \ / \
/ \ / \
DSUSRK11 DSUSRK12 DSUSRK21 DSUSRK22
The DSRK is a USRK with a key label of "dsrk@ietf.org" and the optional data containing a domain label. The optional data MUST contain an ASCII string representing the key management domain for which the root key is being derived. The DSRK MUST be at least 64 octets long.
DSRKは、「dsrk@ietf.org」のキーラベルとドメインラベルを含むオプションのデータを持つUSRKです。オプションのデータには、ルートキーが導出されるキー管理ドメインを表すASCII文字列が含まれている必要があります。 DSRKは少なくとも64オクテットの長さでなければなりません。
Domain-Specific Usage-Specific Root Keys (DSUSRKs) are derived from the DSRK. The KDF is expected to give the same output for the same input. The basic key derivation function is given below.
ドメイン固有の用途固有のルートキー（DSUSRK）は、DSRKから派生します。 KDFは、同じ入力に対して同じ出力を提供することが期待されています。基本的な鍵導出関数を以下に示します。
DSUSRK = KDF(DSRK, key label | "\0" | optional data | length)
DSUSRK = KDF（DSRK、キーラベル| "\ 0" |オプションのデータ|長さ）
The key labels are printable ASCII strings unique for each usage definition within a DSRK usage and are a maximum of 255 octets. In general, they are of the form label-string@specorg where specorg is the organization that controls the specification of the usage definition of the DSRK. The key label is intended to provide global uniqueness. Rules for the allocation of these labels are given in Section 8. For the optional data, the KDF MUST be capable of processing at least 2048 opaque octets. The optional data must be constant during the execution of the KDF. The length is a 2-octet unsigned integer in network byte order of the output key length in octets. An implementation of the KDF MUST be capable of producing at least 2048 octets of output; however, it is RECOMMENDED that DSUSRKs be at least 64 octets long.
キーラベルは、DSRK使用法内の使用法定義ごとに一意の印刷可能なASCII文字列で、最大255オクテットです。一般に、それらはlabel-string @ specorgという形式です。specorgは、DSRKの使用法定義の仕様を制御する組織です。キーラベルは、グローバルな一意性を提供することを目的としています。これらのラベルの割り当てに関する規則は、セクション8に記載されています。オプションのデータの場合、KDFは少なくとも2048個の不透明オクテットを処理できる必要があります。オプションのデータは、KDFの実行中は一定でなければなりません。長さは、オクテット単位の出力キー長のネットワークバイトオーダーの2オクテットの符号なし整数です。 KDFの実装は、少なくとも2048オクテットの出力を生成できる必要があります。ただし、DSUSRKの長さが少なくとも64オクテットであることが推奨されます。
Usages that make use of the DSRK must define how the peer learns the domain label to use in a particular derivation. A multi-domain usage must define how both DSRKs and specific DSUSRKs are transported to different key management domains. Note that usages may define alternate ways to constrain specific keys to particular key management domains.
DSRKを使用する使用法は、ピアが特定の派生で使用するドメインラベルを学習する方法を定義する必要があります。マルチドメインの使用法では、DSRKと特定のDSUSRKの両方を異なるキー管理ドメインに転送する方法を定義する必要があります。使用法は、特定のキーを特定のキー管理ドメインに制約する代替方法を定義する場合があることに注意してください。
To facilitate the use of EMSKname to refer to keys derived from DSRKs, EMSKname SHOULD be sent along with the DSRK. The exception is when a DSRKname is expected to be used. The usage SHALL signal such an exception in key naming, so both parties know the key name used.
DSRKから派生したキーを参照するためのEMSKnameの使用を容易にするために、EMSKnameはDSRKとともに送信する必要があります（SHOULD）。例外は、DSRKnameの使用が予想される場合です。使用法は、キーの命名におけるそのような例外を通知する必要があるため（SHALL）、両方の当事者は、使用されるキー名を知っています。
DSUSRKs MAY be named explicitly with a name derivation specified as follows:
DSUSRKは、次のように指定された名前の派生を使用して、明示的に名前を付けることができます。
DSUSRKName = KDF(EMSKName,key label | "\0" | optional data | length)
DSUSRKName = KDF（EMSKName、key label | "\ 0" |オプションのデータ|長さ）
where length is the 2-octet unsigned integer 8 in network byte order.
ここで、lengthは、ネットワークバイトオーダーの2オクテットの符号なし整数8です。
The DSUSRKs generated by a domain can be used to authorize entities in a domain to perform specific functions. In cases where it is appropriate for only a specific domain to be authorized to perform a function, the usage SHOULD NOT be defined as multi-domain.
ドメインによって生成されたDSUSRKは、ドメイン内のエンティティに特定の機能の実行を承認するために使用できます。特定のドメインのみに機能の実行を許可することが適切な場合は、使用法をマルチドメインとして定義してはなりません（SHOULD NOT）。
In some cases, only certain domains are authorized for a particular multi-domain usage. In this case, domains that do not have full authorization should not receive the DSRK and should only receive DSUSRKs for the usages for which they are authorized. If it is possible for a peer to know which domains are authorized for a particular usage without relying on restricting access to the DSRK to specific domains, then this recommendation may be relaxed.
場合によっては、特定のマルチドメインの使用に対して特定のドメインのみが許可されます。この場合、完全な承認を持たないドメインはDSRKを受信せず、承認されている用途のDSUSRKのみを受信する必要があります。ピアが、DSRKへのアクセスを特定のドメインに制限することなく、特定の使用が許可されているドメインを知ることができる場合、この推奨事項は緩和される可能性があります。
In order for a usage definition to meet the guidelines for USRK usage, it must meet the following recommendations:
使用法の定義がUSRKの使用法のガイドラインを満たすためには、次の推奨事項を満たしている必要があります。
o The usage must define if it is a domain-enabled usage.
o 使用法は、ドメイン対応の使用法であるかどうかを定義する必要があります。
o The usage definition MUST NOT use the EMSK in any other way except to derive Root Keys using the key derivation specified in Section 3 of this document. They MUST NOT use the EMSK directly.
o 使用法の定義では、このドキュメントのセクション3で指定されているキー導出を使用してルートキーを導出する以外の方法でEMSKを使用してはなりません（MUST NOT）。 EMSKを直接使用してはなりません。
o The usage definition SHOULD NOT require caching of the EMSK. It is RECOMMENDED that the Root Key derived specifically for the usage definition (rather than the EMSK) should be used to derive child keys for specific cryptographic operations.
o 使用法の定義では、EMSKのキャッシュを必要としません（SHOULD NOT）。特定の暗号化操作の子キーを導出するには、EMSKではなく使用法の定義用に特別に導出されたルートキーを使用することをお勧めします。
o Usage definitions MUST define distinct key labels and optional data used in the key derivation described in Section 3. Usage definitions are encouraged to use the key name described in Section 3.2 and include additional data in the optional data to provide additional entropy.
o 使用法の定義では、セクション3で説明されているキーの派生で使用される個別のキーラベルとオプションのデータを定義する必要があります。
o Usage definitions MUST define the length of their Root Keys. It is RECOMMENDED that the Root Keys be at least as long as the EMSK (at least 64 octets).
o 使用法の定義では、ルートキーの長さを定義する必要があります。ルートキーは少なくともEMSKと同じ長さ（少なくとも64オクテット）にすることをお勧めします。
o Usage definitions MUST define how they use their Root Keys. This includes aspects of key management covered in the next section on Root Key management guidelines.
o 使用法の定義では、ルートキーの使用方法を定義する必要があります。これには、ルートキー管理ガイドラインに関する次のセクションで説明するキー管理の側面が含まれます。
This section makes recommendations for various aspects of key management of the Root Key including lifetime, child key derivation, caching, and transport.
このセクションでは、ライフタイム、子キーの派生、キャッシング、トランスポートなど、ルートキーのキー管理のさまざまな側面について推奨事項を示します。
It is RECOMMENDED that the Root Key is only used for deriving child keys. A usage definition must specify how and when the derivation of child keys should be done. It is RECOMMENDED that usages following similar considerations for key derivation are as outlined in this document for the Root Key derivation with respect to cryptographic separation and key reuse. In addition, usages should take into consideration the number of keys that will be derived from the Root Key and ensure that enough entropy is introduced in the derivation to support this usage. It is desirable that the entropy is provided by the two parties that derive the child key.
ルートキーは、子キーの派生にのみ使用することをお勧めします。使用法の定義では、子キーの派生をいつどのように行うかを指定する必要があります。鍵の導出について同様の考慮事項に従う使用法は、暗号の分離と鍵の再利用に関するルート鍵の導出について、このドキュメントで概説されているとおりにすることをお勧めします。さらに、使用法では、ルートキーから派生するキーの数を考慮に入れ、この使用法をサポートするために十分なエントロピーが派生に導入されていることを確認する必要があります。エントロピーは、子鍵を導出する2つのパーティによって提供されることが望ましい。
Root Keys' lifetimes should not be more than that of the EMSK. Thus, when the EMSK expires, the Root Keys derived from it should be removed from use. If a new EMSK is derived from a subsequent EAP transaction, then a usage implementation should begin to use the new Root Keys derived from the new EMSK as soon as possible. Whether or not child keys associated with a Root Key are replaced depends on the requirements of the usage definition. It is conceivable that some usage definition forces the child key to be replaced and others allow child keys to be used based on the policy of the entities that use the child key.
ルートキーの有効期間は、EMSKの有効期間を超えてはなりません。したがって、EMSKの有効期限が切れると、EMSKから派生したルートキーを使用できなくなります。新しいEMSKが後続のEAPトランザクションから派生した場合、使用法の実装は、できるだけ早く新しいEMSKから派生した新しいルートキーの使用を開始する必要があります。ルートキーに関連付けられた子キーが置き換えられるかどうかは、使用法定義の要件によって異なります。使用法の定義によっては、子キーを強制的に置き換えたり、子キーを使用するエンティティのポリシーに基づいて子キーの使用を許可したりすることが考えられます。
Recall that the EMSK never leaves the EAP peer and server. That also holds true for some Root Keys; however, some Root Keys may be provided to other entities for child key derivation and delivery. Each usage definition specification will specify delivery caching and/or delivery procedures. Note that the purpose of the key derivation in Section 3 is to ensure that Root Keys are cryptographically separate from each other and the EMSK. In other words, given a Root Key, it is computationally infeasible to derive the EMSK, any other Root Keys, or child keys associated with other Root Keys. In addition to the Root Key, several other parameters may need to be sent.
EMSKがEAPピアとサーバーを離れることはありません。これは、一部のルートキーにも当てはまります。ただし、一部のルートキーは、子キーの派生と配信のために他のエンティティに提供される場合があります。各使用定義仕様は、配信キャッシングおよび/または配信手順を指定します。セクション3での鍵導出の目的は、ルート鍵が互いに、およびEMSKから暗号的に分離されることを保証することであることに注意してください。つまり、ルートキーが指定されている場合、EMSK、他のルートキー、または他のルートキーに関連付けられた子キーを導出することは、計算上実行不可能です。ルートキーに加えて、他のいくつかのパラメータを送信する必要がある場合があります。
Root Key names may be derived using the EAP Session-ID, and thus the key name may need to be sent along with the key. When Root Keys are delivered to another entity, the EMSKname and the lifetime associated with the specific root keys MUST also be transported to that entity. Recommendations for transporting keys are discussed in the Security Considerations (Section 7.4).
ルートキー名はEAPセッションIDを使用して取得できるため、キーと共にキー名を送信する必要がある場合があります。ルートキーが別のエンティティに配信されると、EMSKnameと特定のルートキーに関連付けられた有効期間もそのエンティティに転送される必要があります。鍵の転送に関する推奨事項は、セキュリティに関する考慮事項（セクション7.4）で説明されています。
Usage definitions may also define how keys are bound to particular entities. This can be done through the inclusion of usage parameters and identities in the child key derivation. Some of this data is described as "channel bindings" in [RFC3748].
使用法の定義では、キーを特定のエンティティにバインドする方法も定義できます。これは、子キーの派生に使用パラメーターとIDを含めることで実行できます。このデータの一部は、[RFC3748]で「チャネルバインディング」として説明されています。
The system that wishes to make use of EAP root keys derived from the EMSK must take certain things into consideration. The following is a list of these considerations:
EMSKから派生したEAPルートキーを使用するシステムでは、特定の事項を考慮する必要があります。以下は、これらの考慮事項のリストです。
o The EMSK MUST NOT be used for any other purpose than the key derivation described in this document.
o EMSKは、このドキュメントで説明されている鍵の派生以外の目的で使用してはなりません。
o The EMSK MUST be secret and not known to someone observing the authentication mechanism protocol exchange.
o EMSKは秘密である必要があり、認証メカニズムのプロトコル交換を監視している人には知られていません。
o The EMSK MUST be maintained within a protected location inside the entity where it is generated. Only root keys derived according to this specification may be exported from this boundary.
o EMSKは、それが生成されるエンティティー内の保護された場所内で維持する必要があります。この境界からエクスポートできるのは、この仕様に従って導出されたルートキーのみです。
o The EMSK MUST be unique for each EAP session
o EMSKはEAPセッションごとに一意である必要があります
o The EAP method MUST provide an identifier for the EAP transaction that generated the key.
o EAPメソッドは、キーを生成したEAPトランザクションの識別子を提供する必要があります。
o The system MUST define which usage definitions are used and how they are invoked.
o システムは、どの使用定義が使用され、どのように呼び出されるかを定義する必要があります。
o The system may define ways to select an alternate PRF for key derivation as defined in Section 3.1.
o システムは、セクション3.1で定義されているように、鍵導出用の代替PRFを選択する方法を定義できます。
The system MAY use the MSK transmitted to the Network Access Server (NAS) in any way it chooses in accordance with [RFC3748], [RFC5247], and other relevant specifications. This is required for backward compatibility. New usage definitions following this specification MUST NOT use the MSK. If more than one usage uses the MSK, then the cryptographic separation is not achieved. Implementations MUST prevent such combinations.
システムは、ネットワークアクセスサーバー（NAS）に送信されたMSKを、[RFC3748]、[RFC5247]、およびその他の関連仕様に従って選択した方法で使用できます（MAY）。これは下位互換性のために必要です。この仕様に従う新しい使用法の定義では、MSKを使用してはなりません。複数の使用法がMSKを使用する場合、暗号化の分離は行われません。実装では、このような組み合わせを防止する必要があります。
The effective key strength of the derived keys will never be greater than the strength of the EMSK (or a master key internal to an EAP mechanism).
派生キーの有効なキー強度は、EMSK（またはEAPメカニズムの内部のマスターキー）の強度を超えることはありません。
The intent of the KDF is to derive keys that are cryptographically separate: the compromise of one of the Usage-Specific Root Keys (USRKs) should not compromise the security of other USRKs or the EMSK. It is believed that the KDF chosen provides the desired separation.
KDFの目的は、暗号的に分離されたキーを導出することです。Usage-SpecificRoot Key（USRK）の1つが侵害されても、他のUSRKまたはEMSKのセキュリティは侵害されません。選択されたKDFが望ましい分離を提供すると考えられています。
An implementation of an EAP framework should keep the EMSK internally as close to where it is derived as possible and only provide an interface for obtaining Root Keys. It may also choose to restrict which callers have access to which keys. A usage definition MUST NOT assume that any entity outside the EAP server or EAP peer has access to the EMSK. In particular, it MUST NOT assume that a lower layer has access to the EMSK.
EAPフレームワークの実装は、EMSKを内部で可能な限り近くに保持し、ルートキーを取得するためのインターフェイスのみを提供する必要があります。また、どの発信者がどのキーにアクセスできるかを制限することもできます。使用法の定義では、EAPサーバーまたはEAPピアの外部にあるエンティティがEMSKにアクセスできると想定してはなりません。特に、下位層がEMSKにアクセスできると想定してはなりません。
In some cases, it will be necessary or convenient to distribute USRKs from where they are generated. Since these are secret keys, they MUST be transported with their integrity and confidentiality maintained. They MUST be transmitted between authenticated and authorized parties. It is also important that the context of the key usage be transmitted along with the key. This includes information to identify the key and constraints on its usage such as lifetime.
場合によっては、USRKの生成元から配布することが必要または便利です。これらは秘密鍵であるため、整合性と機密性を維持したまま転送する必要があります。それらは、認証された当事者と承認された当事者の間で送信されなければなりません。また、キーの使用状況をキーとともに送信することも重要です。これには、キーを識別するための情報と、ライフタイムなどの使用に関する制約が含まれます。
This document does not define a mechanism for key transport. It is up to usage definitions and the systems that use them to define how keys are distributed. Usage definition designers may enforce constraints on key usage by various parties by deriving a key hierarchy and by providing entities only with the keys in the hierarchy that they need.
このドキュメントでは、キー転送のメカニズムを定義していません。キーの配布方法を定義するために使用定義とシステムを使用します。使用法定義の設計者は、キー階層を導出し、エンティティに必要な階層内のキーのみを提供することにより、さまざまな関係者によるキー使用法に制約を課すことができます。
The key lifetime is dependent upon how the key is generated and how the key is used. Since the Root Key is the responsibility of the usage definition, it must determine how long the key is valid for. If key lifetime or key strength information is available from the authenticated key exchange, then this information SHOULD be used in determining the lifetime of the key. If possible, it is recommended that key lifetimes be coordinated throughout the system. Setting a key lifetime shorter that a system lifetime may result in keys becoming invalid with no convenient way to refresh them. Setting a key lifetime to longer may result in decreased security since the key may be used beyond its recommended lifetime.
キーの有効期間は、キーの生成方法と使用方法によって異なります。ルートキーは使用法定義の責任であるため、キーの有効期間を決定する必要があります。認証された鍵交換から鍵の寿命または鍵強度の情報が利用可能な場合、この情報は鍵の寿命を決定する際に使用されるべきです（SHOULD）。可能であれば、キーの有効期間をシステム全体で調整することをお勧めします。キーの有効期間をシステムの有効期間より短く設定すると、キーを更新する便利な方法がなく、キーが無効になる場合があります。キーのライフタイムを長く設定すると、キーが推奨ライフタイムを超えて使用される可能性があるため、セキュリティが低下する可能性があります。
The number of root keys derived from the EMSK is expected to be low. Note that there is no randomness required to be introduced into the EMSK-to-Root-Key derivation beyond the root key labels. Thus, if many keys are going to be derived from a Root Key, it is important that Root-Key-to-child-key derivation introduce fresh random numbers in deriving each key.
EMSKから派生したルートキーの数は少ないと予想されます。ルートキーラベル以外に、EMSKからルートキーへの派生に導入する必要のあるランダム性はないことに注意してください。したがって、ルートキーから多くのキーが導出される場合、ルートキーから子キーへの導出で各キーを導出する際に新しい乱数を導入することが重要です。
The keywords "Private Use", "Specification Required", and "IETF Consensus" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC5226].
名前空間の割り当てを説明するためにこのドキュメントで使用されている「私的使用」、「仕様が必要」、および「IETFコンセンサス」というキーワードは、[RFC5226]で説明されているように解釈されます。
This specification introduces a new name space for "USRK Key Labels". Key labels MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ("@") except as noted below, comma (","), whitespace, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL). Labels are case-sensitive and MUST NOT be longer than 64 characters.
この仕様では、「USRKキーラベル」の新しい名前空間が導入されています。キーラベルは、印刷可能なUS-ASCII文字列である必要があり、以下に示す場合を除き、アットマーク（ "@"）、コンマ（ "、"）、空白、制御文字（ASCIIコード32以下）、またはASCIIコード127（DEL）。ラベルは大文字と小文字が区別され、64文字以下にする必要があります。
Labels can be assigned based on Specification Required policy [RFC5226]. In addition, the labels "experimental1" and "experimental2" are reserved for experimental use. The following considerations apply to their use:
ラベルは、Specification Requiredポリシー[RFC5226]に基づいて割り当てることができます。また、ラベル「experimental1」と「experimental2」は実験用に予約されています。これらの使用には、以下の考慮事項が適用されます。
Production networks do not necessarily support the use of experimental code points. The network scope of support for experimental values should carefully be evaluated before deploying any experiment across extended network domains, such as the public Internet. The potential to disrupt the stable operation of EAP devices is a consideration when planning an experiment using such code points.
実稼働ネットワークは必ずしも実験的なコードポイントの使用をサポートしていません。実験値のサポートのネットワーク範囲は、パブリックインターネットなどの拡張ネットワークドメインに実験を展開する前に慎重に評価する必要があります。 EAPデバイスの安定した動作を中断させる可能性は、そのようなコードポイントを使用して実験を計画する際の考慮事項です。
The network administrators should ensure that each code point is used consistently to avoid interference between experiments. Particular attention should be given to security vulnerabilities and the freedom of different domains to employ their own experiments. Cross-domain usage is NOT RECOMMENDED.
ネットワーク管理者は、実験間の干渉を回避するために、各コードポイントが一貫して使用されるようにする必要があります。セキュリティの脆弱性と、独自の実験を使用するためのさまざまなドメインの自由に特に注意を払う必要があります。クロスドメインの使用は推奨されません。
Similarly, labels "private1" and "private2" have been reserved for Private Use within an organization. Again, cross-domain usage of these labels is NOT RECOMMENDED.
同様に、「private1」と「private2」のラベルは、組織内の私的使用のために予約されています。繰り返しになりますが、これらのラベルのクロスドメイン使用はお勧めしません。
Labels starting with a string and followed by the "@" and a valid, fully qualified Internet domain name [RFC1034] can be requested by the person or organization that is in control of the domain name. Such labels can be allocated based on Expert Review with Specification Required. Besides the review needed for Specification Required (see Section 4.1 of [RFC5226]), the expert needs to review the proposed usage for conformance to this specification, including the suitability of the usage according to the applicability statement outlined in Section 1.1. It is RECOMMENDED that the specification contain the following information:
文字列で始まり、その後に「@」と有効な完全修飾インターネットドメイン名[RFC1034]が続くラベルは、ドメイン名を制御している個人または組織が要求できます。このようなラベルは、仕様が必要なエキスパートレビューに基づいて割り当てることができます。スペシフィケーションが必要とされるレビュー（[RFC5226]のセクション4.1を参照）に加えて、エキスパートは、セクション1.1で概説されている適用性ステートメントに従った使用法の適合性を含め、この仕様への適合について提案された使用法をレビューする必要があります。仕様には次の情報を含めることをお勧めします。
o A description of the usage
o 使用法の説明
o The key label to be used
o 使用する鍵ラベル
o Length of the Root Key o If optional data is used, what it is and how it is maintained
oルートキーの長さoオプションのデータが使用されている場合、それは何であり、どのように維持されているか
o How child keys will be derived from the Root Key and how they will be used
o 子キーがルートキーからどのように派生し、どのように使用されるか
o How lifetime of the Root Key and its child keys will be managed
o ルートキーとその子キーの有効期間を管理する方法
o Where the Root Keys or child keys will be used and how they are communicated if necessary
o ルートキーまたは子キーが使用される場所と、必要な場合の伝達方法
The following labels are reserved by this document: "EMSK", "dsrk@ietf.org".
このドキュメントで予約されているラベルは、「EMSK」、「dsrk@ietf.org」です。
This specification introduces a new number space for "EMSK PRF numbers". The numbers are in the range 0 to 255. Numbers from 0 to 220 are assigned through the policy IETF Consensus, and numbers in the range 221 to 255 are left for Private Use. The initial registry contains the following values:
この仕様では、「EMSK PRF番号」用の新しい番号スペースが導入されています。番号の範囲は0〜255です。0〜220の番号は、IETFコンセンサスポリシーを通じて割り当てられ、221〜255の範囲の番号は私的使用のために残されます。初期レジストリには、次の値が含まれています。
0 RESERVED
0予約済み
1 HMAC-SHA-256 PRF+ (Default)
1 HMAC-SHA-256 PRF +（デフォルト）
This document expands upon previous collaboration with Pasi Eronen. This document reflects conversations with Bernard Aboba, Jari Arkko, Avi Lior, David McGrew, Henry Haverinen, Hao Zhou, Russ Housley, Glen Zorn, Charles Clancy, Dan Harkins, Alan DeKok, Yoshi Ohba, and members of the EAP and HOKEY working groups.
このドキュメントは、Pasi Eronenとの以前のコラボレーションを拡張したものです。このドキュメントは、Bernard Aboba、Jari Arkko、Avi Lior、David McGrew、Henry Haverinen、Hao Zhou、Russ Housley、Glen Zorn、Charles Clancy、Dan Harkins、Alan DeKok、Yoshi Ohba、およびEAPおよびHOKEYワーキンググループのメンバーとの会話を反映しています。
Thanks to Dan Harkins for the idea of using a single root key name to refer to all keys.
単一のルートキー名を使用してすべてのキーを参照するというアイデアを提供してくれたDan Harkinsに感謝します。
[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、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「インターネットキーエクスチェンジ（IKEv2）プロトコル」、RFC 4306、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月。
[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、「Extensible Authentication Protocol（EAP）Key Management Framework」、RFC 5247、2008年8月。
[SHA256] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-2, With Change Notice 1 dated February 2004, August 2002.
[SHA256]米国国立標準技術研究所、「Secure Hash Standard」、FIPS 180-2、変更通知1（2004年2月、2002年8月）
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、2006年4月。
[SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", LNCS 2729, Springer, 2003, <http://www.informatik.uni-trier.de/~ley/db/conf/ crypto/crypto2003.html>.
[シグマ] Krawczyk、H。、「シグマ：認証済みDiffie-Hellmanへの「SIGn-and-MAc」アプローチとIKEプロトコルでの使用」、LNCS 2729、Springer、2003、<http：//www.informatik。 uni-trier.de/~ley/db/conf/crypto/crypto2003.html>。
Authors' Addresses
著者のアドレス
Joseph Salowey Cisco Systems
ジョセフSaloweyシスコシステムズ
EMail: jsalowey@cisco.com
Lakshminath Dondeti Qualcomm, Inc
Laxminath Dandeti Qualcomm、これ
EMail: ldondeti@qualcomm.com
Vidya Narayanan Qualcomm, Inc
Vidya Narayanan Qualcomm、Inc
EMail: vidyan@qualcomm.com
Madjid Nakhjiri Motorola
マジッド・ナクジリ・モトローラ
EMail: madjid.nakhjiri@motorola.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2008).
Copyright（C）IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。