Network Working Group L. Morand
Request for Comments: 5192 France Telecom R&D
Category: Standards Track A. Yegin
Samsung
S. Kumar
Tech Mahindra Ltd
S. Madanapalli
Samsung
May 2008
Network Working Group L. Morand
Request for Comments: 5192 France Telecom R&D
Category: Standards Track A. Yegin
Samsung
S. Kumar
Tech Mahindra Ltd
S. Madanapalli
Samsung
May 2008
DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents
用于承载网络访问身份验证（PANA）身份验证代理的协议的DHCP选项
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）。本备忘录的分发不受限制。
Abstract
摘要
This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more PANA (Protocol for carrying Authentication for Network Access) Authentication Agents (PAAs). This is one of the methods that a PANA Client (PaC) can use to locate PAAs.
本文档定义了新的DHCPv4和DHCPv6选项，其中包含一个IP地址列表，用于定位一个或多个PANA（用于承载网络访问身份验证的协议）身份验证代理（PAA）。这是PANA客户端（PaC）可以用来定位PAAs的方法之一。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. PANA Authentication Agent DHCPv4 Option . . . . . . . . . . . . 3
5. PANA Authentication Agent DHCPv6 Option . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. PANA Authentication Agent DHCPv4 Option . . . . . . . . . . . . 3
5. PANA Authentication Agent DHCPv6 Option . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
The Protocol for carrying Authentication for Network Access (PANA) [RFC5191] defines a new Extensible Authentication Protocol (EAP) [RFC3748] lower layer that uses IP between the protocol end-points.
用于承载网络访问身份验证（PANA）的协议[RFC5191]定义了一个新的可扩展身份验证协议（EAP）[RFC3748]较低层，该层在协议端点之间使用IP。
The PANA protocol is run between a PANA Client (PaC) and a PANA Authentication Agent (PAA) in order to perform authentication and authorization for the network access service.
PANA协议在PANA客户端（PaC）和PANA身份验证代理（PAA）之间运行，以便对网络访问服务执行身份验证和授权。
This document specifies DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options that allow PANA clients (PaCs) to discover PANA Authentication Agents (PAAs). This is one of the methods for locating PAAs.
本文档指定了DHCPv4[RFC2131]和DHCPv6[RFC3315]选项，允许PANA客户端（PAC）发现PANA身份验证代理（PAA）。这是定位PAAs的方法之一。
The DHCP options defined in this document are used only as a PAA discovery mechanism. These DHCP options MUST NOT be used to perform any negotiation of the use of PANA between the PaC and a PAA.
本文档中定义的DHCP选项仅用作PAA发现机制。这些DHCP选项不得用于在PaC和PAA之间就PANA的使用进行任何协商。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the DHCP terminology defined in [RFC2131], [RFC2132], and [RFC3315].
本文档使用[RFC2131]、[RFC2132]和[RFC3315]中定义的DHCP术语。
This document uses the PANA terminology defined in [RFC5191]. In particular, the following terms are defined:
本文件使用[RFC5191]中定义的PANA术语。具体而言，定义了以下术语：
PANA Client (PaC):
泛亚客户（PaC）：
The client side of the protocol that resides in the access device (e.g., laptop, PDA, etc.). It is responsible for providing the credentials in order to prove its identity (authentication) for network access authorization. The PaC and the EAP peer are co-located in the same access device.
驻留在接入设备（如笔记本电脑、PDA等）中的协议客户端。它负责提供凭证，以证明其网络访问授权的身份（身份验证）。PaC和EAP对等机位于同一接入设备中。
PANA Authentication Agent (PAA):
PANA身份验证代理（PAA）：
The protocol entity in the access network whose responsibility it is to verify the credentials provided by a PANA client (PaC) and authorize network access to the access device. The PAA and
接入网络中的协议实体，其职责是验证PANA客户端（PaC）提供的凭据并授权对接入设备的网络访问。PAA和
the EAP authenticator (and optionally the EAP server) are colocated in the same node.
EAP验证器（以及可选的EAP服务器）位于同一节点中。
This DHCPv4 option carries a list of 32-bit (binary) IPv4 addresses indicating PANA Authentication Agents (PAAs) available to the PANA client (PaC).
此DHCPv4选项包含一个32位（二进制）IPv4地址列表，指示PANA客户端（PaC）可用的PANA身份验证代理（PAA）。
The DHCPv4 option for PANA Authentication Agent has the format shown in Figure 1.
PANA认证代理的DHCPv4选项的格式如图1所示。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ PAA IPv4 Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PAA DHCPv4 option
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ PAA IPv4 Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PAA DHCPv4 option
option-code: OPTION_PANA_AGENT (136).
选项代码：选项PANA_代理（136）。
option-length: Length of the 'options' field in octets; MUST be a multiple of four (4).
选项长度：“选项”字段的长度（以八位字节为单位）；必须是四（4）的倍数。
PAA IPv4 Address: IPv4 address of a PAA for the client to use. The PAAs are listed in the order of preference for use by the client.
PAA IPv4地址：客户端要使用的PAA的IPv4地址。PaA按客户使用的优先顺序列出。
A PaC (DHCPv4 client) SHOULD request the PAA DHCPv4 Option in a Parameter Request List, as described in [RFC2131] and [RFC2132].
PaC（DHCPv4客户端）应在参数请求列表中请求PAA DHCPv4选项，如[RFC2131]和[RFC2132]中所述。
If configured with a (list of) PAA address(es), a DHCPv4 server SHOULD send a client the PAA DHCPv4 option, even if this option is not explicitly requested by the client.
如果配置了（列表）PAA地址，则DHCPv4服务器应向客户端发送PAA DHCPv4选项，即使客户端未明确请求此选项。
A PaC (DHCPv4 client) receiving the PAA DHCPv4 option SHOULD use the (list of) IP address(es) to locate PAA(s).
接收PAA DHCPv4选项的PaC（DHCPv4客户端）应使用（列表）IP地址来定位PAA。
The PaC (DHCPv4 client) MUST try the records in the order listed in the PAA DHCPv4 option received from the DHCPv4 server.
PaC（DHCPv4客户端）必须按照从DHCPv4服务器接收的PAA DHCPv4选项中列出的顺序尝试记录。
This DHCPv6 option carries a list of 128-bit (binary) IPv6 addresses indicating PANA Authentication Agents (PAAs) available to the PANA client (PaC).
此DHCPv6选项包含一个128位（二进制）IPv6地址列表，指示PANA客户端（PaC）可用的PANA身份验证代理（PAA）。
The DHCPv6 option for PANA Authentication Agent has the format shown in Figure 2.
PANA Authentication Agent的DHCPv6选项的格式如图2所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ PAA IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PAA DHCPv6 option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ PAA IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PAA DHCPv6 option
option-code: OPTION_PANA_AGENT (40).
选项代码：选项PANA_代理（40）。
option-length: Length of the 'options' field in octets; MUST be a multiple of sixteen (16).
选项长度：“选项”字段的长度（以八位字节为单位）；必须是十六（16）的倍数。
PAA IPv6 Address: IPv6 address of a PAA for the client to use. The PAAs are listed in the order of preference for use by the client.
PAA IPv6地址：供客户端使用的PAA的IPv6地址。PaA按客户使用的优先顺序列出。
A PaC DHCPv6 client SHOULD request the PAA DHCPv6 option in an Options Request Option (ORO) as described in the DHCPv6 specification [RFC3315].
PaC DHCPv6客户机应在选项请求选项（ORO）中请求PAA DHCPv6选项，如DHCPv6规范[RFC3315]所述。
If configured with a (list of) PAA address(es), a DHCPv6 server SHOULD send a client the PAA DHCPv6 option, even if this option is not explicitly requested by the client.
如果配置了（列表）PAA地址，则DHCPv6服务器应向客户端发送PAA DHCPv6选项，即使客户端未明确请求此选项。
A PaC (DHCPv6 client) receiving the PAA DHCPv6 option SHOULD use the (list of) IP address(es) to locate PAA(s).
接收PAA DHCPv6选项的PaC（DHCPv6客户端）应使用（列表）IP地址来定位PAA。
The PaC (DHCPv6 client) MUST try the records in the order listed in the PAA DHCPv6 option received from the DHCPv6 server.
PaC（DHCPv6客户端）必须按照从DHCPv6服务器接收的PAA DHCPv6选项中列出的顺序尝试记录。
The following DHCPv4 option code for PANA Authentication Agent options has been assigned by IANA:
IANA已为PANA身份验证代理选项分配了以下DHCPv4选项代码：
Option Name Value Described in
-----------------------------------------------
OPTION_PANA_AGENT 136 Section 4
Option Name Value Described in
-----------------------------------------------
OPTION_PANA_AGENT 136 Section 4
The following DHCPv6 option code for PANA Authentication Agent options has been assigned by IANA:
IANA已为PANA身份验证代理选项分配了以下DHCPv6选项代码：
Option Name Value Described in
------------------------------------------------
OPTION_PANA_AGENT 40 Section 5
Option Name Value Described in
------------------------------------------------
OPTION_PANA_AGENT 40 Section 5
The security considerations in [RFC2131], [RFC2132], and [RFC3315] apply. If an adversary manages to modify the response from a DHCP server or insert its own response, a PANA Client could be led to contact a rogue PANA Authentication Agent, possibly one that then intercepts authentication requests and/or denies network access to the access device.
[RFC2131]、[RFC2132]和[RFC3315]中的安全注意事项适用。如果对手设法修改DHCP服务器的响应或插入自己的响应，则PANA客户端可能会被引导与流氓PANA身份验证代理联系，该代理可能会拦截身份验证请求和/或拒绝访问设备的网络访问。
In most networks, the DHCP exchange that delivers the options prior to network access authentication is neither integrity protected nor origin authenticated. Therefore, the options defined in this document MUST NOT be used to perform any negotiation on the use of PANA between the PANA Client and a PANA Authentication Agent. Using the presence (or absence) of these DHCP options as an indication of network mandating PANA authentication (or not) is an example of such a negotiation mechanism. This negotiation would allow bidding-down attacks by making the clients choose to use a lower-grade security mechanism (or even no security at all).
在大多数网络中，在网络访问身份验证之前提供选项的DHCP交换既没有完整性保护，也没有原始身份验证。因此，本文档中定义的选项不得用于在PANA客户端和PANA身份验证代理之间就PANA的使用进行任何协商。使用这些DHCP选项的存在（或不存在）作为网络强制PANA身份验证（或不存在）的指示是此类协商机制的一个示例。这种协商将允许通过让客户端选择使用较低级别的安全机制（甚至根本没有安全机制）来降低攻击。
We would like to thank Ralph Droms, Stig Venaas, Ted Lemon, Andre Kostur and Bernie Volz for their valuable comments. We would also like to thank Jari Arkko, Thomas Narten and Bernard Aboba that provided several reviews, as well as all members of the PANA and DHC working groups that contribute to improve this document.
我们要感谢拉尔夫·德罗姆斯、斯蒂格·维纳斯、特德·莱蒙、安德烈·科斯特尔和伯尼·沃尔兹的宝贵意见。我们还要感谢Jari Arkko、Thomas Narten和Bernard Aboba进行了多次审查，并感谢PANA和DHC工作组的所有成员为改进本文件做出了贡献。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191]Forsberg，D.，Ohba，Y.，Patil，B.，Tschofenig，H.，和A.Yegin，“承载网络接入认证（PANA）的协议”，RFC 51912008年5月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
Authors' Addresses
作者地址
Lionel Morand France Telecom R&D
莱昂内尔·莫兰法国电信研发部
EMail: lionel.morand@orange-ftgroup.com
EMail: lionel.morand@orange-ftgroup.com
Alper E. Yegin Samsung
阿尔珀·E·耶金三星
EMail: a.yegin@partner.samsung.com
EMail: a.yegin@partner.samsung.com
Suraj Kumar Tech Mahindra Ltd
苏拉杰·库马尔技术马欣德拉有限公司
EMail: surajk@techmahindra.com
EMail: surajk@techmahindra.com
Syam Madanapalli Samsung
Syam Madanapalli三星
EMail: syam@samsung.com
EMail: syam@samsung.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.