Network Working Group C. Rigney
Request for Comments: 2869 Livingston
Category: Informational W. Willats
Cyno Technologies
P. Calhoun
Sun Microsystems
June 2000
Network Working Group C. Rigney
Request for Comments: 2869 Livingston
Category: Informational W. Willats
Cyno Technologies
P. Calhoun
Sun Microsystems
June 2000
RADIUS Extensions
半径延伸
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 [1] and RFC 2866 [2].
本文档描述了使用RFC 2865[1]和RFC 2866[2]中描述的远程身份验证拨入用户服务（RADIUS）协议在网络访问服务器（NAS）和共享计费服务器之间传输身份验证、授权和计费信息的附加属性。
Table of Contents
目录
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 3
1.2 Terminology ..................................... 3
2. Operation ............................................. 4
2.1 RADIUS support for Interim Accounting Updates.... 4
2.2 RADIUS support for Apple Remote Access
Protocol ........................................ 5
2.3 RADIUS Support for Extensible Authentication
Protocol (EAP) .................................. 11
2.3.1 Protocol Overview ............................... 11
2.3.2 Retransmission .................................. 13
2.3.3 Fragmentation ................................... 14
2.3.4 Examples ........................................ 14
2.3.5 Alternative uses ................................ 19
3. Packet Format ......................................... 19
4. Packet Types .......................................... 19
5. Attributes ............................................ 20
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 3
1.2 Terminology ..................................... 3
2. Operation ............................................. 4
2.1 RADIUS support for Interim Accounting Updates.... 4
2.2 RADIUS support for Apple Remote Access
Protocol ........................................ 5
2.3 RADIUS Support for Extensible Authentication
Protocol (EAP) .................................. 11
2.3.1 Protocol Overview ............................... 11
2.3.2 Retransmission .................................. 13
2.3.3 Fragmentation ................................... 14
2.3.4 Examples ........................................ 14
2.3.5 Alternative uses ................................ 19
3. Packet Format ......................................... 19
4. Packet Types .......................................... 19
5. Attributes ............................................ 20
5.1 Acct-Input-Gigawords ............................ 22
5.2 Acct-Output-Gigawords ........................... 23
5.3 Event-Timestamp ................................. 23
5.4 ARAP-Password ................................... 24
5.5 ARAP-Features ................................... 25
5.6 ARAP-Zone-Access ................................ 26
5.7 ARAP-Security ................................... 27
5.8 ARAP-Security-Data .............................. 28
5.9 Password-Retry .................................. 28
5.10 Prompt .......................................... 29
5.11 Connect-Info .................................... 30
5.12 Configuration-Token ............................. 31
5.13 EAP-Message ..................................... 32
5.14 Message-Authenticator ........................... 33
5.15 ARAP-Challenge-Response ......................... 35
5.16 Acct-Interim-Interval ........................... 36
5.17 NAS-Port-Id ..................................... 37
5.18 Framed-Pool ..................................... 37
5.19 Table of Attributes ............................. 38
6. IANA Considerations ................................... 39
7. Security Considerations ............................... 39
7.1 Message-Authenticator Security .................. 39
7.2 EAP Security .................................... 39
7.2.1 Separation of EAP server and PPP authenticator .. 40
7.2.2 Connection hijacking ............................ 41
7.2.3 Man in the middle attacks ....................... 41
7.2.4 Multiple databases .............................. 41
7.2.5 Negotiation attacks ............................. 42
8. References ............................................ 43
9. Acknowledgements ...................................... 44
10. Chair's Address ....................................... 44
11. Authors' Addresses .................................... 45
12. Full Copyright Statement .............................. 47
5.1 Acct-Input-Gigawords ............................ 22
5.2 Acct-Output-Gigawords ........................... 23
5.3 Event-Timestamp ................................. 23
5.4 ARAP-Password ................................... 24
5.5 ARAP-Features ................................... 25
5.6 ARAP-Zone-Access ................................ 26
5.7 ARAP-Security ................................... 27
5.8 ARAP-Security-Data .............................. 28
5.9 Password-Retry .................................. 28
5.10 Prompt .......................................... 29
5.11 Connect-Info .................................... 30
5.12 Configuration-Token ............................. 31
5.13 EAP-Message ..................................... 32
5.14 Message-Authenticator ........................... 33
5.15 ARAP-Challenge-Response ......................... 35
5.16 Acct-Interim-Interval ........................... 36
5.17 NAS-Port-Id ..................................... 37
5.18 Framed-Pool ..................................... 37
5.19 Table of Attributes ............................. 38
6. IANA Considerations ................................... 39
7. Security Considerations ............................... 39
7.1 Message-Authenticator Security .................. 39
7.2 EAP Security .................................... 39
7.2.1 Separation of EAP server and PPP authenticator .. 40
7.2.2 Connection hijacking ............................ 41
7.2.3 Man in the middle attacks ....................... 41
7.2.4 Multiple databases .............................. 41
7.2.5 Negotiation attacks ............................. 42
8. References ............................................ 43
9. Acknowledgements ...................................... 44
10. Chair's Address ....................................... 44
11. Authors' Addresses .................................... 45
12. Full Copyright Statement .............................. 47
RFC 2865 [1] describes the RADIUS Protocol as it is implemented and deployed today, and RFC 2866 [2] describes how Accounting can be performed with RADIUS.
RFC 2865[1]描述了RADIUS协议目前的实施和部署情况，RFC 2866[2]描述了如何使用RADIUS执行记帐。
This memo suggests several additional Attributes that can be added to RADIUS to perform various useful functions. These Attributes do not have extensive field experience yet and should therefore be considered experimental.
此备忘录建议将几个附加属性添加到RADIUS中，以执行各种有用的功能。这些属性还没有广泛的现场经验，因此应被视为实验性的。
The Extensible Authentication Protocol (EAP) [3] is a PPP extension that provides support for additional authentication methods within PPP. This memo describes how the EAP-Message and Message-Authenticator attributes may be used for providing EAP support within RADIUS.
可扩展身份验证协议（EAP）[3]是一个PPP扩展，为PPP中的其他身份验证方法提供支持。本备忘录描述了如何使用EAP消息和消息验证器属性在RADIUS内提供EAP支持。
All attributes are comprised of variable length Type-Length-Value 3- tuples. New attribute values can be added without disturbing existing implementations of the protocol.
所有属性都由可变长度类型长度值3元组组成。可以添加新的属性值，而不会干扰协议的现有实现。
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 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释。
An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant."
如果一个实现未能满足其实现的协议的一个或多个必须或不得要求，则该实现是不兼容的。满足其协议的所有必须、不得、应该和不应该要求的实现称为“无条件兼容”；满足其协议的所有必须和不得要求，但并非所有应该或不应该要求的协议称为“有条件兼容”
A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST treat a RADIUS access-request requesting an unavailable service as an access-reject instead.
未实现给定服务的NAS不得实现该服务的RADIUS属性。例如，无法提供ARAP服务的NAS不得实现ARAP的RADIUS属性。NAS必须将请求不可用服务的RADIUS访问请求视为访问拒绝。
This document uses the following terms:
本文件使用以下术语：
service The NAS provides a service to the dial-in user, such as PPP or Telnet.
服务NAS向拨入用户提供服务，如PPP或Telnet。
session Each service provided by the NAS to a dial-in user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service
会话NAS向拨入用户提供的每个服务都构成一个会话，会话的开始定义为首次提供服务的点，会话的结束定义为服务提供的点
is ended. A user may have multiple sessions in parallel or series if the NAS supports that, with each session generating a separate start and stop accounting record.
结束了。如果NAS支持，一个用户可以有多个并行或串行会话，每个会话生成一个单独的开始和停止记帐记录。
silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
静默丢弃这意味着实现在不进行进一步处理的情况下丢弃数据包。实现应该提供记录错误的能力，包括静默丢弃的数据包的内容，并且应该在统计计数器中记录事件。
Operation is identical to that defined in RFC 2865 [1] and RFC 2866 [2].
操作与RFC 2865[1]和RFC 2866[2]中定义的操作相同。
When a user is authenticated, a RADIUS server issues an Access-Accept in response to a successful Access-Request. If the server wishes to receive interim accounting messages for the given user it must include the Acct-Interim-Interval RADIUS attribute in the message, which indicates the interval in seconds between interim messages.
当用户通过身份验证时，RADIUS服务器会发出访问接受，以响应成功的访问请求。如果服务器希望接收给定用户的临时记帐消息，则必须在消息中包含Acct INTERMIT Interval RADIUS属性，该属性指示临时消息之间的间隔（以秒为单位）。
It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept.
还可以在NAS本身上静态配置临时值。请注意，NAS上本地配置的值必须覆盖Access Accept中的值。
This scheme does not break backward interoperability since a RADIUS server not supporting this extension will simply not add the new Attribute. NASes not supporting this extension will ignore the Attribute.
此方案不会中断向后互操作性，因为不支持此扩展的RADIUS服务器将不会添加新属性。不支持此扩展的NASE将忽略该属性。
Note that all information in an interim message is cumulative (i.e. number of packets sent is the total since the beginning of the session, not since the last interim message).
请注意，临时消息中的所有信息都是累积的（即，发送的数据包数是自会话开始以来的总数，而不是自上次临时消息以来的总数）。
It is envisioned that an Interim Accounting record (with Acct-Status-Type = Interim-Update (3)) would contain all of the attributes normally found in an Accounting Stop message with the exception of the Acct-Term-Cause attribute.
可以设想，临时会计记录（账户状态类型=临时更新（3））将包含通常在会计停止消息中找到的所有属性，但账户期限原因属性除外。
Since all the information is cumulative, a NAS MUST ensure that only a single generation of an interim Accounting message for a given session is present in the retransmission queue at any given time.
由于所有信息都是累积的，NAS必须确保在任何给定时间，在重传队列中仅存在给定会话的一代临时记帐消息。
A NAS MAY use a fudge factor to add a random delay between Interim Accounting messages for separate sessions. This will ensure that a cycle where all messages are sent at once is prevented, such as might otherwise occur if a primary link was recently restored and many dial-up users were directed to the same NAS at once.
NAS可能会使用一个伪造因子在单独会话的临时记帐消息之间添加一个随机延迟。这将确保避免一次发送所有消息的循环，例如，如果最近恢复了主链路，并且许多拨号用户同时被定向到同一NAS，则可能会发生这种循环。
The Network and NAS CPU load of using Interim Updates should be carefully considered, and appropriate values of Acct-Interim-Interval chosen.
应仔细考虑使用临时更新的网络和NAS CPU负载，并选择适当的Acct临时间隔值。
The RADIUS (Remote Authentication Dial-In User Service) protocol provides a method that allows multiple dial-in Network Access Server (NAS) devices to share a common authentication database.
RADIUS（远程身份验证拨入用户服务）协议提供了一种允许多个拨入网络访问服务器（NAS）设备共享公共身份验证数据库的方法。
The Apple Remote Access Protocol (ARAP) provides a method for sending AppleTalk network traffic over point-to-point links, typically, but not exclusively, asynchronous and ISDN switched-circuit connections. Though Apple is moving toward ATCP on PPP for future remote access services, ARAP is still a common way for the installed base of Macintosh users to make remote network connections, and is likely to remain so for some time.
Apple Remote Access Protocol（ARAP）提供了一种通过点到点链路发送AppleTalk网络流量的方法，通常（但不限于）异步和ISDN交换电路连接。尽管苹果正在为未来的远程访问服务转向基于PPP的ATCP，但ARAP仍然是Macintosh安装用户进行远程网络连接的常用方式，并且可能在一段时间内保持这种状态。
ARAP is supported by several NAS vendors who also support PPP, IPX and other protocols in the same NAS. ARAP connections in these multi-protocol devices are often not authenticated with RADIUS, or if they are, each vendor creates an individual solution to the problem.
ARAP由多家NAS供应商支持，这些供应商还支持同一NAS中的PPP、IPX和其他协议。这些多协议设备中的ARAP连接通常不使用RADIUS进行身份验证，或者，如果是，每个供应商都会针对该问题创建一个单独的解决方案。
This section describes the use of additional RADIUS attributes to support ARAP. RADIUS client and server implementations that implement this specification should be able to authenticate ARAP connections in an interoperable manner.
本节介绍如何使用其他半径属性来支持ARAP。实现此规范的RADIUS客户端和服务器实现应该能够以互操作的方式对ARAP连接进行身份验证。
This section assumes prior knowledge of RADIUS, and will go into some detail on the operation of ARAP before entering a detailed discussion of the proposed ARAP RADIUS attributes.
本节假设事先了解RADIUS，并将在详细讨论拟议的ARAP RADIUS属性之前，详细介绍ARAP的操作。
There are two features of ARAP this document does not address:
ARAP有两个特点，本文件未涉及：
1. User initiated password changing. This is not part of RADIUS, but can be implemented through a software process other than RADIUS.
1. 用户发起的密码更改。这不是RADIUS的一部分，但可以通过RADIUS以外的软件过程实现。
2. Out-of-Band messages. At any time, the NAS can send messages to an ARA client which appear in a dialog box on the dial-in user's screen. These are not part of authentication and do not belong here. However, we note that a Reply-Message attribute in
2. 带外消息。NAS可以随时向ARA客户端发送消息，这些消息出现在拨号用户屏幕上的对话框中。这些不是身份验证的一部分，不属于此处。但是，我们注意到
an Access-Accept may be sent down to the user as a sign-on message of the day string using the out-of-band channel.
访问接受可以使用带外信道作为当天字符串的登录消息发送给用户。
We have tried to respect the spirit of the existing RADIUS protocol as much as possible, making design decisions compatible with prior art. Further, we have tried to strike a balance between flooding the RADIUS world with new attributes, and hiding all of ARAP operation within a single multiplexed ARAP attribute string or within Extended Authentication Protocol (EAP) [3] machinery.
我们尽可能地尊重现有RADIUS协议的精神，使设计决策与现有技术兼容。此外，我们还试图在用新属性淹没RADIUS世界和在单个多路复用的ARAP属性字符串或扩展认证协议（EAP）[3]机制中隐藏所有ARAP操作之间取得平衡。
However, we feel ARAP is enough of a departure from PPP to warrant a small set of similarly named attributes of its own.
然而，我们认为ARAP与PPP的背离足以保证其自身的一小部分类似命名的属性。
We have assumed that an ARAP-aware RADIUS server will be able to do DES encryption and generate security module challenges. This is in keeping with the general RADIUS goal of smart server / simple NAS.
我们假设ARAP感知RADIUS服务器将能够进行DES加密并生成安全模块挑战。这与智能服务器/简单NAS的RADIUS总体目标一致。
ARAP authenticates a connection in two phases. The first is a "Two-Way DES" random number exchange, using the user's password as a key. We say "Two-Way" because the ARAP NAS challenges the dial-in client to authenticate itself, and the dial-in client challenges the ARAP NAS to authenticate itself.
ARAP分两个阶段对连接进行身份验证。第一种是“双向DES”随机数交换，使用用户密码作为密钥。我们之所以说“双向”，是因为ARAP NAS挑战拨入客户端进行自我验证，而拨入客户端挑战ARAP NAS进行自我验证。
Specifically, ARAP does the following:
具体而言，ARAP做了以下工作：
1. The NAS sends two 32-bit random numbers to the dial-in client in an ARAP msg_auth_challenge packet.
1. NAS在ARAP msg_auth_质询数据包中向拨入客户端发送两个32位随机数。
2. The dial-in client uses the user's password to DES encrypt the two random numbers sent to it by the NAS. The dial-in client then sends this result, the user's name and two 32-bit random numbers of its own back to the NAS in an ARAP msg_auth_request packet.
2. 拨入客户端使用用户密码对NAS发送给它的两个随机数字进行DES加密。然后，拨入客户端在ARAP msg_auth_请求数据包中将该结果、用户名和它自己的两个32位随机数发送回NAS。
3. The NAS verifies the encrypted random numbers sent by the dial-in client are what it expected. If so, it encrypts the dial-in client's challenge using the password and sends it back to the dial-in client in an ARAP msg_auth_response packet.
3. NAS验证拨入客户端发送的加密随机数是否符合预期。如果是这样，它将使用密码加密拨入客户端的质询，并在ARAP msg_auth_响应数据包中将其发送回拨入客户端。
Note that if the dial-in client's response was wrong, meaning the user has the wrong password, the server can initiate a retry sequence up to the maximum amount of retries allowed by the NAS. In this case, when the dial-in client receives the ARAP msg_auth_response packet it will acknowledge it with an ARAP msg_auth_again packet.
请注意，如果拨入客户端的响应错误，即用户的密码错误，则服务器可以启动重试序列，最大重试次数为NAS允许的最大重试次数。在这种情况下，当拨入客户端接收到ARAP msg_auth_响应数据包时，它将再次使用ARAP msg_auth_数据包对其进行确认。
After this first "DES Phase" the ARAP NAS MAY initiate a secondary authentication phase using what Apple calls "Add-In Security Modules." Security Modules are small pieces of code which run on
在第一个“DES阶段”之后，ARAP NAS可能会使用苹果公司称之为“附加安全模块”的方式启动第二个身份验证阶段。安全模块是在计算机上运行的小块代码
both the client and server and are allowed to read and write arbitrary data across the communications link to perform additional authentication functions. Various security token vendors use this mechanism to authenticate ARA callers.
客户端和服务器都可以通过通信链路读取和写入任意数据，以执行附加的身份验证功能。各种安全令牌供应商使用此机制对ARA调用者进行身份验证。
Although ARAP allows security modules to read and write anything they like, all existing security modules use simple challenge and response cycles, with perhaps some overall control information. This document assumes all existing security modules can be supported with one or more challenge/response cycles.
尽管ARAP允许安全模块读写任何他们喜欢的东西，但所有现有的安全模块都使用简单的挑战和响应周期，可能还有一些总体控制信息。本文档假设所有现有安全模块都可以通过一个或多个质询/响应周期得到支持。
To complicate RADIUS and ARAP integration, ARAP sends down some profile information after the DES Phase and before the Security Module phase. This means that besides the responses to challenges, this profile information must also be present, at somewhat unusual times. Fortunately the information is only a few pieces of numeric data related to passwords, which this document packs into a single new attribute.
为了使RADIUS和ARAP集成复杂化，ARAP在DES阶段之后和安全模块阶段之前发送一些概要信息。这意味着，除了应对挑战外，还必须在某些不寻常的时候提供这些概要信息。幸运的是，这些信息只是与密码相关的一些数字数据，本文档将这些数据打包成一个新属性。
Presenting an Access-Request to RADIUS on behalf of an ARAP connection is straightforward. The ARAP NAS generates the random number challenge, and then receives the dial-in client's response, the dial-in client's challenge, and the user's name. Assuming the user is not a guest, the following information is forwarded in an Access-Request packet: User-Name (up to 31 characters long), Framed-Protocol (set to 3, ARAP), ARAP-Password, and any additional attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc.
代表ARAP连接向RADIUS提交访问请求非常简单。ARAP NAS生成随机数质询，然后接收拨入客户端的响应、拨入客户端的质询和用户名。假设用户不是来宾，则在访问请求数据包中转发以下信息：用户名（最多31个字符）、框架协议（设置为3，ARAP）、ARAP密码以及所需的任何其他属性，如服务类型、NAS IP地址、NAS Id、NAS端口类型、NAS端口、NAS端口Id、连接信息等。
The Request Authenticator is a NAS-generated 16 octet random number. The low-order 8 octets of this number are sent to the dial-in user as the two 4 octet random numbers required in the ARAP msg_auth_challenge packet. Octets 0-3 are the first random number and Octets 4-7 are the second random number.
请求验证器是NAS生成的16个八位组随机数。此号码的低位8个八位组作为ARAP msg_auth_质询数据包中所需的两个4个八位组随机数发送给拨入用户。八位字节0-3是第一个随机数，八位字节4-7是第二个随机数。
The ARAP-Password in the Access-Request contains a 16 octet random number field, and is used to carry the dial-in user's response to the NAS challenge and the client's own challenge to the NAS. The high-order octets contain the dial-in user's challenge to the NAS (2 32- bit numbers, 8 octets) and the low-order octets contain the dial-in user's response to the NAS challenge (2 32-bit numbers, 8 octets).
访问请求中的ARAP密码包含一个16个八位字节的随机数字段，用于携带拨入用户对NAS质询的响应以及客户端对NAS的质询。高阶八位字节包含拨入用户对NAS的质询（2个32位数字，8个八位字节），低阶八位字节包含拨入用户对NAS质询的响应（2个32位数字，8个八位字节）。
Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages.
访问请求或一条或多条EAP消息中只需存在用户密码、CHAP密码或ARAP密码中的一条。
If the RADIUS server does not support ARAP it SHOULD return an Access-Reject to the NAS.
如果RADIUS服务器不支持ARAP，则应返回对NAS的访问拒绝。
If the RADIUS server does support ARAP, it should verify the user's response using the Challenge (from the lower order 8 octets of the Request Authenticator) and the user's response (from the low order 8 octets of the ARAP-Password).
如果RADIUS服务器确实支持ARAP，则应使用质询（来自请求验证器的低阶8个八位字节）和用户响应（来自ARAP密码的低阶8个八位字节）验证用户的响应。
If that authentication fails, the RADIUS server should return an Access-Reject packet to the NAS, with optional Password-Retry and Reply-Messages attributes. The presence of Password-Retry indicates the ARAP NAS MAY choose to initiate another challenge-response cycle, up to a total number of times equal to the integer value of the Password-Retry attribute.
如果身份验证失败，RADIUS服务器应向NAS返回访问拒绝数据包，并带有可选的密码重试和回复消息属性。密码重试的存在表示ARAP NAS可以选择启动另一个质询响应周期，总次数等于密码重试属性的整数值。
If the user is authenticated, the RADIUS server should return an Access-Accept packet (Code 2) to the NAS, with ID and Response Authenticator as usual, and attributes as follows:
如果用户已通过身份验证，RADIUS服务器应向NAS返回一个访问接受数据包（代码2），其ID和响应身份验证符与往常一样，属性如下：
Service-Type of Framed-Protocol.
框架协议的服务类型。
Framed-Protocol of ARAP (3).
ARAP的框架协议（3）。
Session-Timeout with the maximum connect time for the user in seconds. If the user is to be given unlimited time, Session-Timeout should not be included in the Access-Accept packet, and ARAP will treat that as an unlimited timeout (-1).
会话超时，用户的最大连接时间（秒）。如果要给用户无限时间，则会话超时不应包含在访问接受数据包中，并且ARAP会将其视为无限超时（-1）。
ARAP-Challenge-Response, containing 8 octets with the response to the dial-in client's challenge. The RADIUS server calculates this value by taking the dial-in client's challenge from the high order 8 octets of the ARAP-Password attribute and performing DES encryption on this value with the authenticating user's password as the key. If the user's password is less than 8 octets in length, the password is padded at the end with NULL octets to a length of 8 before using it as a key. If the user's password is greater than 8 octets in length, an Access-Reject MUST be sent instead.
ARAP质询响应，包含8个八位字节，以及对拨入客户端质询的响应。RADIUS服务器通过从ARAP Password属性的高阶8个八位字节获取拨入客户端的质询，并使用身份验证用户的密码作为密钥对该值执行DES加密来计算该值。如果用户的密码长度小于8个八位字节，则在将其用作密钥之前，将在密码末尾用空八位字节填充到8个八位字节。如果用户密码长度大于8个八位字节，则必须发送访问拒绝。
ARAP-Features, containing information that the NAS should send to the user in an ARAP "feature flags" packet.
ARAP功能，包含NAS应在ARAP“功能标志”数据包中发送给用户的信息。
Octet 0: If zero, user cannot change their password. If non-zero user can. (RADIUS does not handle the password changing, just the attribute which indicates whether ARAP indicates they can.)
八位字节0：如果为零，则用户无法更改其密码。如果非零用户可以。（RADIUS不处理密码更改，只处理指示ARAP是否可以更改密码的属性。）
Octet 1: Minimum acceptable password length (0-8).
八位组1：可接受的最小密码长度（0-8）。
Octet 2-5: Password creation date in Macintosh format, defined as 32 bits unsigned representing seconds since Midnight GMT January 1, 1904.
八位字节2-5：Macintosh格式的密码创建日期，定义为32位无符号，表示自格林尼治标准时间1904年1月1日午夜起的秒数。
Octet 6-9 Password Expiration Delta from create date in seconds.
从创建日期算起的八位字节6-9密码过期增量（秒）。
Octet 10-13: Current RADIUS time in Macintosh format
八位组10-13：麦金塔格式的当前半径时间
Optionally, a single Reply-Message with a text string up to 253 characters long which MAY be sent down to the user to be displayed in a sign-on/message of the day dialog.
可选地，一条文本字符串长达253个字符的回复消息，可发送给用户，以显示在登录/当日消息对话框中。
Framed-AppleTalk-Network may be included.
可以包括框架AppleTalk网络。
Framed-AppleTalk-Zone, up to 32 characters in length, may be included.
可包括带边框的AppleTalk区域，长度不超过32个字符。
ARAP defines the notion of a list of zones for a user. Along with a list of zone names, a Zone Access Flag is defined (and used by the NAS) which says how to use the list of zone names. That is, the dial-in user may only be allowed to see the Default Zone, or only the zones in the zone list (inclusive) or any zone except those in the zone list (exclusive).
ARAP为用户定义了区域列表的概念。除了区域名称列表外，还定义了一个区域访问标志（NAS使用），该标志说明了如何使用区域名称列表。也就是说，拨入用户可能只允许查看默认区域，或仅允许查看区域列表中的区域（包括）或除区域列表中的区域（排除）以外的任何区域。
The ARAP NAS handles this by having a named filter which contains (at least) zone names. This solves the problem where a single RADIUS server is managing disparate NAS clients who may not be able to "see" all of the zone names in a user zone list. Zone names only have meaning "at the NAS." The disadvantage of this approach is that zone filters must be set up on the NAS somehow, then referenced by the RADIUS Filter-Id.
ARAP NAS通过具有包含（至少）区域名称的命名过滤器来处理此问题。这解决了单个RADIUS服务器管理可能无法“查看”用户区域列表中所有区域名称的不同NAS客户端的问题。区域名称仅具有“在NAS上”的含义。这种方法的缺点是必须以某种方式在NAS上设置区域过滤器，然后由RADIUS Filter-Id引用。
ARAP-Zone-Access contains an integer which specifies how the "zone list" for this user should be used. If this attribute is present and the value is 2 or 4 then a Filter-Id must also be present to name a zone list filter to apply the access flag to.
ARAP区域访问包含一个整数，指定如何使用此用户的“区域列表”。如果存在此属性且值为2或4，则还必须存在筛选器Id来命名要应用访问标志的区域列表筛选器。
The inclusion of a Callback-Number or Callback-Id attribute in the Access-Accept MAY cause the ARAP NAS to disconnect after sending the Feature Flags to begin callback processing in an ARAP specific way.
在Access Accept中包含回调编号或回调Id属性可能会导致ARAP NAS在发送功能标志后断开连接，以便以特定于ARAP的方式开始回调处理。
Other attributes may be present in the Access-Accept packet as well.
其他属性也可以存在于接入-接受分组中。
An ARAP NAS will need other information to finish bringing up the connection to the dial in client, but this information can be provided by the ARAP NAS without any help from RADIUS, either through configuration by SNMP, a NAS administration program, or deduced by the AppleTalk stack in the NAS. Specifically:
ARAP NAS需要其他信息来完成与拨入客户端的连接，但ARAP NAS可以通过SNMP配置、NAS管理程序或NAS中的AppleTalk堆栈提供此信息，而无需RADIUS的任何帮助。明确地：
1. AppearAsNet and AppearAsNode values, sent to the client to tell it what network and node numbers it should use in its datagram packets. AppearAsNet can be taken from the Framed-AppleTalk-Network attribute or from the configuration or AppleTalk stack onthe NAS.
1. AppearAsNet和AppearAsNode值，发送给客户端，告诉它应该在数据报数据包中使用什么网络和节点号。AppearAsNet可以从框架AppleTalk网络属性中获取，也可以从NAS上的配置或AppleTalk堆栈中获取。
2. The "default" zone - that is the name of the AppleTalk zone in which the dial-in client will appear. (Or can be specified with the Framed-AppleTalk-Zone attribute.)
2. “默认”区域-即拨号客户端将出现的AppleTalk区域的名称。（也可以使用Framed AppleTalk Zone属性指定。）
3. Other very NAS specific stuff such as the name of the NAS, and smartbuffering information. (Smartbuffering is an ARAP mechanism for replacing common AppleTalk datagrams with small tokens, to improve slow link performance in a few common traffic situations.)
3. 其他特定于NAS的内容，如NAS的名称和smartbuffering信息。（Smartbuffering是一种ARAP机制，用于用小令牌替换常见的AppleTalk数据报，以在一些常见流量情况下提高慢速链路性能。）
4. "Zone List" information for this user. The ARAP specification defines a "zone count" field which is actually unused.
4. 此用户的“区域列表”信息。ARAP规范定义了一个实际未使用的“区域计数”字段。
RADIUS supports ARAP Security Modules in the following manner.
RADIUS以以下方式支持ARAP安全模块。
After DES authentication has been completed, the RADIUS server may instruct the ARAP NAS to run one or more security modules for the dial-in user. Although the underlying protocol supports executing multiple security modules in series, in practice all current implementations only allow executing one. Through the use of multiple Access-Challenge requests, multiple modules can be supported, but this facility will probably never be used.
DES身份验证完成后，RADIUS服务器可指示ARAP NAS为拨入用户运行一个或多个安全模块。尽管底层协议支持串联执行多个安全模块，但实际上所有当前实现只允许执行一个。通过使用多访问质询请求，可以支持多个模块，但此功能可能永远不会被使用。
We also assume that, even though ARAP allows a free-form dialog between security modules on each end of the point-to-point link, in actual practice all security modules can be reduced to a simple challenge/response cycle.
我们还假设，即使ARAP允许点到点链路两端的安全模块之间进行自由形式的对话，但在实际操作中，所有安全模块都可以简化为一个简单的质询/响应周期。
If the RADIUS server wishes to instruct the ARAP NAS to run a security module, it should send an Access-Challenge packet to the NAS with (optionally) the State attribute, plus the ARAP-Challenge-Response, ARAP-Features, and two more attributes:
如果RADIUS服务器希望指示ARAP NAS运行安全模块，则应向NAS发送一个访问质询数据包，其中包含（可选）State属性、ARAP质询响应、ARAP功能和另外两个属性：
ARAP-Security: a four octet security module signature, containing a Macintosh OSType.
ARAP安全性：一个四个八位组的安全模块签名，包含一个Macintosh OSType。
ARAP-Security-Data, a string to carry the actual security module challenge and response.
ARAP安全数据，一个字符串，用于承载实际的安全模块质询和响应。
When the security module finishes executing, the security module response is passed in an ARAP-Security-Data attribute from the NAS to the RADIUS server in a second Access-Request, also including the State from the Access-Challenge. The authenticator field contains no special information in this case, and this can be discerned by the presence of the State attribute.
当安全模块完成执行时，安全模块响应在第二个访问请求中以ARAP安全数据属性的形式从NAS传递到RADIUS服务器，还包括访问质询的状态。在这种情况下，authenticator字段不包含特殊信息，这可以通过State属性的存在来识别。
The Extensible Authentication Protocol (EAP), described in [3], provides a standard mechanism for support of additional authentication methods within PPP. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos, Public Key, One Time Passwords, and others. In order to provide for support of EAP within RADIUS, two new attributes, EAP-Message and Message-Authenticator, are introduced in this document. This section describes how these new attributes may be used for providing EAP support within RADIUS.
[3]中描述的可扩展身份验证协议（EAP）提供了一种标准机制，用于支持PPP中的其他身份验证方法。通过使用EAP，可以添加对许多身份验证方案的支持，包括智能卡、Kerberos、公钥、一次性密码等。为了在RADIUS内提供EAP支持，本文引入了两个新属性，EAP消息和消息验证器。本节介绍如何使用这些新属性在RADIUS内提供EAP支持。
In the proposed scheme, the RADIUS server is used to shuttle RADIUS-encapsulated EAP Packets between the NAS and a backend security server. While the conversation between the RADIUS server and the backend security server will typically occur using a proprietary protocol developed by the backend security server vendor, it is also possible to use RADIUS-encapsulated EAP via the EAP-Message attribute. This has the advantage of allowing the RADIUS server to support EAP without the need for authentication-specific code, which can instead reside on the backend security server.
在该方案中，RADIUS服务器用于在NAS和后端安全服务器之间穿梭RADIUS封装的EAP数据包。虽然RADIUS服务器和后端安全服务器之间的对话通常使用后端安全服务器供应商开发的专有协议进行，但也可以通过EAP消息属性使用RADIUS封装的EAP。这样做的优点是允许RADIUS服务器支持EAP，而不需要特定于身份验证的代码，该代码可以驻留在后端安全服务器上。
The EAP conversation between the authenticating peer (dial-in user) and the NAS begins with the negotiation of EAP within LCP. Once EAP has been negotiated, the NAS MUST send an EAP-Request/Identity message to the authenticating peer, unless identity is determined via some other means such as Called-Station-Id or Calling-Station-Id. The peer will then respond with an EAP-Response/Identity which the the NAS will then forward to the RADIUS server in the EAP-Message attribute of a RADIUS Access-Request packet. The RADIUS Server will typically use the EAP-Response/Identity to determine which EAP type is to be applied to the user.
认证对等方（拨入用户）和NAS之间的EAP对话从LCP内的EAP协商开始。一旦协商EAP，NAS必须向认证对等方发送EAP请求/标识消息，除非通过其他方式（如被叫站Id或主叫站Id）确定标识。否则，对等方随后将使用EAP响应/标识进行响应，NAS随后将在RADIUS访问请求数据包的EAP消息属性中转发给RADIUS服务器。RADIUS服务器通常会使用EAP响应/标识来确定将应用于用户的EAP类型。
In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS sends the EAP-Request/Identity, the NAS MUST copy the contents of the EAP-Response/Identity into the User-Name attribute and MUST include the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. NAS-Port or NAS-Port-Id SHOULD be included in the attributes issued by the NAS in the Access-Request packet, and either NAS-Identifier or NAS-IP-Address MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name attribute was included in an Access-Request, the RADIUS Server MUST include the User-Name attribute in subsequent Access-Accept packets. Without the User-Name attribute, accounting and billing becomes very difficult to manage.
为了允许非EAP感知的RADIUS代理转发访问请求数据包，如果NAS发送EAP请求/标识，NAS必须将EAP响应/标识的内容复制到用户名属性中，并且必须在每个后续访问请求的用户名属性中包含EAP响应/标识。NAS端口或NAS端口Id应包含在NAS在访问请求数据包中发布的属性中，并且必须包含NAS标识符或NAS IP地址。为了允许EAP非感知代理转发访问回复，如果访问请求中包含用户名属性，RADIUS服务器必须在后续访问接受数据包中包含用户名属性。如果没有用户名属性，记帐和计费将变得非常难以管理。
If identity is determined via another means such as Called-Station-Id or Calling-Station-Id, the NAS MUST include these identifying attributes in every Access-Request.
如果通过另一种方式（如被叫站Id或主叫站Id）确定标识，则NAS必须在每个访问请求中包含这些标识属性。
While this approach will save a round-trip, it cannot be universally employed. There are circumstances in which the user's identity may not be needed (such as when authentication and accounting is handled based on Called-Station-Id or Calling-Station-Id), and therefore an EAP-Request/Identity packet may not necessarily be issued by the NAS to the authenticating peer. In cases where an EAP-Request/Identity packet will not be sent, the NAS will send to the RADIUS server a RADIUS Access-Request packet containing an EAP-Message attribute signifying EAP-Start. EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). However, it should be noted that since no User-Name attribute is included in the Access-Request, this approach is not compatible with RADIUS as specified in [1], nor can it easily be applied in situations where proxies are deployed, such as roaming or shared use networks.
虽然这种方法可以节省往返时间，但不能普遍采用。存在可能不需要用户的身份的情况（例如，当基于被叫站Id或主叫站Id处理认证和记帐时），因此，NAS可能不一定向认证对等方发出EAP请求/身份分组。在不发送EAP请求/标识数据包的情况下，NAS将向RADIUS服务器发送一个RADIUS访问请求数据包，其中包含表示EAP启动的EAP消息属性。EAP启动通过发送长度为2（无数据）的EAP消息属性来指示。然而，应该注意的是，由于访问请求中不包括用户名属性，因此这种方法与[1]中指定的RADIUS不兼容，也不容易应用于部署代理的情况，例如漫游或共享使用网络。
If the RADIUS server supports EAP, it MUST respond with an Access-Challenge packet containing an EAP-Message attribute. If the RADIUS server does not support EAP, it MUST respond with an Access-Reject. The EAP-Message attribute includes an encapsulated EAP packet which is then passed on to the authenticating peer. In the case where the NAS does not initially send an EAP-Request/Identity message to the peer, the Access-Challenge typically will contain an EAP-Message attribute encapsulating an EAP-Request/Identity message, requesting the dial-in user to identify themself. The NAS will then respond with a RADIUS Access-Request packet containing an EAP-Message attribute encapsulating an EAP-Response. The conversation continues until either a RADIUS Access-Reject or Access-Accept packet is received.
如果RADIUS服务器支持EAP，则必须使用包含EAP消息属性的访问质询数据包进行响应。如果RADIUS服务器不支持EAP，它必须以访问拒绝响应。EAP消息属性包括一个封装的EAP数据包，然后该数据包被传递给认证对等方。在NAS最初不向对等方发送EAP请求/标识消息的情况下，访问质询通常将包含封装EAP请求/标识消息的EAP消息属性，请求拨入用户识别自己。NAS随后将使用包含封装EAP响应的EAP消息属性的RADIUS访问请求数据包进行响应。对话将继续，直到收到RADIUS访问拒绝或访问接受数据包。
Reception of a RADIUS Access-Reject packet, with or without an EAP-Message attribute encapsulating EAP-Failure, MUST result in the NAS issuing an LCP Terminate Request to the authenticating peer. A RADIUS Access-Accept packet with an EAP-Message attribute encapsulating EAP-Success successfully ends the authentication phase. The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain all of the expected attributes which are currently returned in an Access-Accept packet.
接收到RADIUS访问拒绝数据包，无论是否带有封装EAP故障的EAP消息属性，都必须导致NAS向认证对等方发出LCP终止请求。具有封装EAP Success的EAP消息属性的RADIUS访问接受数据包成功结束身份验证阶段。RADIUS访问接受/EAP消息/EAP成功数据包必须包含访问接受数据包中当前返回的所有预期属性。
The above scenario creates a situation in which the NAS never needs to manipulate an EAP packet. An alternative may be used in situations where an EAP-Request/Identity message will always be sent by the NAS to the authenticating peer.
上述场景会造成NAS永远不需要操纵EAP数据包的情况。在NAS始终向认证对等方发送EAP请求/标识消息的情况下，可以使用另一种方法。
For proxied RADIUS requests there are two methods of processing. If the domain is determined based on the Called-Station-Id, the RADIUS Server may proxy the initial RADIUS Access-Request/EAP-Start. If the domain is determined based on the user's identity, the local RADIUS Server MUST respond with a RADIUS Access-Challenge/EAP-Identity packet. The response from the authenticating peer MUST be proxied to the final authentication server.
对于代理RADIUS请求，有两种处理方法。如果域是基于被叫站点Id确定的，RADIUS服务器可以代理初始RADIUS访问请求/EAP启动。如果根据用户的身份确定域，则本地RADIUS服务器必须使用RADIUS访问质询/EAP身份数据包进行响应。来自身份验证对等方的响应必须代理到最终身份验证服务器。
For proxied RADIUS requests, the NAS may receive an Access-Reject packet in response to its Access-Request/EAP-Identity packet. This would occur if the message was proxied to a RADIUS Server which does not support the EAP-Message extension. On receiving an Access-Reject, the NAS MUST send an LCP Terminate Request to the authenticating peer, and disconnect.
对于代理的RADIUS请求，NAS可接收访问拒绝分组以响应其访问请求/EAP标识分组。如果消息被代理到不支持EAP消息扩展的RADIUS服务器，则会发生这种情况。在接收到访问拒绝时，NAS必须向身份验证对等方发送LCP终止请求，并断开连接。
As noted in [3], the EAP authenticator (NAS) is responsible for retransmission of packets between the authenticating peer and the NAS. Thus if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit. As in RADIUS [1], the RADIUS client is responsible for retransmission of packets between the RADIUS client and the RADIUS server.
如[3]所述，EAP认证器（NAS）负责在认证对等方和NAS之间重新传输数据包。因此，如果EAP数据包在认证对等方和NAS之间的传输过程中丢失（反之亦然），NAS将重新传输。与RADIUS[1]中一样，RADIUS客户端负责在RADIUS客户端和RADIUS服务器之间重新传输数据包。
Note that it may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the RADIUS server. This can be accomplished by inclusion of Session-Timeout and Password-Retry attributes within the Access-Challenge packet.
注意，在某些情况下，可能需要调整重传策略和认证超时。例如，当使用令牌卡时，可能需要额外的时间来允许用户找到该卡并输入令牌。由于NAS通常不知道所需的参数，因此需要由RADIUS服务器提供这些参数。这可以通过在访问质询数据包中包含会话超时和密码重试属性来实现。
If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout provides the NAS with the maximum number of seconds the NAS should wait for an EAP-Response before retransmitting the EAP-Message to the dial-in user.
如果也包含EAP消息的访问质询数据包中存在会话超时，则会话超时值为NAS提供了在将EAP消息重新传输给拨入用户之前NAS应等待EAP响应的最长秒数。
Using the EAP-Message attribute, it is possible for the RADIUS server to encapsulate an EAP packet that is larger than the MTU on the link between the NAS and the peer. Since it is not possible for the RADIUS server to use MTU discovery to ascertain the link MTU, the Framed-MTU attribute may be included in an Access-Request packet containing an EAP-Message attribute so as to provide the RADIUS server with this information.
使用EAP消息属性，RADIUS服务器可以在NAS和对等机之间的链路上封装比MTU大的EAP数据包。由于RADIUS服务器不可能使用MTU发现来确定链路MTU，因此帧MTU属性可以包括在包含EAP消息属性的访问请求分组中，以便向RADIUS服务器提供该信息。
The example below shows the conversation between the authenticating peer, NAS, and RADIUS server, for the case of a One Time Password (OTP) authentication. OTP is used only for illustrative purposes; other authentication protocols could also have been used, although they might show somewhat different behavior.
下面的示例显示了在一次性密码（OTP）身份验证的情况下，身份验证对等方、NAS和RADIUS服务器之间的对话。OTP仅用于说明目的；也可以使用其他身份验证协议，尽管它们可能表现出一些不同的行为。
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts
RADIUS访问请求/EAP消息/EAP响应/OTP，OTPpw-><-RADIUS访问接受/EAP消息/EAP成功（其他属性）<-PPP EAP成功PPP认证阶段完成，NCP阶段开始
In the case where the NAS first sends an EAP-Start packet to the RADIUS server, the conversation would appear as follows:
在NAS首次向RADIUS服务器发送EAP启动数据包的情况下，对话将显示如下：
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EA-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EA-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts
RADIUS访问请求/EAP消息/EAP响应/OTP，OTPpw-><-RADIUS访问接受/EAP消息/EAP成功（其他属性）<-PPP EAP成功PPP认证阶段完成，NCP阶段开始
In the case where the client fails EAP authentication, the conversation would appear as follows:
如果客户端未能通过EAP身份验证，对话将如下所示：
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS
Access-Request/
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS
Access-Request/
EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Reject/ EAP-Message/EAP-Failure
EAP消息/EAP响应/OTP，OTPpw-><-RADIUS访问拒绝/EAP消息/EAP故障
<- PPP EAP-Failure (client disconnected)
<-PPP EAP故障（客户端断开连接）
In the case that the RADIUS server or proxy does not support EAP-Message, the conversation would appear as follows:
如果RADIUS服务器或代理不支持EAP消息，对话将显示如下：
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)
<-PPP LCP请求EAP auth PPP LCP ACK-EAP auth->RADIUS访问请求/EAP消息/Start-><-RADIUS访问拒绝<-PPP LCP终止（用户断开连接）
In the case where the local RADIUS Server does support EAP-Message, but the remote RADIUS Server does not, the conversation would appear as follows:
如果本地RADIUS服务器不支持EAP消息，而远程RADIUS服务器不支持EAP消息，则对话将显示如下：
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- PPP EAP-Request/ Identity
<-PPP LCP请求EAP身份验证PPP LCP确认-EAP身份验证->RADIUS访问请求/EAP消息/Start-><-RADIUS访问质询/EAP消息/Identity<-PPP EAP请求/Identity
PPP EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Reject (proxied from remote RADIUS Server) <- PPP LCP Terminate (User Disconnected)
PPP EAP响应/标识（MyID）->RADIUS访问请求/EAP消息/EAP响应/（MyID）-><-RADIUS访问拒绝（从远程RADIUS服务器代理）<-PPP LCP终止（用户断开连接）
In the case where the authenticating peer does not support EAP, but where EAP is required for that user, the conversation would appear as follows:
在认证对等方不支持EAP，但该用户需要EAP的情况下，对话将显示如下：
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP auth PPP LCP NAK-EAP auth -> <- PPP LCP Request-CHAP auth PPP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)
<-PPP LCP请求EAP auth PPP LCP NAK-EAP auth-><-PPP LCP请求CHAP auth PPP LCP ACK-CHAP auth-><-PPP CHAP质询PPP CHAP响应->RADIUS访问请求/用户名、CHAP密码-><-RADIUS访问拒绝<-PPP LCP终止（用户断开连接）
In the case where the NAS does not support EAP, but where EAP is required for that user, the conversation would appear as follows:
如果NAS不支持EAP，但该用户需要EAP，则对话将显示如下：
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-CHAP auth
<-PPP LCP请求CHAP验证
PP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password ->
PP LCP ACK-CHAP验证-><-PPP CHAP挑战PPP CHAP响应->RADIUS访问请求/用户名、CHAP密码->
<- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)
<-RADIUS访问拒绝<-PPP LCP终止（用户断开连接）
Currently the conversation between the backend security server and the RADIUS server is proprietary because of lack of standardization. In order to increase standardization and provide interoperability between Radius vendors and backend security vendors, it is recommended that RADIUS-encapsulated EAP be used for this conversation.
目前，由于缺乏标准化，后端安全服务器和RADIUS服务器之间的对话是专有的。为了提高标准化并提供Radius供应商和后端安全供应商之间的互操作性，建议将Radius封装的EAP用于此对话。
This has the advantage of allowing the RADIUS server to support EAP without the need for authentication-specific code within the RADIUS server. Authentication-specific code can then reside on a backend security server instead.
这样做的优点是允许RADIUS服务器支持EAP，而无需在RADIUS服务器中使用特定于身份验证的代码。然后，特定于身份验证的代码可以驻留在后端安全服务器上。
In the case where RADIUS-encapsulated EAP is used in a conversation between a RADIUS server and a backend security server, the security server will typically return an Access-Accept/EAP-Success message without inclusion of the expected attributes currently returned in an Access-Accept. This means that the RADIUS server MUST add these attributes prior to sending an Access-Accept/EAP-Success message to the NAS.
如果在RADIUS服务器和后端安全服务器之间的对话中使用RADIUS封装的EAP，则安全服务器通常会返回Access Accept/EAP成功消息，而不包括Access Accept中当前返回的预期属性。这意味着RADIUS服务器必须在向NAS发送访问接受/EAP成功消息之前添加这些属性。
Packet Format is identical to that defined in RFC 2865 [1] and 2866 [2].
数据包格式与RFC 2865[1]和2866[2]中定义的格式相同。
Packet types are identical to those defined in RFC 2865 [1] and 2866 [2].
数据包类型与RFC 2865[1]和2866[2]中定义的数据包类型相同。
See "Table of Attributes" below to determine which types of packets can contain which attributes defined here.
请参阅下面的“属性表”，以确定哪些类型的数据包可以包含此处定义的属性。
RADIUS Attributes carry the specific authentication, authorization and accounting details for the request and response.
RADIUS属性包含请求和响应的特定身份验证、授权和记帐详细信息。
Some attributes MAY be included more than once. The effect of this is attribute specific, and is specified in each attribute description. The order of attributes of the same type SHOULD be preserved. The order of attributes of different types is not required to be preserved.
某些属性可能包含多次。其效果是特定于属性的，并在每个属性描述中指定。应保留相同类型属性的顺序。不需要保留不同类型属性的顺序。
The end of the list of attributes is indicated by the Length of the RADIUS packet.
属性列表的末尾由RADIUS数据包的长度表示。
A summary of the attribute format is the same as in RFC 2865 [1] but is included here for ease of reference. The fields are transmitted from left to right.
属性格式的摘要与RFC 2865[1]中的内容相同，但为了便于参考，此处将其包括在内。字段从左向右传输。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
The Type field is one octet. Up-to-date values of the RADIUS Type field are specified in the most recent "Assigned Numbers" RFC [5]. Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used. This specification concerns the following values:
类型字段是一个八位字节。半径类型字段的最新值在最近的“已分配编号”RFC[5]中指定。值192-223保留供实验使用，值224-240保留供具体实现使用，值241-255保留且不应使用。本规范涉及以下值：
1-39 (refer to RFC 2865 [1], "RADIUS") 40-51 (refer to RFC 2866 [2], "RADIUS Accounting") 52 Acct-Input-Gigawords 53 Acct-Output-Gigawords 54 Unused 55 Event-Timestamp 56-59 Unused 60-63 (refer to RFC 2865 [1], "RADIUS") 64-67 (refer to [6]) 68 (refer to [7]) 69 (refer to [6]) 70 ARAP-Password 71 ARAP-Features 72 ARAP-Zone-Access
1-39（参考RFC 2865[1]，“RADIUS”）40-51（参考RFC 2866[2]，“RADIUS记帐”）52账户输入千兆字53账户输出千兆字54未使用55事件时间戳56-59未使用60-63（参考RFC 2865[1]，“RADIUS”）64-67（参考[6]）68（参考[7]）69（参考[6]）70 ARAP密码71 ARAP功能72 ARAP区域访问
73 ARAP-Security 74 ARAP-Security-Data 75 Password-Retry 76 Prompt 77 Connect-Info 78 Configuration-Token 79 EAP-Message 80 Message-Authenticator 81-83 (refer to [6]) 84 ARAP-Challenge-Response 85 Acct-Interim-Interval 86 (refer to [7]) 87 NAS-Port-Id 88 Framed-Pool 89 Unused 90-91 (refer to [6]) 92-191 Unused
73 ARAP安全74 ARAP安全数据75密码重试76提示77连接信息78配置令牌79 EAP消息80消息验证器81-83（参考[6]）84 ARAP质询响应85帐户临时间隔86（参考[7]）87 NAS端口Id 88帧池89未使用90-91（参考[6]）92-191未使用
Length
长
The Length field is one octet, and indicates the length of this attribute including the Type, Length and Value fields. If an attribute is received in a packet with an invalid Length, the entire request should be silently discarded.
长度字段是一个八位字节，表示该属性的长度，包括类型、长度和值字段。如果在具有无效长度的数据包中接收到属性，则整个请求应被静默地丢弃。
Value
价值
The Value field is zero or more octets and contains information specific to the attribute. The format and length of the Value field is determined by the Type and Length fields.
值字段为零个或多个八位字节，包含特定于属性的信息。值字段的格式和长度由类型和长度字段决定。
Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types "text" and "string" in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [8] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings.
请注意，RADIUS中的所有类型都不会以NUL（十六进制00）终止。特别是，RADIUS中的类型“text”和“string”不会以NUL（十六进制00）结尾。该属性有一个长度字段，不使用终止符。文本包含UTF-8编码的10646[8]个字符，字符串包含8位二进制数据。服务器、服务器和客户端必须能够处理嵌入的空值。使用C的RADIUS实现者在处理字符串时应注意不要使用strcpy（）。
The format of the value field is one of five data types. Note that type "text" is a subset of type "string."
值字段的格式是五种数据类型之一。请注意，“text”类型是“string”类型的子集
text 1-253 octets containing UTF-8 encoded 10646 [8] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead.
文本1-253个八位字节，包含UTF-8编码的10646[8]个字符。不得发送长度为零（0）的文本；而忽略整个属性。
string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead.
字符串1-253个八位字节，包含二进制数据（0到255个十进制值，含）。不得发送长度为零（0）的字符串；而忽略整个属性。
address 32 bit unsigned value, most significant octet first.
地址32位无符号值，最重要的八位位组在前。
integer 32 bit unsigned value, most significant octet first.
整数32位无符号值，最高有效八位位组在先。
time 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970.
时间32位无符号值，最高有效八位组第一位--自1970年1月1日UTC 00:00:00以来的秒数。
Description
描述
This attribute indicates how many times the Acct-Input-Octets counter has wrapped around 2^32 over the course of this service being provided, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop or Interim-Update.
此属性表示在提供此服务的过程中，Acct Input Octets计数器环绕2^32的次数，并且只能出现在Acct Status Type设置为Stop（停止）或Missional Update（临时更新）的记帐请求记录中。
A summary of the Acct-Input-Gigawords attribute format is shown below. The fields are transmitted from left to right.
Acct Input Gigawords属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
52 for Acct-Input-Gigawords.
52用于帐户输入千兆字。
Length
长
6
6.
Value
价值
The Value field is four octets.
值字段是四个八位字节。
Description
描述
This attribute indicates how many times the Acct-Output-Octets counter has wrapped around 2^32 in the course of delivering this service, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop or Interim-Update.
此属性表示在提供此服务的过程中，Acct Output Octets计数器环绕2^32的次数，并且只能出现在Acct Status Type设置为Stop（停止）或Missional Update（临时更新）的记帐请求记录中。
A summary of the Acct-Output-Gigawords attribute format is shown below. The fields are transmitted from left to right.
Acct Output Gigawords属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
53 for Acct-Output-Gigawords.
53用于帐户输出千兆字。
Length
长
6
6.
Value
价值
The Value field is four octets.
值字段是四个八位字节。
Description
描述
This attribute is included in an Accounting-Request packet to record the time that this event occurred on the NAS, in seconds since January 1, 1970 00:00 UTC.
此属性包含在记帐请求数据包中，用于记录自1970年1月1日00:00 UTC以来NAS上发生此事件的时间（以秒为单位）。
A summary of the Event-Timestamp attribute format is shown below. The fields are transmitted from left to right.
事件时间戳属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
55 for Event-Timestamp
55表示事件时间戳
Length
长
6
6.
Value
价值
The Value field is four octets encoding an unsigned integer with the number of seconds since January 1, 1970 00:00 UTC.
值字段是四个八位字节，编码一个无符号整数，自1970年1月1日00:00 UTC起的秒数。
Description
描述
This attribute is only present in an Access-Request packet containing a Framed-Protocol of ARAP.
此属性仅存在于包含ARAP框架协议的访问请求数据包中。
Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages.
访问请求或一条或多条EAP消息中只需存在用户密码、CHAP密码或ARAP密码中的一条。
A summary of the ARAP-Password attribute format is shown below. The fields are transmitted from left to right.
ARAP密码属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
70 for ARAP-Password.
70表示ARAP密码。
Length
长
18
18
Value
价值
This attribute contains a 16 octet string, used to carry the dial-in user's response to the NAS challenge and the client's own challenge to the NAS. The high-order octets (Value1 and Value2) contain the dial-in user's challenge to the NAS (2 32-bit numbers, 8 octets) and the low-order octets (Value3 and Value4) contain the dial-in user's response to the NAS challenge (2 32-bit numbers, 8 octets).
此属性包含一个16字节的字符串，用于携带拨入用户对NAS质询的响应以及客户端对NAS的质询。高阶八位字节（值1和值2）包含拨入用户对NAS的质询（2个32位数字，8个八位字节），低阶八位字节（值3和值4）包含拨入用户对NAS质询的响应（2个32位数字，8个八位字节）。
Description
描述
This attribute is sent in an Access-Accept packet with Framed-Protocol of ARAP, and includes password information that the NAS should sent to the user in an ARAP "feature flags" packet.
该属性在具有ARAP框架协议的访问接受数据包中发送，并包括NAS应在ARAP“功能标志”数据包中发送给用户的密码信息。
A summary of the ARAP-Features attribute format is shown below. The fields are transmitted from left to right.
ARAP Features属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
71 for ARAP-Features.
71用于ARAP功能。
Length
长
16
16
Value
价值
The Value field is a compound string containing information the NAS should send to the user in the ARAP "feature flags" packet.
值字段是一个复合字符串，包含NAS应在ARAP“功能标志”数据包中发送给用户的信息。
Value1: If zero, user cannot change their password. If non-zero user can. (RADIUS does not handle the password changing, just the attribute which indicates whether ARAP indicates they can.)
值1：如果为零，则用户无法更改其密码。如果非零用户可以。（RADIUS不处理密码更改，只处理指示ARAP是否可以更改密码的属性。）
Value2: Minimum acceptable password length, from 0 to 8.
值2：可接受的最小密码长度，从0到8。
Value3: Password creation date in Macintosh format, defined as 32 unsigned bits representing seconds since Midnight GMT January 1, 1904.
值3：Macintosh格式的密码创建日期，定义为32个无符号位，表示自1904年1月1日格林尼治标准时间午夜起的秒数。
Value4: Password Expiration Delta from create date in seconds.
值4:从创建日期算起的密码过期增量（秒）。
Value5: Current RADIUS time in Macintosh format.
值5：Macintosh格式的当前RADIUS时间。
Description
描述
This attribute is included in an Access-Accept packet with Framed-Protocol of ARAP to indicate how the ARAP zone list for the user should be used.
此属性包含在具有ARAP框架协议的访问接受数据包中，以指示应如何使用用户的ARAP区域列表。
A summary of the ARAP-Zone-Access attribute format is shown below. The fields are transmitted from left to right.
ARAP区域访问属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
72 for ARAP-Zone-Access.
72用于ARAP区域访问。
Length
长
6
6.
Value
价值
The Value field is four octets encoding an integer with one of the following values:
值字段是四个八位字节，用以下值之一编码整数：
1 Only allow access to default zone 2 Use zone filter inclusively 4 Use zone filter exclusively
1仅允许访问默认区域2包括使用区域筛选器4仅使用区域筛选器
The value 3 is skipped, not because these are bit flags, but because 3 in some ARAP implementations means "all zones" which is the same as not specifying a list at all under RADIUS.
跳过值3，不是因为它们是位标志，而是因为在某些ARAP实现中3表示“所有区域”，这与在RADIUS下完全不指定列表相同。
If this attribute is present and the value is 2 or 4 then a Filter-Id must also be present to name a zone list filter to apply the access flag to.
如果存在此属性且值为2或4，则还必须存在筛选器Id来命名要应用访问标志的区域列表筛选器。
Description
描述
This attribute identifies the ARAP Security Module to be used in an Access-Challenge packet.
此属性标识要在访问质询数据包中使用的ARAP安全模块。
A summary of the ARAP-Security attribute format is shown below. The fields are transmitted from left to right.
ARAP安全属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
73 for ARAP-Security.
73阿拉普安全局。
Length
长
6
6.
Value
价值
The Value field is four octets, containing an integer specifying the security module signature, which is a Macintosh OSType. (Macintosh OSTypes are 4 ascii characters cast as a 32-bit integer)
值字段是四个八位字节，包含一个指定安全模块签名的整数，该签名是Macintosh OSType。（Macintosh OSTYPE是4个ascii字符，转换为32位整数）
Description
描述
This attribute contains the actual security module challenge or response, and can be found in Access-Challenge and Access-Request packets.
此属性包含实际的安全模块质询或响应，可在访问质询和访问请求数据包中找到。
A summary of the ARAP-Security-Data attribute format is shown below. The fields are transmitted from left to right.
ARAP安全数据属性格式的摘要如下所示。字段从左向右传输。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
74 for ARAP-Security-Data.
74用于ARAP安全数据。
Length
长
>=3
>=3
String
一串
The String field contains the security module challenge or response associated with the ARAP Security Module specified in ARAP-Security.
字符串字段包含与在ARAP security中指定的ARAP安全模块关联的安全模块质询或响应。
Description
描述
This attribute MAY be included in an Access-Reject to indicate how many authentication attempts a user may be allowed to attempt before being disconnected.
此属性可以包含在访问拒绝中，以指示在断开连接之前允许用户尝试的身份验证次数。
It is primarily intended for use with ARAP authentication.
它主要用于ARAP身份验证。
A summary of the Password-Retry attribute format is shown below. The fields are transmitted from left to right.
密码重试属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
75 for Password-Retry.
75用于密码重试。
Length
长
6
6.
Value
价值
The Value field is four octets, containing an integer specifying the number of password retry attempts to permit the user.
值字段是四个八位字节，包含一个整数，指定允许用户重试密码的次数。
Description
描述
This attribute is used only in Access-Challenge packets, and indicates to the NAS whether it should echo the user's response as it is entered, or not echo it.
此属性仅在访问质询数据包中使用，并向NAS指示是否应在输入时回显用户的响应，或不回显用户的响应。
A summary of the Prompt attribute format is shown below. The fields are transmitted from left to right.
提示属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
76 for Prompt.
76英镑，请立即付款。
Length
长
6
6.
Value
价值
The Value field is four octets.
值字段是四个八位字节。
0 No Echo 1 Echo
0无回音1回音
Description
描述
This attribute is sent from the NAS to indicate the nature of the user's connection.
此属性从NAS发送以指示用户连接的性质。
The NAS MAY send this attribute in an Access-Request or Accounting-Request to indicate the nature of the user's connection.
NAS可以在访问请求或记帐请求中发送此属性，以指示用户连接的性质。
A summary of the Connect-Info attribute format is shown below. The fields are transmitted from left to right.
“连接信息”属性格式的摘要如下所示。字段从左向右传输。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
77 for Connect-Info.
77获取连接信息。
Length
长
>= 3
>= 3
Text
文本
The Text field consists of UTF-8 encoded 10646 [8] characters. The connection speed SHOULD be included at the beginning of the first Connect-Info attribute in the packet. If the transmit and receive connection speeds differ, they may both be included in the first attribute with the transmit speed first (the speed the NAS modem transmits at), a slash (/), the receive speed, then optionally other information.
文本字段由UTF-8编码的10646[8]个字符组成。连接速度应包含在数据包中第一个Connect Info属性的开头。如果发送和接收连接速度不同，则它们可能都包含在第一个属性中，首先是发送速度（NAS调制解调器的传输速度）、斜杠（/）、接收速度，然后是可选的其他信息。
For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
例如，“28800 V42BIS/LAPM”或“52000/31200 V90”
More than one Connect-Info attribute may be present in an Accounting-Request packet to accommodate expected efforts by ITU to have modems report more connection information in a standard format that might exceed 252 octets.
计费请求数据包中可能存在多个连接信息属性，以适应ITU的预期努力，使调制解调器以可能超过252个八位字节的标准格式报告更多的连接信息。
Description
描述
This attribute is for use in large distributed authentication networks based on proxy. It is sent from a RADIUS Proxy Server to a RADIUS Proxy Client in an Access-Accept to indicate a type of user profile to be used. It should not be sent to a NAS.
此属性用于基于代理的大型分布式身份验证网络。它从RADIUS代理服务器发送到Access Accept中的RADIUS代理客户端，以指示要使用的用户配置文件的类型。不应将其发送到NAS。
A summary of the Configuration-Token attribute format is shown below. The fields are transmitted from left to right.
配置令牌属性格式的摘要如下所示。字段从左向右传输。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
78 for Configuration-Token.
78用于配置令牌。
Length
长
>= 3
>= 3
String
一串
The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
字符串字段是一个或多个八位字节。信息的实际格式是特定于站点或应用程序的，一个健壮的实现应该支持字段作为无差别的八位字节。
The codification of the range of allowed usage of this field is outside the scope of this specification.
该字段允许使用范围的编码不在本规范范围内。
Description
描述
This attribute encapsulates Extended Access Protocol [3] packets so as to allow the NAS to authenticate dial-in users via EAP without having to understand the EAP protocol.
此属性封装扩展访问协议[3]数据包，以便允许NAS通过EAP对拨入用户进行身份验证，而无需了解EAP协议。
The NAS places any EAP messages received from the user into one or more EAP attributes and forwards them to the RADIUS Server as part of the Access-Request, which can return EAP messages in Access-Challenge, Access-Accept and Access-Reject packets.
NAS将从用户接收的任何EAP消息放入一个或多个EAP属性中，并将其作为访问请求的一部分转发到RADIUS服务器，该服务器可以在访问质询、访问接受和访问拒绝数据包中返回EAP消息。
A RADIUS Server receiving EAP messages that it does not understand SHOULD return an Access-Reject.
RADIUS服务器接收其不理解的EAP消息时，应返回访问拒绝。
The NAS places EAP messages received from the authenticating peer into one or more EAP-Message attributes and forwards them to the RADIUS Server within an Access-Request message. If multiple EAP-Messages are contained within an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. Access-Accept and Access-Reject packets SHOULD only have ONE EAP-Message attribute in them, containing EAP-Success or EAP-Failure.
NAS将从身份验证对等方接收的EAP消息放入一个或多个EAP消息属性中，并在访问请求消息中将其转发到RADIUS服务器。如果一个访问请求或访问质询数据包中包含多个EAP消息，则它们必须是有序的，并且它们必须是访问请求或访问质询数据包中的连续属性。Access Accept和Access Reject数据包中应该只有一个EAP消息属性，包含EAP Success或EAP Failure。
It is expected that EAP will be used to implement a variety of authentication methods, including methods involving strong cryptography. In order to prevent attackers from subverting EAP by attacking RADIUS/EAP, (for example, by modifying the EAP-Success or EAP-Failure packets) it is necessary that RADIUS/EAP provide integrity protection at least as strong as those used in the EAP methods themselves.
预计EAP将用于实现各种身份验证方法，包括涉及强加密的方法。为了防止攻击者通过攻击RADIUS/EAP（例如，通过修改EAP成功或EAP失败数据包）破坏EAP，RADIUS/EAP必须提供至少与EAP方法本身中使用的完整性保护一样强的完整性保护。
Therefore the Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute.
因此，必须使用消息验证器属性来保护所有包含EAP消息属性的访问请求、访问质询、访问接受和访问拒绝数据包。
Access-Request packets including an EAP-Message attribute without a Message-Authenticator attribute SHOULD be silently discarded by the RADIUS server. A RADIUS Server supporting EAP-Message MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. A RADIUS Server not supporting EAP-Message MUST return an Access-Reject if it receives an Access-Request containing an EAP-Message attribute. A RADIUS Server receiving an EAP-Message attribute that it does not understand MUST return an Access-Reject.
RADIUS服务器应以静默方式丢弃包含EAP消息属性但不包含消息验证器属性的访问请求数据包。支持EAP消息的RADIUS服务器必须计算消息验证器的正确值，如果数据包与发送的值不匹配，则自动丢弃该数据包。不支持EAP消息的RADIUS服务器如果接收到包含EAP消息属性的访问请求，则必须返回访问拒绝。RADIUS服务器接收到其不理解的EAP消息属性时，必须返回访问拒绝。
Access-Challenge, Access-Accept, or Access-Reject packets including an EAP-Message attribute without a Message-Authenticator attribute SHOULD be silently discarded by the NAS. A NAS supporting EAP-Message MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.
NAS应以静默方式丢弃包含EAP消息属性但不包含消息验证器属性的访问质询、访问接受或访问拒绝数据包。支持NAS的EAP消息必须计算消息验证器的正确值，如果数据包与发送的值不匹配，则自动丢弃该数据包。
A summary of the EAP-Message attribute format is shown below. The fields are transmitted from left to right.
EAP消息属性格式的摘要如下所示。字段从左向右传输。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
79 for EAP-Message.
79用于EAP消息。
Length
长
>= 3
>= 3
String
一串
The String field contains EAP packets, as defined in [3]. If multiple EAP-Message attributes are present in a packet their values should be concatenated; this allows EAP packets longer than 253 octets to be passed by RADIUS.
字符串字段包含EAP数据包，如[3]中所定义。如果数据包中存在多个EAP消息属性，则应将其值串联起来；这允许长度超过253个八位字节的EAP数据包通过RADIUS传递。
Description
描述
This attribute MAY be used to sign Access-Requests to prevent spoofing Access-Requests using CHAP, ARAP or EAP authentication methods. It MAY be used in any Access-Request. It MUST be used in any Access-Request, Access-Accept, Access-Reject or Access-Challenge that includes an EAP-Message attribute.
此属性可用于对访问请求进行签名，以防止使用CHAP、ARAP或EAP身份验证方法欺骗访问请求。它可以用于任何访问请求。它必须用于包含EAP消息属性的任何访问请求、访问接受、访问拒绝或访问质询。
A RADIUS Server receiving an Access-Request with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.
接收到具有消息验证器属性的访问请求的RADIUS服务器必须计算消息验证器的正确值，如果数据包与发送的值不匹配，则会自动丢弃该数据包。
A RADIUS Client receiving an Access-Accept, Access-Reject or Access-Challenge with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.
接收到访问接受、访问拒绝或访问质询且存在消息验证器属性的RADIUS客户端必须计算消息验证器的正确值，如果数据包与发送的值不匹配，则自动丢弃数据包。
Earlier drafts of this memo used "Signature" as the name of this attribute, but Message-Authenticator is more precise. Its operation has not changed, just the name.
此备忘录的早期草稿使用“签名”作为此属性的名称，但消息验证器更精确。它的操作没有改变，只是名称而已。
A summary of the Message-Authenticator attribute format is shown below. The fields are transmitted from left to right.
消息验证器属性格式的摘要如下所示。字段从左向右传输。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
80 for Message-Authenticator
80用于消息验证器
Length
长
18
18
String
一串
When present in an Access-Request packet, Message-Authenticator is an HMAC-MD5 [9] checksum of the entire Access-Request packet, including Type, ID, Length and authenticator, using the shared secret as the key, as follows.
当存在于访问请求数据包中时，消息验证器是整个访问请求数据包的HMAC-MD5[9]校验和，包括类型、ID、长度和验证器，使用共享密钥作为密钥，如下所示。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
消息验证器=HMAC-MD5（类型、标识符、长度、请求验证器、属性）
When the checksum is calculated the signature string should be considered to be sixteen octets of zero.
当计算校验和时，签名字符串应被视为十六个八位组的零。
For Access-Challenge, Access-Accept, and Access-Reject packets, the Message-Authenticator is calculated as follows, using the Request-Authenticator from the Access-Request this packet is in reply to:
对于访问质询、访问接受和访问拒绝数据包，使用该数据包响应的访问请求中的请求验证器，按如下方式计算消息验证器：
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
消息验证器=HMAC-MD5（类型、标识符、长度、请求验证器、属性）
When the checksum is calculated the signature string should be considered to be sixteen octets of zero. The shared secret is used as the key for the HMAC-MD5 hash. The is calculated and inserted in the packet before the Response Authenticator is calculated.
当计算校验和时，签名字符串应被视为十六个八位组的零。共享密钥用作HMAC-MD5哈希的密钥。在计算响应验证器之前，计算并插入数据包。
This attribute is not needed if the User-Password attribute is present, but is useful for preventing attacks on other types of authentication. This attribute is intended to thwart attempts by an attacker to setup a "rogue" NAS, and perform online dictionary attacks against the RADIUS server. It does not afford protection against "offline" attacks where the attacker intercepts packets containing (for example) CHAP challenge and response, and performs a dictionary attack against those packets offline.
如果存在用户密码属性，则不需要此属性，但可用于防止对其他类型身份验证的攻击。此属性旨在阻止攻击者试图设置“恶意”NAS，并对RADIUS服务器执行在线字典攻击。它无法提供针对“脱机”攻击的保护，攻击者会拦截包含（例如）CHAP质询和响应的数据包，并对这些数据包脱机执行字典攻击。
IP Security will eventually make this attribute unnecessary, so it should be considered an interim measure.
IP安全最终会使此属性变得不必要，因此应将其视为临时措施。
Description
描述
This attribute is sent in an Access-Accept packet with Framed-Protocol of ARAP, and contains the response to the dial-in client's challenge.
此属性以ARAP的框架协议在Access Accept数据包中发送，并包含对拨入客户端质询的响应。
A summary of the ARAP-Challenge-Response attribute format is shown below. The fields are transmitted from left to right.
ARAP质询响应属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
84 for ARAP-Challenge-Response.
84用于ARAP挑战响应。
Length
长
10
10
Value
价值
The Value field contains an 8 octet response to the dial-in client's challenge. The RADIUS server calculates this value by taking the dial-in client's challenge from the high order 8 octets of the ARAP-Password attribute and performing DES encryption on this value with the authenticating user's password as the key. If the user's password is less than 8 octets in length, the password is padded at the end with NULL octets to a length of 8 before using it as a key.
值字段包含对拨入客户端质询的8个八位字节响应。RADIUS服务器通过从ARAP Password属性的高阶8个八位字节获取拨入客户端的质询，并使用身份验证用户的密码作为密钥对该值执行DES加密来计算该值。如果用户的密码长度小于8个八位字节，则在将其用作密钥之前，将在密码末尾用空八位字节填充到8个八位字节。
Description
描述
This attribute indicates the number of seconds between each interim update in seconds for this specific session. This value can only appear in the Access-Accept message.
此属性表示此特定会话每次临时更新之间的秒数（以秒为单位）。此值只能出现在Access Accept消息中。
A summary of the Acct-Interim-Interval attribute format is shown below. The fields are transmitted from left to right.
Acct中间间隔属性格式的摘要如下所示。字段从左向右传输。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
85 for Acct-Interim-Interval.
会计中期间隔为85。
Length
长
6
6.
Value
价值
The Value field contains the number of seconds between each interim update to be sent from the NAS for this session. The value MUST NOT be smaller than 60. The value SHOULD NOT be smaller than 600, and careful consideration should be given to its impact on network traffic.
值字段包含从NAS为此会话发送的每个临时更新之间的秒数。该值不得小于60。该值不应小于600，并应仔细考虑其对网络流量的影响。
Description
描述
This Attribute contains a text string which identifies the port of the NAS which is authenticating the user. It is only used in Access-Request and Accounting-Request packets. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number.
此属性包含一个文本字符串，用于标识正在验证用户的NAS端口。它仅用于访问请求和记帐请求数据包。请注意，这是使用NAS上物理连接意义上的“端口”，而不是TCP或UDP端口号意义上的端口。
Either NAS-Port or NAS-Port-Id SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports. NAS-Port-Id is intended for use by NASes which cannot conveniently number their ports.
如果NAS不同于其端口，则NAS端口或NAS端口Id应出现在访问请求数据包中。NAS端口Id供无法方便地对其端口编号的NASE使用。
A summary of the NAS-Port-Id Attribute format is shown below. The fields are transmitted from left to right.
NAS端口Id属性格式的摘要如下所示。字段从左向右传输。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
87 for NAS-Port-Id.
87用于NAS-Port-Id。
Length
长
>= 3
>= 3
Text
文本
The Text field contains the name of the port using UTF-8 encoded 10646 [8] characters.
文本字段包含使用UTF-8编码的10646[8]字符的端口名称。
Description
描述
This Attribute contains the name of an assigned address pool that SHOULD be used to assign an address for the user. If a NAS does not support multiple address pools, the NAS should ignore this Attribute. Address pools are usually used for IP addresses, but can be used for other protocols if the NAS supports pools for those protocols.
此属性包含应用于为用户分配地址的已分配地址池的名称。如果NAS不支持多个地址池，则NAS应忽略此属性。地址池通常用于IP地址，但如果NAS支持用于其他协议的池，则可以用于这些协议。
A summary of the Framed-Pool Attribute format is shown below. The fields are transmitted from left to right.
框架池属性格式的摘要如下所示。字段从左向右传输。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
88 for Framed-Pool
88用于框架式游泳池
Length
长
>= 3
>= 3
String
一串
The string field contains the name of an assigned address pool configured on the NAS.
字符串字段包含NAS上配置的已分配地址池的名称。
The following table provides a guide to which attributes may be found in which kind of packets. Acct-Input-Gigawords, Acct-Output-Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in an Accounting-Request packet. Connect-Info may have 0+ instances in an Accounting-Request packet. The other attributes added in this document must not be present in an Accounting-Request.
下表提供了在哪种数据包中可以找到哪些属性的指南。Acct Input Gigawords、Acct Output Gigawords、事件时间戳和NAS端口Id在记帐请求数据包中可能有0-1个实例。连接信息在记帐请求数据包中可能有0多个实例。此文档中添加的其他属性不得出现在记帐请求中。
Request Accept Reject Challenge # Attribute
0-1 0 0 0 70 ARAP-Password [Note 1]
0 0-1 0 0-1 71 ARAP-Features
0 0-1 0 0 72 ARAP-Zone-Access
0-1 0 0 0-1 73 ARAP-Security
0+ 0 0 0+ 74 ARAP-Security-Data
0 0 0-1 0 75 Password-Retry
0 0 0 0-1 76 Prompt
0-1 0 0 0 77 Connect-Info
0 0+ 0 0 78 Configuration-Token
0+ 0+ 0+ 0+ 79 EAP-Message [Note 1]
0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1]
0 0-1 0 0-1 84 ARAP-Challenge-Response
0 0-1 0 0 85 Acct-Interim-Interval
0-1 0 0 0 87 NAS-Port-Id
0 0-1 0 0 88 Framed-Pool
Request Accept Reject Challenge # Attribute
Request Accept Reject Challenge # Attribute
0-1 0 0 0 70 ARAP-Password [Note 1]
0 0-1 0 0-1 71 ARAP-Features
0 0-1 0 0 72 ARAP-Zone-Access
0-1 0 0 0-1 73 ARAP-Security
0+ 0 0 0+ 74 ARAP-Security-Data
0 0 0-1 0 75 Password-Retry
0 0 0 0-1 76 Prompt
0-1 0 0 0 77 Connect-Info
0 0+ 0 0 78 Configuration-Token
0+ 0+ 0+ 0+ 79 EAP-Message [Note 1]
0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1]
0 0-1 0 0-1 84 ARAP-Challenge-Response
0 0-1 0 0 85 Acct-Interim-Interval
0-1 0 0 0 87 NAS-Port-Id
0 0-1 0 0 88 Framed-Pool
Request Accept Reject Challenge # Attribute
[Note 1] An Access-Request that contains either a User-Password or CHAP-Password or ARAP-Password or one or more EAP-Message attributes MUST NOT contain more than one type of those four attributes. If it does not contain any of those four attributes, it SHOULD contain a Message-Authenticator. If any packet type contains an EAP-Message attribute it MUST also contain a Message-Authenticator.
[注意1]包含用户密码、CHAP密码、ARAP密码或一个或多个EAP消息属性的访问请求不得包含这四个属性中的一种以上类型。如果它不包含这四个属性中的任何一个，那么它应该包含一个消息验证器。如果任何数据包类型包含EAP消息属性，则它还必须包含消息验证器。
The following table defines the above table entries.
下表定义了上述表格条目。
0 This attribute MUST NOT be present 0+ Zero or more instances of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present. 1 Exactly one instance of this attribute MUST be present.
0此属性不能存在0+此属性可能存在零个或多个实例。0-1此属性可能存在零个或一个实例。1此属性必须仅存在一个实例。
The Packet Type Codes, Attribute Types, and Attribute Values defined in this document are registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS name spaces as described in the "IANA Considerations" section of [1], in accordance with BCP 26 [10].
根据BCP 26[10]，本文件中定义的数据包类型代码、属性类型和属性值由互联网分配号码管理局（IANA）从[1]的“IANA注意事项”部分所述的RADIUS名称空间进行注册。
The attributes other than Message-Authenticator and EAP-Message in this document have no additional security considerations beyond those already identified in [1].
除[1]中已确定的属性外，本文档中除消息验证器和EAP消息以外的其他属性没有其他安全注意事项。
Access-Request packets with a User-Password establish the identity of both the user and the NAS sending the Access-Request, because of the way the shared secret between NAS and RADIUS server is used. Access-Request packets with CHAP-Password or EAP-Message do not have a User-Password attribute, so the Message-Authenticator attribute should be used in access-request packets that do not have a User-Password, in order to establish the identity of the NAS sending the request.
带有用户密码的访问请求数据包建立了发送访问请求的用户和NAS的身份，这是因为NAS和RADIUS服务器之间使用了共享机密的方式。具有CHAP密码或EAP消息的访问请求数据包没有用户密码属性，因此在没有用户密码的访问请求数据包中应使用消息验证器属性，以便建立发送请求的NAS的标识。
Since the purpose of EAP is to provide enhanced security for PPP authentication, it is critical that RADIUS support for EAP be secure. In particular, the following issues must be addressed:
由于EAP的目的是为PPP身份验证提供增强的安全性，因此对EAP的RADIUS支持必须是安全的。特别是，必须解决以下问题：
Separation of EAP server and PPP authenticator Connection hijacking Man in the middle attacks Multiple databases
分离EAP服务器和PPP认证器连接劫持中间人攻击多个数据库
Negotiation attacks
谈判攻击
It is possible for the EAP endpoints to mutually authenticate, negotiate a ciphersuite, and derive a session key for subsequent use in PPP encryption.
EAP端点可以相互验证、协商密码套件并派生会话密钥，以供后续在PPP加密中使用。
This does not present an issue on the peer, since the peer and EAP client reside on the same machine; all that is required is for the EAP client module to pass the session key to the PPP encryption module.
这不会在对等机上出现问题，因为对等机和EAP客户端位于同一台机器上；EAP客户端模块只需将会话密钥传递给PPP加密模块。
The situation is more complex when EAP is used with RADIUS, since the PPP authenticator will typically not reside on the same machine as the EAP server. For example, the EAP server may be a backend security server, or a module residing on the RADIUS server.
当EAP与RADIUS一起使用时，情况更加复杂，因为PPP验证器通常不会与EAP服务器驻留在同一台机器上。例如，EAP服务器可以是后端安全服务器，或者是驻留在RADIUS服务器上的模块。
In the case where the EAP server and PPP authenticator reside on different machines, there are several implications for security. Firstly, mutual authentication will occur between the peer and the EAP server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to.
在EAP服务器和PPP验证器驻留在不同机器上的情况下，存在几个安全问题。首先，相互认证将在对等方和EAP服务器之间发生，而不是在对等方和验证器之间发生。这意味着对等方不可能验证与之对话的NAS或隧道服务器的身份。
As described earlier, when EAP/RADIUS is used to encapsulate EAP packets, the Message-Authenticator attribute is required in EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the RADIUS server. Since the Message-Authenticator attribute involves a HMAC-MD5 hash, it is possible for the RADIUS server to verify the integrity of the Access-Request as well as the NAS or tunnel server's identity. Similarly, Access-Challenge packets sent from the RADIUS server to the NAS are also authenticated and integrity protected using an HMAC-MD5 hash, enabling the NAS or tunnel server to determine the integrity of the packet and verify the identity of the RADIUS server. Moreover, EAP packets sent via methods that contain their own integrity protection cannot be successfully modified by a rogue NAS or tunnel server.
如前所述，当EAP/RADIUS用于封装EAP数据包时，从NAS或隧道服务器发送到RADIUS服务器的EAP/RADIUS访问请求中需要消息验证器属性。由于消息验证器属性涉及HMAC-MD5哈希，RADIUS服务器可以验证访问请求的完整性以及NAS或隧道服务器的身份。类似地，从RADIUS服务器发送到NAS的访问质询数据包也使用HMAC-MD5哈希进行身份验证和完整性保护，从而使NAS或隧道服务器能够确定数据包的完整性并验证RADIUS服务器的身份。此外，恶意NAS或隧道服务器无法成功修改通过包含自身完整性保护的方法发送的EAP数据包。
The second issue that arises in the case of an EAP server and PPP authenticator residing on different machines is that the session key negotiated between the peer and EAP server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the session key from the EAP server to the authenticator or tunnel server that needs to use the key. The specification of this transit mechanism is outside the scope of this document.
在EAP服务器和PPP验证器驻留在不同机器上的情况下出现的第二个问题是，对等服务器和EAP服务器之间协商的会话密钥将需要传输到验证器。因此，需要提供一种机制，将会话密钥从EAP服务器传输到需要使用密钥的验证器或隧道服务器。本传输机制的规范不在本文件范围内。
In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the RADIUS server, or between the RADIUS server and the backend security server. RADIUS does not support encryption, and as described in [1], only Access-Reply and Access-Challenge packets are integrity protected. Moreover, the integrity protection mechanism described in [1] is weaker than that likely to be used by some EAP methods, making it possible to subvert those methods by attacking EAP/RADIUS.
在这种形式的攻击中，攻击者试图将数据包注入NAS与RADIUS服务器之间或RADIUS服务器与后端安全服务器之间的会话。RADIUS不支持加密，如[1]所述，只有访问应答和访问质询数据包受完整性保护。此外，[1]中描述的完整性保护机制比某些EAP方法可能使用的机制弱，因此有可能通过攻击EAP/RADIUS来破坏这些方法。
In order to provide for authentication of all packets in the EAP exchange, all EAP/RADIUS packets MUST be authenticated using the Message-Authenticator attribute, as described previously.
为了提供EAP交换中所有数据包的身份验证，必须使用消息验证器属性对所有EAP/RADIUS数据包进行身份验证，如前所述。
Since RADIUS security is based on shared secrets, end-to-end security is not provided in the case where authentication or accounting packets are forwarded along a proxy chain. As a result, attackers gaining control of a RADIUS proxy will be able to modify EAP packets in transit.
由于RADIUS安全性基于共享机密，因此在认证或记帐数据包沿代理链转发的情况下，不提供端到端安全性。因此，获得RADIUS代理控制权的攻击者将能够修改传输中的EAP数据包。
In many cases a backend security server will be deployed along with a RADIUS server in order to provide EAP services. Unless the backend security server also functions as a RADIUS server, two separate user databases will exist, each containing information about the security requirements for the user. This represents a weakness, since security may be compromised by a successful attack on either of the servers, or their backend databases. With multiple user databases, adding a new user may require multiple operations, increasing the chances for error. The problems are further magnified in the case where user information is also being kept in an LDAP server. In this case, three stores of user information may exist.
在许多情况下，后端安全服务器将与RADIUS服务器一起部署，以提供EAP服务。除非后端安全服务器也可以用作RADIUS服务器，否则将存在两个独立的用户数据库，每个数据库都包含有关用户安全要求的信息。这是一个弱点，因为成功攻击任一服务器或其后端数据库可能会危及安全性。对于多用户数据库，添加新用户可能需要多次操作，从而增加出错的机会。如果用户信息也保存在LDAP服务器中，则问题会进一步扩大。在这种情况下，可能存在三个用户信息存储。
In order to address these threats, consolidation of databases is recommended. This can be achieved by having both the RADIUS server and backend security server store information in the same backend database; by having the backend security server provide a full RADIUS implementation; or by consolidating both the backend security server and the RADIUS server onto the same machine.
为了应对这些威胁，建议整合数据库。这可以通过让RADIUS服务器和后端安全服务器在同一后端数据库中存储信息来实现；通过让后端安全服务器提供完整的RADIUS实现；或者将后端安全服务器和RADIUS服务器整合到同一台计算机上。
In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or RADIUS server causes the authenticating peer to choose a less secure authentication method so as to make it easier to obtain the user's password. For example, a session that would normally be authenticated with EAP would instead authenticated via CHAP or PAP; alternatively, a connection that would normally be authenticated via one EAP type occurs via a less secure EAP type, such as MD5. The threat posed by rogue devices, once thought to be remote, has gained currency given compromises of telephone company switching systems, such as those described in [11].
在协商攻击中，恶意NAS、隧道服务器、RADIUS代理或RADIUS服务器会导致身份验证对等方选择不太安全的身份验证方法，以便更容易获取用户密码。例如，通常使用EAP进行身份验证的会话将改为通过CHAP或PAP进行身份验证；或者，通常通过一种EAP类型进行身份验证的连接通过不太安全的EAP类型（如MD5）发生。曾经被认为是远程的流氓设备所造成的威胁，由于电话公司交换系统（如[11]中所述）的妥协而变得普遍。
Protection against negotiation attacks requires the elimination of downward negotiations. This can be achieved via implementation of per-connection policy on the part of the authenticating peer, and per-user policy on the part of the RADIUS server.
防止谈判攻击需要消除向下谈判。这可以通过在身份验证对等方上实施每个连接策略和在RADIUS服务器上实施每个用户策略来实现。
For the authenticating peer, authentication policy should be set on a per-connection basis. Per-connection policy allows an authenticating peer to negotiate EAP when calling one service, while negotiating CHAP for another service, even if both services are accessible via the same phone number.
对于身份验证对等方，应基于每个连接设置身份验证策略。每连接策略允许身份验证对等方在呼叫一个服务时协商EAP，同时协商另一个服务的CHAP，即使两个服务可以通过相同的电话号码访问。
With per-connection policy, an authenticating peer will only attempt to negotiate EAP for a session in which EAP support is expected. As a result, there is a presumption that an authenticating peer selecting EAP requires that level of security. If it cannot be provided, it is likely that there is some kind of misconfiguration, or even that the authenticating peer is contacting the wrong server. Should the NAS not be able to negotiate EAP, or should the EAP-Request sent by the NAS be of a different EAP type than what is expected, the authenticating peer MUST disconnect. An authenticating peer expecting EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP.
对于每连接策略，身份验证对等方将仅尝试为预期EAP支持的会话协商EAP。因此，假设选择EAP的认证对等方需要该安全级别。如果无法提供，则可能存在某种配置错误，甚至验证对等方正在联系错误的服务器。如果NAS无法协商EAP，或者如果NAS发送的EAP请求与预期的EAP类型不同，则验证对等方必须断开连接。期望为会话协商EAP的身份验证对等方不得协商CHAP或PAP。
For a NAS, it may not be possible to determine whether a user is required to authenticate with EAP until the user's identity is known. For example, for shared-uses NASes it is possible for one reseller to implement EAP while another does not. In such cases, if any users of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every call. This avoids forcing an EAP-capable client to do more than one authentication, which weakens security.
对于NAS，在知道用户身份之前，可能无法确定是否需要用户使用EAP进行身份验证。例如，对于共享使用NASE，一个分销商可以实施EAP，而另一个分销商则不实施EAP。在这种情况下，如果NAS的任何用户必须执行EAP，则NAS必须尝试为每个呼叫协商EAP。这避免了强制支持EAP的客户端执行多个身份验证，从而削弱了安全性。
If CHAP is negotiated, the NAS will pass the User-Name and CHAP-Password attributes to the RADIUS Server in an Access-Request packet. If the user is not required to use EAP, then the RADIUS Server will respond with an Access-Accept or Access-Reject packet as appropriate. However, if CHAP has been negotiated but EAP is required, the RADIUS
如果协商CHAP，NAS将在访问请求数据包中将用户名和CHAP密码属性传递给RADIUS服务器。如果用户不需要使用EAP，则RADIUS服务器将根据需要使用访问接受或访问拒绝数据包进行响应。但是，如果已协商CHAP，但需要EAP，则半径
server MUST respond with an Access-Reject, rather than an Access-Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST refuse to renegotiate authentication, even if the renegotiation is from CHAP to EAP.
服务器必须以访问拒绝响应，而不是访问质询/EAP消息/EAP请求数据包。身份验证对等方必须拒绝重新协商身份验证，即使重新协商是从CHAP到EAP。
If EAP is negotiated but is not supported by the RADIUS proxy or server, then the server or proxy MUST respond with an Access-Reject. In these cases, the NAS MUST send an LCP-Terminate and disconnect the user. This is the correct behavior since the authenticating peer is expecting EAP to be negotiated, and that expectation cannot be fulfilled. An EAP-capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP had initially been negotiated. Note that problems with a non-EAP capable RADIUS proxy could prove difficult to diagnose, since a user dialing in from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same user dialing into another location (and encountering an EAP-incapable proxy) might be consistently disconnected.
如果EAP已协商，但RADIUS代理或服务器不支持，则服务器或代理必须以访问拒绝响应。在这些情况下，NAS必须发送LCP终止并断开用户连接。这是正确的行为，因为身份验证对等方期望协商EAP，而该期望无法实现。如果最初协商了EAP，则具有EAP能力的认证对等方必须拒绝重新协商认证协议。请注意，不支持EAP的RADIUS代理的问题可能很难诊断，因为从一个位置拨入的用户（使用支持EAP的代理）可能能够通过EAP成功进行身份验证，而同一用户拨入另一个位置（遇到不支持EAP的代理）可能会持续断开连接。
[1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[1] Rigney，C.，Willens，S.，Rubens，A.和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[2] 里格尼，C.，“半径会计”，RFC 28662000年6月。
[3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[3] Blunk，L.和J.Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[5] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[6] Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.和I.Goyret，“隧道协议支持的半径属性”，RFC 28682000年6月。
[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[7] Zorn，G.，Aboba，B.和D.Mitton，“隧道协议支持的半径计算修改”，RFC 2867，2000年6月。
[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[8] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[9] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1997年2月。
[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Alvestrand，H.和T.Narten，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[11] Slatalla, M., and Quittner, J., "Masters of Deception." HarperCollins, New York, 1995.
[11] 《欺骗大师》，纽约哈珀柯林斯，1995年。
RADIUS and RADIUS Accounting were originally developed by Livingston Enterprises (now part of Lucent Technologies) for their PortMaster series of Network Access Servers.
RADIUS和RADIUS Accounting最初是由Livingston Enterprise（现在是朗讯科技的一部分）为其PortMaster系列网络访问服务器开发的。
The section on ARAP is adopted with permission from "Using RADIUS to Authenticate Apple Remote Access Connections" by Ward Willats of Cyno Technologies (ward@cyno.com).
关于ARAP的部分是在Cyno Technologies的Ward Willats“使用RADIUS验证苹果远程访问连接”的许可下通过的(ward@cyno.com).
The section on Acct-Interim-Interval is adopted with permission from an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies.
关于Acct中间间隔的部分是在获得Sun Microsystems的Pat Calhoun、Compuserve的Mark Beadles和UUnit Technologies的Alex Ratcliffe的早期工作许可后采用的。
The section on EAP is adopted with permission from an earlier work in progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit Network, and Bernard Aboba of Microsoft. Thanks also to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of Microsoft for useful discussions of this problem space.
有关EAP的部分是在获得Sun Microsystems的帕特·卡尔霍恩（Pat Calhoun）、Merit Network的艾伦·鲁本斯（Allan Rubens）和微软的伯纳德·阿博巴（Bernard Aboba）的早期工作许可后采用的。还要感谢Ascend的Dave Dawson和Karl Fox，以及微软的Glen Zorn和Narendra Gidwani，他们对这个问题空间进行了有益的讨论。
The RADIUS working group can be contacted via the current chair:
可通过现任主席联系RADIUS工作组：
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
加利福尼亚州普莱森顿市柳树路4464号卡尔·里格尼·利文斯顿企业，邮编94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com
Phone: +1 925 737 2100
EMail: cdr@telemancy.com
Questions about this memo can also be directed to:
有关本备忘录的问题，请联系：
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
加利福尼亚州普莱森顿市柳树路4464号卡尔·里格尼·利文斯顿企业，邮编94588
EMail: cdr@telemancy.com
EMail: cdr@telemancy.com
Questions on ARAP and RADIUS may be directed to:
有关ARAP和RADIUS的问题，请联系：
Ward Willats Cyno Technologies 1082 Glen Echo Ave San Jose, CA 95125
加利福尼亚州圣何塞市格伦埃科大街1082号沃德威拉斯赛诺科技公司，邮编95125
Phone: +1 408 297 7766
EMail: ward@cyno.com
Phone: +1 408 297 7766
EMail: ward@cyno.com
Questions on EAP and RADIUS may be directed to any of the following:
有关EAP和RADIUS的问题可向以下任何一方提出：
Pat R. Calhoun Network and Security Research Center Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025
Pat R.Calhoun网络与安全研究中心Sun Microsystems，Inc.位于加利福尼亚州门罗公园网络圈15号，邮编94025
Phone: +1 650 786 7733
EMail: pcalhoun@eng.sun.com
Phone: +1 650 786 7733
EMail: pcalhoun@eng.sun.com
Allan C. Rubens Tut Systems, Inc. 220 E. Huron, Suite 260 Ann Arbor, MI 48104
艾伦·C·鲁本斯图坦卡蒙系统有限公司，密歇根州安娜堡220 E·休伦260室，邮编：48104
Phone: +1 734 995 1697
EMail: arubens@tutsys.com
Phone: +1 734 995 1697
EMail: arubens@tutsys.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。