Network Working Group R. Droms
Request for Comments: 4014 J. Schnizlein
Category: Standards Track Cisco Systems
February 2005
Network Working Group R. Droms
Request for Comments: 4014 J. Schnizlein
Category: Standards Track Cisco Systems
February 2005
Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option
动态主机配置协议（DHCP）中继代理信息选项的远程身份验证拨入用户服务（RADIUS）属性子选项
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client.
RADIUS属性子选项使网元能够将RADIUS身份验证期间接收到的标识和授权属性传递给DHCP服务器。当DHCP服务器从中继代理接收到包含RADIUS属性子选项的消息时，它将提取子选项的内容，并在为客户端选择配置参数时使用该信息。
The RADIUS Attributes suboption for the DHCP Relay Agent option provides a way in which a NAS can pass attributes obtained from a RADIUS server to a DHCP server [1]. IEEE 802.1X [2] is an example of a mechanism through which a NAS such as a switch or a wireless LAN access point can authenticate the identity of the user of a device before providing layer 2 network access with RADIUS as the Authentication Service, as specified in RFC 3580 [8]. In IEEE 802.1X authenticated access, a device must first exchange some authentication credentials with the NAS. The NAS then supplies these credentials to a RADIUS server, which eventually sends either an Access-Accept or an Access-Reject in response to an Access-Request. The NAS, based on the reply of the RADIUS server, then allows or denies network access to the requesting device.
DHCP中继代理选项的RADIUS属性子选项提供了NAS将从RADIUS服务器获得的属性传递给DHCP服务器的方式[1]。IEEE 802.1X[2]是一种机制的示例，通过该机制，NAS（如交换机或无线LAN接入点）可以在提供以RADIUS作为身份验证服务的第2层网络访问之前，对设备用户的身份进行身份验证，如RFC 3580[8]中所述。在IEEE 802.1X认证访问中，设备必须首先与NAS交换一些认证凭据。NAS然后将这些凭据提供给RADIUS服务器，RADIUS服务器最终会发送访问接受或访问拒绝以响应访问请求。NAS基于RADIUS服务器的回复，然后允许或拒绝对请求设备的网络访问。
Figure 1 summarizes the message exchange among the participants in IEEE 802.1X authentication.
图1总结了IEEE 802.1X认证参与者之间的消息交换。
+-----------------+
|Device requesting|
| network access |
+-----------------+
| ^
| |
(1) Request for access
| |
| (4) Success/Failure
v |
+-----------------+
| NAS |
|(IEEE 802.1X and |
|DHCP relay agent}|
+-----------------+
| ^
| |
(2) Request for authentication
| |
| (3) Access-Accept/Reject
v |
+-----------------+
| RADIUS |
| Server |
+-----------------+
+-----------------+
|Device requesting|
| network access |
+-----------------+
| ^
| |
(1) Request for access
| |
| (4) Success/Failure
v |
+-----------------+
| NAS |
|(IEEE 802.1X and |
|DHCP relay agent}|
+-----------------+
| ^
| |
(2) Request for authentication
| |
| (3) Access-Accept/Reject
v |
+-----------------+
| RADIUS |
| Server |
+-----------------+
Figure 1
图1
The access device acts as an IEEE 802.1X Authenticator and adds a DHCP relay agent option that includes a RADIUS Attributes suboption to DHCP messages. At the successful conclusion of IEEE 802.1X authentication, a RADIUS Access-Accept provides attributes for service authorizations to the NAS. The NAS stores these attributes locally. When the NAS subsequently relays DHCP messages from the network device, the NAS adds these attributes in a RADIUS Attributes suboption. The RADIUS Attributes suboption is another suboption of the Relay Agent Information option [5].
接入设备充当IEEE 802.1X认证器，并添加DHCP中继代理选项，该选项包括DHCP消息的RADIUS属性子选项。在IEEE 802.1X认证成功结束时，RADIUS访问接受为NAS提供服务授权属性。NAS在本地存储这些属性。当NAS随后中继来自网络设备的DHCP消息时，NAS会将这些属性添加到RADIUS属性子选项中。“半径属性”子选项是中继代理信息选项[5]的另一个子选项。
The RADIUS Attributes suboption described in this document is not limited to use in conjunction with IEEE 802.1X and can be used to carry RADIUS attributes obtained by the relay agent for any reason. That is, the option is not limited to use with IEEE 802.1X but is constrained by RADIUS semantics (see Section 4).
本文档中描述的RADIUS Attributes子选项不限于与IEEE 802.1X结合使用，可用于承载中继代理出于任何原因获得的RADIUS属性。也就是说，该选项不限于与IEEE 802.1X一起使用，而是受RADIUS语义的约束（参见第4节）。
The scope of applicability of this specification is such that robust interoperability is only guaranteed for RADIUS service implementations that exist within the same scope as does the DHCP service implementation, i.e., within a single, localized administrative domain. Global interoperability of this specification, across administrative domains, is not required.
本规范的适用范围是，只有与DHCP服务实现在同一范围内的RADIUS服务实现（即，在单个本地化管理域内）才能保证健壮的互操作性。本规范不需要跨管理域的全局互操作性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
Within this specification, the use of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" is with respect to RADIUS clients and servers that implement the optional features of this specification. The use of these key words does not create any normative requirements outside of that scope, and does not modify the base RADIUS specifications, such as RFC 2865 [4].
在本规范中，关键字“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”的使用与实现本规范可选功能的RADIUS客户端和服务器有关。使用这些关键词不会产生超出该范围的任何规范性要求，也不会修改基准半径规范，如RFC 2865[4]。
The following terms are used as defined in RFC 2131 and RFC 3046: DHCP relay agent, DHCP server, DHCP client.
按照RFC 2131和RFC 3046中的定义使用以下术语：DHCP中继代理、DHCP服务器、DHCP客户端。
The following terms are used in conjunction with RADIUS:
以下术语与半径一起使用：
RADIUS server: A RADIUS server is responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user.
RADIUS服务器：RADIUS服务器负责接收用户连接请求、验证用户，然后返回客户端向用户提供服务所需的所有配置信息。
Attribute: A Type-Length-Value tuple encapsulating data elements as defined in RFC 2865 [4].
属性：封装RFC 2865[4]中定义的数据元素的类型长度值元组。
NAS: A Network Access Server (NAS) provides access to the network and operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers and then acting on the response that is returned. Unlike a traditional dial NAS, the NAS considered here may not have a protocol such as PPP through which it can pass configuration information from the RADIUS attributes to the client.
NAS：网络访问服务器（NAS）提供对网络的访问，并作为RADIUS的客户端运行。客户端负责将用户信息传递到指定的RADIUS服务器，然后对返回的响应执行操作。与传统的拨号NAS不同，此处考虑的NAS可能没有PPP之类的协议，通过该协议可以将配置信息从RADIUS属性传递给客户端。
The following terms are used as defined in the IEEE 802.1X protocol: Authenticator, Supplicant.
按照IEEE 802.1X协议中的定义使用以下术语：验证器、请求者。
The RADIUS Attributes suboption is a new suboption for the DHCP Relay Agent option.
RADIUS属性子选项是DHCP中继代理选项的新子选项。
The format of the RADIUS Attributes suboption is as follows:
“半径属性”子选项的格式如下所示：
SubOpt Len RADIUS attributes
code
+-------+-----+------+------+------+------+--...-+------+
| 7 | N | o1 | o2 | o3 | o4 | | oN |
+-------+-----+------+------+------+------+--...-+------+
SubOpt Len RADIUS attributes
code
+-------+-----+------+------+------+------+--...-+------+
| 7 | N | o1 | o2 | o3 | o4 | | oN |
+-------+-----+------+------+------+------+--...-+------+
The RADIUS attributes are encoded according to the encoding rules in RFC 2865, in octets o1...oN.
半径属性根据RFC 2865中的编码规则进行编码，以八位字节o1…为单位。
The DHCP relay agent truncates the RADIUS attributes to fit in the RADIUS Attributes suboption.
DHCP中继代理将截断RADIUS属性以适合RADIUS属性子选项。
When the DHCP relay agent receives a DHCP message from the client, it MAY append a DHCP Relay Agent Information option containing the RADIUS Attributes suboption, along with any other suboptions it is configured to supply. The RADIUS Attributes suboption MUST only contain the attributes provided in the RADIUS Access/Accept message. The DHCP relay agent MUST NOT add more than one RADIUS Attributes suboption in a message.
当DHCP中继代理从客户端接收DHCP消息时，它可以附加一个包含RADIUS属性子选项的DHCP中继代理信息选项，以及它配置为提供的任何其他子选项。“RADIUS属性”子选项只能包含RADIUS访问/接受消息中提供的属性。DHCP中继代理在消息中不能添加多个RADIUS属性子选项。
The relay agent MUST include the User-Name and Framed-Pool attributes in the RADIUS Attributes suboption, if they are available, and MAY include other attributes.
中继代理必须在RADIUS属性子选项（如果可用）中包括用户名和帧池属性，并且可能包括其他属性。
To avoid dependencies between the address allocation and other state information between the RADIUS server and the DHCP server, the DHCP relay agent SHOULD include only the attributes in the table below in an instance of the RADIUS Attributes suboption. The table, based on the analysis in RFC 3580 [8], lists attributes that MAY be included:
为避免RADIUS服务器和DHCP服务器之间的地址分配和其他状态信息之间的依赖关系，DHCP中继代理应在RADIUS属性子选项的实例中仅包括下表中的属性。根据RFC 3580[8]中的分析，该表列出了可能包括的属性：
# Attribute
--- ---------
1 User-Name (RFC 2865 [3])
6 Service-Type (RFC 2865)
26 Vendor-Specific (RFC 2865)
27 Session-Timeout (RFC 2865)
88 Framed-Pool (RFC 2869)
100 Framed-IPv6-Pool (RFC 3162 [7])
# Attribute
--- ---------
1 User-Name (RFC 2865 [3])
6 Service-Type (RFC 2865)
26 Vendor-Specific (RFC 2865)
27 Session-Timeout (RFC 2865)
88 Framed-Pool (RFC 2869)
100 Framed-IPv6-Pool (RFC 3162 [7])
When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client. If the relay agent relays RADIUS attributes not included in the table in Section 4, the DHCP server SHOULD ignore them. If the DHCP server uses attributes not specified here, it might result in side effects not anticipated in the existing RADIUS specifications.
当DHCP服务器从中继代理接收到包含RADIUS属性子选项的消息时，它将提取子选项的内容，并在为客户端选择配置参数时使用该信息。如果中继代理中继第4节表中未包含的RADIUS属性，则DHCP服务器应忽略这些属性。如果DHCP服务器使用此处未指定的属性，则可能会导致现有RADIUS规范中未预期的副作用。
Relay agent options are exchanged only between relay agents and the DHCP server, so DHCP clients are never aware of their use.
中继代理选项仅在中继代理和DHCP服务器之间交换，因此DHCP客户端永远不会知道它们的使用。
Message authentication in DHCP for intradomain use where the out-of-band exchange of a shared secret is feasible is defined in RFC 3118 [6]. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in RFC 2131 [1].
RFC 3118[6]中定义了DHCP中用于域内使用的消息认证，其中共享秘密的带外交换是可行的。RFC 2131[1]中DHCP协议规范的第7节讨论了潜在的攻击风险。
The DHCP Relay Agent option depends on a trusted relationship between the DHCP relay agent and the server, as described in section 5 of RFC 3046 [5]. Although the introduction of fraudulent relay-agent options can be prevented by a perimeter defense that blocks these options unless the relay agent is trusted, a deeper defense using the authentication option for relay agent options [9] or IPsec [10] SHOULD be deployed as well.
DHCP中继代理选项取决于DHCP中继代理和服务器之间的信任关系，如RFC 3046[5]第5节所述。尽管引入欺诈性中继代理选项可以通过周界防御来防止，除非中继代理受信任，否则周界防御会阻止这些选项，但也应部署使用中继代理选项[9]或IPsec[10]的身份验证选项的更深入防御。
IANA has assigned the value of 7 for the DHCP Relay Agent Information option suboption code for this suboption. This document does not define any new namespaces or other constants for which IANA must maintain a registry.
IANA为此子选项的DHCP中继代理信息选项子选项代码分配了值7。本文档未定义IANA必须维护的任何新名称空间或其他常量。
Expert advice from Bernard Aboba, Paul Funk, David Nelson, Ashwin Palekar, and Greg Weber on avoiding RADIUS entanglements is gratefully acknowledged.
感谢Bernard Aboba、Paul Funk、David Nelson、Ashwin Palekar和Greg Weber关于避免半径纠缠的专家建议。
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[1] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[2] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port based Network Access Control", IEEE Standard 802.1X, March 2001.
[2] 电气和电子工程师协会，“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X，2001年3月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[4] Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[5] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[5] Patrick，M.，“DHCP中继代理信息选项”，RFC 3046，2001年1月。
[6] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[6] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[7] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[7] Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC3162001年8月。
[8] 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.
[8] Congdon，P.，Aboba，B.，Smith，A.，Zorn，G.，和J.Roese，“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”，RFC 35802003年9月。
[9] Stapp, M. and T. Lemon, "The Authentication Suboption for the DHCP Relay Agent Option", Work in Progress, October 2003.
[9] Stapp，M.和T.Lemon，“DHCP中继代理选项的身份验证子选项”，正在进行的工作，2003年10月。
[10] Droms, R., "Authentication of DHCP Relay Agent Options Using IPsec", Work in Progress, September 2003.
[10] Droms，R.，“使用IPsec认证DHCP中继代理选项”，正在进行的工作，2003年9月。
Authors' Addresses
作者地址
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Ralph Droms Cisco Systems美国马萨诸塞州Boxborough马萨诸塞大道1414号，邮编01719
EMail: rdroms@cisco.com
EMail: rdroms@cisco.com
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744 USA
美国马里兰州华盛顿堡Loughran路9123号思科系统公司John Schnizlein 20744
EMail: jschnizl@cisco.com
EMail: jschnizl@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.translate error, please retry
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.translate error, please retry
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。