Network Working Group P. Jayaraman
Request for Comments: 5193 Net.Com
Category: Informational R. Lopez
Univ. of Murcia
Y. Ohba, Ed.
Toshiba
M. Parthasarathy
Nokia
A. Yegin
Samsung
May 2008
Network Working Group P. Jayaraman
Request for Comments: 5193 Net.Com
Category: Informational R. Lopez
Univ. of Murcia
Y. Ohba, Ed.
Toshiba
M. Parthasarathy
Nokia
A. Yegin
Samsung
May 2008
Protocol for Carrying Authentication for Network Access (PANA) Framework
承载网络访问身份验证（PANA）框架的协议
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 defines the general Protocol for Carrying Authentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments.
本文档定义了用于承载网络访问身份验证（PANA）框架功能元素、高级调用流和部署环境的通用协议。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. General PANA Framework ..........................................2
3. Call Flow .......................................................5
4. Environments ....................................................6
5. Security Considerations .........................................8
6. Acknowledgments .................................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................9
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. General PANA Framework ..........................................2
3. Call Flow .......................................................5
4. Environments ....................................................6
5. Security Considerations .........................................8
6. Acknowledgments .................................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................9
PANA (Protocol for carrying Authentication for Network Access) is a link-layer agnostic network access authentication protocol that runs between a client that wants to gain access to the network and a server on the network side. PANA defines a new Extensible Authentication Protocol (EAP) [RFC3748] lower layer that uses IP between the protocol end points.
PANA（用于承载网络访问身份验证的协议）是一种链路层不可知的网络访问身份验证协议，它在希望访问网络的客户端和网络端的服务器之间运行。PANA定义了一个新的可扩展身份验证协议（EAP）[RFC3748]较低层，该层在协议端点之间使用IP。
The motivation to define such a protocol and the requirements are described in [RFC4058]. Protocol details are documented in [RFC5191]. Upon following a successful PANA authentication, per-data-packet security can be achieved by using physical security, link-layer ciphering, or IPsec [PANA-IPSEC]. The server implementation of PANA may or may not be colocated with the entity enforcing the per-packet access control function. When the server for PANA and per-packet access control entities are separate, a protocol (e.g., [ANCP-PROTO]) may be used to carry information between the two nodes.
[RFC4058]中描述了定义此类协议的动机和要求。协议细节记录在[RFC5191]中。在成功进行PANA身份验证后，可以通过使用物理安全、链路层加密或IPsec[PANA-IPsec]来实现每个数据包的安全性。PANA的服务器实现可能与实施每包访问控制功能的实体共存，也可能不共存。当用于PANA和每分组访问控制实体的服务器分开时，可以使用协议（例如，[ANCP-PROTO]）在两个节点之间传送信息。
PANA is intended to be used in any access network regardless of the underlying security. For example, the network might be physically secured, or secured by means of cryptographic mechanisms after the successful client-network authentication. While it is mandatory for a PANA deployment to implement behavior that ensures the integrity of PANA messages when the EAP method produces MSK, it is not mandatory to implement support for network security at the link-layer or network-layer.
PANA旨在用于任何接入网络，而不考虑底层安全性。例如，网络可以是物理安全的，或者在成功的客户机网络认证之后通过加密机制进行安全保护。当EAP方法生成MSK时，PANA部署必须实现确保PANA消息完整性的行为，但在链路层或网络层实现对网络安全的支持不是必须的。
This document defines the general framework for describing how these various PANA and other network access authentication elements interact with each other, especially considering the two basic types of deployment environments (see Section 4).
本文档定义了通用框架，用于描述这些不同的PANA和其他网络访问认证元素如何相互交互，特别是考虑到两种基本类型的部署环境（请参见第4节）。
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]中所述进行解释。
PANA is designed to facilitate the authentication and authorization of clients in access networks. PANA is an EAP [RFC3748] lower layer that carries EAP authentication methods encapsulated inside EAP between a client node and a server in the access network. While PANA
PANA旨在促进接入网络中客户端的身份验证和授权。PANA是EAP[RFC3748]的较低层，它在接入网络中的客户端节点和服务器之间携带封装在EAP内部的EAP身份验证方法。而帕纳
enables the authentication process between the two entities, it is only a part of an overall AAA (Authentication, Authorization and Accounting) and access control framework. A AAA and access control framework using PANA is comprised of four functional entities.
启用两个实体之间的身份验证过程，它只是整个AAA（身份验证、授权和记帐）和访问控制框架的一部分。使用PANA的AAA和访问控制框架由四个功能实体组成。
Figure 1 illustrates these functional entities and the interfaces (protocols, APIs) among them.
图1说明了这些功能实体以及它们之间的接口（协议、API）。
RADIUS,
Diameter,
+-----+ PANA +-----+ LDAP, API, etc. +-----+
| PaC |<----------------->| PAA |<------------------->| AS |
+-----+ +-----+ +-----+
^ ^
| |
| +-----+ |
IKE, +-------->| EP |<--------+ ANCP, API, etc.
4-way handshake, +-----+
etc. .
.
.
v
Data traffic
RADIUS,
Diameter,
+-----+ PANA +-----+ LDAP, API, etc. +-----+
| PaC |<----------------->| PAA |<------------------->| AS |
+-----+ +-----+ +-----+
^ ^
| |
| +-----+ |
IKE, +-------->| EP |<--------+ ANCP, API, etc.
4-way handshake, +-----+
etc. .
.
.
v
Data traffic
Figure 1: PANA Functional Model
图1:PANA功能模型
PANA Client (PaC):
泛亚客户（PaC）：
The PaC is the client implementation of PANA. This entity resides on the node that is requesting network access. PaCs can be end hosts, such as laptops, PDAs, cell phones, desktop PCs, or routers that are connected to a network via a wired or wireless interface. A PaC is responsible for requesting network access and engaging in the authentication process using PANA.
PaC是PANA的客户端实现。此实体位于请求网络访问的节点上。PAC可以是终端主机，如笔记本电脑、PDA、手机、台式PC或通过有线或无线接口连接到网络的路由器。PaC负责使用PANA请求网络访问并参与身份验证过程。
PANA Authentication Agent (PAA):
PANA身份验证代理（PAA）：
The PAA is the server implementation of PANA. A PAA is in charge of interfacing with the PaCs for authenticating and authorizing them for the network access service.
PAA是PANA的服务器实现。PAA负责与PaCs接口，以验证和授权PaCs的网络接入服务。
The PAA consults an authentication server in order to verify the credentials and rights of a PaC. If the authentication server resides on the same node as the PAA, an API is sufficient for this interaction. When they are separated (a much more common case in public access networks), a protocol needs to run between the two. AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are commonly used for this purpose.
PAA咨询身份验证服务器以验证PaC的凭据和权限。如果身份验证服务器与PAA驻留在同一节点上，那么API就足以进行此交互。当它们分开时（公共接入网络中更常见的情况），需要在两者之间运行协议。诸如RADIUS[RFC2865]和Diameter[RFC3588]之类的AAA协议通常用于此目的。
The PAA is also responsible for updating the access control state (i.e., filters) depending on the creation and deletion of the authorization state. The PAA communicates the updated state to the Enforcement Points (EPs) in the network. If the PAA and EP are residing on the same node, an API is sufficient for this communication. Otherwise, a protocol is required to carry the authorized client attributes from the PAA to the EP.
PAA还负责根据授权状态的创建和删除更新访问控制状态（即过滤器）。PAA将更新后的状态传送给网络中的实施点（EP）。如果PAA和EP驻留在同一节点上，那么API就足以进行此通信。否则，需要协议将授权客户端属性从PAA传送到EP。
The PAA resides on a node that is typically called a NAS (network access server) in the access network. For example, on a BRAS (Broadband Remote Access Server) [DSL] in DSL networks, or PDSN (Packet Data Serving Node) [3GPP2] in 3GPP2 networks. The PAA may be one or more IP hops away from the PaCs.
PAA驻留在接入网络中通常称为NAS（网络接入服务器）的节点上。例如，在DSL网络中的BRAS（宽带远程访问服务器）[DSL]或3GPP2网络中的PDSN（分组数据服务节点）[3GPP2]上。PAA可以是距离PaCs的一个或多个IP跃点。
Authentication Server (AS):
身份验证服务器（AS）：
The server implementation that is in charge of verifying the credentials of a PaC that is requesting the network access service. The AS receives requests from the PAA on behalf of the PaCs, and responds with the result of verification together with the authorization parameters (e.g., allowed bandwidth, IP configuration, etc). This is the server that terminates the EAP and the EAP methods. The AS might be hosted on the same node as the PAA, on a dedicated node on the access network, or on a central server somewhere in the Internet.
负责验证请求网络访问服务的PaC的凭据的服务器实现。AS代表PaCs接收来自PAA的请求，并以验证结果和授权参数（例如，允许带宽、IP配置等）作出响应。这是终止EAP和EAP方法的服务器。AS可能托管在与PAA相同的节点上、接入网络上的专用节点上或Internet中的某个中央服务器上。
Enforcement Point (EP):
执行点（EP）：
The access control implementation that is in charge of allowing access (data traffic) of authorized clients while preventing access by others. An EP learns the attributes of the authorized clients from the PAA.
一种访问控制实现，负责允许授权客户端访问（数据通信），同时防止其他客户端访问。EP从PAA中学习授权客户的属性。
The EP uses non-cryptographic or cryptographic filters to selectively allow and discard data packets. These filters may be applied at the link layer or the IP layer [PANA-IPSEC]. When cryptographic access control is used, a secure association protocol [RFC3748] needs to run between the PaC and EP. After completion of the secure association protocol, link- or network-layer per-packet security (for example TKIP, IPsec ESP) is enabled for integrity protection, data origin authentication, replay protection, and optionally confidentiality protection.
EP使用非加密或加密过滤器选择性地允许和丢弃数据包。这些过滤器可应用于链路层或IP层[PANA-IPSEC]。使用加密访问控制时，需要在PaC和EP之间运行安全关联协议[RFC3748]。完成安全关联协议后，将启用链路层或网络层每数据包安全性（例如TKIP、IPsec ESP），以实现完整性保护、数据源身份验证、重播保护和可选的机密性保护。
An EP is located between the access network (the topology within reach of any client) and the accessed network (the topology within reach of only authorized clients). It must be located strategically in a local area network to minimize the access of unauthorized clients. It is recommended but not mandated that the
EP位于接入网络（任何客户端都可以到达的拓扑）和接入网络（只有授权客户端才能到达的拓扑）之间。它必须战略性地位于局域网中，以尽量减少未经授权的客户端的访问。建议但不是强制要求
EP be on the path between the PaC and the PAA for the aforementioned reason. For example, the EP can be hosted on the switch that is directly connected to the clients in a wired network. That way the EP can drop unauthorized packets before they reach any other client node or nodes beyond the local area network.
由于上述原因，EP可能位于PaC和PAA之间的路径上。例如，EP可以托管在交换机上，交换机直接连接到有线网络中的客户端。这样，EP可以在未经授权的数据包到达局域网以外的任何其他客户端节点之前丢弃这些数据包。
Some of the entities may be colocated depending on the deployment scenario. For example, the PAA and EP would be on the same node (BRAS) in DSL networks. In that case, a simple API is sufficient between the PAA and EP. In small enterprise deployments, the PAA and AS may be hosted on the same node (access router) that eliminates the need for a protocol run between the two. The decision to colocate these entities or otherwise, and their precise location in the network topology, are deployment decisions that are out of the scope of this document.
根据部署场景的不同，某些实体可能会被共同定位。例如，在DSL网络中，PAA和EP将位于同一节点（BRA）上。在这种情况下，在PAA和EP之间使用一个简单的API就足够了。在小型企业部署中，PAA和AS可以托管在同一节点（访问路由器）上，这样就不需要在两者之间运行协议。将这些实体或其他实体合并的决定，以及它们在网络拓扑中的精确位置，都是不在本文档范围内的部署决定。
Figure 2 illustrates the signaling flow for authorizing a client for network access.
图2说明了授权客户端进行网络访问的信令流。
PaC EP PAA AS
| | | |
IP address ->| | | |
config. | PANA | | AAA |
|<------------------------------>|<-------------->|
| | Provisioning | |
(Optional) | |<-------------->| |
IP address ->| | | |
reconfig. | Sec.Assoc. | | |
|<------------->| | |
| | | |
| Data traffic | | |
|<-----------------> | |
| | | |
PaC EP PAA AS
| | | |
IP address ->| | | |
config. | PANA | | AAA |
|<------------------------------>|<-------------->|
| | Provisioning | |
(Optional) | |<-------------->| |
IP address ->| | | |
reconfig. | Sec.Assoc. | | |
|<------------->| | |
| | | |
| Data traffic | | |
|<-----------------> | |
| | | |
Figure 2: PANA Signaling Flow
图2:PANA信令流
The EP on the access network allows general data traffic from any authorized PaC, whereas it allows only a limited type of traffic (e.g., PANA, DHCP, router discovery, etc.) for the unauthorized PaCs. This ensures that the newly attached clients have the minimum access service to engage in PANA and get authorized for the unlimited service.
接入网络上的EP允许来自任何授权PaC的一般数据通信，而对于未经授权的PaC，它只允许有限类型的通信（例如，PANA、DHCP、路由器发现等）。这确保了新连接的客户端具有参与PANA的最低访问权限服务，并获得无限服务的授权。
The PaC dynamically or statically configures an IP address prior to running PANA. After the successful PANA authentication, depending on
PaC在运行PANA之前动态或静态配置IP地址。成功进行PANA身份验证后，取决于
the deployment scenario, the PaC may need to re-configure its IP address or configure additional IP address(es). For example, a link-local IPv6 address may be used for PANA and the PaC may be allowed to configure additional global IPv6 address(es) upon successful authentication. Another example: A PaC may be limited to using an IPv4 link-local address during PANA, and allowed to reconfigure its interface with a non-link-local IPv4 address after the authentication. General-purpose applications cannot use the interface until PANA authentication succeeds and appropriate IP address configuration takes place.
在部署场景中，PaC可能需要重新配置其IP地址或配置其他IP地址。例如，链路本地IPv6地址可用于PANA，且PaC可被允许在成功认证后配置额外的全局IPv6地址。另一个示例：PaC可能被限制在PANA期间使用IPv4链路本地地址，并允许在身份验证后使用非链路本地IPv4地址重新配置其接口。在PANA身份验证成功并进行适当的IP地址配置之前，通用应用程序无法使用该接口。
An initially unauthorized PaC starts PANA authentication by discovering the PAA, followed by the EAP exchange over PANA. The PAA interacts with the AS during this process. Upon receiving the authentication and authorization result from the AS, the PAA informs the PaC about the result of its network access request.
最初未经授权的PaC通过发现PAA启动PAA身份验证，然后通过PAA进行EAP交换。在此过程中，PAA与AS相互作用。收到AS的认证和授权结果后，PAA将其网络访问请求的结果通知PaC。
If the PaC is authorized to gain access to the network, the PAA also sends the PaC-specific attributes (e.g., IP address, cryptographic keys, etc.) to the EP by using another protocol. The EP uses this information to alter its filters to allow data traffic from and to the PaC to pass through.
如果PaC被授权访问网络，则PAA还通过使用另一协议向EP发送PaC特定属性（例如，IP地址、加密密钥等）。EP使用此信息更改其过滤器，以允许来自和到PaC的数据流量通过。
In case cryptographic access control needs to be enabled after PANA authentication, a secure association protocol runs between the PaC and the EP. Dynamic parameters required for that protocol (e.g., endpoint identity, shared secret) are derived from successful PANA authentication; these parameters are used to authenticate the PaC to the EP and vice-versa as part of creating the security association. For example, see [PANA-IPSEC] for how it is done for IKE [RFC2409] [RFC4306] based on using a key-generating EAP method for PANA between the PaC and PAA. The secure association protocol exchange produces the required security associations between the PaC and the EP to enable cryptographic data traffic protection. Per-packet cryptographic data traffic protection introduces additional per-packet overhead but the overhead exists only between the PaC and EP and will not affect communications beyond the EP.
如果在PANA身份验证后需要启用加密访问控制，则在PaC和EP之间运行安全关联协议。该协议所需的动态参数（例如，端点标识、共享密钥）来自成功的PANA身份验证；这些参数用于向EP验证PaC，反之亦然，作为创建安全关联的一部分。例如，请参见[PANA-IPSEC]，了解如何基于在PaC和PAA之间为PANA使用密钥生成EAP方法来实现IKE[RFC2409][RFC4306]。安全关联协议交换在PaC和EP之间生成所需的安全关联，以启用加密数据流量保护。每包加密数据流量保护引入了额外的每包开销，但该开销仅存在于PaC和EP之间，不会影响EP之外的通信。
Finally, filters that are installed at the EP allow general purpose data traffic to flow between the PaC and the intranet/Internet.
最后，安装在EP的过滤器允许通用数据流量在PaC和intranet/Internet之间流动。
PANA can be used on any network environment whether there is a lower-layer secure channel between the PaC and the EP prior to PANA, or one has to be enabled upon successful PANA authentication.
PANA可用于任何网络环境，无论在PANA之前PaC和EP之间存在较低层的安全通道，还是在成功进行PANA身份验证后必须启用一个安全通道。
With regard to network access authentication, two types of networks need to be considered:
关于网络接入认证，需要考虑两种类型的网络：
a. Networks where a secure channel is already available prior to running PANA
a. 在运行PANA之前已经有安全通道的网络
This type of network is characterized by the existence of protection against spoofing and eavesdropping. Nevertheless, user authentication and authorization is required for network connectivity.
这类网络的特点是存在防止欺骗和窃听的保护。然而，网络连接需要用户身份验证和授权。
a.1. One example is a DSL network where lower-layer security is provided by a physical means. Physical protection of the network wiring ensures that practically there is only one client that can send and receive IP packets on the link.
a、 一,。一个例子是DSL网络，其中通过物理手段提供较低层安全性。网络布线的物理保护确保实际上只有一个客户端可以在链路上发送和接收IP数据包。
a.2. Another example is a cdma2000 network where the lower-layer security is provided by means of cryptographic protection. By the time the client requests access to the network-layer services, it is already authenticated and authorized for accessing the radio channel, and link-layer ciphering is enabled.
a、 二,。另一个例子是cdma2000网络，其中通过密码保护提供较低层的安全性。当客户端请求访问网络层服务时，它已经被认证和授权访问无线信道，并且链路层加密已启用。
The presence of a secure channel before the PANA exchange eliminates the need for executing a secure association protocol after PANA. The PANA session can be associated with the communication channel it was carried over. Also, the choice of EAP authentication method depends on the presence of this security while PANA is running.
由于在PANA交换之前存在安全通道，因此在PANA交换之后无需执行安全关联协议。PANA会话可以与其承载的通信信道相关联。此外，EAP身份验证方法的选择取决于PANA运行时是否存在这种安全性。
b. Networks where a secure channel is created after running PANA
b. 运行PANA后创建安全通道的网络
These are the networks where there is no lower-layer protection prior to running PANA. Successful PANA authentication enables the generation of cryptographic keys that are used with a secure association protocol to enable per-packet cryptographic protection.
这些网络在运行PANA之前没有底层保护。成功的PANA身份验证可以生成加密密钥，这些密钥与安全关联协议一起使用，以启用每个数据包的加密保护。
PANA authentication is run on an insecure channel that is vulnerable to eavesdropping and spoofing. The choice of EAP method must be resilient to the possible attacks associated with such an environment. Furthermore, the EAP method must be able to create cryptographic keys that will later be used by the secure association protocol.
PANA身份验证在易受窃听和欺骗的不安全通道上运行。EAP方法的选择必须能够抵御与此类环境相关的可能攻击。此外，EAP方法必须能够创建稍后将由安全关联协议使用的加密密钥。
Whether to use
是否使用
b.1. link-layer per-packet security or
b、 一,。每个数据包的链路层安全性或
b.2. network-layer per-packet security
b、 二,。网络层每包安全
is a deployment decision and outside the scope of this document. This decision also dictates the choice of the secure association protocol. If link-layer protection is used, the protocol would be link-layer specific. If IP-layer protection is used, the secure association protocol would be IKE and the per-packet security would be provided by IPsec AH/ESP regardless of the underlying link-layer technology.
是部署决策，不在本文档范围内。这个决定还决定了安全关联协议的选择。如果使用链路层保护，则协议将是特定于链路层的。如果使用IP层保护，则安全关联协议将是IKE，并且无论底层链路层技术如何，IPsec AH/ESP都将提供每个数据包的安全性。
Security is discussed throughout this document. For protocol-specific security considerations, refer to [RFC4016] and [RFC5191].
安全性在本文档中进行了讨论。有关特定于协议的安全注意事项，请参阅[RFC4016]和[RFC5191]。
We would like to thank Bernard Aboba, Yacine El Mghazli, Randy Turner, Hannes Tschofenig, Lionel Morand, Mark Townsley, Jari Arkko, Pekka Savola, Tom Yu, Joel Halpern, Lakshminath Dondeti, David Black, and IEEE 802.11 Working Group for their valuable comments.
我们要感谢Bernard Aboba、Yacine El-Mghazli、Randy Turner、Hannes Tschofenig、Lionel Morand、Mark Townsley、Jari Arkko、Pekka Savola、Tom Yu、Joel Halpern、Lakshminath Dondeti、David Black和IEEE 802.11工作组提出的宝贵意见。
[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月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4058] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements", RFC 4058, May 2005.
[RFC4058]Yegin，A.，Ed.，Ohba，Y.，Penno，R.，Tsirtsis，G.，和C.Wang，“承载网络接入认证（PANA）要求的协议”，RFC 4058，2005年5月。
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191]Forsberg，D.，Ohba，Y.，Ed.，Patil，B.，Tschofenig，H.，和A.Yegin，“承载网络接入认证（PANA）的协议”，RFC 51912008年5月。
[DSL] DSL Forum Architecture and Transport Working Group, "DSL Forum TR-059 DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", September 2003.
[DSL]DSL论坛架构和传输工作组，“DSL论坛TR-059 DSL演进-支持QoS支持IP服务的架构要求”，2003年9月。
[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月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, March 2005.
[RFC4016]Parthasarathy，M.“承载身份验证和网络访问协议（PANA）威胁分析和安全要求”，RFC4016，2005年3月。
[ANCP-PROTO] Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., and N. Voigt, "Protocol for Access Node Control Mechanism in Broadband Networks", Work in Progress, November 2007.
[ANCP-PROTO]Wadhwa，S.，Moisand，J.，Subramanian，S.，Haag，T.，和N.Voigt，“宽带网络中接入节点控制机制的协议”，正在进行的工作，2007年11月。
[PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access Control", Work in Progress, July 2005.
[PANA-IPSEC]Parthasarathy，M.，“PANA启用基于IPSEC的访问控制”，正在进行的工作，2005年7月。
[3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless IP Network Standard", 3GPP2 P.S0001-B/v2.0, September 2004.
[3GPP2]第三代合作伙伴项目2，“cdma2000无线IP网络标准”，3GPP2 P.S0001-B/v2.0，2004年9月。
Authors' Addresses
作者地址
Prakash Jayaraman Network Equipment Technologies, Inc. 6900 Paseo Padre Parkway Fremont, CA 94555 USA
Prakash Jayaraman网络设备技术有限公司，美国加利福尼亚州弗雷蒙特帕塞奥-帕德雷公园路6900号，邮编94555
Phone: +1 510 574 2305
EMail: prakash_jayaraman@net.com
Phone: +1 510 574 2305
EMail: prakash_jayaraman@net.com
Rafa Marin Lopez University of Murcia 30100 Murcia Spain
拉法马林洛佩兹大学穆尔西亚30100西班牙穆尔西亚
Phone: +34 968 398 501
EMail: rafa@um.es
Phone: +34 968 398 501
EMail: rafa@um.es
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA
东芝美国研究公司，地址：美国新泽西州皮斯卡特韦市Telcordia大道1号，邮编：08854
Phone: +1 732 699 5305
EMail: yohba@tari.toshiba.com
Phone: +1 732 699 5305
EMail: yohba@tari.toshiba.com
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
Mohan Parthasarathy诺基亚313飞兆半导体山景大道，美国加利福尼亚州94043
Phone: +1 408 734 8820
EMail: mohanp@sbcglobal.net
Phone: +1 408 734 8820
EMail: mohanp@sbcglobal.net
Alper E. Yegin Samsung Istanbul, Turkey
土耳其伊斯坦布尔阿尔珀·E·耶金三星酒店
EMail: a.yegin@partner.samsung.com
EMail: a.yegin@partner.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.