Internet Engineering Task Force (IETF) S. Winter
Request for Comments: 7585 RESTENA
Category: Experimental M. McCauley
ISSN: 2070-1721 AirSpayce
October 2015
Internet Engineering Task Force (IETF) S. Winter
Request for Comments: 7585 RESTENA
Category: Experimental M. McCauley
ISSN: 2070-1721 AirSpayce
October 2015
Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)
基于网络访问标识符（NAI）的RADIUS/TLS和RADIUS/DTL动态对等发现
Abstract
摘要
This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS).
本文档指定了为给定领域查找权威RADIUS服务器的方法。它与RADIUS上传输层安全（RADIUS/TLS）或RADIUS上数据报传输层安全（RADIUS/DTLS）结合使用。
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/rfc7585.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7585.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. DNS Resource Record (RR) Definition . . . . . . . . . . . 7
2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3. Optional Name Mangling . . . . . . . . . . . . . . . 12
2.2. Definition of the X.509 Certificate Property
SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 14
3. DNS-Based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 16
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Configuration Variables . . . . . . . . . . . . . . . . . 16
3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4. Realm to RADIUS Server Resolution Algorithm . . . . . . . 17
3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 18
3.4.4. Validity of Results . . . . . . . . . . . . . . . . . 20
3.4.5. Delay Considerations . . . . . . . . . . . . . . . . 21
3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 21
4. Operations and Manageability Considerations . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. ASN.1 Syntax of NAIRealm . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. DNS Resource Record (RR) Definition . . . . . . . . . . . 7
2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3. Optional Name Mangling . . . . . . . . . . . . . . . 12
2.2. Definition of the X.509 Certificate Property
SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 14
3. DNS-Based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 16
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Configuration Variables . . . . . . . . . . . . . . . . . 16
3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4. Realm to RADIUS Server Resolution Algorithm . . . . . . . 17
3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 18
3.4.4. Validity of Results . . . . . . . . . . . . . . . . . 20
3.4.5. Delay Considerations . . . . . . . . . . . . . . . . 21
3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 21
4. Operations and Manageability Considerations . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. ASN.1 Syntax of NAIRealm . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP, RADIUS/TLS, and RADIUS/DTLS) requires manual configuration of all peers (clients and servers).
RADIUS的所有当前传输变体（RADIUS/UDP、RADIUS/TCP、RADIUS/TLS和RADIUS/DTLS）都需要手动配置所有对等方（客户端和服务器）。
Where more than one administrative entity collaborates for RADIUS authentication of their respective customers (a "roaming consortium"), the Network Access Identifier (NAI) [RFC7542] is the suggested way of differentiating users between those entities; the part of a username to the right of the "@" delimiter in an NAI is called the user's "realm". Where many realms and RADIUS forwarding servers are in use, the number of realms to be forwarded and the corresponding number of servers to configure may be significant. Where new realms with new servers are added or details of existing servers change on a regular basis, maintaining a single monolithic configuration file for all these details may prove too cumbersome to be useful.
如果多个管理实体合作对其各自客户进行RADIUS认证（“漫游联盟”），则网络访问标识符（NAI）[RFC7542]是区分这些实体之间用户的建议方法；NAI中“@”分隔符右侧的用户名部分称为用户的“领域”。在使用多个领域和RADIUS转发服务器的情况下，要转发的领域数量和要配置的相应服务器数量可能非常重要。如果添加了具有新服务器的新领域，或者定期更改现有服务器的详细信息，那么为所有这些详细信息维护一个单一的配置文件可能过于繁琐而没有用处。
Furthermore, in cases where a roaming consortium consists of independently working branches (e.g., departments and national subsidiaries), each with their own forwarding servers, and who add or change their realm lists at their own discretion, there is additional complexity in synchronizing the changed data across all branches.
此外，如果漫游联盟由独立工作的分支机构（例如，部门和国家级子公司）组成，每个分支机构都有自己的转发服务器，并自行决定添加或更改其领域列表，则在所有分支机构之间同步更改的数据会增加复杂性。
Where realms can be partitioned (e.g., according to their top-level domain (TLD) ending), forwarding of requests can be realized with a hierarchy of RADIUS servers, all serving their partition of the realm space. Figure 1 shows an example of this hierarchical routing.
如果可以对领域进行分区（例如，根据其顶级域（TLD）结尾），则可以通过RADIUS服务器的层次结构实现请求的转发，所有服务器都为领域空间的分区服务。图1显示了这种分层路由的示例。
+-------+
| |
| . |
| |
+---+---+
/ | \
+----------------/ | \---------------------+
| | |
| | |
| | |
+--+---+ +--+--+ +----+---+
| | | | | |
| .edu | . . . | .nl | . . . | .ac.uk |
| | | | | |
+--+---+ +--+--+ +----+---+
/ | \ | \ |
/ | \ | \ |
/ | \ | \ |
+-----+ | +-----+ | +------+ |
| | | | | |
| | | | | |
+---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
| | | | | | | | | | | |
|utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
| | | | | | | | | | | |
+----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
| |
| |
+--+--+ +--+--+
| | | |
+-+-----+-+ | |
| | +-----+
+---------+
user: paul@surfnet.nl surfnet.nl Authentication server
+-------+
| |
| . |
| |
+---+---+
/ | \
+----------------/ | \---------------------+
| | |
| | |
| | |
+--+---+ +--+--+ +----+---+
| | | | | |
| .edu | . . . | .nl | . . . | .ac.uk |
| | | | | |
+--+---+ +--+--+ +----+---+
/ | \ | \ |
/ | \ | \ |
/ | \ | \ |
+-----+ | +-----+ | +------+ |
| | | | | |
| | | | | |
+---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
| | | | | | | | | | | |
|utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
| | | | | | | | | | | |
+----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
| |
| |
+--+--+ +--+--+
| | | |
+-+-----+-+ | |
| | +-----+
+---------+
user: paul@surfnet.nl surfnet.nl Authentication server
Figure 1: RADIUS Hierarchy Based on Top-Level Domain Partitioning
图1：基于顶级域分区的RADIUS层次结构
However, such partitioning is not always possible. As an example, in one real-life deployment, the administrative boundaries and RADIUS forwarding servers are organized along country borders, but generic top-level domains such as .edu do not map to this choice of boundaries (see [RFC7593] for details). These situations can benefit significantly from a distributed mechanism for storing realm and server reachability information. This document describes one such mechanism: storage of realm-to-server mappings in DNS; realm-based request forwarding can then be realized without a static hierarchy such as in the following figure:
然而，这种划分并不总是可能的。例如，在一个实际部署中，管理边界和RADIUS转发服务器沿国家边界组织，但通用顶级域（如.edu）不映射到此边界选择（有关详细信息，请参见[RFC7593]）。这些情况可以从存储领域和服务器可达性信息的分布式机制中获益匪浅。本文描述了这样一种机制：在DNS中存储领域到服务器的映射；然后，可以在没有静态层次结构的情况下实现基于领域的请求转发，如下图所示：
---------
/ \
--------- ------------
/ \
| DNS -
----------| \
/ \ surfnet.nl NAPTR? |
(1) / ---- -> radius.surfnet.nl /
/ \ /
/ -------- ---------
/ \---------/
|
| ---------------------------------------
| / (2) RADIUS \
| | |
+---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
| | | | | | | | | | | |
|utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
| | | | | | | | | | | |
+----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
| |
| |
+--+--+ +--+--+
| | | |
+-+-----+-+ | |
| | +-----+
+---------+
user: paul@surfnet.nl surfnet.nl Authentication server
---------
/ \
--------- ------------
/ \
| DNS -
----------| \
/ \ surfnet.nl NAPTR? |
(1) / ---- -> radius.surfnet.nl /
/ \ /
/ -------- ---------
/ \---------/
|
| ---------------------------------------
| / (2) RADIUS \
| | |
+---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
| | | | | | | | | | | |
|utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
| | | | | | | | | | | |
+----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
| |
| |
+--+--+ +--+--+
| | | |
+-+-----+-+ | |
| | +-----+
+---------+
user: paul@surfnet.nl surfnet.nl Authentication server
Figure 2: RADIUS Hierarchy Based on Top-Level Domain Partitioning
图2：基于顶级域分区的RADIUS层次结构
This document also specifies various approaches for verifying that server information that was retrieved from DNS was from an authorized party; for example, an organization that is not at all part of a given roaming consortium may alter its own DNS records to yield a result for its own realm.
本文件还规定了验证从DNS检索的服务器信息是否来自授权方的各种方法；例如，完全不属于给定漫游联盟的组织可能会更改其自己的DNS记录，以生成其自己领域的结果。
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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
在本文件中，使用了几个词来表示规范的要求。本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance that initiates a new connection.
RADIUS/TLS客户端：启动新连接的RADIUS/TLS[RFC6614]实例。
RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance that listens on a RADIUS/TLS port and accepts new connections.
RADIUS/TLS服务器：侦听RADIUS/TLS端口并接受新连接的RADIUS/TLS[RFC6614]实例。
RADIUS/TLS Node: a RADIUS/TLS client or server.
RADIUS/TLS节点：RADIUS/TLS客户端或服务器。
[RFC7542] defines the terms NAI, realm, and consortium.
[RFC7542]定义了术语NAI、领域和联盟。
This document is an Experimental RFC.
本文档是一个实验性RFC。
The communities expected to use this document are roaming consortia whose authentication services are based on the RADIUS protocol.
预期使用本文档的社区是漫游联盟，其身份验证服务基于RADIUS协议。
The duration of the experiment is undetermined; as soon as enough experience is collected on the choice points mentioned below, it is expected to be obsoleted by a Standards Track version of the protocol, which trims down the choice points.
实验的持续时间尚未确定；一旦在以下提到的选择点上收集到足够的经验，它将被协议的标准跟踪版本淘汰，该版本将精简选择点。
If that removal of choice points obsoletes tags or service names as defined in this document and allocated by IANA, these items will be returned to IANA as per the provisions in [RFC6335].
如果选择点的删除使本文件中定义的标签或服务名称作废，并由IANA分配，则这些项目将按照[RFC6335]中的规定返还给IANA。
The document provides a discovery mechanism for RADIUS, which is very similar to the approach that is taken with the Diameter protocol [RFC6733]. As such, the basic approach (using Naming Authority Pointer (NAPTR) records in DNS domains that match NAI realms) is not of a very experimental nature.
该文档提供了RADIUS的发现机制，这与Diameter协议[RFC6733]采用的方法非常相似。因此，基本方法（在匹配NAI领域的DNS域中使用命名机构指针（NAPTR）记录）不是一种非常实验性的方法。
However, the document offers a few choice points and extensions that go beyond the provisions for Diameter. The list of major additions/ deviations is
然而，该文件提供了一些超出直径规定的选择点和扩展。主要增加/偏差列表如下所示
o provisions for determining the authority of a server to act for users of a realm (declared out of scope for Diameter)
o 用于确定服务器为领域用户执行操作的权限的规定（已声明超出Diameter的范围）
o much more in-depth guidance on DNS regarding timeouts, failure conditions, and alteration of Time-To-Live (TTL) information than the Diameter counterpart
o 关于超时、故障条件和生存时间（TTL）信息更改的DNS指南比Diameter指南更深入
o a partially correct routing error detection during DNS lookups
o DNS查找期间的部分正确路由错误检测
DNS definitions of RADIUS/TLS servers can be either S-NAPTR records (see [RFC3958]) or SRV records. When both are defined, the resolution algorithm prefers S-NAPTR results (see Section 3.4 below).
RADIUS/TLS服务器的DNS定义可以是S-NAPTR记录（请参见[RFC3958]）或SRV记录。当两者都被定义时，解析算法更倾向于S-NAPTR结果（见下文第3.4节）。
This specification defines three S-NAPTR service tags:
本规范定义了三个S-NAPTR服务标签：
+-----------------+-----------------------------------------+
| Service Tag | Use |
+-----------------+-----------------------------------------+
| aaa+auth | RADIUS Authentication, i.e., traffic as |
| | defined in [RFC2865] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| aaa+acct | RADIUS Accounting, i.e., traffic as |
| | defined in [RFC2866] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| aaa+dynauth | RADIUS Dynamic Authorization, i.e., |
| | traffic as defined in [RFC5176] |
+-----------------+-----------------------------------------+
+-----------------+-----------------------------------------+
| Service Tag | Use |
+-----------------+-----------------------------------------+
| aaa+auth | RADIUS Authentication, i.e., traffic as |
| | defined in [RFC2865] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| aaa+acct | RADIUS Accounting, i.e., traffic as |
| | defined in [RFC2866] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| aaa+dynauth | RADIUS Dynamic Authorization, i.e., |
| | traffic as defined in [RFC5176] |
+-----------------+-----------------------------------------+
Figure 3: List of Service Tags
图3：服务标签列表
This specification defines two S-NAPTR protocol tags:
本规范定义了两个S-NAPTR协议标签：
+-----------------+-----------------------------------------+
| Protocol Tag | Use |
+-----------------+-----------------------------------------+
| radius.tls.tcp | RADIUS transported over TLS as defined |
| | in [RFC6614] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| radius.dtls.udp | RADIUS transported over DTLS as defined |
| | in [RFC7360] |
+-----------------+-----------------------------------------+
+-----------------+-----------------------------------------+
| Protocol Tag | Use |
+-----------------+-----------------------------------------+
| radius.tls.tcp | RADIUS transported over TLS as defined |
| | in [RFC6614] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| radius.dtls.udp | RADIUS transported over DTLS as defined |
| | in [RFC7360] |
+-----------------+-----------------------------------------+
Figure 4: List of Protocol Tags
图4：协议标签列表
Note well:
请注意：
The S-NAPTR service and protocols are unrelated to the IANA "Service Name and Transport Protocol Port Number Registry".
S-NAPTR服务和协议与IANA“服务名称和传输协议端口号注册表”无关。
The delimiter "." in the protocol tags is only a separator for human reading convenience -- not for structure or namespacing; it MUST NOT be parsed in any way by the querying application or resolver.
协议标记中的分隔符“.”只是一个便于阅读的分隔符，而不是用于结构或名称空间；查询应用程序或解析器不得以任何方式对其进行解析。
The use of the separator "." is common also in other protocols' protocol tags. This is coincidence and does not imply a shared semantics with such protocols.
分隔符“.”的使用在其他协议的协议标记中也很常见。这是巧合，并不意味着与此类协议共享语义。
RADIUS is a time-critical protocol; RADIUS clients that do not receive an answer after a configurable, but short, amount of time will consider the request failed. Due to this, there is little leeway for extensive retries.
RADIUS是一个时间关键协议；RADIUS客户端在一个可配置的但短的时间内没有接收到应答，将考虑请求失败。因此，几乎没有进行大量重试的余地。
As a general rule, only error conditions that generate an immediate response from the other end are eligible for a retry of a discovered target. Any error condition involving timeouts, or the absence of a reply for more than one second during the connection setup phase, is to be considered a failure; the next target in the set of discovered NAPTR targets is to be tried.
一般来说，只有从另一端生成即时响应的错误条件才有资格重试发现的目标。任何涉及超时的错误情况，或在连接设置阶段超过1秒没有回复，都将被视为失败；将尝试发现的NAPTR目标集中的下一个目标。
Note that [RFC3958] already defines that a failure to identify the server as being authoritative for the realm is always considered a failure; so even if a discovered target returns a wrong credential instantly, it is not eligible for retry.
请注意，[RFC3958]已经定义，未能将服务器标识为领域的权威服务器始终视为故障；因此，即使发现的目标立即返回错误的凭据，它也没有资格重试。
Furthermore, the contacted RADIUS/TLS server verifies during connection setup whether or not it finds the connecting RADIUS/TLS client authorized. If the connecting RADIUS/TLS client is not found acceptable, the server will close the TLS connection immediately with an appropriate alert. Such TLS handshake failures are permanently fatal and not eligible for retry, unless the connecting client has more X.509 certificates to try; in this case, a retry with the remainder of its set of certificates SHOULD be attempted. Not trying all available client certificates potentially creates a DoS for the end user whose authentication attempt triggered the discovery; one of the neglected certificates might have led to a successful RADIUS connection and subsequent end-user authentication.
此外，已联系的RADIUS/TLS服务器在连接设置期间验证是否找到已授权的连接RADIUS/TLS客户端。如果发现连接RADIUS/TLS客户端不可接受，服务器将立即关闭TLS连接并发出相应警报。这种TLS握手失败是永久性的致命错误，不适合重试，除非连接客户端有更多的X.509证书要尝试；在这种情况下，应尝试使用其证书集的其余部分重试。不尝试所有可用的客户端证书可能会为其身份验证尝试触发发现的最终用户创建DoS；其中一个被忽略的证书可能导致成功的RADIUS连接和后续的最终用户身份验证。
If the TLS session setup to a discovered target does not succeed, that target (as identified by the IP address and port number) SHOULD be ignored from the result set of any subsequent executions of the discovery algorithm at least until the target's Effective TTL (see Section 3.3) has expired or until the entity that executes the algorithm changes its TLS context to either send a new client certificate or expect a different server certificate.
如果发现目标的TLS会话设置未成功，则至少在目标的有效TTL之前，该目标（由IP地址和端口号标识）应从发现算法的任何后续执行的结果集中忽略（见第3.3节）已过期或直到执行算法的实体更改其TLS上下文以发送新的客户端证书或期望其他服务器证书。
After the algorithm in this document has been executed, a RADIUS/TLS session as per [RFC6614] is established. Since the discovery algorithm does not have provisions to establish confidential keying material between the RADIUS/TLS client (i.e., the server that executes the discovery algorithm) and the RADIUS/TLS server that was discovered, Pre-Shared Key (PSK) ciphersuites for TLS cannot be used in the subsequent TLS handshake. Only TLS ciphersuites using X.509 certificates can be used with this algorithm.
执行本文件中的算法后，根据[RFC6614]建立RADIUS/TLS会话。由于发现算法没有规定在RADIUS/TLS客户端（即执行发现算法的服务器）和被发现的RADIUS/TLS服务器之间建立机密密钥材料，因此TLS的预共享密钥（PSK）密码套件不能用于后续TLS握手。此算法只能使用使用X.509证书的TLS密码套件。
There are numerous ways to define which certificates are acceptable for use in this context. This document defines one mandatory-to-implement mechanism that allows verification of whether the contacted host is authoritative for an NAI realm or not. It also gives one example of another mechanism that is currently in widespread deployment and one possible approach based on DNSSEC, which is yet unimplemented.
有许多方法可以定义哪些证书可以在这种情况下使用。本文档定义了一种强制实现机制，该机制允许验证所联系的主机是否具有NAI领域的权威性。它还提供了目前正在广泛部署的另一种机制的一个示例，以及一种基于DNSSEC的可能方法，该方法尚未实现。
For the approaches that use trust roots (see the following two sections), a typical deployment will use a dedicated trust store for RADIUS/TLS certificate authorities, particularly a trust store that is independent from default "browser" trust stores. Often, this will be one or a few Certification Authorities (CAs), and they only issue certificates for the specific purpose of establishing RADIUS server-to-server trust. It is important not to trust a large set of CAs that operate outside the control of the roaming consortium, since their issuance of certificates with the properties important for authorization (such as NAIRealm and policyOID below) is difficult to verify. Therefore, clients SHOULD NOT be preconfigured 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.
对于使用信任根的方法（请参见以下两部分），典型的部署将为RADIUS/TLS证书颁发机构使用专用的信任存储，特别是独立于默认“浏览器”信任存储的信任存储。通常，这将是一个或几个证书颁发机构（CA），它们仅为建立RADIUS服务器到服务器信任的特定目的颁发证书。重要的是，不要信任在漫游联盟控制范围之外运行的大量CA，因为它们颁发的证书具有对授权很重要的属性（如下面的NAIRealm和policyOID）很难验证。因此，供应商或制造商不应使用已知公共CA列表预配置客户端。相反，客户端应该从一个空的CA列表开始。仅当管理员手动配置时，才应添加CA。
Verification of authority to provide Authentication, Authorization, and Accounting (AAA) services over RADIUS/TLS is a two-step process.
验证通过RADIUS/TLS提供身份验证、授权和记帐（AAA）服务的权限是一个两步过程。
Step 1 is the verification of certificate well-formedness and validity as per [RFC5280] and whether it was issued from a root certificate that is deemed trustworthy by the RADIUS/TLS client.
步骤1是根据[RFC5280]验证证书的良好格式和有效性，以及它是否由RADIUS/TLS客户端认为可信的根证书颁发。
Step 2 is to compare the value of the algorithm's variable "R" after the execution of step 3 of the discovery algorithm in Section 3.4.3 below (i.e., after a consortium name mangling but before conversion to a form usable by the name resolution library) to all values of the
第2步是在执行下文第3.4.3节中发现算法的第3步后（即，在联合体名称损坏后，但在转换为名称解析库可用的形式之前），将算法变量“R”的值与
contacted RADIUS/TLS server's X.509 certificate property "subjectAlternativeName:otherName:NAIRealm" as defined in Section 2.2.
已联系RADIUS/TLS服务器的X.509证书属性“subjectAlternativeName:otherName:NAIRealm”，定义见第2.2节。
Verification of authority to provide AAA services over RADIUS/TLS is a two-step process.
通过RADIUS/TLS提供AAA服务的权限验证分为两步。
Step 1 is the verification of certificate well-formedness and validity as per [RFC5280] and whether it was issued from a root certificate that is deemed trustworthy by the RADIUS/TLS client.
步骤1是根据[RFC5280]验证证书的良好格式和有效性，以及它是否由RADIUS/TLS客户端认为可信的根证书颁发。
Step 2 is to compare the values of the contacted RADIUS/TLS server's X.509 certificate's extensions of type "Policy OID" to a list of configured acceptable Policy OIDs for the roaming consortium. If one of the configured OIDs is found in the certificate's Policy OID extensions, then the server is considered authorized; if there is no match, the server is considered unauthorized.
步骤2是将所联系的RADIUS/TLS服务器的X.509证书的“策略OID”类型扩展的值与为漫游联盟配置的可接受策略OID的列表进行比较。如果在证书的策略OID扩展中找到一个已配置的OID，则认为服务器已授权；如果不匹配，则认为服务器未经授权。
This mechanism is inferior to the mandatory-to-implement mechanism in the previous section because all authorized servers are validated by the same OID value; the mechanism is not fine grained enough to express authority for one specific realm inside the consortium. If the consortium contains members that are hostile against other members, this weakness can be exploited by one RADIUS/TLS server impersonating another if DNS responses can be spoofed by the hostile member.
此机制不如前一节中的强制实现机制，因为所有授权服务器都由相同的OID值验证；该机制不够细粒度，无法表达联盟内部某个特定领域的权限。如果联合体包含对其他成员怀有敌意的成员，如果恶意成员可以欺骗DNS响应，则一台RADIUS/TLS服务器可以模拟另一台RADIUS/TLS服务器来利用此弱点。
The shortcomings in server identification can be partially mitigated by using the RADIUS infrastructure only with authentication payloads that provide mutual authentication and credential protection (i.e., Extensible Authentication Protocol (EAP) types passing the criteria of [RFC4017]): using mutual authentication prevents the hostile server from mimicking the real EAP server (it can't terminate the EAP authentication unnoticed because it does not have the server certificate from the real EAP server); protection of credentials prevents the impersonating server from learning usernames and passwords of the ongoing EAP conversation (other RADIUS attributes pertaining to the authentication, such as the EAP peer's Calling-Station-ID, can still be learned though).
通过使用RADIUS基础设施，仅使用提供相互身份验证和凭证保护的身份验证有效负载（即通过[RFC4017]标准的可扩展身份验证协议（EAP）类型），可以部分缓解服务器标识方面的缺点：使用相互身份验证可防止恶意服务器模仿真实EAP服务器（它不能在未被注意的情况下终止EAP身份验证，因为它没有来自真实EAP服务器的服务器证书）；凭据保护可防止模拟服务器学习正在进行的EAP会话的用户名和密码（但仍可学习与身份验证相关的其他RADIUS属性，如EAP对等方的呼叫站ID）。
Where DNSSEC is used, the results of the algorithm can be trusted; that is, the entity that executes the algorithm can be certain that the realm that triggered the discovery is actually served by the server that was discovered via DNS. However, this does not guarantee
在使用DNSSEC的情况下，算法的结果是可信的；也就是说，执行算法的实体可以确定触发发现的领域实际上由通过DNS发现的服务器提供服务。然而，这并不能保证
that the server is also authorized (i.e., a recognized member of the roaming consortium). The server still needs to present an X.509 certificate proving its authority to serve a particular realm.
服务器也被授权（即，漫游联盟的公认成员）。服务器仍然需要提供一个X.509证书，以证明其服务于特定领域的权限。
The authorization can be sketched using DNSSEC and DNS-Based Authentication of Named Entities (DANE) as follows: DANE/TLSA records of all authorized servers are put into a DNSSEC zone that contains all known and authorized realms; the zone is rooted in a common, consortium-agreed branch of the DNS tree. The entity executing the algorithm uses the realm information from the authentication attempt and then attempts to retrieve TLSA resource records (TLSA RRs) for the DNS label "realm.commonroot". It then verifies that the presented server certificate during the RADIUS/TLS handshake matches the information in the TLSA record.
可以使用DNSSEC和基于DNS的命名实体身份验证（DANE）绘制授权草图，如下所示：所有授权服务器的DANE/TLSA记录被放入包含所有已知和授权领域的DNSSEC区域；该区域植根于DNS树的一个共同的、财团同意的分支。执行算法的实体使用身份验证尝试中的领域信息，然后尝试检索DNS标签“realm.commonroot”的TLSA资源记录（TLSA RRs）。然后验证RADIUS/TLS握手期间提供的服务器证书是否与TLSA记录中的信息匹配。
Example:
例子：
Realm = "example.com"
Realm=“example.com”
Common Branch = "idp.roaming-consortium.example.
Common Branch=“idp.roaming-consortium.example。
label for TLSA query = "example.com.idp.roaming-consortium.example.
TLSA查询标签=“example.com.idp.roaming-consortium.example。
result of discovery algorithm for realm "example.com" = 192.0.2.1:2083
领域“example.com”的发现算法结果=192.0.2.1:2083
( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" : "FAIL" )
（192.0.2.1:2083的TLS证书与TLSA RR相匹配？“通过”：“失败”）
Note that RADIUS/TLS connections always mutually authenticate the RADIUS server and the RADIUS client. This specification provides an algorithm for a RADIUS client to contact and verify authorization of a RADIUS server only. During connection setup, the RADIUS server also needs to verify whether it considers the connecting RADIUS client authorized; this is outside the scope of this specification.
请注意，RADIUS/TLS连接始终相互验证RADIUS服务器和RADIUS客户端。本规范为RADIUS客户端提供了一种算法，用于仅联系和验证RADIUS服务器的授权。在连接设置期间，RADIUS服务器还需要验证其是否认为连接RADIUS客户端已授权；这超出了本规范的范围。
This specification defines two SRV prefixes (i.e., two values for the "_service._proto" part of an SRV RR as per [RFC2782]):
本规范定义了两个SRV前缀（即，根据[RFC2782]），SRV RR中“_服务._协议”部分的两个值：
+-------------------+-----------------------------------------+
| SRV Label | Use |
+-------------------+-----------------------------------------+
| _radiustls._tcp | RADIUS transported over TLS as defined |
| | in [RFC6614] |
| - - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| _radiusdtls._udp | RADIUS transported over DTLS as defined |
| | in [RFC7360] |
+-------------------+-----------------------------------------+
+-------------------+-----------------------------------------+
| SRV Label | Use |
+-------------------+-----------------------------------------+
| _radiustls._tcp | RADIUS transported over TLS as defined |
| | in [RFC6614] |
| - - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| _radiusdtls._udp | RADIUS transported over DTLS as defined |
| | in [RFC7360] |
+-------------------+-----------------------------------------+
Figure 5: List of SRV Labels
图5：SRV标签列表
Just like NAPTR records, the lookup and subsequent follow up of SRV records may yield more than one server to contact in a prioritized list. [RFC2782] does not specify rules regarding "Definition of Conditions for Retry/Failure" nor "Server Identification and Handshake". This specification states that the rules for these two topics as defined in Sections 2.1.1.2 and 2.1.1.3 SHALL be used both for targets retrieved via an initial NAPTR RR as well as for targets retrieved via an initial SRV RR (i.e., in the absence of NAPTR RRs).
与NAPTR记录一样，SRV记录的查找和后续跟踪可能会在优先列表中产生多个要联系的服务器。[RFC2782]未指定有关“重试/失败条件的定义”或“服务器标识和握手”的规则。本规范规定，第2.1.1.2节和第2.1.1.3节中定义的这两个主题的规则应用于通过初始NAPTR RR检索的目标以及通过初始SRV RR检索的目标（即，在没有NAPTR RR的情况下）。
It is expected that in most cases, the SRV and/or NAPTR label used for the records is the DNS A-label representation of the literal realm name for which the server is the authoritative RADIUS server (i.e., the realm name after conversion according to Section 5 of [RFC5891]).
预计在大多数情况下，用于记录的SRV和/或NAPTR标签是文字域名的DNS A标签表示，服务器是权威RADIUS服务器（即，根据[RFC5891]第5节转换后的域名）。
However, arbitrary other labels or service tags may be used if, for example, a roaming consortium uses realm names that are not associated to DNS names or special-purpose consortia where a globally valid discovery is not a use case. Such other labels require a consortium-wide agreement about the transformation from realm name to lookup label and/or which service tag to use.
然而，如果漫游联盟使用的域名与DNS名称或特殊用途联盟（其中全局有效的发现不是用例）无关，则可以使用任意其他标签或服务标签。此类其他标签需要在整个联盟范围内就从领域名称到查找标签的转换和/或使用哪个服务标签达成一致。
Examples:
示例：
a. A general-purpose RADIUS server for realm example.com might have DNS entries as follows:
a. realm example.com的通用RADIUS服务器可能具有以下DNS条目：
example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" _radiustls._tcp.foobar.example.com.
example.com。在NAPTR 50 50“s”aaa+auth:radius.tls.tcp“\u radiustls.\u tcp.foobar.example.com中。
_radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 radsec.example.com.
_radiustls.\u tcp.foobar.example.com。在SRV 0 10 2083 radsec.example.com中。
b. The consortium "foo" provides roaming services for its members only. The realms used are of the form enterprise-name.example. The consortium operates a special purpose DNS server for the (private) TLD "example", which all RADIUS servers use to resolve realm names. "Company, Inc." is part of the consortium. On the consortium's DNS server, realm company.example might have the following DNS entries:
b. 联合体“foo”仅为其成员提供漫游服务。所使用的领域的形式为enterprise-name.example。该联盟为（私有）TLD“示例”运行一个专用DNS服务器，所有RADIUS服务器都使用该服务器解析域名。“公司”是联合体的一部分。在联合体的DNS服务器上，realm company.example可能具有以下DNS条目：
company.example. IN NAPTR 50 50 "a" "aaa+auth:radius.dtls.udp" "" roamserv.company.example.
公司。例如。在NAPTR 50 50“a”中，aaa+auth:radius.dtls.udp“roamserv.company.example。
c. The eduroam consortium (see [RFC7593]) uses realms based on DNS but provides its services to a closed community only. However, a AAA domain participating in eduroam may also want to expose AAA services to other, general-purpose, applications (on the same or other RADIUS servers). Due to that, the eduroam consortium uses the service tag "x-eduroam" for authentication purposes and eduroam RADIUS servers use this tag to look up other eduroam servers. An eduroam participant example.org that also provides general-purpose AAA on a different server uses the general "aaa+auth" tag:
c. eduroam consortium（参见[RFC7593]）使用基于DNS的领域，但仅向封闭社区提供服务。但是，参与eduroam的AAA域可能还希望将AAA服务公开给其他通用应用程序（在相同或其他RADIUS服务器上）。因此，eduroam consortium使用服务标签“x-eduroam”进行身份验证，eduroam RADIUS服务器使用此标签查找其他eduroam服务器。在不同服务器上提供通用AAA的eduroam participant example.org使用通用“AAA+auth”标记：
example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" "" _radiustls._tcp.eduroam.example.org.
example.org。在NAPTR 50 50“s”中的“x-eduroam:radius.tls.tcp”“”\u radiustls.\u tcp.eduroam.example.org。
example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" _radiustls._tcp.aaa.example.org.
example.org。在NAPTR 50 50“s”aaa+auth:radius.tls.tcp“\u radiustls.\u tcp.aaa.example.org中。
_radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa-eduroam.example.org.
_radiustls._tcp.eduroam.example.org。在SRV 0 10 2083 aaa-eduroam.example.org中。
_radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa-default.example.org.
_radiustls._tcp.aaa.example.org。在SRV 0 10 2083 aaa-default.example.org中。
2.2. Definition of the X.509 Certificate Property SubjectAltName:otherName:NAIRealm
2.2. X.509证书属性SubjectName:otherName:NAIRealm的定义
This specification retrieves IP addresses and port numbers from the Domain Name System that are subsequently used to authenticate users via the RADIUS/TLS protocol. Regardless whether the results from DNS discovery are trustworthy or not (e.g., DNSSEC in use), it is always important to verify that the server that was contacted is authorized to service requests for the user that triggered the discovery process.
此规范从域名系统检索IP地址和端口号，这些地址和端口号随后用于通过RADIUS/TLS协议对用户进行身份验证。无论DNS发现的结果是否可信（例如，使用中的DNSSEC），务必验证所联系的服务器是否有权为触发发现过程的用户的请求提供服务。
The input to the algorithm is an NAI realm as specified in Section 3.4.1. As a consequence, the X.509 certificate of the server that is ultimately contacted for user authentication needs to be able to express that it is authorized to handle requests for that realm.
算法的输入是第3.4.1节规定的NAI域。因此，最终联系进行用户身份验证的服务器的X.509证书需要能够表示它有权处理该领域的请求。
Current subjectAltName fields do not semantically allow an NAI realm to be expressed; the field subjectAltName:dNSName is syntactically a good match but would inappropriately conflate DNS names and NAI realm names. Thus, this specification defines a new subjectAltName field to hold either a single NAI realm name or a wildcard name matching a set of NAI realms.
当前subjectAltName字段在语义上不允许表达NAI领域；字段subjectAltName:dNSName在语法上是一个很好的匹配项，但会不适当地将DNS名称和NAI领域名称混为一谈。因此，该规范定义了一个新的subjectAltName字段，用于保存单个NAI领域名称或与一组NAI领域匹配的通配符名称。
The subjectAltName:otherName:sRVName field certifies that a certificate holder is authorized to provide a service; this can be compared to the target of a DNS label's SRV resource record. If the Domain Name System is insecure, it is required that the label of the SRV record itself is known-correct. In this specification, that label is not known-correct; it is potentially derived from a (potentially untrusted) NAPTR resource record of another label. If DNS is not secured with DNSSEC, the NAPTR resource record may have been altered by an attacker with access to the Domain Name System resolution, and thus the label used to look up the SRV record may already be tainted. This makes subjectAltName:otherName:sRVName not a trusted comparison item.
subjectAltName:otherName:sRVName字段证明证书持有人有权提供服务；这可以与DNS标签的SRV资源记录的目标进行比较。如果域名系统不安全，则需要知道SRV记录本身的标签是否正确。在本规范中，该标签不正确；它可能来自另一个标签的（可能不受信任的）NAPTR资源记录。如果DNS未使用DNSSEC进行保护，则有权访问域名系统解析的攻击者可能已更改NAPTR资源记录，因此用于查找SRV记录的标签可能已被污染。这使得subjectAltName:otherName:sRVName不是受信任的比较项目。
Further to this, this specification's NAPTR entries may be of type "A", which does not involve resolution of any SRV records, which again makes subjectAltName:otherName:sRVName unsuited for this purpose.
除此之外，本规范的NAPTR条目可能是“A”类型，它不涉及任何SRV记录的解析，这再次使subjectAltName:otherName:sRVName不适合此用途。
This section defines the NAIRealm name as a form of otherName from the GeneralName structure in subjectAltName defined in [RFC5280].
本节从[RFC5280]中定义的subjectAltName中的GeneralName结构中将NAIRealm名称定义为otherName的一种形式。
id-on-naiRealm OBJECT IDENTIFIER ::= { id-on 8 }
id-on-naiRealm OBJECT IDENTIFIER ::= { id-on 8 }
ub-naiRealm-length INTEGER ::= 255
ub-naiRealm-length INTEGER ::= 255
NAIRealm ::= UTF8String (SIZE (1..ub-naiRealm-length))
NAIRealm ::= UTF8String (SIZE (1..ub-naiRealm-length))
The NAIRealm, if present, MUST contain an NAI realm as defined in [RFC7542]. It MAY substitute the leftmost dot-separated label of the NAI with the single character "*" to indicate a wildcard match for "all labels in this part". Further features of regular expressions, such as a number of characters followed by an "*" to indicate a common prefix inside the part, are not permitted.
NAI领域（如果存在）必须包含[RFC7542]中定义的NAI领域。它可以用单个字符“*”替换NAI最左边的点分隔标签，以表示通配符匹配“此部分中的所有标签”。不允许使用正则表达式的其他特性，例如后面带有“*”的字符数，以表示部件内部的公共前缀。
The comparison of an NAIRealm to the NAI realm as derived from user input with this algorithm is a byte-by-byte comparison, except for the optional leftmost dot-separated part of the value whose content is a single "*" character; such labels match all strings in the same dot-separated part of the NAI realm. If at least one of the sAN:otherName:NAIRealm values match the NAI realm, the server is considered authorized; if none match, the server is considered unauthorized.
使用此算法从用户输入导出的NAI域与NAI域的比较是逐字节比较，但值的可选最左侧点分隔部分除外，其内容为单个“*”字符；这样的标签匹配NAI领域中相同点分隔部分中的所有字符串。如果sAN:otherName:NAIRealm值中至少有一个与NAI领域匹配，则认为服务器已授权；如果不匹配，则认为服务器未经授权。
Since multiple names and multiple name forms may occur in the subjectAltName extension, an arbitrary number of NAIRealms can be specified in a certificate.
由于subjectAltName扩展中可能出现多个名称和多个名称形式，因此可以在证书中指定任意数量的NAIRAMES。
Examples:
示例：
+---------------------+-------------------+-----------------------+
| NAI realm (RADIUS) | NAIRealm (cert) | MATCH? |
+---------------------+-------------------+-----------------------+
| foo.example | foo.example | YES |
| foo.example | *.example | YES |
| bar.foo.example | *.example | NO |
| bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) |
| bar.foo.example | bar.*.example | NO (NAIRealm invalid) |
| bar.foo.example | *.*.example | NO (NAIRealm invalid) |
| sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) |
| sub.bar.foo.example | *.bar.foo.example | YES |
+-----------------+-----------------------------------------------+
+---------------------+-------------------+-----------------------+
| NAI realm (RADIUS) | NAIRealm (cert) | MATCH? |
+---------------------+-------------------+-----------------------+
| foo.example | foo.example | YES |
| foo.example | *.example | YES |
| bar.foo.example | *.example | NO |
| bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) |
| bar.foo.example | bar.*.example | NO (NAIRealm invalid) |
| bar.foo.example | *.*.example | NO (NAIRealm invalid) |
| sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) |
| sub.bar.foo.example | *.bar.foo.example | YES |
+-----------------+-----------------------------------------------+
Figure 6: Examples for NAI Realm vs. Certificate Matching
图6:NAI领域与证书匹配的示例
Appendix A contains the ASN.1 definition of the above objects.
附录A包含ASN.1对上述对象的定义。
Dynamic server discovery as defined in this document is only applicable for new AAA transactions and per service (i.e., distinct discovery is needed for Authentication, Accounting, and Dynamic Authorization) where a RADIUS entity that acts as a forwarding server for one or more realms receives a request with a realm for which it is not authoritative, and which no explicit next hop is configured. It is only applicable for
本文档中定义的动态服务器发现仅适用于新的AAA事务和每个服务（即，身份验证、记帐和动态授权需要不同的发现）其中，充当一个或多个域的转发服务器的RADIUS实体接收到一个域的请求，该域不具有权威性，并且未配置明确的下一跳。它只适用于
a. new user sessions, i.e., for the initial Access-Request. Subsequent messages concerning this session, for example, Access-Challenges and Access-Accepts, use the previously established communication channel between client and server.
a. 新用户会话，即用于初始访问请求的会话。有关此会话的后续消息（例如，访问挑战和访问接受）使用先前在客户端和服务器之间建立的通信通道。
b. the first accounting ticket for a user session.
b. 用户会话的第一个记帐票证。
c. the first RADIUS DynAuth packet for a user session.
c. 用户会话的第一个RADIUS DynAuth数据包。
The algorithm contains various variables for timeouts. These variables are named here and reasonable default values are provided. Implementations wishing to deviate from these defaults should make sure they understand the implications of changes.
该算法包含各种超时变量。这些变量在此处命名，并提供合理的默认值。希望偏离这些默认值的实现应该确保它们理解更改的含义。
DNS_TIMEOUT: maximum amount of time to wait for the complete set of all DNS queries to complete: Default = 3 seconds
DNS_超时：等待所有DNS查询完成的最长时间：默认值=3秒
MIN_EFF_TTL: minimum DNS TTL of discovered targets: Default = 60 seconds
MIN_EFF_TTL:发现目标的最小DNS TTL:默认值=60秒
BACKOFF_TIME: if no conclusive DNS response was retrieved after DNS_TIMEOUT, do not attempt dynamic discovery before BACKOFF_TIME has elapsed: Default = 600 seconds
退避时间：如果在DNS\u超时后未检索到最终DNS响应，则在退避时间过去之前不要尝试动态发现：默认值=600秒
Positive DNS response: A response that contains the RR that was queried for.
正向DNS响应：包含所查询RR的响应。
Negative DNS response: A response that does not contain the RR that was queried for but contains an SOA record along with a TTL indicating cache duration for this negative result.
负DNS响应：不包含查询的RR，但包含SOA记录以及指示此负结果的缓存持续时间的TTL的响应。
DNS Error: Where the algorithm states "name resolution returns with an error", this shall mean that either the DNS request timed out or it is a DNS response, which is neither a positive nor a negative response (e.g., SERVFAIL).
DNS错误：当算法声明“名称解析返回错误”时，这意味着DNS请求超时或它是一个DNS响应，既不是正响应也不是负响应（例如SERVFAIL）。
Effective TTL: The validity period for discovered RADIUS/TLS target
hosts. Calculated as: Effective TTL (set of DNS TTL values) = max {
MIN_EFF_TTL, min { DNS TTL values } }
Effective TTL: The validity period for discovered RADIUS/TLS target
hosts. Calculated as: Effective TTL (set of DNS TTL values) = max {
MIN_EFF_TTL, min { DNS TTL values } }
SRV lookup: For the purpose of this specification, SRV lookup procedures are defined as per [RFC2782] but excluding that RFCs "A" fallback as defined in the "Usage Rules" section, final "else" clause.
SRV查找：在本规范中，SRV查找程序根据[RFC2782]定义，但不包括“使用规则”部分最终“else”条款中定义的RFC“A”回退。
Greedy result evaluation: The NAPTR to SRV/A/AAAA resolution may lead to a tree of results, whose leafs are the IP addresses to contact. The branches of the tree are ordered according to their order/ preference DNS properties. An implementation is executing greedy result evaluation if it uses a depth-first search in the tree along the highest order results, attempts to connect to the corresponding resulting IP addresses, and only backtracks to other branches if the higher ordered results did not end in successful connection attempts.
贪婪结果评估：NAPTR到SRV/A/AAAA的解析可能导致结果树，其叶子是要联系的IP地址。树的分支根据其顺序/首选DNS属性进行排序。如果实现在树中沿最高顺序的结果使用深度优先搜索，尝试连接到相应的结果IP地址，并且如果较高顺序的结果未成功连接，则仅返回到其他分支，则执行贪婪结果求值。
For RADIUS Authentication and RADIUS Accounting server discovery, input I to the algorithm is the RADIUS User-Name attribute with content of the form "user@realm"; the literal "@" sign is the separator between a local user identifier within a realm and its realm. The use of multiple literal "@" signs in a User-Name is strongly discouraged; but if present, the last "@" sign is to be considered the separator. All previous instances of the "@" sign are to be considered part of the local user identifier.
对于RADIUS身份验证和RADIUS Accounting server discovery，算法的输入I是RADIUS用户名属性，其内容如下“user@realm"; 文字“@”符号是域内的本地用户标识符与其域之间的分隔符。强烈反对在用户名中使用多个文字“@”符号；但如果存在，最后一个“@”符号将被视为分隔符。“@”符号之前的所有实例都将被视为本地用户标识符的一部分。
For RADIUS DynAuth server discovery, input I to the algorithm is the domain name of the operator of a RADIUS realm as was communicated during user authentication using the Operator-Name attribute ([RFC5580], Section 4.1). Only Operator-Name values with the namespace "1" are supported by this algorithm -- the input to the algorithm is the actual domain name, preceded with an "@" (but without the "1" namespace identifier byte of that attribute).
对于RADIUS DynAuth服务器发现，算法的输入I是RADIUS领域的运营商的域名，在用户身份验证期间使用运营商名称属性进行通信（[RFC5580]，第4.1节）。此算法只支持名称空间为“1”的运算符名称值——算法的输入是实际域名，前面有“@”（但没有该属性的“1”名称空间标识符字节）。
Note well: The attribute User-Name is defined to contain UTF-8 text. In practice, the content may or may not be UTF-8. Even if UTF-8, it may or may not map to a domain name in the realm part. Implementors MUST take possible conversion error paths into consideration when
注意：属性用户名被定义为包含UTF-8文本。实际上，内容可能是也可能不是UTF-8。即使是UTF-8，它也可能映射到域部分中的域名，也可能不映射到域部分中的域名。实现者必须在以下情况下考虑可能的转换错误路径：
parsing incoming User-Name attributes. This document describes server discovery only for well-formed realms mapping to DNS domain names in UTF-8 encoding. The result of all other possible contents of User-Name is unspecified; this includes, but is not limited to:
正在分析传入的用户名属性。本文档描述的服务器发现仅适用于格式良好的领域，映射到UTF-8编码的DNS域名。未指定用户名的所有其他可能内容的结果；这包括但不限于：
Usage of separators other than "@".
使用除“@”以外的分离器。
Encoding of User-Name in local encodings.
在本地编码中对用户名进行编码。
UTF-8 realms that fail the conversion rules as per [RFC5891].
未通过[RFC5891]规定的转换规则的UTF-8领域。
UTF-8 realms that end with a "." ("dot") character.
以“.”（“点”）字符结尾的UTF-8域。
For the last bullet point, "trailing dot", special precautions should be taken to avoid problems when resolving servers with the algorithm below: they may resolve to a RADIUS server even if the peer RADIUS server only is configured to handle the realm without the trailing dot. If that RADIUS server again uses NAI discovery to determine the authoritative server, the server will forward the request to localhost, resulting in a tight endless loop.
对于最后一点，“尾随点”，在使用以下算法解决服务器时，应采取特殊预防措施以避免出现问题：即使对等RADIUS服务器仅配置为处理没有尾随点的领域，它们也可能会解析为RADIUS服务器。如果RADIUS服务器再次使用NAI发现来确定权威服务器，则服务器将把请求转发给localhost，从而产生一个紧密的无休止的循环。
Output O of the algorithm is a two-tuple consisting of: O-1) a set of tuples {hostname; port; protocol; order/preference; Effective TTL} -- the set can be empty -- and O-2) an integer. If the set in the first part of the tuple is empty, the integer contains the Effective TTL for backoff timeout; if the set is not empty, the integer is set to 0 (and not used).
算法的输出O是一个两元组，由以下内容组成：O-1）一组元组{hostname；port；protocol；order/preference；Effective TTL}--该组可以为空--和O-2）一个整数。如果元组第一部分中的集合为空，则整数包含退避超时的有效TTL；如果集合不为空，则整数将设置为0（且不使用）。
The algorithm to determine the RADIUS server to contact is as follows:
确定要联系的RADIUS服务器的算法如下：
1. Determine P = (position of last "@" character) in I.
1. 确定I中P=（最后一个“@”字符的位置）。
2. Generate R = (substring from P+1 to end of I).
2. 生成R=（从P+1到I结尾的子字符串）。
3. Modify R according to agreed consortium procedures if applicable.
3. 根据商定的联合体程序修改R（如适用）。
4. Convert R to a representation usable by the name resolution library if needed.
4. 如果需要，将R转换为名称解析库可用的表示形式。
5. Initialize TIMER = 0; start TIMER. If TIMER reaches DNS_TIMEOUT, continue at step 20.
5. 初始化定时器=0；启动计时器。如果计时器达到DNS_超时，则继续执行步骤20。
6. Using the host's name resolution library, perform a NAPTR query for R (see "Delay Considerations", Section 3.4.5, below). If the result is a negative DNS response, O-2 = Effective TTL ( TTL value of the SOA record ) and continue at step 13. If name resolution returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME, and terminate.
6. 使用主机名称解析库，对R执行NAPTR查询（请参阅下面第3.4.5节的“延迟注意事项”）。如果结果是否定的DNS响应，则O-2=有效TTL（SOA记录的TTL值），并继续执行步骤13。如果名称解析返回错误，则O-1={empty set}，O-2=BACKOFF_TIME，并终止。
7. Extract NAPTR records with service tags "aaa+auth", "aaa+acct", and "aaa+dynauth" as appropriate. Keep note of the protocol tag and remaining TTL of each of the discovered NAPTR records.
7. 提取带有服务标签“aaa+auth”、“aaa+acct”和“aaa+dynauth”的NAPTR记录（视情况而定）。记录协议标签和发现的每个NAPTR记录的剩余TTL。
8. If no records are found, continue at step 13.
8. 如果未找到任何记录，请继续执行步骤13。
9. For the extracted NAPTRs, perform successive resolution as defined in [RFC3958], Section 2.2. An implementation MAY use greedy result evaluation according to the NAPTR order/preference fields (i.e., can execute the subsequent steps of this algorithm for the highest-order entry in the set of results and only look up the remainder of the set if necessary).
9. 对于提取的NAPTR，执行[RFC3958]第2.2节中定义的连续分辨率。实现可以根据NAPTR顺序/首选项字段使用贪婪结果评估（即，可以对结果集中的最高顺序条目执行此算法的后续步骤，并且仅在必要时查找集合的其余部分）。
10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = BACKOFF_TIME, and terminate.
10. 如果主机名集为空，则O-1={empty set}，O-2=BACKOFF_TIME，并终止。
11. O' = (set of {hostname; port; protocol; order/preference; Effective TTL ( all DNS TTLs that led to this hostname ) } for all terminal lookup results).
11. O'=（所有终端查找结果的{主机名；端口；协议；顺序/首选项；有效TTL（导致此主机名的所有DNS TTL）}集）。
12. Proceed with step 18.
12. 继续执行步骤18。
13. Generate R' = (prefix R with "_radiustls._tcp." and/or "_radiustls._udp.").
13. 生成R'=（前缀R带有“\u radiustls.\u tcp.”和/或“\u radiustls.\u udp.”）。
14. Using the host's name resolution library, perform SRV lookup with R' as label (see "Delay Considerations", Section 3.4.5, below).
14. 使用主机名称解析库，以R'作为标签执行SRV查找（请参阅下文第3.4.5节的“延迟注意事项”）。
15. If name resolution returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME, and terminate.
15. 如果名称解析返回错误，则O-1={empty set}，O-2=BACKOFF_TIME，并终止。
16. If the result is a negative DNS response, O-1 = { empty set }, O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) }, and terminate.
16. 如果结果是否定的DNS响应，O-1={empty set}，O-2=min{O-2，Effective TTL（SOA记录的TTL值）}，然后终止。
17. O' = (set of {hostname; port; protocol; order/preference; Effective TTL ( all DNS TTLs that led to this result ) } for all hostnames).
17. O'=（所有主机名的{主机名；端口；协议；顺序/首选项；有效TTL（导致此结果的所有DNS TTL）}集）。
18. Generate O-1 by resolving hostnames in O' into corresponding A and/or AAAA addresses: O-1 = (set of {IP address; port; protocol; order/preference; Effective TTL ( all DNS TTLs that led to this result ) } for all hostnames ), O-2 = 0.
18. 通过将O'中的主机名解析为相应的A和/或AAAA地址来生成O-1：O-1=（所有主机名的{IP地址；端口；协议；顺序/首选项；有效TTL（导致此结果的所有DNS TTL）}），O-2=0。
19. For each element in O-1, test if the original request that triggered dynamic discovery was received on {IP address; port}. If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, and terminate (see next section for a rationale). If no, O is the result of dynamic discovery; terminate.
19. 对于O-1中的每个元素，测试是否在{IP地址；端口}上接收到触发动态发现的原始请求。如果是，O-1={empty set}，O-2=退避时间，记录错误，并终止（参见下一节了解基本原理）。如果否，O是动态发现的结果；终止
20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, and terminate.
20. O-1={empty set}，O-2=退避时间，日志错误，终止。
The discovery algorithm is used by servers that do not have sufficient configuration information to process an incoming request on their own. If the discovery algorithm result contains the server's own listening address (IP address and port), then there is a potential for an endless forwarding loop. If the listening address is the DNS result with the highest priority, the server will enter a tight loop (the server would forward the request to itself, triggering dynamic discovery again in a perpetual loop). If the address has a lower priority in the set of results, there is a potential loop with intermediate hops in between (the server could forward to another host with a higher priority, which might use DNS itself and forward the packet back to the first server). The underlying reason that enables these loops is that the server executing the discovery algorithm is seriously misconfigured in that it does not recognize the request as one that is to be processed by itself. RADIUS has no built-in loop detection, so any such loops would remain undetected. So, if step 18 of the algorithm discovers such a possible-loop situation, the algorithm should be aborted and an error logged. Note that this safeguard does not provide perfect protection against routing loops. One reason that might introduce a loop includes the possibility that a subsequent hop has a statically configured next hop that leads to an earlier host in the loop. Another reason for occurring loops is if the algorithm was executed with greedy result evaluation, and the server's own address was in a lower-priority branch of the result set that was not retrieved from DNS at all, and thus can't be detected.
发现算法用于没有足够配置信息的服务器，这些服务器无法单独处理传入请求。如果发现算法结果包含服务器自己的侦听地址（IP地址和端口），则可能会出现无止境的转发循环。如果侦听地址是具有最高优先级的DNS结果，则服务器将进入一个紧密循环（服务器将请求转发给自身，在永久循环中再次触发动态发现）。如果地址在结果集中具有较低的优先级，则可能存在一个中间跳数的循环（服务器可以转发到具有较高优先级的另一台主机，该主机可能使用DNS本身并将数据包转发回第一台服务器）。启用这些循环的根本原因是执行发现算法的服务器配置严重错误，因为它无法将请求识别为将由自身处理的请求。RADIUS没有内置环路检测，因此任何此类环路都不会被检测到。因此，如果算法的步骤18发现这种可能的循环情况，则应中止算法并记录错误。请注意，此保护措施不能提供针对路由环路的完美保护。可能引入循环的一个原因是，后续跃点可能有一个静态配置的下一个跃点，该下一个跃点指向循环中较早的主机。发生循环的另一个原因是，如果算法是在贪婪结果求值的情况下执行的，并且服务器自己的地址位于结果集的较低优先级分支中，而该分支根本没有从DNS检索到，因此无法检测到。
After executing the above algorithm, the RADIUS server establishes a connection to a home server from the result set. This connection can potentially remain open for an indefinite amount of time. This conflicts with the possibility of changing device and network configurations on the receiving end. Typically, TTL values for
执行上述算法后，RADIUS服务器从结果集中建立到家庭服务器的连接。此连接可能会无限期地保持打开状态。这与改变接收端设备和网络配置的可能性相冲突。通常，TTL值为
records in the name resolution system are used to indicate how long it is safe to rely on the results of the name resolution. If these TTLs are very low, thrashing of connections becomes possible; the Effective TTL mitigates that risk. When a connection is open and the smallest of the Effective TTL value that was learned during discovering the server has not expired, subsequent new user sessions for the realm that corresponds to that open connection SHOULD reuse the existing connection and SHOULD NOT re-execute the discovery algorithm nor open a new connection. To allow for a change of configuration, a RADIUS server SHOULD re-execute the discovery algorithm after the Effective TTL that is associated with this connection has expired. The server SHOULD keep the session open during this reassessment to avoid closure and immediate reopening of the connection should the result not have changed.
名称解析系统中的记录用于指示依赖名称解析结果的安全时间。如果这些TTL非常低，则可能出现连接抖动；有效的TTL缓解了这种风险。当连接打开且发现服务器期间学习到的最小有效TTL值未过期时，与该打开连接对应的领域的后续新用户会话应重用现有连接，并且不应重新执行发现算法，也不应打开新连接。为了允许更改配置，RADIUS服务器应在与此连接关联的有效TTL过期后重新执行发现算法。在此重新评估期间，服务器应保持会话打开，以避免在结果未更改的情况下关闭和立即重新打开连接。
Should the algorithm above terminate with O-1 = { empty set }, the
RADIUS server SHOULD NOT attempt another execution of this algorithm
for the same target realm before the timeout O-2 has passed.
Should the algorithm above terminate with O-1 = { empty set }, the
RADIUS server SHOULD NOT attempt another execution of this algorithm
for the same target realm before the timeout O-2 has passed.
The host's name resolution library may need to contact outside entities to perform the name resolution (e.g., authoritative name servers for a domain), and since the NAI discovery algorithm is based on uncontrollable user input, the destination of the lookups is out of control of the server that performs NAI discovery. If such outside entities are misconfigured or unreachable, the algorithm above may need an unacceptably long time to terminate. Many RADIUS implementations time out after five seconds of delay between Request and Response. It is not useful to wait until the host name resolution library signals a timeout of its name resolution algorithms. The algorithm therefore controls execution time with TIMER. Execution of the NAI discovery algorithm SHOULD be non-blocking (i.e., allow other requests to be processed in parallel to the execution of the algorithm).
主机的名称解析库可能需要联系外部实体以执行名称解析（例如，域的权威名称服务器），并且由于NAI发现算法基于不可控的用户输入，因此查找的目的地不受执行NAI发现的服务器的控制。如果这些外部实体配置错误或无法访问，上述算法可能需要很长时间才能终止。许多RADIUS实现在请求和响应之间延迟5秒后超时。等待主机名解析库发出其名称解析算法超时的信号是没有用的。因此，该算法使用计时器控制执行时间。NAI发现算法的执行应该是非阻塞的（即，允许在执行算法的同时并行处理其他请求）。
Assume
假定
a user from the Technical University of Munich, Germany, has a RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example".
来自德国慕尼黑工业大学的用户有一个RADIUS用户名。foobar@tu-m[U+00FC]nchen.示例”。
The name resolution library on the RADIUS forwarding server does not have the realm tu-m[U+00FC]nchen.example in its forwarding configuration but uses DNS for name resolution and has configured the use of dynamic discovery to discover RADIUS servers.
RADIUS转发服务器上的名称解析库在其转发配置中没有域tu-m[U+00FC]nchen.example，但使用DNS进行名称解析，并已配置使用动态发现来发现RADIUS服务器。
It is IPv6 enabled and prefers AAAA records over A records.
它已启用IPv6，并且更喜欢AAAA记录而不是A记录。
It is listening for incoming RADIUS/TLS requests on 192.0.2.1, TCP/2083.
它正在侦听192.0.2.1 TCP/2083上传入的RADIUS/TLS请求。
May the configuration variables be
配置变量可以是
DNS_TIMEOUT = 3 seconds
DNS_TIMEOUT = 3 seconds
MIN_EFF_TTL = 60 seconds
MIN_EFF_TTL = 60 seconds
BACKOFF_TIME = 3600 seconds
BACKOFF_TIME = 3600 seconds
If DNS contains the following records
如果DNS包含以下记录
xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example.
xn--tu-mnchen-t9a。示例。在NAPTR 50 50 50“s”中，aaa+auth:radius.tls.tcp”“\u myradius.\u tcp.xn--tu-mnchen-t9a.example。
xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example.
xn--tu-mnchen-t9a。示例。在NAPTR 50 50“s”中的“fooservice:bar.dccp”_abc123.\u def.xn--tu-mnchen-t9a.example。
_myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 radsecserver.xn--tu-mnchen-t9a.example.
_myradius._tcp.xn--tu-mnchen-t9a.示例。在SRV 0 10 2083 radsecserver.xn--tu-mnchen-t9a.example中。
_myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 backupserver.xn--tu-mnchen-t9a.example.
_myradius._tcp.xn--tu-mnchen-t9a.示例。在SRV 0 20 2083 backupserver.xn--tu-mnchen-t9a.example中。
radsecserver.xn--tu-mnchen-t9a.example. IN AAAA
2001:0DB8::202:44ff:fe0a:f704
radsecserver.xn--tu-mnchen-t9a.example. IN AAAA
2001:0DB8::202:44ff:fe0a:f704
radsecserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.3
radsecserver.xn--tu-mnchen-t9a.example。在192.0.2.3中
backupserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.7
backupserver.xn--tu-mnchen-t9a.example。在192.0.2.7中
Then the algorithm executes as follows, with I = "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling in use:
然后算法执行如下，I=”foobar@tu-m[U+00FC]nchen.示例”，且未使用任何联合体名称：
1. P = 7
1. P=7
2. R = "tu-m[U+00FC]nchen.example"
2. R=“tu-m[U+00FC]nchen.示例”
3. NOOP
3. 努普
4. Name resolution library converts R to xn--tu-mnchen-t9a.example
4. 名称解析库将R转换为xn--tu-mnchen-t9a。示例
5. TIMER starts.
5. 计时器启动。
6. Result:
6. 结果:
(TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example.
（TTL=47）50 50 50“s”aaa+auth:radius.tls.tcp”“\u myradius.\u tcp.xn--tu-mnchen-t9a.example。
(TTL = 522) 50 50 "s" "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example.
（TTL=522）50 50“s”fooservice:bar.dccp“\u abc123.\u def.xn--tu-mnchen-t9a.example。
7. Result:
7. 结果:
(TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-t9a.example.
（TTL=47）50 50 50“s”aaa+auth:radius.tls.tcp”“\u myradius.\u tcp.xn--tu-mnchen-t9a.example。
8. NOOP
8. 努普
9. Successive resolution performs SRV query for label _myradius._tcp.xn--tu-mnchen-t9a.example, which results in
9. 连续解析对标签_myradius执行SRV查询。_tcp.xn--tu-mnchen-t9a.example，结果是
(TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example.
（TTL 499）0 10 2083 radsec.xn--tu-mnchen-t9a.示例。
(TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example.
（TTL 2200）0 20 2083 backup.xn--tu-mnchen-t9a.example。
10. NOOP
10. 努普
11. O' = {
11. O'={
(radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10; 60),
（radsec.xn--tu-mnchen-t9a.示例；2083；半径/TLS；10；60），
(backup.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 20; 60)
(backup.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 20; 60)
} // minimum TTL is 47, upped to MIN_EFF_TTL
} // minimum TTL is 47, upped to MIN_EFF_TTL
12. Continuing at 18.
12. 18岁继续。
13. (not executed)
13. （未执行）
14. (not executed)
14. （未执行）
15. (not executed)
15. （未执行）
16. (not executed)
16. （未执行）
17. (not executed)
17. （未执行）
18. O-1 = {
18. O-1={
(2001:0DB8::202:44ff:fe0a:f704; 2083; RADIUS/TLS; 10; 60),
（2001:0DB8:：202:44ff:fe0a:f704；2083；半径/TLS；10；60），
(192.0.2.7; 2083; RADIUS/TLS; 20; 60)
(192.0.2.7; 2083; RADIUS/TLS; 20; 60)
}; O-2 = 0
}; O-2 = 0
19. No match with own listening address; terminate with tuple (O-1, O-2) from previous step.
19. 与自己的收听地址不匹配；使用上一步中的元组（O-1，O-2）终止。
The implementation will then attempt to connect to two servers, with preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/ TLS protocol.
然后，实现将尝试连接到两台服务器，首选使用RADIUS/TLS协议的[2001:0DB8:：202:44ff:fe0a:f704]：2083。
The discovery algorithm as defined in this document contains several options: the major ones are use of NAPTR vs. SRV; how to determine the authorization status of a contacted server for a given realm; and which trust anchors to consider trustworthy for the RADIUS conversation setup.
本文档中定义的发现算法包含几个选项：主要选项是使用NAPTR与SRV；如何确定给定领域的已联系服务器的授权状态；以及信任信任锚为RADIUS会话设置考虑可信。
Random parties that do not agree on the same set of options may not be able to interoperate. However, such a global interoperability is not intended by this document.
不同意同一组选项的随机各方可能无法进行互操作。但是，本文档并不打算提供这种全局互操作性。
Discovery as per this document becomes important inside a roaming consortium, which has set up roaming agreements with the other partners. Such roaming agreements require much more than a technical means of server discovery; there are administrative and contractual considerations at play (service contracts, back-office compensations, procedures, etc.).
根据本文档进行的发现在漫游联盟中变得非常重要，该联盟已和其他合作伙伴建立了漫游协议。这种漫游协议需要的不仅仅是服务器发现的技术手段；有行政和合同方面的考虑（服务合同、后台补偿、程序等）。
A roaming consortium's roaming agreement must include a profile of which choice points in this document to use. So as long as the roaming consortium can settle on one deployment profile, they will be able to interoperate based on that choice; this per-consortium interoperability is the intended scope of this document.
漫游联盟的漫游协议必须包括本文档中要使用的选择点的配置文件。因此，只要漫游联盟能够确定一个部署配置文件，他们就能够基于该选择进行互操作；每个联合体的互操作性是本文件的预期范围。
When using DNS without DNSSEC security extensions and validation for all of the replies to NAPTR, SRV, and A/AAAA requests as described in Section 3, the result of the discovery process can not be trusted. Even if it can be trusted (i.e., DNSSEC is in use), actual authorization of the discovered server to provide service for the given realm needs to be verified. A mechanism from Section 2.1.1.3 or equivalent MUST be used to verify authorization.
如第3节所述，对NAPTR、SRV和A/AAAA请求的所有回复使用不带DNSSEC安全扩展和验证的DNS时，发现过程的结果不可信。即使可以信任它（即DNSSEC正在使用），也需要验证发现的服务器为给定领域提供服务的实际授权。必须使用第2.1.1.3节中的机制或等效机制来验证授权。
The algorithm has a configurable completion timeout DNS_TIMEOUT defaulting to three seconds for RADIUS' operational reasons. The lookup of DNS resource records based on unverified user input is an attack vector for DoS attacks: an attacker might intentionally craft bogus DNS zones that take a very long time to reply (e.g., due to a particularly byzantine tree structure or artificial delays in responses).
由于RADIUS的操作原因，该算法有一个可配置的完成超时DNS_超时，默认为3秒。基于未经验证的用户输入的DNS资源记录的查找是DoS攻击的攻击向量：攻击者可能故意伪造非常长的时间来回复的伪DNS区域（例如，由于特定拜占庭树结构或响应中的人为延迟）。
To mitigate this DoS vector, implementations SHOULD consider rate limiting either the amount of new executions of the discovery algorithm as a whole or the amount of intermediate responses to track, or at least the number of pending DNS queries. Implementations MAY choose lower values than the default for DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They MAY also continue their attempt to resolve DNS records even after DNS_TIMEOUT has passed; a subsequent request for the same realm might benefit from retrieving the results anyway. The amount of time spent waiting for a result will influence the impact of a possible DoS attack; the waiting time value is implementation dependent and outside the scope of this specification.
为了减轻这种DOS向量，实现应该考虑速率限制作为整体的发现算法的新执行量或跟踪的中间响应的量，或者至少待处理DNS查询的数量。实现可能会选择低于默认值的DNS_超时值，以限制通过该向量的DoS攻击的影响。即使DNS_超时已过，他们也可能继续尝试解析DNS记录；对同一领域的后续请求可能会从检索结果中获益。等待结果所花费的时间将影响可能的DoS攻击的影响；等待时间值取决于实现，不在本规范的范围内。
With dynamic discovery being enabled for a RADIUS server, and depending on the deployment scenario, the server may need to open up its target IP address and port for the entire Internet because arbitrary clients may discover it as a target for their authentication requests. If such clients are not part of the roaming consortium, the RADIUS/TLS connection setup phase will fail (which is intended), but the computational cost for the connection attempt is significant. When the port for a TLS-based service is open, the RADIUS server shares all the typical attack vectors for services based on TLS (such as HTTPS and SMTPS). Deployments of RADIUS/TLS with dynamic discovery should consider these attack vectors and take appropriate countermeasures (e.g., blacklisting known bad IPs on a firewall, rate limiting new connection attempts, etc.).
RADIUS服务器启用动态发现后，根据部署场景，服务器可能需要为整个Internet打开其目标IP地址和端口，因为任意客户端可能会将其作为身份验证请求的目标进行发现。如果这些客户端不是漫游联盟的一部分，RADIUS/TLS连接设置阶段将失败（这是预期的），但连接尝试的计算成本是巨大的。当基于TLS的服务的端口打开时，RADIUS服务器共享基于TLS的服务（如HTTPS和SMTPS）的所有典型攻击向量。具有动态发现的RADIUS／TLS的部署应考虑这些攻击向量并采取适当的对策（例如，黑名单上已知的防火墙上的坏IP，限制新的连接尝试等）。
The classic RADIUS operational model (known, preconfigured peers, shared secret security, and mostly plaintext communication) and this new RADIUS dynamic discovery model (peer discovery with DNS, PKI security, and packet confidentiality) differ significantly in their impact on the privacy of end users trying to authenticate to a RADIUS server.
经典的RADIUS运营模型（已知的、预配置的对等点、共享秘密安全性，以及大部分明文通信）和这种新的RADIUS动态发现模型（使用DNS的对等点发现、PKI安全性和数据包机密性）在对试图向RADIUS服务器进行身份验证的最终用户的隐私的影响方面存在显著差异。
With classic RADIUS, traffic in large environments gets aggregated by statically configured clearinghouses. The packets sent to those clearinghouses and their responses are mostly unprotected. As a consequence,
使用经典的RADIUS，大型环境中的流量通过静态配置的交换所聚合。发送到这些票据交换所的数据包及其回复大多没有受到保护。因此,，
o All intermediate IP hops can inspect most of the packet payload in clear text, including the User-Name and Calling-Station-Id attributes, and can observe which client sent the packet to which clearinghouse. This allows the creation of mobility profiles for any passive observer on the IP path.
o 所有中间IP跃点都可以以明文形式检查大部分数据包有效负载，包括用户名和呼叫站Id属性，并可以观察哪个客户端将数据包发送到哪个清算所。这允许为IP路径上的任何被动观察者创建移动性配置文件。
o The existence of a central clearinghouse creates an opportunity for the clearinghouse to trivially create the same mobility profiles. The clearinghouse may or may not be trusted not to do this, e.g., by sufficiently threatening contractual obligations.
o 中央票据交换所的存在为票据交换所创造了一个机会，使其能够轻松地创建相同的流动性配置文件。清算所可能会也可能不会被信任不这样做，例如，通过充分威胁合同义务。
o In addition to that, with the clearinghouse being a RADIUS intermediate in possession of a valid shared secret, the clearinghouse can observe and record even the security-critical RADIUS attributes such as User-Password. This risk may be mitigated by choosing authentication payloads that are cryptographically secured and do not use the attribute User-Password -- such as certain EAP types.
o 除此之外，由于票据交换所是拥有有效共享秘密的RADIUS中间人，票据交换所甚至可以观察和记录安全关键的RADIUS属性，如用户密码。通过选择加密安全且不使用属性用户密码的身份验证有效负载（如某些EAP类型），可以减轻此风险。
o There is no additional information disclosure to parties outside the IP path between the RADIUS client and server (in particular, no DNS servers learn about realms of current ongoing authentications).
o 对于RADIUS客户端和服务器之间的IP路径之外的各方，没有其他信息披露（特别是，没有DNS服务器了解当前正在进行的身份验证的领域）。
With RADIUS and dynamic discovery,
借助半径和动态发现，
o This protocol allows for RADIUS clients to identify and directly connect to the RADIUS home server. This can eliminate the use of clearinghouses to do forwarding of requests, and it also eliminates the ability of the clearinghouse to then aggregate the user information that flows through it. However, there are reasons why clearinghouses might still be used. One reason to keep a clearinghouse is to act as a gateway for multiple backends
o 此协议允许RADIUS客户端识别并直接连接到RADIUS家庭服务器。这可以消除使用票据交换所转发请求的情况，还可以消除票据交换所随后聚合流经它的用户信息的能力。然而，仍有理由使用票据交换所。保留票据交换所的一个原因是充当多个后端的网关
in a company; another reason may be a requirement to sanitize RADIUS datagrams (filter attributes, tag requests with new attributes, etc.).
在公司；另一个原因可能是需要清理RADIUS数据报（过滤器属性、具有新属性的标记请求等）。
o Even where intermediate proxies continue to be used for reasons unrelated to dynamic discovery, the number of such intermediates may be reduced by removing those proxies that are only deployed for pure request routing reasons. This reduces the number of entities that can inspect the RADIUS traffic.
o 即使由于与动态发现无关的原因而继续使用中间代理，也可以通过删除那些仅出于纯粹请求路由原因而部署的代理来减少此类中间代理的数量。这减少了可以检查RADIUS流量的实体数量。
o RADIUS clients that make use of dynamic discovery will need to query the Domain Name System and use a user's realm name as the query label. A passive observer on the IP path between the RADIUS client and the DNS server(s) being queried can learn that a user of that specific realm was trying to authenticate at that RADIUS client at a certain point in time. This may or may not be sufficient for the passive observer to create a mobility profile. During the recursive DNS resolution, a fair number of DNS servers and the IP hops in between those get to learn that information. Not every single authentication triggers DNS lookups, so there is no one-to-one relation of leaked realm information and the number of authentications for that realm.
o 使用动态发现的RADIUS客户端需要查询域名系统，并使用用户的域名作为查询标签。RADIUS客户端和被查询DNS服务器之间的IP路径上的被动观察者可以了解到特定领域的用户在某个时间点试图在该RADIUS客户端进行身份验证。这可能或可能不足以让被动观测者创建移动性剖面。在递归DNS解析过程中，相当多的DNS服务器和这些服务器之间的IP跃点可以了解这些信息。并非每个身份验证都会触发DNS查找，因此泄漏的领域信息与该领域的身份验证数量之间不存在一一对应的关系。
o Since dynamic discovery operates on a RADIUS hop-by-hop basis, there is no guarantee that the RADIUS payload is not transmitted between RADIUS systems that do not make use of this algorithm, and they possibly use other transports such as RADIUS/UDP. On such hops, the enhanced privacy is jeopardized.
o 由于动态发现以RADIUS逐跳运行，因此无法保证RADIUS有效负载不会在不使用此算法的RADIUS系统之间传输，并且它们可能使用其他传输，如RADIUS/UDP。在这种跳跃中，增强的隐私受到了威胁。
In summary, with classic RADIUS, few intermediate entities learn very detailed data about every ongoing authentication, while with dynamic discovery, many entities learn only very little about recently authenticated realms.
总之，使用classic RADIUS，很少有中间实体了解有关每个正在进行的身份验证的非常详细的数据，而使用dynamic discovery，许多实体对最近经过身份验证的领域了解很少。
Per this document, IANA has added the following entries in existing registries:
根据本文件，IANA在现有注册中添加了以下条目：
o S-NAPTR Application Service Tags registry
o S-NAPTR应用程序服务标记注册表
* aaa+auth
* aaa+auth
* aaa+acct
* aaa+账户
* aaa+dynauth
* aaa+dynauth
o S-NAPTR Application Protocol Tags registry
o S-NAPTR应用程序协议标记注册表
* radius.tls.tcp
* radius.tls.tcp
* radius.dtls.udp
* radius.dtls.udp
This document reserves the use of the "radiustls" and "radiusdtls" service names. Registration information as per Section 8.1.1 of [RFC6335] is as follows:
本文件保留“radiustls”和“radiustls”服务名称的使用。[RFC6335]第8.1.1节规定的注册信息如下：
Service Name: radiustls; radiusdtls
服务名称：radiustls；放射状
Transport Protocols: TCP (for radiustls), UDP (for radiusdtls)
传输协议：TCP（用于radiustls）、UDP（用于RADIUDTLS）
Assignee: IESG <iesg@ietf.org>
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Authentication, Accounting, and Dynamic Authorization via the RADIUS protocol. These service names are used to construct the SRV service labels "_radiustls" and "_radiusdtls" for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively.
描述：通过RADIUS协议进行身份验证、记帐和动态授权。这些服务名称分别用于构建用于发现RADIUS/TLS和RADIUS/DTLS服务器的SRV服务标签“_radiustls”和“_radiustls”。
Reference: RFC 7585
参考：RFC 7585
This specification makes use of the SRV protocol identifiers "_tcp" and "_udp", which are mentioned as early as [RFC2782] but do not appear to be assigned in an actual registry. Since they are in widespread use in other protocols, this specification refrains from requesting a new registry "RADIUS/TLS SRV Protocol Registry" and continues to make use of these tags implicitly.
本规范使用了SRV协议标识符“_tcp”和“_udp”，这些标识符早在[RFC2782]中就有提及，但似乎没有在实际注册表中分配。由于它们在其他协议中广泛使用，本规范避免请求新的注册表“RADIUS/TLS SRV协议注册表”，并继续隐式使用这些标记。
Per this document, a number of Object Identifiers have been assigned. They are now under the control of IANA following [RFC7299].
根据本文件，分配了许多对象标识符。根据[RFC7299]，它们现在由IANA控制。
IANA has assigned the following identifiers:
IANA已分配以下标识符：
85 has been assigned from the "SMI Security for PKIX Module Identifier" registry. The description is id-mod-nai-realm-08.
85已从“SMI Security for PKIX模块标识符”注册表中分配。描述为id-mod-nai-realm-08。
8 has been assigned from the "SMI Security for PKIX Other Name Forms" registry. The description is id-on-naiRealm.
8已从“SMI Security for PKIX其他名称表单”注册表中分配。描述是NAIRAMD上的id。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<http://www.rfc-editor.org/info/rfc2782>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <http://www.rfc-editor.org/info/rfc2865>.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 2865，DOI 10.17487/RFC2865，2000年6月<http://www.rfc-editor.org/info/rfc2865>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <http://www.rfc-editor.org/info/rfc2866>.
[RFC2866]Rigney，C.，“半径会计”，RFC 2866，DOI 10.17487/RFC2866，2000年6月<http://www.rfc-editor.org/info/rfc2866>.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, January 2005, <http://www.rfc-editor.org/info/rfc3958>.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，DOI 10.17487/RFC3958，2005年1月<http://www.rfc-editor.org/info/rfc3958>.
[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, DOI 10.17487/RFC5176, January 2008, <http://www.rfc-editor.org/info/rfc5176>.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 5176，DOI 10.17487/RFC5176，2008年1月<http://www.rfc-editor.org/info/rfc5176>.
[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, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009, <http://www.rfc-editor.org/info/rfc5580>.
[RFC5580]Tschofenig，H.，Ed.，Adrangi，F.，Jones，M.，Lior，A.，和B.Aboba，“以半径和直径携带定位物体”，RFC 5580，DOI 10.17487/RFC5580，2009年8月<http://www.rfc-editor.org/info/rfc5580>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 5891，DOI 10.17487/RFC5891，2010年8月<http://www.rfc-editor.org/info/rfc5891>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, <http://www.rfc-editor.org/info/rfc6614>.
[RFC6614]Winter，S.，McCauley，M.，Venaas，S.，和K.Wierenga，“RADIUS的传输层安全（TLS）加密”，RFC 6614，DOI 10.17487/RFC66142012年5月<http://www.rfc-editor.org/info/rfc6614>.
[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS", RFC 7360, DOI 10.17487/RFC7360, September 2014, <http://www.rfc-editor.org/info/rfc7360>.
[RFC7360]DeKok，A.，“作为RADIUS传输层的数据报传输层安全性（DTLS）”，RFC 7360，DOI 10.17487/RFC7360，2014年9月<http://www.rfc-editor.org/info/rfc7360>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <http://www.rfc-editor.org/info/rfc7542>.
[RFC7542]DeKok，A.，“网络访问标识符”，RFC 7542，DOI 10.17487/RFC7542，2015年5月<http://www.rfc-editor.org/info/rfc7542>.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March 2005, <http://www.rfc-editor.org/info/rfc4017>.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 4017，DOI 10.17487/RFC4017，2005年3月<http://www.rfc-editor.org/info/rfc4017>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<http://www.rfc-editor.org/info/rfc6335>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6733]Fajardo，V.，Ed.，Arkko，J.，Loughney，J.，和G.Zorn，Ed.，“直径基准协议”，RFC 6733，DOI 10.17487/RFC6733，2012年10月<http://www.rfc-editor.org/info/rfc6733>.
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, <http://www.rfc-editor.org/info/rfc7299>.
[RFC7299]Housley，R.，“PKIX工作组的对象标识符注册表”，RFC 7299，DOI 10.17487/RFC7299，2014年7月<http://www.rfc-editor.org/info/rfc7299>.
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam Architecture for Network Roaming", RFC 7593, DOI 10.17487/RFC7593, September 2015, <http://www.rfc-editor.org/info/rfc7593>.
[RFC7593]K.Wierenga，S.Winter和T.Wolniewicz，“网络漫游的eduroam架构”，RFC 7593，DOI 10.17487/RFC7593，2015年9月<http://www.rfc-editor.org/info/rfc7593>.
PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-nai-realm-08(85) }
PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-nai-realm-08(85) }
DEFINITIONS EXPLICIT TAGS ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
id-pkix
FROM PKIX1Explicit-2009
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
-- from RFCs 5280 and 5912
id-pkix
FROM PKIX1Explicit-2009
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
-- from RFCs 5280 and 5912
OTHER-NAME
FROM PKIX1Implicit-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
-- from RFCs 5280 and 5912
;
OTHER-NAME
FROM PKIX1Implicit-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
-- from RFCs 5280 and 5912
;
-- Service Name Object Identifier
--服务名称对象标识符
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-naiRealm OBJECT IDENTIFIER ::= { id-on 8 }
id-on-naiRealm OBJECT IDENTIFIER ::= { id-on 8 }
-- Service Name
--服务名称
naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-naiRealm }}
naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-naiRealm }}
ub-naiRealm-length INTEGER ::= 255
ub-naiRealm-length INTEGER ::= 255
NAIRealm ::= UTF8String (SIZE (1..ub-naiRealm-length))
NAIRealm ::= UTF8String (SIZE (1..ub-naiRealm-length))
END
终止
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
Phone: +352 424409 1
Fax: +352 422473
Email: stefan.winter@restena.lu
URI: http://www.restena.lu
Mike McCauley AirSpayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia
Mike McCauley AirSpayce私人有限公司9 Bulbul Place Currumbin Waters昆士兰州4223澳大利亚
Phone: +61 7 5598 7474
Email: mikem@airspayce.com
URI: http://www.airspayce.com
Phone: +61 7 5598 7474
Email: mikem@airspayce.com
URI: http://www.airspayce.com