Network Working Group M. Nakhjiri, Ed.
Request for Comments: 5030 Motorola
Category: Informational K. Chowdhury
Starent Networks
A. Lior
Bridgewater Systems
K. Leung
Cisco Systems
October 2007
Network Working Group M. Nakhjiri, Ed.
Request for Comments: 5030 Motorola
Category: Informational K. Chowdhury
Starent Networks
A. Lior
Bridgewater Systems
K. Leung
Cisco Systems
October 2007
Mobile IPv4 RADIUS Requirements
移动IPv4半径要求
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service (RADIUS) extensions to support Mobile IPv4. The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures.
本文档提供了适用性声明以及范围定义，用于指定远程身份验证拨入用户服务（RADIUS）扩展以支持移动IPv4。目标是允许指定RADIUS属性，以协助移动IPv4信令过程。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
To kick start the Mobile IPv4 [RFC3344] processing of its packets by Mobile IP agents, a mobile node (MN) needs to be able to acquire a pair of home and care of addresses (HoA and CoA, respectively), find a willing agent to act as a Home Agent (HA) for the MN and perform a registration process with the HA. The registration process consists of an exchange of a registration request and a registration reply message between the MN and the HA. The specification in [RFC3344] allows an MN to start the registration process prior to having acquired its home address or the address of its HA. Acquiring those parameters by the MN is typically part of a process referred to as bootstrapping.
为了启动移动IP代理对其分组的移动IPv4[RFC3344]处理，移动节点（MN）需要能够获取一对归属地址和转交地址（分别为HoA和CoA），找到愿意充当MN的归属代理（HA）的代理，并向HA执行注册过程。注册过程包括在MN和HA之间交换注册请求和注册回复消息。[RFC3344]中的规范允许MN在获取其家庭地址或其HA地址之前启动注册过程。MN获取这些参数通常是称为引导的过程的一部分。
Successful processing of registration request and reply messages, among other things, depends on successful creation and verification of a number of authentication extensions developed specifically to protect the integrity and security of these messages and the entities processing them, i.e., MN, HA and some times, Foreign Agents (FAs) [RFC3344]. Creation as well as verification of these extensions requires existence of trust relationships and shared keys between MN and each of the mobility agents. However, creation of these trust relationships, typically referred to as mobility security associations (MSAs), is considered outside the scope of the base Mobile IPv4 specification defined in [RFC3344]. Avoiding the scalability issues arising from creating static security associations between an MN and all possible mobility agents is desired. Thus, establishing the associations dynamically, using the pre-existing relationship between the MN and the AAA server, is preferred.
成功处理注册请求和回复消息，除其他外，取决于成功创建和验证专门为保护这些消息的完整性和安全性而开发的许多身份验证扩展，以及处理这些消息的实体，即MN、HA，有时还包括外国代理（FAs）[RFC3344]。创建和验证这些扩展需要MN和每个移动代理之间存在信任关系和共享密钥。然而，这些信任关系的创建（通常称为移动安全关联（MSA））被认为超出了[RFC3344]中定义的基本移动IPv4规范的范围。需要避免由于在MN和所有可能的移动代理之间创建静态安全关联而引起的可伸缩性问题。因此，优选使用MN和AAA服务器之间预先存在的关系来动态地建立关联。
To allow for utilization of an existing AAA infrastructure in the bootstrapping of the Mobile IPv4 parameters and security relationships, the Mobile IPv4 working group has developed Mobile IPv4 extensions to allow the MN to authenticate to the home AAA server [RFC4721]. The extensions also allow the MN to request assistance from the AAA server in creation of mobility security associations [RFC3957] with the mobility agents, using the pre-established trust relationship between the MN and its home AAA server.
为了允许在移动IPv4参数和安全关系的引导中利用现有的AAA基础设施，移动IPv4工作组开发了移动IPv4扩展，以允许MN向家庭AAA服务器进行身份验证[RFC4721]。扩展还允许MN使用MN与其家庭AAA服务器之间预先建立的信任关系，请求AAA服务器协助创建与移动代理的移动安全关联[RFC3957]。
While Mobile IPv4 extensions are necessary for implementing a utilization of the AAA infrastructure for Mobile IPv4 purposes, they are not sufficient. The interaction between the MN and the mobility agents (HA and FA) is based on Mobile IP signaling. However, the signaling beyond the mobility agents to the AAA server is typically based on AAA protocols. Around the time, when the specification of the aforementioned Mobile IP extensions was being developed, the AAA community was in the process of designing a successor to RADIUS.
虽然移动IPv4扩展对于实现AAA基础设施的移动IPv4用途是必要的，但它们还不够。MN和移动代理（HA和FA）之间的交互基于移动IP信令。然而，从移动代理到AAA服务器的信令通常基于AAA协议。大约在开发上述移动IP扩展规范的时候，AAA社区正在设计RADIUS的后续产品。
Thus, the Mobile IP group developed a set of guidelines and requirements from the Mobile IP standpoint [RFC2977] specifically for such a successor (which turned out to be Diameter). These requirements led to the development of a specification for using Diameter in Mobile IPv4 bootstrapping [RFC4004]. The requirements for Mobile IP Authentication, Authorization, and Accounting [RFC2977] were standardized after the standardization of RADIUS [RFC2865].
因此，移动IP小组从移动IP的角度[RFC2977]制定了一套指导方针和要求，专门针对这样一个继任者（后来证明是Diameter）。这些要求导致了在移动IPv4引导中使用Diameter的规范的开发[RFC4004]。在RADIUS[RFC2865]标准化之后，移动IP认证、授权和计费[RFC2977]的要求得到了标准化。
Thus, it is obvious that RADIUS does not and cannot meet all the requirements listed in [RFC2977] without undergoing an extensive design change. Consequently, within IETF no RADIUS attributes have been standardized for Mobile IP support thus far. However, in the absence of IETF standardized RADIUS attributes, different wireless SDOs have taken the path of developing Vendor Specific Attributes (VSAs) for providing Mobile IPv4 support. The use of different vendor specific RADIUS attributes and procedures for the same purpose of Mobile IPv4 bootstrapping at different SDOs is deemed to cause a lack interoperability between these wireless standards, potentially hindering mobility across these wireless networks.
因此，很明显，如果不进行广泛的设计变更，RADIUS不能也不能满足[RFC2977]中列出的所有要求。因此，在IETF中，迄今为止还没有为移动IP支持标准化RADIUS属性。然而，在缺乏IETF标准化RADIUS属性的情况下，不同的无线SDO已经采取了开发供应商特定属性（VSA）的方式来提供移动IPv4支持。在不同的SDO上使用不同的特定于供应商的RADIUS属性和过程来实现移动IPv4引导的相同目的被认为会导致这些无线标准之间缺乏互操作性，从而可能阻碍这些无线网络的移动性。
To respond to the described issue, it is desired to standardize a set of RADIUS attributes within IETF to allow a consistent and interoperable interaction with RADIUS based AAA infrastructure during the Mobile IPv4 Registration procedure. The bootstrapping attributes can include configuration parameters as well as material used for provisioning security of Mobile IPv4 messaging (authentication) as defined by [RFC4721] and [RFC3957].
为了响应所描述的问题，希望在IETF中标准化一组RADIUS属性，以允许在移动IPv4注册过程中与基于RADIUS的AAA基础设施进行一致且可互操作的交互。引导属性可以包括配置参数以及用于提供[RFC4721]和[RFC3957]定义的移动IPv4消息传递（身份验证）安全性的材料。
As it stands today, RADIUS cannot meet all the requirements in [RFC2977]. The purpose of these requirements is to define a set of goals and non-goals specifically for RADIUS when it comes to assisting mobile nodes and mobility agents in bootstrapping Mobile IPv4 operation.
目前，RADIUS无法满足[RFC2977]中的所有要求。这些要求的目的是在帮助移动节点和移动代理引导移动IPv4操作时，专门为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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Since this document serves as a requirement specification for RADIUS extensions that support Mobile IPv4 interaction with RADIUS infrastructure, the goals and non-goals refer to only those RADIUS extensions that are required to support Mobile IPv4.
由于本文档作为支持移动IPv4与RADIUS基础设施交互的RADIUS扩展的需求规范，因此目标和非目标仅指支持移动IPv4所需的RADIUS扩展。
The scope of the work is to standardize RADIUS attributes and to define the procedure by which the Mobile IPv4 agents (e.g., Home agent (HA) and Foreign Agent (FA)) map the Mobile IP registration message fields into the proposed RADIUS attributes, and vice versa.
工作范围是标准化RADIUS属性，并定义移动IPv4代理（例如，归属代理（HA）和外部代理（FA））将移动IP注册消息字段映射到建议的RADIUS属性的过程，反之亦然。
o RADIUS servers are REQUIRED to be able to understand and process the attributes to be defined for Mobile IPv4 support and to perform verification of authentication extensions specified in [RFC4721]. RADIUS proxies are expected to be able to forward messages including the Mobile IPv4 related attributes as they would with any other RADIUS messages and attributes.
o RADIUS服务器需要能够理解和处理为移动IPv4支持定义的属性，并执行[RFC4721]中指定的身份验证扩展。RADIUS代理预计能够转发包括移动IPv4相关属性的消息，就像它们转发任何其他RADIUS消息和属性一样。
o All RADIUS work MUST be backward compatible with existing RADIUS RFCs, including RFCs the following: [RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869], [RFC3576], [RFC3579], and [RFC3580].
o 所有RADIUS作业必须与现有RADIUS RFC向后兼容，包括以下RFC:[RFC2865]、[RFC2866]、[RFC2867]、[RFC2868]、[RFC2869]、[RFC3576]、[RFC3579]和[RFC3580]。
o Mobile IP agents (FA and HA) are REQUIRED to operate as RADIUS clients (NASes in context of [RFC2865]) when translating RADIUS signaling into Mobile IP signaling, and vice versa. Details on the behavior of Mobile IP agents as RADIUS clients are to be provided by the solution document describing the RADIUS extensions for Mobile IP support.
o 在将RADIUS信令转换为移动IP信令时，移动IP代理（FA和HA）需要作为RADIUS客户端（在[RFC2865]上下文中为NASE）运行，反之亦然。关于作为RADIUS客户端的移动IP代理行为的详细信息，将在描述移动IP支持的RADIUS扩展的解决方案文档中提供。
The scope of this work is to only standardize RADIUS attributes and to define the procedure by which the Mobile IPv4 agents (e.g., Home agent (HA) and Foreign Agent (FA)) map the Mobile IP registration message fields into the proposed RADIUS attributes, and vice versa. Extension of the functionality of the existing protocol or RADIUS servers is not intended. More specifically, the following are NON-GOALS:
这项工作的范围仅是标准化RADIUS属性，并定义移动IPv4代理（例如，归属代理（HA）和外部代理（FA））将移动IP注册消息字段映射到建议的RADIUS属性的过程，反之亦然。不打算扩展现有协议或RADIUS服务器的功能。更具体地说，以下是非目标：
o Enhancing RADIUS Security: Creating new security properties for RADIUS, such as creating key transport capabilities is not the goal. No new security mechanisms are to be defined for the transport of RADIUS Access Requests in relation to the support of Mobile IPv4 bootstrapping. Existing RADIUS authentication procedures, e.g., Message-Authenticator (80) described in [RFC2869], are used. The security considerations for using RADIUS in bootstrapping Mobile IPv4 are described in a later section of this document.
o 增强RADIUS安全性：目标不是为RADIUS创建新的安全属性，例如创建关键传输功能。对于支持移动IPv4引导的RADIUS访问请求的传输，不需要定义新的安全机制。使用现有的RADIUS认证程序，例如[RFC2869]中描述的消息认证器（80）。在引导移动IPv4时使用RADIUS的安全注意事项将在本文档后面的一节中介绍。
o Enhancing RADIUS transport reliability: The transport properties of RADIUS remain intact. No new reliability mechanisms are defined in the transport of such Access Requests.
o 增强RADIUS传输可靠性：RADIUS的传输特性保持不变。在这种访问请求的传输中没有定义新的可靠性机制。
o Extending RADIUS message set: RADIUS extensions for bootstrapping Mobile IPv4 are not to define new RADIUS messages. The Diameter Mobile IP application [RFC4004] has defined new command codes to support Mobile IP signaling, depending on whether Diameter server is dealing with a Mobile IP HA or an FA. RADIUS currently does not have any messages that correspond to these Diameter commands. Instead, RADIUS extensions for Mobile IPv4 bootstrapping need to provide proposals for new RADIUS attributes that facilitate Diameter-RADIUS messaging translation without defining any new RADIUS messaging. At the same time, the RADIUS extensions for Mobile IPv4 need to re-use Diameter AVPs to the fullest extent possible.
o 扩展RADIUS消息集：用于引导移动IPv4的RADIUS扩展不用于定义新的RADIUS消息。Diameter移动IP应用程序[RFC4004]定义了支持移动IP信令的新命令代码，具体取决于Diameter服务器是处理移动IP HA还是FA。RADIUS当前没有与这些Diameter命令对应的任何消息。相反，用于移动IPv4引导的RADIUS扩展需要为新的RADIUS属性提供建议，以便于在不定义任何新RADIUS消息的情况下进行Diameter RADIUS消息传递转换。同时，移动IPv4的RADIUS扩展需要尽可能充分地重用Diameter AVP。
o RFC 2977 compatibility: Extending RADIUS in a way that fulfills the full list of requirements in [RFC2977] will not be attempted.
o RFC 2977兼容性：不尝试以满足[RFC2977]中完整要求列表的方式扩展半径。
A specification of the RADIUS extensions for Mobile IPv4 needs to describe the full set of attributes required for RADIUS-Mobile IP interaction. While some of the attributes may already be standardized, others will require standardization and IANA type assignments.
移动IPv4的RADIUS扩展规范需要描述RADIUS移动IP交互所需的全套属性。虽然某些属性可能已经标准化，但其他属性将需要标准化和IANA类型分配。
This requirement document does not allocate any numbers, so there are no IANA considerations. On the other hand, future solution documents for RADIUS support of Mobile IPv4 will likely introduce new RADIUS attributes. Thus, those documents will need new attribute type numbers assigned by IANA.
本需求文件未分配任何编号，因此不考虑IANA。另一方面，未来支持移动IPv4的RADIUS解决方案文档可能会引入新的RADIUS属性。因此，这些文件将需要IANA分配的新属性类型编号。
Enhancing security properties of RADIUS are a specific non-goal for the RADIUS extensions providing support for Mobile IP. Also, as this is a requirements document and not a solution specification document, no new security considerations are noted, aside from those that already exist for RADIUS. As such, the existing RADIUS security considerations described previously apply, and no additional security considerations are added here. For instance, the assumption in RADIUS is that intermediary nodes are trusted, while at the same time there is a concern on using AAA protocols that use hop-by-hop security to distribute keys. Use of hop-by-hop security for key
增强RADIUS的安全属性是RADIUS扩展为移动IP提供支持的一个具体的非目标。此外，由于这是一份需求文档而不是解决方案规范文档，因此除了RADIUS已经存在的安全注意事项外，没有注意到任何新的安全注意事项。因此，前面描述的现有RADIUS安全注意事项适用，此处不添加其他安全注意事项。例如，RADIUS中的假设是中间节点是可信的，但同时也存在使用AAA协议的问题，该协议使用逐跳安全性来分发密钥。对密钥使用逐跳安全性
distribution can be in conflict with some of the requirements stated in [RFC4962], such as the requirement on binding a key to its context and the requirement on limitation of the key scope. The former for instance states that a key MUST be bound to the parties that are expected to have access to the keying material, while the latter implies that parties that do not require access to a key to perform their role MUST not have access to the key. Both of these requirements rule against trusting intermediary nodes and proxies with distribution of keys. Due to lack of end-to-end security mechanisms for RADIUS, imposing a MUST requirement for not trusting proxies is not possible. The RADIUS Extension working group is in the process of specifying procedures for wrapping key materials within RADIUS attributes. For the time being, support of Mobile IP within RADIUS may need to be based on trust of intermediaries, despite the security considerations described.
分发可能与[RFC4962]中所述的一些要求相冲突，例如将密钥绑定到其上下文的要求和限制密钥范围的要求。例如，前者规定，密钥必须绑定到预期可以访问密钥材料的当事人，而后者则意味着不需要访问密钥才能执行其角色的当事人不得访问密钥。这两项要求都禁止信任具有密钥分发的中间节点和代理。由于缺乏RADIUS的端到端安全机制，不可能强制要求不信任代理。半径扩展工作组正在指定在半径属性内包装关键材料的程序。目前，在RADIUS范围内支持移动IP可能需要基于中介机构的信任，尽管有所述的安全考虑。
When it comes to protecting attributes in the Access Request, [RFC2868], Section 3.5 provides a mechanism for encrypting RADIUS attributes, such as passwords. There is also work under progress for specifying wrapping of sensitive attributes, such as key material within RADIUS Access Accept messages. This work is currently considered part of RADIUS crypto-agility extensions and when completed can be used in the process of distributing sensitive attributes, such as keying material from RADIUS servers.
当涉及到保护访问请求[RFC2868]中的属性时，第3.5节提供了加密RADIUS属性（如密码）的机制。还正在进行指定敏感属性包装的工作，例如RADIUS Access Accept消息中的关键材料。这项工作目前被认为是RADIUS加密敏捷性扩展的一部分，完成后可用于分发敏感属性的过程，如RADIUS服务器的密钥材料。
It is also possible to protect RADIUS transactions using IPsec (e.g., as in RFC3579).
还可以使用IPsec保护RADIUS事务（例如，如RFC3579）。
The authors would like to thank Alan DeKok for review and feedback, and Pete McCann and Jari Arkko for diligent shepherding of this document.
作者要感谢Alan DeKok的审查和反馈，以及Pete McCann和Jari Arkko对本文件的辛勤指导。
[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月。
[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月。
[RFC2977] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[RFC2977]Glass，S.，Hiller，T.，Jacobs，S.，和C.Perkins，“移动IP认证、授权和记帐要求”，RFC 2977，2000年10月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC3957] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[RFC3957]Perkins，C.和P.Calhoun，“移动IPv4的身份验证、授权和计费（AAA）注册密钥”，RFC 3957，2005年3月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004]Calhoun，P.，Johansson，T.，Perkins，C.，Hiller，T.，和P.McCann，“Diameter移动IPv4应用”，RFC 40042005年8月。
[RFC4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[RFC4721]Perkins，C.，Calhoun，P.，和J.Bharatia，“移动IPv4挑战/响应扩展（修订版）”，RFC 47212007年1月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[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月。
[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月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580]Congdon，P.，Aboba，B.，Smith，A.，Zorn，G.，和J.Roese，“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”，RFC 35802003年9月。
Authors' Addresses
作者地址
Madjid Nakhjiri (editor) Motorola
Madjid Nakhjiri（编辑）摩托罗拉
EMail: madjid.nakhjiri@motorola.com
EMail: madjid.nakhjiri@motorola.com
Kuntal Chowdhury Starent Networks
Kuntal Chowdhury Starent网络公司
EMail: kchowdhury@starentnetworks.com
EMail: kchowdhury@starentnetworks.com
Avi Lior Bridgewater Systems
Avi Lior Bridgewater系统公司
EMail: avi@bridgewatersystems.com
EMail: avi@bridgewatersystems.com
Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 US
美国加利福尼亚州圣何塞西塔斯曼大道170号肯特梁思科系统公司，邮编95134
EMail: kleung@cisco.com
EMail: kleung@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.