Network Working Group A. Yegin, Ed.
Request for Comments: 4058 Samsung AIT
Category: Informational Y. Ohba
Toshiba
R. Penno
Juniper Networks
G. Tsirtsis
Flarion
C. Wang
ARO/NCSU
May 2005
Protocol for Carrying Authentication for Network Access (PANA)
Requirements
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of the AAA infrastructure.
将来のIPデバイスがネットワーク接続を得るためのアクセス技術の多様性を持っていることが期待されます。現在、認証および承認の目的のために、ネットワークにクライアント情報を提供するためのアクセス固有のメカニズムがあります。特定のアクセスメディアに限定されることに加えて（例えば、802.1X IEEE 802個のリンクのため）、これらのプロトコルのいくつかは、特定のネットワークトポロジに限定されている（例えば、ポイントツーポイントリンクのPPP）。このドキュメントの目標は、ホストとネットワークは、ネットワークアクセスのために互いを認証することを可能にするリンク層にとらわれないプロトコルのための要件を特定することです。このプロトコルは、クライアントのデバイスとエージェントはAAAインフラストラクチャのクライアントであるかもしれない、ネットワーク内のエージェントとの間で実行されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Notation ...........................................3
3. Terminology .....................................................4
4. Requirements ....................................................4
4.1. Authentication .............................................4
4.1.1. Authentication of Client ............................4
4.1.2. Authorization, Accounting, and Access Control .......6
4.1.3. Authentication Backend ..............................7
4.1.4. Identifiers .........................................7
4.2. IP Address Assignment ......................................7
4.3. EAP Lower Layer Requirements ...............................7
4.4. PAA-to-EP Protocol .........................................8
4.5. Network ....................................................8
4.5.1. Multi-access ........................................8
4.5.2. Disconnect Indication ...............................8
4.5.3. Location of PAA .....................................9
4.5.4. Secure Channel ......................................9
4.6. Interaction with Other Protocols ..........................10
4.7. Performance ...............................................10
4.8. Congestion Control ........................................10
4.9. IP Version Independence ...................................10
4.10. Denial of Service Attacks ................................10
4.11. Client Identity Privacy ..................................10
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
A. Problem Statement ..............................................12
B. Usage Scenarios ................................................13
References ........................................................16
Normative References ...........................................16
Informative References .........................................16
Secure network access service requires access control based on the authentication and authorization of the clients and the access networks. Initial and subsequent client-to-network authentication provides parameters that are needed to police the traffic flow through the enforcement points. A protocol is needed to carry authentication parameters between the client and the access network. See Appendix A for the associated problem statement.
セキュアなネットワーク・アクセス・サービスは、クライアントとアクセスネットワークの認証と承認に基づいてアクセス制御を必要とします。初期とその後のクライアントとネットワーク認証が実施ポイントを通過するトラフィックフローをポリシングするために必要なパラメータを提供します。プロトコルは、クライアントとアクセスネットワークとの間の認証パラメータを運ぶために必要とされています。関連する問題の声明については、付録Aを参照してください。
The protocol design will be limited to defining a messaging protocol (i.e., a carrier) that will allow authentication payload to be carried between the host/client and an agent/server in the access network for authentication and authorization purposes regardless of the AAA infrastructure that may (or may not) reside on the network. As a network-layer protocol, it will be independent of the underlying access technologies and applicable to any network topology.
プロトコルの設計は、メッセージングプロトコルを定義するに制限されます（すなわち、キャリア）の認証ペイロードがホスト/クライアントとにかかわらず、AAAインフラストラクチャの認証および承認の目的のために、アクセスネットワーク内のエージェント/サーバ間で行われることを可能にすること（またはしない場合があります）ネットワーク上に存在してもよいです。ネットワーク層プロトコルとして、それは根本的なアクセス技術に依存せず、任意のネットワークトポロジに適用されます。
The intent is not to invent new security protocols and mechanisms but to reuse existing mechanisms such as EAP [RFC3748]. In particular, the requirements do not mandate the need to define new authentication protocols (e.g., EAP-TLS [RFC2716]), key distribution or key agreement protocols, or key derivation methods. The desired protocol can be viewed as the front-end of the AAA protocol or any other protocol/mechanisms the network is running at the background to authenticate its clients. It will act as a carrier for an already defined security protocol or mechanism.
その意図は、新しいセキュリティプロトコルとメカニズムを発明するが、そのようなEAP [RFC3748]などの既存のメカニズムを再利用することはありません。具体的には、要件は、新しい認証プロトコル（例えば、EAP-TLS [RFC2716]）、キー配布又はキー合意プロトコル、又は鍵導出方法を定義する必要性を強制しません。所望のプロトコルは、ネットワークがそのクライアントを認証するために、バックグラウンドで実行されているAAAプロトコルまたは他のプロトコル/メカニズムのフロントエンドとして見ることができます。これは、すでに定義されたセキュリティプロトコルやメカニズムのためのキャリアとして機能します。
An example of a protocol being extended for use in authenticating a host for network access is Mobile IPv4. A Mobile IPv4 registration request message is used as a carrier for authentication extensions (MN-FA [RFC3344] or MN-AAA [RFC3012]) that allows a foreign agent to authenticate mobile nodes before providing forwarding service. The goal of PANA is similar in that it aims to define a network-layer transport for authentication information. However, PANA will be decoupled from mobility management and will rely on other specifications for the definition of authentication payloads.
ネットワークアクセスのためのホストを認証する際に使用するために拡張されているプロトコルの例は、モバイルIPv4です。モバイルIPv4登録要求メッセージは、外部エージェントは、転送サービスを提供する前にモバイルノードを認証することを可能にする認証拡張（MN-FA [RFC3344]またはMN-AAA [RFC3012]）のための担体として使用されます。 PANAの目標は、認証情報のネットワーク層、トランスポートを定義することを目指していることが似ています。しかし、PANAは、モビリティ管理から分離され、認証ペイロードの定義については、他の仕様に依存します。
This document defines common terminology and identifies requirements of a protocol for PANA that will be used to define and limit the scope of the work to be done in this group.
この文書は、一般的な用語を定義し、このグループ内で行われるべき作業の範囲を定義し、制限するために使用されるPANAプロトコルのための要件を識別する。
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 Client (PaC)
PANAクライアント（PAC）
The client side of the protocol that resides in the host device which is responsible for providing the credentials to prove its identity for network access authorization.
ネットワークアクセス認可のための身元を証明する資格情報を提供する責任がホストデバイスに常駐するプロトコルのクライアント側。
PANA Client Identifier (PaCI)
PANAクライアント識別子（平和）
The identifier that is presented by the PaC to the PAA for network access authentication. A simple username and NAI [RFC2794] are examples of PANA client identifiers.
ネットワークアクセス認証のためのPAAへのPaCによって提示された識別子。シンプルなユーザ名とNAI [RFC2794]はPANAクライアント識別子の例です。
Device Identifier (DI)
機器識別子（DI）
The identifier used by the network as a handle to control and police the network access of a client. Depending on the access technology, this identifier might contain an IP address, a link-layer address, or a switch port number, etc. of a connected device.
識別子は、クライアントのネットワークアクセスを制御し、取り締まるためのハンドルなどのネットワークで使用されます。アクセス技術に応じて、この識別子は、接続されたデバイスのIPアドレスなど、リンク層アドレス、またはスイッチポート番号を、含まれている場合があります。
PANA Authentication Agent (PAA)
喫煙anthentikesanエージェント（F）
The access network side entity of the protocol whose responsibility is to verify the credentials provided by a PANA client and grant network access service to the device associated with the client and identified by a DI.
責任プロトコルのアクセスネットワーク側エンティティは、DIによってクライアントに関連付けられていると識別されたデバイスにPANAクライアントと許可のネットワークアクセスサービスによって提供される認証情報を検証することです。
Enforcement Point (EP)
施行ポイント（EP）
A node on the access network where per-packet enforcement policies (i.e., filters) are applied on the inbound and outbound traffic of client devices. Information such as DI and (optionally) cryptographic keys are provided by PAA per client for constructing filters on the EP.
パケットごとの実施方針（すなわち、フィルタ）は、クライアントデバイスのインバウンドとアウトバウンドのトラフィックに適用されているアクセス・ネットワーク上のノード。情報などDIやなど（オプション）暗号化キーがEPにフィルタを構築するために、クライアントごとにPAAによって提供されています。
PANA MUST enable authentication of PaCs for network access. A PaC's identity can be authenticated by verifying the credentials (e.g., identifier, authenticator) supplied by one of the users of the device or the device itself. PANA MUST only grant network access service to the device identified by the DI, rather than separate access to multiple simultaneous users of the device. Once network access is granted to the device, methods used by the device on arbitrating which user can access the network is outside the scope of PANA.
PANAは、ネットワークアクセスのためのPAC認証を有効にする必要があります。 PaCのアイデンティティは、デバイスまたはデバイス自体のユーザのいずれかによって提供された資格情報（例えば、識別子、オーセンティケータ）を検証することによって認証することができます。 PANAは、むしろデバイスの複数の同時ユーザに別個のアクセスより、DIにより識別されたデバイスへのネットワーク・アクセス・サービスを付与する必要があります。ネットワークアクセスがデバイスに許可されると、ユーザがネットワークにアクセスすることができる調停上のデバイスによって使用される方法は、PANAの範囲外です。
PANA MUST NOT define new security protocols or mechanisms. Instead, it MUST be defined as a "carrier" for such protocols. PANA MUST identify which specific security protocol(s) or mechanism(s) it can carry (the "payload"). EAP is a candidate protocol that satisfies many requirements for authentication. PANA would be a carrier protocol for EAP. If the PANA Working Group decides that extensions to EAP are needed, it will define requirements for the EAP WG instead of designing such extensions.
PANAは、新たなセキュリティプロトコルやメカニズムを定義してはなりません。代わりに、それはそのようなプロトコルのための「キャリア」として定義されなければなりません。 PANAは、（「ペイロード」）を運ぶことができる特定のセキュリティプロトコル（S）または機構（複数可）を識別しなければなりません。 EAP認証のための多くの要件を満たす候補プロトコルです。 PANAはEAPのためのキャリアプロトコルになります。 PANAワーキンググループはEAPへの拡張が必要であると判断した場合に、それはEAP WGの代わりに、そのような拡張を設計するための要件を定義します。
Providing authentication, integrity and replay protection for data traffic after a successful PANA exchange is outside the scope of this protocol. In networks where physical layer security is not present, link-layer or network-layer ciphering (e.g., IPsec) can be used to provide such security. These mechanisms require the presence of cryptographic keying material at PaC and EP. Although PANA does not deal with key derivation or distribution, it enables this by carrying EAP and allowing appropriate EAP method selection. Various EAP methods are capable of generating basic keying material that cannot be directly used with IPsec because it lacks the properties of an IPsec SA (security association) including secure cipher suite negotiation, mutual proof of possession of keying material, freshness of transient session keys, key naming, etc. These basic (initial) EAP keys can be used with an IPsec key management protocol, like IKE, to generate the required security associations. A separate protocol, called secure association protocol, is required to generate IPsec SAs based on the basic EAP keys. This protocol MUST be capable of enabling IPsec-based access control on the EPs. IPsec SAs MUST enable authentication, integrity and replay protection of data packets as they are sent between the EP and PaC.
成功したPANA交換した後、認証、整合性とデータトラフィックのための再生保護を提供することは、このプロトコルの範囲外です。物理層セキュリティが存在しないネットワークでは、リンク層又はネットワーク層暗号化（例えば、IPsec）は、このようなセキュリティを提供するために使用することができます。これらのメカニズムは、PACとEPでの暗号化キーイングマテリアルの存在を必要とします。 PANAは鍵導出又は配布を扱っていないが、EAPを搬送して、適切なEAP方式の選択を可能にすることによって、これを可能にします。種々のEAPメソッドは、それが安全な暗号スイートのネゴシエーション、鍵材料の所有の相互証明、トランジエントセッション鍵の鮮度などのIPsec SA（セキュリティアソシエーション）の特性を欠いているので、直接のIPsecで使用することができない基本的な鍵材料を生成することができますなどが挙げられる。これらの基本（初期）EAPキーキー命名は、必要なセキュリティアソシエーションを生成するために、IKEのように、IPsecの鍵管理プロトコルで使用することができます。セキュアアソシエーションプロトコルと呼ばれる別のプロトコルは、基本的なEAPキーに基づいてIPSec SAを生成するために必要とされます。このプロトコルをEPSにIPsecベースのアクセス制御を可能にすることができなければなりません。 IPsecのSAは、認証、整合性を有効にし、それらはEPとPACとの間で送信されるデータパケットの保護を再生する必要があります。
Providing a complete secure network access solution by securing router discovery [RFC1256], neighbor discovery [RFC2461], and address resolution protocols [RFC826] is outside the scope as well.
ルータ発見[RFC1256]、近隣探索[RFC2461]、およびアドレス解決プロトコル[RFC826]を確保することにより、完全な安全なネットワークアクセスソリューションを提供することも範囲外です。
Some access networks might require or allow their clients to get authenticated and authorized by the network access provider (NAP) and ISP before the clients gain network access. NAP is the owner of the access network who provides physical and link-layer connectivity to the clients. PANA MUST be capable of enabling two independent authentication operations (i.e., execution of two separate EAP methods) for the same client. Determining the authorization parameters as a result of two separate authentications is an operational issue and therefore outside the scope of PANA.
一部のアクセスネットワークが必要とするか、または自分のクライアントが認証され、クライアントがネットワークアクセスを得る前に、ネットワークアクセスプロバイダ（NAP）とISPによって認可を取得することを可能にするかもしれません。 NAPは、クライアントへの物理およびリンク層の接続性を提供するアクセスネットワークの所有者です。 PANAは、2つの独立した認証操作を可能にすることができなければなりません（すなわち、二つの別個のEAPメソッドの実行）同じクライアントのため。二つの別々の認証の結果、認証パラメータを決定する演算問題従ってPANAの範囲外です。
Both the PaC and the PAA MUST be able to perform mutual authentication for network access. Providing only the capability of a PAA authenticating the PaC is not sufficient. Mutual authentication capability is required in some environments but not in all of them. For example, clients might not need to authenticate the access network when physical security is available (e.g., dial-up networks).
PaCとPAAの両方がネットワークアクセスのための相互認証を実行できなければなりません。 PaCを認証PAAの機能のみを提供することは十分ではありません。相互認証機能は、一部の環境ではなく、それらのすべてで必要とされます。例えば、クライアントは、物理的なセキュリティが（例えば、ダイヤルアップネットワーク）が利用可能であるとき、アクセスネットワークを認証する必要がないかもしれません。
PANA MUST be capable of carrying out both periodic and on-demand re-authentication. Both the PaC and the PAA MUST be able to initiate both the initial authentication and the re-authentication process.
PANAは、定期的およびオンデマンドの再認証の両方を行うことができなければなりません。 PaCとPAAの両方が初期認証及び再認証プロセスの両方を開始することができなければなりません。
Certain types of service theft are possible when the DI is not protected during or after the PANA exchange [RFC4016]. PANA MUST have the capability to exchange DI securely between the PaC and PAA where the network is vulnerable to man-in-the-middle attacks. While PANA MUST provide such a capability, its utility relies on the use of an authentication method that can generate keys for cryptographic computations on PaC and PAA.
DIは、PANA交換[RFC4016]の間または後に保護されていない場合、サービス窃盗の特定のタイプが可能です。 PANAは、ネットワークがman-in-the-middle攻撃に対して脆弱であるのPaCとPAAとの間にしっかりとDIを交換する能力を持たなければなりません。 PANAは、そのような能力を提供しなければならないが、その有用性は、PACとPAA上の暗号計算のための鍵を生成することができる認証方法の使用に依存しています。
After a device is authenticated by using PANA, it MUST be authorized for "network access." That is, the core requirement of PANA is to verify the authorization of a PaC so that PaC's device may send and receive any IP packets. It may also be possible to provide finer granularity authorization, such as authorization for QoS or individual services (e.g., http vs. ssh). However, while a backend authorization infrastructure (e.g., RADIUS or Diameter based AAA infra) might provide such indications to the PAA, explicit support for them is outside the scope of PANA. For instance, PANA is not required to carry any indication of the services authorized for the authenticated device.
デバイスはPANAを使用することによって認証された後、それがために承認されなければなりません「ネットワークアクセス。」これは、PACのデバイスが送信し、任意のIPパケットを受け取ることができるようにPANAのコア要件は、PACの承認を検証することにあります。また、QoSのまたは個別のサービス（例えば、HTTP、SSH対）の認可など、より細かい粒度の認可を、提供することが可能です。しかし、バックエンド認証インフラストラクチャ（例えば、RADIUSまたはDIAMETERベースのAAAインフラ）がPAAにそのような指標を提供するかもしれないが、それらの明示的なサポートは、PANAの範囲外です。例えば、PANAが認証されたデバイスのための認可済みのサービスのいずれかの指示を運ぶために必要とされません。
Providing access control functionality in the network is outside the scope of PANA. Client access authentication SHOULD be followed by access control to make sure only authenticated and authorized clients can send and receive IP packets via the access network. Access control can involve setting access control lists on the EPs. PANA protocol exchange identifies clients that are authorized to access the network. If IPsec-based access control is deployed in an access network, PaC and EPs should have the required IPsec SA in place. Generating the IPsec SAs based on EAP keys is outside the scope of PANA protocol. This transformation MUST be handled by a separate secure association protocol (see section 4.1.1).
ネットワークアクセス制御機能を提供するPANAの範囲外です。クライアントアクセス認証は、認証および承認されたクライアントは、アクセスネットワークを介してIPパケットを送受信できることを確認するために、アクセス制御を記述する必要があります。アクセス制御をEPSにアクセス制御リストを設定することを含むことができます。 PANAプロトコル交換は、ネットワークへのアクセスを許可されたクライアントを識別します。 IPsecベースのアクセス制御は、アクセスネットワークに配置されている場合は、PaCでとEPSは場所に必要なのIPsec SAを持っている必要があります。 EAPキーに基づいてIPSec SAを生成することは、PANAプロトコルの範囲外です。この変換は、別のセキュアアソシエーションプロトコルによって処理されなければならない（セクション4.1.1を参照）。
Carrying accounting data is outside the scope of PANA.
アカウンティングデータを運ぶことはPANAの範囲外です。
PANA protocol MUST NOT make any assumptions on the backend authentication protocol or mechanisms. A PAA MAY interact with backend AAA infrastructures such as RADIUS or Diameter, but it is not a requirement. When the access network does not rely on an IETF-defined AAA protocol (e.g., RADIUS, Diameter), it can still use a proprietary backend system, or rely on the information locally stored on the authentication agents.
PANAプロトコルは、バックエンドの認証プロトコルやメカニズムのいずれかの仮定をしてはなりません。 PAAは、RADIUSまたはDIAMETERなどのバックエンドAAAインフラストラクチャと相互作用することができるが、それは必要条件ではありません。アクセスネットワークは、IETF定義のAAAプロトコル（例えば、RADIUS、直径）に依存しない場合、それはまだ、独自のバックエンドシステムを使用するか、またはローカル認証エージェントに記憶された情報に頼ることができます。
The interaction between the PAA and the backend authentication entities is outside the scope of PANA.
PAAとバックエンド認証エンティティとの間の相互作用は、PANAの範囲外です。
PANA SHOULD allow various types of identifiers to be used as the PaCI (e.g., username, Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), etc.). This requirement generally relies on the client identifiers supported by various EAP methods.
PANAは、識別子の各種のPacIとして使用することを可能にすべきである（例えば、ユーザ名、ネットワークアクセス識別子（NAI）、完全修飾ドメイン名（FQDN）、等）。この要件は、一般的に、様々なEAP方法でサポートされているクライアント識別子に依存しています。
PANA SHOULD allow various types of identifiers to be used as the DI (e.g., IP address, link-layer address, port number of a switch, etc.).
PANAは、識別子の各種DIとして使用することを可能にすべきである（例えば、IPアドレス、リンクレイヤアドレス、スイッチのポート番号、等）。
A PAA MUST be able to create a binding between the PaCI and the associated DI upon successful PANA exchange. This can be achieved by PANA communicating the PaCI and DI to the PAA during the protocol exchange. The DI can be carried either explicitly as part of the PANA payload, or implicitly as the source of the PANA message, or both. Multi-access networks also require use of a cryptographic protection along with DI filtering to prevent unauthorized access [RFC4016]. The keying material required by the cryptographic methods needs to be indexed by the DI. As described in section 4.1.2, the binding between DI and PaCI is used for access control and accounting in the network.
PAAは、成功したPANA交換時PacIおよび関連するDIとの間の結合を作り出すことができなければなりません。これは、PANAプロトコル交換中にPAAにPacIおよびDIを通信することによって達成することができます。 DIは、明示的にPANAペイロードの一部として、または暗黙的にPANAメッセージ、または両方の供給源としてのいずれかで実施することができます。マルチアクセスネットワークはまた、不正なアクセス[RFC4016]を防ぐために、DIフィルタと共に暗号保護の使用を必要とします。暗号化の方法によって必要とされる鍵材料は、DIによって索引付けされる必要があります。セクション4.1.2で説明したように、DIおよびPacIとの間の結合は、ネットワーク内のアクセス制御と課金のために使用されます。
Assigning an IP address to the client is outside the scope of PANA. PaC MUST configure an IP address before running PANA.
クライアントにIPアドレスを割り当てると、PANAの範囲外です。 PACはPANAを実行する前に、IPアドレスを設定する必要があります。
The EAP protocol imposes various requirements on its transport protocols that are based on the nature of the EAP protocol, and need to be satisfied for correct operation. Please see [RFC3748] for the generic transport requirements that MUST be satisfied by PANA.
EAPプロトコルはEAPプロトコルの性質に基づいて、そのトランスポートプロトコル上の様々な要件を課し、正しい動作のために満たされる必要があります。 PANAが満たさなければならない一般的な輸送要件については、[RFC3748]を参照してください。
PANA does not assume that the PAA is always co-located with the EP(s). Network access enforcement can be provided by one or more nodes on the same IP subnet as the client (e.g., multiple routers), or on another subnet in the access domain (e.g., gateway to the Internet, depending on the network architecture). When the PAA and the EP(s) are separated, another transport for client provisioning is necessary. This transport is needed to create access control lists in order to allow authenticated and authorized clients' traffic through the EPs. PANA Working Group will preferably identify an existing protocol solution that allows the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. Possible candidates include, but are not limited to COPS, SNMP, Diameter, etc.
PANAはPAAは常にEP（S）と同じ場所にあることを前提としていません。ネットワークアクセス施行は、クライアント（例えば、複数のルータ）と同じIPサブネット上に1つ以上のノードによって提供される、またはすることができ、アクセスドメイン内の別のサブネット上に（例えば、インターネットへのゲートウェイ、ネットワークアーキテクチャに依存します）。 PAAとEP（S）が分離されている場合、クライアント・プロビジョニングのための別の輸送が必要です。この輸送はのEPを使用して認証および認可クライアントのトラフィックを許可するために、アクセス制御リストを作成するために必要とされます。 PANAワーキンググループは、好ましくは、PAAがエンコーダパケットから分離されている場合、PAAは、1つまたは複数のEPSへ認証情報を配信することを可能にする既存のプロトコル・ソリューションを特定します。可能性のある候補者には、それだけなどCOPS、SNMP、直径が、これらに限定されません
The communication between PAA and EP(s) MUST be secure. The objective of using a PAA-to-EP protocol is to provide filtering rules to EP(s) for allowing network access of a recently authenticated and authorized PaC. The chosen protocol MUST be capable of carrying DI and cryptographic keys for a given PaC from PAA to EP. Depending on the PANA protocol design, support for either of the pull model (i.e., EP initiating the PAA-to-EP protocol exchange per PaC) or the push model (i.e., PAA initiating the PAA-to-EP protocol exchange per PaC), or both may be required. For example, if the design is such that the EP allows the PANA traffic to pass through even for unauthenticated PaCs, the EP should also allow and expect the PAA to send the filtering information at the end of a successful PANA exchange without the EP ever sending a request.
PAAとEPとの間の通信が安全でなければなりません。 PAA対EPプロトコルを使用することの目的は、最近、認証及び認可のPACネットワークアクセスを可能にするためのEP（複数可）にフィルタルールを提供することです。選択されたプロトコルは、EPのPAAから所与のPaCのためのDI及び暗号鍵を運ぶことができなければなりません。プルモデルのいずれかのためのPANAプロトコルの設計、サポートによって（すなわち、のPaCあたりPAA-に-EPプロトコル交換を開始EP）またはプッシュモデルを（すなわち、PAAは、PACあたりPAA-に-EPプロトコル交換を開始します） 、またはその両方が必要とされ得ます。デザインはEPがPANAトラフィックも認証されていないPaCのために通過することを可能にするようなものである場合、例えば、EPも許可し、PAAはEPがこれまでに送信せずに成功したPANA交換の終わりにフィルタリング情報を送信するために期待するべきですリクエスト。
PANA MUST support PaCs with multiple interfaces, and networks with multiple routers on multi-access links. In other words, PANA MUST NOT assume that the PaC has only one network interface, that the access network has only one first hop router, or that the PaC is using a point-to-point link.
PANAは、複数のインターフェイス、マルチアクセスリンク上の複数のルータとネットワークとPACをサポートしなければなりません。換言すれば、PANAは、アクセスネットワークが一つだけ最初のホップルータを有すること、PACは1つだけのネットワークインターフェースを有すると仮定してはいけません、またはPACはポイントツーポイントリンクを使用しています。
PANA MUST NOT assume that the link is connection-oriented. Links may or may not provide disconnect indication. Such notification is desirable in order for the PAA to clean up resources when a client moves away from the network (e.g., inform the enforcement points that the client is no longer connected). PANA SHOULD have a mechanism to provide disconnect indication. PANA MUST be capable of securing disconnect messages in order to prevent malicious nodes from leveraging this extension for DoS attacks.
PANAは、リンクが接続指向であると仮定してはいけません。リンクまたは切断指示を提供しない場合があります。このような通知は、クライアントがネットワーク（例えば、クライアントがもはや接続されていることを実施ポイントを通知しない）から離れたときにリソースをクリーンアップするPAAためには望ましいです。 PANAは、切断指示を提供するためのメカニズムを持っているべきです。 PANAは、DoS攻撃のためにこの拡張機能を活用することから悪意のあるノードを防ぐために、切断メッセージを確保することができなければなりません。
This mechanism MUST allow the PAA to be notified about the departure of a PaC from the network. This mechanism MUST also allow a PaC to be notified about the discontinuation of the network access service. Access discontinuation can occur due to various reasons such as network systems going down or a change in the access policy.
このメカニズムは、PAAは、ネットワークからのPaCの出発について通知することを許可する必要があります。また、このメカニズムは、PACは、ネットワークアクセスサービスの中止を通知することを許可する必要があります。アクセス中止は、そのようなネットワークのダウンシステムやアクセスポリシーの変更など、さまざまな理由により発生する可能性があります。
In case the clients cannot send explicit disconnect messages to the PAA, it can still detect their departure by relying on periodic authentication requests.
場合は、クライアントがPAAに明示的な切断メッセージを送信することはできません、それはまだ定期的な認証要求に依存することによって彼らの出発を検出することができます。
The PAA and PaC MUST be exactly one IP hop away from each other. That is, there must be no IP routers between the two. Note that this does not mean they are on the same physical link. Bridging and tunneling (e.g., IP-in-IP, GRE, L2TP, etc.) techniques can place two nodes just exactly one IP hop away from each other although they might be connected to separate physical links. A PAA can be on the network access server (NAS) or WLAN access point or first hop router. The use of PANA when the PAA is multiple IP hops away from the PaC is outside the scope of PANA.
PAAとPACは、1つのIPが互いに離れるホップでなければなりません。つまり、両者の間にIPルータがあってはなりません。これは、彼らが同じ物理リンク上にあるという意味ではありませんので注意してください。ブリッジとトンネリング（例えば、IPインIP等、GRE、L2TP）技術は、それらが物理リンクを分離するために接続されるかもしれないがちょうど正確に一つのIPが互いに離れるホップつのノードを配置することができます。 PAAは、ネットワークアクセスサーバ（NAS）またはWLANアクセスポイントまたは最初のホップルータであることができます。 PAAは、複数のIPによってPACから離れホップであるPANAの使用は、PANAの範囲外です。
A PaC may or may not be pre-configured with the IP address of PAA. Therefore the PANA protocol MUST define a dynamic discovery method. Given that the PAA is one hop away from the PaC, there are a number of discovery techniques that could be used (e.g., multicast or anycast) by the PaC to find out the address of the PAA.
PACは、またはPAAのIPアドレスを事前設定してもしなくてもよいです。従ってPANAプロトコルは、動的検出方法を定義しなければなりません。 PAA一つ離れたPaCからのホップであることを考えると、PAAのアドレスを見つけるためのPaCにより（例えば、マルチキャストまたはエニーキャスト）を使用することができる発見の多くの技術が存在します。
PANA MUST NOT assume the presence of a secure channel between the PaC and the PAA. PANA MUST be able to provide authentication especially in networks which are not protected against eavesdropping and spoofing. PANA MUST enable protection against replay attacks on both PaCs and PAAs.
PANAは、PACとPAA間のセキュアなチャネルの存在を仮定してはいけません。 PANAは特に盗聴やなりすましから保護されていないネットワークで認証を提供できなければなりません。 PANAはPaCのとPaaSの両方でリプレイ攻撃に対する保護を有効にする必要があります。
This requirement partially relies on the EAP protocol and the EAP methods carried over PANA. Use of EAP methods that provide mutual authentication and key derivation/distribution is essential for satisfying this requirement. EAP does not make a secure channel assumption, and supports various authentication methods that can be used in such environments. Additionally, PANA MUST ensure that its design does not contain vulnerabilities that can be exploited when it is used over insecure channels. PANA MAY provide a secure channel by deploying a two-phase authentication. The first phase can be used for creation of the secure channel, and the second phase for client and network authentication.
この要件は、部分的にEAPプロトコルとPANA上で運ばEAP方式に依存しています。相互認証および鍵導出/配布を提供EAPメソッドを使用すると、この要件を満たすために不可欠です。 EAPは、セキュリティで保護されたチャネルの仮定を行い、そのような環境で使用できるさまざまな認証方式をサポートしていません。また、PANAは、その設計は、それが安全でないチャネルを介して使用した場合に悪用される可能な脆弱性が含まれていないことを保証しなければなりません。 PANAは、二相の認証を展開することにより、安全なチャネルを提供することができます。第一段階は、セキュアなチャネルの作成、およびクライアントとネットワーク認証のための第二段階のために使用することができます。
Mobility management is outside the scope of PANA. However, PANA MUST be able to co-exist and MUST NOT unintentionally interfere with various mobility management protocols, such as Mobile IPv4 [RFC3344], Mobile IPv6 [RFC3775], fast handover protocols [FMIPv6] [FMIPv4], and other standard protocols like IPv6 stateless address auto-configuration [RFC2461] (including privacy extensions [RFC3041]), and DHCP [RFC2131] [RFC3315]. PANA MUST NOT make any assumptions on the protocols or mechanisms used for IP address configuration of the PaC.
モビリティ管理は、PANAの範囲外です。しかし、PANAは共存することができなければならないと意図せずにそのようなモバイルIPv4 [RFC3344]、モバイルIPv6 [RFC3775]、高速ハンドオーバプロトコル[FMIPv6と] [FMIPv4]など他の標準プロトコルとして、種々のモビリティ管理プロトコルを妨害してはなりませんIPv6ステートレスアドレス自動設定（プライバシー拡張[RFC3041]を含む）[RFC2461]、およびDHCP [RFC2131] [RFC3315]。 PANAは、PACのIPアドレスの設定のために使用されるプロトコルやメカニズム上の任意の仮定をしてはなりません。
PANA design SHOULD efficiently handle the authentication process in order to gain network access with minimum latency. For example, it may minimize the protocol signaling by creating local security associations.
PANA設計は、効率的に最小レイテンシでのネットワークアクセスを得るために認証プロセスを処理する必要があります。例えば、ローカルセキュリティアソシエーションを作成することにより、プロトコルシグナリングを最小化することができます。
PANA MUST provide congestion control for the protocol messaging. Under certain conditions PaCs might unintentionally get synchronized when sending their requests to the PAA (e.g., upon recovering from a power outage on the access network). The network congestion generated from such events can be avoided by using techniques like delayed initialization and exponential back off.
PANAは、プロトコルメッセージングのための輻輳制御を提供しなければなりません。 （例えば、アクセスネットワーク上の停電からの復旧時）PAAへのリクエストを送信する際に特定の条件下でPACSが意図せずに同期されてしまうかもしれません。そのようなイベントから生成されたネットワーク輻輳バックオフ遅延初期化および指数のような技術を使用することによって回避することができます。
PANA MUST work with both IPv4 and IPv6.
PANAは、IPv4とIPv6の両方で動作しなければなりません。
PANA MUST be robust against a class of DoS attacks such as blind masquerade attacks through IP spoofing. These attacks would swamp the PAA, causing it to spend resources and prevent network access by legitimate clients.
PANAは、IPスプーフィングによって、このような盲目の仮面舞踏会攻撃などのDoS攻撃のクラスに対して堅牢でなければなりません。これらの攻撃は、リソースを費やすし、正当なクライアントによるネットワークアクセスを防止することを引き起こして、PAAを圧倒します。
Some clients might prefer hiding their identity from visited access networks for privacy reasons. Providing identity protection for clients is outside the scope of PANA. Note that some authentication methods may already have this capability. Where necessary, identity protection can be achieved by letting PANA carry such authentication methods.
一部のクライアントは、プライバシー上の理由のために訪問したアクセスネットワークから自分のアイデンティティを隠し好むかもしれません。クライアント用のアイデンティティ保護を提供することはPANAの範囲外です。いくつかの認証方法は、すでにこの能力を持っていることに注意してください。必要な場合には、ID保護はPANAは、このような認証方法を実行させることによって達成することができます。
This document identifies requirements for the PANA protocol design. Due to the nature of this protocol, most of the requirements are security related. The actual protocol design is not specified in this document. A thorough discussion on PANA security threats can be found in PANA Threat Analysis and Security Requirements [RFC4016]. Security threats identified in that document are already included in this general PANA requirements document.
この文書では、PANAプロトコルの設計のための要件を識別します。これによって、プロトコルの性質のために、要件のほとんどは、セキュリティ関連のあります。実際のプロトコルの設計は、この文書で指定されていません。 PANAセキュリティの脅威の徹底的な議論は、PANA脅威の分析とセキュリティ要件[RFC4016]で見つけることができます。その文書で特定されたセキュリティ上の脅威は、すでにこの一般的なPANAの要件文書に含まれています。
Authors would like to thank Bernard Aboba, Derek Atkins, Steven Bellovin, Julien Bournelle, Subir Das, Francis Dupont, Dan Forsberg, Pete McCann, Lionel Morand, Thomas Narten, Mohan Parthasarathy, Basavaraj Patil, Hesham Soliman, and the PANA Working Group members for their valuable contributions to the discussions and preparation of this document.
著者はバーナードAboba、デレク・アトキンス、スティーブンBellovin氏、ジュリアンBournelle、Subirダス、フランシスデュポン、ダンフォースバーグ、ピートマッキャン、ライオネル・モラン、トーマスNarten氏、モハンパルタサラティ、Basavarajパティル、Heshamソリマン、およびPANA作業部会のメンバーに感謝したいと思います議論や本文書の作成に彼らの貴重な貢献のために。
Appendix A. Problem Statement
付録A.問題文
Access networks in most cases require some form of authentication in order to prevent unauthorized usage. In the absence of physical security (and sometimes in addition to it) a higher layer (L2+) access authentication mechanism is needed. Depending on the deployment scenarios, a number of features are expected from the authentication mechanism. For example, support for various authentication methods (e.g., MD5, TLS, SIM, etc.), network roaming, network service provider discovery and selection, separate authentication for access (L1+L2) service provider and ISP (L3), etc. In the absence of a link-layer authentication mechanism that can satisfy these needs, operators are forced to either use non-standard ad-hoc solutions at layers above the link, insert additional shim layers for authentication, or misuse some of the existing protocols in ways that were not intended by design. PANA will be developed to fill this gap by defining a standard network-layer access authentication protocol. As a network-layer access authentication protocol, PANA can be used over any link-layer that supports IP.
ほとんどの場合、アクセスネットワークは、不正使用を防ぐために、何らかの形式の認証を必要とします。物理的なセキュリティの非存在下で（時にはそれに加えて）より高い層（L2 +）アクセス認証機構が必要です。展開シナリオによっては、機能の数は、認証機構から期待されています。例えば、ネットワークは、ローミング様々な認証方法（例えば、MD5、TLS、SIMなど）、ネットワークサービスプロバイダの発見および選択、アクセスのために別個の認証のサポート（L1 + L2）サービスプロバイダとISP（L3）、等これらのニーズを満たすことができるリンク層の認証機構がない場合には、事業者は、リンク上の層では非標準のアドホックソリューションを使用して認証するための追加のシム層を挿入し、または、既存のプロトコルの一部を誤用のいずれかに強制されています設計者が意図していなかった方法。 PANAは、標準的なネットワーク層アクセス認証プロトコルを定義することによって、このギャップを埋めるために開発されます。ネットワーク層のアクセス認証プロトコルとして、PANAは、IPをサポートする任意のリンク層の上に使用することができます。
DSL networks are a specific example where PANA has the potential for addressing some of the deployment scenarios. Some DSL deployments do not use PPP [RFC1661] as the access link-layer (IP is carried over ATM and the subscriber device is either statically or DHCP-configured). The operators of these networks are left either using an application-layer web-based login (captive portal) scheme for subscriber authentication, or providing a best-effort service only as they cannot perform subscriber authentication required for the differentiated services. The captive portal scheme is a non-standard solution that has various limitations and security flaws.
DSLネットワークはPANAが展開シナリオの一部に対処するための可能性を秘めている具体的な例です。いくつかのDSLの展開は、アクセスリンク層としてPPP [RFC1661]を使用していない（IPは、ATM上で伝送され、加入者デバイスは、静的またはDHCP-設定されています）。これらのネットワークの事業者は、加入者認証のためのアプリケーション層のWebベースのログイン（キャプティブポータル）方式を使用して、または、彼らは差別化されたサービスのために必要な加入者認証を行うことができないだけのようにベストエフォート型のサービスを提供するいずれか残っています。キャプティブポータル方式は様々な制限やセキュリティ上の欠陥を持っている非標準的なソリューションです。
PPP-based authentication can provide some of the required functionality. But using PPP only for authentication is not a good choice, as it incurs additional messaging during the connection setup and extra per-packet processing. It also forces the network topology to a point-to-point model. Aside from resistance to incorporating PPP into an architecture unless it is absolutely necessary, there is even interest in the community in removing PPP from some of the existing architectures and deployments (e.g., 3GPP2, DSL).
PPPベースの認証が必要な機能の一部を提供することができます。それは接続設定と余分なパケットあたりの処理中に追加のメッセージングを負うとしてではなく、唯一の認証のためにPPPを使用することは、良い選択ではありません。また、ポイント・ツー・ポイント・モデルへのネットワークトポロジを強制します。別にそれが絶対に必要でない限り、アーキテクチャにPPPを組み込むに対する耐性から、既存のアーキテクチャと展開（例えば、3GPP2、DSL）の一部からPPPを除去するのにコミュニティにおけるも関心があります。
Using Mobile IPv4 authentication with a foreign agent instead of proper network access authentication is an example of protocol misuse. The Registration Required flag allows a foreign agent to force authentication even when the agent is not involved in any Mobile IPv4 signalling (co-located care-of address case). This enables the use of a mobility-specific protocol for an unrelated functionality.
代わりに、適切なネットワークアクセス認証のフォーリンエージェントとモバイルIPv4認証を使用するプロトコル誤用の一例です。登録が必要フラグは、薬剤は、任意のモバイルIPv4シグナリング（同一位置気付アドレスの場合）に関与していない場合であっても、外部エージェントは、認証を強制することを可能にします。これは関係のない機能のためのモビリティ固有のプロトコルの使用を可能にします。
PANA will carry EAP above IP in order to enable any authentication method on any link-layer. EAP can already be carried by [IEEE-802.1X] and PPP. IEEE 802.1X can only be used on unbridged IEEE 802 links, hence it only applies to limited link types. Inserting PPP between IP and a link-layer can be perceived as a way to enable EAP over that particular link-layer, but using PPP for this reason has the aforementioned drawbacks and is not a good choice. While IEEE 802.1X and PPP can continue to be used in their own domains, they do not take away the need to have a protocol like PANA.
PANAは、任意のリンク層上の任意の認証方法を有効にするためにIP上でEAPを運ぶでしょう。 EAPは、すでに[IEEE-802.1X]とPPPによって実施することができます。 IEEE 802.1Xは、したがって、それは限られたリンクタイプに適用され、非架橋IEEE 802のリンクにのみ使用することができます。 IPおよびリンク層の間でPPPを挿入するには、その特定のリンク層の上にEAPを有効にする方法として認識が、この理由でPPPを使用すると、上記の欠点を持っているし、良い選択ではありませんすることができます。 IEEE 802.1XとPPPは、独自のドメインで使用し続けることができるが、それらはPANAのようなプロトコルを持つ必要性を奪うことはありません。
Appendix B. Usage Scenarios
付録B.の使用シナリオ
PANA will be applicable to various types of networks. Based on the presence of lower-layer security prior to running PANA, the following types cover all possibilities:
PANAは、ネットワークの様々なタイプに適用されます。前PANAを実行する下位層のセキュリティの存在に基づいて、次のタイプは、すべての可能性をカバーします：
a) Physically secured networks (e.g., DSL networks). Although data traffic is always carried over a physically secured link, the client might need to be authenticated and authorized when accessing the IP services.
A）物理的に固定ネットワーク（例えば、DSLネットワーク）。データトラフィックは、常に物理的に保護されたリンクを介して行われているが、クライアントはIPサービスにアクセスする際に認証および承認が必要になることがあります。
b) Networks where L1-L2 is already cryptographically secured before enabling IP (e.g., cdma2000 networks). Although the client is authenticated on the radio link before enabling ciphering, it additionally needs to get authenticated and authorized for accessing the IP services.
L1-L2が既に暗号IP（例えば、CDMA2000ネットワーク）を有効にする前に、固定されているB）ネットワーク。クライアントが暗号化を有効にする前に、無線リンク上で認証されているが、それは、さらにIPサービスにアクセスするための認証および承認を取得する必要があります。
c) No lower-layer security present before enabling IP. PANA is run in an insecure network. PANA-based access authentication is used to bootstrap cryptographic per-packet authentication and integrity protection.
c）のIPを有効にする前に、ノー下位層のセキュリティ存在。 PANAは、安全でないネットワークで実行されます。 PANAベースのアクセス認証は、暗号化パケットごとの認証と完全性保護をブートストラップするために使用されます。
PANA is applicable to not only large-scale operator deployments with full AAA infrastructure, but also to small disconnected deployments like home networks and personal area networks.
PANAは、完全なAAAインフラストラクチャとの大規模な演算子の展開のみならず、だけでなく、ホームネットワークおよびパーソナルエリアネットワークのような小規模な切断の展開にも適用することができます。
Since PANA enables decoupling AAA from the link-layer procedures, network access authentication does not have to take place during the link establishment. This allows deferring client authentication until the client attempts to access differentiated services (e.g., high bandwidth, unlimited access, etc.) in some deployments. Additionally, multiple simultaneous network access sessions over the same link-layer connection can occur as well.
PANAは、リンク層の手順からAAAを分離できるため、ネットワークアクセス認証は、リンク確立中に行われる必要はありません。これにより、クライアントは、いくつかの展開で差別化サービス（例えば、高帯域幅、無制限のアクセスなど）にアクセスしようとするまで、クライアント認証を延期できます。また、同じリンク層接続を介して複数の同時ネットワークアクセスセッションも同様に発生する可能性があります。
The following five scenarios capture the PANA usage model in different network architectures with reference to its placement of logical elements such as the PANA Client (PaC) and the PANA Authentication Agent (PAA) with respect to the Enforcement Point (EP) and the Access Router (AR). Note that PAA may or may not use AAA infrastructure to verify the credentials of PaC in order to authorize network access.
以下の5つのシナリオでは、施行ポイント（EP）とアクセスルータに対して、そのようなPANAクライアント（PAC）などの論理要素の配置とPANA認証エージェント（PAA）を参照して、異なるネットワークアーキテクチャでPANA使用モデルをキャプチャ（AR）。そのPAAはネットワークアクセスを許可するために、PaCでの資格情報を検証するために、AAAインフラストラクチャを使用することはできません可能性があります。
Scenario 1: PAA co-located with EP but separated from AR
シナリオ1：PAAのEPと同じ場所に配置が、ARから分離
In this scenario (Figure 1), PAA is co-located with the enforcement point on which access control is performed. This might be the case where PAA is co-located with the L2 access device (e.g., an IP-capable switch).
このシナリオ（図1）において、PAAは、アクセス制御が行われる施行ポイントと同じ場所に配置されます。これは、PAAは、L2アクセスデバイス（例えば、IP対応のスイッチ）と同じ場所に配置されている場合であるかもしれません。
PaC -----EP/PAA--+
|
+------ AR ----- (AAA)
|
PaC -----EP/PAA--+
Figure 1: PAA co-located with EP but separated from AR.
図1：PAAとEPと同じ場所に配置しかしARから分離します。
Scenario 2: PAA co-located with AR but separated from EP
シナリオ2：PAAのARと同じ場所に配置が、EPから分離
In this scenario, PAA is not co-located with EPs but is placed on the AR. Although we have shown only one AR here, there could be multiple ARs, one of which is co-located with the PAA. Access control parameters have to be distributed to the respective enforcement points so that the corresponding device on which PaC is authenticated can access the network. A separate protocol is needed between PAA and EP to carry access control parameters.
このシナリオでは、PAAをEPSと同じ場所にではなく、AR上に配置されます。私たちはここに一つだけARを示しているが、PAAと同じ場所に配置されたそのうちの一つ、複数のAR、がある可能性があります。アクセス制御パラメータは、PACが認証された対応するデバイスがネットワークにアクセスできるように、各実施ポイントに配布されなければなりません。別のプロトコルは、アクセス制御パラメータを運ぶためにPAAとEPとの間に必要とされます。
PaC ----- EP --+
|
+------ AR/PAA --- (AAA)
|
PaC ----- EP --+
Figure 2: PAA co-located with AR but separated from EP
図2：PAAのARと同じ場所に配置しかしEPから分離
Scenario 3: PAA co-located with EP and AR
シナリオ3：PAAのEPとARと同じ場所に配置
In this scenario (Figure 3), PAA is co-located with the EP and AR on which access control and routing are performed.
このシナリオ（図3）において、PAAは、制御およびルーティングが行われるアクセスたEPとARと同じ場所に配置されます。
PaC ----- EP/PAA/AR--+
|
+-------(AAA)
|
PaC ----- EP/PAA/AR--+
Figure 3: PAA co-located with EP and AR.
図3：PAAのEPとARと同じ場所に配置。
Scenario 4: Separated PAA, EP, and AR
シナリオ4：別居PAA、EP、およびAR
In this scenario, PAA is neither co-located with EPs nor with ARs. It still resides on the same IP link as ARs. After successful authentication, access control parameters will be distributed to respective enforcement points via a separate protocol and PANA does not play any explicit role in this.
このシナリオでは、PAAはどちらのEPでものARと同じ場所に配置されます。それはまだのARと同じIPリンク上に存在します。認証が成功すると、アクセス制御パラメータは、別のプロトコルを介して各実施ポイントに配布され、PANAは、この中で明示的な役割を果たしていません。
PaC ----- EP -----+--- AR ---+
| |
PaC ----- EP --- -+ |
| |
PaC ----- EP -----+--- AR -- + ----(AAA)
|
+--- PAA
Figure 4: PAA, EP and AR separated.
図4：PAA、EP及びARを分離しました。
Scenario 5: PAA separated from co-located EP and AR
シナリオ5：PAAは共同設置EPとARから分離
In this scenario, EP and AR are co-located with each other but separated from PAA. PAA still resides on the same IP link as ARs. After successful authentication, access control parameters will be distributed to respective enforcement points via a separate protocol and PANA does not play any explicit role in this.
このシナリオでは、EPとARは、互いに同じ場所に配置されているが、PAAから分離します。 PAAはまだのARと同じIPリンク上に存在します。認証が成功すると、アクセス制御パラメータは、別のプロトコルを介して各実施ポイントに配布され、PANAは、この中で明示的な役割を果たしていません。
PaC --------------+--- AR/EP ---+
| |
PaC --------------+ |
| |
PaC --------------+--- AR/EP -- + ----(AAA)
|
+--- PAA
Figure 5: PAA separated from EP and AR.
図5：EPとARから分離PAA。
References
リファレンス
Normative References
引用規格
[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, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[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月。
Informative References
参考文献
[FMIPv4] Malki, K., "Low Latency Handoffs in Mobile IPv4", Work in Progress, June 2004.
[FMIPv4] Malki、K.進行中、 "モバイルIPv4における低遅延ハンドオフ"、仕事、2004年6月。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001.
電気電子学会、「地方とメトロポリタンエリアネットワーク：ポートベースのネットワークアクセスコントロール」の[IEEE-802.1X]研究所、IEEE標準802.1X、2001年9月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC826]プラマー、D.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上での送信のためにイーサネット（登録商標）アドレスを48ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256]デアリング、S.、 "ICMPルータ発見メッセージ"、RFC 1256、1991年9月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999.
[RFC2716] Aboba、B.及びD.シモン、 "PPP EAP TLS認証プロトコル"、RFC 2716、1999年10月。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794]カルフーン、P.とC.パーキンス、 "IPv4のモバイルIPネットワークアクセス識別子拡張"、RFC 2794、2000年3月。
[RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ Response Extensions", RFC 3012, November 2000.
[RFC3012]パーキンス、C.およびP.カルフーン、 "モバイルIPv4チャレンジ/レスポンス拡張機能"、RFC 3012、2000年11月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", Work in Progress.
[FMIPv6と] Koodli、R.、エド。、 "モバイルIPv6のための高速ハンドオーバ" が進行中で働いています。
Authors' Addresses
著者のアドレス
Alper E. Yegin (editor) Samsung Advanced Institute of Technology 75 West Plumeria Drive San Jose, CA 95134 USA
アルパースE. Yegin（エディタ）サムスン先端技術研究所の75西プルメリアドライブサンノゼ、CA 95134 USA
Phone: +1 408 544 5656 EMail: alper.yegin@samsung.com
電話：+1 408 544 5656 Eメール：alper.yegin@samsung.com
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
義弘大場東芝アメリカリサーチ社1のTelcordiaドライブピスカタウェイ、NJ 08854 USA
Phone: +1 732 699 5305 EMail: yohba@tari.toshiba.com
電話：+1 732 699 5305 Eメール：yohba@tari.toshiba.com
Reinaldo Penno Juniper Networks 10 Technology Park Drive Westford, MA 01886-3146 USA
レイナルドPennoジュニパーネットワークスの10テクノロジーパークドライブウェストフォード、マサチューセッツ州01886から3146 USA
EMail: rpenno@juniper.net
メールアドレス：rpenno@juniper.net
George Tsirtsis Flarion Bedminster One 135 Route 202/206 South Bedminster, NJ 07921 USA
ジョージTsirtsisフラリオンBedminster一つ135国道206分の202南Bedminster、NJ 07921 USA
Phone: +44 20 88260073 EMail: G.Tsirtsis@Flarion.com
電話：+44 20 88260073 Eメール：G.Tsirtsis@Flarion.com
Cliff Wang ARO/NCSU 316 Riggsbee Farm Morrisville, NC 27560 USA
クリフ王ARO / NCSU 316 Riggsbeeファームモリスビル、NC 27560 USA
Phone: +1 919 548 4207 EMail: cliffwangmail@yahoo.com
電話：+1 919 548 4207 Eメール：cliffwangmail@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。