Network Working Group B. Aboba
Request for Comments: 3579 Microsoft
Updates: 2869 P. Calhoun
Category: Informational Airespace
September 2003
Network Working Group B. Aboba
Request for Comments: 3579 Microsoft
Updates: 2869 P. Calhoun
Category: Informational Airespace
September 2003
RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)
RADIUS（远程身份验证拨入用户服务）支持可扩展身份验证协议（EAP）
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method-specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802.
本文档定义了可扩展身份验证协议（EAP）的远程身份验证拨入用户服务（RADIUS）支持，EAP是一个支持多种身份验证机制的身份验证框架。在所提出的方案中，网络接入服务器（NAS）将EAP数据包转发到RADIUS服务器，并将其封装在EAP消息属性中。这样做的优点是允许NAS支持任何EAP身份验证方法，而不需要驻留在RADIUS服务器上的方法特定代码。虽然EAP最初是为与PPP一起使用而开发的，但现在也与IEEE 802一起使用。
This document updates RFC 2869.
本文件更新了RFC 2869。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. RADIUS Support for EAP . . . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Overview. . . . . . . . . . . . . . . . . . . . 5
2.2. Invalid Packets. . . . . . . . . . . . . . . . . . . . . 9
2.3. Retransmission . . . . . . . . . . . . . . . . . . . . . 10
2.4. Fragmentation. . . . . . . . . . . . . . . . . . . . . . 10
2.5. Alternative uses . . . . . . . . . . . . . . . . . . . . 11
2.6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . 11
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Message-Authenticator. . . . . . . . . . . . . . . . . . 16
3.3. Table of Attributes. . . . . . . . . . . . . . . . . . . 18
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
4.1. Security Requirements. . . . . . . . . . . . . . . . . . 19
4.2. Security Protocol. . . . . . . . . . . . . . . . . . . . 20
4.3. Security Issues. . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 30
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1. Normative References . . . . . . . . . . . . . . . . . . 30
6.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A - Examples. . . . . . . . . . . . . . . . . . . . . . . 34
Appendix B - Change Log. . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property Statement. . . . . . . . . . . . . . . . . . 44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. RADIUS Support for EAP . . . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Overview. . . . . . . . . . . . . . . . . . . . 5
2.2. Invalid Packets. . . . . . . . . . . . . . . . . . . . . 9
2.3. Retransmission . . . . . . . . . . . . . . . . . . . . . 10
2.4. Fragmentation. . . . . . . . . . . . . . . . . . . . . . 10
2.5. Alternative uses . . . . . . . . . . . . . . . . . . . . 11
2.6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . 11
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Message-Authenticator. . . . . . . . . . . . . . . . . . 16
3.3. Table of Attributes. . . . . . . . . . . . . . . . . . . 18
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
4.1. Security Requirements. . . . . . . . . . . . . . . . . . 19
4.2. Security Protocol. . . . . . . . . . . . . . . . . . . . 20
4.3. Security Issues. . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 30
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1. Normative References . . . . . . . . . . . . . . . . . . 30
6.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A - Examples. . . . . . . . . . . . . . . . . . . . . . . 34
Appendix B - Change Log. . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property Statement. . . . . . . . . . . . . . . . . . 44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 46
The Remote Authentication Dial In User Service (RADIUS) is an authentication, authorization and accounting protocol used to control network access. RADIUS authentication and authorization is specified in [RFC2865], and RADIUS accounting is specified in [RFC2866]; RADIUS over IPv6 is specified in [RFC3162].
远程身份验证拨入用户服务（RADIUS）是用于控制网络访问的身份验证、授权和记帐协议。[RFC2865]中规定了RADIUS认证和授权，[RFC2866]中规定了RADIUS记帐；[RFC3162]中指定了IPv6上的RADIUS。
The Extensible Authentication Protocol (EAP), defined in [RFC2284], is an authentication framework which supports multiple authentication mechanisms. EAP may be used on dedicated links, switched circuits, and wired as well as wireless links.
[RFC2284]中定义的可扩展身份验证协议（EAP）是一个支持多种身份验证机制的身份验证框架。EAP可用于专用链路、交换电路以及有线和无线链路。
To date, EAP has been implemented with hosts and routers that connect via switched circuits or dial-up lines using PPP [RFC1661]. It has also been implemented with bridges supporting [IEEE802]. EAP encapsulation on IEEE 802 wired media is described in [IEEE8021X].
迄今为止，EAP已经通过使用PPP[RFC1661]通过交换电路或拨号线连接的主机和路由器实现。它还通过支持[IEEE802]的网桥实现。[IEEE8021X]中描述了IEEE 802有线媒体上的EAP封装。
RADIUS attributes are comprised of variable length Type-Length-Value 3-tuples. New attribute values can be added without disturbing existing implementations of the protocol. This specification describes RADIUS attributes supporting the Extensible Authentication Protocol (EAP): EAP-Message and Message-Authenticator. These attributes now have extensive field experience. The purpose of this document is to provide clarification and resolve interoperability issues.
半径属性由可变长度类型长度值3元组组成。可以添加新的属性值，而不会干扰协议的现有实现。本规范描述了支持可扩展身份验证协议（EAP）的RADIUS属性：EAP消息和消息验证器。这些属性现在具有广泛的现场经验。本文件旨在澄清和解决互操作性问题。
As noted in [RFC2865], a Network Access Server (NAS) that does not implement a given service MUST NOT implement the RADIUS attributes for that service. This implies that a NAS that is unable to offer EAP service MUST NOT implement the RADIUS attributes for EAP. A NAS MUST treat a RADIUS Access-Accept requesting an unavailable service as an Access-Reject instead.
如[RFC2865]中所述，未实现给定服务的网络访问服务器（NAS）不得实现该服务的RADIUS属性。这意味着无法提供EAP服务的NAS不得实现EAP的RADIUS属性。NAS必须将请求不可用服务的RADIUS访问接受视为访问拒绝。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document frequently uses the following terms:
本文件经常使用以下术语：
authenticator The end of the link requiring the authentication. Also known as the Network Access Server (NAS) or RADIUS client. Within IEEE 802.1X terminology, the term Authenticator is used.
authenticator需要身份验证的链接的末尾。也称为网络访问服务器（NAS）或RADIUS客户端。在IEEE 802.1X术语中，使用了术语验证器。
peer The other end of the point-to-point link (PPP), point-to-point LAN segment (IEEE 802.1X) or wireless link, which is being authenticated by the authenticator. In IEEE 802.1X, this end is known as the Supplicant.
对等点对点链路（PPP）、点对点LAN段（IEEE 802.1X）或无线链路的另一端，该链路正在由验证器进行身份验证。在IEEE 802.1X中，此端称为请求者。
authentication server An authentication server is an entity that provides an authentication service to an authenticator (NAS). This service verifies from the credentials provided by the peer, the claim of identity made by the peer; it also may provide credentials allowing the peer to verify the identity of the authentication server. Within this document it is assumed that the NAS operates as a pass-through, forwarding EAP packets between the RADIUS server and the EAP peer.
身份验证服务器身份验证服务器是向身份验证程序（NAS）提供身份验证服务的实体。此服务根据对等方提供的凭据验证对等方提出的身份声明；它还可以提供凭证，允许对等方验证认证服务器的身份。在本文档中，假设NAS作为直通操作，在RADIUS服务器和EAP对等方之间转发EAP数据包。
Therefore the RADIUS server operates as an authentication server.
因此，RADIUS服务器作为身份验证服务器运行。
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.
静默丢弃这意味着实现在不进行进一步处理的情况下丢弃数据包。实现应该提供记录错误的能力，包括静默丢弃的数据包的内容，并且应该在统计计数器中记录事件。
displayable message This is interpreted to be a human readable string of characters, and MUST NOT affect operation of the protocol. The message encoding MUST follow the UTF-8 transformation format [RFC2279].
可显示消息这被解释为人类可读的字符串，并且不得影响协议的操作。消息编码必须遵循UTF-8转换格式[RFC2279]。
Network Access Server (NAS) The device providing access to the network. Also known as the Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client.
网络访问服务器（NAS）提供网络访问的设备。也称为验证器（IEEE 802.1X或EAP术语）或RADIUS客户端。
service The NAS provides a service to the user, such as IEEE 802 or PPP.
服务NAS向用户提供服务，如IEEE 802或PPP。
session Each service provided by the NAS to a peer 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 is ended. A peer 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向对等方提供的每个服务都构成一个会话，会话的开始定义为首次提供服务的点，会话的结束定义为服务的结束点。如果NAS支持，对等机可以并行或串联多个会话，每个会话生成单独的开始和停止记帐记录。
The Extensible Authentication Protocol (EAP), described in [RFC2284], provides a standard mechanism for support of additional authentication methods without the NAS to be upgraded to support each new method. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos [RFC1510], Public Key [RFC2716], One Time Passwords [RFC2284], and others.
[RFC2284]中描述的可扩展身份验证协议（EAP）提供了一种标准机制，用于支持其他身份验证方法，而无需升级NAS以支持每种新方法。通过使用EAP，可以添加对许多身份验证方案的支持，包括智能卡、Kerberos[RFC1510]、公钥[RFC2716]、一次性密码[RFC2284]和其他。
One of the advantages of the EAP architecture is its flexibility. EAP is used to select a specific authentication mechanism. Rather than requiring the NAS to be updated to support each new authentication method, EAP permits the use of an authentication server implementing authentication methods, with the NAS acting as a pass-through for some or all methods and peers.
EAP体系结构的优点之一是它的灵活性。EAP用于选择特定的身份验证机制。EAP不要求更新NAS以支持每种新的身份验证方法，而是允许使用实现身份验证方法的身份验证服务器，NAS充当某些或所有方法和对等方的传递。
A NAS MAY authenticate local peers while at the same time acting as a pass-through for non-local peers and authentication methods it does not implement locally. A NAS implementing this specification is not required to use RADIUS to authenticate every peer. However, once the NAS begins acting as a pass-through for a particular session, it can no longer perform local authentication for that session.
NAS可以对本地对等点进行身份验证，同时充当非本地对等点和未在本地实现的身份验证方法的传递。实现此规范的NAS无需使用RADIUS对每个对等方进行身份验证。但是，一旦NAS开始充当特定会话的传递，它就不能再为该会话执行本地身份验证。
In order to support 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.
为了支持RADIUS中的EAP，本文引入了两个新属性：EAP消息和消息验证器。本节介绍如何使用这些新属性在RADIUS内提供EAP支持。
In RADIUS/EAP, RADIUS is used to shuttle RADIUS-encapsulated EAP Packets between the NAS and an authentication server.
在RADIUS/EAP中，RADIUS用于在NAS和身份验证服务器之间传输RADIUS封装的EAP数据包。
The authenticating peer and the NAS begin the EAP conversation by negotiating use of EAP. Once EAP has been negotiated, the NAS SHOULD send an initial EAP-Request message to the authenticating peer. This will typically be an EAP-Request/Identity, although it could be an EAP-Request for an authentication method (Types 4 and greater). A NAS MAY be configured to initiate with a default authentication method. This is useful in cases where the identity is determined by another means (such as Called-Station-Id, Calling-Station-Id and/or Originating-Line-Info); where a single authentication method is required, which includes its own identity exchange; where identity hiding is desired, so that the identity is not requested until after a protected channel has been set up.
认证对等方和NAS通过协商EAP的使用开始EAP对话。协商EAP后，NAS应向认证对等方发送初始EAP请求消息。这通常是EAP请求/标识，但也可能是针对身份验证方法（类型4及更高）的EAP请求。NAS可以配置为使用默认身份验证方法启动。这在通过其他方式（例如被叫站Id、主叫站Id和/或始发线路信息）确定身份的情况下是有用的；需要单一认证方法的，包括其自身的身份交换；其中需要身份隐藏，以便在设置受保护通道之前不请求身份。
The peer replies with an EAP-Response. The NAS MAY determine from the Response that it should proceed with local authentication. Alternatively, the NAS MAY act as a pass-through, encapsulating the EAP-Response within EAP-Message attribute(s) sent to the RADIUS server within a RADIUS Access-Request packet. If the NAS sends an EAP-Request/Identity message as the initial packet, the peer responds with an EAP-Response/Identity. The NAS may determine that the peer is local and proceed with local authentication. If no match is found against the list of local users, the NAS encapsulates the EAP-Response/Identity message within an EAP-Message attribute, enclosed within an Access-Request packet.
对等方回复EAP响应。NAS可根据响应确定应继续进行本地身份验证。或者，NAS可以充当传递，将EAP响应封装在发送到RADIUS服务器的EAP消息属性中的RADIUS访问请求数据包中。如果NAS发送EAP请求/标识消息作为初始数据包，则对等方将使用EAP响应/标识进行响应。NAS可以确定对等方是本地的，并继续进行本地身份验证。如果在本地用户列表中未找到匹配项，NAS将EAP响应/标识消息封装在EAP消息属性中，并封装在访问请求数据包中。
On receiving a valid Access-Request packet containing EAP-Message attribute(s), a RADIUS server compliant with this specification and wishing to authenticate with EAP MUST respond with an Access-Challenge packet containing EAP-Message attribute(s). If the RADIUS server does not support EAP or does not wish to authenticate with EAP, it MUST respond with an Access-Reject.
在收到包含EAP消息属性的有效访问请求数据包时，符合本规范并希望通过EAP验证的RADIUS服务器必须使用包含EAP消息属性的访问质询数据包进行响应。如果RADIUS服务器不支持EAP或不希望使用EAP进行身份验证，则必须以访问拒绝响应。
EAP-Message attribute(s) encapsulate a single EAP packet which the NAS decapsulates and passes on to the authenticating peer. The peer then responds with an EAP-Response packet, which the NAS encapsulates within an Access-Request containing EAP-Message attribute(s). EAP is a 'lock step' protocol, so that other than the initial Request, a new Request cannot be sent prior to receiving a valid Response.
EAP消息属性封装一个EAP数据包，NAS将该数据包解封并传递给身份验证对等方。然后，对等方使用EAP响应数据包进行响应，NAS将该数据包封装在包含EAP消息属性的访问请求中。EAP是一种“锁定步骤”协议，因此除了初始请求之外，在接收到有效响应之前不能发送新请求。
The conversation continues until either a RADIUS Access-Reject or Access-Accept packet is received from the RADIUS server. Reception of a RADIUS Access-Reject packet MUST result in the NAS denying access to the authenticating peer. A RADIUS Access-Accept packet successfully ends the authentication phase. The NAS MUST NOT "manufacture" a Success or Failure packet as the result of a timeout. After a suitable number of timeouts have elapsed, the NAS SHOULD instead end the EAP conversation.
对话将继续，直到从RADIUS服务器接收到RADIUS访问拒绝或访问接受数据包。接收RADIUS访问拒绝数据包必须导致NAS拒绝对身份验证对等方的访问。RADIUS访问接受数据包成功结束身份验证阶段。NAS不得因超时而“制造”成功或失败数据包。经过适当数量的超时后，NAS应结束EAP对话。
Using RADIUS, the NAS can act as a pass-through for an EAP conversation between the peer and authentication server, without needing to implement the EAP method used between them. Where the NAS initiates the conversation by sending an EAP-Request for an authentication method, it may not be required that the NAS fully implement the EAP method reflected in the initial EAP-Request. Depending on the initial method, it may be sufficient for the NAS to be configured with the initial packet to be sent to the peer, and for the NAS to act as a pass-through for subsequent messages. Note that since the NAS only encapsulates the EAP-Response in its initial Access-Request, the initial EAP-Request within the authentication method is not available to the RADIUS server. For the RADIUS server to be able to continue the conversation, either the initial EAP-Request is vestigial, so that the RADIUS server need not be aware of it, or the relevant information from the initial EAP-Request (such as a nonce) is reflected in the initial EAP-Response, so that the RADIUS server can obtain it without having received the initial EAP-Request.
使用RADIUS，NAS可以充当对等方和身份验证服务器之间EAP对话的传递，而无需实现它们之间使用的EAP方法。如果NAS通过发送认证方法的EAP请求来启动对话，则可能不要求NAS完全实现初始EAP请求中反映的EAP方法。根据初始方法，NAS配置为具有要发送到对等方的初始分组，并且NAS充当后续消息的传递就足够了。请注意，由于NAS仅在其初始访问请求中封装EAP响应，因此身份验证方法中的初始EAP请求对RADIUS服务器不可用。为了使RADIUS服务器能够继续对话，要么初始EAP请求是残留的，这样RADIUS服务器就不需要知道它，要么初始EAP请求的相关信息（如nonce）反映在初始EAP响应中，这样RADIUS服务器就可以在没有收到初始EAP请求的情况下获得它。
Where the initial EAP-Request sent by the NAS is for an authentication Type (4 or greater), the peer MAY respond with a Nak indicating that it would prefer another authentication method that is not implemented locally. In this case, the NAS SHOULD send Access-Request encapsulating the received EAP-Response/Nak. This provides the RADIUS server with a hint about the authentication method(s) preferred by the peer, although it does not provide information on the Type of the original Request. It also provides the server with the Identifier used in the initial EAP-Request, so that Identifier conflicts can be avoided.
当NAS发送的初始EAP请求是针对认证类型（4或更大）时，对等方可以用Nak响应，指示其更喜欢未在本地实现的另一认证方法。在这种情况下，NAS应发送封装接收到的EAP响应/Nak的访问请求。这为RADIUS服务器提供了关于对等方首选的身份验证方法的提示，尽管它没有提供关于原始请求类型的信息。它还向服务器提供初始EAP请求中使用的标识符，以便避免标识符冲突。
In order to evaluate whether the alternatives preferred by the authenticating peer are allowed, the RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). This allows the RADIUS server to determine the peer identity, so as to be able to retrieve the associated authentication policy. Alternatively, an EAP-Request for an authentication method (Type 4 or greater) could be sent. Since the RADIUS server may not be aware of the Type of the initial EAP-Request, it is possible for the RADIUS server to choose an unacceptable method, and for the peer to respond with another Nak.
为了评估是否允许认证对等方首选的备选方案，RADIUS服务器通常会响应一个包含封装EAP请求/标识（类型1）的EAP消息属性的访问质询。这允许RADIUS服务器确定对等身份，以便能够检索关联的身份验证策略。或者，可以发送针对身份验证方法（类型4或更高）的EAP请求。由于RADIUS服务器可能不知道初始EAP请求的类型，因此RADIUS服务器可能选择不可接受的方法，并且对等方可能使用另一个Nak进行响应。
In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. Since RADIUS proxies are assumed to act as a pass-through, they cannot be expected to parse an EAP-Response/Identity encapsulated within EAP-Message attribute(s). If the NAS initially sends an EAP-Request for an authentication method, and the peer identity cannot be determined from the EAP-Response, then the User-Name attribute SHOULD be determined by another means. As noted in [RFC2865] Section 5.6, it is recommended that Access-Requests use the value of the Calling-Station-Id as the value of the User-Name attribute.
为了允许非EAP感知RADIUS代理转发访问请求数据包，如果NAS最初向对等方发送EAP请求/标识消息，NAS必须将从对等方接收的EAP响应/标识的类型数据字段的内容复制到用户名属性中，并且必须在每个后续访问请求的用户名属性中包含EAP响应/标识的类型数据字段。由于假定RADIUS代理充当传递，因此不能期望它们解析封装在EAP消息属性中的EAP响应/标识。如果NAS最初发送认证方法的EAP请求，并且无法从EAP响应中确定对等身份，则应通过其他方式确定用户名属性。如[RFC2865]第5.6节所述，建议访问请求使用呼叫站Id的值作为用户名属性的值。
Having the NAS send the initial EAP-Request packet has a number of advantages:
让NAS发送初始EAP请求数据包有许多优点：
[1] It saves a round trip between the NAS and RADIUS server.
[1] 它节省了NAS和RADIUS服务器之间的往返。
[2] An Access-Request is only sent to the RADIUS server if the authenticating peer sends an EAP-Response, confirming that it supports EAP. In situations where peers may be EAP unaware, initiating a RADIUS Access-Request on a "carrier sense" or "media up" indication may result in many authentication exchanges that cannot complete successfully. For example, on wired networks [IEEE8021X] Supplicants typically do not initiate the 802.1X conversation with an EAPOL-Start. Therefore an IEEE 802.1X-enabled bridge may not be able to determine whether the peer supports EAP until it receives a Response to the initial EAP-Request.
[2] 只有验证对等方发送EAP响应，确认其支持EAP时，才会向RADIUS服务器发送访问请求。在对等方可能不知道EAP的情况下，在“载波感知”或“媒体启动”指示上启动RADIUS访问请求可能会导致许多无法成功完成的身份验证交换。例如，在有线网络[IEEE8021X]上，请求者通常不使用EAPOL启动启动802.1X对话。因此，启用IEEE 802.1X的网桥在收到对初始EAP请求的响应之前可能无法确定对等方是否支持EAP。
[3] It allows some peers to be authenticated locally.
[3] 它允许一些对等点在本地进行身份验证。
Although having the NAS send the initial EAP-Request packet has substantial advantages, this technique cannot be universally employed. There are circumstances in which the peer identity is already known (such as when authentication and accounting is handled based on Called-Station-Id, Calling-Station-Id and/or Originating-Line-Info), but where the appropriate EAP method may vary based on that identity.
尽管让NAS发送初始EAP请求数据包具有很大的优势，但这种技术不能普遍采用。在某些情况下，对等身份是已知的（例如，当基于被叫站Id、主叫站Id和/或始发线路信息处理身份验证和记帐时），但是适当的EAP方法可能基于该身份而变化。
Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server.
在检测到对等方的存在时，NAS可以向RADIUS服务器发送包含表示EAP启动的EAP消息属性的访问请求分组，而不是向认证对等方发送初始EAP请求分组。RADIUS服务器通常会响应包含封装EAP请求/标识（类型1）的EAP消息属性的访问质询。但是，服务器也可以发送针对身份验证方法（类型4或更高）的EAP请求。
EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). The Calling-Station-Id SHOULD be included in the User-Name attribute. This may result in a RADIUS Access-Request being sent by the NAS to the RADIUS server without first confirming that the peer supports EAP. Since this technique can result in a large number of uncompleted RADIUS conversations, in situations where EAP unaware peers are common, or where peer support for EAP cannot be determined on initial contact (e.g. [IEEE8021X] Supplicants not initiating the conversation with an EAPOL-Start) it SHOULD NOT be employed by default.
EAP启动通过发送长度为2（无数据）的EAP消息属性来指示。呼叫站Id应包含在用户名属性中。这可能导致NAS向RADIUS服务器发送RADIUS访问请求，而不首先确认对等方是否支持EAP。由于此技术可能导致大量未完成的RADIUS对话，因此在EAP不知道的对等方很常见的情况下，或者在初始接触时无法确定对等方对EAP的支持（例如，[IEEE8021X]请求方未启动EAPOL启动的对话）的情况下，默认情况下不应使用此技术。
For proxied RADIUS requests, there are two methods of processing. If the domain is determined based on the Calling-Station-Id, Called-Station-Id and/or Originating-Line-Info, the RADIUS server may proxy the initial RADIUS Access-Request/EAP-Start. If the realm is determined based on the peer identity, the local RADIUS server MUST respond with a RADIUS Access-Challenge including an EAP-Message attribute encapsulating an EAP-Request/Identity packet. The response from the authenticating peer SHOULD be proxied to the final authentication server.
对于代理RADIUS请求，有两种处理方法。如果根据主叫站Id、被叫站Id和/或始发线路信息确定域，RADIUS服务器可以代理初始RADIUS访问请求/EAP启动。如果领域是基于对等身份确定的，则本地RADIUS服务器必须响应RADIUS访问质询，包括封装EAP请求/身份数据包的EAP消息属性。来自身份验证对等方的响应应代理给最终身份验证服务器。
If an Access-Request is sent to a RADIUS server which does not support the EAP-Message attribute, then an Access-Reject MUST be sent in response. On receiving an Access-Reject, the NAS MUST deny access to the authenticating peer.
如果向不支持EAP消息属性的RADIUS服务器发送访问请求，则必须发送访问拒绝响应。在接收到访问拒绝时，NAS必须拒绝对身份验证对等方的访问。
While acting as a pass-through, the NAS MUST validate the EAP header fields (Code, Identifier, Length) prior to forwarding an EAP packet to or from the RADIUS server. On receiving an EAP packet from the peer, the NAS checks the Code (2) and Length fields, and matches the Identifier value against the current Identifier, supplied by the RADIUS server in the most recently validated EAP-Request. On receiving an EAP packet from the RADIUS server (encapsulated within an Access-Challenge), the NAS checks the Code (1) and Length fields, then updates the current Identifier value. Pending EAP Responses that do not match the current Identifier value are silently discarded by the NAS.
当作为传递时，NAS必须在向RADIUS服务器转发EAP数据包或从RADIUS服务器转发EAP数据包之前验证EAP报头字段（代码、标识符、长度）。从对等方接收EAP数据包时，NAS将检查代码（2）和长度字段，并将标识符值与RADIUS服务器在最近验证的EAP请求中提供的当前标识符进行匹配。从RADIUS服务器（封装在访问质询中）接收EAP数据包时，NAS检查代码（1）和长度字段，然后更新当前标识符值。与当前标识符值不匹配的挂起EAP响应将被NAS自动丢弃。
Since EAP method fields (Type, Type-Data) are typically not validated by a NAS operating as a pass-through, despite these checks it is possible for a NAS to forward an invalid EAP packet to or from the RADIUS server. A RADIUS server receiving EAP-Message attribute(s) it does not understand SHOULD make the determination of whether the error is fatal or non-fatal based on the EAP Type. A RADIUS server determining that a fatal error has occurred MUST send an Access-Reject containing an EAP-Message attribute encapsulating EAP-Failure.
由于EAP方法字段（类型、类型数据）通常不会由作为直通操作的NAS进行验证，因此尽管进行了这些检查，NAS仍有可能向RADIUS服务器转发无效的EAP数据包或从RADIUS服务器转发无效的EAP数据包。接收EAP消息属性的RADIUS服务器不了解该属性，应根据EAP类型确定错误是致命的还是非致命的。确定发生致命错误的RADIUS服务器必须发送包含封装EAP失败的EAP消息属性的访问拒绝。
A RADIUS server determining that a non-fatal error has occurred MAY send an Access-Challenge to the NAS including EAP-Message attribute(s) as well as an Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid EAP Packet (Ignored)". The Access-Challenge SHOULD encapsulate within EAP-Message attribute(s) the most recently sent EAP-Request packet (including the same Identifier value). On receiving such an Access-Challenge, a NAS implementing previous versions of this specification will decapsulate the EAP-Request and send it to the peer, which will retransmit the EAP-Response.
确定发生非致命错误的RADIUS服务器可向NAS发送访问质询，包括EAP消息属性以及值为202（十进制）“无效EAP数据包（忽略）”的错误原因属性[RFC3576]。访问质询应在EAP消息属性中封装最近发送的EAP请求数据包（包括相同的标识符值）。在收到此类访问质询时，实施本规范以前版本的NAS将解除EAP请求的封装并将其发送给对等方，对等方将重新传输EAP响应。
A NAS compliant with this specification, on receiving an Access-Challenge with an Error-Cause attribute of value 202 (decimal) SHOULD discard the EAP-Response packet most recently transmitted to the RADIUS server and check whether additional EAP-Response packets have been received matching the current Identifier value. If so, a new EAP-Response packet, if available, MUST be sent to the RADIUS server within an Access-Request, and the EAP-Message attribute(s) included within the Access-Challenge are silently discarded. If no EAP-Response packet is available, then the EAP-Request encapsulated within the Access-Challenge is sent to the peer, and the retransmission timer is reset.
符合本规范的NAS在接收到错误原因属性值为202（十进制）的访问质询时，应丢弃最近传输到RADIUS服务器的EAP响应数据包，并检查是否已接收到与当前标识符值匹配的其他EAP响应数据包。如果是这样，则必须在访问请求中向RADIUS服务器发送新的EAP响应数据包（如果可用），并且访问质询中包含的EAP消息属性将被自动丢弃。如果没有可用的EAP响应数据包，则将封装在访问质询中的EAP请求发送给对等方，并重置重传计时器。
In order to provide protection against Denial of Service (DoS) attacks, it is advisable for the NAS to allocate a finite buffer for EAP packets received from the peer, and to discard packets according to an appropriate policy once that buffer has been exceeded. Also, the RADIUS server is advised to permit only a modest number of invalid EAP packets within a single session, prior to terminating the session with an Access-Reject. By default a value of 5 invalid EAP packets is recommended.
为了提供针对拒绝服务（DoS）攻击的保护，建议NAS为从对等方接收的EAP数据包分配有限缓冲区，并在超过该缓冲区后根据适当的策略丢弃数据包。此外，建议RADIUS服务器在使用访问拒绝终止会话之前，在单个会话中仅允许少量无效EAP数据包。默认情况下，建议使用5个无效EAP数据包。
As noted in [RFC2284], if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit.
如[RFC2284]中所述，如果EAP数据包在认证对等方和NAS之间的传输过程中丢失（反之亦然），NAS将重新传输。
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 attribute 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 is used to set the EAP retransmission timer for that EAP Request, and that Request alone. Once the EAP-Request has been sent, the NAS sets the retransmission timer, and if it expires without having received an EAP-Response corresponding to the Request, then the EAP-Request is retransmitted.
如果也包含EAP消息的访问质询数据包中存在会话超时，则会话超时的值用于为该EAP请求以及该请求单独设置EAP重传计时器。一旦发送了EAP请求，NAS将设置重传计时器，如果该计时器过期而未收到与该请求对应的EAP响应，则将重传该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. A RADIUS server having received a Framed-MTU attribute in an Access-Request packet MUST NOT send any subsequent packet in this EAP conversation containing EAP-Message attributes whose values, when concatenated, exceed the length specified by the Framed-MTU value, taking the link type (specified by the NAS-Port-Type attribute) into account. For example, as noted in [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 802.11, the
使用EAP消息属性，RADIUS服务器可以在NAS和对等机之间的链路上封装比MTU大的EAP数据包。由于RADIUS服务器不可能使用MTU发现来确定链路MTU，因此帧MTU属性可以包括在包含EAP消息属性的访问请求分组中，以便向RADIUS服务器提供该信息。在访问请求数据包中接收到帧MTU属性的RADIUS服务器不得在此EAP会话中发送任何后续数据包，该EAP会话包含EAP消息属性，其值在连接时超过帧MTU值指定的长度，并考虑链路类型（由NAS端口类型属性指定）。例如，如[RFC3580]第3.10节所述，对于IEEE 802.11的NAS端口类型值
RADIUS server may send an EAP packet as large as Framed-MTU minus four (4) octets, taking into account the additional overhead for the IEEE 802.1X Version (1), Type (1) and Body Length (2) fields.
考虑到IEEE 802.1X版本（1）、类型（1）和正文长度（2）字段的额外开销，RADIUS服务器可以发送一个EAP数据包，其大小为帧MTU减去四（4）个八位字节。
Currently the conversation between security servers and the RADIUS server is often proprietary because of lack of standardization. In order to increase standardization and provide interoperability between RADIUS vendors and 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 security server instead.
这样做的优点是允许RADIUS服务器支持EAP，而无需在RADIUS服务器中使用特定于身份验证的代码。然后，特定于身份验证的代码可以驻留在安全服务器上。
In the case where RADIUS-encapsulated EAP is used in a conversation between a RADIUS server and a security server, the security server will typically return an Access-Accept 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 message to the NAS.
在RADIUS封装的EAP用于RADIUS服务器和安全服务器之间的对话的情况下，安全服务器通常会返回Access Accept消息，而不包括Access Accept中当前返回的预期属性。这意味着RADIUS服务器必须在向NAS发送访问接受消息之前添加这些属性。
In EAP, each session has its own unique Identifier space. RADIUS server implementations MUST be able to distinguish between EAP packets with the same Identifier existing within distinct sessions, originating on the same NAS. For this purpose, sessions can be distinguished based on NAS and session identification attributes. NAS identification attributes include NAS-Identifier, NAS-IPv6-Address and NAS-IPv4-Address. Session identification attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id, Called-Station-Id, Calling-Station-Id and Originating-Line-Info.
在EAP中，每个会话都有自己的唯一标识符空间。RADIUS服务器实施必须能够区分不同会话中存在相同标识符、源自相同NAS的EAP数据包。为此，可以根据NAS和会话标识属性来区分会话。NAS标识属性包括NAS标识符、NAS-IPv6-Address和NAS-IPv4-Address。会话标识属性包括用户名、NAS端口、NAS端口类型、NAS端口Id、被叫站Id、主叫站Id和始发线路信息。
Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time.
由于EAP是一种对等协议，因此独立且同时的身份验证可能发生在相反的方向。两个对等方可以同时充当身份验证方和被身份验证方。
However, role reversal is not supported by this specification. A RADIUS server MUST respond to an Access-Request encapsulating an EAP-Request with an Access-Reject. In order to avoid retransmissions
但是，此规范不支持角色转换。RADIUS服务器必须响应用访问拒绝封装EAP请求的访问请求。为了避免重发
by the peer, the Access-Reject SHOULD include an EAP-Response/Nak packet indicating no preferred method, encapsulated within EAP-Message attribute(s).
对于对等方，访问拒绝应该包括一个EAP响应/Nak分组，该分组指示没有首选方法，封装在EAP消息属性中。
The NAS MUST make its access control decision based solely on the RADIUS Packet Type (Access-Accept/Access-Reject). The access control decision MUST NOT be based on the contents of the EAP packet encapsulated in one or more EAP-Message attributes, if present.
NAS必须仅根据RADIUS数据包类型（访问接受/访问拒绝）做出访问控制决策。访问控制决策不得基于封装在一个或多个EAP消息属性（如果存在）中的EAP数据包的内容。
Access-Accept packets SHOULD have only one EAP-Message attribute in them, containing EAP Success; similarly, Access-Reject packets SHOULD have only one EAP-Message attribute in them, containing EAP Failure.
Access-Accept数据包中应该只有一个EAP消息属性，包含EAP Success；类似地，Access Reject数据包中应该只有一个EAP消息属性，其中包含EAP Failure。
Where the encapsulated EAP packet does not match the result implied by the RADIUS Packet Type, the combination is likely to cause confusion, because the NAS and peer will arrive at different conclusions as to the outcome of the authentication.
在封装的EAP分组与RADIUS分组类型所暗示的结果不匹配的情况下，组合很可能导致混淆，因为NAS和对等方将对认证的结果得出不同的结论。
For example, if the NAS receives an Access-Reject with an encapsulated EAP Success, it will not grant access to the peer. However, on receiving the EAP Success, the peer will be lead to believe that it authenticated successfully.
例如，如果NAS接收到带有封装EAP成功的访问拒绝，它将不会向对等方授予访问权限。然而，在接收到EAP成功后，对等方将被引导相信其已成功认证。
If the NAS receives an Access-Accept with an encapsulated EAP Failure, it will grant access to the peer. However, on receiving an EAP Failure, the peer will be lead to believe that it failed authentication. If no EAP-Message attribute is included within an Access-Accept or Access-Reject, then the peer may not be informed as to the outcome of the authentication, while the NAS will take action to allow or deny access.
如果NAS接收到带有封装EAP故障的访问接受，它将向对等方授予访问权限。但是，在接收到EAP失败时，会导致对等方认为其身份验证失败。如果访问接受或访问拒绝中不包含EAP消息属性，则可能不会通知对等方身份验证的结果，而NAS将采取允许或拒绝访问的操作。
As described in [RFC2284], the EAP Success and Failure packets are not acknowledged, and these packets terminate the EAP conversation. As a result, if these packets are encapsulated within an Access-Challenge, no response will be received, and therefore the NAS will send no further Access-Requests to the RADIUS server for the session. As a result, the RADIUS server will not indicate to the NAS whether to allow or deny access, while the peer will be informed as to the outcome of the authentication.
如[RFC2284]所述，EAP成功和失败数据包不被确认，这些数据包终止EAP对话。因此，如果这些数据包被封装在访问质询中，则不会收到任何响应，因此NAS不会向RADIUS服务器发送进一步的会话访问请求。因此，RADIUS服务器将不会向NAS指示是否允许或拒绝访问，而将通知对等方身份验证的结果。
To avoid these conflicts, the following combinations SHOULD NOT be sent by a RADIUS server:
为避免这些冲突，RADIUS服务器不应发送以下组合：
Access-Accept/EAP-Message/EAP Failure
Access-Accept/no EAP-Message attribute
Access-Accept/EAP-Start
Access-Reject/EAP-Message/EAP Success
Access-Reject/no EAP-Message attribute
Access-Reject/EAP-Start
Access-Challenge/EAP-Message/EAP Success
Access-Challenge/EAP-Message/EAP Failure
Access-Challenge/no EAP-Message attribute
Access-Challenge/EAP-Start
Access-Accept/EAP-Message/EAP Failure
Access-Accept/no EAP-Message attribute
Access-Accept/EAP-Start
Access-Reject/EAP-Message/EAP Success
Access-Reject/no EAP-Message attribute
Access-Reject/EAP-Start
Access-Challenge/EAP-Message/EAP Success
Access-Challenge/EAP-Message/EAP Failure
Access-Challenge/no EAP-Message attribute
Access-Challenge/EAP-Start
Since the responsibility for avoiding conflicts lies with the RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to correct contradictory messages that it receives. This behavior, originally mandated within [IEEE8021X], will be deprecated in the future.
由于避免冲突的责任在于RADIUS服务器，因此NAS不得“制造”EAP数据包以纠正其接收到的相互矛盾的消息。此行为最初是在[IEEE8021X]中强制执行的，将来将不再推荐。
A RADIUS Access-Accept or Access-Reject packet may contain EAP-Message attribute(s). In order to ensure the correct processing of RADIUS packets, the NAS MUST first process the attributes, including the EAP-Message attribute(s), prior to processing the Accept/Reject indication.
RADIUS访问接受或访问拒绝数据包可能包含EAP消息属性。为了确保正确处理RADIUS数据包，NAS必须首先处理属性，包括EAP消息属性，然后再处理接受/拒绝指示。
The Reply-Message attribute, defined in [RFC2865], Section 5.18, indicates text which may be displayed to the peer. This is similar in concept to EAP Notification, defined in [RFC2284]. When sending a displayable message to a NAS during an EAP conversation, the RADIUS server MUST encapsulate displayable messages within EAP-Message/EAP-Request/Notification attribute(s). Reply-Message attribute(s) MUST NOT be included in any RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an Access-Accept or Access-Reject packet.
[RFC2865]第5.18节中定义的回复消息属性表示可向对等方显示的文本。这在概念上类似于[RFC2284]中定义的EAP通知。在EAP对话期间向NAS发送可显示消息时，RADIUS服务器必须将可显示消息封装在EAP消息/EAP请求/通知属性中。任何包含EAP消息属性的RADIUS消息中不得包含回复消息属性。访问接受或访问拒绝数据包中不应包含EAP消息/EAP请求/通知。
In some existing implementations, a NAS receiving Reply-Message attribute(s) copies the Text field(s) into the Type-Data field of an EAP-Request/Notification packet, fills in the Identifier field, and sends this to the peer. However, several issues arise from this:
在一些现有实现中，NAS接收回复消息属性将文本字段复制到EAP请求/通知数据包的类型数据字段中，填写标识符字段，并将其发送给对等方。然而，由此产生了几个问题：
[1] Unexpected Responses. On receiving an EAP-Request/Notification, the peer will send an EAP-Response/Notification, and the NAS will pass this on to the RADIUS server, encapsulated within EAP-Message attribute(s). However, the RADIUS server may not be expecting an Access-Request containing an EAP-Message/EAP-Response/Notification attribute.
[1] 意外的反应。在接收到EAP请求/通知时，对等方将发送EAP响应/通知，NAS将此信息传递给RADIUS服务器，封装在EAP消息属性中。但是，RADIUS服务器可能不需要包含EAP消息/EAP响应/通知属性的访问请求。
For example, consider what happens when a Reply-Message is included within an Access-Accept or Access-Reject packet with no EAP-Message attribute(s) present. If the value of the Reply-Message attribute is copied into the Type-Data of an EAP-Request/Notification and sent to the peer, this will result in an Access-Request containing an EAP-Message/EAP-Response/Notification attribute being sent by the NAS to the RADIUS server. Since an Access-Accept or Access-Reject packet terminates the RADIUS conversation, such an Access-Request would not be expected, and could be interpreted as the start of another conversation.
例如，考虑在没有接受EAP消息属性的情况下，将应答消息包含在访问接受或拒绝拒绝包中的情况。如果应答消息属性的值被复制到EAP请求/通知的类型数据中并发送到对等方，这将导致NAS将包含EAP消息/EAP响应/通知属性的访问请求发送到RADIUS服务器。由于Access Accept或Access Reject数据包终止RADIUS对话，因此这样的访问请求将不会出现，并且可能被解释为另一个对话的开始。
[2] Identifier conflicts. While the EAP-Request/Notification is an EAP packet containing an Identifier field, the Reply-Message attribute does not contain an Identifier field. As a result, a NAS receiving a Reply-Message attribute and wishing to translate this to an EAP-Request/Notification will need to choose an Identifier value. It is possible that the chosen Identifier value will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation, potentially causing confusion between a new packet and a retransmission.
[2] 标识符冲突。虽然EAP请求/通知是包含标识符字段的EAP数据包，但回复消息属性不包含标识符字段。因此，接收回复消息属性并希望将其转换为EAP请求/通知的NAS需要选择标识符值。选择的标识符值可能与RADIUS服务器为EAP会话中的另一个数据包选择的值冲突，这可能导致新数据包和重传之间的混淆。
To avoid these problems, a NAS receiving a Reply-Message attribute from the RADIUS server SHOULD silently discard the attribute, rather than attempting to translate it to an EAP Notification Request.
为了避免这些问题，从RADIUS服务器接收回复消息属性的NAS应该自动放弃该属性，而不是尝试将其转换为EAP通知请求。
The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in Access-Request packets, and either NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address attributes 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 difficult to manage. The User-Name attribute within the Access-Accept packet need not be the same as the User-Name attribute in the Access-Request.
NAS应在访问请求数据包中包括NAS端口或NAS端口Id属性，并且必须包括NAS标识符、NAS IP地址或NAS-IPv6-Address属性。为了允许EAP非感知代理转发访问回复，如果访问请求中包含用户名属性，RADIUS服务器必须在后续访问接受数据包中包含用户名属性。如果没有用户名属性，会计和账单就很难管理。访问接受数据包中的用户名属性不必与访问请求中的用户名属性相同。
Description
描述
This attribute encapsulates EAP [RFC2284] packets so as to allow the NAS to authenticate peers via EAP without having to understand the EAP method it is passing through.
此属性封装EAP[RFC2284]数据包，以便允许NAS通过EAP对对等方进行身份验证，而无需了解其所通过的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-Message attributes 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. The RADIUS server can return EAP-Message attributes in Access-Challenge, Access-Accept and Access-Reject packets.
NAS将从身份验证对等方接收的EAP消息放入一个或多个EAP消息属性中，并在访问请求消息中将其转发到RADIUS服务器。如果一个访问请求或访问质询数据包中包含多个EAP消息属性，则它们必须是有序的，并且必须是访问请求或访问质询数据包中的连续属性。RADIUS服务器可以在访问质询、访问接受和访问拒绝数据包中返回EAP消息属性。
When RADIUS is used to enable EAP authentication, Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets SHOULD contain one or more EAP-Message attributes. Where more than one EAP-Message attribute is included, it is assumed that the attributes are to be concatenated to form a single EAP packet.
当RADIUS用于启用EAP身份验证时，访问请求、访问质询、访问接受和访问拒绝数据包应包含一个或多个EAP消息属性。在包括多个EAP消息属性的情况下，假设将这些属性串联以形成单个EAP分组。
Multiple EAP packets MUST NOT be encoded within EAP-Message attributes contained within a single Access-Challenge, Access-Accept, Access-Reject or Access-Request packet.
不得在单个访问质询、访问接受、访问拒绝或访问请求数据包中包含的EAP消息属性中对多个EAP数据包进行编码。
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 EAP Success or EAP Failure packets) it is necessary that RADIUS provide per-packet authentication and integrity protection.
预计EAP将用于实现各种身份验证方法，包括涉及强加密的方法。为了防止攻击者通过攻击RADIUS/EAP（例如，通过修改EAP成功或EAP失败数据包）破坏EAP，RADIUS必须提供每个数据包的身份验证和完整性保护。
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 EAP-Message attribute(s) without a Message-Authenticator attribute SHOULD be silently discarded by the RADIUS server. A RADIUS server supporting the EAP-Message attribute MUST calculate the correct value of the Message-Authenticator and MUST silently discard the packet if it does not match the value sent. A RADIUS server not supporting the EAP-Message attribute MUST return an Access-Reject if it receives an Access-Request containing an EAP-Message attribute.
RADIUS服务器应以静默方式丢弃包含EAP消息属性但不包含消息验证器属性的访问请求数据包。支持EAP消息属性的RADIUS服务器必须计算消息验证器的正确值，如果数据包与发送的值不匹配，则必须自动丢弃该数据包。不支持EAP消息属性的RADIUS服务器如果接收到包含EAP消息属性的访问请求，则必须返回访问拒绝。
Access-Challenge, Access-Accept, or Access-Reject packets including EAP-Message attribute(s) without a Message-Authenticator attribute SHOULD be silently discarded by the NAS. A NAS supporting the EAP-Message attribute MUST calculate the correct value of the Message-Authenticator and MUST silently discard the packet if it does not match the value sent.
NAS应自动丢弃包括EAP消息属性（不含消息验证器属性）的访问质询、访问接受或访问拒绝数据包。支持EAP消息属性的NAS必须计算消息验证器的正确值，如果数据包与发送的值不匹配，则必须自动丢弃该数据包。
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 an EAP packet, as defined in [RFC2284]. 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 transported by RADIUS.
字符串字段包含[RFC2284]中定义的EAP数据包。如果数据包中存在多个EAP消息属性，则应将其值串联起来；这允许RADIUS传输长度超过253个八位组的EAP数据包。
Description
描述
This attribute MAY be used to authenticate and integrity-protect Access-Requests in order to prevent spoofing. 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.
此属性可用于验证和完整性保护访问请求，以防止欺骗。它可以用于任何访问请求。它必须用于包含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客户端必须计算消息验证器的正确值，如果数据包与发送的值不匹配，则自动丢弃数据包。
This attribute is not required in Access-Requests which include the User-Password attribute, 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质询和响应的数据包，并对这些数据包脱机执行字典攻击。
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 [RFC2104] hash of the entire Access-Request packet, including Type, ID, Length and Authenticator, using the shared secret as the key, as follows.
当存在于接入请求分组中时，消息验证器是整个接入请求分组的HMAC-MD5[RFC2104]散列，包括类型、ID、长度和验证器，使用共享密钥作为密钥，如下所示。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
消息验证器=HMAC-MD5（类型、标识符、长度、请求验证器、属性）
When the message integrity check 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 message integrity check 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 message integrity check. The Message-Authenticator is calculated and inserted in the packet before the Response Authenticator is calculated.
当计算消息完整性检查时，签名字符串应被视为十六个八位组的零。共享密钥用作HMAC-MD5消息完整性检查的密钥。在计算响应验证器之前，计算消息验证器并将其插入数据包中。
The following table provides a guide to which attributes may be found in packets including EAP-Message attribute(s), and in what quantity. The EAP-Message and Message-Authenticator attributes specified in this document MUST NOT be present in an Accounting-Request. If a table entry is omitted, the values found in [RFC2548], [RFC2865], [RFC2868], [RFC2869] and [RFC3162] should be assumed.
下表提供了在包含EAP消息属性的数据包中可以找到哪些属性以及数量的指南。本文档中指定的EAP消息和消息验证器属性不得出现在记帐请求中。如果省略表项，则应假定[RFC2548]、[RFC2865]、[RFC2868]、[RFC2869]和[RFC3162]中的值。
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
0 0 0 0 2 User-Password [Note 1]
0 0 0 0 3 CHAP-Password [Note 1]
0 0 0 0 18 Reply-Message
0 0 0 0 60 CHAP-Challenge
0 0 0 0 70 ARAP-Password [Note 1]
0 0 0 0 75 Password-Retry
1+ 1+ 1+ 1+ 79 EAP-Message [Note 1]
1 1 1 1 80 Message-Authenticator [Note 1]
0-1 0 0 0 94 Originating-Line-Info [Note 3]
0 0 0-1 0-1 101 Error-Cause [Note 2]
Request Accept Reject Challenge # Attribute
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
0 0 0 0 2 User-Password [Note 1]
0 0 0 0 3 CHAP-Password [Note 1]
0 0 0 0 18 Reply-Message
0 0 0 0 60 CHAP-Challenge
0 0 0 0 70 ARAP-Password [Note 1]
0 0 0 0 75 Password-Retry
1+ 1+ 1+ 1+ 79 EAP-Message [Note 1]
1 1 1 1 80 Message-Authenticator [Note 1]
0-1 0 0 0 94 Originating-Line-Info [Note 3]
0 0 0-1 0-1 101 Error-Cause [Note 2]
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. A RADIUS server receiving an Access-Request not containing any of those four attributes and also not containing a Message-Authenticator attribute SHOULD silently discard it.
[注意1]包含用户密码、CHAP密码、ARAP密码或一个或多个EAP消息属性的访问请求不得包含这四个属性中的一种以上类型。如果它不包含这四个属性中的任何一个，那么它应该包含一个消息验证器。如果任何数据包类型包含EAP消息属性，则它还必须包含消息验证器。如果RADIUS服务器接收到的访问请求不包含这四个属性中的任何一个，也不包含消息验证器属性，则应自动放弃该请求。
[Note 2] The Error-Cause attribute is defined in [RFC3576].
[注2]错误原因属性在[RFC3576]中定义。
[Note 3] The Originating-Line-Info attribute is defined in [NASREQ].
[注3]原始线路信息属性在[NASREQ]中定义。
The following table defines the meaning of 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. 1+ One or more of these attributes MUST be present.
0此属性不能存在。此属性可能存在0+零个或多个实例。0-1此属性可能存在零个或一个实例。1此属性必须仅存在一个实例。1+必须存在这些属性中的一个或多个。
RADIUS/EAP is used in order to provide authentication and authorization for network access. As a result, both the RADIUS and EAP portions of the conversation are potential targets of an attack. Threats are discussed in [RFC2607], [RFC2865], and [RFC3162]. Examples include:
RADIUS/EAP用于为网络访问提供身份验证和授权。因此，会话的RADIUS和EAP部分都是潜在的攻击目标。[RFC2607]、[RFC2865]和[RFC3162]中讨论了威胁。例子包括：
[1] An adversary may attempt to acquire confidential data and identities by snooping RADIUS packets.
[1] 敌方可能试图通过窥探RADIUS数据包获取机密数据和身份。
[2] An adversary may attempt to modify packets containing RADIUS messages.
[2] 对手可能试图修改包含RADIUS消息的数据包。
[3] An adversary may attempt to inject packets into a RADIUS conversation.
[3] 对手可能试图将数据包注入RADIUS对话。
[4] An adversary may launch a dictionary attack against the RADIUS shared secret.
[4] 对手可以对RADIUS共享机密发起字典攻击。
[5] An adversary may launch a known plaintext attack, hoping to recover the key stream corresponding to a Request Authenticator.
[5] 对手可能发起已知的明文攻击，希望恢复与请求验证器对应的密钥流。
[6] An adversary may attempt to replay a RADIUS exchange.
[6] 对手可以尝试重放半径交换。
[7] An adversary may attempt to disrupt the EAP negotiation, in order to weaken the authentication, or gain access to peer passwords.
[7] 对手可能会试图中断EAP协商，以削弱身份验证，或获得对对等密码的访问。
[8] An authenticated NAS may attempt to forge NAS or session identification attributes,
[8] 经过身份验证的NAS可能会试图伪造NAS或会话标识属性，
[9] A rogue (unauthenticated) NAS may attempt to impersonate a legitimate NAS.
[9] 流氓（未经验证的）NAS可能会试图模拟合法的NAS。
[10] An attacker may attempt to act as a man-in-the-middle.
[10] 攻击者可能试图扮演中间人的角色。
To address these threats, it is necessary to support confidentiality, data origin authentication, integrity, and replay protection on a per-packet basis. Bi-directional authentication between the RADIUS client and server also needs to be provided. There is no requirement that the identities of RADIUS clients and servers be kept confidential (e.g., from a passive eavesdropper).
为了应对这些威胁，有必要在每个数据包的基础上支持机密性、数据源身份验证、完整性和重播保护。还需要提供RADIUS客户端和服务器之间的双向身份验证。不要求对RADIUS客户端和服务器的身份保密（例如，来自被动窃听者）。
To address the security vulnerabilities of RADIUS/EAP, implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management.
为了解决RADIUS/EAP的安全漏洞，本规范的实现应支持IPsec[RFC2401]和IKE[RFC2409]进行密钥管理。应支持具有非空转换的IPsec ESP[RFC2406]，并且应使用具有非空加密转换和身份验证支持的IPsec ESP来提供每个数据包的机密性、身份验证、完整性和重播保护。IKE应该用于密钥管理。
Within RADIUS [RFC2865], a shared secret is used for hiding of attributes such as User-Password, as well as in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Response Authenticator.
在RADIUS[RFC2865]中，共享秘密用于隐藏用户密码等属性，以及计算响应验证器。在RADIUS accounting[RFC2866]中，共享密钥用于计算请求认证器和响应认证器。
Since in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication, only use of IPsec ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPSEC AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret.
由于在RADIUS中，共享秘密用于提供机密性以及完整性保护和身份验证，因此只有使用具有非空转换的IPsec ESP才能提供足以替代RADIUS应用层安全性的安全服务。因此，在使用IPSEC AH或ESP null的情况下，通常仍需要配置RADIUS共享机密。
Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed. However, a RADIUS server that cannot know whether incoming traffic is IPsec-protected MUST be configured with a non-null RADIUS shared secret.
如果RADIUS通过IPsec ESP以非空转换运行，则可能无法配置NAS和RADIUS服务器之间共享的机密。在这种情况下，必须假定一个长度为零的共享秘密。但是，无法知道传入通信是否受IPsec保护的RADIUS服务器必须配置非空RADIUS共享机密。
When IPsec ESP is used with RADIUS, per-packet authentication, integrity and replay protection MUST be used. 3DES-CBC MUST be supported as an encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be offered as a preferred encryption transform if supported. HMAC-SHA1-96 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be used as the encryption transform.
当IPsec ESP与RADIUS一起使用时，必须使用每包身份验证、完整性和重播保护。必须支持3DES-CBC作为加密转换，并且应支持AES-CBC。如果支持，AES-CBC应作为首选加密转换提供。必须支持HMAC-SHA1-96作为身份验证转换。DES-CBC不应用作加密转换。
A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812".
支持IPsec的RADIUS客户端的典型IPsec策略是“启动IPsec，从me到任何目标端口UDP 1812”。这会导致RADIUS客户端在发送RADIUS流量之前设置IPsec SA。如果客户端联系的某些RADIUS服务器不支持IPsec，则需要更精细的策略：“启动IPsec，从me到支持IPsec的RADIUS服务器，目标端口UDP 1812”。
For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept IPsec, from any to me, destination port 1812". This causes the RADIUS server to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS clients connecting to an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec.
对于支持IPsec的RADIUS服务器，典型的IPsec策略是“接受IPsec，从任何到我，目标端口1812”。这会导致RADIUS服务器接受（但不要求）使用IPsec。对于连接到启用IPsec的RADIUS服务器的所有RADIUS客户端，可能不适合要求IPsec，因为某些RADIUS客户端可能不支持IPsec。
Where IPsec is used for security, and no RADIUS shared secret is configured, it is important that the RADIUS client and server perform an authorization check. Before enabling a host to act as a RADIUS client, the RADIUS server SHOULD check whether the host is authorized to provide network access. Similarly, before enabling a host to act as a RADIUS server, the RADIUS client SHOULD check whether the host is authorized for that role.
如果IPsec用于安全，并且未配置RADIUS共享机密，则RADIUS客户端和服务器执行授权检查非常重要。在启用主机作为RADIUS客户端之前，RADIUS服务器应检查主机是否有权提供网络访问。类似地，在启用主机作为RADIUS服务器之前，RADIUS客户端应检查主机是否被授权担任该角色。
RADIUS servers can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS clients. Alternatively, if a separate Certification Authority (CA) exists for RADIUS clients, then the RADIUS server can configure this CA as a trust anchor [RFC3280] for use with IPsec.
RADIUS服务器可以配置RADIUS客户端的IP地址（用于带有预共享密钥的IKE攻击模式）或FQDN（用于证书身份验证）。或者，如果RADIUS客户端存在单独的证书颁发机构（CA），则RADIUS服务器可以将此CA配置为用于IPsec的信任锚[RFC3280]。
Similarly, RADIUS clients can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS servers. Alternatively, if a separate CA exists for RADIUS servers, then the RADIUS client can configure this CA as a trust anchor for use with IPsec.
类似地，RADIUS客户端可以配置RADIUS服务器的IP地址（对于具有预共享密钥的IKE攻击模式）或FQDN（用于证书身份验证）。或者，如果RADIUS服务器存在单独的CA，则RADIUS客户端可以将此CA配置为用于IPsec的信任锚。
Since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, certificate policies need to apply to all uses of IPsec on RADIUS clients and servers. In IPsec deployments supporting only certificate authentication, a management station initiating an IPsec-protected telnet session to the RADIUS server would need to obtain a certificate chaining to the RADIUS client CA. Issuing such a certificate might not be appropriate if the management station was not authorized as a RADIUS client.
由于与SSL/TLS不同，IKE不允许基于每个端口设置证书策略，因此证书策略需要应用于RADIUS客户端和服务器上IPsec的所有使用。在仅支持证书身份验证的IPsec部署中，管理站启动到RADIUS服务器的受IPsec保护的telnet会话将需要获得到RADIUS客户端CA的证书链接。如果管理站未被授权为RADIUS客户端，则颁发此类证书可能不合适。
Where RADIUS clients may obtain their IP address dynamically (such as an Access Point supporting DHCP), IKE Main Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this requires use of a group
如果RADIUS客户端可以动态获取其IP地址（例如支持DHCP的接入点），则不应使用带有预共享密钥[RFC2409]的IKE主模式，因为这需要使用组
pre-shared key; instead, Aggressive Mode SHOULD be used. IKEv2, a work in progress, may address this issue in the future. Where RADIUS client addresses are statically assigned, either Aggressive Mode or Main Mode MAY be used. With certificate authentication, Main Mode SHOULD be used.
预共享密钥；相反，应该使用攻击性模式。IKEv2是一项正在进行的工作，将来可能会解决这个问题。在静态分配RADIUS客户端地址的情况下，可以使用主动模式或主模式。对于证书身份验证，应使用主模式。
Care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so that group pre-shared keys are still a practical necessity. As a result, the ID_FQDN identity payload SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. This approach also has other advantages, since it allows the RADIUS server and client to configure themselves based on the fully qualified domain name of their peers.
需要注意IKE阶段1身份有效负载选择，以便即使在攻击模式下也能将身份映射到预共享密钥。在使用ID_IPV4_ADDR或ID_IPV6_ADDR标识有效载荷并动态分配地址的情况下，不可能将标识映射到密钥，因此组预共享密钥仍然是实际需要的。因此，ID_FQDN标识有效负载应在主动模式与预共享密钥一起使用，并且动态分配IP地址的情况下使用。这种方法还有其他优点，因为它允许RADIUS服务器和客户端根据其对等方的完全限定域名进行自我配置。
Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so that RADIUS exchanges requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also advisable where quality of service considerations dictate different handling RADIUS conversations. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983].
请注意，对于IPsec，安全服务是在IPsec SA的粒度上协商的，因此需要一组不同于与现有IPsec SA协商的安全服务的RADIUS交换将需要协商一个新的IPsec SA。如果服务质量考虑因素要求不同的处理方式，也建议使用单独的IPsec SA。试图对同一IPsec SA处理的连接应用不同的服务质量可能会导致重新排序，并超出重播窗口。有关这些问题的讨论，请参见[RFC2983]。
This section provides more detail on the vulnerabilities identified in Section 4.1., and how they may be mitigated. Vulnerabilities include:
本节详细介绍了第4.1节中确定的漏洞，以及如何缓解这些漏洞。漏洞包括：
Privacy issues Spoofing and hijacking Dictionary attacks Known plaintext attacks Replay attacks Negotiation attacks Impersonation Man in the middle attacks Separation of authenticator and authentication server Multiple databases
隐私问题欺骗和劫持字典攻击已知明文攻击重放攻击协商攻击中间假冒人攻击认证服务器和认证服务器多个数据库的分离
Since RADIUS messages may contain the User-Name attribute as well as NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on RADIUS traffic may be able to determine the geographic location of peers in real time. In wireless networks, it is often assumed that RADIUS traffic is physically secure, since it typically travels over the wired network and that this limits the release of location information.
由于RADIUS消息可能包含用户名属性以及NAS IP地址或NAS标识符属性，因此窥探RADIUS流量的攻击者可能能够实时确定对等方的地理位置。在无线网络中，通常假设RADIUS流量在物理上是安全的，因为它通常通过有线网络传输，这限制了位置信息的发布。
However, it is possible for an authenticated attacker to spoof ARP packets [RFC826] so as to cause diversion of RADIUS traffic onto the wireless network. In this way an attacker may obtain RADIUS packets from which it can glean peer location information, or which it can subject to a known plaintext or offline dictionary attack. To address these vulnerabilities, implementations of this specification SHOULD use IPsec ESP with non-null transform and per-packet encryption, authentication, integrity and replay protection to protect both RADIUS authentication [RFC2865] and accounting [RFC2866] traffic, as described in Section 4.2.
但是，经过身份验证的攻击者有可能伪造ARP数据包[RFC826]，从而将RADIUS流量转移到无线网络上。通过这种方式，攻击者可以获得RADIUS数据包，从中可以收集对等位置信息，或者受到已知的明文或脱机字典攻击。为了解决这些漏洞，本规范的实施应使用IPsec ESP（具有非空转换和每包加密、身份验证、完整性和重播保护），以保护RADIUS身份验证[RFC2865]和记帐[RFC2866]流量，如第4.2节所述。
Access-Request packets with a User-Password attribute establish the identity of both the user and the NAS sending the Access-Request, because of the way the shared secret between the NAS and RADIUS server is used. Access-Request packets with CHAP-Password or EAP-Message attributes do not have a User-Password attribute. As a result, the Message-Authenticator attribute SHOULD be used in Access-Request packets that do not have a User-Password attribute, in order to establish the identity of the NAS sending the request.
具有用户密码属性的访问请求数据包建立发送访问请求的用户和NAS的身份，这是因为NAS和RADIUS服务器之间使用共享机密的方式不同。具有CHAP密码或EAP消息属性的访问请求数据包没有用户密码属性。因此，应该在没有用户密码属性的访问请求数据包中使用消息验证器属性，以便建立发送请求的NAS的标识。
An attacker may attempt to inject packets into the conversation between the NAS and the RADIUS server, or between the RADIUS server and the security server. RADIUS [RFC2865] does not support encryption other than attribute hiding. As described in [RFC2865], only Access-Reply and Access-Challenge packets are integrity protected. Moreover, the per-packet authentication and integrity protection mechanism described in [RFC2865] has known weaknesses [MD5Attack], making it a tempting target for attackers looking to subvert RADIUS/EAP.
攻击者可能试图将数据包注入NAS和RADIUS服务器之间的对话，或RADIUS服务器和安全服务器之间的对话。RADIUS[RFC2865]不支持除属性隐藏以外的加密。如[RFC2865]所述，只有访问应答和访问质询数据包受到完整性保护。此外，[RFC2865]中描述的每包身份验证和完整性保护机制存在已知的弱点[MD5Attack]，使其成为试图颠覆RADIUS/EAP的攻击者的诱人目标。
To provide stronger security, the Message-Authenticator attribute MUST be used in all RADIUS packets containing an EAP-Message attribute. Implementations of this specification SHOULD use IPsec ESP with non-null transform and per-packet encryption, authentication, integrity and replay protection, as described in Section 4.2.
为了提供更强的安全性，必须在包含EAP消息属性的所有RADIUS数据包中使用消息验证器属性。如第4.2节所述，本规范的实施应使用具有非空转换和每包加密、身份验证、完整性和重播保护的IPsec ESP。
The RADIUS shared secret is vulnerable to offline dictionary attack, based on capture of the Response Authenticator or Message-Authenticator attribute. In order to decrease the level of vulnerability, [RFC2865] recommends:
RADIUS共享机密易受脱机字典攻击，攻击基于响应验证器或消息验证器属性的捕获。为了降低漏洞级别，[RFC2865]建议：
The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. It is preferred that the secret be at least 16 octets.
密码（客户端和RADIUS服务器之间共享的密码）应至少与精心选择的密码一样大且不可用。最好秘密至少为16个八位字节。
The risk of an offline dictionary attack can be further reduced by employing IPsec ESP with non-null transform in order to encrypt the RADIUS conversation, as described in Section 4.2.
如第4.2节所述，通过使用带非空转换的IPsec ESP对RADIUS会话进行加密，可以进一步降低脱机字典攻击的风险。
Since EAP [RFC2284] does not support PAP, the RADIUS User-Password attribute is not used to carry hidden user passwords within RADIUS/EAP conversations. The User-Password hiding mechanism, defined in [RFC2865] utilizes MD5, defined in [RFC1321], in order to generate a key stream based on the RADIUS shared secret and the Request Authenticator. Where PAP is in use, it is possible to collect key streams corresponding to a given Request Authenticator value, by capturing RADIUS conversations corresponding to a PAP authentication attempt, using a known password. Since the User-Password is known, the key stream corresponding to a given Request Authenticator can be determined and stored.
由于EAP[RFC2284]不支持PAP，RADIUS用户密码属性不用于在RADIUS/EAP对话中携带隐藏的用户密码。[RFC2865]中定义的用户密码隐藏机制利用[RFC1321]中定义的MD5，以便基于RADIUS共享密钥和请求验证器生成密钥流。在使用PAP的情况下，可以通过使用已知密码捕获与PAP认证尝试相对应的RADIUS会话来收集与给定请求认证器值相对应的密钥流。由于用户密码是已知的，因此可以确定和存储与给定请求验证器对应的密钥流。
Since the key stream may have been determined previously from a known plaintext attack, if the Request Authenticator repeats, attributes encrypted using the RADIUS attribute hiding mechanism should be considered compromised. In addition to the User-Password attribute, which is not used with EAP, this includes attributes such as Tunnel-Password [RFC2868, section 3.5] and MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes [RFC2548, section 2.4], which include a Salt field as part of the hiding algorithm.
由于密钥流可能是先前根据已知明文攻击确定的，因此如果请求验证器重复，则使用RADIUS属性隐藏机制加密的属性应被视为已被破坏。除EAP未使用的用户密码属性外，还包括隧道密码[RFC2868，第3.5节]和MS MPPE发送密钥和MS MPPE Recv密钥属性[RFC2548，第2.4节]等属性，这些属性包括作为隐藏算法一部分的盐场。
To avoid this, [RFC2865], Section 3 advises:
为了避免这种情况，[RFC2865]，第3节建议：
Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness.
由于预期相同的秘密可用于对不同地理区域中的服务器进行身份验证，因此请求验证器字段应显示全局唯一性和时间唯一性。
Where the Request Authenticator repeats, the Salt field defined in [RFC2548], Section 2.4 does not provide protection against compromise. This is because MD5 [RFC1321], rather than HMAC-MD5 [RFC2104], is used to generate the key stream, which is calculated from the 128-bit RADIUS shared secret (S), the 128-bit Request Authenticator (R), and the Salt field (A), using the formula b(1) = MD5(S + R + A). Since the Salt field is placed at the end, if the Request Authenticator were to repeat on a network where PAP is in use, then the salted keystream could be calculated from the User-Password keystream by continuing the MD5 calculation based on the Salt field (A), which is sent in the clear.
当请求验证器重复时，[RFC2548]第2.4节中定义的盐场不提供防止泄露的保护。这是因为MD5[RFC1321]而不是HMAC-MD5[RFC2104]用于生成密钥流，该密钥流使用公式b（1）=MD5（S+R+A）从128位半径共享秘密、128位请求验证器（R）和盐域（A）计算而来。由于Salt字段位于末尾，如果请求验证器要在使用PAP的网络上重复，则可以通过基于Salt字段（a）继续MD5计算来从用户密码密钥流计算Salt密钥流，该字段（a）以明文形式发送。
Even though EAP does not support PAP authentication, a security vulnerability can still exist where the same RADIUS shared secret is used for hiding User-Password as well as other attributes. This can occur, for example, if the same RADIUS proxy handles authentication requests for both EAP and PAP.
即使EAP不支持PAP身份验证，如果使用相同的RADIUS共享密钥隐藏用户密码以及其他属性，则仍然可能存在安全漏洞。例如，如果同一RADIUS代理同时处理EAP和PAP的身份验证请求，则可能发生这种情况。
The threat can be mitigated by protecting RADIUS with IPsec ESP with non-null transform, as described in Section 4.2. Where RADIUS shared secrets are configured, the RADIUS shared secret used by a NAS supporting EAP MUST NOT be reused by a NAS utilizing the User-Password attribute, since improper shared secret hygiene could lead to compromise of hidden attributes.
如第4.2节所述，可以通过使用IPsec ESP和非空转换保护RADIUS来缓解威胁。在配置RADIUS共享机密的情况下，支持EAP的NAS使用的RADIUS共享机密不得由使用用户密码属性的NAS重复使用，因为不正确的共享机密卫生可能会导致隐藏属性受损。
The RADIUS protocol provides only limited support for replay protection. RADIUS Access-Requests include liveness via the 128-bit Request Authenticator. However, the Request Authenticator is not a replay counter. Since RADIUS servers may not maintain a cache of previous Request Authenticators, the Request Authenticator does not provide replay protection.
RADIUS协议仅提供有限的重播保护支持。RADIUS访问请求包括通过128位请求验证器的活动性。但是，请求验证器不是重播计数器。由于RADIUS服务器可能不会维护以前请求验证器的缓存，因此请求验证器不提供重播保护。
RADIUS accounting [RFC2866] does not support replay protection at the protocol level. Due to the need to support failover between RADIUS accounting servers, protocol-based replay protection is not sufficient to prevent duplicate accounting records. However, once accepted by the accounting server, duplicate accounting records can be detected by use of the the Acct-Session-Id [RFC2866, section 5.5] and Event-Timestamp [RFC2869, section 5.3] attributes.
RADIUS记帐[RFC2866]不支持协议级别的重播保护。由于需要支持RADIUS记帐服务器之间的故障切换，基于协议的重播保护不足以防止重复记帐记录。然而，一旦被记帐服务器接受，就可以使用Acct会话Id[RFC2866，第5.5节]和事件时间戳[RFC2869，第5.3节]属性来检测重复的记帐记录。
Unlike RADIUS authentication, RADIUS accounting does not use the Request Authenticator as a nonce. Instead, the Request Authenticator contains an MD5 hash calculated over the Code, Identifier, Length, and request attributes of the Accounting Request packet, plus the shared secret. The Response Authenticator also contains an MD5 hash calculated over the Code, Identifier and Length, the Request
与RADIUS身份验证不同，RADIUS accounting不将请求身份验证程序用作nonce。相反，请求验证器包含一个MD5散列，该散列是根据记帐请求数据包的代码、标识符、长度和请求属性以及共享机密计算的。响应验证器还包含一个MD5散列，该散列根据请求的代码、标识符和长度进行计算
Authenticator field from the Accounting-Request packet being replied to, the response attributes and the shared secret.
正在应答的记帐请求数据包中的Authenticator字段、响应属性和共享机密。
Since the Accounting Response Authenticator depends in part on the Accounting Request Authenticator, it is not possible to replay an Accounting-Response unless the Request Authenticator repeats. While it is possible to utilize EAP methods such as EAP TLS [RFC2716] which include liveness checks on both sides, not all EAP messages will include liveness so that this provides incomplete protection.
由于记帐响应验证器部分依赖于记帐请求验证器，因此除非请求验证器重复，否则无法重播记帐响应。虽然可以使用EAP方法，如EAP TLS[RFC2716]，在两侧都包括活动性检查，但并非所有EAP消息都将包括活动性，因此这提供了不完整的保护。
Strong replay protection for RADIUS authentication and accounting can be provided by enabling IPsec replay protection with RADIUS, as described in Section 4.2.
通过使用RADIUS启用IPsec重播保护，可以为RADIUS身份验证和记帐提供强大的重播保护，如第4.2节所述。
In a negotiation attack a rogue NAS, tunnel server, RADIUS proxy or RADIUS server attempts to cause the authenticating peer to choose a less secure authentication method. For example, a session that would normally be authenticated with EAP would instead be authenticated via CHAP or PAP; alternatively, a connection that would normally be authenticated via a more secure EAP method such as EAP-TLS [RFC2716] might be made to occur via a less secure EAP method, such as MD5-Challenge. 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 [Masters].
在协商攻击中，流氓NAS、隧道服务器、RADIUS代理或RADIUS服务器试图使身份验证对等方选择不太安全的身份验证方法。例如，通常使用EAP进行身份验证的会话将改为通过CHAP或PAP进行身份验证；或者，通常通过更安全的EAP方法（如EAP-TLS[RFC2716]）进行身份验证的连接可以通过更不安全的EAP方法（如MD5质询）进行。曾经被认为是远程的流氓设备所造成的威胁，由于电话公司交换系统的妥协，如[Masters]中所述，已经变得普遍。
Protection against negotiation attacks requires the elimination of downward negotiations. The RADIUS exchange may be further protected by use of IPsec, as described in Section 4.2. Alternatively, where IPsec is not used, the vulnerability can be mitigated via implementation of per-connection policy on the part of the authenticating peer, and per-peer policy on the part of the RADIUS server. For the authenticating peer, authentication policy should be set on a per-connection basis. Per-connection policy allows an authenticating peer to negotiate a strong EAP method when connecting to one service, while negotiating a weaker EAP method for another service.
防止谈判攻击需要消除向下谈判。如第4.2节所述，可以使用IPsec进一步保护RADIUS交换。或者，在未使用IPsec的情况下，可以通过在身份验证对等方上实施每个连接策略和在RADIUS服务器上实施每个对等方策略来缓解该漏洞。对于身份验证对等方，应基于每个连接设置身份验证策略。每连接策略允许身份验证对等方在连接到一个服务时协商强EAP方法，同时协商另一个服务的弱EAP方法。
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
对于每连接策略，身份验证对等方将仅尝试为预期EAP支持的会话协商EAP。因此，假设选择EAP的认证对等方需要该安全级别。如果无法提供，则可能存在某种配置错误，甚至验证对等方正在联系错误的服务器。如果NAS无法协商EAP，或者如果NAS发送的EAP请求与预期的EAP类型不同，则验证对等方必须断开连接。鉴定人
peer expecting EAP to be negotiated for a session MUST NOT negotiate a weaker method, such as CHAP or PAP. In wireless networks, the service advertisement itself may be spoof-able, so that an attacker could fool the peer into negotiating an authentication method suitable for a less secure network.
期望为会话协商EAP的对等方不得协商较弱的方法，如CHAP或PAP。在无线网络中，服务广告本身可能是可欺骗的，因此攻击者可以欺骗对等方协商适合于不太安全的网络的身份验证方法。
For a NAS, it may not be possible to determine whether a peer is required to authenticate with EAP until the peer's identity is known. For example, for shared-uses NASes it is possible for one reseller to implement EAP while another does not. Alternatively, some peer might be authenticated locally by the NAS while other peers are authenticated via RADIUS. In such cases, if any peers of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every session. This avoids forcing a peer to support more than one authentication type, which could weaken security.
对于NAS，在知道对等方的身份之前，可能无法确定是否需要对等方向EAP进行身份验证。例如，对于共享使用NASE，一个分销商可以实施EAP，而另一个分销商则不实施EAP。或者，某些对等方可以由NAS在本地进行身份验证，而其他对等方则通过RADIUS进行身份验证。在这种情况下，如果NAS的任何对等方必须执行EAP，则NAS必须尝试为每个会话协商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 peer 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 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.
如果协商CHAP，NAS将在访问请求数据包中将用户名和CHAP密码属性传递给RADIUS服务器。如果对等方不需要使用EAP，则RADIUS服务器将根据需要使用访问接受或访问拒绝数据包进行响应。但是，如果已协商CHAP，但需要EAP，RADIUS服务器必须以访问拒绝响应，而不是访问质询/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, a PPP NAS MUST send an LCP-Terminate and disconnect the peer. 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 peer connecting from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same peer connecting at another location (and encountering an EAP-incapable proxy) might be consistently disconnected.
如果EAP已协商，但RADIUS代理或服务器不支持，则服务器或代理必须以访问拒绝响应。在这些情况下，PPP NAS必须发送LCP终止并断开对等方的连接。这是正确的行为，因为身份验证对等方期望协商EAP，而该期望无法实现。如果最初协商了EAP，则具有EAP能力的认证对等方必须拒绝重新协商认证协议。请注意，不支持EAP的RADIUS代理的问题可能很难诊断，因为从一个位置连接的对等方（使用支持EAP的代理）可能能够通过EAP成功进行身份验证，而在另一个位置连接的同一对等方（遇到不支持EAP的代理）可能会持续断开连接。
[RFC2865] Section 3 states:
[RFC2865]第3节规定：
A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.
RADIUS服务器必须使用RADIUS UDP数据包的源IP地址来决定使用哪个共享密钥，以便可以代理RADIUS请求。
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address attributes may not match the source address. Since the NAS-Identifier attribute need not contain an FQDN, this attribute also may not correspond to the source address, even indirectly, with or without a proxy present.
当RADIUS请求由代理转发时，NAS IP地址或NAS-IPv6-Address属性可能与源地址不匹配。由于NAS标识符属性不需要包含FQDN，因此无论是否存在代理，此属性也可能与源地址不对应，即使是间接的。
As a result, the authenticity check performed by a RADIUS server or proxy does not verify the correctness of NAS identification attributes. This makes it possible for a rogue NAS to forge NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within a RADIUS Access-Request in order to impersonate another NAS. It is also possible for a rogue NAS to forge session identification attributes such as Called-Station-Id, Calling-Station-Id, and Originating-Line-Info.
因此，RADIUS服务器或代理执行的真实性检查不会验证NAS标识属性的正确性。这使得流氓NAS可以在RADIUS访问请求中伪造NAS IP地址、NAS-IPv6-Address或NAS标识符属性，以模拟另一个NAS。流氓NAS也可能伪造会话标识属性，如被叫站Id、主叫站Id和始发线路信息。
This could fool the RADIUS server into subsequently sending Disconnect or CoA-Request messages [RFC3576] containing forged session identification attributes to a NAS targeted by an attacker.
这可能会欺骗RADIUS服务器，使其随后将包含伪造会话标识属性的断开连接或CoA请求消息[RFC3576]发送到攻击者所针对的NAS。
To address these vulnerabilities RADIUS proxies SHOULD check whether NAS identification attributes (NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier) match the source address of packets originating from the NAS. Where a match is not found, an Access-Reject SHOULD be sent, and an error SHOULD be logged.
要解决这些漏洞，RADIUS代理应检查NAS标识属性（NAS IP地址、NAS-IPv6-address、NAS标识符）是否与源自NAS的数据包的源地址匹配。如果未找到匹配项，则应发送访问拒绝，并记录错误。
However, such a check may not always be possible. Since the NAS-Identifier attribute need not correspond to an FQDN, it may not be resolvable to an IP address to be matched against the source address. Also, where a NAT exists between the RADIUS client and proxy, checking the NAS-IP-Address or NAS-IPv6-Address attributes may not be feasible.
然而，这种检查可能并不总是可能的。由于NAS标识符属性不需要对应于FQDN，因此它可能无法解析为要与源地址匹配的IP地址。此外，如果RADIUS客户端和代理之间存在NAT，则检查NAS IP地址或NAS-IPv6-Address属性可能不可行。
To allow verification of NAS and session identification parameters,
EAP methods can support the secure exchange of these parameters
between the EAP peer and EAP server. NAS identification attributes
include NAS-IP-Address, NAS-IPv6-Address and Called-Station-Id;
session identification attributes include User-Name and
Calling-Station-Id. The secure exchange of these parameters between
the EAP peer and server enables the RADIUS server to check whether
the attributes provided by the NAS match those provided by the peer;
similarly, the peer can check the parameters provided by the NAS
against those provided by the EAP server. This enables detection of
a rogue NAS.
To allow verification of NAS and session identification parameters,
EAP methods can support the secure exchange of these parameters
between the EAP peer and EAP server. NAS identification attributes
include NAS-IP-Address, NAS-IPv6-Address and Called-Station-Id;
session identification attributes include User-Name and
Calling-Station-Id. The secure exchange of these parameters between
the EAP peer and server enables the RADIUS server to check whether
the attributes provided by the NAS match those provided by the peer;
similarly, the peer can check the parameters provided by the NAS
against those provided by the EAP server. This enables detection of
a rogue NAS.
RADIUS only provides security on a hop-by-hop basis, even where IPsec is used. As a result, an attacker gaining control of a RADIUS proxy could attempt to modify EAP packets in transit. To protect against this, EAP methods SHOULD incorporate their own per-packet integrity protection and authentication mechanisms.
RADIUS仅在逐跳的基础上提供安全性，即使在使用IPsec的情况下也是如此。因此，获得RADIUS代理控制权的攻击者可能会试图修改传输中的EAP数据包。为了防止这种情况发生，EAP方法应该包含它们自己的每包完整性保护和身份验证机制。
As noted in [RFC2716], it is possible for the EAP peer and authenticator to mutually authenticate, and derive a Master Session Key (MSK) for a ciphersuite used to protect subsequent data traffic. 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 derive and pass a Transient Session Key (TSK) to the ciphersuite module.
如[RFC2716]所述，EAP对等方和认证方可以相互认证，并为用于保护后续数据流量的密码套件派生主会话密钥（MSK）。这不会在对等机上出现问题，因为对等机和EAP客户端位于同一台机器上；EAP客户端模块只需派生一个临时会话密钥（TSK）并将其传递给ciphersuite模块。
The situation is more complex when EAP is used with RADIUS, since the authenticator and authentication server may not reside on the same host.
当EAP与RADIUS一起使用时，情况更加复杂，因为身份验证程序和身份验证服务器可能不在同一台主机上。
In the case where the authenticator and authentication server reside on different machines, there are several implications for security. First, mutual authentication will occur between the peer and the authentication 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, using EAP alone.
在身份验证程序和身份验证服务器位于不同机器上的情况下，存在几个安全问题。首先，相互身份验证将发生在对等方和身份验证服务器之间，而不是对等方和身份验证程序之间。这意味着，对等方不可能单独使用EAP来验证与之对话的NAS或隧道服务器的身份。
As described in Section 4.2, when RADIUS/EAP is used to encapsulate EAP packets, IPsec SHOULD be used to provide per-packet authentication, integrity, replay protection and confidentiality. The Message-Authenticator attribute is also required in RADIUS Access-Requests containing an EAP-Message attribute sent from the NAS or tunnel server to the RADIUS server. Since the Message-Authenticator attribute involves an HMAC-MD5 message integrity check, 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, even where IPsec is not used. Similarly, Access-Challenge packets containing an EAP-Message attribute sent from the RADIUS server to the NAS are also authenticated and integrity protected using an HMAC-MD5 message integrity check, enabling the NAS or tunnel server to determine the integrity of the packet and verify the identity of the RADIUS server, even where IPsec is not used. Moreover, EAP packets sent using methods that contain their own integrity protection cannot be successfully modified by a rogue NAS or tunnel server.
如第4.2节所述，当RADIUS/EAP用于封装EAP数据包时，应使用IPsec来提供每个数据包的身份验证、完整性、重播保护和机密性。在包含从NAS或隧道服务器发送到RADIUS服务器的EAP消息属性的RADIUS访问请求中，还需要消息验证器属性。由于Message Authenticator属性涉及HMAC-MD5消息完整性检查，因此RADIUS服务器可以验证访问请求的完整性以及NAS或隧道服务器的身份，即使在未使用IPsec的情况下也是如此。类似地，包含从RADIUS服务器发送到NAS的EAP消息属性的访问质询数据包也使用HMAC-MD5消息完整性检查进行身份验证和完整性保护，从而使NAS或隧道服务器能够确定数据包的完整性并验证RADIUS服务器的身份，即使未使用IPsec。此外，恶意NAS或隧道服务器无法成功修改使用包含自身完整性保护的方法发送的EAP数据包。
The second issue that arises where the authenticator and authentication server reside on separate hosts is that the EAP Master Session Key (MSK) negotiated between the peer and authentication server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the MSK from the authentication server to the NAS or tunnel server that needs it. The specification of the key transport and wrapping mechanism is outside the scope of this document. However, it is expected that the wrapping mechanism will provide confidentiality, integrity and replay protection, and data origin authentication.
当认证器和认证服务器位于不同的主机上时，出现的第二个问题是，对等方和认证服务器之间协商的EAP主会话密钥（MSK）将需要传输到认证器。因此，需要提供一种机制，将MSK从身份验证服务器传输到需要它的NAS或隧道服务器。密钥传输和包装机制的规范不在本文件范围内。但是，包装机制将提供机密性、完整性和重播保护以及数据源身份验证。
In many cases a security server will be deployed along with a RADIUS server in order to provide EAP services. Unless the 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 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 security server store information in the same database; by having the security server provide a full RADIUS implementation; or by consolidating both the security server and the RADIUS server onto the same machine.
为了应对这些威胁，建议整合数据库。这可以通过让RADIUS服务器和安全服务器在同一数据库中存储信息来实现；通过让安全服务器提供完整的RADIUS实现；或者将安全服务器和RADIUS服务器整合到同一台计算机上。
This specification does not create any new registries, or define any new RADIUS attributes or values.
本规范不创建任何新的注册表，也不定义任何新的RADIUS属性或值。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284]Blunk，L.和J.Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Atkinson，R.和S.Kent，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486]Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“半径和IP6”，RFC 3162，2001年8月。
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3576]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 35762003年7月。
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982.
[RFC826]Plummer，D.，“以太网地址解析协议”，STD 37，RFC 826，1982年11月。
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]Zorn，G.，“微软特定于供应商的半径属性”，RFC 2548，1999年3月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607]Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[RFC2716] Aboba, B. and D. Simon,"PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716]Aboba，B.和D.Simon，“PPP EAP TLS认证协议”，RFC 2716，1999年10月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月。
[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867]Zorn，G.，Aboba，B.和D.Mitton，“隧道协议支持的半径计算修改”，RFC 28672000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.和I.Goyret，“隧道协议支持的半径属性”，RFC 28682000年6月。
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869]Rigney，C.，Willats，W.和P.Calhoun，“半径延伸”，RFC 2869，2000年6月。
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.“差异化服务和隧道”，RFC 29832000年10月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580]Congdon，P.，Aboba，B.，Smith，A.，Zorn，G.和J.Roese，“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”，RFC 35802003年9月。
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE802]局域网和城域网的IEEE标准：概述和体系结构，ANSI/IEEE标准802，1990年。
[IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001.
[IEEE8021X]IEEE局域网和城域网标准：基于端口的网络访问控制，IEEE标准802.1X-2001，2001年6月。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack]Dobbertin，H.，“最近一次攻击后MD5的状态”，CryptoBytes第2卷第2期，1996年夏季。
[Masters] Slatalla, M. and J. Quittner, "Masters of Deception." HarperCollins, New York, 1995.
[大师]斯拉塔拉，M.和J.奎特纳，“欺骗大师”，哈珀柯林斯，纽约，1995年。
[NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", Work in Progress.
[NASREQ]Calhoun，P.等人，“Diameter网络访问服务器应用程序”，正在进行中。
Appendix A - Examples
附录A-示例
The examples below illustrate conversations between an authenticating peer, NAS, and RADIUS server. The OTP and EAP-TLS protocols are used only for illustrative purposes; other authentication protocols could also have been used, although they might show somewhat different behavior.
下面的示例演示了身份验证对等方、NAS和RADIUS服务器之间的对话。OTP和EAP-TLS协议仅用于说明目的；也可以使用其他身份验证协议，尽管它们可能表现出一些不同的行为。
Where the NAS sends an EAP-Request/Identity as the initial packet, the exchange appears as follows:
当NAS发送EAP请求/标识作为初始数据包时，交换显示如下：
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
In the case where the NAS initiates with an EAP-Request for EAP TLS [RFC2716], and the identity is determined based on the contents of the client certificate, the exchange will appear as follows:
如果NAS通过EAP TLS[RFC2716]的EAP请求发起，并且根据客户端证书的内容确定身份，则交换将显示如下：
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Challenge/
EAP-Message/
EAP-Request/
EAP-Type=EAP-TLS
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Challenge/
EAP-Message/
EAP-Request/
EAP-Type=EAP-TLS
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Challenge/
EAP-Message/
EAP-Request/
EAP-Type=EAP-TLS
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Challenge/
EAP-Message/
EAP-Request/
EAP-Type=EAP-TLS
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
EAP-Response/
EAP-Type=EAP-TLS ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
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
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Identity (MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Identity (MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
In the case where the NAS initiates with an EAP-Request for EAP TLS [RFC2716], but the peer responds with a Nak, indicating that it would prefer another method not implemented locally on the NAS, the exchange will appear as follows:
如果NAS通过EAP TLS[RFC2716]的EAP请求发起，但对等方以Nak响应，表明它更希望另一种方法不在NAS上本地实现，则交换将显示如下：
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=Nak
(Alternative(s))->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Nak ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=Nak
(Alternative(s))->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Nak ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-Success
In the case where the authenticating peer attempts to authenticate the NAS, the conversation would appear as follows:
在身份验证对等方尝试对NAS进行身份验证的情况下，对话将如下所示：
Authenticating peer NAS RADIUS Server
------------------- --- -------------
EAP-Request/
Challenge, MD5 ->
RADIUS Access-Request/
EAP-Message/EAP-Request/
Challenge, MD5 ->
<- RADIUS
Access-Reject/
EAP-Message/
EAP-Response/
Nak (no alternative)
Authenticating peer NAS RADIUS Server
------------------- --- -------------
EAP-Request/
Challenge, MD5 ->
RADIUS Access-Request/
EAP-Message/EAP-Request/
Challenge, MD5 ->
<- RADIUS
Access-Reject/
EAP-Message/
EAP-Response/
Nak (no alternative)
<- EAP-Response/Nak (no alternative) EAP-Failure ->
<-EAP响应/Nak（无替代方案）EAP故障->
In the case where an invalid EAP Response is inserted by an attacker, the conversation would appear as follows:
在攻击者插入无效EAP响应的情况下，对话将显示如下：
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=Foo
EAP-Response/
EAP-Type=Foo ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Foo ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
EAP-Type=Foo
<- EAP-Request/
EAP-Type=Foo
Attacker spoof:
EAP-Response/
EAP-Type=Bar ->
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=Foo
EAP-Response/
EAP-Type=Foo ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Foo ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
EAP-Type=Foo
<- EAP-Request/
EAP-Type=Foo
Attacker spoof:
EAP-Response/
EAP-Type=Bar ->
Good guy:
EAP-Response/
EAP-Type=Foo ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Bar ->
Good guy:
EAP-Response/
EAP-Type=Foo ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Bar ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
EAP-Type=Foo,
Error-Cause="Invalid EAP
Packet (Ignored)"
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Foo ->
<- Access-Accept/
EAP-Message/Success
<- EAP Success
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
EAP-Type=Foo,
Error-Cause="Invalid EAP
Packet (Ignored)"
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Foo ->
<- Access-Accept/
EAP-Message/Success
<- EAP Success
In the case where the client fails EAP authentication, and an error message is sent prior to disconnection, the conversation would appear as follows:
如果客户端未能通过EAP身份验证，并且在断开连接之前发送了错误消息，则对话将显示如下：
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Response/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Notification
<- EAP-Request/
Notification
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Response/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Notification
<- EAP-Request/
Notification
EAP-Response/
Notification ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Notification ->
<- RADIUS
Access-Reject/
EAP-Message/EAP-Failure
<- EAP-Failure
(client disconnected)
EAP-Response/
Notification ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Notification ->
<- RADIUS
Access-Reject/
EAP-Message/EAP-Failure
<- EAP-Failure
(client disconnected)
In the case that the RADIUS server or proxy does not support EAP-Message, but no error message is sent, the conversation would appear as follows:
如果RADIUS服务器或代理不支持EAP消息，但未发送错误消息，则对话将显示如下：
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Reject
(User Disconnected)
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Reject
(User Disconnected)
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
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/
EAP-Response/
Identity
<- EAP-Request/
Identity
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/
EAP-Response/
Identity
<- EAP-Request/
Identity
EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Reject (proxied from remote RADIUS server) (User Disconnected)
EAP响应/标识（MyID）->RADIUS访问请求/EAP消息/EAP响应/（MyID）-><-RADIUS访问拒绝（由远程RADIUS服务器代理）（用户断开连接）
In the case where PPP is the link and the authenticating peer does not support EAP, but where EAP is required for that user, the conversation would appear as follows:
如果PPP是链路，且认证对等方不支持EAP，但该用户需要EAP，则对话将如下所示：
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)
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)
In the case where PPP is the link, the NAS does not support EAP, but where EAP is required for that user, the conversation would appear as follows:
在PPP是链路的情况下，NAS不支持EAP，但如果该用户需要EAP，则对话将显示如下：
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- PPP LCP Request-CHAP
auth
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- PPP LCP Request-CHAP
auth
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终止（用户断开连接）
Appendix B - Change Log
附录B-变更日志
The following changes have been made from RFC 2869:
对RFC 2869进行了以下更改：
A NAS may simultaneously support both local authentication and pass-through; once the NAS enters pass-through mode within a session, it cannot revert back to local authentication. Also EAP is explicitly described as a 'lock step' protocol. (Section 2).
NAS可以同时支持本地身份验证和直通；一旦NAS在会话中进入直通模式，它就无法恢复到本地身份验证。此外，EAP被明确描述为“锁定步骤”协议。（第2节）。
The NAS may initiate with an EAP-Request for an authentication Type. If the Request is NAK'd, the NAS should send an initial Access-Request with an EAP-Message attribute containing an EAP-Response/Nak.
NAS可通过EAP认证类型请求发起。如果请求为NAK'd，NAS应发送一个初始访问请求，其EAP消息属性包含EAP响应/NAK。
The RADIUS server may treat an invalid EAP Response as a non-fatal error (Section 2.2)
RADIUS服务器可将无效EAP响应视为非致命错误（第2.2节）
For use with RADIUS/EAP, the Password-Retry (Section 2.3) and Reply-Message (2.6.5) attributes are deprecated.
对于RADIUS/EAP，不推荐使用密码重试（第2.3节）和回复消息（第2.6.5节）属性。
Each EAP session has a unique Identifier space (Section 2.6.1).
每个EAP会话都有一个唯一的标识符空间（第2.6.1节）。
Role reversal is not supported (Section 2.6.2).
不支持角色转换（第2.6.2节）。
Message combinations (e.g. Access-Accept/EAP-Failure) that conflict are discouraged (Section 2.6.3).
不鼓励出现冲突的消息组合（如访问接受/EAP失败）（第2.6.3节）。
Only a single EAP packet may be encapsulated within a RADIUS message (Section 3.1).
RADIUS消息中只能封装一个EAP数据包（第3.1节）。
An Access-Request lacking explicit authentication as well as a Message- Authenticator attribute SHOULD be silently discarded (Section 3.3).
缺少显式身份验证以及消息验证器属性的访问请求应该被静默地丢弃（第3.3节）。
The Originating-Line-Info attribute is supported (Section 3.3).
支持原始线路信息属性（第3.3节）。
IPsec ESP with non-null transform SHOULD be used and the usage model is described in detail (Section 4.2).
应使用带非空转换的IPsec ESP，并详细描述使用模型（第4.2节）。
Additional discussion of security vulnerabilities (Section 4.1) and potential fixes (Section 4.3).
关于安全漏洞（第4.1节）和潜在修复（第4.3节）的补充讨论。
Separated normative (Section 6.1) and informative (Section 6.2) references.
单独的规范性（第6.1节）和信息性（第6.2节）参考文件。
Added additional examples (Appendix A): a NAS initiating with an EAP-Request for an authentication Type; attempted role reversal.
添加了其他示例（附录A）：NAS通过认证类型的EAP请求启动；尝试角色转换。
Intellectual Property Statement
知识产权声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Acknowledgments
致谢
Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco Systems, Jari Arkko of Ericsson and Ashwin Palekar, Tim Moore and Narendra Gidwani of Microsoft for useful discussions of this problem space. The authors would also like to acknowledge Tony Jeffree, Chair of IEEE 802.1 for his assistance in resolving RADIUS/EAP issues in IEEE 802.1X-2001.
感谢Ascend的Dave Dawson和Karl Fox、Cisco Systems的Glen Zorn、爱立信的Jari Arkko和微软的Ashwin Palekar、Tim Moore和Narendra Gidwani对这个问题空间进行了有益的讨论。作者还想感谢IEEE 802.1主席Tony Jeffree在解决IEEE 802.1X-2001中的RADIUS/EAP问题方面提供的帮助。
Authors' Addresses
作者地址
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Pat R. Calhoun Airespace 110 Nortech Parkway San Jose, California, 95134 USA
Pat R.Calhoun Airespace 110 Nortech Parkway圣何塞，加利福尼亚州，95134美国
Phone: +1 408 635 2023
Fax: +1 408 635 2020
EMail: pcalhoun@airespace.com
Phone: +1 408 635 2023
Fax: +1 408 635 2020
EMail: pcalhoun@airespace.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。