RFC5295 日本語訳
5295 Specification for the Derivation of Root Keys from an ExtendedMaster Session Key (EMSK). J. Salowey, L. Dondeti, V. Narayanan, M.Nakhjiri. August 2008. (Format: TXT=45622 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
Saloweyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5295のシスコシステムズアップデート: 5247年のL.Dondetiカテゴリ: 標準化過程V.ナラヤナンクアルコム、Inc M.Nakhjiriモトローラ2008年8月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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)は、Extended Master Session Key(EMSK)世代を定義しましたが、不特定の将来の用途のためにそれを予約しました。 このメモはルートキーを引き出す唯一の目的のためにEMSKを予約します。 ルートキーは用法定義で特定された複数の目的に使用できるマスターキーです。 また、このドキュメントはルートキーの間で暗号の分離を保証する方法でそれらを引き出すことによって摩擦を避けるのにメカニズムを指定します。 また、最終的に、このドキュメントはそのような用法のルートキー1つを定義します: ドメイン特有のRootキーズは特定のかぎ管理ドメインの中で利用可能で使用されるようにされたルートキーです。
Salowey, et al. Standards Track [Page 1] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[1ページ]RFC5295EMSK根
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 キーの適切な使用法がEMSK. . . . . 3 1.2に由来していました。 用語. . . . . . . . . . . . . . . . . . . . . . . 5 2。 暗号の分離と連携主要な派生. . . 6 3。 EMSKの主要な根の派生フレームワーク. . . . . . . . . . . . . . 7 3.1。 USRK派生. . . . . . . . . . . . . . . . . . . . . 8 3.1.1。 KDFs. . . . . . . . . . . . . . . . . . . . . 9 3.1.2に関して。 デフォルトKDF. . . . . . . . . . . . . . . . . . . . . 9 3.2。 EMSKとUSRKは派生. . . . . . . . . . . . . . 10 4を命名します。 ドメイン特有のルートキー派生. . . . . . . . . . . . . 11 4.1。 マルチドメイン用法. . . . . . . . . . . 12 5の適用性。 用法定義. . . . . . . . . . . . . . 13 5.1のための要件。 Key Managementガイドライン. . . . . . . . . . . . . . 13 6を根づかせてください。 EAPシステム. . . . . . . . . . . . . . . . . 14 7のための要件。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 15 7.1。 主要な強さ. . . . . . . . . . . . . . . . . . . . . . . 15 7.2。 キー. . . . . . . . . . . . . 15 7.3の暗号の分離。 実装. . . . . . . . . . . . . . . . . . . . . . 15 7.4。 主要な分配. . . . . . . . . . . . . . . . . . . . . 16 7.5。 主要な生涯. . . . . . . . . . . . . . . . . . . . . . . 16 7.6。 エントロピーの考慮. . . . . . . . . . . . . . . . . . 16 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 16 8.1。 主要なラベル. . . . . . . . . . . . . . . . . . . . . . . . 17 8.2。 PRF No.. . . . . . . . . . . . . . . . . . . . . . . 18 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 18 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 19 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 19
Salowey, et al. Standards Track [Page 2] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[2ページ]RFC5295EMSK根
1. Introduction
1. 序論
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は材料を合わせる2つのタイプを定義します: マスターセッションキー(MSK)と拡張マスターセッションキー(EMSK)。 EAP仕様は、EAPによって生産されたMSKが単一のデバイスのただ一つの目的に使用されるとそれとなく仮定します。 しかしながら、それは今後の使用のためにEMSKを予約します。 このドキュメントは、唯一指定された主要な派生を使用することでルートキーを引き出すのに使用されるためにEMSKを定義します。 ルートキーは用法と呼ばれる明確な目標のために意味されます。 特別な用法のクラスは特定のかぎ管理ドメインの中で利用可能で使用されるようにされたDomain特有のRootキーズです。 また、このドキュメントは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の主要な材料の特定の使用法がこの仕様を利用するように、それはいわゆる用法定義を指定しなければなりません。 このドキュメントは派生しているUsage特定のRootキーズ(USRK)がどう使用されているかを定義しません。 適切な用法の議論に関して以下のセクションを見てください。 独自にお互いと異なった用法を開発できて、それは異なる役割のためのUSRKsの派生のためにフレームワークを定義します。 目標は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.
Domainの特定のRoot Key(DSRK)は、かぎ管理ドメインに特定のキーを引き出すことにおける使用のためにこのドキュメントがUSRKの特別なクラスを定義すると呼びました。 各DSRKはDomainの特定のUsage特有のRootキーズを引き出すのに使用されるルートキー(DSUSRK)です。 DSUSRKsは特定のかぎ管理ドメインに特定のUSRKsです。
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.1. Applicable Usages of Keys Derived from the EMSK
1.1. EMSKから得られたキーの適切な使用法
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
EMSKはネットワークアクセス認証と承認の一部と通常書き立てられます。 プロトコルが関連した中古のコネがネットワークアクセスで、そのようであったならEMSKから得られたキーが望んでいると予想されます。
Salowey, et al. Standards Track [Page 3] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[3ページ]RFC5295EMSK根
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.
引き渡し最適化、およびこれらのプロトコルの範囲が通常そうので、どの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から得られたキーを使用するNOT RECOMMENDEDです。
Salowey, et al. Standards Track [Page 4] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[4ページ]RFC5295EMSK根
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.
これらのグループキー分配プロトコルの定義は、このドキュメントの範囲を超えていて、追加仕様を必要とするでしょう。
1.2. Terminology
1.2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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 Server、同輩、固有識別文字、Master Session Key(MSK)、Extended Master Session Key(EMSK)、Cryptographic Separation。
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つ以上のセキュリティ機能を提供する暗号化キーの材料の用法Definition An塗布。 このドキュメントは用法定義に含まれるべきであることのためのガイドラインと推薦を提供します。 このドキュメントは使用のタイプにおける規制がケースに入れるいずれか用法定義を作成するサービスを置きません。
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.
材料を合わせる用法特有のRoot Key(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.
Key Management Domain Aかぎ管理ドメインは与えられたルートキーの範囲によって指定されます。 範囲はそのキーから得られたアクセスキーの材料に認可されたシステムの収集です。 (3) かぎ管理ドメインの中のシステムは(2) (1)に認可されて、主要資材を誘導してください、使用が材料を合わせるということであるかもしれませんか同じドメインの他のシステムに主要資材を分配してください。 派生しているキーの範囲はそれが引き出されるキーの範囲の部分集合に抑制されます。 本書では、別の方法で資格がない場合、「ドメイン」という用語はかぎ管理ドメインについて言及します。
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
特定のかぎ管理ドメインでの使用に制限されるEMSKから得られた材料を合わせるドメインSpecific Root Key(DSRK。) それは、特定の用法定義のための子供キーを引き出すのに使用されます。 aから得られた子供キー
Salowey, et al. Standards Track [Page 5] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[5ページ]RFC5295EMSK根
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はDomain特有のUsage特有のRootキーズ(DSUSRKs)と呼ばれます。 DSUSRKはUSRKと同様です、範囲がそれが引き出される親DSRKと同じドメインに制限されるという事実を除いて。
2. Cryptographic Separation and Coordinated Key Derivation
2. 暗号の分離と連携主要な派生
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の派生がたとえば、暗号のハッシュ関数を逆にするのに必要であるそれに同等な計算の量を必要としなければならないことを意味します。
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の上のPseudo無作為のFunction(PRF)を使用してください、そして、主要なストリームを生成してください。 必要に応じて様々な長さのキーを主要なストリームから様々な用途に提供するかもしれません。
o Derive keys from EMSK by providing different inputs to the PRF.
o EMSKから異なった入力をPRFに供給することによって、キーを得てください。
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に由来している他のすべての用法によります。 1つの用法による警備上の問題が別の用法を妨げるのを防ぐために、以下の暗号の分離が必要です:
o It MUST be computationally infeasible to compute the EMSK from any
root key derived from it.
o それから得られたどんなルートキーからもEMSKを計算するのは計算上実行不可能でなければなりません。
Salowey, et al. Standards Track [Page 6] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[6ページ]RFC5295EMSK根
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 USRKsの派生を調整しなければならないので、2つの別々の暗号の用法は同じキーを引き出しません。
o Derivation of DSRKs MUST be coordinated so that two separate key
management domains do not derive the same key.
o DSRKsの派生を調整しなければならないので、2つの別々のかぎ管理ドメインは同じキーを引き出しません。
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 どんなドメインもUsage Key Labelと同じドメイン名を提供することによってUSRKを入手できないように、DSRKsとUSRKsの派生を指定しなければなりません。
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メソッドのためのガイドラインを提供します。 これは異なった用法定義の間の厄介なコーディネートなしで新しい用法の開発を考慮します。
3. EMSK Key Root Derivation Framework
3. EMSKの主要な根の派生フレームワーク
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
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からUsage特有のRootキーズ(USRKs)を引き出す方法を定義して、また、Domainの特定のRoot Key(DSRK)と呼ばれる特定のUSRKを定義します。 DSRKsは特定のかぎ管理ドメインでの使用に制限されたルートキーです。 DSRKから、特定用途のためのUsage特有のRootキーズは引き出されるかもしれません(DSUSRKs)。 DSUSRKsは特定のドメインでの使用に制限されるUSRKsに同等です。 このドキュメントの範囲の外に主要な階層構造の下のレベルの詳細があります。 主要な階層構造は以下の通りに見えます:
Salowey, et al. Standards Track [Page 7] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[7ページ]RFC5295EMSK根
EMSK
/ \
USRK DSRK
/ \
DSUSRK1 DSUSRK2
EMSK/\USRK DSRK/\DSUSRK1 DSUSRK2
3.1. USRK Derivation
3.1. USRK派生
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 Root Key Derivation Function(KDF)がUSRKにEMSK、主要なラベル、任意のデータ、および出力の長さに由来しています。 KDFが同じ入力のための同じ出力を与えると予想されます。 基本的な主要な派生機能を以下に与えます。
USRK = KDF(EMSK, key label | "%%BODY%%" | optional data | length)
USRKはKDFと等しいです。「(主要なラベル| 」 %%BODY%%インチ| 任意のデータ| EMSK、長さ)
where:
どこ:
| denotes concatenation
"%%BODY%%" is a NULL octet (0x00 in hex)
length is a 2-octet unsigned integer in network byte order
「|、連結を指示する、」 %%BODY%%インチによるaヌル八重奏(十六進法における0×00)の長さがネットワークバイトオーダーで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はRoot Keyの用法定義の仕様を制御する組織です。 主要なラベルがグローバルなユニークさを提供することを意図します。 セクション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.
そして、主要なラベルが1個の主要なラベルが別のラベルの接頭語であるなら衝突を避けるのに使用された後にNULL八重奏、(例えば、"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 MUST、少なくとも2048の不透明な八重奏を処理できてください。 任意のデータはKDFの実行の間、一定であるに違いありません。 用法定義はKDF機能に入る任意のデータパラメタの仕様でEAP Session-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バイトの入力キーを処理できなければなりません。 それは、長いキーが基本的な誘導アルゴリズムで消費できる適当なサイズまで「論じ尽くす」であるのにメカニズムを提供することによって、これをするかもしれません。
Salowey, et al. Standards Track [Page 8] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[8ページ]RFC5295EMSK根
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 MUSTでは、出力の少なくとも2048の八重奏を起こすことができてください。 しかしながら、Rootキーズが長い間少なくとも64の八重奏であることがRECOMMENDEDです。
A usage definition requiring derivation of a Root Key must specify all the inputs (other than EMSK) to the key derivation function.
Root Keyの派生を必要とする用法定義はすべての入力(EMSKを除いた)を主要な派生機能に指定しなければなりません。
USRKs MUST be at least 64 octets in length.
USRKsは長さが少なくとも64の八重奏であるに違いありません。
3.1.1. On the KDFs
3.1.1. KDFsに関して
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:
この仕様は異なったKDFsの使用を考慮します。 しかしながら、連携主要な派生機能を持っていて、すべての与えられたEMSKに、主要な派生に同じKDF機能を使用しなければなりません。 KDFが全く指定されないなら、セクション3.1.2で指定されたデフォルトKDFを使用しなければなりません。 システムは追加KDFsを交渉する能力を提供するかもしれません。 セクション8に設定された方針に従って、数はIANAを通してKDFsに割り当てられます。 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を指定するかもしれません。 例えば、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で指定された入力を心配する必要があるだけです。
3.1.2. Default KDF
3.1.2. デフォルトKDF
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:
HMAC-SHA-256[SHA256]に基づく[RFC4306]で指定されたPRF+主要な拡張からEMSKからルートキーを得るためのデフォルトKDFを取ります。 PRF+工事はその簡単さと効率のために[RFC4346]で使用されるものなどの他のメカニズムに関して選ばれました。 +が説明されるPRFのデザイン[SIGMA]に関する動機。 [RFC4306]からの+が与えられているPRFの定義:
Salowey, et al. Standards Track [Page 9] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[9ページ]RFC5295EMSK根
PRF+ (K,S) = T1 | T2 | T3 | T4 | ...
PRF+(K、S)はT1と等しいです。| T2| T3| T4| ...
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(S| K、0×01)T2=PRF(K、T1|S|0×02)T3=PRF(K、T2|S|0×03)T4はPRFと等しいです。(K、T3|S|0×04)
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はセクション3.1で定義された主要なラベル、NULL八重奏、任意のデータ、および長さの連結です。 この仕様において、PRFはHMAC-SHA-256[SHA256]としてみなされます。 PRF以来、+は255繰り返しのために定義されるだけであり、それは主要な材料の8160の八重奏まで生産されるかもしれません。
3.2. EMSK and USRK Name Derivation
3.2. EMSKとUSRK名前派生
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:
フレームワーク[RFC5247]を合わせるEAPは、EMSK MUSTがEAP Session-IDと2進の、または、原文の指示を使用すると命名されると指定します。 要件、EMSKがSHALLを命名するのに続いて、以下の通り引き出されてください:
EMSKname = KDF ( EAP Session-ID, "EMSK" | "%%BODY%%" | length )
EMSKnameはKDFと等しいです。「("EMSK"| 」 %%BODY%%インチ| EAP Session-ID、長さ)
where:
どこ:
| denotes concatenation
"EMSK" consists of the 4 ASCII values for the letters
"%%BODY%%" = is a NULL octet (0x00 in hex)
length is the 2-octet unsigned integer 8 in network byte order
「|、指示、連結"EMSK"が成る、=によるaヌル八重奏(十六進法における0×00)の長さがネットワークバイトオーダーで2八重奏の符号のない整数8であるというASCIIが手紙のために」 %%BODY%%インチ評価する4では、ことです。
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と文脈によって言及されるのは、RECOMMENDEDです。 これはデフォルトの振舞いです。 どんな例外SHALL、も独特の用法で、合図されてください。
USRKs MAY be named explicitly with a name derivation specified as follows:
名前派生が以下の通り指定されている状態で、USRKsは明らかに命名されるかもしれません:
USRKName =
KDF(EAP Session-ID, key label|"%%BODY%%"|optional data|length)
USRKNameはKDFと等しいです。「(主要なラベル| 」 %%BODY%%インチ| 任意のデータ| EAP Session-ID、長さ)
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であるということであるに違いありません。
Salowey, et al. Standards Track [Page 10] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[10ページ]RFC5295EMSK根
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.
USRK用法のEMSKnameと関連文脈を使用することでキーに参照をつけるのにおいてあいまいさがあるとき、USRKName派生と用法は適切です。 用法SHALLが主要な命名におけるそのような例外に合図するので、したがって、双方は使用という主要な名前を知っています。
4. Domain-Specific Root Key Derivation
4. ドメイン特有のルートキー派生
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:
特定のかぎ管理ドメインの特定の使用法のためにEMSKからDomain特有のRoot Key(DSRK)と呼ばれる特定のUSRKを得ます。 用法が特定のサービスのための特定のキーにこのDSRKに由来しています。 それらの用法のためにかぎ管理ドメインの中でキーを引き出すことができて、DSRKは特定の使用法のためにかぎ管理ドメインに分配されるかもしれません。 DSRKベースの用法は以下と同様の主要な階層構造に従うでしょう:
EMSK
/ \
/ \
/ \
/ \
DSRK1 DSRK2
/ \ / \
/ \ / \
DSUSRK11 DSUSRK12 DSUSRK21 DSUSRK22
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 MUSTは少なくともそうです。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.
DSRKからドメイン特有のUsage特有のRootキーズ(DSUSRKs)を得ます。 KDFが同じ入力のための同じ出力を与えると予想されます。 基本的な主要な派生機能を以下に与えます。
DSUSRK = KDF(DSRK, key label | "%%BODY%%" | optional data | length)
DSUSRKはKDFと等しいです。「(主要なラベル| 」 %%BODY%%インチ| 任意のデータ| DSRK、長さ)
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
主要なラベルは、それぞれの用法定義に、DSRK用法の中でユニークな印刷可能なASCIIストリングであり、最大255の八重奏です。 一般に、それらはspecorgがDSRKの用法定義の仕様を制御する組織であるところのフォーム label-string@specorg のものです。 主要なラベルがグローバルなユニークさを提供することを意図します。 セクション8でこれらのラベルの配分のための規則を与えます。 任意のデータ、KDF MUST、少なくとも2048の不透明な八重奏を処理できてください。 任意のデータはKDFの実行の間、一定であるに違いありません。 長さは八重奏における出力キー長のネットワークバイトオーダーで2八重奏の符号のない整数です。 実装、KDF MUSTでは、生産できてください。
Salowey, et al. Standards Track [Page 11] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[11ページ]RFC5295EMSK根
least 2048 octets of output; however, it is RECOMMENDED that DSUSRKs be at least 64 octets long.
出力の最少の2048の八重奏。 しかしながら、DSUSRKsが長い間少なくとも64の八重奏であることがRECOMMENDEDです。
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を利用する用法は同輩がどう特定の派生に使用するドメインラベルを学ぶかを定義しなければなりません。 マルチドメイン用法はDSRKsと特定のDSUSRKsの両方がどう異なったかぎ管理ドメインに輸送されるかを定義しなければなりません。 用法が特定のかぎ管理ドメインの特定のキーを抑制する代替の方法を定義するかもしれないことに注意してください。
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.
DSRKs、EMSKname SHOULDから引き出しているキーについて言及するためにEMSKnameの使用を容易にするには、DSRKと共に送ってください。 例外はDSRKnameが使用されると予想される時です。 用法SHALLが主要な命名におけるそのような例外に合図するので、したがって、双方は使用という主要な名前を知っています。
DSUSRKs MAY be named explicitly with a name derivation specified as follows:
名前派生が以下の通り指定されている状態で、DSUSRKsは明らかに命名されるかもしれません:
DSUSRKName =
KDF(EMSKName,key label | "%%BODY%%" | optional data | length)
DSUSRKNameはKDFと等しいです。「(主要なラベル| 」 %%BODY%%インチ| 任意のデータ| EMSKName、長さ)
where length is the 2-octet unsigned integer 8 in network byte order.
長さがネットワークバイトオーダーで2八重奏の符号のない整数8であるところ。
4.1. Applicability of Multi-Domain Usages
4.1. マルチドメイン用法の適用性
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.
ドメインの実体が具体的な機能を実行するのを認可するのにドメインによって生成されたDSUSRKsは使用できます。 特定のドメインだけが認可されるのが、適切である場合では、機能、用法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を受けるべきでなくて、それらが認可されている用法のためにDSUSRKsを受けるだけであるべきです。 同輩が、どのドメインが特定の用法のためにアクセスをDSRKに制限するのを当てにしないで特定のドメインに認可されるかを知るのが、可能であるなら、この推薦はリラックスするかもしれません。
Salowey, et al. Standards Track [Page 12] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[12ページ]RFC5295EMSK根
5. Requirements for Usage Definitions
5. 用法定義のための要件
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で指定された主要な派生を使用することでRootキーズを引き出す以外に、用法定義はいかなる他の方法でもEMSKを使用してはいけません。 彼らは直接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 用法定義SHOULD NOTは、EMSKがキャッシュされるのを必要とします。 特に用法定義(EMSKよりむしろ)のために引き出されたRoot Keyが特定の暗号の操作のための子供キーを引き出すのに使用されるべきであるのは、RECOMMENDEDです。
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で説明された主要な派生に使用される異なった主要なラベルと任意のデータを定義しなければなりません。 用法定義は、セクション3.2で説明された主要な名前を使用して、追加エントロピーを提供するために任意のデータに追加データを含んでいるよう奨励されます。
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 用法定義はそれらのRootキーズの長さを定義しなければなりません。 RootキーズがEMSK(少なくとも64の八重奏)と少なくとも同じくらい長いのは、RECOMMENDEDです。
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 用法定義はそれらがどう自己のRootキーズを使用するかを定義しなければなりません。 これはRoot Key管理ガイドラインの次のセクションでカバーされたかぎ管理の局面を含んでいます。
5.1. Root Key Management Guidelines
5.1. ルートキー管理ガイドライン
This section makes recommendations for various aspects of key management of the Root Key including lifetime, child key derivation, caching, and transport.
このセクションは生涯、子供の主要な派生、キャッシュ、および輸送を含むRoot Keyのかぎ管理の種々相のための推薦状をします。
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.
Root Keyが子供キーを引き出すのに使用されるだけであるのは、RECOMMENDEDです。 用法定義は、どのように、いつ子供キーの派生をするべきであるかを指定しなければなりません。 主要な派生のために同様の問題に従う用法が本書ではRoot Key派生のために暗号の分離と主要な再利用に関して概説されているようにあるのは、RECOMMENDEDです。 さらに、用法は、Root Keyから得られるキーの数を考慮に入れて、十分なエントロピーがこの用法をサポートするために派生で導入されるのを確実にするべきです。 エントロピーが子供キーを引き出す2回のパーティーによって提供されるのは、望ましいです。
Salowey, et al. Standards Track [Page 13] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[13ページ]RFC5295EMSK根
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.
'Rootキーズ'寿命はEMSKのものほど以上であるべきではありません。 EMSKが期限が切れるとき、したがって、使用からそれから得られたRootキーズを取り除くべきです。 その後のEAPトランザクションから新しいEMSKを得るなら、用法実装はできるだけ早く新しいEMSKから得られた新しいRootキーズを使用し始めるべきです。 Root Keyに関連している子供キーを取り替えるかどうかが用法定義の要件によります。 何らかの用法定義によってやむを得ず子供キーを取り替えるのが想像できて、他のものは子供キーを使用する実体の方針に基づいて子供キーを使用させます。
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同輩とサーバを決して置き去りにしないと思い出してください。また、それはいくつかのRootキーズに当てはまります。 しかしながら、子供の主要な派生と配送のためにいくつかのRootキーズを他の実体に提供するかもしれません。 それぞれの用法定義仕様は配送キャッシュ、そして/または、配送手順を指定するでしょう。 セクション3における主要な派生の目的がRootキーズが暗号でそうであることを保証することであるというメモは互いとEMSKから分離します。 言い換えれば、Root Keyを考えて、EMSK、いかなる他のRootキーズか他のRootキーズに関連している子供キーも引き出すのは計算上実行不可能です。 Root Keyに加えて、他のいくつかのパラメタが、送られる必要があるかもしれません。
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).
根のKey名はEAP Session-IDを使用することで引き出されるかもしれません、そして、その結果、主要な名前はキーと共に送られる必要があるかもしれません。 また、Rootキーズが別の実体に提供されるとき、特定のルートキーに関連しているEMSKnameと生涯をその実体に輸送しなければなりません。 Security Considerations(セクション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].
また、用法定義はキーがどう特定の実体に縛られるかを定義するかもしれません。 子供の主要な派生における用法パラメタとアイデンティティの包含でこれができます。 このいくつかのデータが[RFC3748]で「チャンネル結合」として記述されています。
6. Requirements for EAP System
6. EAPシステムのための要件
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 MUST NOT、本書では説明された主要な派生よりいかなる他の目的にはも、使用されてください。
o The EMSK MUST be secret and not known to someone observing the
authentication mechanism protocol exchange.
o 認証機構を観測しながら秘密であり、だれかにとって知られないEMSK MUSTは交換について議定書の中で述べます。
Salowey, et al. Standards Track [Page 14] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[14ページ]RFC5295EMSK根
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 MUST、実体におけるそれが発生している保護位置の中で維持されてください。 この境界からこの仕様通りに引き出されたルートキーだけをエクスポートしてもよいです。
o The EMSK MUST be unique for each EAP session
o EMSK MUST、それぞれの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.
システムは[RFC3748]、[RFC5247]、および他の関連仕様通りに選ぶどんな方法でもNetwork Access Server(NAS)に伝えられたMSKを使用するかもしれません。 これが後方の互換性に必要です。 この仕様に従う新しい用法定義はMSKを使用してはいけません。 1つ以上の用法がMSKを使用するなら、暗号の分離は達成されません。 実装はそのような組み合わせを防がなければなりません。
7. Security Considerations
7. セキュリティ問題
7.1. Key Strength
7.1. 主要な強さ
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メカニズムへの内部のマスターキー)の強さより決して大きくなくなるでしょう。
7.2. Cryptographic Separation of Keys
7.2. キーの暗号の分離
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特有のRootキーズ(USRKs)の1つの感染は他のUSRKsかEMSKのセキュリティに感染するべきではありません。 選ばれたKDFが必要な分離を提供すると信じられています。
7.3. Implementation
7.3. 実装
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を保って、Rootキーズを得るのにインタフェースを提供するだけであるべきです。 そうするかもしれません、また、どれを制限するかを選んでください。訪問者はそれのキーに近づく手段を持っています。 用法定義は、EAPサーバかEAP同輩の外のどんな実体もEMSKに近づく手段を持っていると仮定してはいけません。 特に、それは、下層がEMSKに近づく手段を持っていると仮定してはいけません。
Salowey, et al. Standards Track [Page 15] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[15ページ]RFC5295EMSK根
7.4. Key Distribution
7.4. 主要な分配
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.
いくつかの場合、彼らが発生しているところからUSRKsを分配するのは、必要であるか、または便利になるでしょう。 これらが秘密鍵であるので、それらの保全と秘密性が維持されている状態で、それらを輸送しなければなりません。 認証されて認可されたパーティーの間にそれらを伝えなければなりません。 また、主要な用法の文脈がキーと共に伝えられるのも、重要です。 これは、生涯などの用法でキーと規制を特定するために情報を含んでいます。
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.
このドキュメントは主要な輸送のためにメカニズムを定義しません。 用法定義とシステムまで、それらを使用して、キーがどう分配されているかを定義してください。 用法定義デザイナーは、様々なパーティーで彼らが必要とする階層構造で規制に主要な用法に主要な階層構造を引き出して、キーを実体に提供するだけで押しつけるかもしれません。
7.5. Key Lifetime
7.5. 主要な生涯
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.
主要な寿命は、キーがどう発生しているかの扶養家族とキーがどう使用されているかということです。 Root Keyが用法定義の責任であるので、それは、キーがどれくらい長いかを有効な状態で決定しなければなりません。 情報は主要な生涯か主要な強さであるなら認証された主要な交換、次に、この情報SHOULDから利用可能です。キーの生涯を決定する際に、使用されます。 できれば、主要な寿命がシステム中で調整されるのは、お勧めです。 より急に主要な生涯を決めて、システム寿命が中に結果として生じるかもしれないのがそれらをリフレッシュする便利な道のないふさわしい病人を合わせます。 キーがお勧めの生涯使用されるかもしれないので、より長いことへの主要な寿命がもたらすかもしれない設定はセキュリティを下げました。
7.6. Entropy Consideration
7.6. エントロピーの考慮
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から根のキーへの派生に導入するのに必要である偶発性が全くルートキーラベルを超えていないことに注意してください。 したがって、Root Keyから多くのキーを得るなら、Rootキーから子供キーへの派生が各キーを引き出す際に新鮮な乱数を紹介するのは、重要です。
8. IANA Considerations
8. IANA問題
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]で説明されるように解釈されることです。
Salowey, et al. Standards Track [Page 16] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[16ページ]RFC5295EMSK根
8.1. Key Labels
8.1. 主要なラベル
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の主要なラベル」のために新しい名前スペースを導入します。 主要なラベルは、以下に述べられるのを除いて、サインであることで("@")印刷可能な米国-ASCIIストリングでなければならなく、キャラクタを含んではいけません、コンマ、(「」、)、空白、制御文字(ASCIIよりコード32)、またはASCIIが127(デル)をコード化します。 ラベルは、大文字と小文字を区別していて、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.
ネットワーク管理者は、各コード・ポイントが実験の間の干渉を避けるのに一貫して使用されるのを保証するべきです。 セキュリティの脆弱性とそれら自身の実験を使う異なったドメインの自由に特別の注意を与えるべきです。 交差しているドメイン用法は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"は兵士のUseのために組織の中で予約されました」。 一方、これらのラベルの交差しているドメイン使用法はNOT RECOMMENDEDです。
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]を要求できます。 Specification RequiredとExpert Reviewに基づいてそのようなラベルを割り当てることができます。 Specification Required([RFC5226]のセクション4.1を見る)に必要であるレビュー以外に、専門家は、順応のための提案された用法をこの仕様に見直す必要があります、セクション1.1に概説された適用性証明によると、用法の適合を含んでいて。 仕様が以下の情報を含んでいるのは、RECOMMENDEDです:
o A description of the usage
o 用法の記述
o The key label to be used
o 使用されるべき主要なラベル
o Length of the Root Key
o ルートキーの長さ
Salowey, et al. Standards Track [Page 17] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[17ページ]RFC5295EMSK根
o If optional data is used, what it is and how it is maintained
o 任意のデータは使用されているか、そして、それが何であるかということであり、それはどう維持されるか。
o How child keys will be derived from the Root Key and how they will
be used
o Root Keyから子供キーをどう得るだろうか、そして、それらはどう使用されるだろうか。
o How lifetime of the Root Key and its child keys will be managed
o Root Keyとその子供キーの寿命はどう管理されるだろうか。
o Where the Root Keys or child keys will be used and how they are
communicated if necessary
o Rootキーズか子供キーがどこで使用されるでしょうか、そして、必要なら、それらはどう伝えられるか。
The following labels are reserved by this document: "EMSK", "dsrk@ietf.org".
以下のラベルはこのドキュメントによって予約されます: "EMSK"、" dsrk@ietf.org "。
8.2. PRF Numbers
8.2. PRF番号
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 Consensusで割り当てられます、そして、範囲221〜255の数は兵士のUseに残されます。 初期の登録は以下の値を含んでいます:
0 RESERVED
予約された0
1 HMAC-SHA-256 PRF+ (Default)
1 HMAC-SHA-256 PRF+(デフォルト)
9. Acknowledgements
9. 承認
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.
このドキュメントはパシEronenとの前の共同のときに広がります。 このドキュメントはバーナードAboba、ヤリArkko、アヴィLior、デヴィッド・マグリュー、ヘンリーHaverinen、ハオ・周、ラスHousley、Glenゾルン、チャールズClancy、ダン・ハーキンズ、アランDeKok、Yoshiオオバ、EAPのメンバー、およびHOKEYワーキンググループとの会話を反映します。
Thanks to Dan Harkins for the idea of using a single root key name to refer to all keys.
すべてのキーについて言及するのにただ一つのルートキー名を使用するという考えをダン・ハーキンをありがとうございます。
Salowey, et al. Standards Track [Page 18] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[18ページ]RFC5295EMSK根
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、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(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
[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)Key Managementフレームワーク」、RFC5247、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]米国商務省標準技術局、「安全なハッシュ規格」、FIPS180-2、With Change Notice1は2004年2月にデートしました、2002年8月。
10.2. Informative References
10.2. 有益な参照
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[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.、「σ:」 「Authenticatedディフィー-ヘルマンとIKEプロトコルのそのUseへの'SIGnとMAc'Approach」、LNCS2729、Springer、2003、<http://www.informatik.uni-trier.de/~レウ/db/conf/暗号/crypto2003.html>。
Salowey, et al. Standards Track [Page 19] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[19ページ]RFC5295EMSK根
Authors' Addresses
作者のアドレス
Joseph Salowey Cisco Systems
ジョゼフSaloweyシスコシステムズ
EMail: jsalowey@cisco.com
メール: jsalowey@cisco.com
Lakshminath Dondeti Qualcomm, Inc
Lakshminath Dondetiクアルコム、Inc
EMail: ldondeti@qualcomm.com
メール: ldondeti@qualcomm.com
Vidya Narayanan Qualcomm, Inc
Vidyaナラヤナンクアルコム、Inc
EMail: vidyan@qualcomm.com
メール: vidyan@qualcomm.com
Madjid Nakhjiri Motorola
Madjid Nakhjiriモトローラ
EMail: madjid.nakhjiri@motorola.com
メール: madjid.nakhjiri@motorola.com
Salowey, et al. Standards Track [Page 20] RFC 5295 EMSK Root Key Derivation August 2008
Salowey、他 派生2008年8月に主要な標準化過程[20ページ]RFC5295EMSK根
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Salowey, et al. Standards Track [Page 21]
Salowey、他 標準化過程[21ページ]
一覧
スポンサーリンク
