Internet Engineering Task Force (IETF) D. Nelson, Ed.
Request for Comments: 6421 Elbrys Networks, Inc.
Category: Informational November 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Nelson, Ed.
Request for Comments: 6421 Elbrys Networks, Inc.
Category: Informational November 2011
ISSN: 2070-1721
Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)
远程身份验证拨入用户服务（RADIUS）的加密灵活性要求
Abstract
摘要
This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS).
本备忘录描述了远程身份验证拨入用户服务（RADIUS）的加密敏捷解决方案的要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6421.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6421.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
1.1. General ....................................................2
1.2. Requirements Language ......................................3
1.3. Publication Process ........................................3
2. A Working Definition of Crypto-Agility ..........................4
3. The Current State of RADIUS Security ............................5
4. The Requirements ................................................5
4.1. Overall Solution Approach ..................................5
4.2. Security Services ..........................................6
4.3. Backwards Compatibility ....................................7
4.4. Interoperability and Change Control ........................9
4.5. Scope of Work ..............................................9
4.6. Applicability of Automated Key Management Requirements .....9
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................11
1. Introduction ....................................................2
1.1. General ....................................................2
1.2. Requirements Language ......................................3
1.3. Publication Process ........................................3
2. A Working Definition of Crypto-Agility ..........................4
3. The Current State of RADIUS Security ............................5
4. The Requirements ................................................5
4.1. Overall Solution Approach ..................................5
4.2. Security Services ..........................................6
4.3. Backwards Compatibility ....................................7
4.4. Interoperability and Change Control ........................9
4.5. Scope of Work ..............................................9
4.6. Applicability of Automated Key Management Requirements .....9
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................11
At the IETF 66 meeting, the RADIUS Extensions (RADEXT) Working Group (WG) was asked by members of the Security Area Directorate to prepare a formal description of a crypto-agility work item and corresponding charter milestones. After consultation with one of the Security Area Directors (Russ Housley), text was initially proposed on the RADEXT WG mailing list on October 26, 2006. The following summarizes that proposal:
在IETF 66会议上，安全区董事会成员要求RADIUS Extensions（RADEXT）工作组（WG）编写加密敏捷性工作项目和相应的宪章里程碑的正式说明。在与一名安全区域主管（Russ Housley）协商后，文本最初于2006年10月26日在RADEXT工作组邮件列表上提出。以下概述了该建议：
The RADEXT WG will review the security requirements for crypto-agility in IETF protocols, and identify the deficiencies of the existing RADIUS protocol specifications against these requirements. Specific attention will be paid to RFC 4962 [RFC4962].
RADEXT工作组将审查IETF协议中加密灵活性的安全要求，并根据这些要求确定现有RADIUS协议规范的缺陷。将特别注意RFC 4962[RFC4962]。
The RADEXT WG will propose one or more specifications to remediate any identified deficiencies in the crypto-agility properties of the RADIUS protocol. The known deficiencies include the issue of negotiation of substitute algorithms for the message digest functions, the key-wrap functions, and the password-hiding function. Additionally, at least one mandatory to implement cryptographic algorithm will be defined in each of these areas, as required.
RADEXT工作组将提出一个或多个规范，以弥补RADIUS协议加密灵活性属性中的任何已识别缺陷。已知的缺陷包括消息摘要函数、密钥包装函数和密码隐藏函数的替代算法的协商问题。此外，根据需要，将在这些区域中的每个区域中定义至少一个实现加密算法的强制选项。
This document describes the features, properties, and limitations of RADIUS crypto-agility solutions; defines the term "crypto-agility" as used in this context; and provides the motivations for this work.
本文档介绍RADIUS加密敏捷解决方案的特点、特性和局限性；定义本文中使用的术语“加密敏捷性”；并提供了这项工作的动机。
The requirements defined in this memo have been developed based on email messages posted to the RADEXT WG mailing list, which may be found in the archives of that list. The purpose of framing the requirements in this memo is to formalize and archive them for future reference and to bring them explicitly to the attention of the IESG and the IETF community as we proceed with this work.
本备忘录中定义的要求是根据发送到RADEXT WG邮件列表的电子邮件制定的，该邮件列表可在该列表的档案中找到。在本备忘录中制定要求的目的是将其正式化并存档，以备将来参考，并在我们进行此项工作时，明确提请IESG和IETF社区注意。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
A RADIUS crypto-agility solution is not compliant with this specification if it fails to satisfy one or more of the MUST or MUST NOT statements. A solution 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".
如果RADIUS crypto agility解决方案不能满足一个或多个必须或不必须的语句，则该解决方案不符合本规范。满足所有必须、不得、应该和不应该陈述的解决方案被称为“无条件遵从”；满足所有“必须”和“不得”陈述，但并非所有“应该”或“不应该”要求的人被称为“有条件遵从”。
RADIUS [RFC2865] is a widely deployed protocol that has attained Draft Standard status based on multiple independent interoperable implementations. Therefore, it is desirable that a high level of interoperability be maintained for crypto-agility solutions.
RADIUS[RFC2865]是一种广泛部署的协议，基于多个独立的可互操作实现，已达到标准草案状态。因此，需要为加密敏捷性解决方案保持高水平的互操作性。
To ensure that crypto-agility solutions published on the standards track are well specified and interoperable, the RADEXT WG has adopted a two phase process for standards-track publication of crypto-agility solutions.
为了确保在标准轨道上发布的加密敏捷解决方案具有良好的指定性和互操作性，RADEXT WG采用了两阶段流程来发布加密敏捷解决方案的标准轨道。
In the initial phase, crypto-agility solutions adopted by the working group will be published as Experimental. These documents should contain a description of the implementations and experimental deployments in progress as well as an evaluation of the proposal against the requirements described in this document.
在初始阶段，工作组采用的加密敏捷解决方案将作为实验性方案发布。这些文件应包含实施和正在进行的实验性部署的说明，以及根据本文件所述要求对提案进行的评估。
The working group will then select proposals to advance on the standards track. Criteria to be used include evaluation of the proposal against the requirements, summary of the experimental deployment experience, and evidence of multiple interoperable implementations.
然后，工作组将选择在标准轨道上推进的提案。要使用的标准包括根据需求评估提案、总结实验部署经验以及多个可互操作实现的证据。
Crypto-agility is the ability of a protocol to adapt to evolving cryptography and security requirements. This may include the provision of a modular mechanism to allow cryptographic algorithms to be updated without substantial disruption to fielded implementations. It may provide for the dynamic negotiation and installation of cryptographic algorithms within protocol implementations (think of Dynamic-Link Libraries (DLL)).
加密灵活性是协议适应不断发展的加密和安全需求的能力。这可能包括提供模块化机制，以允许在不严重中断现场实施的情况下更新加密算法。它可以提供协议实现中加密算法的动态协商和安装（想想动态链接库（DLL））。
In the specific context of the RADIUS protocol and RADIUS implementations, crypto-agility may be better defined as the ability of RADIUS implementations to automatically negotiate cryptographic algorithms for use in RADIUS exchanges, including the algorithms used to integrity protect and authenticate RADIUS packets and to hide RADIUS attributes. This capability covers all RADIUS message types: Access-Request/Response, Accounting-Request/Response, CoA/Disconnect-Request/Response, and Status-Server. Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer.
在RADIUS协议和RADIUS实现的特定上下文中，加密敏捷性可以更好地定义为RADIUS实现自动协商用于RADIUS交换的加密算法的能力，包括用于完整性保护和认证RADIUS数据包以及隐藏RADIUS属性的算法。此功能涵盖所有RADIUS消息类型：访问请求/响应、记帐请求/响应、CoA/断开连接请求/响应和状态服务器。密码算法的协商可以在RADIUS协议中进行，也可以在较低的层（如传输层）中进行。
Proposals MUST NOT introduce generic new capability negotiation features into the RADIUS protocol or require changes to the RADIUS operational model as defined in "RADIUS Design Guidelines" [RFC6158], Section 3.1 and Appendix A.4. A proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats and SHOULD be compatible with the guidance provided in [RFC6158], Section 2.3. Issues of backward compatibility are described in more detail in Section 4.3.
建议书不得在RADIUS协议中引入通用的新能力协商功能，或要求对“RADIUS设计指南”[RFC6158]，第3.1节和附录A.4中定义的RADIUS运行模型进行更改。提案应该关注加密灵活性问题，而不是其他问题。例如，建议书不应要求新的属性格式，且应符合[RFC6158]第2.3节中提供的指南。第4.3节更详细地描述了向后兼容性问题。
RADIUS packets, as defined in [RFC2865], are protected by an MD5 message integrity check (MIC) within the Authenticator field of RADIUS packets other than Access-Request [RFC2865] and Status-Server [RFC5997]. The Message-Authenticator Attribute utilizes HMAC-MD5 to authenticate and integrity protect RADIUS packets.
[RFC2865]中定义的RADIUS数据包由RADIUS数据包的验证器字段内的MD5消息完整性检查（MIC）保护，访问请求[RFC2865]和状态服务器[RFC5997]除外。消息验证器属性利用HMAC-MD5对RADIUS数据包进行身份验证和完整性保护。
While RADIUS does not support confidentiality of entire packets, various RADIUS attributes support encrypted (also known as "hidden") values, including User-Password (defined in [RFC2865], Section 5.2), Tunnel-Password (defined in [RFC2868], Section 3.5), and various Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes (defined in [RFC2548], Section 2.4). Generally speaking, the hiding mechanism uses a stream cipher based on a key stream from an MD5 digest. Attacks against this mechanism are described in "RADIUS Support for EAP" [RFC3579], Section 4.3.4.
虽然RADIUS不支持整个数据包的保密性，但各种RADIUS属性支持加密（也称为“隐藏”）值，包括用户密码（在[RFC2865]第5.2节中定义）、隧道密码（在[RFC2868]第3.5节中定义）和各种特定于供应商的属性，例如MS MPPE发送密钥和MS MPPE Recv密钥属性（在[RFC2548]第2.4节中定义）。一般来说，隐藏机制使用基于MD5摘要的密钥流的流密码。针对该机制的攻击在第4.3.4节“EAP的RADIUS支持”[RFC3579]中进行了描述。
"Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for use of the MD5 and HMAC-MD5 algorithms. While the advances in MD5 collisions do not immediately compromise the use of MD5 or HMAC-MD5 for the purposes used within RADIUS absent knowledge of the RADIUS shared secret, the progress toward compromise of MD5's basic cryptographic assumptions has resulted in the deprecation of MD5 usage in a variety of applications. As noted in [RFC6151], Section 2:
“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”[RFC6151]讨论了使用MD5和HMAC-MD5算法的安全注意事项。虽然MD5冲突的进展不会立即影响MD5或HMAC-MD5在RADIUS中的使用，但在不了解RADIUS共享机密的情况下，MD5的基本密码假设的进展导致MD5在各种应用中的使用遭到否决。如[RFC6151]第2节所述：
MD5 is no longer acceptable where collision resistance is required such as digital signatures. It is not urgent to stop using MD5 in other ways, such as HMAC-MD5; however, since MD5 must not be used for digital signatures, new protocol designs should not employ HMAC-MD5.
MD5不再适用于需要抗碰撞的情况，如数字签名。停止以其他方式使用MD5并不紧急，例如HMAC-MD5；然而，由于MD5不能用于数字签名，新的协议设计不应使用HMAC-MD5。
RADIUS crypto-agility solutions are not restricted to utilizing technology described in existing RFCs. Since RADIUS over IPsec is already described in Section 5 of "RADIUS and IPv6" [RFC3162] and Section 4.2 of [RFC3579], this technique is already available to those who wish to use it. Therefore, it is expected that proposals will utilize other techniques.
RADIUS加密敏捷解决方案不限于利用现有RFC中描述的技术。由于“RADIUS和IPv6”[RFC3162]第5节和[RFC3579]第4.2节中已经描述了IPsec上的RADIUS，因此希望使用该技术的人可以使用该技术。因此，预计提案将利用其他技术。
Proposals MUST support the negotiation of cryptographic algorithms for per-packet integrity/authentication protection. Proposals also MUST support per-packet replay protection for all RADIUS message types. Crypto-agility solutions MUST specify mandatory-to-implement cryptographic algorithms for each defined mechanism.
提案必须支持每包完整性/认证保护的加密算法协商。提案还必须支持所有RADIUS消息类型的每包重播保护。Crypto agility解决方案必须指定强制为每个定义的机制实现加密算法。
Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g., in the event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding-down attacks. In analyzing the resilience of a crypto-agility solution, it can be assumed that RADIUS requesters and responders can be configured to require the use of new secure algorithms in the event of a compromise of existing cryptographic algorithms or the legacy RADIUS shared secret.
加密敏捷性解决方案必须避免安全性泄露，即使在RADIUS实施所使用的现有加密算法被证明足够弱，无法提供很少或没有安全性的情况下（例如，在传统RADIUS共享秘密泄露的情况下）。这将包括防止出价下降攻击。在分析加密敏捷性解决方案的弹性时，可以假设RADIUS请求者和响应者可以配置为在现有加密算法或遗留RADIUS共享机密受到破坏的情况下要求使用新的安全算法。
Guidance on acceptable algorithms can be found in [NIST-SP800-131A]. It is RECOMMENDED that mandatory-to-implement cryptographic algorithms be chosen from among those classified as "Acceptable" with no known deprecation date from within this or successor documents.
有关可接受算法的指南，请参见[NIST-SP800-131A]。建议从本文件或后续文件中归类为“可接受”且无已知弃用日期的文件中选择强制实施加密算法。
It is RECOMMENDED that solutions provide support for confidentiality, either by supporting encryption of entire RADIUS packets or by encrypting individual RADIUS attributes. Proposals supporting confidentiality MUST support the negotiation of cryptographic algorithms for encryption.
建议解决方案通过支持整个RADIUS数据包的加密或通过加密单个RADIUS属性来提供机密性支持。支持保密性的提案必须支持加密算法的协商。
Support for encryption of individual RADIUS attributes is OPTIONAL for solutions that provide encryption of entire RADIUS packets. Solutions providing for encryption of individual RADIUS attributes are REQUIRED to provide support for improving the confidentiality of existing encrypted (sometimes referred to as "hidden") attributes as well as encrypting attributes (such as location attributes) that are currently transmitted in cleartext.
对于提供整个RADIUS数据包加密的解决方案，对单个RADIUS属性的加密支持是可选的。提供单个RADIUS属性加密的解决方案需要提供支持，以提高现有加密（有时称为“隐藏”）属性以及当前以明文传输的加密属性（例如位置属性）的机密性。
In addition to the goals referred to above, [RFC4962] Section 3 describes additional security requirements, which translate into the following requirements for RADIUS crypto-agility solutions:
除上述目标外，[RFC4962]第3节描述了其他安全要求，这些要求转化为RADIUS加密敏捷性解决方案的以下要求：
Strong, fresh session keys:
强、新会话密钥：
RADIUS crypto-agility solutions are REQUIRED to generate fresh session keys for use between the RADIUS client and server. In order to prevent the disclosure of one session key from aiding an attacker in discovering other session keys, RADIUS crypto-agility
RADIUS crypto agility解决方案需要生成新的会话密钥，以便在RADIUS客户端和服务器之间使用。为了防止一个会话密钥的泄露帮助攻击者发现其他会话密钥，RADIUS crypto agility
solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS) with respect to session keys negotiated between the RADIUS client and server.
建议使用解决方案来支持RADIUS客户端和服务器之间协商的会话密钥的完美前向保密（PFS）。
Limit key scope:
限制关键范围：
In order to enable a Network Access Server (NAS) and RADIUS server to exchange confidential information such as keying material without disclosure to third parties, it is RECOMMENDED that a RADIUS crypto-agility solution support X.509 certificates for authentication between the NAS and RADIUS server. Manual configuration or automated discovery mechanisms such as NAI-based Dynamic Peer Discovery [RADYN] can be used to enable direct NAS-RADIUS server communications. Support for end-to-end confidentiality of RADIUS attributes is OPTIONAL.
为了使网络访问服务器（NAS）和RADIUS服务器能够在不向第三方披露的情况下交换密钥材料等机密信息，建议RADIUS crypto agility解决方案支持X.509证书，用于NAS和RADIUS服务器之间的身份验证。手动配置或自动发现机制（如基于NAI的动态对等发现[RADYN]）可用于实现直接NAS-RADIUS服务器通信。支持RADIUS属性的端到端机密性是可选的。
For compatibility with existing operations, RADIUS crypto-agility solutions SHOULD also support pre-shared key credentials. However, support for direct communications between the NAS and RADIUS server is OPTIONAL when pre-shared key credentials are used.
为了与现有操作兼容，RADIUS crypto agility解决方案还应支持预共享密钥凭据。但是，在使用预共享密钥凭据时，支持NAS和RADIUS服务器之间的直接通信是可选的。
Solutions MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both crypto-agility and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms).
解决方案必须证明与现有RADIUS实现的向后兼容性。也就是说，同时支持加密敏捷性和遗留机制的实现必须能够与遗留RADIUS客户端和服务器进行通信（使用遗留机制）。
While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy mechanisms have been compromised, secure algorithms MUST be used so that backward compatibility is no longer possible.
虽然需要向后兼容来简化遗留RADIUS和加密敏捷RADIUS之间的转换，但只有在这些机制妥协之前，才适合使用遗留机制。在遗留机制被破坏后，必须使用安全算法，以便不再可能向后兼容。
Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within a single RADIUS exchange is inherently limited. Prior to receipt of a response, a requester will not know what algorithms are supported by the responder. Therefore, while a RADIUS request can provide a list of supported cryptographic algorithms that can be selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within an initial request will need to be predetermined.
由于RADIUS是一种请求/响应协议，因此在单个RADIUS交换中协商加密算法的能力本质上是有限的。在收到响应之前，请求者将不知道响应者支持哪些算法。因此，尽管RADIUS请求可以提供可选择用于响应中的受支持密码算法的列表，但在接收响应之前，用于在初始请求中提供安全服务的密码算法将需要预先确定。
In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms was well as with attributes providing security services
为了使请求能够由遗留的和加密敏捷的实现来处理，可以使用遗留算法以及提供安全服务的属性来保护请求
using more secure algorithms. This approach allows a RADIUS packet to be processed by legacy implementations as well as by crypto-agile implementations, and it does not result in additional response delays. If this technique is used, credentials used with legacy algorithms MUST be cryptographically independent of the credentials used with the more secure algorithms, so that compromise of the legacy credentials does not result in compromise of the credentials used with more secure algorithms.
使用更安全的算法。这种方法允许传统实现和加密敏捷实现处理RADIUS数据包，并且不会导致额外的响应延迟。如果使用此技术，则与遗留算法一起使用的凭据必须在加密方面独立于与更安全的算法一起使用的凭据，以便遗留凭据的泄露不会导致与更安全的算法一起使用的凭据的泄露。
In this approach to backward compatibility, legacy mechanisms are initially used in requests sent between crypto-agile implementations. However, if the responder indicates support for crypto-agility, future requests can use more secure mechanisms. Note that if a responder is upgraded and then subsequently needs to be downgraded (e.g., due to bugs), this could result in requesters being unable to communicate with the downgraded responder unless a mechanism is provided to configure the requester to re-enable use of legacy algorithms.
在这种向后兼容的方法中，遗留机制最初用于加密敏捷实现之间发送的请求。但是，如果响应者表示支持加密灵活性，则未来的请求可以使用更安全的机制。请注意，如果响应者升级，然后需要降级（例如，由于bug），这可能导致请求者无法与降级的响应者通信，除非提供了一种机制来配置请求者以重新启用遗留算法。
Probing techniques can be used to avoid the use of legacy algorithms in requests sent between crypto-agile implementations. For example, an initial request can omit use of legacy mechanisms. If a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure mechanisms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy mechanisms in future requests. Note that if a requester is upgraded and then subsequently needs to be downgraded (e.g., due to bugs), this could result in the requester being unable to interpret responses, unless a mechanism is provided to configure the responder to re-enable use of legacy algorithms.
探测技术可用于避免在加密敏捷实现之间发送的请求中使用遗留算法。例如，初始请求可以省略遗留机制的使用。如果收到响应，则可以假定收件人是加密敏捷的，并且将来对该收件人的请求可以利用安全机制。类似地，响应者可以假设请求者支持加密灵活性，并且可以禁止在将来的请求中使用遗留机制。请注意，如果请求者升级后需要降级（例如，由于bug），这可能导致请求者无法解释响应，除非提供了一种机制来配置响应者以重新启用遗留算法。
If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre-configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy mechanisms.
如果没有收到响应，在没有指示响应者支持加密敏捷性的信息（例如预配置或之前收到加密敏捷响应）的情况下，可以利用遗留机制组合新请求。
Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests can be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. Therefore, probing techniques can delay initial communication between crypto-agile requesters and legacy responders. This can be addressed by upgrading the responders (e.g., RADIUS servers) first.
由于不支持加密敏捷性的旧式实现将悄悄地丢弃不受旧式算法保护的请求，而不是返回错误，因此可能需要重复请求来区分不支持加密敏捷性与数据包丢失或其他故障情况。因此，探测技术可以延迟加密敏捷请求者和遗留响应者之间的初始通信。这可以通过首先升级响应程序（例如RADIUS服务器）来解决。
Proposals MUST indicate a willingness to cede change control to the IETF.
提案必须表明愿意将变更控制权移交给IETF。
Crypto-agility solutions MUST be interoperable between independent implementations based purely on the information provided in the specification.
加密敏捷性解决方案必须完全基于规范中提供的信息在独立实现之间进行互操作。
Crypto-agility solutions MUST apply to all RADIUS packet types, including Access-Request, Access-Challenge, Access-Reject, Access-Accept, Accounting-Request, Accounting-Response, Status-Server and CoA/Disconnect messages.
加密敏捷性解决方案必须适用于所有RADIUS数据包类型，包括访问请求、访问质询、访问拒绝、访问接受、记帐请求、记帐响应、状态服务器和CoA/断开连接消息。
Since it is expected that the work will occur purely within RADIUS or in the transport, message data exchanged with Diameter SHOULD NOT be affected.
由于预计工作将纯粹发生在半径范围内或传输中，因此使用直径交换的消息数据不应受到影响。
Proposals MUST discuss any inherent assumptions about, or limitations on, client/server operations or deployment and SHOULD provide recommendations for transition of deployments from legacy RADIUS to crypto-agile RADIUS. Issues regarding cipher-suite negotiation, legacy interoperability, and the potential for bidding-down attacks SHOULD be among these discussions.
提案必须讨论关于客户机/服务器操作或部署的任何固有假设或限制，并应提供从传统RADIUS到加密敏捷RADIUS部署过渡的建议。有关密码套件协商、遗留互操作性以及降低攻击的可能性的问题应该在这些讨论中讨论。
"Guidelines for Cryptographic Key Management" [RFC4107] provides guidelines for when automated key management is necessary. Consideration was given as to whether or not RFC 4107 would require a RADIUS crypto-agility solution to feature Automated Key Management (AKM). It was determined that AKM was not inherently required for RADIUS based on the following points:
“加密密钥管理指南”[RFC4107]提供了何时需要自动密钥管理的指南。考虑了RFC 4107是否需要RADIUS加密敏捷解决方案来实现自动密钥管理（AKM）。根据以下几点，确定AKM不是半径的固有要求：
o RFC 4107 requires AKM for protocols that involve O(n^2) keys. This does not apply to RADIUS deployments, which require O(n) keys.
o RFC 4107要求涉及O（n^2）密钥的协议使用AKM。这不适用于需要O（n）键的RADIUS部署。
o Requirements for session key freshness can be met without AKM, for example, by utilizing a pre-shared key along with an exchange of nonces.
o 在没有AKM的情况下，可以满足会话密钥新鲜度的要求，例如，通过使用预先共享的密钥以及nonce的交换。
o RADIUS does not require the encryption of large amounts of data in a short time.
o RADIUS不需要在短时间内对大量数据进行加密。
o Organizations already have operational practices to manage existing RADIUS shared secrets to address key changes required as a result of personnel changes.
o 组织已经有了管理现有RADIUS共享机密的操作实践，以解决人事变动所需的关键变更。
o The crypto-agility solution can avoid the use of cryptographic modes of operation, such as a counter mode cipher, that require frequent key changes.
o crypto agility解决方案可以避免使用需要频繁更改密钥的加密操作模式，例如计数器模式密码。
However, at the same time, it is recognized that features recommended in Section 4.2 such as support for perfect forward secrecy and direct transport of keys between a NAS and RADIUS server can only be provided by a solution supporting AKM. As a result, support for Automated Key Management is RECOMMENDED within a RADIUS crypto-agility solution.
但是，同时，人们认识到，第4.2节中推荐的功能，如支持完美的前向保密性和NAS与RADIUS服务器之间的密钥直接传输，只能由支持AKM的解决方案提供。因此，建议在RADIUS加密敏捷解决方案中支持自动密钥管理。
Also, automated key management is REQUIRED for RADIUS crypto-agility solutions that use cryptographic modes of operation that require frequent key changes.
此外，RADIUS crypto agility解决方案需要自动密钥管理，该解决方案使用需要频繁更改密钥的加密操作模式。
Potential attacks against the RADIUS protocol are described in [RFC3579], Section 4.1, and details of known exploits as well as potential mitigations are discussed in [RFC3579], Section 4.3.
[RFC3579]第4.1节描述了针对RADIUS协议的潜在攻击，而已知漏洞的详细信息以及潜在的缓解措施在[RFC3579]第4.3节中进行了讨论。
This specification describes the requirements for new cryptographic protection mechanisms, including the modular selection of algorithms and modes. Therefore, all the subject matter of this memo is related to security.
本规范描述了新密码保护机制的要求，包括算法和模式的模块化选择。因此，本备忘录的所有主题均与安全相关。
Thanks to all the reviewers and contributors, including Bernard Aboba, Mary Barnes, Pasi Eronen, Dan Romascanu, Joe Salowey, and Glen Zorn.
感谢所有的评论者和贡献者，包括伯纳德·阿博巴、玛丽·巴恩斯、帕西·埃隆、丹·罗马斯坎努、乔·萨洛维和格伦·佐恩。
[NIST-SP800-131A] Barker, E. and A. Roginsky, "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths", NIST SP-800-131A, January 2011.
[NIST-SP800-131A]Barker，E.和A.Roginsky，“转换：密码算法和密钥长度使用的转换建议”，NIST SP-800-131A，2011年1月。
[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月。
[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月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[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月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月。
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011.
[RFC6158]DeKok，A.，Ed.，和G.Weber，“半径设计指南”，BCP 158，RFC 6158，2011年3月。
[RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS", Work in Progress, July 2011.
[RADYN]Winter，S.和M.McCauley，“基于NAI的RADIUS/TLS和RADIUS/DTL动态对等发现”，正在进行的工作，2011年7月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]Zorn，G.，“微软特定于供应商的半径属性”，RFC 2548，1999年3月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.，和I.Goyret，“隧道协议支持的半径属性”，RFC 28682000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC 3162，2001年8月。
[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月。
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, August 2010.
[RFC5997]DeKok，A.，“远程身份验证拨入用户服务（RADIUS）协议中状态服务器数据包的使用”，RFC 5997，2010年8月。
Author's Address
作者地址
David B. Nelson (editor) Elbrys Networks, Inc. 282 Corporate Drive, Unit 1 Portsmouth, NH 03801 USA
David B.Nelson（编辑）Elbrys Networks，Inc.美国新罕布什尔州朴茨茅斯市企业大道282号1单元03801
EMail: d.b.nelson@comcast.net
EMail: d.b.nelson@comcast.net