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
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プロトコルのエンドポイント間でIPを使用する新しい拡張認証プロトコル（EAP）[RFC3748]下位層を定義します。
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]）は、2つのノード間の情報を伝達するために使用することができます。
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を参照）の2つの基本的なタイプを考慮して、互いに相互作用する方法を記述するための一般的なフレームワークを定義します。
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].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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 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.
PANAは、アクセスネットワーク内のクライアントの認証と承認を容易にするように設計されています。 PANAはEAP [RFC3748]クライアントノードとアクセス・ネットワーク内のサーバ間でEAP内部に封入されたEAP認証メソッドを搬送する下位層です。 PANAは、2つのエンティティの間で認証処理を可能にするが、それは全体的なAAA（認証、許可、およびアカウンティング）とアクセス制御フレームワークの一部のみです。 PANAを使用してAAAとアクセス制御フレームワークは、4つの機能エンティティで構成されています。
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
Figure 1: PANA Functional Model
図1：PANA機能モデル
PANA Client (PaC):
PANAクライアント（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):
喫煙anthentikesanエージェント（F）：
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はネットワークアクセスサービスのためにそれらを認証と認可のためにPaCのとのインタフェースを担当します。
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は、この相互作用のために十分です。彼らは（パブリックアクセスネットワークにおけるはるかに一般的なケース）分離されている場合、プロトコルは、2つの間で実行する必要があります。 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は、ネットワーク内のエンフォースメントポイント（EPS）に更新された状態を伝えます。 PAAとEPが同じノード上に存在している場合、APIは、この通信のために十分です。それ以外の場合は、プロトコルは、許可クライアントはEPにPAAから属性を運ぶために必要とされます。
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（ネットワークアクセスサーバ）と呼ばれるノードに常駐します。例えば、3GPP2ネットワークにおけるBRAS（ブロードバンドリモートアクセスサーバ）DSLネットワークにおける[DSL]、またはPDSN（パケットデータサービングノード）[3GPP2]に。 PAAは、1つまたは複数のIP離れPaCのからホップかもしれません。
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は、認証パラメータ（例えば、許容帯域幅、IP構成、など）と一緒に検証した結果とのPACに代わってPAAから要求を受信し、応答します。これは、EAPとEAPメソッドを終了し、サーバです。 ASはPAAと同じノード上で、アクセス・ネットワーク上の専用のノード上で、どこかインターネットで中央のサーバーでホストされる可能性があります。
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]で適用されてもよいです。暗号アクセス制御を使用する場合、セキュアアソシエーションプロトコル[RFC3748]はのPaCとEPの間で実行する必要があります。セキュアアソシエーションプロトコルの完了後、（例えば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.
エンティティの一部が展開シナリオに応じて、同じ場所に配置することができます。例えば、PAAとEPは、DSLネットワーク内の同じノード（BRAS）であろう。その場合には、シンプルなAPIは、PAAとEPの間に十分なものです。小規模な企業での展開では、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 | | |
|<-----------------> | |
| | | |
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.
それは不正PACに対するトラフィック（例えば、PANA、DHCP、ルータ発見、等）の限られた種類を許可に対し、アクセスネットワーク上のEPは、任意の承認のPaCからの一般的なデータトラフィックを可能にします。これは、新たに接続されたクライアントがPANAに従事し、無制限のサービスのための認可を取得するための最小アクセスサービスを持っていることを保証します。
The PaC dynamically or statically configures an IP address prior to running PANA. After the successful PANA authentication, depending on 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は動的または静的PANAを実行する前にIPアドレスを設定します。成功したPANA認証後、展開シナリオによっては、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はPANA上のEAP交換に続いて、PAAを発見することにより、PANA認証を開始します。 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認証するために使用されます。例えば、それはのPaCとPAAとの間のPANA用鍵生成EAP方式を使用することに基づくIKE [RFC2409]、[RFC4306]のためにどのように行われるかについては[PANA-IPSEC]を参照。安全な協会プロトコル交換は、暗号データトラフィック保護を有効にした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とイントラネット/インターネットの間に流れることを可能に。
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の間に下層安全なチャネルがあるかどうか、任意のネットワーク環境で使用することができ、または1つが成功PANA認証時に有効にされなければなりません。
With regard to network access authentication, two types of networks need to be considered:
ネットワークアクセス認証に関しては、2つのタイプのネットワークを考慮する必要があります。
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.1。一例では、下位層のセキュリティが物理的手段によって提供される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.2。別の例では、下層のセキュリティは、暗号保護の手段によって提供される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セッションは、それが引き継がれた通信チャネルに関連付けることができます。 PANAが実行されている間にも、EAP認証方式の選択は、このセキュリティの存在に依存します。
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.1。リンク層パケットごとのセキュリティや
b.2. network-layer per-packet security
B.2。ネットワーク層パケットごとのセキュリティ
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.
私たちは、彼らの貴重なためにバーナードAboba、YacineエルMghazli、ランディ・ターナー、ハンネスTschofenig、ライオネル・モラン、マークTownsley、ヤリArkko、ペッカSavola、トム・ゆう、ジョエル・ハルパーン、Lakshminath Dondeti、デビッド・ブラック、およびIEEE 802.11ワーキンググループに感謝したいと思いますコメント。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、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.編、オオバ、Y.、Penno、R.、Tsirtsis、G.、及びC.王、 "要件ネットワークアクセス（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]フォースバーグ、D.、オオバ、Y.、編、パティル、B.、Tschofenig、H.、およびA. Yegin、RFC 5191、2008年5月 "ネットワークアクセス（PANA）の認証を搬送するプロトコル"。
[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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、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]パルタサラティ、M.、 "認証とネットワークアクセス（PANA）を実施するためのプロトコル脅威の分析とセキュリティ要件"、RFC 4016、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.、サブラマニアン、S.、ハーグ、T.、およびN.フォークト、進歩、2007年11月の作業 "広帯域ネットワークにおけるアクセスノード制御機構のための議定書"。
[PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access Control", Work in Progress, July 2005.
[PANA-IPSEC]パルタサラティ、M.、進歩、2005年7月ワーク "のIPsecベースのアクセス制御を有効にするPANA"。
[3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless IP Network Standard", 3GPP2 P.S0001-B/v2.0, September 2004.
[3GPP2]第3世代パートナーシッププロジェクト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パセオパドレ・パークウェイフリーモント、CA 94555 USA
Phone: +1 510 574 2305 EMail: prakash_jayaraman@net.com
電話：+1 510 574 2305 Eメール：prakash_jayaraman@net.com
Rafa Marin Lopez University of Murcia 30100 Murcia Spain
ムルシア30100ムルシア、スペインのラファ・マリン・ロペス大学
Phone: +34 968 398 501 EMail: rafa@um.es
電話：+34 968 398 501 Eメール：rafa@um.es
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA
義弘大場東芝アメリカリサーチ社1のTelcordiaドライブPiscateway、NJ 08854 USA
Phone: +1 732 699 5305 EMail: yohba@tari.toshiba.com
電話：+1 732 699 5305 Eメール：yohba@tari.toshiba.com
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
モハンパルタサラティノキア313フェアチャイルドドライブマウンテンビュー、CA 94043 USA
Phone: +1 408 734 8820 EMail: mohanp@sbcglobal.net
電話：+1 408 734 8820 Eメール：mohanp@sbcglobal.net
Alper E. Yegin Samsung Istanbul, Turkey
アルパースE. Yeginサムスンイスタンブール、トルコ
EMail: a.yegin@partner.samsung.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。