Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 7360 FreeRADIUS
Category: Experimental September 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 7360 FreeRADIUS
Category: Experimental September 2014
ISSN: 2070-1721
Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS
数据报传输层安全性（DTLS）作为RADIUS的传输层
Abstract
摘要
The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems.
RFC 2865中定义的RADIUS协议对RADIUS数据包的身份验证和加密支持有限。该协议以明文形式传输数据，尽管数据包的某些部分可能具有模糊的内容。攻击者可能会逐字重播数据包，并且客户端-服务器身份验证基于固定的共享机密。本文档规定了如何使用数据报传输层安全（DTLS）协议解决这些问题。它还描述了该方案的实现如何与当前的RADIUS系统共存。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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/rfc7360.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7360.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
1.3. Document Status ............................................5
2. Building on Existing Foundations ................................6
2.1. Changes to RADIUS ..........................................7
2.2. Similarities with RADIUS/TLS ...............................8
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ..............8
3. Interaction with RADIUS/UDP .....................................9
3.1. DTLS Port and Packet Types ................................10
3.2. Server Behavior ...........................................10
4. Client Behavior ................................................11
5. Session Management .............................................12
5.1. Server Session Management .................................12
5.1.1. Session Opening and Closing ........................13
5.2. Client Session Management .................................15
6. Implementation Guidelines ......................................16
6.1. Client Implementations ....................................17
6.2. Server Implementations ....................................18
7. Diameter Considerations ........................................18
8. IANA Considerations ............................................18
9. Implementation Status ..........................................18
9.1. Radsecproxy ...............................................19
9.2. jradius ...................................................19
10. Security Considerations .......................................19
10.1. Crypto-Agility ...........................................20
10.2. Legacy RADIUS Security ...................................21
10.3. Resource Exhaustion ......................................22
10.4. Client-Server Authentication with DTLS ...................22
10.5. Network Address Translation ..............................24
10.6. Wildcard Clients .........................................24
10.7. Session Closing ..........................................25
10.8. Client Subsystems ........................................25
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................27
Acknowledgments ...................................................27
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
1.3. Document Status ............................................5
2. Building on Existing Foundations ................................6
2.1. Changes to RADIUS ..........................................7
2.2. Similarities with RADIUS/TLS ...............................8
2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ..............8
3. Interaction with RADIUS/UDP .....................................9
3.1. DTLS Port and Packet Types ................................10
3.2. Server Behavior ...........................................10
4. Client Behavior ................................................11
5. Session Management .............................................12
5.1. Server Session Management .................................12
5.1.1. Session Opening and Closing ........................13
5.2. Client Session Management .................................15
6. Implementation Guidelines ......................................16
6.1. Client Implementations ....................................17
6.2. Server Implementations ....................................18
7. Diameter Considerations ........................................18
8. IANA Considerations ............................................18
9. Implementation Status ..........................................18
9.1. Radsecproxy ...............................................19
9.2. jradius ...................................................19
10. Security Considerations .......................................19
10.1. Crypto-Agility ...........................................20
10.2. Legacy RADIUS Security ...................................21
10.3. Resource Exhaustion ......................................22
10.4. Client-Server Authentication with DTLS ...................22
10.5. Network Address Translation ..............................24
10.6. Wildcard Clients .........................................24
10.7. Session Closing ..........................................25
10.8. Client Subsystems ........................................25
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................27
Acknowledgments ...................................................27
The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176], and others has traditionally used methods based on MD5 [RFC1321] for per-packet authentication and integrity checks. However, the MD5 algorithm has known weaknesses such as [MD5Attack] and [MD5Break]. As a result, some specifications, such as [RFC5176], have recommended using IPsec to secure RADIUS traffic.
[RFC2865]、[RFC2866]、[RFC5176]等中所述的RADIUS协议传统上使用基于MD5[RFC1321]的方法进行每包身份验证和完整性检查。然而，MD5算法存在已知的弱点，如[MD5Attack]和[MD5Break]。因此，一些规范（如[RFC5176]）建议使用IPsec来保护RADIUS通信。
While RADIUS over IPsec has been widely deployed, there are difficulties with this approach. The simplest point against IPsec is that there is no straightforward way for an application to control or monitor the network security policies. That is, the requirement that the RADIUS traffic be encrypted and/or authenticated is implicit in the network configuration, and it cannot be enforced by the RADIUS application.
虽然IPsec上的RADIUS已被广泛部署，但这种方法存在一些困难。针对IPsec最简单的一点是，应用程序无法直接控制或监视网络安全策略。也就是说，对RADIUS流量进行加密和/或身份验证的要求在网络配置中是隐含的，RADIUS应用程序无法强制执行该要求。
This specification takes a different approach. We define a method for using DTLS [RFC6347] as a RADIUS transport protocol. This approach has the benefit that the RADIUS application can directly monitor and control the security policies associated with the traffic that it processes.
本规范采用不同的方法。我们定义了一种使用DTLS[RFC6347]作为RADIUS传输协议的方法。这种方法的好处是RADIUS应用程序可以直接监视和控制与其处理的流量相关联的安全策略。
Another benefit is that RADIUS over DTLS continues to be a UDP-based protocol. The change from RADIUS/UDP is largely to add DTLS support, and make any necessary related changes to RADIUS. This allows implementations to remain UDP based, without changing to a TCP architecture.
另一个好处是，RADIUS over DTLS仍然是基于UDP的协议。RADIUS/UDP的更改主要是添加DTLS支持，并对RADIUS进行任何必要的相关更改。这允许实现保持基于UDP，而不改变TCP体系结构。
This specification does not, however, solve all of the problems associated with RADIUS/UDP. The DTLS protocol does not add reliable or in-order transport to RADIUS. DTLS also does not support fragmentation of application-layer messages, or of the DTLS messages themselves. This specification therefore shares with traditional RADIUS the issues of order, reliability, and fragmentation. These issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS [RFC6614].
但是，本规范并不能解决与RADIUS/UDP相关的所有问题。DTLS协议不向RADIUS添加可靠或有序传输。DTLS也不支持应用层消息或DTLS消息本身的分段。因此，本规范与传统RADIUS一样存在顺序、可靠性和碎片问题。这些问题在RADIUS/TCP[RFC6613]和RADIUS/TLS[RFC6614]中讨论。
This document uses the following terms:
本文件使用以下术语：
RADIUS/DTLS This term is a shorthand for "RADIUS over DTLS".
RADIUS/DTLS这个术语是“DTLS上的RADIUS”的缩写。
RADIUS/DTLS client This term refers both to RADIUS clients as defined in [RFC2865] and to Dynamic Authorization clients as defined in [RFC5176] that implement RADIUS/DTLS.
RADIUS/DTLS客户端该术语指[RFC2865]中定义的RADIUS客户端和[RFC5176]中定义的实现RADIUS/DTLS的动态授权客户端。
RADIUS/DTLS server This term refers both to RADIUS servers as defined in [RFC2865] and to Dynamic Authorization servers as defined in [RFC5176] that implement RADIUS/DTLS.
RADIUS/DTLS服务器该术语既指[RFC2865]中定义的RADIUS服务器，也指[RFC5176]中定义的实现RADIUS/DTLS的动态授权服务器。
RADIUS/UDP RADIUS over UDP, as defined in [RFC2865].
[RFC2865]中定义的UDP上的RADIUS/UDP RADIUS。
RADIUS/TLS RADIUS over TLS, as defined in [RFC6614].
半径/TLS根据[RFC6614]中的定义，在TLS上的半径。
silently discard This means that the implementation discards the packet without further processing.
静默丢弃这意味着实现在不进行进一步处理的情况下丢弃数据包。
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
在本文件中，使用了几个词来表示规范的要求。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This document is an Experimental RFC.
本文档是一个实验性RFC。
It contains one of several approaches to address known cryptographic weaknesses of the RADIUS protocol, such as described in [RFC6614]. This specification does not fulfill all recommendations for an Authentication, Authorization, and Accounting (AAA) transport profile as per [RFC3539]; however, unlike [RFC6614], it is based on UDP and therefore does not have head-of-line blocking issues.
它包含几种解决RADIUS协议已知密码弱点的方法之一，如[RFC6614]中所述。根据[RFC3539]，本规范不满足认证、授权和计费（AAA）传输配置文件的所有建议；但是，与[RFC6614]不同，它基于UDP，因此不存在线路头阻塞问题。
If this specification is indeed selected for advancement to Standards Track, certificate verification options ([RFC6614], Section 2.3, point 2) will need to be refined.
如果选择本规范确实是为了推进标准跟踪，则需要改进证书验证选项（[RFC6614]，第2.3节，第2点）。
Another experimental characteristic of this specification is the question of key management between RADIUS/DTLS peers. RADIUS/UDP only allowed for manual key management, i.e., distribution of a shared secret between a client and a server. RADIUS/DTLS allows manual distribution of long-term proofs of peer identity, by using TLS-PSK ciphersuites. RADIUS/DTLS also allows the use of X.509 certificates in a PKIX infrastructure. It remains to be seen if one of these methods will prevail or if both will find their place in real-life deployments. The authors can imagine pre-shared keys (PSKs) to be popular in small-scale deployments (Small Office, Home Office (SOHO) or isolated enterprise deployments) where scalability is not an issue and the deployment of a Certification Authority (CA) is considered too much of a hassle; however, the authors can also imagine large roaming consortia to make use of PKIX. Readers of this specification are encouraged to read the discussion of key management issues within [RFC6421] as well as [RFC4107].
该规范的另一个实验特性是RADIUS/DTLS对等方之间的密钥管理问题。RADIUS/UDP仅允许手动密钥管理，即在客户端和服务器之间分发共享密钥。RADIUS/DTLS允许使用TLS-PSK密码套件手动分发对等身份的长期证明。RADIUS/DTLS还允许在PKIX基础设施中使用X.509证书。这些方法中是否有一种会占上风，或者两者是否都能在实际部署中找到一席之地，还有待观察。作者可以想象，预共享密钥（PSK）在小规模部署（小型办公室、家庭办公室（SOHO）或独立企业部署）中很流行，在这些部署中，可伸缩性不是一个问题，并且证书颁发机构（CA）的部署被认为是一件非常麻烦的事情；然而，作者也可以想象大型漫游联盟使用PKIX。鼓励本规范的读者阅读[RFC6421]和[RFC4107]中对关键管理问题的讨论。
It has yet to be decided whether this approach is to be chosen for Standards Track. One key aspect to judge whether the approach is usable on a large scale is by observing the uptake, usability, and operational behavior of the protocol in large-scale, real-life deployments.
尚未决定是否将此方法用于标准跟踪。判断方法是否在大规模上可用的一个关键方面是通过观察协议在大规模实际部署中的使用、可用性和操作行为。
Adding DTLS as a RADIUS transport protocol requires a number of changes to systems implementing standard RADIUS. This section outlines those changes, and defines new behaviors necessary to implement DTLS.
将DTLS添加为RADIUS传输协议需要对实现标准RADIUS的系统进行大量更改。本节概述了这些更改，并定义了实现DTL所需的新行为。
The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and [RFC5176]. Specifically, all of the following portions of RADIUS MUST be unchanged when using RADIUS/DTLS:
RADIUS数据包格式与[RFC2865]、[RFC2866]和[RFC5176]的格式相同。具体而言，使用RADIUS/DTL时，RADIUS的以下所有部分必须保持不变：
* Packet format * Permitted codes * Request Authenticator calculation * Response Authenticator calculation * Minimum packet length * Maximum packet length * Attribute format * Vendor-Specific Attribute (VSA) format * Permitted data types * Calculations of dynamic attributes such as CHAP-Challenge, or Message-Authenticator. * Calculation of "obfuscated" attributes such as User-Password and Tunnel-Password.
* 数据包格式*允许的代码*请求验证器计算*响应验证器计算*最小数据包长度*最大数据包长度*属性格式*供应商特定属性（VSA）格式*允许的数据类型*动态属性（如CHAP质询或消息验证器）的计算。*计算“模糊”属性，如用户密码和隧道密码。
In short, the application creates a RADIUS packet via the usual methods, and then instead of sending it over a UDP socket, sends the packet to a DTLS layer for encapsulation. DTLS then acts as a transport layer for RADIUS: hence, the names "RADIUS/UDP" and "RADIUS/DTLS".
简而言之，应用程序通过常用方法创建RADIUS数据包，然后将数据包发送到DTLS层进行封装，而不是通过UDP套接字发送数据包。然后，DTLS充当RADIUS的传输层：因此，命名为“RADIUS/UDP”和“RADIUS/DTLS”。
The requirement that RADIUS remain largely unchanged ensures the simplest possible implementation and widest interoperability of this specification.
RADIUS基本保持不变的要求确保了本规范最简单的实现和最广泛的互操作性。
We note that the DTLS encapsulation of RADIUS means that RADIUS packets have an additional overhead due to DTLS. Implementations MUST support sending and receiving encapsulated RADIUS packets of 4096 octets in length, with a corresponding increase in the maximum size of the encapsulated DTLS packets. This larger packet size may cause the packet to be larger than the Path MTU (PMTU), where a RADIUS/UDP packet may be smaller. See Section 5.2, below, for more discussion.
我们注意到，RADIUS的DTLS封装意味着RADIUS数据包由于DTLS而具有额外的开销。实现必须支持发送和接收长度为4096个八位字节的封装RADIUS数据包，并相应增加封装DTLS数据包的最大大小。此较大的分组大小可能导致分组大于路径MTU（PMTU），其中RADIUS/UDP分组可能更小。更多讨论见下文第5.2节。
The only changes made from RADIUS/UDP to RADIUS/DTLS are the following two items:
从RADIUS/UDP到RADIUS/DTLS的唯一更改是以下两项：
(1) The Length checks defined in [RFC2865], Section 3, MUST use the length of the decrypted DTLS data instead of the UDP packet length. They MUST treat any decrypted DTLS data octets outside the range of the Length field as padding and ignore it on reception.
(1) [RFC2865]第3节中定义的长度检查必须使用解密DTLS数据的长度，而不是UDP数据包的长度。他们必须将长度字段范围之外的任何解密DTLS数据八位字节视为填充，并在接收时忽略它。
(2) The shared secret used to compute the MD5 integrity checks and the attribute encryption MUST be "radius/dtls".
(2) 用于计算MD5完整性检查和属性加密的共享机密必须是“radius/dtls”。
All other aspects of RADIUS are unchanged.
半径的所有其他方面不变。
While this specification can be thought of as RADIUS/TLS over UDP instead of the Transmission Control Protocol (TCP), there are some differences between the two methods. The bulk of [RFC6614] applies to this specification, so we do not repeat it here.
虽然可以将此规范视为UDP上的RADIUS/TLS，而不是传输控制协议（TCP），但这两种方法之间存在一些差异。[RFC6614]的大部分内容适用于本规范，因此在此不再重复。
This section explains the differences between RADIUS/TLS and RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as follows:
本节解释RADIUS/TLS和RADIUS/DTL之间的区别，作为[RFC6614]的语义“补丁”。更改如下:
* We replace references to "TCP" with "UDP"
* 我们将对“TCP”的引用替换为“UDP”
* We replace references to "RADIUS/TLS" with "RADIUS/DTLS"
* 我们将“RADIUS/TLS”替换为“RADIUS/DTL”
* We replace references to "TLS" with "DTLS"
* 我们将对“TLS”的引用替换为“DTL”
Those changes are sufficient to cover the majority of the differences between the two specifications. The next section reviews some more detailed changes from [RFC6614], giving additional commentary only where necessary.
这些更改足以覆盖两个规范之间的大部分差异。下一节将回顾[RFC6614]的一些更详细的更改，仅在必要时提供附加注释。
This section describes how particular sections of [RFC6614] apply to RADIUS/DTLS.
本节介绍[RFC6614]的特定章节如何应用于RADIUS/DTL。
Section 2.1 applies to RADIUS/DTLS, with the exception that the RADIUS/DTLS port is UDP/2083.
第2.1节适用于RADIUS/DTLS，RADIUS/DTLS端口为UDP/2083除外。
Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be pre-configured to use RADIUS/DTLS for a given endpoint.
第2.2节适用于RADIUS/DTL。服务器和客户端需要预先配置，以便为给定端点使用RADIUS/DTL。
Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be interpreted as applying to DTLS session initiation, instead of TCP connection establishment. Item (2) applies, except for the recommendation that implementations "SHOULD" support TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical artifact of RADIUS/TLS, and it does not apply to RADIUS/DTLS. Item (3) applies to RADIUS/DTLS. Item (4) applies, except that the fixed shared secret is "radius/dtls", as described above.
第2.3节的大部分内容也适用于RADIUS/DTL。第（1）项应解释为适用于DTLS会话启动，而不是TCP连接建立。第（2）项适用，但建议实施“应”支持TLS_RSA_和_RC4_128_SHA。此建议是RADIUS/TLS的历史产物，不适用于RADIUS/DTL。第（3）项适用于RADIUS/DTL。第（4）项适用，但如上所述，固定共享秘密为“radius/dtls”。
Section 2.4 applies to RADIUS/DTLS. Client identities SHOULD be determined from DTLS parameters, instead of relying solely on the source IP address of the packet.
第2.4节适用于RADIUS/DTL。客户端身份应该根据DTLS参数确定，而不是仅仅依赖于数据包的源IP地址。
Section 2.5 does not apply to RADIUS/DTLS. The relationship between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from RADIUS/UDP.
第2.5节不适用于RADIUS/DTL。RADIUS/DTLS中RADIUS数据包代码和UDP端口之间的关系与RADIUS/UDP的关系相同。
Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS.
第3.1、3.2和3.3节适用于RADIUS/DTL。
Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS packet is encapsulated in one DTLS packet, and there is no "stream" of RADIUS packets inside of a TLS session. Implementors MUST enforce the requirements of [RFC2865], Section 3, for the RADIUS Length field, using the length of the decrypted DTLS data for the checks. This check replaces the RADIUS method of using the Length field from the UDP packet.
第3.4节第（1）项不适用于RADIUS/DTL。每个RADIUS数据包封装在一个DTLS数据包中，TLS会话中没有RADIUS数据包的“流”。实施者必须执行[RFC2865]第3节对半径长度字段的要求，使用解密DTLS数据的长度进行检查。此检查将替换使用UDP数据包中长度字段的RADIUS方法。
Section 3.4 items (2), (3), (4), and (5) apply to RADIUS/DTLS.
第3.4节第（2）、（3）、（4）和（5）项适用于RADIUS/DTL。
Section 4 does not apply to RADIUS/DTLS. Protocol compatibility considerations are defined in this document.
第4节不适用于RADIUS/DTL。本文档中定义了协议兼容性注意事项。
Section 6 applies to RADIUS/DTLS.
第6节适用于RADIUS/DTL。
Transitioning to DTLS is a process that needs to be done carefully. A poorly handled transition is complex for administrators and potentially subject to security downgrade attacks. It is not sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. RADIUS has no provisions for protocol negotiation, so simply disabling RADIUS/UDP would result in timeouts, lost traffic, and network instabilities.
转换到DTLS是一个需要小心完成的过程。处理不当的转换对于管理员来说是复杂的，并且可能受到安全降级攻击。仅禁用RADIUS/UDP和启用RADIUS/DTL是不够的。RADIUS没有协议协商的规定，因此简单地禁用RADIUS/UDP将导致超时、流量丢失和网络不稳定。
The end result of this specification is that nearly all RADIUS/UDP implementations should transition to using a secure alternative. In some cases, RADIUS/UDP may remain where IPsec is used as a transport, or where implementation and/or business reasons preclude a change.
该规范的最终结果是，几乎所有RADIUS/UDP实现都应该过渡到使用安全替代方案。在某些情况下，RADIUS/UDP可能会保留在IPsec用作传输的位置，或者由于实施和/或业务原因而无法进行更改的位置。
However, we do not recommend long-term use of RADIUS/UDP outside of isolated and secure networks.
但是，我们不建议在隔离和安全的网络之外长期使用RADIUS/UDP。
This section describes how clients and servers should use RADIUS/DTLS, and how it interacts with RADIUS/UDP.
本节介绍客户端和服务器应如何使用RADIUS/DTL，以及它如何与RADIUS/UDP交互。
The default destination port number for RADIUS/DTLS is UDP/2083. There are no separate ports for authentication, accounting, and dynamic authorization changes. The source port is arbitrary. The text in [RFC6614], Section 3.4, describes issues surrounding the use of one port for multiple packet types. We recognize that implementations may allow the use of RADIUS/DTLS over non-standard ports. In that case, the references to UDP/2083 in this document should be read as applying to any port used for transport of RADIUS/DTLS traffic.
RADIUS/DTLS的默认目标端口号为UDP/2083。没有用于身份验证、记帐和动态授权更改的单独端口。源端口是任意的。[RFC6614]第3.4节中的文本描述了多个数据包类型使用一个端口的相关问题。我们认识到，实现可能允许在非标准端口上使用RADIUS/DTL。在这种情况下，本文档中对UDP/2083的引用应理解为适用于用于传输RADIUS/DTLS流量的任何端口。
When a server receives packets on UDP/2083, all packets MUST be treated as being DTLS. RADIUS/UDP packets MUST NOT be accepted on this port.
当服务器在UDP/2083上接收数据包时，必须将所有数据包视为DTL。此端口上不能接受RADIUS/UDP数据包。
Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports. Early versions of this specification permitted this behavior. It is forbidden here, as it depended on behavior in DTLS that may change without notice.
服务器不得接受旧RADIUS/UDP端口上的DTLS数据包。本规范的早期版本允许这种行为。这里是禁止的，因为它取决于DTL中的行为，这些行为可能会在未经通知的情况下更改。
Servers MUST authenticate clients. RADIUS is designed to be used by mutually trusted systems. Allowing anonymous clients would ensure privacy for RADIUS/DTLS traffic, but would negate all other security aspects of the protocol.
服务器必须对客户端进行身份验证。RADIUS设计用于相互信任的系统。允许匿名客户端将确保RADIUS/DTLS通信的隐私，但会否定协议的所有其他安全方面。
As RADIUS has no provisions for capability signaling, there is no way for a server to indicate to a client that it should transition to using DTLS. This action has to be taken by the administrators of the two systems, using a method other than RADIUS. This method will likely be out of band, or manual configuration will need to be used.
由于RADIUS没有能力信令的规定，服务器无法向客户机指示它应该转换为使用DTL。此操作必须由两个系统的管理员使用RADIUS以外的方法执行。此方法可能是带外的，或者需要使用手动配置。
Some servers maintain a list of allowed clients per destination port. Others maintain a global list of clients that are permitted to send packets to any port. Where a client can send packets to multiple ports, the server MUST maintain a "DTLS Required" flag per client.
有些服务器维护每个目标端口允许的客户端列表。其他人维护允许向任何端口发送数据包的客户端的全局列表。当客户端可以向多个端口发送数据包时，服务器必须为每个客户端维护“DTLS Required”标志。
This flag indicates whether or not the client is required to use DTLS. When set, the flag indicates that the only traffic accepted from the client is over UDP/2083. When packets are received from a
此标志指示客户端是否需要使用DTL。设置时，该标志指示从客户端接受的唯一通信量是通过UDP/2083。当从服务器接收数据包时
client on non-DTLS ports, for which DTLS is required, the server MUST silently discard these packets, as there is no RADIUS/UDP shared secret available.
在非DTLS端口（需要DTLS）上的客户端，服务器必须以静默方式丢弃这些数据包，因为没有可用的RADIUS/UDP共享机密。
This flag will often be set by an administrator. However, if a server receives DTLS traffic from a client, it SHOULD notify the administrator that DTLS is available for that client. It MAY mark the client as "DTLS Required".
此标志通常由管理员设置。但是，如果服务器从客户端接收到DTLS通信，它应该通知管理员该客户端可以使用DTLS。它可以将客户机标记为“需要DTLS”。
It is RECOMMENDED that servers support the following Perfect Forward Secrecy (PFS) ciphersuites:
建议服务器支持以下完美前向保密（PFS）密码套件：
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_，带AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_与_AES_128_GCM_SHA256
Allowing RADIUS/UDP and RADIUS/DTLS from the same client exposes the traffic to downbidding attacks and is NOT RECOMMENDED.
允许来自同一客户机的RADIUS/UDP和RADIUS/DTL会使流量受到降级攻击，因此不建议这样做。
When a client sends packets to the assigned RADIUS/DTLS port, all packets MUST be DTLS. RADIUS/UDP packets MUST NOT be sent to this port.
当客户端向指定的RADIUS/DTLS端口发送数据包时，所有数据包都必须是DTLS。RADIUS/UDP数据包不得发送到此端口。
Clients MUST authenticate themselves to servers via credentials that are unique to each client.
客户端必须通过每个客户端唯一的凭据向服务器进行身份验证。
It is RECOMMENDED that clients support the following PFS ciphersuites:
建议客户支持以下PFS密码套件：
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_，带AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_与_AES_128_GCM_SHA256
RADIUS/DTLS clients SHOULD NOT probe servers to see if they support DTLS transport. Instead, clients SHOULD use DTLS as a transport layer only when administratively configured. If a client is configured to use DTLS and the server appears to be unresponsive, the client MUST NOT fall back to using RADIUS/UDP. Instead, the client should treat the server as being down.
RADIUS/DTLS客户端不应探测服务器以查看它们是否支持DTLS传输。相反，客户端应该仅在管理配置时才将DTL用作传输层。如果客户机配置为使用DTL，而服务器似乎没有响应，则客户机不得退回到使用RADIUS/UDP。相反，客户端应该将服务器视为停机。
RADIUS clients often had multiple independent RADIUS implementations and/or processes that originate packets. This practice was simple to implement, but the result is that each independent subsystem must independently discover network issues or server failures. It is therefore RECOMMENDED that clients with multiple internal RADIUS sources use a local proxy as described in Section 6.1, below.
RADIUS客户端通常有多个独立的RADIUS实现和/或发起数据包的进程。这种做法很容易实现，但结果是每个独立的子系统必须独立地发现网络问题或服务器故障。因此，建议具有多个内部半径源的客户端使用下面第6.1节所述的本地代理。
Clients may implement "pools" of servers for fail-over or load-balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS servers.
客户端可以实现服务器的“池”，用于故障转移或负载平衡。这些池不应混合使用RADIUS/UDP和RADIUS/DTLS服务器。
Where [RFC6614] can rely on the TCP state machine to perform session tracking, this specification cannot. As a result, implementations of this specification may need to perform session management of the DTLS session in the application layer. This section describes logically how this tracking is done. Implementations may choose to use the method described here, or another, equivalent method.
如果[RFC6614]可以依赖TCP状态机执行会话跟踪，则本规范不能。因此，本规范的实现可能需要在应用层执行DTLS会话的会话管理。本节从逻辑上描述了如何完成此跟踪。实现可以选择使用这里描述的方法，或者其他等效方法。
We note that [RFC5080], Section 2.2.2, already mandates a duplicate detection cache. The session tracking described below can be seen as an extension of that cache, where entries contain DTLS sessions instead of RADIUS/UDP packets.
我们注意到[RFC5080]第2.2.2节已经要求使用重复检测缓存。下面描述的会话跟踪可以看作是该缓存的扩展，其中条目包含DTLS会话，而不是RADIUS/UDP数据包。
[RFC5080], Section 2.2.2, describes how duplicate RADIUS/UDP requests result in the retransmission of a previously cached RADIUS/UDP response. Due to DTLS sequence window requirements, a server MUST NOT retransmit a previously sent DTLS packet. Instead, it should cache the RADIUS response packet, and re-process it through DTLS to create a new RADIUS/DTLS packet, every time it is necessary to retransmit a RADIUS response.
[RFC5080]第2.2.2节描述了重复的RADIUS/UDP请求如何导致重新传输先前缓存的RADIUS/UDP响应。由于DTLS序列窗口要求，服务器不得重新传输先前发送的DTLS数据包。相反，每次需要重新传输RADIUS响应时，它应该缓存RADIUS响应数据包，并通过DTLS重新处理该数据包以创建新的RADIUS/DTLS数据包。
A RADIUS/DTLS server MUST track ongoing DTLS sessions for each, based on the following 4-tuple:
RADIUS/DTLS服务器必须根据以下4元组跟踪每个会话的正在进行的DTLS会话：
* source IP address * source port * destination IP address * destination port
* 源IP地址*源端口*目标IP地址*目标端口
Note that this 4-tuple is independent of IP address version (IPv4 or IPv6).
请注意，此4元组独立于IP地址版本（IPv4或IPv6）。
Each 4-tuple points to a unique session entry, which usually contains the following information:
每个4元组指向一个唯一的会话条目，该条目通常包含以下信息：
DTLS Session Any information required to maintain and manage the DTLS session.
DTLS会话维护和管理DTLS会话所需的任何信息。
Last Traffic A variable containing a timestamp that indicates when this session last received valid traffic. If "Last Traffic" is not used, this variable may not exist.
Last Traffic包含时间戳的变量，该时间戳指示此会话上次接收有效流量的时间。如果未使用“Last Traffic”，则此变量可能不存在。
DTLS Data An implementation-specific variable that may contain information about the active DTLS session. This variable may be empty or nonexistent.
DTLS数据一个特定于实现的变量，可能包含有关活动DTLS会话的信息。此变量可能为空或不存在。
This data will typically contain information such as idle timeouts, session lifetimes, and other implementation-specific data.
此数据通常包含诸如空闲超时、会话生存期和其他特定于实现的数据等信息。
Session tracking is subject to Denial-of-Service (DoS) attacks due to the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers SHOULD use the stateless cookie tracking technique described in [RFC6347], Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a ClientHello packet has been received with an appropriate Cookie value. Server implementation SHOULD have a way of tracking DTLS sessions that are partially set up. Servers MUST limit both the number and impact on resources of partial sessions.
由于攻击者伪造UDP流量的能力，会话跟踪会受到拒绝服务（DoS）攻击。RADIUS/DTLS服务器应使用[RFC6347]第4.2.1节所述的无状态cookie跟踪技术。在收到具有适当Cookie值的ClientHello数据包之前，不应跟踪DTLS会话。服务器实现应该有一种跟踪部分设置的DTLS会话的方法。服务器必须限制部分会话的数量和对资源的影响。
Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure Alert ([RFC5246], Section 7.2.1) or a fatal TLS Error Alert ([RFC5246], Section 7.2.2) is received. When a session is deleted due to it failing security requirements, the DTLS session MUST be closed, any TLS session resumption parameters for that session MUST be discarded, and all tracking information MUST be deleted.
当收到TLS关闭警报（[RFC5246]，第7.2.1节）或致命TLS错误警报（[RFC5246]，第7.2.2节）时，必须删除会话（4元组和条目）。当由于会话未满足安全要求而删除会话时，必须关闭DTLS会话，必须放弃该会话的任何TLS会话恢复参数，并且必须删除所有跟踪信息。
Sessions MUST also be deleted when a RADIUS packet fails validation due to a packet being malformed, or when it has an invalid Message-Authenticator or invalid Request Authenticator. There are other cases when the specifications require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying session as described above. There are few reasons to communicate with a Network Access Server (NAS) that is not implementing RADIUS.
当RADIUS数据包由于数据包格式错误而未能通过验证时，或者当其具有无效的消息验证器或无效的请求验证器时，也必须删除会话。当规范要求通过DTLS会话接收的数据包被“静默丢弃”时，还有其他情况。在这些情况下，实现可以如上所述删除底层会话。很少有理由与未实施RADIUS的网络访问服务器（NAS）通信。
A session MUST be deleted when non-RADIUS traffic is received over it. This specification is for RADIUS, and there is no reason to allow non-RADIUS traffic over a RADIUS/DTLS session. A session MUST be deleted when RADIUS traffic fails to pass security checks. There is no reason to permit insecure networks. A session SHOULD NOT be deleted when a well-formed, but "unexpected", RADIUS packet is received over it. Future specifications may extend RADIUS/DTLS, and we do not want to forbid those specifications.
当通过会话接收到非RADIUS流量时，必须删除该会话。本规范适用于RADIUS，没有理由允许RADIUS/DTLS会话上的非RADIUS通信。当RADIUS通信无法通过安全检查时，必须删除会话。没有理由允许不安全的网络。当通过会话接收到格式良好但“意外”的RADIUS数据包时，不应删除会话。未来的规范可能会扩展RADIUS/DTL，我们不想禁止这些规范。
The goal of the above requirements is to ensure security, while maintaining flexibility. Any security-related issue causes the connection to be closed. After the security restrictions have been applied, any unexpected traffic may be safely ignored, as it cannot cause a security issue. There is no need to close the session for unexpected but valid traffic, and the session can safely remain open.
上述要求的目标是确保安全性，同时保持灵活性。任何与安全相关的问题都会导致连接关闭。应用安全限制后，任何意外流量都可以安全地忽略，因为它不会导致安全问题。对于意外但有效的通信量，无需关闭会话，并且会话可以安全地保持打开状态。
Once a DTLS session is established, a RADIUS/DTLS server SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity between the two servers. A server SHOULD also use watchdog packets from the client to determine that the session is still active.
一旦建立DTLS会话，RADIUS/DTLS服务器应使用DTLS心跳[RFC6520]来确定两台服务器之间的连接。服务器还应该使用来自客户端的看门狗数据包来确定会话是否仍然处于活动状态。
As UDP does not guarantee delivery of messages, RADIUS/DTLS servers that do not implement an application-layer watchdog MUST also maintain a "Last Traffic" timestamp per DTLS session. The granularity of this timestamp is not critical and could be limited to one-second intervals. The timestamp SHOULD be updated on reception of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no more than once per interval. The timestamp MUST NOT be updated in other situations.
由于UDP不保证消息的传递，未实现应用层看门狗的RADIUS/DTLS服务器还必须为每个DTLS会话维护“最后通信量”时间戳。此时间戳的粒度并不重要，可以限制为1秒的间隔。在接收到有效的RADIUS/DTLS数据包或DTLS心跳信号时，应更新时间戳，但每个间隔不得超过一次。在其他情况下，时间戳不得更新。
When a session has not received a packet for a period of time, it is labeled "idle". The server SHOULD delete idle DTLS sessions after an "idle timeout". The server MAY cache the TLS session parameters, in order to provide for fast session resumption.
当会话有一段时间没有收到数据包时，它被标记为“空闲”。服务器应在“空闲超时”后删除空闲DTLS会话。服务器可以缓存TLS会话参数，以便提供快速会话恢复。
This session "idle timeout" SHOULD be exposed to the administrator as a configurable setting. It SHOULD NOT be set to less than 60 seconds and SHOULD NOT be set to more than 600 seconds (10 minutes). The minimum useful value for this timer is determined by the application-layer watchdog mechanism defined in the following section.
此会话“空闲超时”应作为可配置设置公开给管理员。它不应设置为小于60秒，也不应设置为大于600秒（10分钟）。此计时器的最小有用值由下一节中定义的应用层看门狗机制确定。
RADIUS/DTLS servers SHOULD also monitor the total number of open sessions. They SHOULD have a "maximum sessions" setting exposed to administrators as a configurable parameter. When this maximum is reached and a new session is started, the server MUST either drop an old session in order to open the new one or not create a new session.
RADIUS/DTLS服务器还应监控打开会话的总数。它们应该有一个“最大会话数”设置，作为可配置参数向管理员公开。当达到此最大值并启动新会话时，服务器必须删除旧会话以打开新会话，或者不创建新会话。
RADIUS/DTLS servers SHOULD implement session resumption, preferably stateless session resumption as given in [RFC5077]. This practice lowers the time and effort required to start a DTLS session with a client and increases network responsiveness.
RADIUS/DTLS服务器应实现会话恢复，最好是[RFC5077]中给出的无状态会话恢复。这种做法减少了与客户端启动DTLS会话所需的时间和精力，并提高了网络响应能力。
Since UDP is stateless, the potential exists for the client to initiate a new DTLS session using a particular 4-tuple, before the server has closed the old session. For security reasons, the server MUST keep the old session active until either it has received secure notification from the client that the session is closed or the server decides to close the session based on idle timeouts. Taking any other action would permit unauthenticated clients to perform a DoS attack, by reusing a 4-tuple and thus causing the server to close an active (and authenticated) DTLS session.
由于UDP是无状态的，因此在服务器关闭旧会话之前，客户端可能会使用特定的4元组启动新的DTLS会话。出于安全原因，服务器必须保持旧会话处于活动状态，直到从客户端收到会话关闭的安全通知，或者服务器根据空闲超时决定关闭会话。采取任何其他操作都将允许未经身份验证的客户端通过重用4元组来执行DoS攻击，从而导致服务器关闭活动（且经过身份验证）的DTLS会话。
As a result, servers MUST ignore any attempts to reuse an existing 4-tuple from an active session. This requirement can likely be reached by simply processing the packet through the existing session, as with any other packet received via that 4-tuple. Non-compliant, or unexpected packets will be ignored by the DTLS layer.
因此，服务器必须忽略从活动会话重用现有4元组的任何尝试。这一要求可能通过简单地通过现有会话处理数据包来实现，就像通过该4元组接收的任何其他数据包一样。DTLS层将忽略不兼容或意外的数据包。
The above requirement is mitigated by the suggestion in Section 6.1, below, that the client use a local proxy for all RADIUS traffic. That proxy can then track the ports that it uses and ensure that reuse of 4-tuples is avoided. The exact process by which this tracking is done is outside of the scope of this document.
以下第6.1节中的建议缓解了上述要求，即客户对所有RADIUS流量使用本地代理。然后，该代理可以跟踪它使用的端口，并确保避免重用4元组。完成此跟踪的确切过程不在本文档的范围内。
Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU between the client and server, prior to sending any RADIUS traffic. Once a DTLS session is established, a RADIUS/DTLS client SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity between the two systems. RADIUS/DTLS clients SHOULD also use the application-layer watchdog algorithm defined in [RFC3539] to determine server responsiveness. The Status-Server packet defined in [RFC5997] SHOULD be used as the "watchdog packet" in any application-layer watchdog algorithm.
在发送任何RADIUS流量之前，客户端应使用PMTU发现[RFC6520]确定客户端和服务器之间的PMTU。一旦建立DTLS会话，RADIUS/DTLS客户端应使用DTLS心跳[RFC6520]来确定两个系统之间的连接。RADIUS/DTLS客户端还应使用[RFC3539]中定义的应用层看门狗算法来确定服务器响应。[RFC5997]中定义的状态服务器数据包应在任何应用层看门狗算法中用作“看门狗数据包”。
RADIUS/DTLS clients SHOULD proactively close sessions when they have been idle for a period of time. Clients SHOULD close a session when the DTLS Heartbeat algorithm indicates that the session is no longer active. Clients SHOULD close a session when no traffic other than watchdog packets and (possibly) watchdog responses has been sent for three watchdog timeouts. This behavior ensures that clients do not waste resources on the server by causing it to track idle sessions.
RADIUS/DTLS客户端在空闲一段时间后应主动关闭会话。当DTLS心跳算法指示会话不再处于活动状态时，客户端应关闭会话。当在三次看门狗超时期间未发送除看门狗数据包和（可能）看门狗响应以外的通信量时，客户端应关闭会话。此行为确保客户端不会因跟踪空闲会话而浪费服务器上的资源。
When a client fails to implement both DTLS Heartbeats and watchdog packets, it has no way of knowing that a DTLS session has been closed. Therefore, there is the possibility that the server closes the session without the client knowing. When that happens, the client may later transmit packets in a session, and those packets will be ignored by the server. The client is then forced to time out those packets and then the session, leading to delays and network instabilities.
当客户端无法实现DTLS心跳和看门狗数据包时，它无法知道DTLS会话已关闭。因此，服务器有可能在客户端不知道的情况下关闭会话。当这种情况发生时，客户端可能稍后在会话中传输数据包，服务器将忽略这些数据包。然后，客户端被迫超时这些数据包，然后超时会话，从而导致延迟和网络不稳定。
For these reasons, it is RECOMMENDED that all DTLS sessions be configured to use DTLS Heartbeats and/or watchdog packets.
出于这些原因，建议将所有DTLS会话配置为使用DTLS心跳和/或看门狗数据包。
DTLS sessions MUST also be deleted when a RADIUS packet fails validation due to a packet being malformed, or when it has an invalid Message-Authenticator or invalid Response Authenticator. There are other cases when the specifications require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying DTLS session.
当RADIUS数据包由于数据包格式错误而未能通过验证时，或者当其具有无效消息验证器或无效响应验证器时，也必须删除DTLS会话。当规范要求通过DTLS会话接收的数据包被“静默丢弃”时，还有其他情况。在这些情况下，实现可能会删除底层DTLS会话。
RADIUS/DTLS clients should not send both RADIUS/UDP and RADIUS/DTLS packets to different servers from the same source socket. This practice causes increased complexity in the client application and increases the potential for security breaches due to implementation issues.
RADIUS/DTLS客户端不应从同一源套接字向不同的服务器发送RADIUS/UDP和RADIUS/DTLS数据包。这种做法会增加客户端应用程序的复杂性，并增加由于实现问题而导致安全漏洞的可能性。
RADIUS/DTLS clients SHOULD implement session resumption, preferably stateless session resumption as given in [RFC5077]. This practice lowers the time and effort required to start a DTLS session with a server and increases network responsiveness.
RADIUS/DTLS客户端应实现会话恢复，最好是[RFC5077]中给出的无状态会话恢复。这种做法减少了与服务器启动DTLS会话所需的时间和精力，并提高了网络响应能力。
The text above describes the protocol. In this section, we give additional implementation guidelines. These guidelines are not part of the protocol, but they may help implementors create simple, secure, and interoperable implementations.
上面的文字描述了协议。在本节中，我们将提供其他实施指南。这些指南不是协议的一部分，但它们可以帮助实现者创建简单、安全和可互操作的实现。
Where a TLS-PSK method is used, implementations MUST support keys of at least 16 octets in length. Implementations SHOULD support key lengths of 32 octets and SHOULD allow for longer keys. The key data MUST be capable of being any value (0 through 255, inclusive). Implementations MUST NOT limit themselves to using textual keys. It is RECOMMENDED that the administration interface allow for the keys to be entered as human-readable strings in hex format.
在使用TLS-PSK方法的情况下，实现必须支持长度至少为16个八位字节的密钥。实现应该支持32个八位字节的密钥长度，并且应该允许更长的密钥。密钥数据必须能够是任何值（0到255，包括0到255）。实现不能局限于使用文本键。建议管理界面允许以十六进制格式将密钥作为人类可读字符串输入。
When creating keys for use with PSK ciphersuites, it is RECOMMENDED that keys be derived from a Cryptographically Secure Pseudorandom Number Generator (CSPRNG) instead of administrators inventing keys on their own. If managing keys is too complicated, a certificate-based TLS method SHOULD be used instead.
创建用于PSK密码套件的密钥时，建议密钥从加密安全的伪随机数生成器（CSPRNG）派生，而不是由管理员自行发明密钥。如果密钥管理过于复杂，则应使用基于证书的TLS方法。
RADIUS/DTLS clients should use connected sockets where possible. Use of connected sockets means that the underlying kernel tracks the sessions, so that the client subsystem does not need to manage multiple sessions on one socket.
RADIUS/DTLS客户端应尽可能使用连接的套接字。使用连接的套接字意味着底层内核跟踪会话，因此客户端子系统不需要在一个套接字上管理多个会话。
RADIUS/DTLS clients should use a single source (IP + port) when sending packets to a particular RADIUS/DTLS server. Doing so minimizes the number of DTLS session setups. It also ensures that information about the home server state is discovered only once.
RADIUS/DTLS客户端在向特定RADIUS/DTLS服务器发送数据包时应使用单一源（IP+端口）。这样做可以最大限度地减少DTLS会话设置的数量。它还确保仅查找一次有关家庭服务器状态的信息。
In practice, this means that RADIUS/DTLS clients with multiple internal RADIUS sources should use a local proxy that arbitrates all RADIUS traffic between the client and all servers. The proxy should accept traffic only from the authorized subsystems on the client machine and should proxy that traffic to known servers. Each authorized subsystem should include an attribute that uniquely identifies that subsystem to the proxy, so that the proxy can apply origin-specific proxy rules and security policies. We suggest using NAS-Identifier for this purpose.
实际上，这意味着具有多个内部RADIUS源的RADIUS/DTLS客户端应使用本地代理来仲裁客户端和所有服务器之间的所有RADIUS流量。代理应仅接受来自客户机上授权子系统的流量，并应将该流量代理到已知服务器。每个授权子系统都应该包含一个属性，该属性可以唯一地将该子系统标识给代理，以便代理可以应用特定于源站的代理规则和安全策略。我们建议为此使用NAS标识符。
The local proxy should be able to interact with multiple servers at the same time. There is no requirement that each server have its own unique proxy on the client, as that would be inefficient.
本地代理应该能够同时与多个服务器交互。没有要求每台服务器在客户机上都有自己的唯一代理，因为这样效率很低。
The suggestion to use a local proxy means that there is only one process that discovers network and/or connectivity issues with a server. If each client subsystem communicated directly with a server, issues with that server would have to be discovered independently by each subsystem. The side effect would be increased delays in re-routing traffic, error reporting, and network instabilities.
建议使用本地代理意味着只有一个进程可以发现服务器的网络和/或连接问题。如果每个客户机子系统直接与服务器通信，那么每个子系统都必须独立地发现该服务器的问题。副作用将是在重新路由流量、错误报告和网络不稳定方面增加延迟。
Each client subsystem can include a subsystem-specific NAS-Identifier in each request. The format of this attribute is implementation-specific. The proxy should verify that the request originated from the local system, ideally via a loopback address. The proxy MUST then rewrite any subsystem-specific NAS-Identifier to a NAS-Identifier that identifies the client as a whole, or, remove the NAS-Identifier entirely and replace it with NAS-IP-Address or NAS-IPv6-Address.
每个客户端子系统都可以在每个请求中包含一个特定于子系统的NAS标识符。此属性的格式是特定于实现的。代理应该验证请求是否来自本地系统，最好是通过环回地址。然后，代理必须将任何特定于子系统的NAS标识符重写为整个客户端的NAS标识符，或者完全删除NAS标识符，并将其替换为NAS IP地址或NAS-IPv6-Address。
In traditional RADIUS, the cost to set up a new "session" between a client and server was minimal. The client subsystem could simply open a port, send a packet, wait for the response, and then close the port. With RADIUS/DTLS, the connection setup is significantly more expensive. In addition, there may be a requirement to use DTLS in order to communicate with a server, as RADIUS/UDP may not be supported by that server. The knowledge of what protocol to use is best managed by a dedicated RADIUS subsystem, rather than by each individual subsystem on the client.
在传统的RADIUS中，在客户机和服务器之间建立新的“会话”的成本是最低的。客户端子系统可以简单地打开一个端口，发送一个数据包，等待响应，然后关闭端口。使用RADIUS/DTLS时，连接设置的成本要高得多。此外，可能需要使用DTL与服务器通信，因为该服务器可能不支持RADIUS/UDP。使用何种协议的知识最好由专用的RADIUS子系统管理，而不是由客户机上的每个单独的子系统管理。
RADIUS/DTLS servers should not use connected sockets to read DTLS packets from a client. This recommendation exists because a connected UDP socket will accept packets only from one source IP address and port. This limitation would prevent the server from accepting packets from multiple clients on the same port.
RADIUS/DTLS服务器不应使用连接的套接字从客户端读取DTLS数据包。之所以存在此建议，是因为连接的UDP套接字将只接受来自一个源IP地址和端口的数据包。此限制将阻止服务器在同一端口上接受来自多个客户端的数据包。
This specification defines a transport layer for RADIUS. It makes no other changes to the RADIUS protocol. As a result, there are no Diameter considerations.
本规范定义了RADIUS的传输层。它不会对RADIUS协议进行其他更改。因此，没有直径方面的考虑。
No new RADIUS attributes or packet codes are defined. IANA has updated the "Service Name and Transport Protocol Port Number Registry". The entries corresponding to port service name "radsec", port number "2083", and transport protocol "UDP" have been updated as follows:
未定义新的RADIUS属性或数据包代码。IANA已更新“服务名称和传输协议端口号注册表”。与端口服务名称“radsec”、端口号“2083”和传输协议“UDP”对应的条目已更新如下：
o Assignee: IESG
o 受让人：IESG
o Contact: IETF Chair
o 联系人：IETF主席
o Reference: This document
o 参考：本文件
o Assignment Notes: The UDP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/TLS, prior to issuance of this RFC.
o 分配说明：在发布本RFC之前，IANA已将UDP端口2083分配给“RadSec”，这是RADIUS/TLS的早期实现。
This section records the status of known implementations of RADIUS/DTLS at the time of writing, and is based on a proposal described in [RFC6982].
本节记录了编写本文时已知的RADIUS/DTL实现的状态，并基于[RFC6982]中描述的提案。
The description of implementations in this section is intended to assist the IETF in its decision processes in progressing Internet-Drafts to RFCs.
本节中的实施说明旨在帮助IETF在将互联网草案提交至RFC的过程中做出决策。
Organization: Radsecproxy
组织：Radsecproxy
URL: https://software.uninett.no/radsecproxy/
URL: https://software.uninett.no/radsecproxy/
Maturity: Widely used software based on early versions of this document. The use of the DTLS functionality is not clear.
成熟度：基于本文档早期版本的广泛使用的软件。DTLS功能的使用尚不清楚。
Coverage: The bulk of this specification is implemented, based on earlier versions of this document. Exact revisions that were implemented are unknown.
覆盖范围：本规范的大部分是基于本文档的早期版本实现的。实施的确切修订尚不清楚。
Licensing: Freely distributable with acknowledgment.
许可证：经确认后可自由分发。
Implementation experience: No comments from implementors.
实施经验：实施者没有评论。
Organization: Coova
组织：库瓦
URL: http://www.coova.org/JRadius/RadSec
URL: http://www.coova.org/JRadius/RadSec
Maturity: Production software based on early versions of this document. The use of the DTLS functionality is not clear.
成熟度：基于本文档早期版本的生产软件。DTLS功能的使用尚不清楚。
Coverage: The bulk of this specification is implemented, based on earlier versions of this document. Exact revisions that were implemented are unknown.
覆盖范围：本规范的大部分是基于本文档的早期版本实现的。实施的确切修订尚不清楚。
Licensing: Freely distributable with requirement to redistribute source.
许可：自由分发，需要重新分发源。
Implementation experience: No comments from implementors.
实施经验：实施者没有评论。
The bulk of this specification is devoted to discussing security considerations related to RADIUS. However, we discuss a few additional issues here.
本规范的大部分内容用于讨论与RADIUS相关的安全注意事项。然而，我们在这里讨论一些额外的问题。
This specification relies on the existing DTLS, RADIUS/UDP, and RADIUS/TLS specifications. As a result, all security considerations for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the TLS and RADIUS security issues discussed in [RFC6614] also apply to this specification. Most of the security considerations for RADIUS apply to the RADIUS portion of the specification.
此规范依赖于现有的DTL、RADIUS/UDP和RADIUS/TLS规范。因此，DTL的所有安全注意事项都适用于RADIUS/DTL的DTLS部分。类似地，[RFC6614]中讨论的TLS和RADIUS安全问题也适用于本规范。RADIUS的大多数安全注意事项适用于规范的RADIUS部分。
However, many security considerations raised in the RADIUS documents are related to RADIUS encryption and authorization. Those issues are largely mitigated when DTLS is used as a transport method. The issues that are not mitigated by this specification are related to the RADIUS packet format and handling, which is unchanged in this specification.
但是，RADIUS文档中提出的许多安全注意事项与RADIUS加密和授权相关。当DTLS用作传输方法时，这些问题在很大程度上得到缓解。本规范未缓解的问题与RADIUS数据包格式和处理有关，本规范中未作任何更改。
This specification also suggests that implementations use a session tracking table. This table is an extension of the duplicate detection cache mandated in [RFC5080], Section 2.2.2. The changes given here are that DTLS-specific information is tracked for each table entry. Section 5.1.1, above, describes steps to mitigate any DoS issues that result from tracking additional information.
该规范还建议实现使用会话跟踪表。此表是[RFC5080]第2.2.2节规定的重复检测缓存的扩展。这里给出的更改是跟踪每个表条目的DTLS特定信息。上文第5.1.1节描述了缓解因跟踪附加信息而导致的任何DoS问题的步骤。
The fixed shared secret given above in Section 2.2.1 is acceptable only when DTLS is used with a non-null encryption method. When a DTLS session uses a null encryption method due to misconfiguration or implementation error, all of the RADIUS traffic will be readable by an observer. Therefore, implementations MUST NOT use null encryption methods for RADIUS/DTLS.
只有当DTLS与非空加密方法一起使用时，上述第2.2.1节中给出的固定共享秘密才是可接受的。当DTLS会话由于配置错误或实现错误而使用空加密方法时，所有RADIUS通信量都将被观察者读取。因此，实现不能对RADIUS/DTL使用空加密方法。
For systems that perform protocol-based firewalling and/or filtering, it is RECOMMENDED that they be configured to permit only DTLS over the RADIUS/DTLS port.
对于执行基于协议的防火墙和/或过滤的系统，建议将其配置为仅允许RADIUS/DTLS端口上的DTL。
Section 4.2 of [RFC6421] makes a number of recommendations about security properties of new RADIUS proposals. All of those recommendations are satisfied by using DTLS as the transport layer.
[RFC6421]第4.2节对新RADIUS提案的安全属性提出了一些建议。通过使用DTL作为传输层，所有这些建议都得到了满足。
Section 4.3 of [RFC6421] makes a number of recommendations about backwards compatibility with RADIUS. Section 3, above, addresses these concerns in detail.
[RFC6421]第4.3节对RADIUS的向后兼容性提出了许多建议。上文第3节详细阐述了这些问题。
Section 4.4 of [RFC6421] recommends that change control be ceded to the IETF, and that interoperability is possible. Both requirements are satisfied.
[RFC6421]第4.4节建议将变更控制权交给IETF，并且互操作性是可能的。这两项要求都得到满足。
Section 4.5 of [RFC6421] requires that the new security methods apply to all packet types. This requirement is satisfied by allowing DTLS to be used for all RADIUS traffic. In addition, Section 3, above, addresses concerns about documenting the transition from legacy RADIUS to crypto-agile RADIUS.
[RFC6421]第4.5节要求新的安全方法适用于所有数据包类型。通过允许DTL用于所有半径流量，可以满足此要求。此外，上面的第3节讨论了有关记录从遗留RADIUS到加密敏捷RADIUS过渡的问题。
Section 4.6 of [RFC6421] requires automated key management. This requirement is satisfied by using DTLS key management.
[RFC6421]第4.6节要求自动密钥管理。使用DTLS密钥管理可以满足这一要求。
We reiterate here the poor security of the legacy RADIUS protocol. We suggest that RADIUS clients and servers implement either this specification or [RFC6614]. New attacks on MD5 have appeared over the past few years, and there is a distinct possibility that MD5 may be completely broken in the near future. Such a break would mean that RADIUS/UDP was completely insecure.
我们在此重申遗留RADIUS协议的安全性差。我们建议RADIUS客户端和服务器实现此规范或[RFC6614]。在过去几年中，出现了针对MD5的新攻击，MD5很可能在不久的将来被完全破坏。这样的中断意味着RADIUS/UDP完全不安全。
The existence of fast and cheap attacks on MD5 could result in a loss of all network security that depends on RADIUS. Attackers could obtain user passwords and possibly gain complete network access. We cannot overstate the disastrous consequences of a successful attack on RADIUS.
对MD5的快速和廉价攻击的存在可能会导致依赖RADIUS的所有网络安全丧失。攻击者可以获取用户密码，并可能获得完整的网络访问权限。我们不能夸大成功攻击RADIUS的灾难性后果。
We also caution implementors (especially client implementors) about using RADIUS/DTLS. It may be tempting to use the shared secret as the basis for a TLS-PSK method and to leave the user interface otherwise unchanged. This practice MUST NOT be used. The administrator MUST be given the option to use DTLS. Any shared secret used for RADIUS/UDP MUST NOT be used for DTLS. Reusing a shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of the benefits found by using DTLS.
我们还提醒实现者（尤其是客户端实现者）不要使用RADIUS/DTL。使用共享秘密作为TLS-PSK方法的基础，并保持用户界面不变，这可能很有诱惑力。不得采用这种做法。必须为管理员提供使用DTL的选项。任何用于RADIUS/UDP的共享机密都不得用于DTL。在RADIUS/UDP和RADIUS/DTL之间重用共享机密将否定使用DTL所带来的所有好处。
RADIUS/DTLS client implementors MUST expose a configuration that allows the administrator to choose the ciphersuite. Where certificates are used, RADIUS/DTLS client implementors MUST expose a configuration that allows an administrator to configure all certificates necessary for certificate-based authentication. These certificates include client, server, and root certificates.
RADIUS/DTLS客户端实现者必须公开允许管理员选择密码套件的配置。在使用证书的情况下，RADIUS/DTLS客户端实现者必须公开一种配置，允许管理员配置基于证书的身份验证所需的所有证书。这些证书包括客户端、服务器和根证书。
TLS-PSK methods are susceptible to dictionary attacks. Section 6, above, recommends deriving TLS-PSK keys from a Cryptographically Secure Pseudorandom Number Generator (CSPRNG), which makes dictionary attacks significantly more difficult. Servers SHOULD track failed client connections by TLS-PSK ID and block TLS-PSK IDs that seem to be attempting brute-force searches of the keyspace.
TLS-PSK方法容易受到字典攻击。上文第6节建议从加密安全的伪随机数生成器（CSPRNG）派生TLS-PSK密钥，这使得字典攻击变得更加困难。服务器应通过TLS-PSK ID跟踪失败的客户端连接，并阻止似乎试图对密钥空间进行暴力搜索的TLS-PSK ID。
The historic RADIUS practice of using shared secrets (here, PSKs) that are minor variations of words is NOT RECOMMENDED, as it would negate all of the security of DTLS.
不推荐使用共享机密（此处为PSK）的历史做法，因为它会否定DTL的所有安全性，而共享机密是词语的微小变化。
The use of DTLS allows DoS attacks and resource-exhaustion attacks that were not possible in RADIUS/UDP. These attacks are similar to those described in [RFC6614], Section 6, for TCP.
DTLS的使用允许DoS攻击和资源耗尽攻击，这在RADIUS/UDP中是不可能的。这些攻击与[RFC6614]第6节中描述的TCP攻击类似。
Session tracking, as described in Section 5.1, can result in resource exhaustion. Therefore, servers MUST limit the absolute number of sessions that they track. When the total number of sessions tracked is going to exceed the configured limit, servers MAY free up resources by closing the session that has been idle for the longest time. Doing so may free up idle resources that then allow the server to accept a new session.
如第5.1节所述，会话跟踪可能导致资源耗尽。因此，服务器必须限制其跟踪的会话的绝对数量。当跟踪的会话总数将超过配置的限制时，服务器可以通过关闭空闲时间最长的会话来释放资源。这样做可能会释放空闲资源，从而允许服务器接受新会话。
Servers MUST limit the number of partially open DTLS sessions. These limits SHOULD be exposed to the administrator as configurable settings.
服务器必须限制部分打开的DTLS会话的数量。这些限制应作为可配置设置向管理员公开。
We expect that the initial deployment of DTLS will follow the RADIUS/UDP model of statically configured client-server relationships. The specification for dynamic discovery of RADIUS servers is under development, so we will not address that here.
我们期望DTL的初始部署将遵循静态配置的客户机-服务器关系的RADIUS/UDP模型。RADIUS服务器的动态发现规范正在开发中，因此我们在这里不讨论这个问题。
Static configuration of client-server relationships for RADIUS/UDP means that a client has a fixed IP address for a server and a shared secret used to authenticate traffic sent to that address. The server in turn has a fixed IP address for a client and a shared secret used to authenticate traffic from that address. This model needs to be extended for RADIUS/DTLS.
RADIUS/UDP客户端-服务器关系的静态配置意味着客户端具有服务器的固定IP地址和用于验证发送到该地址的流量的共享密钥。服务器又为客户端提供了一个固定的IP地址和一个用于验证来自该地址的流量的共享秘密。此模型需要针对RADIUS/DTL进行扩展。
Instead of a shared secret, TLS credentials MUST be used by each party to authenticate the other. The issue of identity is more problematic. As with RADIUS/UDP, IP addresses may be used as a key to determine the authentication credentials that a client will present to a server or which credentials a server will accept from a client. This is the fixed IP address model of RADIUS/UDP, with the shared secret replaced by TLS credentials.
各方必须使用TLS凭据来验证另一方，而不是共享机密。身份问题更成问题。与RADIUS/UDP一样，IP地址可用作密钥，以确定客户端将向服务器提供的身份验证凭据或服务器将从客户端接受的凭据。这是RADIUS/UDP的固定IP地址模型，共享密钥由TLS凭据替换。
There are, however, additional considerations with RADIUS/DTLS. When a client is configured with a hostname for a server, the server may present to the client a certificate containing a hostname. The client MUST then verify that the hostnames match. Any mismatch is a security violation, and the connection MUST be closed.
但是，RADIUS/DTL还有其他注意事项。当客户机配置了服务器的主机名时，服务器可能会向客户机提供包含主机名的证书。然后，客户端必须验证主机名是否匹配。任何不匹配都是安全冲突，必须关闭连接。
A RADIUS/DTLS server MAY be configured with a "wildcard" IP address match for clients, instead of a unique fixed IP address for each client. In that case, clients MUST be individually configured with a unique certificate. When the server receives a connection from a client, it MUST determine client identity from the client certificate, and MUST authenticate (or not) the client based on that certificate. See [RFC6614], Section 2.4, for a discussion of how to match a certificate to a client identity.
RADIUS/DTLS服务器可以为客户端配置“通配符”IP地址匹配，而不是为每个客户端配置唯一的固定IP地址。在这种情况下，客户端必须单独配置一个唯一的证书。当服务器接收到来自客户端的连接时，它必须根据客户端证书确定客户端身份，并且必须基于该证书对客户端进行身份验证（或不验证）。请参阅[RFC6614]，第2.4节，了解如何将证书与客户机标识匹配的讨论。
However, servers SHOULD use IP address filtering to minimize the possibility of attacks. That is, they SHOULD permit clients only from a limited IP address range or ranges. They SHOULD silently discard all traffic from outside of those ranges.
但是，服务器应使用IP地址过滤，以将攻击的可能性降至最低。也就是说，它们应该只允许来自一个或多个有限IP地址范围的客户端。他们应该默默地丢弃那些范围之外的所有流量。
Since the client-server relationship is static, the authentication credentials for that relationship must also be statically configured. That is, a client connecting to a DTLS server SHOULD be pre-configured with the server's credentials (e.g., PSK or certificate). If the server fails to present the correct credentials, the DTLS session MUST be closed. Each server SHOULD be pre-configured with sufficient information to authenticate connecting clients.
由于客户机-服务器关系是静态的，因此还必须静态配置该关系的身份验证凭据。也就是说，连接到DTLS服务器的客户端应该预先配置服务器的凭据（例如，PSK或证书）。如果服务器无法提供正确的凭据，则必须关闭DTLS会话。每个服务器都应该预先配置足够的信息，以便对连接的客户端进行身份验证。
The requirement for clients to be individually configured with a unique certificate can be met by using a private CA for certificates used in RADIUS/DTLS environments. If a client were configured to use a public CA, then it could accept as valid any server that has a certificate signed by that CA. While the traffic would be secure from third-party observers, the server would, however, have unrestricted access to all of the RADIUS traffic, including all user credentials and passwords.
对RADIUS/DTLS环境中使用的证书使用专用CA，可以满足客户机单独配置唯一证书的要求。如果客户机被配置为使用公共CA，那么它可以接受任何具有该CA签名的证书的服务器作为有效服务器。虽然第三方观察员可以保护流量，但服务器可以不受限制地访问所有RADIUS流量，包括所有用户凭据和密码。
Therefore, clients SHOULD NOT be pre-configured with a list of known public CAs by the vendor or manufacturer. Instead, the clients SHOULD start off with an empty CA list. The addition of a CA SHOULD be done only when manually configured by an administrator.
因此，供应商或制造商不应使用已知公共CA列表预先配置客户端。相反，客户端应该从一个空的CA列表开始。仅当管理员手动配置时，才应添加CA。
This scenario is the opposite of web browsers, where they are pre-configured with many known CAs. The goal there is security from third-party observers, but also the ability to communicate with any unknown site that presents a signed certificate. In contrast, the goal of RADIUS/DTLS is both security from third-party observers and the ability to communicate with only a small set of well-known servers.
这种情况与web浏览器相反，web浏览器预先配置了许多已知的CA。这样做的目的是确保来自第三方观察员的安全，同时还能够与任何提供签名证书的未知站点进行通信。相比之下，RADIUS/DTLS的目标是保护第三方观察者的安全，以及仅与一小部分知名服务器通信的能力。
This requirement does not prevent clients from using hostnames instead of IP addresses for locating a particular server. Instead, it means that the credentials for that server should be pre-configured on the client, and associated with that hostname. This requirement does suggest that in the absence of a specification for dynamic discovery, clients SHOULD use only those servers that have been manually configured by an administrator.
此要求不阻止客户端使用主机名而不是IP地址来定位特定服务器。相反，这意味着该服务器的凭据应该在客户端上预先配置，并与该主机名关联。此要求确实建议，在没有动态发现规范的情况下，客户端应仅使用管理员手动配置的服务器。
Network Address Translation (NAT) is fundamentally incompatible with RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the shared secret for the client, and NAT hides many clients behind one source IP address. As a result, RADIUS/UDP clients cannot be located behind a NAT gateway.
网络地址转换（NAT）与RADIUS/UDP基本不兼容。RADIUS/UDP使用源IP地址确定客户端的共享机密，NAT将许多客户端隐藏在一个源IP地址后面。因此，RADIUS/UDP客户端不能位于NAT网关后面。
In addition, port reuse on a NAT gateway means that packets from different clients may appear to come from the same source port on the NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from one source IP/port combination, followed by the reception of a RADIUS/UDP packet from that same source IP/port combination. If this behavior is allowed, then the server would have an inconsistent view of the client's security profile, allowing an attacker to choose the most insecure method.
此外，NAT网关上的端口重用意味着来自不同客户端的数据包可能来自NAT上的同一源端口。也就是说，RADIUS服务器可以从一个源IP/端口组合接收RADIUS/DTLS数据包，然后从该源IP/端口组合接收RADIUS/UDP数据包。如果允许此行为，则服务器将具有客户端安全配置文件的不一致视图，从而允许攻击者选择最不安全的方法。
If more than one client is located behind a NAT gateway, then every client behind the NAT MUST use a secure transport such as TLS or DTLS. As discussed below, a method for uniquely identifying each client MUST be used.
如果NAT网关后面有多个客户端，则NAT后面的每个客户端都必须使用安全传输，如TLS或DTL。如下文所述，必须使用唯一标识每个客户机的方法。
Some RADIUS server implementations allow for "wildcard" clients -- that is, clients with an IPv4 netmask of other than 32 or an IPv6 netmask of other than 128. That practice is not recommended for RADIUS/UDP, as it means multiple clients will use the same shared secret.
某些RADIUS服务器实现允许“通配符”客户端，即IPv4网络掩码不是32或IPv6网络掩码不是128的客户端。不建议RADIUS/UDP采用这种做法，因为这意味着多个客户端将使用相同的共享密钥。
The use of RADIUS/DTLS can allow for the safe usage of wildcards. When RADIUS/DTLS is used with wildcards, clients MUST be uniquely identified using TLS parameters, and any certificate or PSK used MUST be unique to each client.
使用RADIUS/DTL可以安全使用通配符。当RADIUS/DTLS与通配符一起使用时，必须使用TLS参数唯一地标识客户端，并且使用的任何证书或PSK对于每个客户端都必须是唯一的。
Section 5.1.1, above, requires that DTLS sessions be closed when the transported RADIUS packets are malformed or fail the authenticator checks. The reason is that the session is expected to be used for transport of RADIUS packets only.
上述第5.1.1节要求，当传输的RADIUS数据包格式错误或验证器检查失败时，关闭DTLS会话。原因是会话预期仅用于传输RADIUS数据包。
Any non-RADIUS traffic on that session means the other party is misbehaving and is a potential security risk. Similarly, any RADIUS traffic failing authentication vector or Message-Authenticator validation means that two parties do not have a common shared secret, and the session is therefore unauthenticated and insecure.
该会话上的任何非RADIUS流量都意味着另一方行为不端，存在潜在的安全风险。类似地，任何未通过身份验证向量或消息身份验证程序验证的RADIUS通信都意味着双方没有公共共享机密，因此会话未经身份验证且不安全。
We wish to avoid the situation where a third party can send well-formed RADIUS packets that cause a DTLS session to close. Therefore, in other situations, the session SHOULD remain open in the face of non-conformant packets.
我们希望避免第三方发送格式良好的RADIUS数据包导致DTLS会话关闭的情况。因此，在其他情况下，会话在遇到不一致的数据包时应保持打开状态。
Many traditional clients treat RADIUS as subsystem-specific. That is, each subsystem on the client has its own RADIUS implementation and configuration. These independent implementations work for simple systems, but break down for RADIUS when multiple servers, fail-over, and load-balancing are required. They have even worse issues when DTLS is enabled.
许多传统客户机将RADIUS视为特定于子系统的。也就是说，客户机上的每个子系统都有自己的RADIUS实现和配置。这些独立的实现适用于简单的系统，但在需要多台服务器、故障转移和负载平衡时，RADIUS会出现故障。启用DTLS时，它们的问题甚至更严重。
As noted in Section 6.1, above, clients SHOULD use a local proxy that arbitrates all RADIUS traffic between the client and all servers. This proxy will encapsulate all knowledge about servers, including security policies, fail-over, and load-balancing. All client subsystems SHOULD communicate with this local proxy, ideally over a loopback address. The requirements on using strong shared secrets still apply.
如上文第6.1节所述，客户端应使用本地代理来仲裁客户端和所有服务器之间的所有RADIUS流量。此代理将封装有关服务器的所有知识，包括安全策略、故障转移和负载平衡。所有客户端子系统都应该与本地代理通信，最好是通过环回地址。使用强共享机密的要求仍然适用。
The benefit of this configuration is that there is one place in the client that arbitrates all RADIUS traffic. Subsystems that do not implement DTLS can remain unaware of DTLS. DTLS sessions opened by the proxy can remain open for long periods of time, even when client subsystems are restarted. The proxy can do RADIUS/UDP to some servers and RADIUS/DTLS to others.
这种配置的好处是，客户端中有一个地方可以仲裁所有RADIUS流量。未实现DTL的子系统可能仍然不知道DTL。代理打开的DTLS会话可以长时间保持打开状态，即使客户端子系统重新启动。代理可以对某些服务器执行RADIUS/UDP，对其他服务器执行RADIUS/DTL。
Delegation of responsibilities and separation of tasks are important security principles. By moving all RADIUS/DTLS knowledge to a DTLS-aware proxy, security analysis becomes simpler, and enforcement of correct security becomes easier.
责任下放和任务分离是重要的安全原则。通过将所有RADIUS/DTLS知识移动到DTLS感知代理，安全性分析变得更简单，正确安全性的实施变得更容易。
[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月。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3539]Aboba，B.和J.Wood，“认证、授权和会计（AAA）传输概要”，RFC 3539，2003年6月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080]Nelson，D.和A.DeKok，“通用远程身份验证拨入用户服务（RADIUS）实施问题和建议修复”，RFC 50802007年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[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月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, February 2012.
[RFC6520]Seggelmann，R.，Tuexen，M.和M.Williams，“传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展”，RFC 6520，2012年2月。
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
[RFC6613]DeKok，A.，“TCP上的半径”，RFC 6613，2012年5月。
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012.
[RFC6614]Winter，S.，McCauley，M.，Venaas，S.，和K.Wierenga，“RADIUS的传输层安全（TLS）加密”，RFC 6614，2012年5月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年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月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 51762008年1月。
[RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, November 2011.
[RFC6421]Nelson，D.，Ed.“远程认证拨入用户服务（RADIUS）的加密灵活性要求”，RFC 64212011年11月。
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, July 2013.
[RFC6982]Sheffer，Y.和A.Farrel，“提高运行代码的意识：实现状态部分”，RFC 6982，2013年7月。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack]Dobbertin，H.，“最近一次攻击后MD5的状态”，CryptoBytes第2卷第2期，1996年夏季。
[MD5Break] Wang, X. and H. Yu, "How to Break MD5 and Other Hash Functions", EUROCRYPT '05 Proceedings of the 24th annual international conference on Theory and Applications of Cryptographic Techniques, pp. 19-35, ISBN 3-540-25910-4, 2005.
[MD5Break]Wang，X.和H.Yu，“如何破解MD5和其他哈希函数”，欧洲密码技术协会2005年第24届国际密码技术理论与应用年会论文集，第19-35页，ISBN 3-540-25910-42005。
Acknowledgments
致谢
Parts of the text in Section 3 defining the Request and Response Authenticators were taken with minor edits from [RFC2865], Section 3.
第3节中定义请求和响应验证器的部分文本由[RFC2865]第3节进行了少量编辑。
Author's Address
作者地址
Alan DeKok
The FreeRADIUS Server Project
URI: http://freeradius.org
EMail: aland@freeradius.org
Alan DeKok
The FreeRADIUS Server Project
URI: http://freeradius.org
EMail: aland@freeradius.org