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
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的唯一目的是导出根密钥。根键是主键，可用于多种用途，由使用定义标识。本文档还指定了一种机制，通过以保证加密分离的方式派生根密钥来避免根密钥之间的冲突。最后，本文档还定义了一种这样的根密钥用法：特定于域的根密钥是提供给特定密钥管理域并在其中使用的根密钥。
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. 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）。EAP规范隐含地假设EAP生产的MSK将在单个设备上用于单个目的；但是，它确实保留了EMSK供将来使用。本文档定义了仅用于使用指定的密钥派生来派生根密钥的EMSK。根键用于称为usage的特定用途；特殊用法类是特定于域的根密钥，可供特定密钥管理域使用。本文档还提供了为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的派生定义了一个框架，以便可以相互独立地开发不同的用途。目标是使一个用法的安全属性对其他用法的安全属性影响最小或没有影响。
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.
本文档定义了一个特殊的USRK类，称为域特定根密钥（DSRK），用于派生特定于密钥管理域的密钥。每个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.
为了使根键在特定用途上彼此独立，以下部分定义了两个要求。一种是协调密钥派生，另一种是密码分离。
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的密钥将用于与网络访问相关的协议，例如
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派生的密钥作为专用安全机制，因为它们的使用不是固有的，也不是永久性的，绑定到执行网络访问认证的较低层。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
使用定义加密密钥材料的应用程序，用于为相关应用程序或服务提供一个或多个安全功能，如身份验证、授权、加密或完整性保护。本文档为使用定义中应包含的内容提供了指南和建议。本文档对创建使用定义的用例或服务的类型没有任何限制。
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）密钥材料，源于EMSK，仅限于在特定密钥管理域中使用。它用于派生特定用法定义的子键。派生自
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被称为域特定用法特定根密钥（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或从另一个子密钥派生EMSK必须需要相当于（比如）反转加密哈希函数所需的计算量。
Cryptographic separation of keys derived from the same key can be achieved in many ways. Two obvious methods are as follows:
从同一密钥派生的密钥的密码分离可以通过多种方式实现。两种明显的方法如下：
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导出一个子密钥独立于另一个子密钥的导出。从EMSK独立派生密钥允许以任何顺序派生子密钥，而不依赖于其他密钥。因此，最好使用上面的选项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:
如果未保持加密分离，则一个使用的安全性取决于使用从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的派生，以便两个单独的加密用法不会派生相同的密钥。
o Derivation of DSRKs MUST be coordinated so that two separate key management domains do not derive the same key.
o 必须协调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.
本文档提供了密钥派生机制的指南，该机制可与现有和新的EAP方法一起使用，以提供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生成多个根密钥。然后，可以出于各种目的从根密钥派生出其他密钥，包括加密、完整性保护、通过占有证明的实体认证以及随后的密钥派生。根密钥是从EMSK中派生出来的，用于第5节所述的使用定义中规定的一组特定使用。
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派生特定于使用情况的根密钥（USRK），还定义了一个称为域特定根密钥（DSRK）的特定USRK。DSRK是限制在特定密钥管理域中使用的根密钥。从DSRK可以导出特定应用程序的特定于使用情况的根密钥（DSUSRK）。DSUSRK等同于仅限于在特定域中使用的USRK。密钥层次结构较低级别的详细信息不在本文档范围内。密钥层次结构如下所示：
EMSK
/ \
USRK DSRK
/ \
DSUSRK1 DSUSRK2
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”是空八位字节（十六进制中的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个八位字节。一般来说，它们属于表单标签-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.
如果一个键标签是另一个标签的前缀（例如，“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。然而，为了具有协调的密钥派生函数，必须对给定EMSK的所有密钥派生使用相同的KDF函数。如果未指定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。例如，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:
根据HMAC-SHA-256[SHA256]，从[RFC4306]中指定的PRF+密钥扩展中获取从EMSK派生根密钥的默认KDF。选择PRF+结构是因为它比[RFC4346]中使用的其他机制更简单、更有效。PRF+设计的动机在[SIGMA]中描述。[RFC4306]中PRF+的定义如下：
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（K，S | 0x01）T2=PRF（K，T1 | S | 0x02）T3=PRF（K，T2 | S | 0x03）T4=PRF（K，T3 | S | 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是密钥标签、空八位字节、可选数据和第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]规定必须使用EAP会话ID和二进制或文本指示来命名EMSK。根据该要求，EMSK名称的推导如下：
EMSKname = KDF ( EAP Session-ID, "EMSK" | "\0" | length )
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”由字母“\0”=为空八位字节（十六进制为0x00）的4个ASCII值组成。长度为网络字节顺序的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.
建议使用EMSKname和子代密钥使用的上下文引用从EMSK派生的所有密钥。这是默认行为。任何例外情况都应通过单独的用途来表示。
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.
当使用EMSKname和USRK用法的关联上下文引用密钥时存在歧义时，USRKName派生和用法适用。该用法应表明密钥命名中存在此类异常，以便双方都知道所使用的密钥名称。
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
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是一个USRK，键标签为“dsrk@ietf.org“以及包含域标签的可选数据。可选数据必须包含表示为其派生根密钥的密钥管理域的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
密钥标签是可打印的ASCII字符串，对于DSRK使用中的每个使用定义都是唯一的，最多为255个八位字节。一般来说，它们属于表单标签-string@specorg其中specorg是控制DSRK使用定义规范的组织。密钥标签旨在提供全局唯一性。第8节给出了这些标签的分配规则。对于可选数据，KDF必须能够处理至少2048个不透明八位字节。在执行KDF期间，可选数据必须是常量。长度是以八位字节为单位的输出密钥长度的网络字节顺序的2个八位无符号整数。KDF的实现必须能够在
least 2048 octets of output; however, it is RECOMMENDED that DSUSRKs be at least 64 octets long.
至少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.
为了便于使用EMSKname引用从DSRK派生的密钥，应将EMSKname与DSRK一起发送。例外情况是预期使用DSRKname时。该用法应表明密钥命名中存在此类异常，以便双方都知道所使用的密钥名称。
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，键标签|“\0”|可选数据|长度）
where length is the 2-octet unsigned integer 8 in network byte order.
其中，length是网络字节顺序的2-octet无符号整数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可用于授权域中的实体执行特定功能。在仅授权特定域执行功能的情况下，不应将使用定义为多域。
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 使用定义不得以任何其他方式使用EMSK，除非使用本文档第3节中指定的密钥派生来派生根密钥。他们不得直接使用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进行缓存。建议使用专门为使用定义（而不是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节中描述的密钥派生中使用的不同密钥标签和可选数据。鼓励使用定义使用第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 使用定义必须定义其根键的长度。建议根密钥至少与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.
建议根密钥仅用于派生子密钥。用法定义必须指定派生子键的方式和时间。建议在本文档中，针对根密钥派生，在密码分离和密钥重用方面，使用与密钥派生类似的注意事项。此外，用法应考虑将从根键派生的键的数量，并确保在派生中引入足够的熵来支持此用法。期望熵由导出子密钥的双方提供。
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是从后续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].
使用定义还可以定义键如何绑定到特定实体。这可以通过在子密钥派生中包含使用参数和标识来实现。其中一些数据在[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必须保存在生成该EMSK的实体内的受保护位置内。只能从此边界导出根据此规范派生的根键。
o The EMSK MUST be unique for each EAP session
o 对于每个EAP会话，EMSK必须是唯一的
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]和其他相关规范选择的任何方式使用传输到网络接入服务器（NAS）的MSK。这是向后兼容性所必需的。遵循此规范的新用法定义不得使用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的目的是派生加密独立的密钥：特定于使用的根密钥（USRK）之一的泄露不应损害其他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的位置分发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.
密钥生存期取决于密钥的生成方式和使用方式。由于根密钥由使用定义负责，因此它必须确定密钥的有效期。如果通过身份验证的密钥交换可以获得密钥生存期或密钥强度信息，则应使用此信息确定密钥的生存期。如果可能，建议在整个系统中协调密钥的使用寿命。将密钥生存期设置为短于系统生存期可能会导致密钥无效，并且无法方便地刷新密钥。将密钥生存期设置为更长可能会导致安全性降低，因为密钥的使用时间可能超过其建议的生存期。
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:
可以根据规范要求的策略[RFC5226]分配标签。此外，“实验1”和“实验2”标签保留供实验使用。以下注意事项适用于其使用：
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:
控制域名的个人或组织可以请求以字符串开头，后跟“@”和有效、完全限定的Internet域名[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 根键的长度
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 如何从根键派生子键以及如何使用子键
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，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年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注意事项部分的指南”，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，“可扩展认证协议（EAP）密钥管理框架”，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]国家标准与技术研究所，“安全哈希标准”，FIPS 180-2，以及日期为2004年2月、2002年8月的变更通知1。
[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，“传输层安全（TLS）协议版本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>.
[SIGMA]Krawczyk，H.，“SIGMA：认证Diffie-Hellman的‘符号和MAc’方法及其在IKE协议中的使用”，LNCS 2729，Springer，2003<http://www.informatik.uni-trier.de/~ley/db/conf/crypto/crypto2003.html>。
Authors' Addresses
作者地址
Joseph Salowey Cisco Systems
约瑟夫·萨洛维思科系统公司
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com
Lakshminath Dondeti Qualcomm, Inc
Lakshminath Dondeti高通公司
EMail: ldondeti@qualcomm.com
EMail: ldondeti@qualcomm.com
Vidya Narayanan Qualcomm, Inc
维迪亚·纳拉亚南高通公司
EMail: vidyan@qualcomm.com
EMail: vidyan@qualcomm.com
Madjid Nakhjiri Motorola
麦吉德·纳基里摩托罗拉
EMail: madjid.nakhjiri@motorola.com
EMail: madjid.nakhjiri@motorola.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.