Internet Engineering Task Force (IETF) K. Hoeper, Ed.
Request for Comments: 5749 M. Nakhjiri
Category: Standards Track Motorola
ISSN: 2070-1721 Y. Ohba, Ed.
Toshiba
March 2010
Internet Engineering Task Force (IETF) K. Hoeper, Ed.
Request for Comments: 5749 M. Nakhjiri
Category: Standards Track Motorola
ISSN: 2070-1721 Y. Ohba, Ed.
Toshiba
March 2010
Distribution of EAP-Based Keys for Handover and Re-Authentication
分发基于EAP的密钥以进行切换和重新身份验证
Abstract
摘要
This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage-specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication, Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used.
本文档描述了一种抽象机制，用于将根密钥从可扩展身份验证协议（EAP）服务器传递到另一个网络服务器，该服务器需要密钥来向EAP对等方提供受安全保护的服务，如重新身份验证。分布式根密钥可以是特定于使用情况的根密钥（USRK）、特定于域的根密钥（DSRK）或特定于域的特定于使用情况的根密钥（DSUSRK），该根密钥是从先前在EAP服务器和EAP对等方之间建立的扩展主会话密钥（EMSK）层次结构派生的。本文档定义了密钥分发交换（KDE）协议的模板，该协议可以使用AAA（身份验证、授权和记帐）协议分发这些不同类型的根密钥，并讨论了其安全要求。所述协议模板未指定消息格式、数据编码或其他实现细节。因此，在使用之前，需要使用特定协议（例如，半径或直径）对其进行实例化。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5749.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5749.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Key Delivery Architecture . . . . . . . . . . . . . . . . . . 5
4. Key Distribution Exchange (KDE) . . . . . . . . . . . . . . . 6
4.1. Context and Scope for Distributed Keys . . . . . . . . . . 7
4.2. Key Distribution Exchange Scenarios . . . . . . . . . . . 8
5. KDE Used in the EAP Re-Authentication Protocol (ERP) . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Requirements on AAA Key Transport Protocols . . . . . . . 9
6.2. Distributing RK without Peer Consent . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Key Delivery Architecture . . . . . . . . . . . . . . . . . . 5
4. Key Distribution Exchange (KDE) . . . . . . . . . . . . . . . 6
4.1. Context and Scope for Distributed Keys . . . . . . . . . . 7
4.2. Key Distribution Exchange Scenarios . . . . . . . . . . . 8
5. KDE Used in the EAP Re-Authentication Protocol (ERP) . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Requirements on AAA Key Transport Protocols . . . . . . . 9
6.2. Distributing RK without Peer Consent . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
The Extensible Authentication Protocol (EAP) [RFC3748] is an authentication framework supporting authentication methods that are specified in EAP methods. By definition, any key-generating EAP method derives a Master Session Key (MSK) and an Extended Master Session Key (EMSK). [RFC5295] reserves the EMSK for the sole purpose of deriving root keys that can be used for specific purposes called usages. In particular, [RFC5295] defines how to create a usage-specific root key (USRK) for bootstrapping security in a specific application, a domain-specific root key (DSRK) for bootstrapping security of a set of services within a domain, and a usage-specific DSRK (DSUSRK) for a specific application within a domain. [RFC5296] defines a re-authentication root key (rRK) that is a USRK designated for re-authentication.
可扩展身份验证协议（EAP）[RFC3748]是一个支持EAP方法中指定的身份验证方法的身份验证框架。根据定义，任何密钥生成EAP方法都会派生主会话密钥（MSK）和扩展主会话密钥（EMSK）。[RFC5295]保留EMSK的唯一目的是导出可用于特定用途（称为usages）的根密钥。具体而言，[RFC5295]定义了如何为特定应用程序中的引导安全性创建特定于使用情况的根密钥（USRK）、为域内一组服务的引导安全性创建特定于域的根密钥（DSRK）以及为域内特定应用程序创建特定于使用情况的DSRK（DSUSRK）。[RFC5296]定义重新身份验证根密钥（rRK），该根密钥是指定用于重新身份验证的USRK。
The MSK and EMSK may be used to derive further keying material for a variety of security mechanisms [RFC5247]. For example, the MSK has been widely used for bootstrapping the wireless link security associations between the peer and the network attachment points. However, performance as well as security issues arise when using the MSK and the current bootstrapping methods in mobile scenarios that require handovers, as described in [RFC5169]. To address handover latencies and other shortcomings, [RFC5296] specifies an EAP re-authentication protocol (ERP) that uses keys derived from the EMSK or DSRK to enable efficient re-authentications in handover scenarios. Neither [RFC5295] nor [RFC5296] specifies how root keys are delivered to the network server requiring the key. Such a key delivery mechanism is essential because the EMSK cannot leave the EAP server ([RFC5295]), but root keys are needed by other network servers disjoint with the EAP server. For example, in order to enable an EAP peer to re-authenticate to a network during a handover, certain root keys need to be made available by the EAP server to the server carrying out the re-authentication.
MSK和EMSK可用于衍生用于各种安全机制的进一步键控材料[RFC5247]。例如，MSK已广泛用于引导对等点和网络连接点之间的无线链路安全关联。但是，在需要切换的移动场景中使用MSK和当前引导方法时，会出现性能和安全问题，如[RFC5169]中所述。为了解决切换延迟和其他缺点，[RFC5296]指定了一种EAP重新认证协议（ERP），该协议使用从EMSK或DSRK派生的密钥来实现切换场景中的高效重新认证。[RFC5295]和[RFC5296]均未指定如何将根密钥传递到需要该密钥的网络服务器。由于EMSK不能离开EAP服务器（[RFC5295]），但与EAP服务器分离的其他网络服务器需要根密钥，因此这种密钥传递机制至关重要。例如，为了使EAP对等方能够在切换期间对网络重新认证，EAP服务器需要向执行重新认证的服务器提供某些根密钥。
This document specifies an abstract mechanism for the delivery of the EMSK child keys from the server holding the EMSK or a root key to another network server that requests a root key for providing protected services (such as re-authentication and other usage and domain-specific services) to EAP peers. In the remainder of this document, a server delivering root keys is referred to as a Key Delivering Server (KDS), and a server authorized to request and receive root keys from a KDS is referred to as a Key Requesting Server (KRS). The Key Distribution Exchange (KDE) mechanism defined in this document runs over a AAA (Authentication, Authorization, and Accounting) protocol, e.g., RADIUS ([RFC2865], [RFC3579]) or Diameter [RFC3588], and has several variants depending on the type of key that is requested and delivered (i.e., DRSK, USRK, or DSUSRK). The
本文档指定了一种抽象机制，用于将EMSK子密钥从持有EMSK或根密钥的服务器传递到另一个网络服务器，该网络服务器请求根密钥，以便向EAP对等方提供受保护的服务（例如重新认证和其他用法以及特定于域的服务）。在本文档的其余部分中，传递根密钥的服务器称为密钥传递服务器（KDS），授权从KDS请求和接收根密钥的服务器称为密钥请求服务器（KRS）。本文档中定义的密钥分发交换（KDE）机制在AAA（身份验证、授权和记帐）协议上运行，例如RADIUS（[RFC2865]、[RFC3579]）或Diameter[RFC3588]，并根据请求和交付的密钥类型（即DRSK、USRK或DSUSRK）具有多个变体。这个
presented KDE mechanism is a protocol template that must be instantiated for a particular protocol, such as RADIUS or Diameter, to specify the format and encoding of the abstract protocol messages. Only after such an instantiation can the KDE mechanism described in this document be implemented. This document also describes security requirements for the secure key delivery over AAA.
提出的KDE机制是一个协议模板，必须为特定协议（如RADIUS或Diameter）实例化该模板，以指定抽象协议消息的格式和编码。只有在这样的实例化之后，才能实现本文中描述的KDE机制。本文档还描述了通过AAA安全密钥传递的安全要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following acronyms are used.
使用以下首字母缩略词。
AAA Authentication, Authorization and Accounting. AAA protocols with EAP support include RADIUS ([RFC2865], [RFC3579]) and Diameter [RFC3588].
AAA认证、授权和记帐。支持EAP的AAA协议包括RADIUS（[RFC2865]、[RFC3579]）和Diameter[RFC3588]。
USRK Usage-Specific Root Key. A root key that is derived from the EMSK; see [RFC5295].
USRK使用特定的根密钥。从EMSK派生的根密钥；参见[RFC5295]。
USR-KH USRK Holder. A network server that is authorized to request and receive a USRK from the EAP server. The USR-KH can be a AAA server or dedicated service server.
USR-KH USRK支架。授权从EAP服务器请求和接收USRK的网络服务器。USR-KH可以是AAA服务器或专用服务服务器。
DSRK Domain-Specific Root Key. A root key that is derived from the EMSK; see [RFC5295].
DSRK特定于域的根密钥。从EMSK派生的根密钥；参见[RFC5295]。
DSR-KH DSRK Holder. A network server that is authorized to request and receive a DSRK from the EAP server. The most likely implementation of a DSR-KH is a AAA server in a domain, enforcing the policies for the usage of the DSRK within this domain.
DSR-KH DSRK支架。授权从EAP服务器请求和接收DSRK的网络服务器。DSR-KH最有可能的实现是域中的AAA服务器，强制执行该域中DSRK的使用策略。
DSUSRK Domain-Specific Usage-Specific Root Key. A root key that is derived from the DSRK; see [RFC5295].
DSUSRK特定于域的使用特定于根密钥。从DSRK派生的根密钥；参见[RFC5295]。
DSUSR-KH DSUSRK holder. A network server authorized to request and receive a DSUSRK from the DSR-KH. The most likely implementation of a DSUSR-KH is a AAA server in a domain, responsible for a particular service offered within this domain.
DSUSR-KH DSUSRK支架。授权从DSR-KH请求和接收DSUSRK的网络服务器。DSUSR-KH最可能的实现是域中的AAA服务器，负责该域中提供的特定服务。
RK Root Key. An EMSK child key, i.e., a USRK, DSRK, or DSUSRK.
RK根键。EMSK子密钥，即USRK、DSRK或DSUSRK。
KDS Key Delivering Server. A network server that holds an EMSK or DSRK and delivers root keys to a KRS requesting root keys. The EAP server (together with the AAA server to which it exports the keys for delivery) and the DSR-KH can both act as KDS.
KDS密钥传递服务器。持有EMSK或DSRK并向请求根密钥的KRS发送根密钥的网络服务器。EAP服务器（连同AAA服务器，它将密钥导出到AAA服务器以进行传递）和DSR-KH都可以充当KDS。
KRS Key Requesting Server. A network server that shares an interface with a KDS and is authorized to request root keys from the KDS. A USR-KH, DSR-KH, and DSUSR-KH can all act as a KRS.
KRS密钥请求服务器。与KDS共享接口并被授权从KDS请求根密钥的网络服务器。USR-KH、DSR-KH和DSUSR-KH都可以充当KRS。
HOKEY Handover Keying.
HOKEY切换键控。
An EAP server carries out normal EAP authentications with EAP peers but is typically not involved in potential handovers and re-authentication attempts by the same EAP peer. Other servers are typically in place to offer these requested services. These servers can be AAA servers or other service network servers. Whenever EAP-based keying material is used to protect a requested service, the respective keying material has to be available to the server providing the requested service. For example, the first time a peer requests a service from a network server, this server acts as a KRS. The KRS requests the root keys needed to derive the keys for protecting the requested service from the respective KDS. In subsequent requests from the same peer and as long as the root key has not expired, the KRS can use the same root keys to derive fresh keying material to protect the requested service. These kinds of key requests and distributions are necessary because an EMSK cannot leave the EAP server ([RFC5295]). Hence, any root key that is directly derived from an EMSK can only be derived by the EAP server itself. The EAP server then exports these keys to a server that can distribute the keys to the KRS. In the remainder of this document, the KDS consisting of the EAP server that derives the root keys together with the AAA server that distributes these keys is denoted EAP/AAA server. Root keys derived from EMSK child keys, such as a DSUSRK, can be requested from the respective root key holder. Hence, a KDS can be either the EAP/AAA server or a DSRK holder (DSR-KH), whereas a KRS can be either a USRK holder (USR-KH), a DSR-KH, or a DSUSRK holder (DSUSR-KH).
EAP服务器与EAP对等方执行正常的EAP身份验证，但通常不涉及同一EAP对等方的潜在切换和重新身份验证尝试。其他服务器通常提供这些请求的服务。这些服务器可以是AAA服务器或其他服务网络服务器。无论何时使用基于EAP的密钥材料来保护请求的服务，提供请求的服务的服务器都必须可以使用相应的密钥材料。例如，对等方第一次从网络服务器请求服务时，该服务器充当KRS。KRS请求根密钥，该根密钥用于从相应的KDS派生用于保护请求的服务的密钥。在来自同一对等方的后续请求中，只要根密钥尚未过期，KRS就可以使用相同的根密钥派生新的密钥材料来保护请求的服务。由于EMSK不能离开EAP服务器（[RFC5295]），因此这些类型的密钥请求和分发是必要的。因此，直接从EMSK派生的任何根密钥只能由EAP服务器本身派生。EAP服务器然后将这些密钥导出到可以将密钥分发给KRS的服务器。在本文档的其余部分中，由派生根密钥的EAP服务器和分发这些密钥的AAA服务器组成的KDS称为EAP/AAA服务器。从EMSK子密钥派生的根密钥（如DSUSRK）可以从相应的根密钥持有者请求。因此，KDS可以是EAP/AAA服务器或DSRK持有者（DSR-KH），而KRS可以是USRK持有者（USR-KH）、DSR-KH或DSUSRK持有者（DSUSR-KH）。
The KRS needs to share an interface with the KDS to be able to send all necessary input data to derive the requested key and to receive the requested key. The provided data includes the Key Derivation Function (KDF) that should be used to derive the requested key. The KRS uses the received root key to derive further keying material in order to secure its offered services. Every KDS is responsible for storing and protecting the received root key as well as the derivation and distribution of any child key derived from the root key. An example of a key delivery architecture is illustrated in Figure 1 showing the different types of KRS and their interfaces to the KDS.
KRS需要与KDS共享一个接口，以便能够发送所有必要的输入数据以导出请求的密钥并接收请求的密钥。提供的数据包括应用于派生请求密钥的密钥派生函数（KDF）。KRS使用接收到的根密钥来派生进一步的密钥材料，以保护其提供的服务。每个KDS负责存储和保护接收到的根密钥以及从根密钥派生的任何子密钥的派生和分发。图1展示了密钥交付体系结构的一个示例，显示了不同类型的KR及其与KDS的接口。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP/AAA server |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | | \
/ | | \
/ | | \
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| USR-KH1 | | USR-KH2 | | DSR-KH1 | | DSR-KH2 |
| HOKEY server| | XYZ server| |Domain 1 | | Domain 2|
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
/ |
/ |
/ |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| DSUSR-KH | | DSUSR-KH2 |
| Domain 1 | | Domain 2 |
|Home domain | |Visited domain |
|HOKEY server | |HOKEY server |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP/AAA server |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | | \
/ | | \
/ | | \
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| USR-KH1 | | USR-KH2 | | DSR-KH1 | | DSR-KH2 |
| HOKEY server| | XYZ server| |Domain 1 | | Domain 2|
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
/ |
/ |
/ |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| DSUSR-KH | | DSUSR-KH2 |
| Domain 1 | | Domain 2 |
|Home domain | |Visited domain |
|HOKEY server | |HOKEY server |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 1: Example Key Delivery Architecture for the Different KRS and KDS
图1：不同KR和KD的密钥交付架构示例
In this section, a generic mechanism for a key distribution exchange (KDE) over AAA is described in which a root key (RK) is distributed from a KDS to a KRS. It is required that the communication path between the KDS and the KRS is protected by the use of an appropriate AAA transport security mechanism (see Section 6 for security requirements). Here, it is assumed that the KRS and the KDS are separate entities, logically if not physically, and the delivery of the requested RK is specified accordingly.
在本节中，描述了AAA上密钥分发交换（KDE）的通用机制，其中根密钥（RK）从KDS分发到KRS。需要使用适当的AAA传输安全机制保护KDS和KRS之间的通信路径（安全要求见第6节）。这里，假设KRS和KDS在逻辑上（如果不是在物理上）是独立的实体，并且相应地指定所请求的RK的交付。
The key distribution exchange consists of one round-trip, i.e., two messages between the KRS and the KDS, as illustrated in Figure 2.
密钥分发交换包括一个往返，即KRS和KDS之间的两条消息，如图2所示。
First, the KRS sends a KDE-Request carrying a Key Request Token (KRT). As a response, the KDS sends a KDE-Response carrying a Key Delivery Token (KDT). Both tokens are encapsulated in AAA messages. The definition of the AAA attributes depends on the implemented AAA protocol and is out of scope of this document. However, the security requirements for AAA messages carrying KDE messages are discussed in Section 6. The contents of KRT and KDT are defined in the following.
首先，KRS发送带有密钥请求令牌（KRT）的KDE请求。作为响应，KDS发送携带密钥传递令牌（KDT）的KDE响应。这两个令牌都封装在AAA消息中。AAA属性的定义取决于实现的AAA协议，不在本文档的范围内。但是，第6节讨论了承载KDE消息的AAA消息的安全要求。KRT和KDT的内容定义如下。
KRS KDS
-------- -------
| |
| KDE-Request: AAA{KRT} |
|----------------------------------------->|
| KDE-Response: AAA{KDT} |
|<-----------------------------------------|
KRS KDS
-------- -------
| |
| KDE-Request: AAA{KRT} |
|----------------------------------------->|
| KDE-Response: AAA{KDT} |
|<-----------------------------------------|
Figure 2: KDE Message Flow
图2:KDE消息流
KRT : (PID, KT, KL)
KRT：（PID，KT，KL）
KRT carries the identifiers of the peer (PID), the key type (KT) and the key label (KL). The key type specifies which type of root key is requested, e.g., DSRK, USRK and DSUSRK. The encoding rules for each key type are left to the protocol developers who define the instantiation of the KDE mechanism for a particular protocol. For the specification of key labels and the associated IANA registries, please refer to [RFC5295], which specifies key labels for USRKs and establishes an IANA registry for them. The same specifications can be applied to other root keys.
KRT携带对等（PID）、密钥类型（KT）和密钥标签（KL）的标识符。密钥类型指定请求哪种类型的根密钥，例如DSRK、USRK和DSUSRK。每个密钥类型的编码规则留给协议开发人员，他们为特定协议定义KDE机制的实例化。有关密钥标签和相关IANA注册表的规范，请参考[RFC5295]，其中规定了USRK的密钥标签并为其建立IANA注册表。同样的规范也可以应用于其他根键。
KDT : (KT, KL, RK, KN_RK, LT_RK)
KDT：（KT、KL、RK、KN_-RK、LT_-RK）
KDT carries the root key (RK) to be distributed to the KRS, as well as the key type (KT) of the key, the key label (KL), the key name (KN_RK), and the lifetime of RK (LT_RK). The key lifetime of each distributed key MUST NOT be greater than that of its parent key.
KDT携带要分发给KRS的根密钥（RK），以及密钥的密钥类型（KT）、密钥标签（KL）、密钥名称（KN_RK）和RK的生存期（LT_RK）。每个分布式密钥的密钥生存期不得大于其父密钥的生存期。
The key context of each distributed key is determined by the sequence of KTs in the key hierarchy. The key scope of each distributed key is determined by the sequence of (PID, KT, KL)-tuples in the key hierarchy and the identifier of the KRS. The KDF used to generate the requested keys includes context and scope information, thus, binding the key to the specific channel [RFC5295].
每个分布式密钥的密钥上下文由密钥层次结构中的KT序列确定。每个分布式密钥的密钥范围由密钥层次结构中的（PID，KT，KL）-元组序列和KRS的标识符确定。用于生成请求密钥的KDF包括上下文和范围信息，因此，将密钥绑定到特定通道[RFC5295]。
Given the three types of KRS, there are three scenarios for the distribution of the EMSK child keys. For all scenarios, the trigger and mechanism for key delivery may involve a specific request from an EAP peer and/or another intermediary (such as an authenticator). For simplicity, it is assumed that USR-KHs reside in the same domain as the EAP server.
考虑到这三种类型的KR，EMSK子密钥的分发有三种方案。对于所有场景，密钥传递的触发器和机制可能涉及来自EAP对等方和/或另一中介（例如验证器）的特定请求。为简单起见，假设USR KHs与EAP服务器位于同一域中。
Scenario 1: EAP/AAA server to USR-KH: In this scenario, the EAP/AAA server delivers a USRK to a USR-KH.
场景1:EAP/AAA服务器到USR-KH：在此场景中，EAP/AAA服务器向USR-KH发送USRK。
Scenario 2: EAP/AAA server to DSR-KH: In this scenario, the EAP/AAA server delivers a DSRK to a DSR-KH.
场景2:EAP/AAA服务器到DSR-KH：在此场景中，EAP/AAA服务器向DSR-KH发送DSRK。
Scenario 3: DSR-KH to DSUSR-KH: In this scenario, a DSR-KH in a specific domain delivers keying material to a DSUSR-KH in the same domain.
场景3:DSR-KH到DSUSR-KH：在此场景中，特定域中的DSR-KH将密钥材料传递给同一域中的DSUSR-KH。
The key distribution exchanges for Scenario 3 can be combined with the key distribution exchanges for Scenario 2 into a single round-trip exchange as shown in Figure 3. Here, KDE-Request and KDE-Response are messages for Scenarios 2, whereas KDE-Request' and KDE-Response' are messages for Scenarios 3.
场景3的密钥分发交换可以与场景2的密钥分发交换组合成一个单一的往返交换，如图3所示。这里，KDE请求和KDE响应是场景2的消息，而KDE请求和KDE响应是场景3的消息。
DSUSR-KH DSR-KH EAP/AAA Server
-------- ------ ------------
| KDE-Request'(KRT') | KDE-Request(KRT) |
|------------------------>|-------------------------->|
| KDE-Response'(KDT') | KDE-Response(KDT) |
|<----------------------- |<--------------------------|
| | |
DSUSR-KH DSR-KH EAP/AAA Server
-------- ------ ------------
| KDE-Request'(KRT') | KDE-Request(KRT) |
|------------------------>|-------------------------->|
| KDE-Response'(KDT') | KDE-Response(KDT) |
|<----------------------- |<--------------------------|
| | |
Figure 3: Combined Message Exchange
图3：组合消息交换
This section describes how the presented KDE mechanism should be used to request and deliver the root keys used for re-authentication in the EAP Re-authentication Protocol (ERP) defined in [RFC5296]. ERP supports two forms of bootstrapping, implicit as well as explicit bootstrapping, and KDE is discussed for both cases in the remainder of this section.
本节描述了如何使用所提供的KDE机制来请求和交付[RFC5296]中定义的EAP重新认证协议（ERP）中用于重新认证的根密钥。ERP支持两种形式的引导，隐式引导和显式引导，KDE将在本节的其余部分讨论这两种情况。
In implicit bootstrapping, the local EAP Re-authentication (ER) server requests the DSRK from the home AAA server during the initial EAP exchange. Here, the local ER server acts as the KRS and the home
在隐式引导中，本地EAP重新身份验证（ER）服务器在初始EAP交换期间从家庭AAA服务器请求DSRK。在这里，本地ER服务器充当KRS和主服务器
AAA server as the KDS. In this case, the local ER server requesting the DSRK includes a KDE-Request in the AAA packet encapsulating the first EAP-Response message from the peer. Here, a AAA User-Name attribute is used as the PID. If the EAP exchange is successful, the home AAA server includes a KDE-Response in the AAA message that carries the EAP-Success message.
AAA服务器作为KDS。在这种情况下，请求DSRK的本地ER服务器在封装来自对等方的第一EAP响应消息的AAA分组中包括KDE请求。这里，AAA用户名属性用作PID。如果EAP交换成功，则家庭AAA服务器在承载EAP成功消息的AAA消息中包含KDE响应。
Explicit bootstrapping is initiated by peers that do not know the domain. Here, the peer sends an EAP-Initiate message with the bootstrapping flag turned on. The local ER server (acting as KRS) includes a KDE-Request message in the AAA message that carries the peer's EAP-Initiate message and sends it to the peer's home AAA server. Here, a AAA User-Name attribute is used as the PID. In its response, the home AAA server (acting as KDS) includes a KDE-Response in the AAA message that carries the EAP-Finish message with the bootstrapping flag set.
显式引导由不知道域的对等方启动。在这里，对等方发送一个EAP启动消息，启动标志打开。本地ER服务器（充当KRS）在AAA消息中包含KDE请求消息，该消息携带对等方的EAP Initiate消息并将其发送到对等方的家庭AAA服务器。这里，AAA用户名属性用作PID。在其响应中，家庭AAA服务器（充当KDS）在AAA消息中包含KDE响应，该消息携带设置了引导标志的EAP Finish消息。
This section provides security requirements and a discussion of distributing RK without peer consent.
本节提供了安全要求，并讨论了在未经同行同意的情况下分发RK的问题。
Any KDE attribute that is exchanged as part of a KDE-Request or KDE-Response MUST be integrity-protected and replay-protected by the underlying AAA protocol that is used to encapsulate the attributes. Additionally, a secure key wrap algorithm MUST be used by the AAA protocol to protect the RK in a KDE-Response. Other confidential information as part of the KDE messages (e.g., identifiers if privacy is a requirement) SHOULD be encrypted by the underlying AAA protocol.
作为KDE请求或KDE响应的一部分进行交换的任何KDE属性都必须由用于封装属性的底层AAA协议进行完整性保护和重播保护。此外，AAA协议必须使用安全密钥包装算法来保护KDE响应中的RK。作为KDE消息一部分的其他机密信息（例如，如果要求隐私，则为标识符）应通过基础AAA协议进行加密。
When there is an intermediary, such as a AAA proxy, on the path between the KRS and the KDS, there will be a series of hop-by-hop security associations along the path. The use of hop-by-hop security associations implies that the intermediary on each hop can access the distributed keying material. Hence, the use of hop-by-hop security SHOULD be limited to an environment where an intermediary is trusted not to abuse the distributed key material. If such a trusted AAA infrastructure does not exist, other means must be applied at a different layer to ensure the end-to-end security (i.e., between KRS and KDS) of the exchanged KDE messages. The security requirements for such a protocol are the same as previously outlined for AAA protocols and MUST hold when encapsulated in AAA messages.
当KRS和KDS之间的路径上存在中间层（如AAA代理）时，将沿路径存在一系列逐跳安全关联。使用逐跳安全关联意味着每个跳上的中介可以访问分布式密钥材料。因此，逐跳安全性的使用应该限制在一个环境中，在这个环境中，信任中介不会滥用分布式密钥材料。如果这种受信任的AAA基础设施不存在，则必须在不同的层应用其他方法，以确保交换的KDE消息的端到端安全性（即KR和KDS之间）。此类协议的安全要求与前面针对AAA协议概述的相同，并且在封装在AAA消息中时必须保持不变。
When a KDE-Request is sent as a result of explicit ERP bootstrapping [RFC5296], cryptographic verification of peer consent on distributing an RK is provided by the integrity checksum of the EAP-Initiate message with the bootstrapping flag turned on.
当作为显式ERP引导[RFC5296]的结果发送KDE请求时，通过启用引导标志的EAP Initiate消息的完整性校验和提供分发RK时对等同意的加密验证。
On the other hand, when a KDE-Request is sent as a result of implicit ERP bootstrapping [RFC5296], cryptographic verification of peer consent on distributing an RK is not provided. A peer is not involved in the process and, thus, not aware of key delivery requests for root keys derived from its established EAP keying material. Hence, a peer has no control where keys derived from its established EAP keying material are distributed. A possible consequence of this is that a KRS may request and obtain an RK from the home server even if the peer does not support ERP. EAP-Initiate/Re-auth-Start messages send to the peer will be silently dropped by the peer causing further waste of resources.
另一方面，当作为隐式ERP引导[RFC5296]的结果发送KDE请求时，不提供分发RK时对等同意的加密验证。对等方不参与该过程，因此不知道从其已建立的EAP密钥材料派生的根密钥的密钥传递请求。因此，对等方无法控制从其已建立的EAP密钥材料派生的密钥的分发位置。这样做的一个可能结果是，即使对等方不支持ERP，KRS也可能从家庭服务器请求并获得RK。发送给对等方的EAP Initiate/Re-auth Start消息将被对等方静默丢弃，从而进一步浪费资源。
The editors would like to thank Dan Harkins, Chunqiang Li, Rafael Marin Lopez, and Charles Clancy for their valuable comments.
编辑们要感谢丹·哈金斯、李春强、拉斐尔·马林·洛佩兹和查尔斯·克兰西的宝贵评论。
The following people contributed to this document: Kedar Gaonkar, Lakshminath Dondeti, Vidya Narayanan, and Glen Zorn.
以下人员对本文件做出了贡献：Kedar Gaonkar、Lakshminath Dondeti、Vidya Narayanan和Glen Zorn。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008.
[RFC5295]Salowey，J.，Dondeti，L.，Narayanan，V.，和M.Nakhjiri，“从扩展主会话密钥（EMSK）派生根密钥的规范”，RFC 52952008年8月。
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5296]Narayanan，V.和L.Dondeti，“EAP再认证协议（ERP）的EAP扩展”，RFC 52962008年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, "Handover Key Management and Re-Authentication Problem Statement", RFC 5169, March 2008.
[RFC5169]Clancy，T.，Nakhjiri，M.，Narayanan，V.，和L.Dondeti，“移交密钥管理和重新认证问题声明”，RFC 5169，2008年3月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，RFC 5247，2008年8月。
Authors' Addresses
作者地址
Katrin Hoeper (editor) Motorola, Inc. 1295 E Algonquin Road Schaumburg, IL 60196 USA
卡特琳·霍珀（编辑）摩托罗拉公司，地址：美国伊利诺伊州绍姆堡阿尔冈昆路东1295号，邮编：60196
Phone: +1 847 576 4714
EMail: khoeper@motorola.com
Phone: +1 847 576 4714
EMail: khoeper@motorola.com
Madjid F. Nakhjiri Motorola, Inc. 6450 Sequence Drive San Diego, CA 92121 USA
Madjid F.Nakhjiri Motorola，Inc.美国加利福尼亚州圣地亚哥6450 Sequence Drive 92121
EMail: madjid.nakhjiri@motorola.com
EMail: madjid.nakhjiri@motorola.com
Yoshihiro Ohba (editor) Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
大叶吉弘（编辑）东芝公司研发中心1 Komukai Toshiba cho Saiwai ku，川崎，神奈川212-8582日本
Phone: +81 44 549 2230
EMail: yoshihiro.ohba@toshiba.co.jp
Phone: +81 44 549 2230
EMail: yoshihiro.ohba@toshiba.co.jp