Internet Engineering Task Force (IETF) S. Winter
Request for Comments: 6614 RESTENA
Category: Experimental M. McCauley
ISSN: 2070-1721 OSC
S. Venaas
K. Wierenga
Cisco
May 2012
Internet Engineering Task Force (IETF) S. Winter
Request for Comments: 6614 RESTENA
Category: Experimental M. McCauley
ISSN: 2070-1721 OSC
S. Venaas
K. Wierenga
Cisco
May 2012
Transport Layer Security (TLS) Encryption for RADIUS
RADIUS的传输层安全（TLS）加密
Abstract
摘要
This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers.
本文档使用TCP上的传输层安全性（TLS）作为传输协议，指定RADIUS的传输配置文件。这将启用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/rfc6614.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6614.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................3
1.1. Requirements Language ......................................3
1.2. Terminology ................................................4
1.3. Document Status ............................................4
2. Normative: Transport Layer Security for RADIUS/TCP ..............5
2.1. TCP port and Packet Types ..................................5
2.2. TLS Negotiation ............................................5
2.3. Connection Setup ...........................................5
2.4. Connecting Client Identity .................................7
2.5. RADIUS Datagrams ...........................................8
3. Informative: Design Decisions ..................................10
3.1. Implications of Dynamic Peer Discovery ....................10
3.2. X.509 Certificate Considerations ..........................10
3.3. Ciphersuites and Compression Negotiation Considerations ...11
3.4. RADIUS Datagram Considerations ............................11
4. Compatibility with Other RADIUS Transports .....................12
5. Diameter Compatibility .........................................13
6. Security Considerations ........................................13
7. IANA Considerations ............................................14
8. Acknowledgements ...............................................15
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
Appendix A. Implementation Overview: Radiator .....................18
Appendix B. Implementation Overview: radsecproxy ..................19
Appendix C. Assessment of Crypto-Agility Requirements .............20
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
1.2. Terminology ................................................4
1.3. Document Status ............................................4
2. Normative: Transport Layer Security for RADIUS/TCP ..............5
2.1. TCP port and Packet Types ..................................5
2.2. TLS Negotiation ............................................5
2.3. Connection Setup ...........................................5
2.4. Connecting Client Identity .................................7
2.5. RADIUS Datagrams ...........................................8
3. Informative: Design Decisions ..................................10
3.1. Implications of Dynamic Peer Discovery ....................10
3.2. X.509 Certificate Considerations ..........................10
3.3. Ciphersuites and Compression Negotiation Considerations ...11
3.4. RADIUS Datagram Considerations ............................11
4. Compatibility with Other RADIUS Transports .....................12
5. Diameter Compatibility .........................................13
6. Security Considerations ........................................13
7. IANA Considerations ............................................14
8. Acknowledgements ...............................................15
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
Appendix A. Implementation Overview: Radiator .....................18
Appendix B. Implementation Overview: radsecproxy ..................19
Appendix C. Assessment of Crypto-Agility Requirements .............20
The RADIUS protocol [RFC2865] is a widely deployed authentication and authorization protocol. The supplementary RADIUS Accounting specification [RFC2866] provides accounting mechanisms, thus delivering a full Authentication, Authorization, and Accounting (AAA) solution. However, RADIUS is experiencing several shortcomings, such as its dependency on the unreliable transport protocol UDP and the lack of security for large parts of its packet payload. RADIUS security is based on the MD5 algorithm, which has been proven to be insecure.
RADIUS协议[RFC2865]是一种广泛部署的身份验证和授权协议。补充RADIUS记帐规范[RFC2866]提供记帐机制，从而提供完整的身份验证、授权和记帐（AAA）解决方案。然而，RADIUS正经历着一些缺点，例如它依赖于不可靠的传输协议UDP，并且它的大部分数据包负载缺乏安全性。RADIUS安全性基于MD5算法，该算法已被证明是不安全的。
The main focus of RADIUS over TLS is to provide a means to secure the communication between RADIUS/TCP peers using TLS. The most important use of this specification lies in roaming environments where RADIUS packets need to be transferred through different administrative domains and untrusted, potentially hostile networks. An example for a worldwide roaming environment that uses RADIUS over TLS to secure communication is "eduroam", see [eduroam].
RADIUS over TLS的主要重点是提供一种方法来保护使用TLS的RADIUS/TCP对等方之间的通信。此规范最重要的用途在于漫游环境中，在漫游环境中，RADIUS数据包需要通过不同的管理域和不受信任的潜在恶意网络进行传输。使用RADIUS over TLS保护通信的全球漫游环境的一个示例是“eduroam”，请参见[eduroam]。
There are multiple known attacks on the MD5 algorithm that is used in RADIUS to provide integrity protection and a limited confidentiality protection (see [MD5-attacks]). RADIUS over TLS wraps the entire RADIUS packet payload into a TLS stream and thus mitigates the risk of attacks on MD5.
RADIUS中使用的MD5算法存在多个已知攻击，以提供完整性保护和有限的机密性保护（请参见[MD5攻击]）。RADIUS over TLS将整个RADIUS数据包有效负载包装到一个TLS流中，从而降低了对MD5的攻击风险。
Because of the static trust establishment between RADIUS peers (IP address and shared secret), the only scalable way of creating a massive deployment of RADIUS servers under the control of different administrative entities is to introduce some form of a proxy chain to route the access requests to their home server. This creates a lot of overhead in terms of possible points of failure, longer transmission times, as well as middleboxes through which authentication traffic flows. These middleboxes may learn privacy-relevant data while forwarding requests. The new features in RADIUS over TLS obsolete the use of IP addresses and shared MD5 secrets to identify other peers and thus allow the use of more contemporary trust models, e.g., checking a certificate by inspecting the issuer and other certificate properties.
由于RADIUS对等方之间建立了静态信任（IP地址和共享机密），在不同管理实体的控制下创建大规模RADIUS服务器部署的唯一可扩展方法是引入某种形式的代理链，将访问请求路由到其主服务器。这在可能的故障点、更长的传输时间以及身份验证流量流经的中间盒方面造成了大量开销。这些中间包可以在转发请求时了解隐私相关数据。RADIUS over TLS中的新功能不再使用IP地址和共享MD5机密来识别其他对等方，因此允许使用更现代的信任模型，例如，通过检查颁发者和其他证书属性来检查证书。
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 RFC 2119 [RFC2119].
在本文件中，使用了几个词来表示规范的要求。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
RADIUS/TLS node: a RADIUS-over-TLS client or server
RADIUS/TLS节点：TLS客户端或服务器上的RADIUS
RADIUS/TLS Client: a RADIUS-over-TLS instance that initiates a new connection.
RADIUS/TLS客户端：启动新连接的RADIUS over TLS实例。
RADIUS/TLS Server: a RADIUS-over-TLS instance that listens on a RADIUS-over-TLS port and accepts new connections
RADIUS/TLS服务器：RADIUS over TLS实例，侦听RADIUS over TLS端口并接受新连接
RADIUS/UDP: a classic RADIUS transport over UDP as defined in [RFC2865]
RADIUS/UDP:UDP上的经典RADIUS传输，定义见[RFC2865]
This document is an Experimental RFC.
本文档是一个实验性RFC。
It is one out of several approaches to address known cryptographic weaknesses of the RADIUS protocol (see also Section 4). The specification does not fulfill all recommendations on a AAA transport profile as per [RFC3539]; in particular, by being based on TCP as a transport layer, it does not prevent head-of-line blocking issues.
这是解决RADIUS协议已知密码弱点的几种方法之一（另见第4节）。本规范不符合[RFC3539]中关于AAA传输模式的所有建议；特别是，通过将TCP作为传输层，它不能防止线路头阻塞问题。
If this specification is indeed selected for advancement to Standards Track, certificate verification options (Section 2.3, point 2) need to be refined.
如果选择本规范确实是为了提升到标准轨道，则需要改进证书验证选项（第2.3节，第2点）。
Another experimental characteristic of this specification is the question of key management between RADIUS/TLS peers. RADIUS/UDP only allowed for manual key management, i.e., distribution of a shared secret between a client and a server. RADIUS/TLS allows manual distribution of long-term proofs of peer identity as well (by using TLS-PSK ciphersuites, or identifying clients by a certificate fingerprint), but as a new feature enables 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 (PSK) 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/TLS对等方之间的密钥管理问题。RADIUS/UDP仅允许手动密钥管理，即在客户端和服务器之间分发共享密钥。RADIUS/TLS还允许手动分发对等身份的长期证明（通过使用TLS-PSK密码套件，或通过证书指纹识别客户端），但作为一项新功能，允许在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.
尚未决定是否将此方法用于标准跟踪。判断方法是否在大规模上可用的一个关键方面是通过观察协议在大规模实际部署中的使用、可用性和操作行为。
An example for a worldwide roaming environment that uses RADIUS over TLS to secure communication is "eduroam", see [eduroam].
使用RADIUS over TLS保护通信的全球漫游环境的一个示例是“eduroam”，请参见[eduroam]。
The default destination port number for RADIUS over TLS is TCP/2083. There are no separate ports for authentication, accounting, and dynamic authorization changes. The source port is arbitrary. See Section 3.4 for considerations regarding the separation of authentication, accounting, and dynamic authorization traffic.
RADIUS over TLS的默认目标端口号为TCP/2083。没有用于身份验证、记帐和动态授权更改的单独端口。源端口是任意的。有关身份验证、记帐和动态授权流量分离的注意事项，请参见第3.4节。
RADIUS/TLS has no notion of negotiating TLS in an established connection. Servers and clients need to be preconfigured to use RADIUS/TLS for a given endpoint.
RADIUS/TLS没有在已建立的连接中协商TLS的概念。服务器和客户端需要预先配置，以便为给定端点使用RADIUS/TLS。
RADIUS/TLS nodes
RADIUS/TLS节点
1. establish TCP connections as per [RFC6613]. Failure to connect leads to continuous retries, with exponentially growing intervals between every try. If multiple servers are defined, the node MAY attempt to establish a connection to these other servers in parallel, in order to implement quick failover.
1. 按照[RFC6613]建立TCP连接。连接失败会导致连续重试，每次尝试之间的间隔呈指数增长。如果定义了多个服务器，则节点可能会尝试并行建立与这些其他服务器的连接，以实现快速故障切换。
2. after completing the TCP handshake, immediately negotiate TLS sessions according to [RFC5246] or its predecessor TLS 1.1. The following restrictions apply:
2. 完成TCP握手后，立即根据[RFC5246]或其前身TLS 1.1协商TLS会话。以下限制适用：
* Support for TLS v1.1 [RFC4346] or later (e.g., TLS 1.2 [RFC5246]) is REQUIRED. To prevent known attacks on TLS versions prior to 1.1, implementations MUST NOT negotiate TLS versions prior to 1.1.
* 需要对TLS v1.1[RFC4346]或更高版本（例如TLS 1.2[RFC5246]）的支持。为了防止对1.1之前的TLS版本的已知攻击，实现不得协商1.1之前的TLS版本。
* Support for certificate-based mutual authentication is REQUIRED.
* 需要支持基于证书的相互身份验证。
* Negotiation of mutual authentication is REQUIRED.
* 需要协商相互认证。
* Negotiation of a ciphersuite providing for confidentiality as well as integrity protection is REQUIRED. Failure to comply with this requirement can lead to severe security problems, like user passwords being recoverable by third parties. See Section 6 for details.
* 需要协商提供机密性和完整性保护的密码套件。不遵守此要求可能导致严重的安全问题，如用户密码可由第三方恢复。详见第6节。
* Support for and negotiation of compression is OPTIONAL.
* 对压缩的支持和协商是可选的。
* Support for TLS-PSK mutual authentication [RFC4279] is OPTIONAL.
* 对TLS-PSK相互认证[RFC4279]的支持是可选的。
* RADIUS/TLS implementations MUST, at a minimum, support negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA, and SHOULD support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3.
* RADIUS/TLS实施必须至少支持TLS_RSA_与_3DES_EDE_CBC_SHA的协商，并应支持TLS_RSA_与_RC4_128_SHA以及TLS_RSA_与_AES_128_CBC_SHA的协商（参见第3.3节）。
* In addition, RADIUS/TLS implementations MUST support negotiation of the mandatory-to-implement ciphersuites required by the versions of TLS that they support.
* 此外，RADIUS/TLS实现必须支持强制协商，以实现其支持的TLS版本所需的密码套件。
3. Peer authentication can be performed in any of the following three operation models:
3. 对等身份验证可以在以下三种操作模式中的任意一种中执行：
* TLS with X.509 certificates using PKIX trust models (this model is mandatory to implement):
* 具有使用PKIX信任模型的X.509证书的TLS（必须实现此模型）：
+ Implementations MUST allow the configuration of a list of trusted Certification Authorities for incoming connections.
+ 实现必须允许为传入连接配置受信任的证书颁发机构列表。
+ Certificate validation MUST include the verification rules as per [RFC5280].
+ 证书验证必须包括[RFC5280]规定的验证规则。
+ Implementations SHOULD indicate their trusted Certification Authorities (CAs). For TLS 1.2, this is done using [RFC5246], Section 7.4.4, "certificate_authorities" (server side) and [RFC6066], Section 6 "Trusted CA Indication" (client side). See also Section 3.2.
+ 实现应指明其受信任的证书颁发机构（CA）。对于TLS 1.2，这是使用[RFC5246]第7.4.4节“证书授权”（服务器端）和[RFC6066]第6节“可信CA指示”（客户端）完成的。另见第3.2节。
+ Peer validation always includes a check on whether the locally configured expected DNS name or IP address of the server that is contacted matches its presented certificate. DNS names and IP addresses can be contained in the Common Name (CN) or subjectAltName entries. For verification, only one of these entries is to be considered. The following precedence applies: for DNS name validation, subjectAltName:DNS has precedence over CN; for IP address validation, subjectAltName:iPAddr has precedence over CN.
+ 对等验证始终包括检查本地配置的所联系服务器的预期DNS名称或IP地址是否与其提供的证书匹配。DNS名称和IP地址可以包含在公共名称（CN）或subjectAltName条目中。为了进行验证，只需考虑其中一个条目。以下优先级适用：对于DNS名称验证，subjectAltName:DNS优先于CN；对于IP地址验证，subjectAltName:IPAddress优先于CN。
Implementors of this specification are advised to read [RFC6125], Section 6, for more details on DNS name validation.
建议本规范的实施者阅读[RFC6125]，第6节，了解有关DNS名称验证的更多详细信息。
+ Implementations MAY allow the configuration of a set of additional properties of the certificate to check for a peer's authorization to communicate (e.g., a set of allowed values in subjectAltName:URI or a set of allowed X509v3 Certificate Policies).
+ 实现可能允许配置证书的一组附加属性，以检查对等方的通信授权（例如，subjectAltName:URI中的一组允许值或一组允许的X509v3证书策略）。
+ When the configured trust base changes (e.g., removal of a CA from the list of trusted CAs; issuance of a new CRL for a given CA), implementations MAY renegotiate the TLS session to reassess the connecting peer's continued authorization.
+ 当配置的信任基础发生变化时（例如，从受信任CA列表中删除CA；为给定CA发布新的CRL），实现可能会重新协商TLS会话以重新评估连接对等方的持续授权。
* TLS with X.509 certificates using certificate fingerprints (this model is optional to implement): Implementations SHOULD allow the configuration of a list of trusted certificates, identified via fingerprint of the DER encoded certificate octets. Implementations MUST support SHA-1 as the hash algorithm for the fingerprint. To prevent attacks based on hash collisions, support for a more contemporary hash function such as SHA-256 is RECOMMENDED.
* 具有使用证书指纹的X.509证书的TLS（此模型是可选实现的）：实现应允许配置通过DER编码的证书八位字节指纹识别的可信证书列表。实现必须支持SHA-1作为指纹的哈希算法。为了防止基于哈希冲突的攻击，建议支持更现代的哈希函数，如SHA-256。
* TLS using TLS-PSK (this model is optional to implement).
* 使用TLS-PSK的TLS（此模型是可选的）。
4. start exchanging RADIUS datagrams (note Section 3.4 (1)). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.4 (2)).
4. 开始交换RADIUS数据报（注意第3.4（1）节）。计算（过时的）MD5完整性检查和属性加密的共享机密必须为“radsec”（见第3.4（2）节）。
In RADIUS/UDP, clients are uniquely identified by their IP address. Since the shared secret is associated with the origin IP address, if more than one RADIUS client is associated with the same IP address, then those clients also must utilize the same shared secret, a practice that is inherently insecure, as noted in [RFC5247].
在RADIUS/UDP中，客户端由其IP地址唯一标识。由于共享机密与源IP地址相关联，如果多个RADIUS客户端与同一IP地址相关联，则这些客户端还必须使用相同的共享机密，这是一种本质上不安全的做法，如[RFC5247]中所述。
RADIUS/TLS supports multiple operation modes.
RADIUS/TLS支持多种操作模式。
In TLS-PSK operation, a client is uniquely identified by its TLS identifier.
在TLS-PSK操作中，客户机由其TLS标识符唯一标识。
In TLS-X.509 mode using fingerprints, a client is uniquely identified by the fingerprint of the presented client certificate.
在使用指纹的TLS-X.509模式中，客户机通过提供的客户机证书的指纹进行唯一标识。
In TLS-X.509 mode using PKIX trust models, a client is uniquely identified by the tuple (serial number of presented client certificate;Issuer).
在使用PKIX信任模型的TLS-X.509模式中，客户端由元组（提供的客户端证书的序列号；颁发者）唯一标识。
Note well: having identified a connecting entity does not mean the server necessarily wants to communicate with that client. For example, if the Issuer is not in a trusted set of Issuers, the server may decline to perform RADIUS transactions with this client.
请注意：识别连接实体并不意味着服务器一定要与该客户机通信。例如，如果发卡机构不在受信任的发卡机构集中，服务器可能会拒绝与该客户端执行RADIUS事务。
There are numerous trust models in PKIX environments, and it is beyond the scope of this document to define how a particular deployment determines whether a client is trustworthy. Implementations that want to support a wide variety of trust models should expose as many details of the presented certificate to the administrator as possible so that the trust model can be implemented by the administrator. As a suggestion, at least the following parameters of the X.509 client certificate should be exposed:
PKIX环境中有许多信任模型，定义特定部署如何确定客户端是否可信超出了本文档的范围。希望支持多种信任模型的实现应该向管理员公开所提供证书的尽可能多的详细信息，以便管理员可以实现信任模型。建议至少公开X.509客户端证书的以下参数：
o Originating IP address
o 起始IP地址
o Certificate Fingerprint
o 证书指纹
o Issuer
o 发行人
o Subject
o 主题
o all X509v3 Extended Key Usage
o 所有X509v3扩展密钥的使用
o all X509v3 Subject Alternative Name
o 所有X509v3受试者备选名称
o all X509v3 Certificate Policies
o 所有X509v3证书策略
In TLS-PSK operation, at least the following parameters of the TLS connection should be exposed:
在TLS-PSK操作中，至少应暴露TLS连接的以下参数：
o Originating IP address
o 起始IP地址
o TLS Identifier
o TLS标识符
Authentication, Authorization, and Accounting packets are sent according to the following rules:
根据以下规则发送身份验证、授权和记帐数据包：
RADIUS/TLS clients transmit the same packet types on the connection they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and (4)). For example, they send
RADIUS/TLS客户端在其启动的连接上传输与RADIUS/UDP客户端相同的数据包类型（参见第3.4（3）和（4）节）。例如，他们发送
o Access-Request
o 访问请求
o Accounting-Request
o 会计请求
o Status-Server
o 状态服务器
o Disconnect-ACK
o 断开确认
o Disconnect-NAK
o 断开NAK
o ...
o ...
and they receive
他们收到
o Access-Accept
o 访问接受
o Accounting-Response
o 会计回应
o Disconnect-Request
o 断开请求
o ...
o ...
RADIUS/TLS servers transmit the same packet types on connections they have accepted as a RADIUS/UDP server would. For example, they send
RADIUS/TLS服务器在其接受为RADIUS/UDP服务器的连接上传输相同的数据包类型。例如，他们发送
o Access-Challenge
o 访问挑战
o Access-Accept
o 访问接受
o Access-Reject
o 访问拒绝
o Accounting-Response
o 会计回应
o Disconnect-Request
o 断开请求
o ...
o ...
and they receive
他们收到
o Access-Request
o 访问请求
o Accounting-Request
o 会计请求
o Status-Server
o 状态服务器
o Disconnect-ACK
o 断开确认
o ...
o ...
Due to the use of one single TCP port for all packet types, it is required that a RADIUS/TLS server signal which types of packets are supported on a server to a connecting peer. See also Section 3.4 for a discussion of signaling.
由于所有数据包类型都使用一个TCP端口，因此需要RADIUS/TLS服务器将服务器上支持的数据包类型发送到连接对等方。关于信号的讨论，另见第3.4节。
o When an unwanted packet of type 'CoA-Request' or 'Disconnect-Request' is received, a RADIUS/TLS server needs to respond with a 'CoA-NAK' or 'Disconnect-NAK', respectively. The NAK SHOULD contain an attribute Error-Cause with the value 406 ("Unsupported Extension"); see [RFC5176] for details.
o 当收到“CoA请求”或“断开连接请求”类型的不需要的数据包时，RADIUS/TLS服务器需要分别用“CoA NAK”或“断开连接NAK”进行响应。NAK应该包含一个值为406的属性Error Cause（“不支持的扩展”）；详见[RFC5176]。
o When an unwanted packet of type 'Accounting-Request' is received, the RADIUS/TLS server SHOULD reply with an Accounting-Response containing an Error-Cause attribute with value 406 "Unsupported Extension" as defined in [RFC5176]. A RADIUS/TLS accounting client receiving such an Accounting-Response SHOULD log the error and stop sending Accounting-Request packets.
o 当收到“记帐请求”类型的不需要的数据包时，RADIUS/TLS服务器应回复一个记帐响应，该响应包含一个错误原因属性，该属性的值为406“Unsupported Extension”，如[RFC5176]中所定义。收到此类记帐响应的RADIUS/TLS记帐客户端应记录错误并停止发送记帐请求数据包。
This section explains the design decisions that led to the rules defined in the previous section.
本节解释了导致上一节中定义的规则的设计决策。
One mechanism to discover RADIUS-over-TLS peers dynamically via DNS is specified in [DYNAMIC]. While this mechanism is still under development and therefore is not a normative dependency of RADIUS/ TLS, the use of dynamic discovery has potential future implications that are important to understand.
[DYNAMIC]中指定了一种通过DNS在TLS对等点上动态发现RADIUS的机制。虽然这一机制仍在开发中，因此不是RADIUS/TLS的规范依赖关系，但动态发现的使用具有潜在的未来影响，需要理解。
Readers of this document who are considering the deployment of DNS-based dynamic discovery are thus encouraged to read [DYNAMIC] and follow its future development.
因此，鼓励正在考虑部署基于DNS的动态发现的本文档读者阅读[动态]并关注其未来发展。
(1) If a RADIUS/TLS client is in possession of multiple certificates from different CAs (i.e., is part of multiple roaming consortia) and dynamic discovery is used, the discovery mechanism possibly does not yield sufficient information to identify the consortium uniquely (e.g., DNS discovery). Subsequently, the client may not know by itself which client certificate to use for the TLS handshake. Then, it is necessary for the server to signal to which consortium it belongs and which certificates it expects. If there is no risk of confusing multiple roaming consortia, providing this information in the handshake is not crucial.
(1) 如果RADIUS/TLS客户端拥有来自不同CA的多个证书（即，是多个漫游联盟的一部分），并且使用了动态发现，则发现机制可能不会产生足够的信息来唯一地识别联盟（例如，DNS发现）。随后，客户机本身可能不知道将哪个客户机证书用于TLS握手。然后，服务器需要通知它所属的联合体以及它所期望的证书。如果不存在混淆多个漫游联盟的风险，那么在握手中提供此信息并不重要。
(2) If a RADIUS/TLS server is in possession of multiple certificates from different CAs (i.e., is part of multiple roaming consortia), it will need to select one of its certificates to present to the RADIUS/TLS client. If the client sends the Trusted CA Indication, this hint can make the server select the appropriate certificate and prevent a handshake failure. Omitting this indication makes it impossible to deterministically select the right certificate in this case. If there is no risk of confusing multiple roaming consortia, providing this indication in the handshake is not crucial.
(2) 如果RADIUS/TLS服务器拥有来自不同CA的多个证书（即，是多个漫游联盟的一部分），则需要选择其中一个证书以显示给RADIUS/TLS客户端。如果客户端发送可信CA指示，此提示可使服务器选择适当的证书并防止握手失败。在这种情况下，省略此指示将无法确定地选择正确的证书。如果不存在混淆多个漫游联盟的风险，那么在握手中提供此指示并不重要。
Not all TLS ciphersuites in [RFC5246] are supported by available TLS tool kits, and licenses may be required in some cases. The existing implementations of RADIUS/TLS use OpenSSL as a cryptographic backend, which supports all of the ciphersuites listed in the rules in the normative section.
并非[RFC5246]中的所有TLS密码套件都受可用的TLS工具包支持，在某些情况下可能需要许可证。RADIUS/TLS的现有实现使用OpenSSL作为加密后端，它支持规范部分规则中列出的所有密码套件。
The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory to implement according to [RFC4346]; thus, it has to be supported by RADIUS/TLS nodes.
必须根据[RFC4346]实施TLS密码套件TLS_RSA_和CBC_SHA；因此，它必须由RADIUS/TLS节点支持。
The two other ciphersuites in the normative section are widely implemented in TLS tool kits and are considered good practice to implement.
规范部分中的另外两个密码套件在TLS工具包中广泛实施，被认为是实施的良好实践。
(1) After the TLS session is established, RADIUS packet payloads are exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet size can be determined by evaluating the size of the datagram that arrived. Due to the stream nature of TCP and TLS, this does not hold true for RADIUS/TLS packet exchange. Instead, packet boundaries of RADIUS packets that arrive in the stream are calculated by evaluating the packet's Length field. Special care needs to be taken on the packet sender side that the value of the Length field is indeed correct before sending it over the TLS tunnel, because incorrect packet lengths can no longer be detected by a differing datagram boundary. See Section 2.6.4 of [RFC6613] for more details.
(1) TLS会话建立后，RADIUS数据包有效载荷通过加密的TLS隧道进行交换。在RADIUS/UDP中，可以通过评估到达的数据报的大小来确定数据包大小。由于TCP和TLS的流性质，RADIUS/TLS数据包交换不适用这种情况。相反，到达流中的RADIUS数据包的数据包边界是通过计算数据包的长度字段来计算的。在通过TLS隧道发送数据包之前，需要特别注意长度字段的值确实是正确的，因为不同的数据包边界无法再检测到不正确的数据包长度。详见[RFC6613]第2.6.4节。
(2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding attributes such as User-Password, as well as in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Response Authenticator. Since TLS provides integrity protection and encryption sufficient to
(2) 在RADIUS/UDP[RFC2865]中，共享秘密用于隐藏用户密码等属性，以及计算响应验证器。在RADIUS accounting[RFC2866]中，共享密钥用于计算请求认证器和响应认证器。因为TLS提供的完整性保护和加密足以
substitute for RADIUS application-layer security, it is not necessary to configure a RADIUS shared secret. The use of a fixed string for the obsolete shared secret eliminates possible node misconfigurations.
代替RADIUS应用层安全，无需配置RADIUS共享机密。对过时的共享机密使用固定字符串可以消除可能的节点错误配置。
(3) RADIUS/UDP [RFC2865] uses different UDP ports for authentication, accounting, and dynamic authorization changes. RADIUS/TLS allocates a single port for all RADIUS packet types. Nevertheless, in RADIUS/TLS, the notion of a client that sends authentication requests and processes replies associated with its users' sessions and the notion of a server that receives requests, processes them, and sends the appropriate replies is to be preserved. The normative rules about acceptable packet types for clients and servers mirror the packet flow behavior from RADIUS/UDP.
(3) RADIUS/UDP[RFC2865]使用不同的UDP端口进行身份验证、记帐和动态授权更改。RADIUS/TLS为所有RADIUS数据包类型分配一个端口。然而，在RADIUS/TLS中，发送身份验证请求并处理与其用户会话相关联的回复的客户端的概念以及接收请求、处理请求并发送适当回复的服务器的概念将被保留。关于客户端和服务器可接受数据包类型的规范性规则反映了RADIUS/UDP的数据包流行为。
(4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support the reception and processing of the packet types in [RFC5176]. These packet types are listed as to be received in RADIUS/TLS implementations. Note well: it is not required for an implementation to actually process these packet types; it is only required that the NAK be sent as defined above.
(4) RADIUS/UDP[RFC2865]使用对新分配的UDP端口的负面ICMP响应来表示对等RADIUS服务器不支持[RFC5176]中数据包类型的接收和处理。这些数据包类型被列为RADIUS/TLS实现中要接收的数据包类型。请注意：实现不需要实际处理这些数据包类型；仅要求按照上述定义发送NAK。
(5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support the reception and processing of RADIUS Accounting packets. There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured for sending Accounting packets to a RADIUS/TLS server that does not wish to process their Accounting packet. To prevent a regression of detectability of this situation, the Accounting-Response + Error-Cause signaling was introduced.
(5) RADIUS/UDP[RFC2865]使用对新分配的UDP端口的负面ICMP响应来表示对等RADIUS服务器不支持RADIUS记帐数据包的接收和处理。没有RADIUS数据报向记帐NAK发送信号。客户端可能配置错误，无法将记帐数据包发送到不希望处理其记帐数据包的RADIUS/TLS服务器。为了防止这种情况的可检测性回归，引入了记帐响应+错误原因信令。
The IETF defines multiple alternative transports to the classic UDP transport model as defined in [RFC2865], namely RADIUS over TCP [RFC6613] and the present document on RADIUS over TLS. The IETF also proposed RADIUS over Datagram Transport Layer Security (DTLS) [RADEXT-DTLS].
IETF定义了[RFC2865]中定义的经典UDP传输模型的多种替代传输，即TCP上的RADIUS[RFC6613]和当前关于TLS上的RADIUS的文档。IETF还提出了数据报传输层安全（DTLS）上的RADIUS[RADEXT-DTLS]。
RADIUS/TLS does not specify any inherent backward compatibility to RADIUS/UDP or cross compatibility to the other transports, i.e., an implementation that utilizes RADIUS/TLS only will not be able to receive or send RADIUS packet payloads over other transports. An implementation wishing to be backward or cross compatible (i.e., wishes to serve clients using other transports than RADIUS/TLS) will
RADIUS/TLS未指定RADIUS/UDP的任何固有向后兼容性或与其他传输的交叉兼容性，即，仅使用RADIUS/TLS的实现将无法通过其他传输接收或发送RADIUS数据包有效负载。希望向后兼容或交叉兼容的实现（即希望使用RADIUS/TLS以外的其他传输服务于客户端）将
need to implement these other transports along with the RADIUS/TLS transport and be prepared to send and receive on all implemented transports, which is called a "multi-stack implementation".
需要与RADIUS/TLS传输一起实现这些其他传输，并准备在所有实现的传输上发送和接收，这称为“多堆栈实现”。
If a given IP device is able to receive RADIUS payloads on multiple transports, this may or may not be the same instance of software, and it may or may not serve the same purposes. It is not safe to assume that both ports are interchangeable. In particular, it cannot be assumed that state is maintained for the packet payloads between the transports. Two such instances MUST be considered separate RADIUS server entities.
如果给定的IP设备能够在多个传输上接收RADIUS有效载荷，则这可能是软件的同一实例，也可能不是软件的同一实例，并且它可能用于或可能不用于相同的目的。假设两个端口都可以互换是不安全的。特别地，不能假设在传输之间为分组有效负载保持状态。必须将这两个实例视为单独的RADIUS服务器实体。
Since RADIUS/TLS is only a new transport profile for RADIUS, the compatibility of RADIUS/TLS - Diameter [RFC3588] and RADIUS/UDP [RFC2865] - Diameter [RFC3588] is identical. The considerations regarding payload size in [RFC6613] apply.
由于RADIUS/TLS只是RADIUS的一个新传输配置文件，RADIUS/TLS-直径[RFC3588]和RADIUS/UDP[RFC2865]-直径[RFC3588]的兼容性是相同的。[RFC6613]中有关有效负载大小的注意事项适用。
The computational resources to establish a TLS tunnel are significantly higher than simply sending mostly unencrypted UDP datagrams. Therefore, clients connecting to a RADIUS/TLS node will more easily create high load conditions and a malicious client might create a Denial-of-Service attack more easily.
建立TLS隧道所需的计算资源比简单地发送大部分未加密的UDP数据报要高得多。因此，连接到RADIUS/TLS节点的客户端将更容易创建高负载条件，恶意客户端可能更容易创建拒绝服务攻击。
Some TLS ciphersuites only provide integrity validation of their payload, and provide no encryption. This specification forbids the use of such ciphersuites. Since the RADIUS payload's shared secret is fixed to the well-known term "radsec" (see Section 2.3 (4)), failure to comply with this requirement will expose the entire datagram payload in plaintext, including User-Password, to intermediate IP nodes.
一些TLS密码套件只提供有效负载的完整性验证，不提供加密。本规范禁止使用此类密码套件。由于RADIUS有效载荷的共享秘密被固定为众所周知的术语“radsec”（见第2.3（4）节），因此不遵守此要求将以明文形式向中间IP节点公开整个数据报有效载荷，包括用户密码。
By virtue of being based on TCP, there are several generic attack vectors to slow down or prevent the TCP connection from being established; see [RFC4953] for details. If a TCP connection is not up when a packet is to be processed, it gets re-established, so such attacks in general lead only to a minor performance degradation (the time it takes to re-establish the connection). There is one notable exception where an attacker might create a bidding-down attack though. If peer communication between two devices is configured for both RADIUS/TLS (i.e., TLS security over TCP as a transport, shared secret fixed to "radsec") and RADIUS/UDP (i.e., shared secret security with a secret manually configured by the administrator), and the RADIUS/UDP transport is the failover option if the TLS session cannot be established, a bidding-down attack can occur if an
由于基于TCP，存在几种通用攻击向量来减慢或阻止TCP连接的建立；详见[RFC4953]。如果在处理数据包时TCP连接未启动，它将被重新建立，因此此类攻击通常只会导致轻微的性能下降（重新建立连接所需的时间）。但有一个值得注意的例外情况，即攻击者可能会发起竞价拒绝攻击。如果两台设备之间的对等通信针对RADIUS/TLS（即TCP上的TLS安全作为传输，共享机密固定为“radsec”）和RADIUS/UDP（即共享机密安全，由管理员手动配置机密）进行配置，并且如果无法建立TLS会话，RADIUS/UDP传输是故障切换选项，如果
adversary can maliciously close the TCP connection or prevent it from being established. Situations where clients are configured in such a way are likely to occur during a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker can reduce the security of the packet payload from the selected TLS ciphersuite packet encryption to the classic MD5 per-attribute encryption. The situation should be avoided by disabling the weaker RADIUS/UDP transport as soon as the new RADIUS/TLS connection is established and tested. Disabling can happen at either the RADIUS client or server side:
对手可以恶意关闭TCP连接或阻止其建立。在从RADIUS/UDP到RADIUS/TLS的迁移阶段，可能会发生以这种方式配置客户端的情况。通过阻止TLS会话设置，攻击者可以将数据包有效负载的安全性从选定的TLS ciphersuite数据包加密降低到经典的MD5每属性加密。应通过在建立和测试新RADIUS/TLS连接后立即禁用较弱的RADIUS/UDP传输来避免这种情况。可以在RADIUS客户端或服务器端禁用：
o Client side: de-configure the failover setup, leaving RADIUS/TLS as the only communication option
o 客户端：取消配置故障切换设置，保留RADIUS/TLS作为唯一的通信选项
o Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients
o 服务器端：从有效RADIUS客户端列表中取消配置RADIUS/UDP客户端
RADIUS/TLS provides authentication and encryption between RADIUS peers. In the presence of proxies, the intermediate proxies can still inspect the individual RADIUS packets, i.e., "end-to-end" encryption is not provided. Where intermediate proxies are untrusted, it is desirable to use other RADIUS mechanisms to prevent RADIUS packet payload from inspection by such proxies. One common method to protect passwords is the use of the Extensible Authentication Protocol (EAP) and EAP methods that utilize TLS.
RADIUS/TLS在RADIUS对等方之间提供身份验证和加密。在存在代理的情况下，中间代理仍然可以检查各个RADIUS分组，即，不提供“端到端”加密。在中间代理不受信任的情况下，最好使用其他RADIUS机制来防止RADIUS数据包有效负载被此类代理检查。保护密码的一种常见方法是使用可扩展身份验证协议（EAP）和利用TLS的EAP方法。
When using certificate fingerprints to identify RADIUS/TLS peers, any two certificates that produce the same hash value (i.e., that have a hash collision) will be considered the same client. Therefore, it is important to make sure that the hash function used is cryptographically uncompromised so that an attacker is very unlikely to be able to produce a hash collision with a certificate of his choice. While this specification mandates support for SHA-1, a later revision will likely demand support for more contemporary hash functions because as of issuance of this document, there are already attacks on SHA-1.
当使用证书指纹识别RADIUS/TLS对等方时，任何两个产生相同哈希值（即具有哈希冲突）的证书都将被视为同一客户端。因此，重要的是要确保所使用的哈希函数是加密的，这样攻击者就不太可能与他选择的证书产生哈希冲突。虽然本规范要求支持SHA-1，但稍后的修订版可能会要求支持更现代的哈希函数，因为在本文档发布时，已有对SHA-1的攻击。
No new RADIUS attributes or packet codes are defined. IANA has updated the already assigned TCP port number 2083 to reflect the following:
未定义新的RADIUS属性或数据包代码。IANA已更新已分配的TCP端口号2083，以反映以下内容：
o Reference: [RFC6614]
o 参考文献：[RFC6614]
o Assignment Notes: The TCP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/ TLS, prior to issuance of this RFC. This early implementation can be configured to be compatible to RADIUS/TLS as specified by the IETF. See RFC 6614, Appendix A for details.
o 分配说明：在发布本RFC之前，IANA已将TCP端口2083分配给“RadSec”，这是RADIUS/TLS的早期实现。此早期实施可配置为与IETF指定的RADIUS/TLS兼容。详见RFC 6614附录A。
RADIUS/TLS was first implemented as "RADSec" by Open Systems Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS server product (see [radsec-whitepaper]).
RADIUS/TLS最初由澳大利亚Currumbin Waters的开放系统顾问公司为其“散热器”RADIUS服务器产品实施为“RADSec”（见[RADSec白皮书]）。
Funding and input for the development of this document was provided by the European Commission co-funded project "GEANT2" [geant2] and further feedback was provided by the TERENA Task Force on Mobility and Network Middleware [terena].
欧盟委员会共同资助的项目“GEANT2”[GEANT2]为本文件的编制提供了资金和投入，TERENA移动和网络中间件工作组[TERENA]提供了进一步反馈。
[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月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279]Eronen，P.和H.Tschofenig，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月。
[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月。
[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月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，RFC 5247，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
[RFC6613]DeKok，A.，“TCP上的半径”，RFC 6613，2012年5月。
[DYNAMIC] Winter, S. and M. McCauley, "NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS", Work in Progress, July 2011.
[DYNAMIC]Winter，S.和M.McCauley，“基于NAI的RADIUS/TLS和RADIUS/DTL动态对等发现”，正在进行的工作，2011年7月。
[MD5-attacks] Black, J., Cochran, M., and T. Highland, "A Study of the MD5 Attacks: Insights and Improvements", October 2006, <http://www.springerlink.com/content/40867l85727r7084/>.
[MD5攻击]Black，J.，Cochran，M.，和T.Highland，“MD5攻击研究：洞察和改进”，2006年10月<http://www.springerlink.com/content/40867l85727r7084/>.
[RADEXT-DTLS] DeKok, A., "DTLS as a Transport Layer for RADIUS", Work in Progress, October 2010.
[RADEXT-DTLS]DeKok，A.，“DTLS作为RADIUS的传输层”，正在进行的工作，2010年10月。
[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月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[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月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]Touch，J.“保护TCP免受欺骗攻击”，RFC 4953，2007年7月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC6421] Nelson, D., "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, November 2011.
[RFC6421]Nelson，D.，“远程认证拨入用户服务（RADIUS）的加密灵活性要求”，RFC 64212011年11月。
[eduroam] Trans-European Research and Education Networking Association, "eduroam Homepage", 2007, <http://www.eduroam.org/>.
[eduroam]泛欧研究和教育网络协会，“eduroam主页”，2007年<http://www.eduroam.org/>.
[geant2] Delivery of Advanced Network Technology to Europe, "European Commission Information Society and Media: GEANT2", 2008, <http://www.geant2.net/>.
[geant2]向欧洲交付先进网络技术，“欧盟委员会信息社会和媒体：geant2”，2008年<http://www.geant2.net/>.
[radsec-whitepaper] Open System Consultants, "RadSec - a secure, reliable RADIUS Protocol", May 2005, <http://www.open.com.au/radiator/radsec-whitepaper.pdf>.
[radsec白皮书]开放系统顾问，“radsec-安全可靠的RADIUS协议”，2005年5月<http://www.open.com.au/radiator/radsec-whitepaper.pdf>.
[radsecproxy-impl] Venaas, S., "radsecproxy Project Homepage", 2007, <http://software.uninett.no/radsecproxy/>.
[radsecproxy impl]Venaas，S.，“radsecproxy项目主页”，2007年<http://software.uninett.no/radsecproxy/>.
[terena] Trans-European Research and Education Networking Association (TERENA), "Task Force on Mobility and Network Middleware", 2008, <http://www.terena.org/activities/tf-mobility/>.
[terena]泛欧研究和教育网络协会（terena），“移动和网络中间件工作组”，2008年<http://www.terena.org/activities/tf-mobility/>.
Appendix A. Implementation Overview: Radiator
附录A.实施概述：散热器
Radiator implements the RadSec protocol for proxying requests with the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator configuration file.
散热器通过散热器配置文件中的<Authby RadSec>和<ServerRADSEC>子句实现代理请求的RadSec协议。
The <AuthBy RADSEC> clause defines a RadSec client, and causes Radiator to send RADIUS requests to the configured RadSec server using the RadSec protocol.
<AuthBy RADSEC>子句定义RADSEC客户端，并使散热器使用RADSEC协议向配置的RADSEC服务器发送RADIUS请求。
The <ServerRADSEC> clause defines a RadSec server, and causes Radiator to listen on the configured port and address(es) for connections from <Authby RADSEC> clients. When an <Authby RADSEC> client connects to a <ServerRADSEC> server, the client sends RADIUS requests through the stream to the server. The server then handles the request in the same way as if the request had been received from a conventional UDP RADIUS client.
<ServerRADSEC>子句定义RadSec服务器，并使散热器在配置的端口和地址上侦听来自<Authby RadSec>客户端的连接。当<Authby RADSEC>客户端连接到<ServerRADSEC>服务器时，客户端通过流向服务器发送RADIUS请求。然后，服务器处理请求的方式与从传统UDP RADIUS客户端接收请求的方式相同。
Radiator is compliant to RADIUS/TLS if the following options are used:
如果使用以下选项，散热器符合RADIUS/TLS：
<AuthBy RADSEC>
<AuthBy RADSEC>
* Protocol tcp
* 协议tcp
* UseTLS
* UseTLS
* TLS_CertificateFile
* TLS_认证文件
* Secret radsec
* 秘密雷达
<ServerRADSEC>
<ServerRADSEC>
* Protocol tcp
* 协议tcp
* UseTLS
* UseTLS
* TLS_RequireClientCert
* TLS_要求客户证书
* Secret radsec
* 秘密雷达
As of Radiator 3.15, the default shared secret for RadSec connections is configurable and defaults to "mysecret" (without quotes). For compliance with this document, this setting needs to be configured for the shared secret "radsec". The implementation uses TCP keepalive socket options, but does not send Status-Server packets. Once established, TLS connections are kept open throughout the server instance lifetime.
从3.15开始，RadSec连接的默认共享机密是可配置的，默认为“mysecret”（不带引号）。为了符合本文档的要求，需要为共享机密“radsec”配置此设置。该实现使用TCP keepalive套接字选项，但不发送状态服务器数据包。一旦建立，TLS连接将在整个服务器实例生命周期中保持打开状态。
Appendix B. Implementation Overview: radsecproxy
附录B.实施概述：radsecproxy
The RADIUS proxy named radsecproxy was written in order to allow use of RadSec in current RADIUS deployments. This is a generic proxy that supports any number and combination of clients and servers, supporting RADIUS over UDP and RadSec. The main idea is that it can be used on the same host as a non-RadSec client or server to ensure RadSec is used on the wire; however, as a generic proxy, it can be used in other circumstances as well.
编写名为radsecproxy的RADIUS代理是为了允许在当前RADIUS部署中使用RadSec。这是一个通用代理，支持任意数量和组合的客户端和服务器，支持UDP和RadSec上的RADIUS。其主要思想是，它可以在与非RadSec客户端或服务器相同的主机上使用，以确保RadSec在线路上使用；但是，作为通用代理，它也可以用于其他情况。
The configuration file consists of client and server clauses, where there is one such clause for each client or server. In such a clause, one specifies either "type tls" or "type udp" for TLS or UDP transport. Versions prior to 1.6 used "mysecret" as a default shared secret for RADIUS/TLS; version 1.6 and onwards uses "radsec". For backwards compatibility with older versions, the secret can be changed (which makes the configuration not compliant with this specification).
配置文件由客户机和服务器子句组成，其中每个客户机或服务器都有一个这样的子句。在这样的子句中，可以为tls或udp传输指定“类型tls”或“类型udp”。1.6之前的版本使用“mysecret”作为RADIUS/TLS的默认共享机密；1.6版及以上版本使用“radsec”。为了与旧版本向后兼容，可以更改机密（这使得配置不符合此规范）。
In order to use TLS for clients and/or servers, one must also specify where to locate CA certificates, as well as certificate and key for the client or server. This is done in a TLS clause. There may be one or several TLS clauses. A client or server clause may reference a particular TLS clause, or just use a default one. One use for multiple TLS clauses may be to present one certificate to clients and another to servers.
为了对客户端和/或服务器使用TLS，还必须指定CA证书的位置，以及客户端或服务器的证书和密钥。这在TLS条款中完成。可能有一个或多个TLS条款。客户机或服务器子句可以引用特定的TLS子句，或者只使用默认的TLS子句。多个TLS子句的一个用途可能是向客户端提供一个证书，向服务器提供另一个证书。
If any RadSec (TLS) clients are configured, the proxy will, at startup, listen on port 2083, as assigned by IANA for the OSC RadSec implementation. An alternative port may be specified. When a client connects, the client certificate will be verified, including checking that the configured Fully Qualified Domain Name (FQDN) or IP address matches what is in the certificate. Requests coming from a RadSec client are treated exactly like requests from UDP clients.
如果配置了任何RadSec（TLS）客户端，则代理将在启动时侦听IANA为OSC RadSec实现分配的端口2083。可以指定替代端口。当客户端连接时，将验证客户端证书，包括检查配置的完全限定域名（FQDN）或IP地址是否与证书中的内容匹配。来自RadSec客户端的请求与来自UDP客户端的请求完全相同。
At startup, the proxy will try to establish a TLS connection to each (if any) of the configured RadSec (TLS) servers. If it fails to connect to a server, it will retry regularly. There is some back-off where it will retry quickly at first, and with longer intervals later. If a connection to a server goes down, it will also start retrying regularly. When setting up the TLS connection, the server certificate will be verified, including checking that the configured FQDN or IP address matches what is in the certificate. Requests are sent to a RadSec server, just like they would be to a UDP server.
启动时，代理将尝试建立到每个已配置RadSec（TLS）服务器（如果有）的TLS连接。如果无法连接到服务器，它将定期重试。有一些后退，它会在开始时快速重试，稍后会有更长的间隔。如果与服务器的连接中断，它也会开始定期重试。设置TLS连接时，将验证服务器证书，包括检查配置的FQDN或IP地址是否与证书中的内容匹配。请求被发送到RadSec服务器，就像发送到UDP服务器一样。
The proxy supports Status-Server messages. They are only sent to a server if enabled for that particular server. Status-Server requests are always responded to.
代理支持状态服务器消息。仅当为特定服务器启用时，才会将其发送到服务器。始终响应状态服务器请求。
This RadSec implementation has been successfully tested together with Radiator. It is a freely available, open-source implementation. For source code and documentation, see [radsecproxy-impl].
该RadSec实施已与散热器一起成功测试。它是一个免费提供的开源实现。有关源代码和文档，请参阅[radsecproxy impl]。
The RADIUS Crypto-Agility Requirements document [RFC6421] defines numerous classification criteria for protocols that strive to enhance the security of RADIUS. It contains mandatory (M) and recommended (R) criteria that crypto-agile protocols have to fulfill. The authors believe that the following assessment about the crypto-agility properties of RADIUS/TLS are true.
RADIUS加密敏捷性要求文件[RFC6421]为旨在增强RADIUS安全性的协议定义了许多分类标准。它包含加密敏捷协议必须满足的强制性（M）和建议性（R）标准。作者相信以下关于RADIUS/TLS加密敏捷性的评估是正确的。
By virtue of being a transport profile using TLS over TCP as a transport protocol, the cryptographically agile properties of TLS are inherited, and RADIUS/TLS subsequently meets the following points:
由于是使用TCP上的TLS作为传输协议的传输配置文件，TLS的加密灵活特性被继承，RADIUS/TLS随后满足以下几点：
(M) negotiation of cryptographic algorithms for integrity and auth
（M） 密码算法的完整性和身份验证协商
(M) negotiation of cryptographic algorithms for encryption
（M） 用于加密的密码算法协商
(M) replay protection
（M） 重放保护
(M) define mandatory-to-implement cryptographic algorithms
（M） 定义强制以实现加密算法
(M) generate fresh session keys for use between client and server
（M） 生成新的会话密钥以在客户端和服务器之间使用
(R) support for Perfect Forward Secrecy in session keys
（R） 在会话密钥中支持完美的前向保密性
(R) support X.509 certificate-based operation
（R） 支持X.509基于证书的操作
(R) support Pre-Shared keys
（R） 支持预共享密钥
(R) support for confidentiality of the entire packet
（R） 支持整个数据包的机密性
(M/R) support Automated Key Management
（M/R）支持自动密钥管理
The remainder of the requirements is discussed individually below in more detail:
下文将详细讨论其余要求：
(M) "...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" [RFC6421]. The existing algorithm, based on MD5, is not of any significance in RADIUS/TLS; its compromise does not compromise the outer transport security.
（M） “…即使在RADIUS实现所使用的现有加密算法显示出足够弱，无法提供很少或没有安全性的情况下，也要避免安全隐患”[RFC6421]。现有的基于MD5的算法在RADIUS/TLS中没有任何意义；它的妥协并不影响外部运输安全。
(R) mandatory-to-implement algorithms are to be NIST-Acceptable with no deprecation date - The mandatory-to-implement algorithm is TLS_RSA_WITH_3DES_EDE_CBC_SHA. This ciphersuite supports three-key 3DES operation, which is classified as Acceptable with no known deprecation date by NIST.
（R） 实施算法的强制性要求是NIST可接受的，无弃用日期-实施算法的强制性要求是TLS_RSA_和_3DES_EDE_CBC_SHA。该密码套件支持三个关键的3DES操作，NIST将其归类为可接受，且不知道弃用日期。
(M) demonstrate backward compatibility with RADIUS - There are multiple implementations supporting both RADIUS and RADIUS/TLS, and the translation between them.
（M） 演示与RADIUS的向后兼容性-有多个实现同时支持RADIUS和RADIUS/TLS以及它们之间的转换。
(M) After legacy mechanisms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible - In RADIUS, communication between client and server is always a manual configuration; after a compromise, the legacy client in question can be de-configured by the same manual configuration.
（M） 在遗留机制被破坏后，必须使用安全算法，这样向后兼容就不再可能——在RADIUS中，客户端和服务器之间的通信始终是手动配置；在折衷之后，可以通过相同的手动配置来取消所讨论的旧客户端的配置。
(M) indicate a willingness to cede change control to the IETF - Change control of this protocol is with the IETF.
（M） 表示愿意将变更控制权移交给IETF——本协议的变更控制权由IETF负责。
(M) be interoperable between implementations based purely on the information in the specification - At least one implementation was created exclusively based on this specification and is interoperable with other RADIUS/TLS implementations.
（M） 完全基于规范中的信息，实现之间可以互操作-至少有一个实现是专门基于本规范创建的，并且可以与其他RADIUS/TLS实现互操作。
(M) apply to all packet types - RADIUS/TLS operates on the transport layer, and can carry all packet types.
（M） 适用于所有数据包类型-RADIUS/TLS在传输层上运行，可以承载所有数据包类型。
(R) message data exchanged with Diameter SHOULD NOT be affected - The solution is Diameter-agnostic.
（R） 与Diameter交换的消息数据不应受到影响-解决方案与Diameter无关。
(M) discuss any inherent assumptions - The authors are not aware of any implicit assumptions that would be yet-unarticulated in the document.
（M） 讨论任何固有假设-作者不知道文件中尚未明确的任何隐含假设。
(R) provide recommendations for transition - The Security Considerations section contains a transition path.
（R） 提供转换建议-安全注意事项部分包含转换路径。
(R) discuss legacy interoperability and potential for bidding-down attacks - The Security Considerations section contains a corresponding discussion.
（R） 讨论遗留互操作性和降低攻击的可能性-安全注意事项部分包含相应的讨论。
Summarizing, it is believed that this specification fulfills all the mandatory and all the recommended requirements for a crypto-agile solution and should thus be considered UNCONDITIONALLY COMPLIANT.
总之，人们认为本规范满足加密敏捷解决方案的所有强制性要求和所有建议要求，因此应被视为无条件符合。
Authors' Addresses
作者地址
Stefan Winter Fondation RESTENA 6, rue Richard Coudenhove-Kalergi Luxembourg 1359 Luxembourg
卢森堡里查德·库登霍夫·卡勒吉街Stefan Winter Foundation RESTENA 6号卢森堡1359
Phone: +352 424409 1 Fax: +352 422473 EMail: stefan.winter@restena.lu URI: http://www.restena.lu.
电话：+352 424409 1传真：+352 422473电子邮件：stefan。winter@restena.luURI:http://www.restena.lu.
Mike McCauley Open Systems Consultants 9 Bulbul Place Currumbin Waters QLD 4223 Australia
Mike McCauley开放系统咨询公司9 Bulbul Place Currumbin Waters昆士兰州4223澳大利亚
Phone: +61 7 5598 7474 Fax: +61 7 5598 7070 EMail: mikem@open.com.au URI: http://www.open.com.au.
电话：+61 7 5598 7474传真：+61 7 5598 7070电子邮件：mikem@open.com.auURI:http://www.open.com.au.
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道Stig Venaas思科系统公司，邮编95134
EMail: stig@cisco.com
EMail: stig@cisco.com
Klaas Wierenga Cisco Systems International BV Haarlerbergweg 13-19 Amsterdam 1101 CH The Netherlands
克拉斯·维伦加思科系统国际有限公司哈勒贝格韦格13-19阿姆斯特丹1101 CH荷兰
Phone: +31 (0)20 3571752
EMail: klaas@cisco.com
URI: http://www.cisco.com
Phone: +31 (0)20 3571752
EMail: klaas@cisco.com
URI: http://www.cisco.com