Network Working Group R. Housley
Request for Comments: 4962 Vigil Security
BCP: 132 B. Aboba
Category: Best Current Practice Microsoft
July 2007
Network Working Group R. Housley
Request for Comments: 4962 Vigil Security
BCP: 132 B. Aboba
Category: Best Current Practice Microsoft
July 2007
Guidance for Authentication, Authorization, and Accounting (AAA) Key Management
认证、授权和记帐（AAA）密钥管理指南
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document provides guidance to designers of Authentication, Authorization, and Accounting (AAA) key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management.
本文档为身份验证、授权和记帐（AAA）密钥管理协议的设计者提供指导。该指南对包括AAA密钥管理协议的系统和解决方案的设计者也很有用。鉴于该领域的专家在设计安全、持久的密钥管理算法和协议方面的复杂性和困难性，几乎可以肯定，在该领域没有深厚专业知识的IETF工作组设计自己的基于身份验证、授权的密钥管理算法和协议是不合适的，和记帐（AAA）协议。本文件中的指南适用于要求作为IETF RFC发布的文件。此外，这些指南将对其他指定AAA密钥管理的标准开发组织（SDO）有用。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Specification .................................3
1.2. Mandatory to Implement .....................................3
1.3. Terminology ................................................3
2. AAA Environment Concerns ........................................5
3. AAA Key Management Requirements .................................7
4. AAA Key Management Recommendations .............................13
5. Security Considerations ........................................14
6. Normative References ...........................................15
7. Informative References .........................................15
Appendix: AAA Key Management History ..............................20
Acknowledgments ...................................................22
1. Introduction ....................................................2
1.1. Requirements Specification .................................3
1.2. Mandatory to Implement .....................................3
1.3. Terminology ................................................3
2. AAA Environment Concerns ........................................5
3. AAA Key Management Requirements .................................7
4. AAA Key Management Recommendations .............................13
5. Security Considerations ........................................14
6. Normative References ...........................................15
7. Informative References .........................................15
Appendix: AAA Key Management History ..............................20
Acknowledgments ...................................................22
This document provides architectural guidance to designers of AAA key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols.
本文档为AAA密钥管理协议的设计者提供了体系结构指导。该指南对包括AAA密钥管理协议的系统和解决方案的设计者也很有用。
AAA key management often includes a collection of protocols, one of which is the AAA protocol. Other protocols are used in conjunction with the AAA protocol to provide an overall solution. These other protocols often provide authentication and security association establishment.
AAA密钥管理通常包括一组协议，其中一个是AAA协议。其他协议与AAA协议结合使用，以提供整体解决方案。这些其他协议通常提供身份验证和安全关联建立。
Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization and Accounting (AAA) protocols. These guidelines apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management that depends on IETF specifications for protocols such as Extensible Authentication Protocol (EAP) [RFC3748], Remote Authentication Dial-In User Service (RADIUS) [RFC2865], and Diameter [RFC3588].
鉴于该领域的专家在设计安全、持久的密钥管理算法和协议方面的复杂性和难度，IETF工作组如果在该领域没有深厚的专业知识，几乎肯定不适合设计基于身份验证的自己的密钥管理算法和协议，授权和记帐（AAA）协议。这些指南适用于要求作为IETF RFC发布的文件。此外，这些指南将对其他标准开发组织（SDO）有用，这些组织指定AAA密钥管理，该管理取决于IETF协议规范，如可扩展认证协议（EAP）[RFC3748]、远程认证拨入用户服务（RADIUS）[RFC2865]和DIAMER[RFC3588]。
In March 2003, at the IETF 56 AAA Working Group Session, Russ Housley gave a presentation on "Key Management in AAA" [H]. That presentation established the vast majority of the requirements contained in this document. Over the last three years, this collection of requirements have become known as the "Housley Criteria".
2003年3月，在IETF 56 AAA工作组会议上，Russ Housley介绍了“AAA中的密钥管理”[H]。该介绍确定了本文件所载的绝大多数要求。在过去的三年中，这些要求被称为“Housley标准”。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [RFC2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可和可选时，应按照RFC 2119[RFC2119]中的说明进行解释。
An AAA key management proposal is not compliant with this specification if it fails to satisfy one or more of the MUST or MUST NOT statements. An AAA key management proposal that satisfies all the MUST, MUST NOT, SHOULD, and SHOULD NOT statements is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT statements but not all the SHOULD or SHOULD NOT requirements is said to be "conditionally compliant".
如果AAA密钥管理方案未能满足一个或多个“必须”或“不得”声明，则该方案不符合本规范。满足所有必须、不得、应该和不应该声明的AAA密钥管理方案称为“无条件符合”；满足所有“必须”和“不得”陈述，但并非所有“应该”或“不应该”要求的人被称为“有条件遵从”。
The guidance provided in this document is mandatory to implement. However, it is not mandatory to use. That is, configuration at the time of deployment may result in a deployed implementation that does not conform with all of these requirements.
本文件中提供的指导是强制性的。但是，它不是强制使用的。也就是说，部署时的配置可能导致部署的实现不符合所有这些要求。
For example, [RFC4072] enables EAP keying material to be delivered from a AAA server to an AAA client without disclosure to third parties. Thus, key confidentiality is mandatory to implement in Diameter [RFC3588]. However, key confidentiality is not mandatory to use.
例如，[RFC4072]使EAP密钥材料能够从AAA服务器传送到AAA客户端，而无需向第三方披露。因此，在Diameter中实现密钥机密性是强制性的[RFC3588]。但是，密钥保密性不是必须使用的。
This section defines terms that are used in this document.
本节定义了本文档中使用的术语。
AAA Authentication, Authorization, and Accounting (AAA). AAA protocols include RADIUS [RFC2865] and Diameter [RFC3588].
AAA认证、授权和记帐（AAA）。AAA协议包括半径[RFC2865]和直径[RFC3588]。
Authenticator The party initiating EAP authentication. The term authenticator is used in [802.1X], and authenticator has the same meaning in this document.
Authenticator发起EAP身份验证的一方。[802.1X]中使用了术语authenticator，authenticator在本文档中具有相同的含义。
Backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. This terminology is also used in [802.1X].
后端身份验证服务器后端身份验证服务器是向身份验证者提供身份验证服务的实体。[802.1X]中也使用了此术语。
CHAP Challenge Handshake Authentication Protocol; a one-way challenge/response authentication protocol defined in [RFC1994].
CHAP挑战握手认证协议；[RFC1994]中定义的单向质询/响应身份验证协议。
EAP Extensible Authentication Protocol, defined in [RFC3748].
[RFC3748]中定义的EAP可扩展身份验证协议。
EAP server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server.
EAP服务器与对等方终止EAP身份验证方法的实体。在不使用后端身份验证服务器的情况下，EAP服务器是身份验证程序的一部分。在认证器以直通模式操作的情况下，EAP服务器位于后端认证服务器上。
Key Wrap The encryption of one symmetric cryptographic key in another. The algorithm used for the encryption is called a key wrap algorithm or a key encryption algorithm. The key used in the encryption process is called a key-encryption key (KEK).
密钥封装一个对称加密密钥在另一个对称加密密钥中的加密。用于加密的算法称为密钥包裹算法或密钥加密算法。加密过程中使用的密钥称为密钥加密密钥（KEK）。
PAP Password Authentication Protocol; a deprecated cleartext password PPP authentication protocol, originally defined in [RFC1334].
密码认证协议；不推荐使用的明文密码PPP身份验证协议，最初在[RFC1334]中定义。
Party A party is a processing entity that can be identified as a single role in a protocol.
参与方是一个处理实体，可以在协议中标识为单个角色。
Peer The end of the link that responds to the authenticator. In [802.1X], this end is known as the supplicant.
对等响应身份验证器的链接的末端。在[802.1X]中，这一端被称为恳求者。
PPP Point-to-Point Protocol, defined in [RFC1661], provides support for multiprotocol serial datalinks. PPP is the primary IP datalink used for dial-in NAS connection service.
[RFC1661]中定义的PPP点对点协议为多协议串行数据链路提供支持。PPP是用于拨入NAS连接服务的主要IP数据链路。
Secure Association Protocol A protocol for managing security associations derived from EAP and/or AAA exchanges. The protocol establishes a security association, which includes symmetric keys and a context for the use of the keys. An example of a Secure Association Protocol is the 4-way handshake defined within [802.11i].
安全关联协议用于管理从EAP和/或AAA交换派生的安全关联的协议。该协议建立了一个安全关联，其中包括对称密钥和密钥使用的上下文。安全关联协议的一个示例是[802.11i]中定义的4路握手。
Session Keys Keying material used to protect data exchanged after authentication has successfully completed, using the negotiated ciphersuite.
会话密钥密钥材料，用于使用协商密码套件保护身份验证成功完成后交换的数据。
Network Access Server (NAS) A device that provides an access service for a user to a network. The service may be a network connection, or a value added service such as terminal emulation, as described in [RFC2881].
网络访问服务器（NAS）为用户提供网络访问服务的设备。如[RFC2881]所述，该服务可以是网络连接，也可以是增值服务，如终端仿真。
4-Way Handshake A Secure Association Protocol, defined in [802.11i], which confirms mutual possession of a Pairwise Master Key by two parties and distributes a Group Key.
4路握手[802.11i]中定义的一种安全关联协议，用于确认双方相互拥有成对主密钥，并分发组密钥。
Examples of serious flaws plague the history of key management protocol development, starting with the very first attempt to define a key management protocol in the open literature, which was published in 1978 [NS]. A flaw and a fix were published in 1981 [DS], and the fix was broken in 1994 [AN]. In 1995 [L], a new flaw was found in the original 1978 version, in an area not affected by the 1981/1994 issue. All of these flaws were blindingly obvious once described, yet no one spotted them earlier. Note that the original protocol, if it were revised to employ certificates, which of course had yet to be invented, was only three messages. Many proposed AAA key management schemes are significantly more complicated.
严重缺陷的例子困扰着密钥管理协议的发展历史，从1978年发表的公开文献中首次尝试定义密钥管理协议开始[NS]。1981年[DS]发布了一个缺陷和一个修复，1994年[AN]发布了该修复。1995年[L]，在1978年的原始版本中发现了一个新的缺陷，该区域不受1981/1994年版本的影响。所有这些缺陷一旦被描述，都是显而易见的，但之前没有人发现它们。请注意，如果将原始协议修改为使用证书（当然，证书尚未发明），那么它只有三条消息。许多建议的AAA密钥管理方案要复杂得多。
This bit of history shows that key management protocols are subtle. Experts can easily miss a flaw. As a result, peer review by multiple experts is essential, especially since many proposed AAA key management schemes are significantly more complicated. In addition, formal methods can help uncover problems [M].
这段历史表明，密钥管理协议是微妙的。专家很容易忽略一个缺陷。因此，由多个专家进行同行审查是必要的，特别是因为许多拟议的AAA密钥管理方案要复杂得多。此外，形式化方法有助于发现问题[M]。
AAA-based key management is being incorporated into standards developed by the IETF and other standards development organizations (SDOs), such as IEEE 802. However, due to ad hoc development of AAA-based key management, AAA-based key distribution schemes have poorly understood security properties, even when well-studied cryptographic algorithms are employed. More academic research is needed to fully understand the security properties of AAA-based key management in the diverse protocol environments where it is being employed today. In the absence of such research results, pragmatic guidance based on sound security engineering principles is needed.
基于AAA的密钥管理正被纳入IETF和其他标准开发组织（SDO）制定的标准中，如IEEE 802。然而，由于基于AAA的密钥管理的特殊发展，基于AAA的密钥分发方案对安全性的了解很少，即使使用了经过充分研究的密码算法。需要进行更多的学术研究，以充分了解基于AAA的密钥管理在当前使用的各种协议环境中的安全特性。在缺乏此类研究成果的情况下，需要基于可靠安全工程原则的务实指导。
In addition to the need for interoperability, cryptographic algorithm independent solutions are greatly preferable. Without algorithm independence, the AAA-based key management protocol must be changed whenever a problem is discovered with any of the selected algorithms. As AAA history shows, problems are inevitable. Problems can surface due to age or design failure.
除了互操作性的需要，密码算法独立的解决方案是非常可取的。在没有算法独立性的情况下，只要发现任何所选算法存在问题，就必须更改基于AAA的密钥管理协议。美国汽车协会的历史表明，问题是不可避免的。由于老化或设计失败，问题可能会浮出水面。
DES [FIPS46] was a well-designed encryption algorithm, and it provided protection for many years. Yet, the 56-bit key size was eventually overcome by Moore's Law. No significant cryptographic deficiencies have been discovered in DES.
DES[FIPS46]是一种设计良好的加密算法，多年来一直提供保护。然而，56位密钥大小最终被摩尔定律所克服。DES中未发现明显的密码缺陷。
The history of AAA underlines the importance of algorithm independence as flaws have been found in authentication mechanisms such as CHAP, MS-CHAPv1 [SM1], MS-CHAPv2 [SM2], Kerberos [W][BM][DLS], and LEAP [B]. Unfortunately, RADIUS [RFC2865] mandates use of the MD5 algorithm for integrity protection, which has known deficiencies, and RADIUS has no provisions to negotiate substitute algorithms. Similarly, the vendor-specific key wrap mechanism defined in [RFC2548] has no provisions to negotiate substitute algorithms.
AAA的历史强调了算法独立性的重要性，因为在诸如CHAP、MS-CHAPv1[SM1]、MS-CHAPv2[SM2]、Kerberos[W][BM][DLS]和LEAP[B]等身份验证机制中发现了缺陷。不幸的是，RADIUS[RFC2865]强制使用MD5算法进行完整性保护，该算法存在已知的缺陷，RADIUS没有规定协商替代算法。类似地，[RFC2548]中定义的特定于供应商的密钥封装机制没有协商替代算法的规定。
The principle of least privilege is an important design guideline. This principle requires that a party be given no more privilege than necessary to perform the task assigned to them. Ensuring least privilege requires clear identification of the tasks assigned to each party, and explicit determination of the minimum set of privileges required to perform those tasks. Only those privileges necessary to perform the tasks are granted. By denying to parties unneeded privileges, those denied privileges cannot be used to circumvent security policy or enable attackers. With this principle in mind, AAA key management schemes need to be designed in a manner where each party has only the privileges necessary to perform their role. That is, no party should have access to any keying material that is not needed to perform their own role. A party has access to a particular key if it has access to all of the secret information needed to derive it.
最小特权原则是一项重要的设计准则。这一原则要求一方不享有执行分配给他们的任务所必需的特权。确保最低权限要求明确标识分配给各方的任务，并明确确定执行这些任务所需的最低权限集。仅授予执行任务所需的特权。通过向各方拒绝不需要的特权，这些被拒绝的特权不能用于规避安全策略或启用攻击者。考虑到这一原则，AAA密钥管理方案的设计需要确保各方仅拥有执行其角色所需的特权。也就是说，任何一方都不应访问执行其自身角色所不需要的任何键控材料。如果一方可以访问派生密钥所需的所有机密信息，则该方可以访问特定密钥。
EAP is being used in new ways. The inclusion of support for EAP within Internet Key Exchange Protocol version 2 (IKEv2) and the standardization of robust Wireless LAN security [802.11i] based on EAP are two examples. EAP has also been proposed within IEEE 802.16e [802.16e] and by the IETF PANA Working Group. AAA-based key management is being incorporated into standards developed by the IETF and other standards development organizations (SDOs), such as IEEE 802. However, due to ad hoc development of AAA-based key management, AAA-based key distribution schemes have poorly understood security properties, even when well-studied cryptographic algorithms are
EAP正在以新的方式使用。互联网密钥交换协议版本2（IKEv2）中包含对EAP的支持，以及基于EAP的健壮无线局域网安全[802.11i]的标准化就是两个例子。IEEE802.16e[802.16e]和IETF PANA工作组也提出了EAP。基于AAA的密钥管理正被纳入IETF和其他标准开发组织（SDO）制定的标准中，如IEEE 802。然而，由于基于AAA的密钥管理的特殊发展，基于AAA的密钥分发方案对安全性的理解很差，即使在使用经过充分研究的密码算法时也是如此
employed. More academic research is needed to fully understand the security properties of AAA-based key management in the diverse protocol environments where it is being employed today. In the absence of research results, pragmatic guidance based on sound security engineering principles is needed.
雇佣。需要进行更多的学术研究，以充分了解基于AAA的密钥管理在当前使用的各种协议环境中的安全特性。在缺乏研究成果的情况下，需要基于健全安全工程原则的务实指导。
EAP selects one end-to-end authentication mechanism. The mechanisms defined in [RFC3748] only support unilateral authentication, and they do not support mutual authentication or key derivation. As a result, these mechanisms do not fulfill the security requirements for many deployment scenarios, including Wireless LAN authentication [RFC4017].
EAP选择一种端到端认证机制。[RFC3748]中定义的机制仅支持单边身份验证，不支持相互身份验证或密钥派生。因此，这些机制无法满足许多部署场景的安全要求，包括无线局域网身份验证[RFC4017]。
To ensure adequate security and interoperability, EAP applications need to specify mandatory-to-implement algorithms. As described in [RFC3748], EAP methods seeking publication as an IETF RFC need to document their security claims. However, some EAP methods are not based on well-studied models, which makes the validity of these security claims difficult to determine.
为了确保足够的安全性和互操作性，EAP应用程序需要指定强制实现算法。如[RFC3748]所述，寻求发布为IETF RFC的EAP方法需要记录其安全声明。然而，一些EAP方法没有基于经过充分研究的模型，这使得这些安全声明的有效性难以确定。
In the context of EAP, the EAP peer and server are the parties involved in the EAP method conversation, and they gain access to key material when the conversation completes successfully. However, the lower-layer needs keying material to provide the desired protection through the use of cryptographic mechanisms. As a result, a "pass-through" mode is used to provide the keying material, and the lower-layer keying material is replicated from the AAA server to the authenticator. The only parties authorized to obtain all of the keying material are the EAP peer and server; the authenticator obtains only the keying material necessary for its specific role. No other party can obtain direct access to any of the keying material; however, other parties may receive keys that are derived from this keying material for a specific purpose as long as the requirements defined in the next section are met.
在EAP上下文中，EAP对等方和服务器是EAP方法对话中涉及的各方，当对话成功完成时，他们可以访问关键材料。然而，较低层需要密钥材料，通过使用密码机制提供所需的保护。结果，使用“通过”模式来提供密钥材料，并且将较低层密钥材料从AAA服务器复制到验证器。只有EAP对等方和服务器被授权获取所有密钥材料；验证器仅获取其特定角色所需的密钥材料。任何其他方均不得直接访问任何键控材料；但是，只要满足下一节中规定的要求，其他方可能会出于特定目的接收从该钥匙材料中衍生的钥匙。
The overall goal of AAA key management is to provide cryptographic keying material in situations where key derivation cannot be used by the peer and authenticator. It may not be possible because the authenticator lacks computational power, because it lacks the resources necessary to implement the various authentication mechanisms that might be required, or because it is undesirable for each authenticator to engage in a separate key management conversation.
AAA密钥管理的总体目标是在对等方和认证方无法使用密钥派生的情况下提供加密密钥材料。这可能是不可能的，因为验证器缺乏计算能力，因为它缺乏实现可能需要的各种身份验证机制所需的资源，或者因为每个验证器不希望参与单独的密钥管理对话。
This section provides guidance to AAA protocol designers, EAP method designers, and security association protocol designers. Acceptable solutions MUST meet all of these requirements.
本节为AAA协议设计人员、EAP方法设计人员和安全关联协议设计人员提供指导。可接受的解决方案必须满足所有这些要求。
Cryptographic algorithm independent
密码算法无关
The AAA key management protocol MUST be cryptographic algorithm independent. However, an EAP method MAY depend on a specific cryptographic algorithm. The ability to negotiate the use of a particular cryptographic algorithm provides resilience against compromise of a particular cryptographic algorithm. Algorithm independence is also REQUIRED with a Secure Association Protocol if one is defined. This is usually accomplished by including an algorithm identifier and parameters in the protocol, and by specifying the algorithm requirements in the protocol specification. While highly desirable, the ability to negotiate key derivation functions (KDFs) is not required. For interoperability, at least one suite of mandatory-to-implement algorithms MUST be selected. Note that without protection by IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] does not meet this requirement, since the integrity protection algorithm cannot be negotiated.
AAA密钥管理协议必须独立于加密算法。然而，EAP方法可能取决于特定的密码算法。协商使用特定加密算法的能力提供了抵御特定加密算法危害的弹性。如果定义了安全关联协议，则还需要算法独立性。这通常通过在协议中包含算法标识符和参数，以及在协议规范中指定算法要求来实现。虽然非常理想，但不需要协商密钥派生函数（KDF）的能力。为了实现互操作性，必须至少选择一套实现算法的必需工具。请注意，如果没有[RFC3579]第4.2节中所述的IPsec保护，RADIUS[RFC2865]不满足此要求，因为无法协商完整性保护算法。
This requirement does not mean that a protocol must support both public-key and symmetric-key cryptographic algorithms. It means that the protocol needs to be structured in such a way that multiple public-key algorithms can be used whenever a public-key algorithm is employed. Likewise, it means that the protocol needs to be structured in such a way that multiple symmetric-key algorithms can be used whenever a symmetric-key algorithm is employed.
这一要求并不意味着协议必须同时支持公钥和对称密钥加密算法。这意味着协议的结构需要确保在使用公钥算法时可以使用多个公钥算法。同样，这意味着协议的结构需要确保在使用对称密钥算法时可以使用多个对称密钥算法。
Strong, fresh session keys
强大、新鲜的会话密钥
While preserving algorithm independence, session keys MUST be strong and fresh. Each session deserves an independent session key. Fresh keys are required even when a long replay counter (that is, one that "will never wrap") is used to ensure that loss of state does not cause the same counter value to be used more than once with the same session key.
在保持算法独立性的同时，会话密钥必须是强且新鲜的。每个会话都需要一个独立的会话密钥。即使使用长重播计数器（即“永不换行”的计数器）来确保状态丢失不会导致同一计数器值与同一会话密钥一起使用多次，也需要使用新密钥。
Some EAP methods are capable of deriving keys of varying strength, and these EAP methods MUST permit the generation of keys meeting a minimum equivalent key strength. BCP 86 [RFC3766] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [SP800-57].
一些EAP方法能够导出不同强度的密钥，这些EAP方法必须允许生成满足最小等效密钥强度的密钥。BCP 86[RFC3766]提供有关适当密钥大小的建议。国家标准与技术研究所（NIST）也在[SP800-57]中提供了关于适当键尺寸的建议。
A fresh cryptographic key is one that is generated specifically for the intended use. In this situation, a secure association protocol is used to establish session keys. The AAA protocol and EAP method MUST ensure that the keying material supplied as an input to session key derivation is fresh, and the secure association protocol MUST generate a separate session key for each session, even if the keying material provided by EAP is cached. A cached key persists after the authentication exchange has completed. For the AAA/EAP server, key caching can happen when state is kept on the server. For the NAS or client, key caching can happen when the NAS or client does not destroy keying material immediately following the derivation of session keys.
新加密密钥是专门为预期用途生成的密钥。在这种情况下，使用安全关联协议来建立会话密钥。AAA协议和EAP方法必须确保作为会话密钥派生输入提供的密钥材料是新的，并且安全关联协议必须为每个会话生成单独的会话密钥，即使EAP提供的密钥材料被缓存。身份验证交换完成后，缓存的密钥将持续存在。对于AAA/EAP服务器，当状态保持在服务器上时，可以进行密钥缓存。对于NAS或客户端，当NAS或客户端在会话密钥派生后没有立即销毁密钥材料时，可能会发生密钥缓存。
Session keys MUST NOT be dependent on one another. Multiple session keys may be derived from a higher-level shared secret as long as a one-time value, usually called a nonce, is used to ensure that each session key is fresh. The mechanism used to generate session keys MUST ensure that the disclosure of one session key does not aid the attacker in discovering any other session keys.
会话密钥不能相互依赖。只要使用一个一次性值（通常称为nonce）来确保每个会话密钥都是新的，就可以从更高级别的共享密钥派生多个会话密钥。用于生成会话密钥的机制必须确保一个会话密钥的泄露不会帮助攻击者发现任何其他会话密钥。
Limit key scope
限制键范围
Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role. A party has access to a particular key if it has access to all of the secret information needed to derive it.
根据最低特权原则，各方不得访问履行其职责不需要的密钥材料。如果一方可以访问派生密钥所需的所有机密信息，则该方可以访问特定密钥。
Any protocol that is used to establish session keys MUST specify the scope for session keys, clearly identifying the parties to whom the session key is available.
用于建立会话密钥的任何协议都必须指定会话密钥的范围，明确标识会话密钥可供使用的各方。
Replay detection mechanism
重播检测机制
The AAA key management protocol exchanges MUST be replay protected, including AAA, EAP, and Secure Association Protocol exchanges. Replay protection allows a protocol message recipient to discard any message that was recorded during a previous legitimate dialogue and presented as though it belonged to the current dialogue.
AAA密钥管理协议交换必须受到重播保护，包括AAA、EAP和安全关联协议交换。重播保护允许协议消息接收者丢弃在上一次合法对话期间录制并显示的任何消息，就好像它属于当前对话一样。
Authenticate all parties
认证各方
Each party in the AAA key management protocol MUST be authenticated to the other parties with whom they communicate. Authentication mechanisms MUST maintain the confidentiality of any secret values used in the authentication process.
AAA密钥管理协议中的每一方都必须向与其通信的其他方进行身份验证。身份验证机制必须保持身份验证过程中使用的任何秘密值的机密性。
When a secure association protocol is used to establish session keys, the parties involved in the secure association protocol MUST identify themselves using identities that are meaningful in the lower-layer protocol environment that will employ the session keys. In this situation, the authenticator and peer may be known by different identifiers in the AAA protocol environment and the lower-layer protocol environment, making authorization decisions difficult without a clear key scope. If the lower-layer identifier of the peer will be used to make authorization decisions, then the pair of identifiers associated with the peer MUST be authorized by the authenticator and/or the AAA server.
当使用安全关联协议来建立会话密钥时，安全关联协议中涉及的各方必须使用在将使用会话密钥的较低层协议环境中有意义的标识来标识自己。在这种情况下，在AAA协议环境和较低层协议环境中，验证器和对等方可能由不同的标识符知道，这使得在没有明确的密钥范围的情况下很难做出授权决策。如果对等方的较低层标识符将用于做出授权决策，则与对等方相关联的标识符对必须由验证器和/或AAA服务器授权。
AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588], provide a mechanism for the identification of AAA clients; since the EAP authenticator and AAA client are always co-resident, this mechanism is applicable to the identification of EAP authenticators.
AAA协议，如RADIUS[RFC2865]和Diameter[RFC3588]，提供了识别AAA客户端的机制；由于EAP验证器和AAA客户端始终是共同驻留的，因此此机制适用于EAP验证器的标识。
When multiple base stations and a "controller" (such as a WLAN switch) comprise a single EAP authenticator, the "base station identity" is not relevant; the EAP method conversation takes place between the EAP peer and the EAP server. Also, many base stations can share the same authenticator identity. The authenticator identity is important in the AAA protocol exchange and the secure association protocol conversation.
当多个基站和“控制器”（例如WLAN交换机）包括单个EAP认证器时，“基站标识”不相关；EAP方法对话在EAP对等方和EAP服务器之间进行。此外，许多基站可以共享相同的验证器身份。认证者身份在AAA协议交换和安全关联协议会话中非常重要。
Authentication mechanisms MUST NOT employ plaintext passwords. Passwords may be used provided that they are not sent to another party without confidentiality protection.
身份验证机制不得使用明文密码。可以使用密码，前提是在没有保密保护的情况下，密码不会发送给另一方。
Peer and authenticator authorization
对等和身份验证器授权
Peer and authenticator authorization MUST be performed. These entities MUST demonstrate possession of the appropriate keying material, without disclosing it. Authorization is REQUIRED whenever a peer associates with a new authenticator. The authorization checking prevents an elevation of privilege attack, and it ensures that an unauthorized authenticator is detected.
必须执行对等和身份验证程序授权。这些实体必须证明拥有适当的键控材料，而不予以披露。每当对等方与新身份验证器关联时，都需要授权。授权检查可防止权限提升攻击，并确保检测到未经授权的身份验证程序。
Authorizations SHOULD be synchronized between the peer, NAS, and backend authentication server. Once the AAA key management protocol exchanges are complete, all of these parties should hold a common view of the authorizations associated with the other parties.
应在对等、NAS和后端身份验证服务器之间同步授权。一旦AAA密钥管理协议交换完成，所有这些方都应持有与其他方相关的授权的共同视图。
In addition to authenticating all parties, key management protocols need to demonstrate that the parties are authorized to possess keying material. Note that proof of possession of keying material does not necessarily prove authorization to hold that keying material. For example, within an IEEE 802.11i, the 4-way handshake demonstrates that both the peer and authenticator possess the same EAP keying material. However, by itself, this possession proof does not demonstrate that the authenticator was authorized by the backend authentication server to possess that keying material. As noted in RFC 3579 in Section 4.3.7, where AAA proxies are present, it is possible for one authenticator to impersonate another, unless each link in the AAA chain implements checks against impersonation. Even with these checks in place, an authenticator may still claim different identities to the peer and the backend authentication server. As described in RFC 3748 in Section 7.15, channel binding is required to enable the peer to verify that the authenticator claim of identity is both consistent and correct.
除了认证各方之外，密钥管理协议还需要证明各方有权拥有密钥材料。请注意，拥有钥匙材料的证明并不一定证明持有该钥匙材料的授权。例如，在IEEE 802.11i中，4路握手证明对等方和认证方都拥有相同的EAP密钥材料。然而，就其本身而言，该占有证明并不能证明认证者已被后端认证服务器授权拥有该密钥材料。如第4.3.7节RFC 3579中所述，如果存在AAA代理，则一个验证器可以模拟另一个验证器，除非AAA链中的每个链路对模拟进行检查。即使有了这些检查，身份验证器仍然可以向对等方和后端身份验证服务器声明不同的身份。如第7.15节RFC 3748所述，需要进行通道绑定，以使对等方能够验证身份验证器声明的一致性和正确性。
Keying material confidentiality and integrity
键入材料机密性和完整性
While preserving algorithm independence, confidentiality and integrity of all keying material MUST be maintained.
在保持算法独立性的同时，必须保持所有密钥材料的机密性和完整性。
Confirm ciphersuite selection
确认密码套件选择
The selection of the "best" ciphersuite SHOULD be securely confirmed. The mechanism SHOULD detect attempted roll-back attacks.
应安全地确认“最佳”密码套件的选择。该机制应检测尝试的回滚攻击。
Uniquely named keys
唯一命名的密钥
AAA key management proposals require a robust key naming scheme, particularly where key caching is supported. The key name provides a way to refer to a key in a protocol so that it is clear to all parties which key is being referenced. Objects that cannot be named cannot be managed. All keys MUST be uniquely named, and the key name MUST NOT directly or indirectly disclose the keying material. If the key name is not based on the keying material, then one can be sure that it cannot be used to assist in a search for the key value.
AAA密钥管理方案需要一个健壮的密钥命名方案，特别是在支持密钥缓存的情况下。密钥名称提供了一种在协议中引用密钥的方法，以便各方都清楚引用哪个密钥。无法管理无法命名的对象。所有密钥必须具有唯一的名称，且密钥名称不得直接或间接透露密钥材料。如果键名称不是基于键控材质，则可以确保它不能用于协助搜索键值。
Prevent the Domino effect
防止多米诺效应
Compromise of a single peer MUST NOT compromise keying material held by any other peer within the system, including session keys and long-term keys. Likewise, compromise of a single
单个对等方的泄露不得泄露系统内任何其他对等方持有的密钥材料，包括会话密钥和长期密钥。同样，一个国家的妥协也是如此
authenticator MUST NOT compromise keying material held by any other authenticator within the system. In the context of a key hierarchy, this means that the compromise of one node in the key hierarchy must not disclose the information necessary to compromise other branches in the key hierarchy. Obviously, the compromise of the root of the key hierarchy will compromise all of the keys; however, a compromise in one branch MUST NOT result in the compromise of other branches. There are many implications of this requirement; however, two implications deserve highlighting. First, the scope of the keying material must be defined and understood by all parties that communicate with a party that holds that keying material. Second, a party that holds keying material in a key hierarchy must not share that keying material with parties that are associated with other branches in the key hierarchy.
验证者不得泄露系统内任何其他验证者持有的密钥材料。在密钥层次结构的上下文中，这意味着密钥层次结构中一个节点的泄露不得泄露泄露泄露密钥层次结构中其他分支所需的信息。显然，密钥层次结构根的折衷将折衷所有密钥；但是，一个分支中的妥协不得导致其他分支的妥协。这一要求有许多含义；然而，有两个影响值得强调。首先，所有与持有密钥材料的一方进行沟通的各方必须定义并理解密钥材料的范围。其次，在密钥层次结构中持有密钥材料的参与方不得与与密钥层次结构中其他分支关联的参与方共享该密钥材料。
Group keys are an obvious exception. Since all members of the group have a copy of the same key, compromise of any one of the group members will result in the disclosure of the group key.
组键是一个明显的例外。由于组的所有成员都有同一密钥的副本，任何一个组成员的泄露都会导致组密钥的泄露。
Bind key to its context
将键绑定到其上下文
Keying material MUST be bound to the appropriate context. The context includes the following.
键控材质必须绑定到适当的上下文。上下文包括以下内容。
o The manner in which the keying material is expected to be used.
o 预期使用键控材料的方式。
o The other parties that are expected to have access to the keying material.
o 预期可以访问键控材料的其他方。
o The expected lifetime of the keying material. Lifetime of a child key SHOULD NOT be greater than the lifetime of its parent in the key hierarchy.
o 键控材质的预期寿命。子密钥的生存期不应大于密钥层次结构中其父密钥的生存期。
Any party with legitimate access to keying material can determine its context. In addition, the protocol MUST ensure that all parties with legitimate access to keying material have the same context for the keying material. This requires that the parties are properly identified and authenticated, so that all of the parties that have access to the keying material can be determined.
任何合法访问密钥材料的一方都可以确定其上下文。此外，协议必须确保合法访问密钥材料的所有各方都拥有相同的密钥材料上下文。这要求各方得到适当的识别和认证，以便能够确定能够访问密钥材料的所有各方。
The context will include the peer and NAS identities in more than one form. One (or more) name form is needed to identify these parties in the authentication exchange and the AAA protocol. Another name form may be needed to identify these parties within the lower layer that will employ the session key.
上下文将以多种形式包括对等和NAS标识。需要一个（或多个）名称表单来识别身份验证交换和AAA协议中的这些方。可能需要另一个名称表单来标识将使用会话密钥的较低层中的这些方。
Acceptable solutions SHOULD meet all of these requirements.
可接受的解决方案应满足所有这些要求。
Confidentiality of identity
身份保密
In many environments, it is important to provide confidentiality protection for identities. However, this is not important in other environments. For this reason, EAP methods are encouraged to provide a mechanism for identity protection of EAP peers, but such protection is not a requirement.
在许多环境中，为身份提供机密性保护非常重要。但是，这在其他环境中并不重要。因此，鼓励EAP方法为EAP对等方提供身份保护机制，但这种保护不是必需的。
Authorization restriction
授权限制
If peer authorization is restricted, then the peer SHOULD be made aware of the restriction. Otherwise, the peer may inadvertently attempt to circumvent the restriction. For example, authorization restrictions in an IEEE 802.11 environment include:
如果对等授权受到限制，则应让对等方知道该限制。否则，对等方可能无意中试图绕过限制。例如，IEEE 802.11环境中的授权限制包括：
o Key lifetimes, where the keying material can only be used for a certain period of time;
o 密钥寿命，其中密钥材料只能使用一段时间；
o SSID restrictions, where the keying material can only be used with a specific IEEE 802.11 SSID;
o SSID限制，其中键控材料只能与特定IEEE 802.11 SSID一起使用；
o Called-Station-ID restrictions, where the keying material can only be used with a single IEEE 802.11 BSSID; and
o 称为站点ID限制，其中键控材料只能与单个IEEE 802.11 BSSID一起使用；和
o Calling-Station-ID restrictions, where the keying material can only be used with a single peer IEEE 802 MAC address.
o 呼叫站ID限制，其中键控材料只能与单个对等IEEE 802 MAC地址一起使用。
This document provides architectural guidance to designers of AAA key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols.
本文档为AAA密钥管理协议的设计者提供了体系结构指导。该指南对包括AAA密钥管理协议的系统和解决方案的设计者也很有用。
In some deployment scenarios, more than one party in the AAA key management protocol can reside on the same host. For example, the EAP authenticator and AAA client are expected to reside on the same entity. Colocation enables a single unique authenticator identity to be sent by the authenticator to the AAA server as well as by the authenticator to the EAP peer. Use of the same identity in both conversations enables the peer and AAA server to confirm that the authenticator is consistent in its identification, avoiding potential impersonation attacks. If the authenticator and AAA client are not colocated, then the authenticator and AAA client identities will differ, and the key scope will not be synchronized between the EAP peer, authenticator, and server. Lack of key scope synchronization enables a number of security vulnerabilities, including impersonation. For this reason, a design needs to include mechanisms to ensure that the key scope and key naming are unambiguous.
在某些部署场景中，AAA密钥管理协议中的多个参与方可以驻留在同一主机上。例如，EAP验证器和AAA客户端应位于同一实体上。托管使身份验证器能够将单个唯一身份验证器标识发送到AAA服务器，也可以将身份验证器发送到EAP对等方。在两次对话中使用相同的身份可以使对等服务器和AAA服务器确认身份验证器的身份是一致的，从而避免潜在的模拟攻击。如果验证器和AAA客户机未共同定位，则验证器和AAA客户机标识将不同，并且密钥作用域将不会在EAP对等方、验证器和服务器之间同步。缺少密钥作用域同步会导致许多安全漏洞，包括模拟。因此，设计需要包括确保键范围和键命名明确的机制。
The AAA server is a trusted entity. When keying material is present at all, it establishes keying material with the peer and distributes keying material to the authenticator using the AAA protocol. It is trusted to only distribute keying material to the authenticator that was established with the peer, and it is trusted to provide that keying material to no other parties. In many systems, keying material established by the EAP peer and EAP server are combined with publicly available data to derive other keys. The AAA server is trusted to refrain from deriving these same keys even though it has access to the secret values that are needed to do so.
AAA服务器是一个受信任的实体。当密钥材料存在时，它与对等方建立密钥材料，并使用AAA协议将密钥材料分发给认证方。信任它只将密钥材料分发给与对等方建立的身份验证方，信任它不向其他方提供该密钥材料。在许多系统中，EAP对等方和EAP服务器建立的密钥材料与公开可用的数据相结合，以导出其他密钥。AAA服务器是可信的，可以避免派生这些相同的密钥，即使它可以访问这样做所需的秘密值。
The authenticator is also a trusted party. The authenticator is trusted not to distribute keying material provided by the AAA server to any other parties. If the authenticator uses a key derivation function to derive additional keying material, the authenticator is trusted to distribute the derived keying material only to the appropriate party that is known to the peer, and no other party. When this approach is used, care must be taken to ensure that the resulting key management system meets all of the principles in this document, confirming that keys used to protect data are to be known only by the peer and authenticator.
身份验证器也是受信任的一方。信任认证者不会将AAA服务器提供的密钥材料分发给任何其他方。如果验证器使用密钥派生函数派生额外的密钥材料，则验证器被信任仅将派生的密钥材料分发给对等方已知的适当方，而不分发给其他方。使用此方法时，必须注意确保生成的密钥管理系统符合本文档中的所有原则，确认用于保护数据的密钥仅由对等方和身份验证方知晓。
EAP is used to authenticate the peer to the AAA/EAP server. Following successful authentication, the AAA/EAP server authorizes the peer. In many situations, this is accomplished by sending keying material to the authenticator and the peer in separate protocol
EAP用于对AAA/EAP服务器的对等方进行身份验证。认证成功后，AAA/EAP服务器授权对等方。在许多情况下，这是通过在单独的协议中向验证器和对等方发送密钥材料来实现的
messages. The authenticator is not directly authenticated to the peer. Rather, the peer determines that the authenticator has been authorized by the AAA/EAP server by confirming that the authenticator has the same AAA/EAP server-provided keying material. In some systems, explicit authenticator and peer mutual authentication is possible. This is desirable since it greatly improves accountability.
信息。验证器未直接向对等方进行身份验证。相反，对等方通过确认认证者具有相同的AAA/EAP服务器提供的密钥材料来确定认证者已被AAA/EAP服务器授权。在某些系统中，显式认证器和对等方相互认证是可能的。这是可取的，因为它大大提高了问责制。
When MIB modules are developed for AAA protocols or EAP methods, these MIB modules might include managed objects for keying material. The existence of managed objects associated with keying material offers an additional avenue for key compromise if these objects include the keying material itself. Therefore, these MIB modules MUST NOT include objects for private keys or symmetric keys. However, these MIB modules MAY include management objects that expose names and context associated with keys, and they MAY provide a means to delete keys.
当为AAA协议或EAP方法开发MIB模块时，这些MIB模块可能包括用于键入材料的托管对象。如果与关键帧材质关联的托管对象包括关键帧材质本身，则这些对象的存在为关键帧折衷提供了额外的途径。因此，这些MIB模块不得包含私钥或对称密钥的对象。然而，这些MIB模块可能包括公开与密钥相关联的名称和上下文的管理对象，并且它们可能提供删除密钥的方法。
[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月。
[802.1X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004, December 2004.
[802.1X]IEEE局域网和城域网标准：基于端口的网络访问控制，IEEE标准802.1X-2004，2004年12月。
[802.11i] Institute of Electrical and Electronics Engineers, "Supplement to Standard for Telecommunications and Information Exchange Between Systems -- LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE 802.11i, July 2004.
[802.11i]电气和电子工程师协会，“系统间电信和信息交换标准的补充——LAN/MAN特定要求——第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范：增强安全规范”，IEEE 802.11i，2004年7月。
[802.16e] Institute of Electrical and Electronics Engineers, "Supplement to Standard for Telecommunications and Information Exchange Between Systems -- LAN/MAN Specific Requirements - Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems -- Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", Draft, IEEE 802.16e/D8, May 2005.
[802.16e]电气和电子工程师学会，“系统间电信和信息交换标准的补充——LAN/MAN特定要求——第16部分：固定和移动宽带无线接入系统的空中接口——许可频带内固定和移动组合操作的物理和介质接入控制层的修改”“，草案，IEEE 802.16e/D8，2005年5月。
[AN] M. Abadi and R. Needham, "Prudent Engineering Practice for Cryptographic Protocols", Proc. IEEE Computer Society Symposium on Research in Security and Privacy, May 1994.
[AN]M.Abadi和R.Needham，“加密协议的谨慎工程实践”，Proc。IEEE计算机协会安全和隐私研究研讨会，1994年5月。
[B] Brewin, B., "LEAP attack tool author says he wants to alert users to risks", Computerworld, October 17, 2003.
[B] Brewin，B.，“LEAP攻击工具作者说他想提醒用户注意风险”，《计算机世界》，2003年10月17日。
[BM] Bellovin, S. and M. Merrit, "Limitations of the Kerberos authentication system", Proceedings of the 1991 Winter USENIX Conference, pp. 253-267, 1991.
[BM]Bellovin，S.和M.Merrit，“Kerberos身份验证系统的局限性”，1991年冬季USENIX会议记录，第253-267页，1991年。
[DDNN39.2] DCA DDN Program Management Office, "MILNET TAC Access Control", Defense Data Network Newsletter, DDN News 39, Special Issue, 26 Apr 1985, <http://www.isi.edu/ in-notes/museum/ddn-news/ddn-news.n39.2>.
[DDNN39.2]DCA DDN项目管理办公室，“MILNET TAC访问控制”，国防数据网络通讯，DDN新闻39，特刊，1985年4月26日<http://www.isi.edu/ 在notes/museum/ddn news/ddn news.n39.2>中。
[DLS] Dole, B., Lodin, S. and E. Spafford, "Misplaced trust: Kerberos 4 session keys", Proceedings of the Internet Society Network and Distributed System Security Symposium, pp. 60-70, March 1997.
[DLS]Dole，B.，Lodin，S.和E.Spafford，“错位信任：Kerberos 4会话密钥”，互联网社会网络和分布式系统安全研讨会论文集，第60-70页，1997年3月。
[DS] D. Denning and G. Sacco. "Timestamps in key distributed protocols", Communication of the ACM, 24(8):533--535, 1981.
D.Denning和G.Sacco。“关键分布式协议中的时间戳”，ACM通信，24（8）：533-5351981。
[FIPS46] Federal Information Processing Standards Publication (FIPS PUB) 46, Data Encryption Standard, 1977 January 15.
[FIPS46]联邦信息处理标准出版物（FIPS PUB）46，数据加密标准，1977年1月15日。
[H] Housley, R., "Key Management in AAA", Presentation to the AAA WG at IETF 56, March 2003, <http://www.ietf.org/ proceedings/03mar/slides/aaa-5/index.html>.
[H] Housley，R.，“AAA中的密钥管理”，在IETF 56上向AAA工作组的介绍，2003年3月<http://www.ietf.org/ 会议记录/03mar/slides/aaa-5/index.html>。
[L] G. Lowe. "An attack on the Needham-Schroeder public key authentication protocol", Information Processing Letters, 56(3):131--136, November 1995.
[五十] G.洛。“对Needham Schroeder公钥认证协议的攻击”，《信息处理信函》，56（3）：131-136，1995年11月。
[M] Meadows, C., "Analysis of the Internet Key Exchange Protocol using the NRL Protocol Analyser", Proceedings of the 1999 IEEE Symposium on Security & Privacy, Oakland, CA, USA, IEEE Computer Society, May 1999, <http://chacs.nrl.navy.mil/publications/CHACS/1999/ 1999meadows-IEEE99.pdf>.
[M] Meadows，C.，“使用NRL协议分析仪分析互联网密钥交换协议”，1999年IEEE安全与隐私研讨会论文集，美国加利福尼亚州奥克兰，IEEE计算机学会，1999年5月<http://chacs.nrl.navy.mil/publications/CHACS/1999/ 1999meadows-IEEE99.pdf>。
[NS] R. Needham and M. Schroeder. "Using encryption for authentication in large networks of computers", Communications of the ACM, 21(12), December 1978.
[NS]李约瑟和施罗德。“在大型计算机网络中使用加密进行认证”，《ACM通讯》，1978年12月21日（12日）。
[RFC0927] Anderson, B.A., "TACACS user identification Telnet option", RFC 927, December 1984.
[RFC0927]Anderson，B.A.，“TACACS用户识别Telnet选项”，RFC 927，1984年12月。
[RFC1334] Lloyd, B. and B. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992, Obsoleted by RFC 1994.
[RFC1334]Lloyd，B.和B.Simpson，“PPP认证协议”，RFC 13341992年10月，被RFC 1994淘汰。
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993.
[RFC1492]Finseth，C.，“访问控制协议，有时称为TACACS”，RFC 1492，1993年7月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1968] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996.
[RFC1968]Meyer，G.“PPP加密协议（ECP）”，RFC 1968，1996年6月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284]Blunk，L.和J.Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2419] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
[RFC2419]Sklower，K.和G.Meyer，“PPP DES加密协议，第2版（DESE bis）”，RFC 2419，1998年9月。
[RFC2420] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998.
[RFC2420]Hummert，K.，“PPP三重DES加密协议（3DESE）”，RFC2420，1998年9月。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[RFC2433]Zorn，G.和S.Cobb，“微软PPP CHAP扩展”，RFC 2433，1998年10月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]Zorn，G.，“微软特定于供应商的半径属性”，RFC 2548，1999年3月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[RFC2637]Hamzeh，K.，Pall，G.，Verthein，W.，Taarud，J.，Little，W.，和G.Zorn，“点对点隧道协议（PPTP）”，RFC 2637，1999年7月。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716]Aboba，B.和D.Simon，“PPP EAP TLS认证协议”，RFC 2716，1999年10月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759]Zorn，G.，“微软PPP CHAP扩展，第2版”，RFC 2759，2000年1月。
[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月。
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000.
[RFC2881]Mitton，D.和M.Beadles，“网络访问服务器要求下一代（NASREQNG）NAS模型”，RFC 28812000年7月。
[RFC3078] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption (MPPE) Protocol", RFC 3078, March 2001.
[RFC3078]Pall，G.和G.Zorn，“微软点对点加密（MPPE）协议”，RFC 3078，2001年3月。
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)", RFC 3079, March 2001.
[RFC3079]Zorn，G.“导出用于Microsoft点对点加密（MPPE）的密钥”，RFC 3079，2001年3月。
[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月。
[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月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strength for Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[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月。
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Ed.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[SM1] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol", Proceedings of the 5th ACM Conference on Communications and Computer Security, ACM Press, November 1998.
[SM1]Schneier，B.和Mudge，“微软点对点隧道协议的密码分析”，第五届ACM通信和计算机安全会议记录，ACM出版社，1998年11月。
[SM2] Schneier, B. and Mudge, "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)", CQRE 99, Springer-Verlag, 1999, pp. 192-203.
[SM2]Schneier，B.和Mudge，“微软PPTP认证扩展（MS-CHAPv2）的密码分析”，CQRE 99，Springer Verlag，1999，第192-203页。
[SP800-57] National Institute of Standards and Technology, "Recommendation for Key Management", Special Publication 800-57, May 2006.
[SP800-57]国家标准与技术研究所，“密钥管理建议”，特别出版物800-57，2006年5月。
[W] Wu, T., "A Real-World Analysis of Kerberos Password Security", Proceedings of the 1999 ISOC Network and Distributed System Security Symposium, <http://www.isoc.org/isoc/conferences/ndss/99/ proceedings/papers/wu.pdf>.
[W] Wu，T.，“Kerberos密码安全的真实世界分析”，1999年ISOC网络和分布式系统安全研讨会论文集<http://www.isoc.org/isoc/conferences/ndss/99/ 会议记录/论文/wu.pdf>。
Appendix: AAA Key Management History
附录：AAA密钥管理历史记录
Protocols for Authentication, Authorization, and Accounting (AAA) were originally developed to support deployments of Network Access Servers (NASes). In the ARPAnet, the Terminal Access Controller (TAC) provided a means for "dumb terminals" to access the network, and the TACACS [RFC0927][RFC1492] AAA protocol was designed by BBN under contract to the Defense Data Network Program Management Office (DDN PMO) for this environment. [RFC1492] documents a later version of TACACS, not the original version that was widely deployed in ARPAnet and MILNET [DDNN39.2].
身份验证、授权和记帐（AAA）协议最初是为了支持网络访问服务器（NASE）的部署而开发的。在ARPAnet中，终端访问控制器（TAC）为“哑终端”提供了访问网络的手段，并且TACACS[RFC0927][RFC1492]AAA协议由BBN根据与国防数据网络项目管理办公室（DDN PMO）签订的合同为该环境设计。[RFC1492]记录了TACACS的更高版本，而不是在ARPAnet和MILNET[DDNN39.2]中广泛部署的原始版本。
Later, additional AAA protocols were developed to support deployments of NASes providing access to the Internet via PPP [RFC1661]. In deployments supporting more than a modest number of users, it became impractical for each NAS to contain its own list of users and associated credentials. As a result, additional AAA protocols were developed, including RADIUS [RFC2865] and Diameter [RFC3588]. These protocols enabled a central AAA server to authenticate users requesting network access, as well as providing authorization and accounting.
后来，开发了附加的AAA协议，以支持NASE的部署，通过PPP提供对互联网的访问[RFC1661]。在支持数量不多的用户的部署中，每个NAS都不可能包含自己的用户列表和相关凭据。因此，开发了额外的AAA协议，包括RADIUS[RFC2865]和Diameter[RFC3588]。这些协议使中央AAA服务器能够对请求网络访问的用户进行身份验证，并提供授权和记帐。
While PPP [RFC1661] originally supported only PAP [RFC1334] and CHAP [RFC1661] authentication, the limitations of these authentication mechanisms became apparent. For example, both PAP and CHAP are unilateral authentication schemes supporting only authentication of the PPP peer to the NAS. Since PAP is a cleartext password scheme, it is vulnerable to snooping by an attacker with access to the conversation between the PPP peer and NAS. In addition, the use of PAP creates vulnerabilities within RADIUS as described in Section 4.3 of [RFC3579]. As a result, use of PAP is deprecated. While CHAP, a challenge-response scheme based on MD5, offers better security than cleartext passwords, it does not provide for mutual authentication, and CHAP is vulnerable to dictionary attack.
虽然PPP[RFC1661]最初只支持PAP[RFC1334]和CHAP[RFC1661]身份验证，但这些身份验证机制的局限性变得显而易见。例如，PAP和CHAP都是单边身份验证方案，仅支持对NAS的PPP对等方进行身份验证。由于PAP是一种明文密码方案，因此很容易被访问PPP对等方和NAS之间对话的攻击者窥探。此外，PAP的使用在[RFC3579]第4.3节所述的半径范围内产生漏洞。因此，不推荐使用PAP。CHAP是一种基于MD5的质询-响应方案，提供了比明文密码更好的安全性，但它不提供相互身份验证，CHAP容易受到字典攻击。
With the addition of the Encryption Control Protocol (ECP) to PPP [RFC1968] as well as the definition of PPP ciphersuites in [RFC2419], [RFC2420], and [RFC3078], the need arose to provide keying material for use with link layer ciphersuites. As with user authentication, provisioning of static keys on each NAS did not scale well.
随着在PPP[RFC1968]中添加加密控制协议（ECP）以及[RFC2419]、[RFC2420]和[RFC3078]中对PPP密码套件的定义，需要提供用于链路层密码套件的密钥材料。与用户身份验证一样，在每个NAS上提供静态密钥并不能很好地扩展。
Additional vendor-specific PPP authentication protocols such as MS-CHAP [RFC2433] and MS-CHAPv2 [RFC2759] were developed to provide mutual authentication as well as key derivation [RFC3079] for use with negotiated ciphersuites, and they were subsequently adapted for use with PPP-based VPNs [RFC2637]. As with PAP and CHAP, flaws were subsequently found in these new mechanisms [SM1][SM2].
开发了其他特定于供应商的PPP认证协议，如MS-CHAP[RFC2433]和MS-CHAPv2[RFC2759]，以提供相互认证以及密钥派生[RFC3079]，以便与协商密码套件一起使用，并随后对其进行了调整，以用于基于PPP的VPN[RFC2637]。与PAP和CHAP一样，随后在这些新机制中发现了缺陷[SM1][SM2]。
Even though PPP provided for negotiation of authentication algorithms, addressing the vulnerabilities found in authentication mechanisms still proved painful, since new code needed to be deployed on PPP peers as well as on the AAA server. In order to enable more rapid deployment of new authentication mechanisms, as well as fixes for vulnerabilities found in existing methods, the Extensible Authentication Protocol (EAP) [RFC3748] was developed, along with support for centralized authentication via RADIUS/EAP [RFC3579].
尽管PPP提供了认证算法的协商，但解决认证机制中发现的漏洞仍然是一件痛苦的事情，因为新代码需要部署在PPP对等方以及AAA服务器上。为了能够更快速地部署新的身份验证机制，以及修复现有方法中发现的漏洞，开发了可扩展身份验证协议（EAP）[RFC3748]，并支持通过RADIUS/EAP进行集中身份验证[RFC3579]。
By enabling "pass through" authentication on the NAS, EAP enabled deployment of new authentication methods or updates to existing methods by revising code only on the EAP peer and AAA server. The initial authentication mechanisms defined in [RFC2284] (MD5- Challenge, One-Time Password (OTP), and Generic Token Card (GTC)) only supported unilateral authentication, and these mechanisms do not support key derivation. Subsequent authentication methods such as EAP-TLS [RFC2716] supported mutual authentication and key derivation.
通过在NAS上启用“直通”身份验证，EAP仅通过修改EAP对等和AAA服务器上的代码来启用新身份验证方法的部署或对现有方法的更新。[RFC2284]（MD5-质询、一次性密码（OTP）和通用令牌卡（GTC））中定义的初始身份验证机制仅支持单向身份验证，而这些机制不支持密钥派生。后续的认证方法，如EAP-TLS[RFC2716]支持相互认证和密钥派生。
In order to support the provisioning of dynamic keying material for link layer ciphersuites in an environment supporting centralized authentication, a mechanism was needed for the transport of keying material between the AAA server and NAS. Vendor-specific RADIUS attributes were developed for this purpose [RFC2548]. Vulnerabilities were subsequently found in the key wrap technique, as described in Section 4.3 of [RFC3579].
为了支持在支持集中身份验证的环境中为链路层密码套件提供动态密钥材料，需要一种机制在AAA服务器和NAS之间传输密钥材料。为此目的开发了特定于供应商的半径属性[RFC2548]。随后在密钥封装技术中发现漏洞，如[RFC3579]第4.3节所述。
In theory, public key authentication mechanisms such as EAP-TLS are capable of supporting mutual authentication and key derivation between the EAP peer and NAS without requiring AAA key distribution. However, in practice, such pure two-party schemes are rarely deployed. Operation of a centralized AAA server significantly reduces the effort required to deploy certificates to NASes, and even though an AAA server may not be required for key derivation and possibly authentication, its participation is required for service authorization and accounting.
理论上，EAP-TLS等公钥认证机制能够支持EAP对等方和NAS之间的相互认证和密钥派生，而无需AAA密钥分发。然而，在实践中，这种纯粹的两党方案很少被部署。集中式AAA服务器的运行大大减少了将证书部署到NASE所需的工作量，即使密钥派生和可能的身份验证可能不需要AAA服务器，但服务授权和记帐也需要它的参与。
"Pass-through" authentication and AAA key distribution has retained popularity even in the face of rapid improvements in processor and memory capabilities. In addition to producing NAS devices of increased capability for enterprise and carrier customers, implementers have also produced low-cost/high-volume NAS devices such as 802.11 Access Points, causing the resources available on an average NAS to increase more slowly than Moore's law. Despite widespread support for certificate handling and sophisticated key derivation mechanisms such as IKEv1 [RFC2409] within host operating systems, these security capabilities are rarely deployed on low-end NASes and clients.
即使在处理器和内存能力快速提高的情况下，“直通”身份验证和AAA密钥分发仍然很受欢迎。除了为企业和运营商客户生产能力增强的NAS设备外，实施者还生产了低成本/高容量NAS设备，如802.11接入点，导致平均NAS上可用资源的增长速度比摩尔定律慢。尽管在主机操作系统中广泛支持证书处理和复杂的密钥派生机制，如IKEv1[RFC2409]，但这些安全功能很少部署在低端NASE和客户端上。
Even on more capable NASes, such as VPN servers, centralized authentication and AAA key management has proven popular. For example, one of the major limitations of IKEv1 [RFC2409] was the lack of integration with EAP and AAA, requiring proprietary extensions to enable use of IPsec VPNs by organizations deploying password or authentication tokens. These limitations were addressed in IKEv2 [RFC4306], which while handling key derivation solely between the VPN client and server, supports EAP methods for user authentication. In order to enable cryptographic binding of EAP user authentication to keys derived within the IKEv2 exchange, the transport of EAP-derived keys within AAA is required where the selected EAP method supports key derivation.
即使在功能更强大的NASE（如VPN服务器）上，集中式身份验证和AAA密钥管理也很流行。例如，IKEv1[RFC2409]的一个主要限制是缺乏与EAP和AAA的集成，需要专有扩展来支持部署密码或身份验证令牌的组织使用IPsec VPN。IKEv2[RFC4306]解决了这些限制，它只处理VPN客户端和服务器之间的密钥派生，支持用于用户身份验证的EAP方法。为了使EAP用户身份验证能够与IKEv2交换中派生的密钥进行加密绑定，在所选EAP方法支持密钥派生的情况下，需要在AAA中传输EAP派生的密钥。
Acknowledgments
致谢
Many thanks to James Kempf, Sam Hartman, and Joe Salowey for their quality review and encouragement.
非常感谢詹姆斯·坎普夫、山姆·哈特曼和乔·萨洛维对质量的评价和鼓励。
Thanks to the IETF AAA Working Group and the IETF EAP Working Group for their review and comment. The document is greatly improved by their contribution.
感谢IETF AAA工作组和IETF EAP工作组的审查和评论。他们的贡献大大改进了这份文件。
Authors' Addresses
作者地址
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com Phone: +1 703-435-1775 Fax: +1 703-435-1274
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州20170美国电子邮件：housley@vigilsec.com电话：+1703-435-1775传真：+1703-435-1274
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: bernarda@microsoft.com Phone: +1 425-706-6605 Fax: +1 425-936-7329
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond，WA 98052美国电子邮件：bernarda@microsoft.com电话：+1425-706-6605传真：+1425-936-7329
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。