[要約] RFC 5193は、ネットワークアクセスの認証を行うためのPANAフレームワークに関するプロトコルです。その目的は、異なるネットワーク環境でのセキュアな認証を提供することです。
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]に文書化されています。パナ認証が成功すると、物理的なセキュリティ、リンク層の暗号化、またはIPSEC [PANA-IPSEC]を使用して、DATAパケットごとのセキュリティを実現できます。PANAのサーバー実装は、パケットごとのアクセス制御機能を実施するエンティティとともにコロンケートされる場合とされない場合があります。PANAおよびパケットごとのアクセス制御エンティティのサーバーが別々の場合、2つのノード間に情報を伝達するためにプロトコル（[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.
パナは、基礎となるセキュリティに関係なく、あらゆるアクセスネットワークで使用することを目的としています。たとえば、ネットワークは、クライアントネットワーク認証を成功させた後、暗号化メカニズムによって物理的に保護されているか、保護される場合があります。EAPメソッドがMSKを生成するときにPANAメッセージの整合性を保証する動作を実装することは、パナ展開がMSKを生成することが必須ですが、リンク層またはネットワーク層でネットワークセキュリティのサポートを実装することは必須ではありません。
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).
このドキュメントでは、これらのさまざまなパナと他のネットワークアクセス認証要素が互いにどのように相互作用するかを説明するための一般的なフレームワークを定義します。
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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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内にカプセル化されたEAP認証方法を搭載するEAP [RFC3748]下層です。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 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は、パナのクライアント実装です。このエンティティは、ネットワークアクセスを要求しているノードにあります。PACは、ラップトップ、PDA、携帯電話、デスクトップPC、または有線または無線インターフェイスを介してネットワークに接続されているルーターなどのエンドホストになります。PACは、ネットワークアクセスを要求し、PANAを使用して認証プロセスに参加する責任があります。
PANA Authentication Agent (PAA):
パナ認証エージェント（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は、パナのサーバー実装です。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]や直径[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で十分です。それ以外の場合、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ネットワークのブラジャー（ブロードバンドリモートアクセスサーバー）[DSL] [DSL]、または3GPP2ネットワークのPDSN（ノードにサービスを提供するパケットデータ）[3GPP2]。PAAは、PACから1つ以上の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と同じノード、アクセスネットワーク上の専用ノード、またはインターネットのどこかにある中央サーバーでホストされる場合があります。
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の間で実行する必要があります。Secure Association Protocolの完了後、リンクまたはネットワークレイヤーパケットごとのセキュリティ（たとえば、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 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は、アクセスネットワーク（任意のクライアントの範囲内のトポロジー）とアクセスしたネットワーク（認定クライアントのみの範囲内のトポロジー）の間にあります。不正なクライアントのアクセスを最小限に抑えるために、ローカルエリアネットワークに戦略的に配置する必要があります。前述の理由で、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ネットワークの同じノード（BRA）上にあります。その場合、PAAとEPの間で簡単なAPIで十分です。小規模なエンタープライズの展開では、PAAおよびASは、2つの間のプロトコル実行の必要性を排除する同じノード（アクセスルーター）でホストされる場合があります。これらのエンティティまたはその他のエンティティをコロケートする決定、およびネットワークトポロジの正確な場所は、このドキュメントの範囲外の展開決定です。
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：パナ信号流
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、ルーター発見など）のみを許可します。これにより、新しく添付されたクライアントがパナに参加し、無制限のサービスの許可を得るための最小アクセスサービスを確保します。
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は、パナを実行する前に動的または静的にIPアドレスを構成します。展開シナリオに応じて、パナ認証が成功した後、PACはIPアドレスを再構成するか、追加のIPアドレスを構成する必要がある場合があります。たとえば、Link-Local IPv6アドレスをPANAに使用する場合があり、PACは認証を成功させると追加のグローバルIPv6アドレスを構成することができます。別の例：PACは、パナ中にIPv4リンクローカルアドレスの使用に限定され、認証後に非リンクローカルIPv4アドレスでインターフェイスを再構成することができます。汎用アプリケーションは、パナ認証が成功し、適切な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を発見することによりパナ認証を開始し、その後にパナを介した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は別のプロトコルを使用してPAC固有の属性（IPアドレス、暗号化キーなど）をEPに送信します。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.
パナ認証後に暗号化アクセス制御を有効にする必要がある場合、PACとEPの間で安全な関連プロトコルが実行されます。そのプロトコル（例：エンドポイントID、共有秘密など）に必要な動的パラメーターは、成功したパナ認証から導き出されます。これらのパラメーターは、セキュリティ協会の作成の一環として、PACをEPに認証するために使用されます。たとえば、PACとPAAの間のパナのキー生成EAPメソッドの使用に基づいて、IKE [RFC2409] [RFC4306]のためにそれがどのように行われるかについては、[PANA-IPSEC]を参照してください。Secure Association Protocol Exchangeは、暗号化データトラフィック保護を可能にするために、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.
パナは、パナの前にPACとEPの間に低層の安全なチャネルがある場合でも、パナ認証を成功させるときに有効にする必要がある場合でも、あらゆるネットワーク環境で使用できます。
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. パナを実行する前に安全なチャネルがすでに利用可能なネットワーク
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。1つの例は、低層セキュリティが物理的手段によって提供されるDSLネットワークです。ネットワークの配線の物理的保護により、リンクにIPパケットを送信および受信できるクライアントが1つしかないことが保証されます。
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。もう1つの例は、暗号化された保護によって低層セキュリティが提供される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.
パナエクスチェンジの前の安全なチャネルの存在により、パナ後の安全な関連プロトコルを実行する必要性がなくなります。パナセッションは、持ち越された通信チャネルに関連付けることができます。また、EAP認証方法の選択は、パナが実行中のこのセキュリティの存在に依存します。
b. Networks where a secure channel is created after running PANA
b. パナを実行した後に安全なチャネルが作成されるネットワーク
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 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.
パナ認証は、盗聴やスプーフィングに対して脆弱な不安定なチャネルで実行されます。EAPメソッドの選択は、そのような環境に関連する可能性のある攻撃に対して回復力がなければなりません。さらに、EAPメソッドは、Secure Associationプロトコルによって後で使用される暗号化キーを作成できる必要があります。
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.
展開決定であり、このドキュメントの範囲外です。この決定は、Secure Associationプロトコルの選択も規定しています。リンク層保護が使用される場合、プロトコルはリンク層固有になります。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.
バーナード・アボバ、ヤシン・エル・ムガズリ、ランディ・ターナー、ハンネス・チョフェニグ、ライオネル・モランド、マーク・タウンズリー、ジャリ・アークコ、ペッカ・サボラ、トム・ユー、ジョエル・ハルパーン、ラクシュミナス・ドネティ、デビッド・ブラック、アイーア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、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、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.、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 5191、2008年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 Evolution- 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 2865、2000年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）脅威分析とセキュリティ要件を伝達するためのプロトコル」、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.、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。、「IPSECベースのアクセス制御を可能にするパナ」、2005年7月の作業。
[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 Network Equipment Technologies、Inc。6900 Paseo Padre Parkway Fremont、CA 94555 USA
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
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA
Yoshihiro Ohba Toshiba America Research、Inc。1 Telcordia Drive Piscateway、NJ 08854 USA
Phone: +1 732 699 5305
EMail: yohba@tari.toshiba.com
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View、CA 94043 USA
Phone: +1 408 734 8820
EMail: mohanp@sbcglobal.net
Alper E. Yegin Samsung Istanbul, Turkey
Alper E. Yegin Samsung Istanbul、トルコ
EMail: a.yegin@partner.samsung.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。