Network Working Group T. Clancy
Request for Comments: 5169 LTS
Category: Informational M. Nakhjiri
Motorola
V. Narayanan
L. Dondeti
Qualcomm
March 2008
Network Working Group T. Clancy
Request for Comments: 5169 LTS
Category: Informational M. Nakhjiri
Motorola
V. Narayanan
L. Dondeti
Qualcomm
March 2008
Handover Key Management and Re-Authentication Problem Statement
切换密钥管理和重新认证问题声明
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover.
本文档描述了切换密钥（HOKEY）重新身份验证问题陈述。当前的可扩展认证协议（EAP）密钥框架的设计不支持在不重新执行EAP方法的情况下重新认证和切换。在各种移动无线环境中，这通常会导致不可接受的延迟。本文档详细说明了问题，并定义了通用机制的设计目标，以重用导出的EAP密钥材料进行移交。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7
5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8
5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9
6.1. Method-Specific EAP Re-Authentication . . . . . . . . . . 9
6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 10
6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Key Context and Domino Effect . . . . . . . . . . . . . . 7
5.2. Key Freshness . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Authentication . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 8
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 8
5.6. Transport Aspects . . . . . . . . . . . . . . . . . . . . 8
6. Use Cases and Related Work . . . . . . . . . . . . . . . . . . 9
6.1. Method-Specific EAP Re-Authentication . . . . . . . . . . 9
6.2. IEEE 802.11r Applicability . . . . . . . . . . . . . . . . 10
6.3. CAPWAP Applicability . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
The Extensible Authentication Protocol (EAP), specified in RFC 3748 [RFC3748] is a generic framework supporting multiple authentication methods. The primary purpose of EAP is network access control. It also supports exporting session keys derived during the authentication. The EAP keying hierarchy defines two keys that are derived at the top level, the Master Session Key (MSK) and the Extended Master Session Key (EMSK).
RFC 3748[RFC3748]中指定的可扩展身份验证协议（EAP）是支持多种身份验证方法的通用框架。EAP的主要目的是网络访问控制。它还支持导出身份验证期间派生的会话密钥。EAP键控层次结构定义了在顶层派生的两个键，即主会话键（MSK）和扩展主会话键（EMSK）。
In many common deployment scenarios, an EAP peer and EAP server authenticate each other through a third party known as the pass-through authenticator (hereafter referred to as simply "authenticator"). The authenticator is responsible for encapsulating EAP packets from a network-access technology lower layer within the Authentication, Authorization, and Accounting (AAA) protocol. The authenticator does not directly participate in the EAP exchange, and simply acts as a gateway during the EAP method execution.
在许多常见部署场景中，EAP对等方和EAP服务器通过称为直通验证器（以下简称为“验证器”）的第三方相互认证。认证器负责在认证、授权和计费（AAA）协议中封装来自网络接入技术较低层的EAP数据包。验证器不直接参与EAP交换，只是在EAP方法执行期间充当网关。
After successful authentication, the EAP server transports the MSK to the authenticator. Note that this is performed using AAA protocols, not EAP itself. The underlying L2 or L3 protocol uses the MSK to derive additional keys, including the transient session keys (TSKs) used for per-packet encryption and authentication.
认证成功后，EAP服务器将MSK传输到认证器。请注意，这是使用AAA协议执行的，而不是EAP本身。底层L2或L3协议使用MSK派生附加密钥，包括用于每个数据包加密和身份验证的临时会话密钥（TSK）。
Note that while the authenticator is one logical device, there can be multiple physical devices involved. For example, the CAPWAP model [RFC3990] splits authenticators into two logical devices: Wireless Termination Points (WTPs) and Access Controllers (ACs). Depending on the configuration, authenticator features can be split in a variety of ways between physical devices; however, from the EAP perspective, there is only one logical authenticator.
请注意，虽然验证器是一个逻辑设备，但可能涉及多个物理设备。例如，CAPWAP模型[RFC3990]将身份验证程序拆分为两个逻辑设备：无线终端点（WTP）和访问控制器（ACs）。根据配置，验证器功能可以在物理设备之间以多种方式分割；但是，从EAP的角度来看，只有一个逻辑验证器。
Wireless handover between access points or base stations is typically a complex process that involves several layers of protocol execution. Often times executing these protocols results in unacceptable delays for many real-time applications such as voice [MSA03]. One part of the handover process is EAP re-authentication, which can contribute significantly to the overall handover time [MSPCA04]. Thus, in many environments we can lower overall handover time by lowering EAP re-authentication time.
接入点或基站之间的无线切换通常是一个涉及多个协议执行层的复杂过程。通常情况下，执行这些协议会导致许多实时应用程序（如语音[MSA03]）出现不可接受的延迟。切换过程的一部分是EAP重新认证，这对总切换时间有很大影响[MSPCA04]。因此，在许多环境中，我们可以通过降低EAP重新认证时间来降低总体切换时间。
In EAP existing implementations, when a peer arrives at the new authenticator, it runs an EAP method irrespective of whether it has been authenticated to the network recently and has unexpired keying material. This typically involves an EAP-Response/Identity message from the peer to the server, followed by one or more round trips between the EAP server and peer to perform the authentication,
在EAP现有实现中，当对等方到达新的认证器时，它运行EAP方法，而不管它最近是否已通过网络认证，并且是否有未过期的密钥材料。这通常涉及从对等方到服务器的EAP响应/标识消息，然后在EAP服务器和对等方之间进行一次或多次往返以执行身份验证，
followed by the EAP-Success or EAP-Failure message from the EAP server to the peer. At a minimum, the EAP exchange consists of 1.5 round trips. However, given the way EAP interacts with AAA, and given that an EAP identity exchange is typically employed, at least 2 round trips are required to the EAP server. An even higher number of round trips is required by the most commonly used EAP methods. For instance, EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) requires at least 3, but typically 4 or more, round trips.
然后是EAP服务器向对等方发送的EAP成功或EAP失败消息。EAP交换至少包括1.5次往返。然而，考虑到EAP与AAA的交互方式，以及EAP身份交换通常采用的方式，EAP服务器至少需要两次往返。最常用的EAP方法需要更多的往返次数。例如，EAP-TLS（可扩展身份验证协议-传输层安全）至少需要3次，但通常需要4次或更多的往返。
There have been attempts to solve the problem of efficient re-authentication in various ways. However, those solutions are either EAP-method specific or EAP lower-layer specific. Furthermore, these solutions do not deal with scenarios involving handovers to new authenticators, or they do not conform to the AAA keying requirements specified in [RFC4962].
已经有人试图以各种方式解决有效的重新认证问题。然而，这些解决方案要么是EAP方法特定的，要么是EAP低层特定的。此外，这些解决方案不处理涉及切换到新验证器的场景，或者不符合[RFC4962]中规定的AAA密钥要求。
This document provides a detailed description of efficient EAP-based re-authentication protocol design goals. The scope of this protocol is specifically re-authentication and handover between authenticators within a single administrative domain. While the design goals presented in this document may facilitate inter-technology handover and inter-administrative-domain handover, they are outside the scope of this protocol.
本文档详细描述了有效的基于EAP的重新认证协议设计目标。该协议的范围特别是在单个管理域内的认证者之间的重新认证和切换。虽然本文件中提出的设计目标可能有助于技术间切换和管理域间切换，但它们不在本协议的范围内。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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], with the qualification that, unless otherwise stated, they apply to the design of the re-authentication protocol, not its implementation or application.
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的描述进行解释，除非另有说明，否则其适用于重新认证协议的设计，而不是其实施或应用。
With respect to EAP, this document follows the terminology that has been defined in [RFC3748] and [EAP-KEYING].
关于EAP，本文件遵循[RFC3748]和[EAP-KEYING]中定义的术语。
Under the existing model, any re-authentication requires a full EAP exchange with the EAP server to which the peer initially authenticated [RFC3748]. This introduces handover latency from both network transit time and processing delay. In service provider networks, the home EAP server for a peer could be on the other side of the world, and typical intercontinental latencies across the Internet are 100 to 300 milliseconds per round trip [LGS07].
在现有模型下，任何重新认证都需要与对等方最初认证的EAP服务器进行完整的EAP交换[RFC3748]。这从网络传输时间和处理延迟两方面引入了切换延迟。在服务提供商网络中，对等方的家庭EAP服务器可能位于世界的另一端，互联网上典型的洲际延迟为每次往返100到300毫秒[LGS07]。
Processing delays average a couple of milliseconds for symmetric-key operations and hundreds of milliseconds for public-key operations.
对称密钥操作的处理延迟平均为几毫秒，公钥操作的处理延迟平均为数百毫秒。
An EAP conversation with a full EAP method run can take two or more round trips to complete, causing delays in re-authentication and handover times. Some methods specify the use of keys and state from the initial authentication to finish subsequent authentications in fewer round trips and without using public-key operations (detailed in Section 6.1). However, even in those cases, multiple round trips to the EAP server are required, resulting in unacceptable handover times.
运行完整EAP方法的EAP会话可能需要两个或更多往返才能完成，从而导致重新身份验证和切换时间延迟。有些方法规定使用初始身份验证中的密钥和状态，以较少的往返次数完成后续身份验证，并且不使用公钥操作（详见第6.1节）。但是，即使在这些情况下，也需要多次往返EAP服务器，从而导致无法接受的切换时间。
In summary, it is undesirable to run an EAP Identity and complete EAP method exchange each time a peer authenticates to a new authenticator or needs to extend its current authentication with the same authenticator. Furthermore, it is desirable to specify a method-independent, efficient, re-authentication protocol. Keying material from the initial authentication can be used to enable efficient re-authentication. It is also desirable to have a local server with low-latency connectivity to the peer that can facilitate re-authentication. Lastly, a re-authentication protocol should also be capable of supporting scenarios where an EAP server passes authentication information to a remote re-authentication server, allowing a peer to re-authenticate locally, without having to communicate with its home re-authentication server.
总之，每次对等方向新的验证器进行身份验证或需要使用同一验证器扩展其当前身份验证时，都不希望运行EAP标识并完成EAP方法交换。此外，希望指定与方法无关的、高效的重新认证协议。初始身份验证中的密钥材料可用于实现有效的重新身份验证。还希望有一个本地服务器，该服务器具有与对等方的低延迟连接，从而有助于重新认证。最后，重新认证协议还应能够支持EAP服务器将认证信息传递给远程重新认证服务器的场景，从而允许对等方在本地重新认证，而无需与其主重新认证服务器通信。
These problems are the primary issues to be resolved. In solving them, there are a number of constraints to conform to, and those result in some additional work to be done in the area of EAP keying.
这些问题是需要解决的首要问题。在解决这些问题时，有许多约束需要遵守，这些约束导致在EAP键控领域需要做一些额外的工作。
The following are the goals and constraints in designing the EAP re-authentication and key management protocol:
以下是设计EAP重新认证和密钥管理协议的目标和约束：
Lower-latency operation: The protocol MUST be responsive to handover and re-authentication latency performance objectives within a mobile access network. A solution that reduces latency as compared to a full EAP authentication will be most favorable, since in networks that rely on reactive re-authentication this will directly impact handover times.
低延迟操作：协议必须响应移动接入网络内的切换和重新认证延迟性能目标。与完全EAP身份验证相比，减少延迟的解决方案将是最有利的，因为在依赖反应式重新身份验证的网络中，这将直接影响切换时间。
EAP lower-layer independence: Any keying hierarchy and protocol defined MUST be lower-layer independent in order to provide capabilities over heterogeneous technologies. The defined protocols MAY require some additional support from the lower layers that use it, but should not require any particular lower layer.
EAP低层独立性：定义的任何键控层次结构和协议都必须是低层独立的，以便在异构技术上提供能力。定义的协议可能需要使用它的较低层的一些额外支持，但不应该需要任何特定的较低层。
EAP method independence: Changes to existing EAP methods MUST NOT be required as a result of the re-authentication protocol. There MUST be no requirements imposed on future EAP methods, provided they satisfy [EAP-KEYING] and [RFC4017]. Note that the only EAP methods for which independence is required are those that currently conform to the specifications of [EAP-KEYING] and [RFC4017]. In particular, methods that do not generate the keys required by [EAP-KEYING] need not be supported by the re-authentication protocol.
EAP方法独立性：重新认证协议不得要求对现有EAP方法进行更改。如果未来EAP方法满足[EAP-KEYING]和[RFC4017]，则不得对其施加任何要求。请注意，唯一需要独立性的EAP方法是目前符合[EAP-KEYING]和[RFC4017]规范的方法。特别是，重新认证协议不需要支持不生成[EAP-KEYING]所需密钥的方法。
AAA protocol compatibility and keying: Any modifications to EAP and EAP keying MUST be compatible with RADIUS [RADEXT-DESIGN] and Diameter [DIME-APP-DESIGN]. Extensions to both RADIUS and Diameter to support these EAP modifications are acceptable. The designs and protocols must be configurable to satisfy the AAA key management requirements specified in RFC 4962 [RFC4962].
AAA协议兼容性和键控：对EAP和EAP键控的任何修改必须与RADIUS[RADEXT-DESIGN]和DIAME[DIME-APP-DESIGN]兼容。支持这些EAP修改的半径和直径扩展是可以接受的。设计和协议必须可配置，以满足RFC 4962[RFC4962]中规定的AAA密钥管理要求。
Compatibility: Compatibility and coexistence with compliant ([RFC3748] [EAP-KEYING]) EAP deployments MUST be provided. Specifically, the protocol should be designed such that a peer not supporting fast re-reauthentication should still function in a network supporting fast re-authentication, and also a peer supporting fast re-authentication should still function in a network not supporting fast re-authentication.
兼容性：必须提供与兼容（[RFC3748][EAP-KEYING]）EAP部署的兼容性和共存性。具体而言，协议的设计应确保不支持快速重新认证的对等方仍能在支持快速重新认证的网络中运行，并且支持快速重新认证的对等方也能在不支持快速重新认证的网络中运行。
Cryptographic Agility: Any re-authentication protocol MUST support cryptographic algorithm agility, to avoid hard-coded primitives whose security may eventually prove to be compromised. The protocol MAY support cryptographic algorithm negotiation, provided it does not adversely affect overall performance (i.e., by requiring additional round trips).
加密敏捷性：任何重新认证协议都必须支持加密算法敏捷性，以避免硬编码原语的安全性最终可能会受到损害。协议可以支持加密算法协商，前提是它不会对总体性能产生不利影响（即，通过要求额外的往返）。
Impact to Existing Deployments: Any re-authentication protocol MAY make changes to the peer, authenticator, and EAP server, as necessary to meet the aforementioned design goals. In order to facilitate protocol deployment, protocols should seek to minimize the necessary changes, without sacrificing performance.
对现有部署的影响：任何重新身份验证协议都可能对对等、身份验证程序和EAP服务器进行更改，以满足上述设计目标。为了便于协议部署，协议应尽量减少必要的更改，而不牺牲性能。
This section draws from the guidance provided in [RFC4962] to further define the security goals to be achieved by a complete re-authentication keying solution.
本节借鉴[RFC4962]中提供的指南，进一步定义通过完整的重新认证密钥解决方案实现的安全目标。
Any key must have a well-defined scope and must be used in a specific context and for the intended use. This specifically means the lifetime and scope of each key must be defined clearly so that all entities that are authorized to have access to the key have the same context during the validity period. In a hierarchical key structure, the lifetime of lower-level keys must not exceed the lifetime of higher-level keys. This requirement may imply that the context and the scope parameters have to be exchanged. Furthermore, the semantics of these parameters must be defined to provide proper channel binding specifications. The definition of exact parameter syntax definition is part of the design of the transport protocol used for the parameter exchange, and that may be outside scope of this protocol.
任何密钥都必须有一个明确定义的范围，并且必须在特定的上下文中使用并用于预期用途。这特别意味着必须明确定义每个密钥的生命周期和范围，以便授权访问该密钥的所有实体在有效期内具有相同的上下文。在分层密钥结构中，较低级别密钥的生存期不得超过较高级别密钥的生存期。这一要求可能意味着必须交换上下文和范围参数。此外，必须定义这些参数的语义，以提供适当的通道绑定规范。精确参数语法定义的定义是用于参数交换的传输协议设计的一部分，可能超出本协议的范围。
If a key hierarchy is deployed, compromising lower-level keys must not result in a compromise of higher-level keys that were used to derive the lower-level keys. The compromise of keys at each level must not result in compromise of other keys at the same level. The same principle applies to entities that hold and manage a particular key defined in the key hierarchy. Compromising keys on one authenticator must not reveal the keys of another authenticator. Note that the compromise of higher-level keys has security implications on lower levels.
如果部署了密钥层次结构，则泄露较低级别密钥不得导致泄露用于派生较低级别密钥的较高级别密钥。每个级别的密钥泄露不得导致同一级别的其他密钥泄露。同样的原则也适用于持有和管理密钥层次结构中定义的特定密钥的实体。一个验证器上的泄露密钥不得泄露另一个验证器的密钥。请注意，较高级别密钥的泄露对较低级别具有安全影响。
Guidance on parameters required, caching, and storage and deletion procedures to ensure adequate security and authorization provisioning for keying procedures must be defined in a solution document.
必须在解决方案文档中定义有关所需参数、缓存以及存储和删除过程的指导，以确保密钥设置过程具有足够的安全性和授权。
All the keying material must be uniquely named so that it can be managed effectively.
所有键控材质必须具有唯一的名称，以便对其进行有效管理。
As [RFC4962] defines, a fresh key is one that is generated for the intended use. This would mean the key hierarchy must provide for creation of multiple cryptographically separate child keys from a root key at higher level. Furthermore, the keying solution needs to provide mechanisms for refreshing each of the keys within the key hierarchy.
正如[RFC4962]所定义的，新密钥是为预期用途生成的密钥。这意味着密钥层次结构必须提供从更高级别的根密钥创建多个加密分离的子密钥。此外，键控解决方案需要提供刷新密钥层次结构中每个密钥的机制。
Each handover keying participant must be authenticated to any other party with whom it communicates to the extent it is necessary to ensure proper key scoping, and securely provide its identity to any other entity that may require the identity for defining the key scope.
每个交接密钥参与者必须向其通信的任何其他方进行身份验证，以确保正确的密钥范围，并安全地向可能需要该身份来定义密钥范围的任何其他实体提供其身份。
The EAP Key management document [EAP-KEYING] discusses several vulnerabilities that are common to handover mechanisms. One important issue arises from the way the authorization decisions might be handled at the AAA server during network access authentication. Furthermore, the reasons for making a particular authorization decision are not communicated to the authenticator. In fact, the authenticator only knows the final authorization result. The proposed solution must make efforts to document and mitigate authorization attacks.
EAP密钥管理文档[EAP-KEYING]讨论了切换机制常见的几个漏洞。一个重要的问题是在网络访问身份验证期间AAA服务器可能处理授权决策的方式。此外，做出特定授权决策的原因没有传达给认证者。事实上，验证器只知道最终的授权结果。建议的解决方案必须努力记录和减轻授权攻击。
Channel Binding procedures are needed to avoid a compromised intermediate authenticator providing unverified and conflicting service information to each of the peer and the EAP server. To support fast re-authentication, there will be intermediate entities between the peer and the back-end EAP server. Various keys need to be established and scoped between these parties and some of these keys may be parents to other keys. Hence, the channel binding for this architecture will need to consider layering intermediate entities at each level to make sure that an entity with a higher level of trust can examine the truthfulness of the claims made by intermediate parties.
需要通道绑定过程，以避免中间认证器向对等方和EAP服务器中的每一个提供未经验证和冲突的服务信息。为了支持快速重新身份验证，对等端和后端EAP服务器之间将有中间实体。需要在这些方之间建立各种密钥并确定其范围，其中一些密钥可能是其他密钥的父密钥。因此，该架构的信道绑定将需要考虑每个级别上的分层中间实体，以确保具有较高信任级别的实体可以检查中间方所提出的索赔的真实性。
Depending on the physical architecture and the functionality of the elements involved, there may be a need for multiple protocols to perform the key transport between entities involved in the handover keying architecture. Thus, a set of requirements for each of these protocols, and the parameters they will carry, must be developed.
取决于所涉及的物理架构和元件的功能性，可能需要多个协议来执行切换键控架构中涉及的实体之间的密钥传输。因此，必须为这些协议中的每一个制定一套要求，以及它们将携带的参数。
The use of existing AAA protocols for carrying EAP messages and keying material between the AAA server and AAA clients that have a role within the architecture considered for the keying problem will be carefully examined. Definition of specific parameters, required for keying procedures and for being transferred over any of the links
将仔细检查现有AAA协议在AAA服务器和AAA客户端之间传输EAP消息和密钥材料的使用情况，AAA服务器和AAA客户端在考虑密钥问题的体系结构中发挥作用。定义键控程序和通过任何链路传输所需的特定参数
in the architecture, are part of the scope. The relation between the identities used by the transport protocol and the identities used for keying also needs to be explored.
在体系结构中，是范围的一部分。传输协议所使用的身份与用于键控的身份之间的关系也需要探索。
In order to further clarify the items listed in scope of the proposed work, this section provides some background on related work and the use cases envisioned for the proposed work.
为了进一步澄清拟议工作范围中列出的项目，本节提供了相关工作的一些背景以及拟议工作设想的用例。
A number of EAP methods support fast re-authentication. In this section, we examine their properties in further detail.
许多EAP方法支持快速重新身份验证。在本节中，我们将进一步详细研究它们的属性。
EAP-SIM [RFC4186] and EAP-AKA [RFC4187] support fast re-authentication, bootstrapped by the keys generated during an initial full authentication. In response to the typical EAP-Request/ Identity, the peer sends a specially formatted identity indicating a desire to perform a fast re-authentication. A single round-trip occurs to verify knowledge of the existing keys and provide fresh nonces for generating new keys. This is followed by an EAP success. In the end, it requires a single local round trip between the peer and authenticator, followed by another round trip between the peer and EAP server. AKA is based on symmetric-key cryptography, so processing latency is minimal.
EAP-SIM[RFC4186]和EAP-AKA[RFC4187]支持快速重新认证，由初始完全认证期间生成的密钥引导。作为对典型EAP请求/标识的响应，对等方发送一个特殊格式的标识，表示希望执行快速重新认证。发生一次往返，以验证现有密钥的知识，并为生成新密钥提供新的nonce。随后是EAP的成功。最后，它需要在对等方和验证器之间进行一次本地往返，然后在对等方和EAP服务器之间进行另一次往返。AKA基于对称密钥加密，因此处理延迟最小。
EAP-TTLS [EAP-TTLS] and PEAP (Protected EAP Protocol) [JOSEFSSON-PPPEXT] support using TLS session resumption for fast re-authentication. During the TLS handshake, the client includes the message ID of the previous session he wishes to resume, and the server can echo that ID back if it agrees to resume the session. EAP-FAST [RFC4851] also supports TLS session resumption, but additionally allows stateless session resumption as defined in [RFC5077]. Overall, for all three protocols, there are still two round trips between the peer and EAP server, in addition to the local round trip for the Identity request and response.
EAP-TTLS[EAP-TTLS]和PEAP（受保护的EAP协议）[JOSEFSSON-PPPEXT]支持使用TLS会话恢复进行快速重新身份验证。在TLS握手期间，客户机包括他希望恢复的上一个会话的消息ID，如果服务器同意恢复会话，则可以回显该ID。EAP-FAST[RFC4851]还支持TLS会话恢复，但还允许[RFC5077]中定义的无状态会话恢复。总的来说，对于所有三个协议，除了身份请求和响应的本地往返之外，对等方和EAP服务器之间还有两个往返。
To improve performance, fast re-authentication needs to reduce the number of overall round trips. Optimal performance could result from eliminating the EAP-Request/Identity and EAP-Response/Identity messages observed in typical EAP method execution, and allowing a single round trip between the peer and a local re-authentication server.
为了提高性能，快速重新身份验证需要减少总体往返次数。最佳性能可以通过消除典型EAP方法执行中观察到的EAP请求/标识和EAP响应/标识消息，并允许对等方和本地重新认证服务器之间的单次往返来实现。
One of the EAP lower layers, IEEE 802.11 [IEEE.802-11R-D9.0], is in the process of specifying a fast handover mechanism. Access Points (APs) are grouped into mobility domains. Initial authentication to any AP in a mobility domain requires execution of EAP, but handover between APs within the mobility domain does not require the use of EAP.
EAP较低层之一IEEE 802.11[IEEE.802-11R-D9.0]正在指定快速切换机制。接入点（AP）被分组到移动域中。对移动域中的任何AP的初始认证需要执行EAP，但是移动域中的AP之间的切换不需要使用EAP。
Internal to the mobility domain are sets of security associations to support key transfers between APs. In one model, relatively few devices, called R0-KHs, act as authenticators. All EAP traffic traverses an R0-KH, and it derives the initial IEEE 802.11 keys. It then distributes cryptographically separate keys to APs in the mobility domain, as necessary, to support the client mobility. For a deployment with M designated R0-KHs and N APs, this requires M*N security associations. For small M, this approach scales reasonably. Another approach allows any AP to act as an R0-KH, necessitating a full mesh of N2 security associations, which scales poorly.
移动域的内部是一组安全关联，用于支持AP之间的密钥传输。在一个模型中，相对较少的设备（称为R0 KHs）充当验证器。所有EAP通信都经过一个R0-KH，并且它派生出初始IEEE 802.11密钥。然后，它根据需要向移动性域中的ap分发加密的独立密钥，以支持客户端移动性。对于具有M个指定R0 KHs和N个AP的部署，这需要M*N个安全关联。对于较小的M，这种方法可以合理地扩展。另一种方法允许任何AP充当R0-KH，需要N2安全关联的完整网格，其扩展性很差。
The model that utilizes designated R0-KHs is architecturally similar to the fast re-authentication model proposed by HOKEY. HOKEY, however, allows for handover between authenticators. This would allow an IEEE 802.11r-enabled peer to handover from one mobility domain to another without performing an EAP authentication.
使用指定R0 KHs的模型在架构上类似于HOKEY提出的快速重新认证模型。然而，HOKEY允许在认证器之间进行切换。这将允许启用IEEE 802.11r的对等切换从一个移动域切换到另一个移动域，而无需执行EAP认证。
The CAPWAP (Control and Provisioning of Wireless Access Points) protocol [CAPWAP-PROTOCOL-SPEC] allows the functionality of an IEEE 802.11 access point to be split into two physical devices in enterprise deployments. Wireless Termination Points (WTPs) implement the physical and low-level Media Access Control (MAC) layers, while a centralized Access Controller (AC) provides higher-level management and protocol execution. Client authentication is handled by the AC, which acts as the AAA authenticator.
CAPWAP（无线接入点的控制和配置）协议[CAPWAP-protocol-SPEC]允许在企业部署中将IEEE 802.11接入点的功能拆分为两个物理设备。无线终端点（WTP）实现物理层和低级媒体访问控制（MAC）层，而集中式访问控制器（AC）提供高级管理和协议执行。客户端身份验证由AC处理，AC充当AAA身份验证程序。
One of the many features provided by CAPWAP is the ability to roam between WTPs without executing an EAP authentication. To accomplish this, the AC caches the MSK from an initial EAP authentication, and uses it to execute a separate four-way handshake with the station as it moves between WTPs. The keys resulting from the four-way handshake are then distributed to the WTP to which the station is associated. CAPWAP is transparent to the station.
CAPWAP提供的众多功能之一是能够在WTP之间漫游，而无需执行EAP身份验证。为了实现这一点，AC缓存来自初始EAP认证的MSK，并在站点在WTP之间移动时使用它与站点执行单独的四向握手。然后，四向握手产生的密钥被分发到与站点相关联的WTP。CAPWAP对电台是透明的。
CAPWAP currently has no means to support roaming between ACs in an enterprise network. The proposed work on EAP efficient re-authentication addresses is an inter-authenticator handover problem
CAPWAP目前无法支持企业网络中ACs之间的漫游。EAP有效重认证地址的研究是一个认证者间切换问题
from an EAP perspective, which applies during handover between ACs. Inter-AC handover is a topic yet to be addressed in great detail and the re-authentication work can potentially address it in an effective manner.
从EAP的角度来看，这适用于ACs之间的切换。AC间切换是一个有待详细解决的主题，重新认证工作可能以有效的方式解决它。
This document details the HOKEY problem statement. Since HOKEY is an authentication protocol, there is a myriad of security-related issues surrounding its development and deployment.
本文档详细介绍了HOKEY问题陈述。由于HOKEY是一种身份验证协议，因此围绕其开发和部署存在大量与安全相关的问题。
In this document, we have detailed a variety of security properties inferred from [RFC4962] to which HOKEY must conform, including the management of key context, scope, freshness, and transport; resistance to attacks based on the domino effect; and authentication and authorization. See Section 5 for further details.
在本文档中，我们详细介绍了从[RFC4962]推断出的HOKEY必须符合的各种安全属性，包括密钥上下文、范围、新鲜度和传输的管理；抵抗基于多米诺效应的攻击；以及认证和授权。详见第5节。
This document represents the synthesis of two problem statement documents. In this section, we acknowledge their contributions, and involvement in the early documents.
本文档综合了两个问题陈述文档。在本节中，我们感谢他们的贡献和参与早期文件。
Mohan Parthasarathy Nokia EMail: mohan.parthasarathy@nokia.com
Mohan Parthasarathy诺基亚电子邮件：Mohan。parthasarathy@nokia.com
Julien Bournelle France Telecom R&D EMail: julien.bournelle@orange-ftgroup.com
Julien Bournelle法国电信研发电子邮件：Julien。bournelle@orange-ftgroup.com
Hannes Tschofenig Siemens EMail: Hannes.Tschofenig@siemens.com
Hannes Tschofenig西门子电子邮件：Hannes。Tschofenig@siemens.com
Rafael Marin Lopez Universidad de Murcia EMail: rafa@dif.um.es
拉斐尔·马林·洛佩兹穆尔西亚大学电子邮件：rafa@dif.um.es
The authors would like to thank the participants of the HOKEY working group for their review and comments including: Glen Zorn, Dan Harkins, Joe Salowey, and Yoshi Ohba. The authors would also like to thank those that provided last-call reviews including: Bernard Aboba, Alan DeKok, Jari Arkko, and Hannes Tschofenig.
作者要感谢HOKEY工作组的参与者的评论和意见，包括：Glen Zorn、Dan Harkins、Joe Salowey和Yoshi Ohba。作者还想感谢那些提供最后通话评论的人，包括：Bernard Aboba、Alan DeKok、Jari Arkko和Hannes Tschofenig。
[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月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[CAPWAP-PROTOCOL-SPEC] Calhoun, P., Montemurro, M., and D. Stanely, "CAPWAP Protocol Specification", Work in Progress, March 2008.
[CAPWAP-PROTOCOL-SPEC]Calhoun，P.，Montemurro，M.，和D.Stanely，“CAPWAP协议规范”，正在进行的工作，2008年3月。
[DIME-APP-DESIGN] Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. Loughney, "Diameter Applications Design Guidelines", Work in Progress, January 2008.
[DIME-APP-DESIGN]Fajardo，V.，Asveren，T.，Tschofenig，H.，McGregor，G.，和J.Loughney，“直径应用设计指南”，正在进行的工作，2008年1月。
[EAP-KEYING] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, November 2007.
[EAP-KEYING]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，正在进行的工作，2007年11月。
[EAP-TTLS] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)", Work in Progress, March 2008.
[EAP-TTLS]Funk，P.和S.Blake Wilson，“EAP隧道TLS认证协议版本0（EAP-TTLSv0）”，正在进行的工作，2008年3月。
[IEEE.802-11R-D9.0] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications - Amendment 2: Fast BSS Transition", IEEE Standard 802.11r, January 2008.
[IEEE.802-11R-D9.0]“信息技术-系统间电信和信息交换-局域网和城域网-特定要求-第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范-修改件2：快速BSS转换”，IEEE标准802.11R，2008年1月。
[JOSEFSSON-PPPEXT] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[JOSEFSSON-PPPEXT]JOSEFSSON，S.，Palekar，A.，Simon，D.，和G.Zorn，“受保护的EAP协议（PEAP）版本2”，正在进行的工作，2004年10月。
[LGS07] Ledlie, J., Gardner, P., and M. Selter, "Network Coordinates in the Wild", USENIX Symposium on Networked System Design and Implementation, April 2007.
[LGS07]Ledlie，J.，Gardner，P.，和M.Selter，“野外网络坐标”，USENIX网络系统设计和实施研讨会，2007年4月。
[MSA03] Mishra, A., Shin, M., and W. Arbaugh, "An Empirical Analysis of the IEEE 802.11 MAC-Layer Handoff Process", ACM SIGCOMM Computer and Communications Review, April 2003.
[MSA03]Mishra，A.，Shin，M.，和W.Arbaugh，“IEEE 802.11 MAC层切换过程的实证分析”，ACM SIGCOMM计算机与通信评论，2003年4月。
[MSPCA04] Mishra, A., Shin, M., Petroni, N., Clancy, T., and W. Arbaugh, "Proactive Key Distribution using Neighbor Graphs", IEEE Wireless Communications, February 2004.
[MSPCA04]Mishra，A.，Shin，M.，Petroni，N.，Clancy，T.，和W.Arbaugh，“使用邻居图的主动密钥分配”，IEEE无线通信，2004年2月。
[RADEXT-DESIGN] Weber, G. and A. DeKok, "RADIUS Design Guidelines", Work in Progress, December 2007.
[RADEXT-DESIGN]Weber，G.和A.DeKok，“半径设计指南”，正在进行的工作，2007年12月。
[RFC3990] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement", RFC 3990, February 2005.
[RFC3990]O'Hara，B.，Calhoun，P.，和J.Kempf，“无线接入点（CAPWAP）配置和配置问题声明”，RFC 39902005年2月。
[RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006.
[RFC4186]Haverinen，H.和J.Salowey，“全球移动通信系统（GSM）用户身份模块（EAP-SIM）的可扩展认证协议方法”，RFC 4186，2006年1月。
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4187]Arkko，J.和H.Haverinen，“第三代认证和密钥协议（EAP-AKA）的可扩展认证协议方法”，RFC 4187，2006年1月。
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.
[RFC4851]Cam Winget，N.，McGrew，D.，Salowey，J.，和H.Zhou，“通过安全隧道可扩展认证协议方法（EAP-FAST）的灵活认证”，RFC 4851，2007年5月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
Authors' Addresses
作者地址
T. Charles Clancy, Editor Laboratory for Telecommunications Sciences US Department of Defense College Park, MD USA
T.Charles Clancy，美国马里兰州国防部帕克学院电信科学编辑实验室
EMail: clancy@LTSnet.net
EMail: clancy@LTSnet.net
Madjid Nakhjiri Motorola
麦吉德·纳基里摩托罗拉
EMail: madjid.nakhjiri@motorola.com
EMail: madjid.nakhjiri@motorola.com
Vidya Narayanan Qualcomm, Inc. San Diego, CA USA
美国加利福尼亚州圣地亚哥市维迪亚·纳拉亚南高通公司
EMail: vidyan@qualcomm.com
EMail: vidyan@qualcomm.com
Lakshminath Dondeti Qualcomm, Inc. San Diego, CA USA
美国加利福尼亚州圣地亚哥Lakshminath Dondeti高通公司
EMail: ldondeti@qualcomm.com
EMail: ldondeti@qualcomm.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.