Network Working Group P. Congdon
Request for Comments: 3580 Hewlett Packard Company
Category: Informational B. Aboba
Microsoft
A. Smith
Trapeze Networks
G. Zorn
Cisco Systems
J. Roese
Enterasys
September 2003
Network Working Group P. Congdon
Request for Comments: 3580 Hewlett Packard Company
Category: Informational B. Aboba
Microsoft
A. Smith
Trapeze Networks
G. Zorn
Cisco Systems
J. Roese
Enterasys
September 2003
IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines
IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南
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 provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes.
本文档提供了有关IEEE 802.1X认证者使用远程认证拨入用户服务（RADIUS）的建议。本文件中的材料也包含在IEEE 802.1X规范的非规范性附录中，并作为IETF RFC提供，以供参考。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language. . . . . . . . . . . . . . . . . . 4
2. RADIUS Accounting Attributes . . . . . . . . . . . . . . . . . 5
2.1. Acct-Terminate-Cause . . . . . . . . . . . . . . . . . . 5
2.2. Acct-Multi-Session-Id. . . . . . . . . . . . . . . . . . 6
2.3. Acct-Link-Count. . . . . . . . . . . . . . . . . . . . . 7
3. RADIUS Authentication. . . . . . . . . . . . . . . . . . . . . 7
3.1. User-Name. . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. User-Password, CHAP-Password, CHAP-Challenge . . . . . . 8
3.3. NAS-IP-Address, NAS-IPv6-Address . . . . . . . . . . . . 8
3.4. NAS-Port . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Service-Type . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Framed-Protocol. . . . . . . . . . . . . . . . . . . . . 9
3.7. Framed-IP-Address, Framed-IP-Netmask . . . . . . . . . . 9
3.8. Framed-Routing . . . . . . . . . . . . . . . . . . . . . 9
3.9. Filter-ID. . . . . . . . . . . . . . . . . . . . . . . . 9
3.10. Framed-MTU . . . . . . . . . . . . . . . . . . . . . . . 9
3.11. Framed-Compression . . . . . . . . . . . . . . . . . . . 10
3.12. Displayable Messages . . . . . . . . . . . . . . . . . . 10
3.13. Callback-Number, Callback-ID . . . . . . . . . . . . . . 10
3.14. Framed-Route, Framed-IPv6-Route. . . . . . . . . . . . . 11
3.15. State, Class, Proxy-State. . . . . . . . . . . . . . . . 11
3.16. Vendor-Specific. . . . . . . . . . . . . . . . . . . . . 11
3.17. Session-Timeout. . . . . . . . . . . . . . . . . . . . . 11
3.18. Idle-Timeout . . . . . . . . . . . . . . . . . . . . . . 12
3.19. Termination-Action . . . . . . . . . . . . . . . . . . . 12
3.20. Called-Station-Id. . . . . . . . . . . . . . . . . . . . 12
3.21. Calling-Station-Id . . . . . . . . . . . . . . . . . . . 12
3.22. NAS-Identifier . . . . . . . . . . . . . . . . . . . . . 12
3.23. NAS-Port-Type. . . . . . . . . . . . . . . . . . . . . . 12
3.24. Port-Limit . . . . . . . . . . . . . . . . . . . . . . . 13
3.25. Password-Retry . . . . . . . . . . . . . . . . . . . . . 13
3.26. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 13
3.27. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 13
3.28. Message-Authenticator. . . . . . . . . . . . . . . . . . 13
3.29. NAS-Port-Id. . . . . . . . . . . . . . . . . . . . . . . 13
3.30. Framed-Pool, Framed-IPv6-Pool. . . . . . . . . . . . . . 14
3.31. Tunnel Attributes. . . . . . . . . . . . . . . . . . . . 14
4. RC4 EAPOL-Key Descriptor . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
5.1. Packet Modification or Forgery . . . . . . . . . . . . . 18
5.2. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 19
5.3. Known Plaintext Attacks. . . . . . . . . . . . . . . . . 19
5.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5. Outcome Mismatches . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language. . . . . . . . . . . . . . . . . . 4
2. RADIUS Accounting Attributes . . . . . . . . . . . . . . . . . 5
2.1. Acct-Terminate-Cause . . . . . . . . . . . . . . . . . . 5
2.2. Acct-Multi-Session-Id. . . . . . . . . . . . . . . . . . 6
2.3. Acct-Link-Count. . . . . . . . . . . . . . . . . . . . . 7
3. RADIUS Authentication. . . . . . . . . . . . . . . . . . . . . 7
3.1. User-Name. . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. User-Password, CHAP-Password, CHAP-Challenge . . . . . . 8
3.3. NAS-IP-Address, NAS-IPv6-Address . . . . . . . . . . . . 8
3.4. NAS-Port . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Service-Type . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Framed-Protocol. . . . . . . . . . . . . . . . . . . . . 9
3.7. Framed-IP-Address, Framed-IP-Netmask . . . . . . . . . . 9
3.8. Framed-Routing . . . . . . . . . . . . . . . . . . . . . 9
3.9. Filter-ID. . . . . . . . . . . . . . . . . . . . . . . . 9
3.10. Framed-MTU . . . . . . . . . . . . . . . . . . . . . . . 9
3.11. Framed-Compression . . . . . . . . . . . . . . . . . . . 10
3.12. Displayable Messages . . . . . . . . . . . . . . . . . . 10
3.13. Callback-Number, Callback-ID . . . . . . . . . . . . . . 10
3.14. Framed-Route, Framed-IPv6-Route. . . . . . . . . . . . . 11
3.15. State, Class, Proxy-State. . . . . . . . . . . . . . . . 11
3.16. Vendor-Specific. . . . . . . . . . . . . . . . . . . . . 11
3.17. Session-Timeout. . . . . . . . . . . . . . . . . . . . . 11
3.18. Idle-Timeout . . . . . . . . . . . . . . . . . . . . . . 12
3.19. Termination-Action . . . . . . . . . . . . . . . . . . . 12
3.20. Called-Station-Id. . . . . . . . . . . . . . . . . . . . 12
3.21. Calling-Station-Id . . . . . . . . . . . . . . . . . . . 12
3.22. NAS-Identifier . . . . . . . . . . . . . . . . . . . . . 12
3.23. NAS-Port-Type. . . . . . . . . . . . . . . . . . . . . . 12
3.24. Port-Limit . . . . . . . . . . . . . . . . . . . . . . . 13
3.25. Password-Retry . . . . . . . . . . . . . . . . . . . . . 13
3.26. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 13
3.27. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 13
3.28. Message-Authenticator. . . . . . . . . . . . . . . . . . 13
3.29. NAS-Port-Id. . . . . . . . . . . . . . . . . . . . . . . 13
3.30. Framed-Pool, Framed-IPv6-Pool. . . . . . . . . . . . . . 14
3.31. Tunnel Attributes. . . . . . . . . . . . . . . . . . . . 14
4. RC4 EAPOL-Key Descriptor . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
5.1. Packet Modification or Forgery . . . . . . . . . . . . . 18
5.2. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 19
5.3. Known Plaintext Attacks. . . . . . . . . . . . . . . . . 19
5.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5. Outcome Mismatches . . . . . . . . . . . . . . . . . . . 20
5.6. 802.11 Integration . . . . . . . . . . . . . . . . . . . 20
5.7. Key Management Issues. . . . . . . . . . . . . . . . . . 21
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
8. Table of Attributes. . . . . . . . . . . . . . . . . . . . . . 25
9. Intellectual Property Statement . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
5.6. 802.11 Integration . . . . . . . . . . . . . . . . . . . 20
5.7. Key Management Issues. . . . . . . . . . . . . . . . . . 21
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
8. Table of Attributes. . . . . . . . . . . . . . . . . . . . . . 25
9. Intellectual Property Statement . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
IEEE 802.1X enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. Although Remote Authentication Dial In User Service (RADIUS) support is optional within IEEE 802.1X, it is expected that many IEEE 802.1X Authenticators will function as RADIUS clients.
IEEE 802.1X允许通过身份验证访问IEEE 802媒体，包括以太网、令牌环和802.11无线局域网。尽管远程身份验证拨入用户服务（RADIUS）支持在IEEE 802.1X中是可选的，但预计许多IEEE 802.1X身份验证程序将用作RADIUS客户端。
IEEE 802.1X [IEEE8021X] provides "network port authentication" for IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring and 802.11 [IEEE80211] wireless LANS.
IEEE 802.1X[IEEE8021X]为IEEE 802[IEEE802]媒体提供“网络端口认证”，包括以太网[IEEE8023]、令牌环和802.11[IEEE80211]无线局域网。
IEEE 802.1X does not require use of a backend Authentication Server, and thus can be deployed with stand-alone bridges or Access Points, as well as in centrally managed scenarios.
IEEE 802.1X不需要使用后端身份验证服务器，因此可以与独立网桥或接入点一起部署，也可以在集中管理的场景中部署。
In situations where it is desirable to centrally manage authentication, authorization and accounting (AAA) for IEEE 802 networks, deployment of a backend authentication and accounting server is desirable. In such situations, it is expected that IEEE 802.1X Authenticators will function as AAA clients.
在需要集中管理IEEE 802网络的身份验证、授权和计费（AAA）的情况下，需要部署后端身份验证和计费服务器。在这种情况下，预计IEEE 802.1X认证器将作为AAA客户端运行。
This document provides suggestions on RADIUS usage by IEEE 802.1X Authenticators. Support for any AAA protocol is optional for IEEE 802.1X Authenticators, and therefore this specification has been incorporated into a non-normative Appendix within the IEEE 802.1X specification.
本文档提供了有关IEEE 802.1X认证器使用RADIUS的建议。对任何AAA协议的支持对于IEEE 802.1X认证器来说都是可选的，因此本规范已纳入IEEE 802.1X规范中的非规范性附录中。
This document uses the following terms:
本文件使用以下术语：
Access Point (AP) A Station that provides access to the distribution services via the wireless medium for associated Stations.
接入点（AP）通过无线媒体为相关站点提供对分发服务的访问的站点。
Association The service used to establish Access Point/Station mapping and enable Station invocation of the distribution system services.
关联用于建立接入点/站点映射和启用分发系统服务的站点调用的服务。
Authenticator An Authenticator is an entity that requires authentication from the Supplicant. The Authenticator may be connected to the Supplicant at the other end of a point-to-point LAN segment or 802.11 wireless link.
验证者验证者是一个需要请求者进行身份验证的实体。认证器可以在点到点LAN段或802.11无线链路的另一端连接到请求者。
Authentication Server An Authentication Server is an entity that provides an Authentication Service to an Authenticator. This service verifies, from the credentials provided by the Supplicant, the claim of identity made by the Supplicant.
身份验证服务器身份验证服务器是向身份验证者提供身份验证服务的实体。此服务根据请求人提供的凭据验证请求人的身份声明。
Port Access Entity (PAE) The protocol entity associated with a physical or virtual (802.11) Port. A given PAE may support the protocol functionality associated with the Authenticator, Supplicant or both.
端口访问实体（PAE）与物理或虚拟（802.11）端口关联的协议实体。给定PAE可支持与认证者、请求者或两者相关联的协议功能。
Station (STA) Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM).
站点（STA）包含符合IEEE 802.11的媒体访问控制（MAC）和无线媒体（WM）物理层（PHY）接口的任何设备。
Supplicant A Supplicant is an entity that is being authenticated by an Authenticator. The Supplicant may be connected to the Authenticator at one end of a point-to-point LAN segment or 802.11 wireless link.
请求者请求者是由验证器进行身份验证的实体。请求者可以在点到点LAN段或802.11无线链路的一端连接到认证器。
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]中所述进行解释。
With a few exceptions, the RADIUS accounting attributes defined in [RFC2866], [RFC2867], and [RFC2869] have the same meaning within IEEE 802.1X sessions as they do in dialup sessions and therefore no additional commentary is needed.
除少数例外，[RFC2866]、[RFC2867]和[RFC2869]中定义的RADIUS记帐属性在IEEE 802.1X会话中的含义与在拨号会话中的含义相同，因此无需额外注释。
Attributes requiring more discussion include:
需要更多讨论的属性包括：
Acct-Terminate-Cause Acct-Multi-Session-Id Acct-Link-Count
帐户终止原因帐户多会话Id帐户链接计数
This attribute indicates how the session was terminated, as described in [RFC2866]. [IEEE8021X] defines the following termination cause values, which are shown with their RADIUS equivalents in the table on the next page.
此属性指示会话是如何终止的，如[RFC2866]中所述。[IEEE8021X]定义了以下终止原因值，下一页的表格中显示了这些值及其半径等效值。
IEEE 802.1X RADIUS
dot1xAuthSessionTerminateCause Acct-Terminate-Cause
Value Value
------------- --------------------
SupplicantLogoff(1) User Request (1)
portFailure(2) Lost Carrier (2)
SupplicantRestart(3) Supplicant Restart (19)
reauthFailed(4) Reauthentication Failure (20)
authControlForceUnauth(5) Admin Reset (6)
portReInit(6) Port Reinitialized (21)
portAdminDisabled(7) Port Administratively Disabled (22)
notTerminatedYet(999) N/A
IEEE 802.1X RADIUS
dot1xAuthSessionTerminateCause Acct-Terminate-Cause
Value Value
------------- --------------------
SupplicantLogoff(1) User Request (1)
portFailure(2) Lost Carrier (2)
SupplicantRestart(3) Supplicant Restart (19)
reauthFailed(4) Reauthentication Failure (20)
authControlForceUnauth(5) Admin Reset (6)
portReInit(6) Port Reinitialized (21)
portAdminDisabled(7) Port Administratively Disabled (22)
notTerminatedYet(999) N/A
When using this attribute, the User Request (1) termination cause corresponds to the situation in which the session terminated due to an EAPOL-Logoff received from the Supplicant. When a session is moved due to roaming, the EAPOL state machines will treat this as a Supplicant Logoff.
使用此属性时，用户请求（1）终止原因对应于由于从请求方接收到EAPOL注销而终止会话的情况。由于漫游而移动会话时，EAPOL状态机会将此视为请求者注销。
A Lost Carrier (2) termination cause indicates session termination due to loss of physical connectivity for reasons other than roaming between Access Points. For example, if the Supplicant disconnects a point-to-point LAN connection, or moves out of range of an Access Point, this termination cause is used. Lost Carrier (2) therefore equates to a Port Disabled condition in the EAPOL state machines.
丢失载波（2）终止原因表示由于除在接入点之间漫游以外的原因导致的物理连接丢失而导致的会话终止。例如，如果请求者断开点对点LAN连接，或移动到访问点范围之外，则使用此终止原因。因此，丢失载波（2）等同于EAPOL状态机中的端口禁用状态。
A Supplicant Restart (19) termination cause indicates re-initialization of the Supplicant state machines.
请求方重启（19）终止原因表示请求方状态机的重新初始化。
A Reauthentication Failure (20) termination cause indicates that a previously authenticated Supplicant has failed to re-authenticate successfully following expiry of the re-authentication timer or explicit re-authentication request by management action.
重新身份验证失败（20）终止原因表示，在重新身份验证计时器或管理操作的显式重新身份验证请求到期后，先前经过身份验证的请求人未能成功重新身份验证。
Within [IEEE80211], periodic re-authentication may be useful in preventing reuse of an initialization vector with a given key. Since successful re-authentication does not result in termination of the session, accounting packets are not sent as a result of re-authentication unless the status of the session changes. For example:
在[IEEE80211]中，定期重新认证可用于防止使用给定密钥重用初始化向量。由于成功的重新身份验证不会导致会话终止，因此除非会话状态发生更改，否则不会作为重新身份验证的结果发送记帐数据包。例如：
a. The session is terminated due to re-authentication failure. In this case the Reauthentication Failure (20) termination cause is used.
a. 由于重新身份验证失败，会话被终止。在这种情况下，使用重新验证失败（20）终止原因。
b. The authorizations are changed as a result of a successful re-authentication. In this case, the Service Unavailable (15) termination cause is used. For accounting purposes, the portion of the session after the authorization change is treated as a separate session.
b. 成功的重新身份验证会导致授权发生更改。在这种情况下，使用服务不可用（15）终止原因。出于记帐目的，授权更改后的会话部分被视为单独的会话。
Where IEEE 802.1X authentication occurs prior to association, accounting packets are not sent until an association occurs.
如果IEEE 802.1X认证在关联之前发生，则在关联发生之前不会发送记帐数据包。
An Admin Reset (6) termination cause indicates that the Port has been administratively forced into the unauthorized state.
管理员重置（6）终止原因表示端口已被管理强制进入未授权状态。
A Port Reinitialized (21) termination cause indicates that the Port's MAC has been reinitialized.
端口重新初始化（21）终止原因表示端口的MAC已重新初始化。
A Port Administratively Disabled (22) termination cause indicates that the Port has been administratively disabled.
端口管理性禁用（22）终止原因表示端口已被管理性禁用。
The purpose of this attribute is to make it possible to link together multiple related sessions. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Access Points to cause multiple RADIUS accounting packets to be sent by different Access Points.
此属性的目的是使链接多个相关会话成为可能。虽然[IEEE8021X]不作用于聚合端口，但请求方在接入点之间漫游可能导致多个RADIUS计费数据包由不同的接入点发送。
Where supported by the Access Points, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant. In such a situation, if the session context is transferred between Access Points, accounting packets MAY be sent without a corresponding authentication and authorization exchange,
在接入点支持的情况下，Acct Multi Session Id属性可用于将漫游请求者的多个相关会话链接在一起。在这种情况下，如果会话上下文在接入点之间传输，则可以在没有相应的认证和授权交换的情况下发送记帐分组，
provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points as part of the Inter-Access Point Protocol (IAPP).
前提是关联已经发生。然而，在这种情况下，假设作为接入点间协议（IAPP）的一部分，在接入点之间传输Acct多会话Id。
If the Acct-Multi-Session-Id were not unique between Access Points, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point, and the Accounting Server would therefore be unable to distinguish a roaming session from a multi-link session.
如果接入点之间的Acct多会话Id不唯一，则所选的Acct多会话Id可能与该接入点上分配的现有值重叠，因此记帐服务器将无法区分漫游会话和多链路会话。
As a result, the Acct-Multi-Session-Id attribute is unique among all the bridges or Access Points, Supplicants and sessions. In order to provide this uniqueness, it is suggested that the Acct-Multi-Session-Id be of the form:
因此，Acct Multi Session Id属性在所有网桥或接入点、请求者和会话中是唯一的。为了提供这种唯一性，建议Acct多会话Id的形式为：
Original AP MAC Address | Supplicant MAC Address | NTP Timestamp
原始AP MAC地址|请求者MAC地址| NTP时间戳
Here "|" represents concatenation, the original AP MAC Address is the MAC address of the bridge or Access Point at which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between roaming sessions, the Acct-Multi-Session-Id may be moved between Access Points as part of IAPP or another handoff scheme.
此处“|”表示连接，原始AP MAC地址是会话开始的网桥或接入点的MAC地址，64位NTP时间戳表示原始会话的开始。为了在漫游会话之间提供Acct多会话Id的一致性，作为IAPP或另一切换方案的一部分，可以在接入点之间移动Acct多会话Id。
The use of an Acct-Multi-Session-Id of this form guarantees uniqueness among all Access Points, Supplicants and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point could choose an Acct-Multi-Session-Id that could be confused with that of a previous session.
使用此表单的Acct多会话Id可确保所有接入点、请求者和会话之间的唯一性。由于NTP时间戳不会在重新启动时自动换行，因此重新启动的接入点不可能选择与上一个会话Id混淆的Acct多会话Id。
Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8"
由于Acct多会话Id为[RFC2866]中定义的字符串类型，用于IEEE 802.1X，因此它被编码为十六进制数字的ASCII字符串。示例：“00-10-A4-23-19-C0-00-12-B2-14-23-DE-AF-23-83-C0-76-B8-44-E8”
The Acct-Link-Count attribute may be used to account for the number of ports that have been aggregated.
Acct Link Count属性可用于说明已聚合的端口数。
This section describes how attributes defined in [RFC2865], [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in IEEE 802.1X authentication.
本节介绍[RFC2865]、[RFC2867]、[RFC2868]、[RFC2869]、[RFC3162]和[RFC3579]中定义的属性如何在IEEE 802.1X身份验证中使用。
In IEEE 802.1X, the Supplicant typically provides its identity via an EAP-Response/Identity message. Where available, the Supplicant identity is included in the User-Name attribute, and included in the RADIUS Access-Request and Access-Reply messages as specified in [RFC2865] and [RFC3579].
在IEEE 802.1X中，请求者通常通过EAP响应/身份消息提供其身份。在可用的情况下，请求者标识包含在用户名属性中，并包含在[RFC2865]和[RFC3579]中指定的RADIUS访问请求和访问回复消息中。
Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name attribute may contain the Calling-Station-ID value, which is set to the Supplicant MAC address.
或者，如[RFC3579]第2.1节所述，用户名属性可以包含呼叫站ID值，该值设置为请求方MAC地址。
Since IEEE 802.1X does not support PAP or CHAP authentication, the User-Password, CHAP-Password or CHAP-Challenge attributes are not used by IEEE 802.1X Authenticators acting as RADIUS clients.
由于IEEE 802.1X不支持PAP或CHAP身份验证，因此充当RADIUS客户端的IEEE 802.1X身份验证程序不使用用户密码、CHAP密码或CHAP质询属性。
For use with IEEE 802.1X, the NAS-IP-Address contains the IPv4 address of the bridge or Access Point acting as an Authenticator, and the NAS-IPv6-Address contains the IPv6 address. If the IEEE 802.1X Authenticator has more than one interface, it may be desirable to use a loopback address for this purpose so that the Authenticator will still be reachable even if one of the interfaces were to fail.
对于IEEE 802.1X，NAS IP地址包含充当身份验证程序的网桥或接入点的IPv4地址，NAS-IPv6-Address包含IPv6地址。如果IEEE 802.1X认证器具有多个接口，则可能需要为此目的使用环回地址，以便即使其中一个接口出现故障，认证器仍然可以访问。
For use with IEEE 802.1X the NAS-Port will contain the port number of the bridge, if this is available. While an Access Point does not have physical ports, a unique "association ID" is assigned to every mobile Station upon a successful association exchange. As a result, for an Access Point, if the association exchange has been completed prior to authentication, the NAS-Port attribute will contain the association ID, which is a 16-bit unsigned integer. Where IEEE 802.1X authentication occurs prior to association, a unique NAS-Port value may not be available.
与IEEE 802.1X一起使用时，NAS端口将包含网桥的端口号（如果可用）。虽然接入点没有物理端口，但在成功的关联交换后，将为每个移动站分配唯一的“关联ID”。因此，对于接入点，如果在身份验证之前已完成关联交换，则NAS端口属性将包含关联ID，它是一个16位无符号整数。如果IEEE 802.1X身份验证在关联之前发生，则唯一的NAS端口值可能不可用。
For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and Call Check (10) values are most commonly used.
对于IEEE 802.1X，最常用的是帧（2）、仅验证（8）和呼叫检查（10）值。
A Service-Type of Framed indicates that appropriate 802 framing should be used for the connection. A Service-Type of Authenticate Only (8) indicates that no authorization information needs to be returned in the Access-Accept. As described in [RFC2865], a
Framed的服务类型表示应为连接使用适当的802帧。仅验证（8）的服务类型表示无需在访问接受中返回授权信息。如[RFC2865]所述
Service-Type of Call Check is included in an Access-Request packet to request that the RADIUS server accept or reject the connection attempt, typically based on the Called-Station-ID (set to the bridge or Access Point MAC address) or Calling-Station-ID attributes (set to the Supplicant MAC address). As noted in [RFC2865], it is recommended that in this case, the User-Name attribute be given the value of Calling-Station-Id.
呼叫检查的服务类型包括在接入请求包中，以请求RADIUS服务器接受或拒绝连接尝试，通常基于被叫站ID（设置为网桥或接入点MAC地址）或主叫站ID属性（设置为请求者MAC地址）。如[RFC2865]所述，在这种情况下，建议为用户名属性指定Calling-Station-Id的值。
Since there is no value for IEEE 802 media, the Framed-Protocol attribute is not used by IEEE 802.1X Authenticators.
由于IEEE 802媒体没有值，IEEE 802.1X身份验证程序不使用框架协议属性。
IEEE 802.1X does not provide a mechanism for IP address assignment. Therefore the Framed-IP-Address and Framed-IP-Netmask attributes can only be used by IEEE 802.1X Authenticators that support IP address assignment mechanisms. Typically this capability is supported by layer 3 devices.
IEEE 802.1X不提供IP地址分配机制。因此，帧IP地址和帧IP网络掩码属性只能由支持IP地址分配机制的IEEE 802.1X身份验证程序使用。通常，第3层设备支持此功能。
The Framed-Routing attribute indicates the routing method for the Supplicant. It is therefore only relevant for IEEE 802.1X Authenticators that act as layer 3 devices, and cannot be used by a bridge or Access Point.
Framed Routing属性表示请求者的路由方法。因此，它仅与充当第3层设备的IEEE 802.1X认证器相关，不能由网桥或接入点使用。
This attribute indicates the name of the filter list to be applied to the Supplicant's session. For use with an IEEE 802.1X Authenticator, it may be used to indicate either layer 2 or layer 3 filters. Layer 3 filters are typically only supported on IEEE 802.1X Authenticators that act as layer 3 devices.
此属性表示要应用于请求者会话的筛选器列表的名称。与IEEE 802.1X认证器一起使用时，它可用于指示第2层或第3层过滤器。层3过滤器通常仅在充当层3设备的IEEE 802.1X身份验证程序上受支持。
This attribute indicates the maximum size of an IP packet that may be transmitted over the wire between the Supplicant and the Authenticator. IEEE 802.1X Authenticators set this to the value corresponding to the relevant 802 medium, and include it in the RADIUS Access-Request. The 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. For EAP over IEEE 802 media, the Framed-MTU values (which do not include LLC/SNAP overhead) and maximum frame length values (not including the preamble) are as follows:
该属性表示可在请求者和认证者之间通过线路传输的IP数据包的最大大小。IEEE 802.1X认证器将其设置为与相关802媒体对应的值，并将其包括在RADIUS访问请求中。考虑到IEEE 802.1X版本（1）、类型（1）和正文长度（2）字段的额外开销，RADIUS服务器可发送帧MTU减去四（4）个八位字节的EAP数据包。对于IEEE 802媒体上的EAP，帧MTU值（不包括LLC/SNAP开销）和最大帧长度值（不包括前导码）如下所示：
Maximum Frame
Media Framed-MTU Length
========= =============== ==============
Ethernet 1500 1522
802.3 1500 1522
802.4 8174 8193
802.5 (4 Mbps) 4528 4550
802.5 (16 Mbps) 18173 18200
802.5 (100 Mb/s) 18173 18200
802.6 9191 9240
802.9a 1500 1518
802.11 2304 2346
802.12 (Ethernet) 1500 1518
802.12 (Token Ring) 4502 4528
FDDI 4479 4500
Maximum Frame
Media Framed-MTU Length
========= =============== ==============
Ethernet 1500 1522
802.3 1500 1522
802.4 8174 8193
802.5 (4 Mbps) 4528 4550
802.5 (16 Mbps) 18173 18200
802.5 (100 Mb/s) 18173 18200
802.6 9191 9240
802.9a 1500 1518
802.11 2304 2346
802.12 (Ethernet) 1500 1518
802.12 (Token Ring) 4502 4528
FDDI 4479 4500
NOTE - the Framed-MTU size for IEEE 802.11 media may change as a result of ongoing work being undertaken in the IEEE 802.11 Working Group. Since some 802.11 stations cannot handle an MTU larger than 1500 octets, it is recommended that RADIUS servers encountering a NAS-Port-Type value of 802.11 send EAP packets no larger than 1496 octets.
注-由于IEEE 802.11工作组正在进行的工作，IEEE 802.11介质的帧MTU大小可能会发生变化。由于某些802.11站点无法处理大于1500个八位字节的MTU，建议遇到NAS端口类型值为802.11的RADIUS服务器发送不大于1496个八位字节的EAP数据包。
[IEEE8021X] does not include compression support. Therefore this attribute is not understood by [IEEE8021X] Authenticators.
[IEEE8021X]不包括压缩支持。因此，[IEEE8021X]验证器无法理解此属性。
The Reply-Message attribute, defined in section 5.18 of [RFC2865], indicates text which may be displayed to the user. This is similar in concept to the EAP Notification Type, defined in [RFC2284]. As noted in [RFC3579], Section 2.6.5, when sending a displayable message to an [IEEE8021X] Authenticator, displayable messages are best sent within EAP-Message/EAP-Request/Notification attribute(s), and not within Reply-Message attribute(s).
[RFC2865]第5.18节中定义的回复消息属性表示可向用户显示的文本。这在概念上类似于[RFC2284]中定义的EAP通知类型。如[RFC3579]第2.6.5节所述，当向[IEEE8021X]验证器发送可显示消息时，可显示消息最好在EAP消息/EAP请求/通知属性内发送，而不是在回复消息属性内发送。
These attributes are not understood by IEEE 802.1X Authenticators.
IEEE 802.1X认证器不理解这些属性。
The Framed-Route and Framed-IPv6-Route attributes provide routes that are to be configured for the Supplicant. These attributes are therefore only relevant for IEEE 802.1X Authenticators that act as layer 3 devices, and cannot be understood by a bridge or Access Point.
Framed Route和Framed-IPv6-Route属性提供要为请求者配置的路由。因此，这些属性仅与充当第3层设备的IEEE 802.1X认证器相关，并且不能被网桥或接入点理解。
These attributes are used for the same purposes as described in [RFC2865].
这些属性用于与[RFC2865]中所述相同的目的。
Vendor-specific attributes are used for the same purposes as described in [RFC2865]. The MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes, described in section 2.4 of [RFC2548], MAY be used to encrypt and authenticate the RC4 EAPOL-Key descriptor [IEEE8021X, Section 7.6]. Examples of the derivation of the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes from the master key negotiated by an EAP method are given in [RFC2716]. Details of the EAPOL-Key descriptor are provided in Section 4.
供应商特定属性用于与[RFC2865]中所述相同的目的。[RFC2548]第2.4节中描述的MS MPPE发送密钥和MS MPPE Recv密钥属性可用于加密和验证RC4 EAPOL密钥描述符[IEEE8021X，第7.6节]。[RFC2716]中给出了从EAP方法协商的主密钥派生MS MPPE发送密钥和MS MPPE Recv密钥属性的示例。第4节提供了EAPOL密钥描述符的详细信息。
When sent along in an Access-Accept without a Termination-Action attribute or with a Termination-Action attribute set to Default, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to session termination.
在Access Accept中发送时，如果没有终止操作属性或终止操作属性设置为默认值，会话超时属性将指定在会话终止之前提供的服务的最大秒数。
When sent in an Access-Accept along with a Termination-Action value of RADIUS-Request, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to re-authentication. In this case, the Session-Timeout attribute is used to load the reAuthPeriod constant within the Reauthentication Timer state machine of 802.1X. When sent with a Termination-Action value of RADIUS-Request, a Session-Timeout value of zero indicates the desire to perform another authentication (possibly of a different type) immediately after the first authentication has successfully completed.
当在Access Accept中与RADIUS请求的终止操作值一起发送时，会话超时属性指定重新身份验证之前提供的服务的最大秒数。在这种情况下，会话超时属性用于在802.1X的重新验证计时器状态机中加载重新验证周期常量。当使用RADIUS请求的终止操作值发送时，会话超时值为零表示希望在第一次身份验证成功完成后立即执行另一次身份验证（可能是不同类型的身份验证）。
When sent in an Access-Challenge, this attribute represents the maximum number of seconds that an IEEE 802.1X Authenticator should wait for an EAP-Response before retransmitting. In this case, the Session-Timeout attribute is used to load the suppTimeout constant within the backend state machine of IEEE 802.1X.
在访问质询中发送时，此属性表示IEEE 802.1X身份验证程序在重新传输前应等待EAP响应的最长秒数。在这种情况下，会话超时属性用于在IEEE 802.1X的后端状态机中加载suppTimeout常量。
The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802 media other than 802.11 the media are always on. As a result the Idle-Timeout attribute is typically only used with wireless media such as IEEE 802.11. It is possible for a wireless device to wander out of range of all Access Points. In this case, the Idle-Timeout attribute indicates the maximum time that a wireless device may remain idle.
[RFC2865]中描述了空闲超时属性。对于802.11以外的IEEE 802媒体，媒体始终处于打开状态。因此，空闲超时属性通常仅用于无线媒体，如IEEE 802.11。无线设备可能会偏离所有接入点的范围。在这种情况下，Idle Timeout属性表示无线设备可能保持空闲的最长时间。
This attribute indicates what action should be taken when the service is completed. The value RADIUS-Request (1) indicates that re-authentication should occur on expiration of the Session-Time. The value Default (0) indicates that the session should terminate.
此属性指示服务完成时应采取的操作。值RADIUS请求（1）指示应在会话时间到期时进行重新身份验证。默认值（0）表示会话应终止。
For IEEE 802.1X Authenticators, this attribute is used to store the bridge or Access Point MAC address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". In IEEE 802.11, where the SSID is known, it SHOULD be appended to the Access Point MAC address, separated from the MAC address with a ":". Example "00-10-A4-23-19-C0:AP1".
对于IEEE 802.1X身份验证程序，此属性用于以ASCII格式（仅大写）存储网桥或接入点MAC地址，八位字节值用“-”分隔。示例：“00-10-A4-23-19-C0”。在已知SSID的IEEE 802.11中，应将其附加到接入点MAC地址，并用“：”与MAC地址分开。示例“00-10-A4-23-19-C0:AP1”。
For IEEE 802.1X Authenticators, this attribute is used to store the Supplicant MAC address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0".
对于IEEE 802.1X身份验证程序，此属性用于以ASCII格式（仅大写）存储请求的MAC地址，八位字节值用“-”分隔。示例：“00-10-A4-23-19-C0”。
This attribute contains a string identifying the IEEE 802.1X Authenticator originating the Access-Request.
此属性包含一个字符串，用于标识发起访问请求的IEEE 802.1X身份验证器。
For use with IEEE 802.1X, NAS-Port-Type values of Ethernet (15) Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be used.
对于IEEE 802.1X，可以使用以太网（15）无线-IEEE 802.11（19）、令牌环（20）和FDDI（21）的NAS端口类型值。
This attribute has no meaning when sent to an [IEEE8021X] Authenticator.
当发送到[IEEE8021X]验证器时，此属性没有意义。
In IEEE 802.1X, the Authenticator always transitions to the HELD state after an authentication failure. Thus this attribute does not make sense for IEEE 802.1X.
在IEEE 802.1X中，身份验证失败后，身份验证程序始终转换为保持状态。因此，该属性对于IEEE 802.1X没有意义。
This attribute is sent by a bridge or Access Point to indicate the nature of the Supplicant's connection. When sent in the Access-Request it is recommended that this attribute contain information on the speed of the Supplicant's connection. For 802.11, the following format is recommended: "CONNECT 11Mbps 802.11b". If sent in the Accounting STOP, this attribute may be used to summarize statistics relating to session quality. For example, in IEEE 802.11, the Connect-Info attribute may contain information on the number of link layer retransmissions. The exact format of this attribute is implementation specific.
此属性由网桥或访问点发送，以指示请求者连接的性质。在访问请求中发送时，建议此属性包含有关请求者连接速度的信息。对于802.11，建议使用以下格式：“连接11Mbps 802.11b”。如果在记帐停止中发送，此属性可用于汇总与会话质量相关的统计信息。例如，在IEEE 802.11中，Connect Info属性可以包含关于链路层重传次数的信息。此属性的确切格式是特定于实现的。
Since IEEE 802.1X provides for encapsulation of EAP as described in [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in [RFC3579] is used to encapsulate EAP packets for transmission from the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579] Section 2.2. describes how the Authentication Server handles invalid EAP packets passed to it by the Authenticator.
由于IEEE 802.1X提供了[RFC2284]和[IEEE8021X]中所述的EAP封装，因此[RFC3579]中定义的EAP消息属性用于封装EAP数据包，以便从IEEE 802.1X认证器传输到认证服务器。[RFC3579]第2.2节。描述身份验证服务器如何处理由身份验证程序传递给它的无效EAP数据包。
As noted in [RFC3579] Section 3.1., the Message-Authenticator attribute MUST be used to protect packets within a RADIUS/EAP conversation.
如[RFC3579]第3.1节所述，必须使用消息验证器属性来保护RADIUS/EAP会话中的数据包。
This attribute is used to identify the IEEE 802.1X Authenticator port which authenticates the Supplicant. The NAS-Port-Id differs from the NAS-Port in that it is a string of variable length whereas the NAS-Port is a 4 octet value.
此属性用于标识对请求者进行身份验证的IEEE 802.1X身份验证程序端口。NAS端口Id与NAS端口的不同之处在于，它是一个长度可变的字符串，而NAS端口是一个4个八位字节的值。
IEEE 802.1X does not provide a mechanism for IP address assignment. Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be used by IEEE 802.1X Authenticators that support IP address assignment mechanisms. Typically this capability is supported by layer 3 devices.
IEEE 802.1X不提供IP地址分配机制。因此，框架池和框架IPv6池属性只能由支持IP地址分配机制的IEEE 802.1X身份验证程序使用。通常，第3层设备支持此功能。
Reference [RFC2868] defines RADIUS tunnel attributes used for authentication and authorization, and [RFC2867] defines tunnel attributes used for accounting. Where the IEEE 802.1X Authenticator supports tunneling, a compulsory tunnel may be set up for the Supplicant as a result of the authentication.
参考文献[RFC2868]定义了用于身份验证和授权的RADIUS隧道属性，[RFC2867]定义了用于记帐的隧道属性。在IEEE 802.1X认证器支持隧道的情况下，作为认证的结果，可以为请求者设置强制隧道。
In particular, it may be desirable to allow a port to be placed into a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the result of the authentication. This can be used, for example, to allow a wireless host to remain on the same VLAN as it moves within a campus network.
具体地说，基于认证的结果，可能希望允许将端口放置到[IEEE8021Q]中定义的特定虚拟LAN（VLAN）中。例如，这可用于允许无线主机在校园网内移动时保持在同一VLAN上。
The RADIUS server typically indicates the desired VLAN by including tunnel attributes within the Access-Accept. However, the IEEE 802.1X Authenticator may also provide a hint as to the VLAN to be assigned to the Supplicant by including Tunnel attributes within the Access-Request.
RADIUS服务器通常通过在Access Accept中包含隧道属性来指示所需的VLAN。然而，IEEE 802.1X认证器还可以通过在访问请求中包括隧道属性来提供关于要分配给请求者的VLAN的提示。
For use in VLAN assignment, the following tunnel attributes are used:
为了在VLAN分配中使用，将使用以下隧道属性：
Tunnel-Type=VLAN (13) Tunnel-Medium-Type=802 Tunnel-Private-Group-ID=VLANID
隧道类型=VLAN（13）隧道介质类型=802隧道专用组ID=VLANID
Note that the VLANID is 12-bits, taking a value between 1 and 4094, inclusive. Since the Tunnel-Private-Group-ID is of type String as defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer value is encoded as a string.
请注意，VLANID为12位，取值范围为1到4094（含1和4094）。由于隧道专用组ID为[RFC2868]中定义的字符串类型，用于IEEE 802.1X，因此VLANID整数值编码为字符串。
When Tunnel attributes are sent, it is necessary to fill in the Tag field. As noted in [RFC2868], section 3.1:
发送隧道属性时，需要填写标记字段。如[RFC2868]第3.1节所述：
The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
标记字段的长度为一个八位字节，旨在提供一种方法，对引用同一隧道的同一数据包中的属性进行分组。此字段的有效值为0x01到0x1F，包括在内。如果标记字段未使用，则它必须为零（0x00）。
For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel-Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel-Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of greater than 0x1F is interpreted as the first octet of the following field.
对于与隧道客户端终结点、隧道服务器终结点、隧道专用组ID、隧道分配ID、隧道客户端身份验证ID或隧道服务器身份验证ID属性（但不包括隧道类型、隧道介质类型、隧道密码或隧道首选项）一起使用，大于0x1F的标记字段被解释为以下字段的第一个八位字节。
Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X Authenticators that may support tunneling but not VLANs), it is only necessary for tunnel attributes to specify a single tunnel. As a result, where it is only desired to specify the VLANID, the tag field SHOULD be set to zero (0x00) in all tunnel attributes. Where alternative tunnel types are to be provided, tag values between 0x01 and 0x1F SHOULD be chosen.
除非提供了替代隧道类型（例如，对于可能支持隧道但不支持VLAN的IEEE 802.1X认证器），否则隧道属性仅需要指定单个隧道。因此，如果只需要指定VLANID，则所有隧道属性中的标记字段都应设置为零（0x00）。如果要提供备选隧道类型，则应选择0x01和0x1F之间的标签值。
The RC4 EAPOL-Key frame is created and transmitted by the Authenticator in order to provide media specific key information. For example, within 802.11 the RC4 EAPOL-Key frame can be used to distribute multicast/broadcast ("default") keys, or unicast ("key mapping") keys. The "default" key is the same for all Stations within a broadcast domain.
认证器创建并传输RC4 EAPOL密钥帧，以提供媒体特定密钥信息。例如，在802.11内，RC4 EAPOL密钥帧可用于分发多播/广播（“默认”）密钥或单播（“密钥映射”）密钥。“默认”键对于广播域内的所有电台都是相同的。
The RC4 EAPOL-Key frame is not acknowledged and therefore the Authenticator does not know whether the Supplicant has received it. If it is lost, then the Supplicant and Authenticator will not have the same keying material, and communication will fail. If this occurs, the problem is typically addressed by re-running the authentication.
RC4 EAPOL密钥帧未被确认，因此身份验证器不知道请求者是否已收到它。如果丢失，那么请求者和验证者将没有相同的密钥材料，通信将失败。如果出现这种情况，通常通过重新运行身份验证来解决问题。
The RC4 EAPOL-Key frame is sent from the Authenticator to the Supplicant in order to provision the "default" key, and subsequently in order to refresh the "default" key. It may also be used to refresh the key-mapping key. Rekey is typically only required with weak ciphersuites such as WEP, defined in [IEEE80211].
RC4 EAPOL密钥帧从验证器发送到请求者，以提供“默认”密钥，随后刷新“默认”密钥。它还可用于刷新密钥映射密钥。通常，只有在[IEEE80211]中定义的WEP等弱密码套件中才需要重新密钥。
Where keys are required, an EAP method that derives keys is typically selected. Therefore the initial "key mapping" keys can be derived from EAP keying material, without requiring the Authenticator to send an RC4 EAPOL-Key frame to the Supplicant. An example of how EAP keying material can be derived and used is presented in [RFC2716].
在需要密钥的情况下，通常选择导出密钥的EAP方法。因此，初始“密钥映射”密钥可以从EAP密钥材料中导出，而不需要验证器向请求者发送RC4 EAPOL密钥帧。[RFC2716]中给出了如何导出和使用EAP键控材料的示例。
While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more complete description is provided on the next page.
虽然[IEEE8021X]中定义了RC4 EAPOL密钥帧，但下一页将提供更完整的描述。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Packet Type | Packet Body Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Key Length |Replay Counter...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Counter...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Counter | Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV... |F| Key Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Packet Type | Packet Body Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Key Length |Replay Counter...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Counter...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Counter | Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key IV... |F| Key Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version The Version field is one octet. For IEEE 802.1X, it contains the value 0x01.
版本版本字段是一个八位字节。对于IEEE 802.1X，它包含值0x01。
Packet Type The Packet Type field is one octet, and determines the type of packet being transmitted. For an EAPOL-Key Descriptor, the Packet Type field contains 0x03.
数据包类型数据包类型字段为一个八位字节，确定传输的数据包类型。对于EAPOL密钥描述符，数据包类型字段包含0x03。
Packet Body Length The Packet Body Length is two octets, and contains the length of the EAPOL-Key descriptor in octets, not including the Version, Packet Type and Packet Body Length fields.
数据包正文长度数据包正文长度为两个八位字节，包含以八位字节为单位的EAPOL密钥描述符的长度，不包括版本、数据包类型和数据包正文长度字段。
Type The Type field is a single octet. The Key descriptor is defined differently for each Type; this specification documents only the RC4 Key Descriptor (Type = 0x01).
类型类型字段是一个八位字节。对于每种类型，密钥描述符的定义不同；本规范仅记录RC4密钥描述符（类型=0x01）。
Key Length The Key Length field is two octets. If Packet Body Length = 44 + Key Length, then the Key Field contains the key in encrypted form, of length Key Length. This is 5 octets (40 bits) for WEP, and 13 octets (104 bits) for WEP-128. If Packet Body Length = 44, then the Key field is absent, and Key Length represents the number of least significant octets from the MS-MPPE-Send-Key attribute [RFC2548] to be used as the keying material. Note that the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the point of view of the Authenticator. From the Supplicant point of reference, the terms are reversed. Thus the MS-MPPE-Recv-Key on the Supplicant corresponds to the MS-MPPE-Send-Key on the Authenticator, and the MS-MPPE-Send-Key on the Supplicant corresponds to the MS-MPPE-Recv-Key on the Authenticator.
密钥长度密钥长度字段是两个八位字节。如果包体长度=44+密钥长度，则密钥字段包含加密形式的密钥，长度为密钥长度。WEP为5个八位字节（40位），WEP-128为13个八位字节（104位）。如果包体长度=44，则密钥字段不存在，并且密钥长度表示要用作密钥材料的MS MPPE发送密钥属性[RFC2548]的最低有效八位字节数。注意，MS-MPPE发送密钥和MS-MPPE-Recv密钥属性是从验证器的角度定义的。从请求者的参照点来看，术语是相反的。因此，请求方上的MS-MPPE-Recv密钥对应于验证器上的MS-MPPE-Send密钥，请求方上的MS-MPPE-Send密钥对应于验证器上的MS-MPPE-Recv密钥。
Replay Counter The Replay Counter field is 8 octets. It does not repeat within the life of the keying material used to encrypt the Key field and compute the Key Signature field. A 64-bit NTP timestamp MAY be used as the Replay Counter.
重播计数器重播计数器字段为8个八位字节。在用于加密密钥字段和计算密钥签名字段的密钥材料的生命周期内，它不会重复。64位NTP时间戳可用作重播计数器。
Key IV The Key IV field is 16 octets and includes a 128-bit cryptographically random number.
密钥IV密钥IV字段为16个八位字节，包括一个128位加密随机数。
F The Key flag (F) is a single bit, describing the type of key that is included in the Key field. Values are:
F键标志（F）是一个位，描述键字段中包含的键类型。价值观是：
0 = for broadcast (default key) 1 = for unicast (key mapping key)
0=用于广播（默认键）1=用于单播（键映射键）
Key Index The Key Index is 7 bits.
键索引键索引为7位。
Key Signature The Key Signature field is 16 octets. It contains an HMAC-MD5 message integrity check computed over the EAPOL-Key descriptor, starting from the Version field, with the Key field filled in if present, but with the Key Signature field set to zero. For the computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is used as the HMAC-MD5 key.
密钥签名密钥签名字段为16个八位字节。它包含通过EAPOL密钥描述符计算的HMAC-MD5消息完整性检查，从版本字段开始，如果存在，则填写密钥字段，但密钥签名字段设置为零。对于计算，使用32个八位组（256位）的MS MPPE发送密钥[RFC2548]作为HMAC-MD5密钥。
Key If Packet Body Length = 44 + Key Length, then the Key Field contains the key in encrypted form, of length Key Length. If Packet Body Length = 44, then the Key field is absent, and the least significant Key Length octets from the MS-MPPE-Send-Key attribute is used as the keying material. Where the Key field is encrypted using RC4, the RC4 encryption key used to encrypt this field is formed by concatenating the 16 octet (128 bit) Key-IV field with the 32 octet MS-MPPE-Recv-Key attribute. This yields a 48 octet RC4 key (384 bits).
密钥如果包体长度=44+密钥长度，则密钥字段包含加密形式的密钥，长度为密钥长度。如果包体长度=44，则密钥字段不存在，并且来自MS-MPPE-Send-Key属性的最低有效密钥长度八位字节被用作密钥材料。在使用RC4加密密钥字段的情况下，用于加密该字段的RC4加密密钥是通过将16个八位组（128位）的密钥IV字段与32个八位组的MS MPPE Recv密钥属性串联而成的。这将产生一个48八位RC4密钥（384位）。
Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802.1X-enabled networks, it is vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3579], and [RFC3576].
由于本文档描述了在支持IEEE 802.1X的网络中使用RADIUS进行身份验证、授权和记帐，因此它容易受到其他RADIUS应用程序中存在的所有威胁的攻击。有关这些威胁的讨论，请参阅[RFC2607]、[RFC2865]、[RFC3162]、[RFC3579]和[RFC3576]。
Vulnerabilities include:
漏洞包括：
Packet modification or forgery Dictionary attacks Known plaintext attacks Replay Outcome mismatches 802.11 integration Key management issues
数据包修改或伪造字典攻击已知明文攻击重播结果不匹配802.11集成密钥管理问题
RADIUS, defined in [RFC2865], does not require all Access-Requests to be authenticated or integrity protected. However, IEEE 802.1X is based on EAP. As described in [3579], Section 3.1.:
[RFC2865]中定义的RADIUS不要求对所有访问请求进行身份验证或完整性保护。然而，IEEE 802.1X是基于EAP的。如[3579]第3.1节所述：
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消息属性的访问请求、访问质询、访问接受和访问拒绝数据包。
As a result, when used with IEEE 802.1X, all RADIUS packets MUST be authenticated and integrity protected. In addition, as described in [3579], Section 4.2.:
因此，当与IEEE 802.1X一起使用时，必须对所有RADIUS数据包进行身份验证和完整性保护。此外，如[3579]第4.2节所述：
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
为了解决RADIUS/EAP的安全漏洞，本规范的实现应支持IPsec[RFC2401]和IKE[RFC2409]进行密钥管理。应支持具有非空转换的IPsec ESP[RFC2406]，以及具有非空加密转换和身份验证的IPsec ESP
support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management.
应使用支持来提供每个数据包的机密性、身份验证、完整性和重播保护。IKE应该用于密钥管理。
As discussed in [RFC3579] Section 4.3.3., 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], Section 3 recommends:
如[RFC3579]第4.3.3节所述，RADIUS共享机密易受脱机字典攻击，这是基于响应验证器或消息验证器属性的捕获。为了降低脆弱性水平，[RFC2865]，第3节建议：
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个八位字节。
In addition, the risk of an offline dictionary attack can be further mitigated by employing IPsec ESP with a non-null transform in order to encrypt the RADIUS conversation, as described in [RFC3579], Section 4.2.
此外，如[RFC3579]第4.2节所述，通过使用带非空转换的IPsec ESP对RADIUS对话进行加密，可以进一步降低脱机字典攻击的风险。
Since IEEE 802.1X is based on EAP, which does not support PAP, the RADIUS User-Password attribute is not used to carry hidden user passwords. The hiding mechanism 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.
由于IEEE 802.1X基于EAP（不支持PAP），因此RADIUS用户密码属性不用于携带隐藏的用户密码。隐藏机制利用[RFC1321]中定义的MD5，以便基于RADIUS共享机密和请求验证器生成密钥流。在使用PAP的情况下，可以通过捕获与使用已知密码的PAP身份验证尝试相对应的RADIUS对话来收集与给定请求验证器值相对应的密钥流。由于用户密码是已知的，因此可以确定和存储与给定请求验证器对应的密钥流。
The vulnerability is described in detail in [RFC3579], Section 4.3.4. Even though IEEE 802.1X Authenticators do 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 IEEE 802.1X (which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes) and GPRS (which may hide the User-Password attribute).
[RFC3579]第4.3.4节详细描述了该漏洞。即使IEEE 802.1X身份验证程序不支持PAP身份验证，如果使用相同的RADIUS共享密钥隐藏用户密码以及其他属性，则仍可能存在安全漏洞。例如，如果同一RADIUS代理处理IEEE 802.1X（可能隐藏隧道密码、MS MPPE发送密钥和MS MPPE Recv密钥属性）和GPRS（可能隐藏用户密码属性）的身份验证请求，则可能会发生这种情况。
The threat can be mitigated by protecting RADIUS with IPsec ESP with a non-null transform, as described in [RFC3579], Section 4.2. In addition, the same RADIUS shared secret MUST NOT be used for both IEEE 802.1X authentication and PAP authentication.
如[RFC3579]第4.2节所述，可通过使用IPsec ESP和非空转换保护RADIUS来缓解威胁。此外，同一RADIUS共享机密不得同时用于IEEE 802.1X身份验证和PAP身份验证。
As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides only limited support for replay protection. Replay protection for RADIUS authentication and accounting can be provided by enabling IPsec replay protection with RADIUS, as described in [RFC3579], Section 4.2.
如[RFC3579]第4.3.5节所述，RADIUS协议仅提供有限的重放保护支持。如[RFC3579]第4.2节所述，通过使用RADIUS启用IPsec重播保护，可以为RADIUS身份验证和记帐提供重播保护。
As with the Request Authenticator, for use with IEEE 802.1X Authenticators, the Acct-Session-Id SHOULD be globally and temporally unique.
与请求验证器一样，为了与IEEE 802.1X验证器一起使用，Acct会话Id应该在全局和时间上都是唯一的。
[RFC3579] Section 2.6.3. discusses the issues that arise when the EAP packet encapsulated in an EAP-Message attribute does not agree with the RADIUS Packet Type. For example, an EAP Success packet might be encapsulated within an Access-Reject; an EAP Failure might be sent within an Access-Accept; or an EAP Success or Failure might be sent within an Access-Challenge.
[RFC3579]第2.6.3节。讨论封装在EAP消息属性中的EAP数据包与RADIUS数据包类型不一致时出现的问题。例如，EAP成功分组可以封装在访问拒绝中；EAP故障可能在访问接受内发送；或者，EAP成功或失败可能在访问质询中发送。
As described in [RFC3579] Section 2.6.3., these conflicting messages are likely to cause confusion. To ensure that access decisions made by IEEE 802.1X Authenticators conform to the wishes of the RADIUS server, it is necessary for the Authenticator to make the decision solely based on the authentication result (Access-Accept/Reject) and not based on the contents of EAP-Message attributes, if present.
如[RFC3579]第2.6.3节所述，这些相互冲突的信息可能会导致混淆。为确保IEEE 802.1X认证机构做出的访问决定符合RADIUS服务器的意愿，认证机构有必要仅基于认证结果（访问接受/拒绝）而不是基于EAP消息属性（如果存在）的内容做出决定。
[IEEE8021X] was developed for use on wired IEEE 802 networks such as Ethernet, and therefore does not describe how to securely adapt IEEE 802.1X for use with 802.11. This is left to an enhanced security specification under development within IEEE 802.11.
[IEEE8021X]是为在有线IEEE 802网络（如以太网）上使用而开发的，因此没有描述如何安全地调整IEEE 802.1X以用于802.11。这取决于IEEE 802.11中正在开发的增强安全规范。
For example, [IEEE8021X] does not specify whether authentication occurs prior to, or after association, nor how the derived keys are used within various ciphersuites. It also does not specify ciphersuites addressing the vulnerabilities discovered in WEP, described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl]. [IEEE8021X] only defines an authentication framework, leaving the definition of the authentication methods to other documents, such as [RFC2716].
例如，[IEEE8021X]没有指定是在关联之前还是之后进行身份验证，也没有指定派生密钥在各种密码套件中的使用方式。它也没有指定解决WEP中发现的漏洞的密码套件，如[Berkeley]、[Arbaugh]、[Fluhrer]和[Stubbl]中所述。[IEEE8021X]只定义了一个身份验证框架，将身份验证方法的定义留给其他文档，如[RFC2716]。
Since [IEEE8021X] does not address 802.11 integration issues, implementors are strongly advised to consult additional IEEE 802.11 security specifications for guidance on how to adapt IEEE 802.1X for use with 802.11. For example, it is likely that the IEEE 802.11
由于[IEEE8021X]未解决802.11集成问题，因此强烈建议实施者参考其他IEEE 802.11安全规范，以获取如何调整IEEE 802.1X以用于802.11的指南。例如，IEEE 802.11很可能
enhanced security specification will define its own IEEE 802.11 key hierarchy as well as new EAPOL-Key descriptors.
增强的安全规范将定义自己的IEEE 802.11密钥层次结构以及新的EAPOL密钥描述符。
The EAPOL-Key descriptor described in Section 4. is likely to be deprecated in the future, when the IEEE 802.11 enhanced security group completes its work. Known security issues include:
第4节中描述的EAPOL密钥描述符。将来，当IEEE 802.11增强型安全组完成其工作时，它可能会被弃用。已知的安全问题包括：
[1] Default key-only support. IEEE 802.1X enables the derivation of per-Station unicast keys, known in [IEEE80211] as "key mapping keys." Keys used to encrypt multicast/broadcast traffic are known as "default keys". However, in some 802.11 implementations, the unicast keys, derived as part of the EAP authentication process, are used solely in order to encrypt, authenticate and integrity protect the EAPOL-Key descriptor, as described in Section 4. These implementations only support use of default keys (ordinarily only used with multicast/broadcast traffic) to secure all traffic, unicast or multicast/broadcast, resulting in inherent security weaknesses.
[1] 默认仅支持密钥。IEEE 802.1X支持推导每站单播密钥，在[IEEE80211]中称为“密钥映射密钥”。用于加密多播/广播流量的密钥称为“默认密钥”。然而，在一些802.11实现中，作为EAP认证过程的一部分导出的单播密钥仅用于加密、认证和完整性保护EAPOL密钥描述符，如第4节所述。这些实现仅支持使用默认密钥（通常仅用于多播/广播流量）来保护所有流量（单播或多播/广播），从而导致固有的安全弱点。
Where per-Station key-mapping keys (e.g. unicast keys) are unsupported, any Station possessing the default key can decrypt traffic from other Stations or impersonate them. When used along with a weak cipher (e.g. WEP), implementations supporting only default keys provide more material for attacks such as those described in [Fluhrer] and [Stubbl]. If in addition, the default key is not refreshed periodically, IEEE 802.1X dynamic key derivation provides little or no security benefit. For an understanding of the issues with WEP, see [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl].
如果不支持每个站点的密钥映射密钥（例如单播密钥），则任何拥有默认密钥的站点都可以解密来自其他站点的流量或模拟这些流量。当与弱密码（例如WEP）一起使用时，仅支持默认密钥的实现为攻击提供了更多材料，如[Fluhrer]和[Stubbl]中所述。此外，如果默认密钥没有定期刷新，IEEE 802.1X动态密钥派生提供的安全好处很少或没有。有关WEP问题的理解，请参见[Berkeley]、[Arbaugh]、[Fluhrer]和[Stubbl]。
[2] Reuse of keying material. The EAPOL-Key descriptor specified in section 4 uses the same keying material (MS-MPPE-Recv-Key) both to encrypt the Key field within the EAPOL-Key descriptor, and to encrypt data passed between the Station and Access Point. Multi-purpose keying material is frowned upon, since multiple uses can leak information helpful to an attacker.
[2] 键控材料的再利用。第4节中指定的EAPOL密钥描述符使用相同的密钥材料（MS MPPE Recv Key）对EAPOL密钥描述符中的密钥字段进行加密，并对站点和接入点之间传递的数据进行加密。多用途密钥材料是不可取的，因为多次使用可能会泄漏对攻击者有用的信息。
[3] Weak algorithms. The algorithm used to encrypt the Key field within the EAPOL-Key descriptor is similar to the algorithm used in WEP, and as a result, shares some of the same weaknesses. As with WEP, the RC4 stream cipher is used to encrypt the key. As input to the RC4 engine, the IV and key are concatenated rather than being combined within a mixing function. As with WEP, the IV is not a counter, and therefore there is little protection against reuse.
[3] 弱算法。用于加密EAPOL密钥描述符中的密钥字段的算法与WEP中使用的算法类似，因此具有一些相同的弱点。与WEP一样，RC4流密码用于加密密钥。作为RC4发动机的输入，IV和钥匙是串联的，而不是在混合功能中组合。与WEP一样，IV不是计数器，因此对重用几乎没有保护。
As a result of these vulnerabilities, implementors intending to use the EAPOL-Key descriptor described in this document are urged to consult the 802.11 enhanced security specification for a more secure alternative. It is also advisable to consult the evolving literature on WEP vulnerabilities, in order to better understand the risks, as well as to obtain guidance on setting an appropriate re-keying interval.
由于这些漏洞，希望使用本文档中描述的EAPOL密钥描述符的实施者应参考802.11增强型安全规范，以获得更安全的替代方案。还建议查阅有关WEP漏洞的不断发展的文献，以便更好地了解风险，并获得关于设置适当密钥更新间隔的指导。
This specification does not create any RADIUS attributes nor any new number spaces for IANA administration. However, it does require assignment of new values to existing RADIUS attributes. These include:
本规范不会为IANA管理创建任何RADIUS属性或任何新的数字空间。但是，它确实需要为现有半径属性指定新值。这些措施包括：
Attribute Values Required
========= ===============
NAS-Port-Type Token-Ring (20), FDDI (21)
Tunnel-Type VLAN (13)
Acct-Terminate-Cause Supplicant Restart (19)
Reauthentication Failure (20)
Port Reinitialized (21)
Port Administratively Disabled (22)
Attribute Values Required
========= ===============
NAS-Port-Type Token-Ring (20), FDDI (21)
Tunnel-Type VLAN (13)
Acct-Terminate-Cause Supplicant Restart (19)
Reauthentication Failure (20)
Port Reinitialized (21)
Port Administratively Disabled (22)
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[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月。
[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月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月。
[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月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，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月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[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月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[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月。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack]Dobbertin，H.，“最近一次攻击后MD5的状态”，《加密字节》第2卷第2期，1996年夏季。
[IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
[IEEE802]局域网和城域网的IEEE标准：概述和体系结构，ANSI/IEEE标准802，1990年。
[IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998.
[IEEE8021Q]IEEE局域网和城域网标准：虚拟桥接局域网标准草案，P802.1Q，1998年1月。
[IEEE8023] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996.
[IEEE8023]ISO/IEC 8802-3信息技术-系统间远程通信和信息交换-局域网和城域网-通用规范-第3部分：带冲突检测的载波侦听多路访问（CSMA/CD）访问方法和物理层规范（也可称为ANSI/IEEE标准802.3-1996），1996年。
[IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999.
[IEEE80211]信息技术-系统间电信和信息交换-局域网和城域网-特定要求第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范，IEEE标准802.11-1999，1999。
[Berkeley] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting Mobile Communications: The Insecurity of 802.11", ACM SIGMOBILE, Seventh Annual International Conference on Mobile Computing and Networking, July 2001, Rome, Italy.
[伯克利]Borisov，N.，Goldberg，I.和D.Wagner，“拦截移动通信：802.11的不安全”，ACM SIGMOBILE，第七届移动计算和网络国际年会，2001年7月，意大利罗马。
[Arbaugh] Arbaugh, W., Shankar, N. and J.Y.C. Wan, "Your 802.11 Wireless Network has No Clothes", Department of Computer Science, University of Maryland, College Park, March 2001.
阿宝，W.，Shankar，N和J.Y.C. Wan，“你的802.11无线网络没有衣服”，马里兰大学计算机科学系，学院公园，2001年3月。
[Fluhrer] Fluhrer, S., Mantin, I. and A. Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4", Eighth Annual Workshop on Selected Areas in Cryptography, Toronto, Canada, August 2001.
[Fluhrer]Fluhrer，S.，Mantin，I.和A.Shamir，“RC4密钥调度算法的弱点”，第八届密码学选定领域年度研讨会，加拿大多伦多，2001年8月。
[Stubbl] Stubblefield, A., Ioannidis, J. and A. Rubin, "Using the Fluhrer, Mantin and Shamir Attack to Break WEP", 2002 NDSS Conference.
[Stubbl]Stubblefield，A.，Ioannidis，J.和A.Rubin，“使用Fluhrer，Mantin和Shamir攻击破坏WEP”，2002年NDSS会议。
The following table provides a guide to which attributes MAY be sent and received as part of IEEE 802.1X authentication. L3 denotes attributes that require layer 3 capabilities, and thus may not be supported by all Authenticators. For each attribute, the reference provides the definitive information on usage.
下表提供了作为IEEE 802.1X身份验证的一部分可以发送和接收哪些属性的指南。L3表示需要第3层功能的属性，因此并非所有身份验证程序都支持这些属性。对于每个属性，参考提供了有关用法的最终信息。
802.1X # Attribute
X 1 User-Name [RFC2865]
2 User-Password [RFC2865]
3 CHAP-Password [RFC2865]
X 4 NAS-IP-Address [RFC2865]
X 5 NAS-Port [RFC2865]
X 6 Service-Type [RFC2865]
7 Framed-Protocol [RFC2865]
L3 8 Framed-IP-Address [RFC2865]
L3 9 Framed-IP-Netmask [RFC2865]
L3 10 Framed-Routing [RFC2865]
X 11 Filter-Id [RFC2865]
X 12 Framed-MTU [RFC2865]
13 Framed-Compression [RFC2865]
L3 14 Login-IP-Host [RFC2865]
L3 15 Login-Service [RFC2865]
L3 16 Login-TCP-Port [RFC2865]
18 Reply-Message [RFC2865]
19 Callback-Number [RFC2865]
20 Callback-Id [RFC2865]
L3 22 Framed-Route [RFC2865]
L3 23 Framed-IPX-Network [RFC2865]
X 24 State [RFC2865]
X 25 Class [RFC2865]
X 26 Vendor-Specific [RFC2865]
X 27 Session-Timeout [RFC2865]
X 28 Idle-Timeout [RFC2865]
X 29 Termination-Action [RFC2865]
X 30 Called-Station-Id [RFC2865]
X 31 Calling-Station-Id [RFC2865]
X 32 NAS-Identifier [RFC2865]
X 33 Proxy-State [RFC2865]
34 Login-LAT-Service [RFC2865]
35 Login-LAT-Node [RFC2865]
36 Login-LAT-Group [RFC2865]
802.1X # Attribute
802.1X # Attribute
X 1 User-Name [RFC2865]
2 User-Password [RFC2865]
3 CHAP-Password [RFC2865]
X 4 NAS-IP-Address [RFC2865]
X 5 NAS-Port [RFC2865]
X 6 Service-Type [RFC2865]
7 Framed-Protocol [RFC2865]
L3 8 Framed-IP-Address [RFC2865]
L3 9 Framed-IP-Netmask [RFC2865]
L3 10 Framed-Routing [RFC2865]
X 11 Filter-Id [RFC2865]
X 12 Framed-MTU [RFC2865]
13 Framed-Compression [RFC2865]
L3 14 Login-IP-Host [RFC2865]
L3 15 Login-Service [RFC2865]
L3 16 Login-TCP-Port [RFC2865]
18 Reply-Message [RFC2865]
19 Callback-Number [RFC2865]
20 Callback-Id [RFC2865]
L3 22 Framed-Route [RFC2865]
L3 23 Framed-IPX-Network [RFC2865]
X 24 State [RFC2865]
X 25 Class [RFC2865]
X 26 Vendor-Specific [RFC2865]
X 27 Session-Timeout [RFC2865]
X 28 Idle-Timeout [RFC2865]
X 29 Termination-Action [RFC2865]
X 30 Called-Station-Id [RFC2865]
X 31 Calling-Station-Id [RFC2865]
X 32 NAS-Identifier [RFC2865]
X 33 Proxy-State [RFC2865]
34 Login-LAT-Service [RFC2865]
35 Login-LAT-Node [RFC2865]
36 Login-LAT-Group [RFC2865]
802.1X # Attribute
802.1X # Attribute
L3 37 Framed-AppleTalk-Link [RFC2865]
L3 38 Framed-AppleTalk-Network [RFC2865]
L3 39 Framed-AppleTalk-Zone [RFC2865]
X 40 Acct-Status-Type [RFC2866]
X 41 Acct-Delay-Time [RFC2866]
X 42 Acct-Input-Octets [RFC2866]
X 43 Acct-Output-Octets [RFC2866]
X 44 Acct-Session-Id [RFC2866]
X 45 Acct-Authentic [RFC2866]
X 46 Acct-Session-Time [RFC2866]
X 47 Acct-Input-Packets [RFC2866]
X 48 Acct-Output-Packets [RFC2866]
X 49 Acct-Terminate-Cause [RFC2866]
X 50 Acct-Multi-Session-Id [RFC2866]
X 51 Acct-Link-Count [RFC2866]
X 52 Acct-Input-Gigawords [RFC2869]
X 53 Acct-Output-Gigawords [RFC2869]
X 55 Event-Timestamp [RFC2869]
60 CHAP-Challenge [RFC2865]
X 61 NAS-Port-Type [RFC2865]
62 Port-Limit [RFC2865]
63 Login-LAT-Port [RFC2865]
X 64 Tunnel-Type [RFC2868]
X 65 Tunnel-Medium-Type [RFC2868]
L3 66 Tunnel-Client-Endpoint [RFC2868]
L3 67 Tunnel-Server-Endpoint [RFC2868]
L3 68 Acct-Tunnel-Connection [RFC2867]
L3 69 Tunnel-Password [RFC2868]
70 ARAP-Password [RFC2869]
71 ARAP-Features [RFC2869]
72 ARAP-Zone-Access [RFC2869]
73 ARAP-Security [RFC2869]
74 ARAP-Security-Data [RFC2869]
75 Password-Retry [RFC2869]
76 Prompt [RFC2869]
X 77 Connect-Info [RFC2869]
X 78 Configuration-Token [RFC2869]
X 79 EAP-Message [RFC3579]
X 80 Message-Authenticator [RFC3579]
X 81 Tunnel-Private-Group-ID [RFC2868]
L3 82 Tunnel-Assignment-ID [RFC2868]
X 83 Tunnel-Preference [RFC2868]
84 ARAP-Challenge-Response [RFC2869]
802.1X # Attribute
802.1X # Attribute
L3 37 Framed-AppleTalk-Link [RFC2865]
L3 38 Framed-AppleTalk-Network [RFC2865]
L3 39 Framed-AppleTalk-Zone [RFC2865]
X 40 Acct-Status-Type [RFC2866]
X 41 Acct-Delay-Time [RFC2866]
X 42 Acct-Input-Octets [RFC2866]
X 43 Acct-Output-Octets [RFC2866]
X 44 Acct-Session-Id [RFC2866]
X 45 Acct-Authentic [RFC2866]
X 46 Acct-Session-Time [RFC2866]
X 47 Acct-Input-Packets [RFC2866]
X 48 Acct-Output-Packets [RFC2866]
X 49 Acct-Terminate-Cause [RFC2866]
X 50 Acct-Multi-Session-Id [RFC2866]
X 51 Acct-Link-Count [RFC2866]
X 52 Acct-Input-Gigawords [RFC2869]
X 53 Acct-Output-Gigawords [RFC2869]
X 55 Event-Timestamp [RFC2869]
60 CHAP-Challenge [RFC2865]
X 61 NAS-Port-Type [RFC2865]
62 Port-Limit [RFC2865]
63 Login-LAT-Port [RFC2865]
X 64 Tunnel-Type [RFC2868]
X 65 Tunnel-Medium-Type [RFC2868]
L3 66 Tunnel-Client-Endpoint [RFC2868]
L3 67 Tunnel-Server-Endpoint [RFC2868]
L3 68 Acct-Tunnel-Connection [RFC2867]
L3 69 Tunnel-Password [RFC2868]
70 ARAP-Password [RFC2869]
71 ARAP-Features [RFC2869]
72 ARAP-Zone-Access [RFC2869]
73 ARAP-Security [RFC2869]
74 ARAP-Security-Data [RFC2869]
75 Password-Retry [RFC2869]
76 Prompt [RFC2869]
X 77 Connect-Info [RFC2869]
X 78 Configuration-Token [RFC2869]
X 79 EAP-Message [RFC3579]
X 80 Message-Authenticator [RFC3579]
X 81 Tunnel-Private-Group-ID [RFC2868]
L3 82 Tunnel-Assignment-ID [RFC2868]
X 83 Tunnel-Preference [RFC2868]
84 ARAP-Challenge-Response [RFC2869]
802.1X # Attribute
802.1X # Attribute
X 85 Acct-Interim-Interval [RFC2869]
X 86 Acct-Tunnel-Packets-Lost [RFC2867]
X 87 NAS-Port-Id [RFC2869]
L3 88 Framed-Pool [RFC2869]
L3 90 Tunnel-Client-Auth-ID [RFC2868]
L3 91 Tunnel-Server-Auth-ID [RFC2868]
X 95 NAS-IPv6-Address [RFC3162]
96 Framed-Interface-Id [RFC3162]
L3 97 Framed-IPv6-Prefix [RFC3162]
L3 98 Login-IPv6-Host [RFC3162]
L3 99 Framed-IPv6-Route [RFC3162]
L3 100 Framed-IPv6-Pool [RFC3162]
X 101 Error-Cause [RFC3576]
802.1X # Attribute
802.1X # Attribute
X 85 Acct-Interim-Interval [RFC2869]
X 86 Acct-Tunnel-Packets-Lost [RFC2867]
X 87 NAS-Port-Id [RFC2869]
L3 88 Framed-Pool [RFC2869]
L3 90 Tunnel-Client-Auth-ID [RFC2868]
L3 91 Tunnel-Server-Auth-ID [RFC2868]
X 95 NAS-IPv6-Address [RFC3162]
96 Framed-Interface-Id [RFC3162]
L3 97 Framed-IPv6-Prefix [RFC3162]
L3 98 Login-IPv6-Host [RFC3162]
L3 99 Framed-IPv6-Route [RFC3162]
L3 100 Framed-IPv6-Pool [RFC3162]
X 101 Error-Cause [RFC3576]
802.1X # Attribute
Key === X = May be used with IEEE 802.1X authentication L3 = Implemented only by Authenticators with Layer 3 capabilities
密钥===X=可与IEEE 802.1X身份验证一起使用L3=仅由具有第3层功能的身份验证程序实现
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执行董事。
The authors would like to acknowledge Bob O'Hara of Airespace, David Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of Microsoft, Andrea Li, Albert Young and Dave Bagby of 3Com for contributions to this document.
作者感谢Airespace的Bob O'Hara、Cisco的David Halasz、微软的Tim Moore、Sachin Seth和Ashwin Palekar、3Com的Andrea Li、Albert Young和Dave Bagby对本文件的贡献。
Paul Congdon Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747
保罗·康登惠普公司惠普ProCurve Networking 8000 Foothills Blvd，加利福尼亚州罗斯维尔市南5662号，邮编95747
Phone: +1 916 785 5753
Fax: +1 916 785 8478
EMail: paul_congdon@hp.com
Phone: +1 916 785 5753
Fax: +1 916 785 8478
EMail: paul_congdon@hp.com
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
Andrew Smith Trapeze Networks 5753 W. Las Positas Blvd. Pleasanton, CA 94588-4084
安德鲁·史密斯吊架网络5753西拉斯波西塔斯大道。加利福尼亚州普莱森顿94588-4084
Fax: +1 415 345 1827
EMail: ah_smith@acm.org
Fax: +1 415 345 1827
EMail: ah_smith@acm.org
John Roese Enterasys
约翰·罗斯企业
Phone: +1 603 337 1506
EMail: jjr@enterasys.com
Phone: +1 603 337 1506
EMail: jjr@enterasys.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004
格伦佐恩思科系统有限公司，地址：华盛顿州贝尔维尤第108大道500号，邮编：98004
Phone: +1 425 438 8218
Fax: +1 425 438 1848
EMail: gwz@cisco.com
Phone: +1 425 438 8218
Fax: +1 425 438 1848
EMail: gwz@cisco.com
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编辑功能的资金目前由互联网协会提供。