RFC4058 日本語訳
4058 Protocol for Carrying Authentication for Network Access (PANA)Requirements. A. Yegin, Ed., Y. Ohba, R. Penno, G. Tsirtsis, C. Wang. May 2005. (Format: TXT=41957 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループA.Yegin、エドをネットワークでつないでください。コメントのために以下を要求してください。 4058年の三星オート麦カテゴリ: 情報のY.オオバ東芝R.ペンノ杜松はC.ワングARO/NCSU2005年5月にG.Tsirtsis Flarionをネットワークでつなぎます。
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).
Copyright(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デバイスにはネットワークの接続性を獲得するさまざまなアクセス技術があると予想されます。 現在、認証と承認目的のためのネットワークへの提供しているクライアント情報のためのアクセス特有のメカニズムがあります。 特定のアクセスメディア(例えば、IEEE802リンクへの802.1X)に制限されることに加えて、これらのプロトコルのいくつかが特定のネットワークtopologies(例えば、ポイントツーポイント接続へのPPP)に制限されます。 このドキュメントの目標はホストを許容するリンクレイヤ不可知論者プロトコルとネットワークがネットワークアクセサリーのために互いを認証するという要件を特定することです。 このプロトコルはクライアントのデバイスとエージェントの間でエージェントがAAAインフラストラクチャのクライアントであるかもしれないネットワークで稼働するでしょう。
Yegin, et al. Informational [Page 1] RFC 4058 PANA Requirements May 2005
Yegin、他 [1ページ]情報のRFC4058パーナ要件2005年5月
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
1. 序論…3 2. 要件記法…3 3. 用語…4 4. 要件…4 4.1. 認証…4 4.1.1. クライアントの認証…4 4.1.2. 承認、会計、およびアクセスは制御されます…6 4.1.3. 認証バックエンド…7 4.1.4. 識別子…7 4.2. IPアドレス課題…7 4.3. EAPは層の要件を下ろします…7 4.4. PAAからEPは議定書を作ります…8 4.5. ネットワークでつなぎます。8 4.5.1. マルチアクセス…8 4.5.2. 指示から切断してください…8 4.5.3. PAAの位置…9 4.5.4. チャンネルを固定してください…9 4.6. 他のプロトコルとの相互作用…10 4.7. パフォーマンス…10 4.8. 混雑コントロール…10 4.9. IPバージョン独立…10 4.10. サービス妨害は攻撃されます…10 4.11. クライアントアイデンティティプライバシー…10 5. セキュリティ問題…11 6. 承認…11 A.問題声明…12 B.用法シナリオ…13の参照箇所…16 標準の参照…16 有益な参照…16
Yegin, et al. Informational [Page 2] RFC 4058 PANA Requirements May 2005
Yegin、他 [2ページ]情報のRFC4058パーナ要件2005年5月
1. Introduction
1. 序論
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.
安全なネットワークアクセス・サービスはクライアントとアクセスネットワークの認証と承認に基づくアクセスコントロールを必要とします。 クライアントからネットワークへの初期の、そして、その後の認証は交通の流れを取り締まるのに必要であるパラメタを実施ポイントを通して提供します。 プロトコルが、クライアントとアクセスネットワークの間の認証パラメタを運ぶのに必要です。 関連する問題声明に関してAppendix 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登録要求メッセージは認証拡大(ミネソタ-FA[RFC3344]かミネソタ-AAA[RFC3012])のための外国人のエージェントに提供する前にサービスを進めながらモバイルノードを認証させるキャリヤーとして使用されます。 パーナの目標は認証情報のためのネットワーク層輸送を定義することを目指すという点において同様です。 しかしながら、パーナは、移動性管理から衝撃を吸収されて、認証ペイロードの定義のために他の仕様を当てにするでしょう。
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.
このドキュメントは、このグループがやるべき仕事の範囲を定義して、制限するのに使用されるパーナに、一般的な用語を定義して、プロトコルの要件を特定します。
2. Requirements Notation
2. 要件記法
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Yegin, et al. Informational [Page 3] RFC 4058 PANA Requirements May 2005
Yegin、他 [3ページ]情報のRFC4058パーナ要件2005年5月
3. Terminology
3. 用語
PANA Client (PaC)
パーナクライアント(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)
パーナクライアント識別子(PaCI)
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.
ネットワークアクセス認証のためにPaCによってPAAに提示される識別子。 簡単なユーザ名とNAI[RFC2794]はパーナクライアント識別子に関する例です。
Device Identifier (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)
パーナの認証エージェント(PAA)
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によって特定された資格証明書について確かめる責任がことであるプロトコルのアクセスネットワークサイド実体。
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.
アクセスでのノードは1パケットあたりの実施方針(すなわち、フィルタ)が本国行きでどこに適用されるか、そして、クライアントデバイスのアウトバウンドトラフィックをネットワークでつなぎます。 DIなどの情報と(任意に)暗号化キーは1クライアントあたりのPAAによってEPの上のフィルタを組み立てるのに提供されます。
4. Requirements
4. 要件
4.1. Authentication
4.1. 認証
4.1.1. Authentication of Client
4.1.1. クライアントの認証
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
パーナはネットワークアクセサリーのためにPaCsの認証を可能にしなければなりません。 デバイスかデバイス自体のユーザのひとりによって供給された資格証明書(例えば、識別子、固有識別文字)について確かめることによって、PaCのアイデンティティを認証できます。 パーナは別々のアクセスよりむしろDIによって特定されたデバイスへのネットワークアクセス・サービスを承諾するだけでよいです。
Yegin, et al. Informational [Page 4] RFC 4058 PANA Requirements May 2005
Yegin、他 [4ページ]情報のRFC4058パーナ要件2005年5月
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 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.
パーナは新しいセキュリティプロトコルかメカニズムを定義してはいけません。代わりに、そのようなプロトコルのための「キャリヤー」とそれを定義しなければなりません。 パーナは、それがどの特定のセキュリティプロトコルかメカニズムを運ぶことができるかを(「ペイロード」)特定しなければなりません。 EAPは認証のための多くの要件を満たす候補プロトコルです。 パーナはEAPのためのキャリヤープロトコルでしょう。 パーナ作業部会が、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.
このプロトコルの範囲の外にうまくいっているパーナの交換の後にデータ通信量のための認証、保全、および反復操作による保護を提供するのがあります。 物理的な層のセキュリティが存在していないネットワークでは、そのようなセキュリティを提供するのに、リンクレイヤかネットワーク層暗号(例えば、IPsec)を使用できます。 これらのメカニズムはPaCとEPで暗号の合わせることの材料を存在に要求します。 パーナは主要な派生か分配に対処しませんが、それは、EAPを運んで、適切なEAPメソッド選択を許すことによって、これを可能にします。 様々なEAPメソッドは安全な暗号スイート交渉、材料、一時的なセッションキーの新しさを合わせる所有物の互いの証拠、主要な命名などを含んでいて、IPsec SA(セキュリティ協会)の特性を欠いているのでIPsecと共に直接使用できない基本的な合わせることの材料を生成することができます。 必要なセキュリティ協会を生成するのにIKEのようなIPsecかぎ管理プロトコルと共にこれらの基本的な(初期の)EAPキーを使用できます。 安全な協会プロトコルと呼ばれる別々のプロトコルが、基本的なEAPキーに基づくIPsec SAsを生成するのに必要です。 このプロトコルはEPsでIPsecベースのアクセスコントロールを可能にすることができなければなりません。 EPとPaCの間にそれらを送るとき、IPsec SAsはデータ・パケットの認証、保全、および反復操作による保護を可能にしなければなりません。
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は物理的、そして、リンクレイヤ接続性をクライアントに提供するアクセスネットワークの所有者です。 パーナは同じクライアントのために、2つの独立している認証操作(すなわち、2つの別々のEAPメソッドの実行)を可能にすることができなければなりません。 したがって、操作上の問題とパーナの範囲の外に2の結果、承認パラメタが認証を切り離すことを決定するのがあります。
Yegin, et al. Informational [Page 5] RFC 4058 PANA Requirements May 2005
Yegin、他 [5ページ]情報のRFC4058パーナ要件2005年5月
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 MUSTの両方、ネットワークアクセサリーのための互いの認証を実行できてください。 PAAがPaCを認証する能力が十分でさえない場合、よかったでしょう。 互いの認証能力が、それらについていくつかの環境で必要ですが、全部で必要であるというわけではありません。 物理的なセキュリティが利用可能であるときに(例えば、ダイアルアップ・ネットワーク)、例えば、クライアントはアクセスネットワークを認証する必要はないかもしれません。
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.
パーナは周期的なものと同様に要求次第の再認証を行うことができなければなりません。 PaCとPAA MUSTの両方、初期の認証と再認証過程の両方を開始できてください。
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が交換かパーナの交換[RFC4016]の後に保護されないとき、サービス窃盗のあるタイプは可能です。 パーナには、PaCとPAAで間ネットワークが介入者攻撃に被害を受け易いしっかりとDIを交換する能力がなければなりません。 パーナはそのような能力を提供しなければなりませんが、ユーティリティはPaCとPAAで暗号の計算のためのキーを生成することができる認証方法の使用に依存します。
4.1.2. Authorization, Accounting, and Access Control
4.1.2. 承認、会計、およびアクセスコントロール
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.
デバイスがパーナを使用することによって認証された後に、「ネットワークアクセサリー」のためにそれを認可しなければなりません。 すなわち、パーナのコア要件はPaCのデバイスがどんなIPパケットも送って、受けることができるようにPaCの承認について確かめることです。 また、よりすばらしい粒状承認を提供するのも可能であるかもしれません、QoSか個々のサービス(例えば、http対セキュアシェル (SSH))のための承認などのように。 しかしながら、バックエンド承認インフラストラクチャ(例えば、RADIUSかDiameterが下にAAAを基礎づけた)はそのような指摘をPAAに供給するかもしれませんが、パーナの範囲の外にそれらの明白なサポートがあります。 例えば、パーナは、どんな認証されたデバイスのために認可されたサービスのしるしも運ぶのに必要ではありません。
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).
パーナの範囲の外にアクセス制御の機能性をネットワークに提供するのがあります。 クライアントアクセス認証SHOULDは念のため認証されただけであるコントロールと認可されたクライアントが送ることができるアクセスがあとに続いていて、アクセスネットワークを通してIPパケットを受けます。 アクセスコントロールは、EPsにアクセスコントロールリストを設定することを伴うことができます。 パーナのプロトコル交換はネットワークにアクセスするのに権限を与えられるクライアントを特定します。 IPsecベースのアクセスコントロールがアクセスネットワークで配布されるなら、PaCとEPsは適所に必要なIPsec SAを持っているはずです。 パーナプロトコルの範囲の外にEAPキーに基づくIPsec SAsを生成するのがあります。 別々の安全な協会プロトコルでこの変換を扱わなければなりません(セクション4.1.1を見てください)。
Carrying accounting data is outside the scope of PANA.
パーナの範囲の外に会計データを運ぶのがあります。
Yegin, et al. Informational [Page 6] RFC 4058 PANA Requirements May 2005
Yegin、他 [6ページ]情報のRFC4058パーナ要件2005年5月
4.1.3. Authentication Backend
4.1.3. 認証バックエンド
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.
メカニズムバックエンド認証プロトコルにおけるどんな仮定かPAA MAYもパーナプロトコルでRADIUSかDiameterなどのバックエンドAAAインフラストラクチャと対話してはいけませんが、それは要件ではありません。 アクセスネットワークがIETFの定義されたAAAプロトコル(例えば、RADIUS、Diameter)を当てにしないとき、それは、まだ独占バックエンドシステムを使用しているか、または認証エージェントの上に局所的に保存された情報を当てにすることができます。
The interaction between the PAA and the backend authentication entities is outside the scope of PANA.
パーナの範囲の外にPAAとバックエンド認証実体との相互作用があります。
4.1.4. Identifiers
4.1.4. 識別子
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 SHOULDは、様々なタイプに関する識別子がPaCI(例えば、ユーザ名、Network Access Identifier(NAI)、Fully Qualified Domain Name(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 SHOULDは、様々なタイプに関する識別子が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 MUST、うまくいっているパーナの交換のときにPaCIと関連DIの間で結合を作成できてください。 プロトコル交換の間にPaCIとDIをPAAに伝えるパーナはこれを達成できます。 パーナメッセージ、または両方の源としてパーナペイロードをそれとなく離れさせるとき、明らかにDIを運ぶことができます。 また、マルチアクセスネットワークは、不正アクセス[RFC4016]を防ぐためにDIフィルタリングに伴う暗号の保護の使用を必要とします。 材料が暗号のメソッドで必要とした合わせるのは、DIによって索引をつけられる必要があります。 セクション4.1.2で説明されるように、DIとPaCIの間の結合はネットワークにおけるアクセスコントロールと会計に使用されます。
4.2. IP Address Assignment
4.2. IPアドレス課題
Assigning an IP address to the client is outside the scope of PANA. PaC MUST configure an IP address before running PANA.
パーナの範囲の外にIPアドレスをクライアントに割り当てるのがあります。 パーナを実行する前に、PaCはIPアドレスを構成しなければなりません。
4.3. EAP Lower Layer Requirements
4.3. EAP下層要件
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プロトコルの本質に基づいていて、正しい操作のために満たされる必要があるトランスポート・プロトコルに様々な要件を課します。 パーナが満たさなければならないジェネリック輸送要件に関して[RFC3748]を見てください。
Yegin, et al. Informational [Page 7] RFC 4058 PANA Requirements May 2005
Yegin、他 [7ページ]情報のRFC4058パーナ要件2005年5月
4.4. PAA-to-EP Protocol
4.4. PAAからEPへのプロトコル
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.
パーナは、PAAがEP(s)と共にいつも共同見つけられていると仮定しません。 クライアントと同じIPサブネット(例えば、倍数ルータ)の上、または、アクセスドメインの別のサブネット(例えば、ネットワークアーキテクチャによるインターネットへのゲートウェイ)の上の1つ以上のノードはネットワークアクセス実施を提供できます。 PAAとEP(s)が切り離されるとき、クライアントの食糧を供給する別の輸送が必要です。 この輸送が、認証されて認可されたクライアントのトラフィックのEPsに通ることを許すためにアクセスコントロールリストを作成するのに必要です。 望ましくは、パーナ作業部会はPAAがEPsと切り離されるときPAAが承認情報を1EPsに提供できる既存のプロトコルソリューションを特定するでしょう。 COPS、SNMP、Diameterなどに含んでいますが、可能な候補は限られていません。
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(s)とのコミュニケーションは安全であるに違いありません。 PAAからEPへのプロトコルを使用する目的は最近、認証されて、認可されたPaCのネットワークアクセスを許すためにEP(s)に規則をフィルターにかけながら提供することです。 選ばれたプロトコルは与えられたPaCのためにPAAからEPまでDIと暗号化キーを運ぶことができなければなりません。 パーナプロトコルデザインによって、牽引力のモデル(すなわち、PAAからEPへのプロトコル1PaCあたりの交換を起こすEP)かプッシュモデルのどちらかのために(すなわち、PAAからEPへのプロトコル1PaCあたりの交換を起こすPAA)をサポートしてください。さもないと、両方が必要であるかもしれません。 例えば、EPがデザインがそのようなものであるのでunauthenticated PaCsのためにさえパーナトラフィックを通り抜けさせるなら、また、EPは、要求を送りながら、PAAがEPなしでうまくいっているパーナの交換の終わりにフィルタリング情報を送ると許容して、予想するはずです。
4.5. Network
4.5. ネットワーク
4.5.1. Multi-access
4.5.1. マルチアクセス
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.
パーナは、複数のインタフェースでPaCsをサポートして、マルチアクセスリンクの上に複数のルータがある状態で、ネットワークをサポートしなければなりません。 言い換えれば、パーナは、PaCには1つのネットワーク・インターフェースしかないか、アクセスネットワークに1/1ホップルータしかないか、またはPaCがポイントツーポイント接続を使用していると仮定してはいけません。
4.5.2. Disconnect Indication
4.5.2. 指示から切断してください。
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
パーナは、リンクが接続指向であると仮定してはいけません。 リンクは分離指示を提供するかもしれません。 クライアントがネットワークから遠くに移行するとき(例えば、クライアントがもう接されないという実施ポイントを知らせてください)、PAAがリソースをきれいにするように、そのような通知は望ましいです。 PANA SHOULDには、メカニズムがあります。
Yegin, et al. Informational [Page 8] RFC 4058 PANA Requirements May 2005
Yegin、他 [8ページ]情報のRFC4058パーナ要件2005年5月
provide disconnect indication. PANA MUST be capable of securing disconnect messages in order to prevent malicious nodes from leveraging this extension for DoS attacks.
分離指示を提供してください。 パーナは、悪意があるノードが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に送ることができないといけないので、それは周期的な認証要求に依存することによって、まだ彼らの出発を検出できます。
4.5.3. Location of PAA
4.5.3. 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ホップであるに違いありません。 すなわち、2つの間には、IPルータが全くあるはずがありません。 これが、彼らが同じ物理的なリンクの上にいることを意味しないことに注意してください。 テクニックをブリッジして、トンネルを堀ると(例えば、中のIP IP、GRE、L2TPなど)、それらは物理的なリンクを切り離すために接続されるかもしれませんが、ちょうどちょうど1IPが互いから遠くを飛び越す2つのノードを置くことができます。 PAAがネットワークアクセス・サーバー(NAS)、WLANアクセスポイントまたは最初のホップルータにあることができます。 PAAがPaCから遠くの複数のIPホップであるときに、パーナの範囲の外にパーナの使用があります。
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アドレスであらかじめ設定されるかもしれません。 したがって、パーナプロトコルはダイナミックな発見メソッドを定義しなければなりません。 PAAが遠くでPaCからワンバウンドであるなら、PaCがPAAのアドレスを見つけるのに使用できた(例えば、マルチキャストかanycast)多くの発見のテクニックがあります。
4.5.4. Secure Channel
4.5.4. 安全なチャンネル
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.
パーナはPaCとPAAの間の安全なチャンネルの存在を仮定してはいけません。 パーナは特に盗聴に対して保護されて、だまされていないネットワークに認証を提供できなければなりません。 パーナはPaCsと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
この要件はEAPプロトコルとパーナの上まで運ばれたEAPメソッドを部分的に当てにします。 この要件を満たすのに、互いの認証と主要な派生/分配を提供するEAPメソッドの使用は不可欠です。 EAPは安全なチャンネル仮定をしないで、そのような環境で使用できる様々な認証方法をサポートします。 さらに、パーナは、デザインがそれが不安定なチャンネルの上に使用されるとき利用できる脆弱性を含まないのを確実にしなければなりません。 パーナは安全なチャンネルを提供するかもしれません。
Yegin, et al. Informational [Page 9] RFC 4058 PANA Requirements May 2005
Yegin、他 [9ページ]情報のRFC4058パーナ要件2005年5月
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.
二相が認証であると配布します。 安全なチャンネルの作成、およびクライアントとネットワーク認証のための2番目のフェーズに第1段階を使用できます。
4.6. Interaction with Other Protocols
4.6. 他のプロトコルとの相互作用
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.
パーナの範囲の外に移動性管理があります。 しかしながら、パーナは、共存できなければならなくて、IPv6の状態がないアドレス自動構成[RFC2461](プライバシー拡大[RFC3041]を含んでいる)、およびDHCP[RFC2131]のようなモバイルIPv4などの様々な移動性管理プロトコル[RFC3344]、モバイルIPv6[RFC3775]、速い引き渡しプロトコル[FMIPv6][FMIPv4]、および他の標準プロトコル[RFC3315]を何気なく妨げてはいけません。 パーナはPaCのIPアドレス構成に使用されるプロトコルかメカニズムにおける少しの仮定もしてはいけません。
4.7. Performance
4.7. パフォーマンス
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.
パーナデザインSHOULDは、最小の潜在でネットワークアクセスを得るために効率的に認証過程を扱います。 例えば、それは、地方のセキュリティ協会を創設することによって、プロトコルシグナリングを最小にするかもしれません。
4.8. Congestion Control
4.8. 輻輳制御
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.
パーナはプロトコルメッセージングのための輻輳制御を提供しなければなりません。 PAA(例えば、アクセスネットワークで電力供給停止から回復するときの)に彼らの要求を送るとき、一定の条件の下でPaCsは何気なく連動するかもしれません。 遅れた初期化と指数の後部のようにオフなテクニックを使用することによって、そのようなイベントから生成されたネットワークの混雑は避けることができます。
4.9. IP Version Independence
4.9. IPバージョン独立
PANA MUST work with both IPv4 and IPv6.
パーナはIPv4とIPv6の両方で働かなければなりません。
4.10. Denial of Service Attacks
4.10. サービス不能攻撃
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.
パーナはIPスプーフィングによる盲目の仮面舞踏会攻撃などのDoS攻撃のクラスに対して強健であるに違いありません。 正統のクライアントでリソースを費やして、ネットワークアクセスを防ぐことを引き起こして、これらの攻撃はPAAを浸すでしょう。
4.11. Client Identity Privacy
4.11. クライアントアイデンティティプライバシー
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
何人かのクライアントが、プライバシー理由で訪問されたアクセスネットワークから彼らのアイデンティティを隠すのを好むかもしれません。 パーナの範囲の外にアイデンティティ保護をクライアントに提供するのがあります。 それにいくつか注意してください、認証
Yegin, et al. Informational [Page 10] RFC 4058 PANA Requirements May 2005
Yegin、他 [10ページ]情報のRFC4058パーナ要件2005年5月
methods may already have this capability. Where necessary, identity protection can be achieved by letting PANA carry such authentication methods.
メソッドには、この能力が既にあるかもしれません。 必要であるところに、パーナにそのような認証方法を運ばせることによって、アイデンティティ保護を達成できます。
5. Security Considerations
5. セキュリティ問題
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.
このドキュメントはパーナプロトコルデザインのための要件を特定します。 このプロトコルの本質のために、要件の大部分は関係づけられたセキュリティです。 実際のプロトコルデザインは本書では指定されません。 パーナThreat AnalysisとSecurity Requirements[RFC4016]でパーナの軍事的脅威の徹底的な議論を見つけることができます。 そのドキュメントで特定された軍事的脅威はこの一般的なパーナ要件ドキュメントに既に含まれています。
6. Acknowledgements
6. 承認
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ソリマン、およびパーナ作業部会のメンバーに感謝したがっています。
Yegin, et al. Informational [Page 11] RFC 4058 PANA Requirements May 2005
Yegin、他 [11ページ]情報のRFC4058パーナ要件2005年5月
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)のための別々の認証など これらの需要を満たすことができるリンクレイヤ認証機構がないとき、故意に意図しなかった方法で、リンクの上の層で標準的でないその場かぎりの解決を使用するか、認証のために追加詰め物の層を挿入するか、またはオペレータはやむを得ず既存のプロトコルのいくつかを誤用します。 パーナは、標準のネットワーク層アクセス認証プロトコルを定義することによってこの不足をいっぱいにするために開発されるでしょう。 ネットワーク層アクセス認証プロトコルとして、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ネットワークはパーナが展開シナリオのいくつかを扱う可能性を持っている特定の例です。 または、いくつかのDSL展開がアクセスリンクレイヤとしてPPP[RFC1661]を使用しない、(IPがATMの上まで運ばれて、加入者デバイスが静的にどちらか、構成されたDHCP) これらのネットワークのオペレータは加入者認証に応用層のウェブベースのログイン(とりこになっている入り口)体系を使用するか、または単に差別化されたサービスに必要である加入者認証を実行できないようにベストエフォート型サービスを提供しているままにされます。 とりこになっている入り口の体系は様々な制限とセキュリティー・フローがある標準的でないソリューションです。
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を使用するのは、良い選択ではありません、接続設定と1パケットあたりの付加的な処理の間追加メッセージングを被るとき。 また、それは二地点間モデルにネットワーク形態を強制します。 それは絶対に必要でない場合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合図にもかかわらないときさえ、外国人のエージェントがRegistration Required旗で認証を強制できる、(共同見つけられている、注意、-、アドレスケース) これは移動性特有のプロトコルの関係ない機能性の使用を可能にします。
Yegin, et al. Informational [Page 12] RFC 4058 PANA Requirements May 2005
Yegin、他 [12ページ]情報のRFC4058パーナ要件2005年5月
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.
パーナは、どんなリンクレイヤのどんな認証方法も可能にするためにIPの上までEAPを運ぶでしょう。 [IEEE802.1X]とPPPは既にEAPを運ぶことができます。 unbridged IEEE802リンクの上にIEEE 802.1Xを使用できるだけです、したがって、それは限られたリンク型に適用されるだけです。 その特定のリンクレイヤの上でEAPを有効にする方法として知覚できますが、この理由にPPPを使用することでIPとリンクレイヤの間にPPPを挿入するのは、前述の欠点を持って、良い選択ではありません。 IEEE 802.1XとPPPが、それら自身のドメインで使用され続けることができる間、それらはパーナのようなプロトコルを持つ必要性を持ち去りません。
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:
パーナは様々なタイプのネットワークに適切になるでしょう。 実行しているパーナの前の下層セキュリティの存在に基づいて、以下のタイプはすべての可能性をカバーしています:
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.
b) IPを可能にする前に、L1-L2が暗号で初霜であるネットワークは(例えば、cdma2000ネットワーク)を機密保護しました。 暗号を可能にする前にクライアントがラジオリンクの上で認証されますが、それは、さらに、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を可能にする前に現在の下層セキュリティがありません。 パーナは不安定なネットワークに立候補することです。 パーナベースのアクセス認証は、1パケットあたりの暗号の認証と保全保護を独力で進むのに使用されます。
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.
パーナは単に完全な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.
パーナがリンクレイヤ手順からデカップリングAAAを可能にするので、ネットワークアクセス認証はリンク設立の間、行われる必要はありません。 これで、クライアントが、いくつかの展開における差別化されたサービス(例えば、高帯域、無制限なアクセスなど)にアクセスするのを試みるまで、クライアント認証を延期します。 また、さらに、同じリンクレイヤ接続の上の複数の同時のネットワークアクセスセッションが起こることができます。
Yegin, et al. Informational [Page 13] RFC 4058 PANA Requirements May 2005
Yegin、他 [13ページ]情報のRFC4058パーナ要件2005年5月
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つのシナリオが、パーナClient(PaC)やパーナAuthenticationなどの論理要素のプレースメントに関した異なったネットワークアーキテクチャのパーナ用法モデルがEnforcement Pointに関するエージェント(PAA)(EP)とAccess Router(AR)であるとキャプチャします。 PAAがネットワークアクセサリーを認可するためにPaCの資格証明書について確かめるのにAAAインフラストラクチャを使用するかもしれないことに注意してください。
Scenario 1: PAA co-located with EP but separated from AR
シナリオ1: EPと共に共同見つけられていますが、ARと切り離されたPAA
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--+
PaC-----EP/PAA--+| +------ アルゴン----- (AAA) | PaC-----EP/PAA--+
Figure 1: PAA co-located with EP but separated from AR.
図1: EPと共に共同場所を見つけましたが、PAAはARから分離しました。
Scenario 2: PAA co-located with AR but separated from EP
シナリオ2: ARと共に共同見つけられていますが、EPと切り離されたPAA
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に置かれます。 私たちはここに1ARだけを示しましたが、複数のARsがあるかもしれません。その1つはPAAと共に共同見つけられています。 アクセス管理パラメータは、PaCが認証される対応するデバイスがネットワークにアクセスできるように、それぞれの実施ポイントに分配されなければなりません。 別々のプロトコルが、アクセス管理パラメータを運ぶのにPAAとEPの間で必要です。
PaC ----- EP --+
|
+------ AR/PAA --- (AAA)
|
PaC ----- EP --+
PaC----- EP--+| +------ アルゴン/PAA--- (AAA) | PaC----- EP--+
Figure 2: PAA co-located with AR but separated from EP
図2: ARと共に共同見つけられていますが、EPと切り離されたPAA
Yegin, et al. Informational [Page 14] RFC 4058 PANA Requirements May 2005
Yegin、他 [14ページ]情報のRFC4058パーナ要件2005年5月
Scenario 3: PAA co-located with EP and AR
シナリオ3: EPとARと共に共同見つけられたPAA
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--+
PaC----- EP/PAA/アルゴン--+| +-------(AAA) | PaC----- EP/PAA/アルゴン--+
Figure 3: PAA co-located with EP and AR.
図3: EPとARと共に共同見つけられたPAA。
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はEPsとARsと共にどちらも共同位置していません。 それはARsと同じIPリンクの上にまだ住んでいます。 うまくいっている認証の後に、アクセス管理パラメータは別々のプロトコルでそれぞれの実施ポイントに分配されるでしょう、そして、パーナはこれにおけるどんな明白な役割も果たしません。
PaC ----- EP -----+--- AR ---+
| |
PaC ----- EP --- -+ |
| |
PaC ----- EP -----+--- AR -- + ----(AAA)
|
+--- PAA
PaC----- EP-----+--- アルゴン---+ | | PaC----- EP--- -+ | | | PaC----- EP-----+--- アルゴン--+----(AAA) | +--- PAA
Figure 4: PAA, EP and AR separated.
図4: PAA、EP、およびARは分離しました。
Scenario 5: PAA separated from co-located EP and AR
シナリオ5: 共同見つけられたEPとARと切り離されたPAA
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はARsと同じIPリンクの上にまだ住んでいます。 うまくいっている認証の後に、アクセス管理パラメータは別々のプロトコルでそれぞれの実施ポイントに分配されるでしょう、そして、パーナはこれにおけるどんな明白な役割も果たしません。
PaC --------------+--- AR/EP ---+
| |
PaC --------------+ |
| |
PaC --------------+--- AR/EP -- + ----(AAA)
|
+--- PAA
PaC--------------+--- アルゴン/EP---+ | | PaC--------------+ | | | PaC--------------+--- アルゴン/EP--+----(AAA) | +--- PAA
Figure 5: PAA separated from EP and AR.
図5: PAAはEPとARから分離しました。
Yegin, et al. Informational [Page 15] RFC 4058 PANA Requirements May 2005
Yegin、他 [15ページ]情報のRFC4058パーナ要件2005年5月
References
参照
Normative References
引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[RFC4016] Parthasarathy, M., "Protocol for Carrying
Authentication and Network Access (PANA) Threat
Analysis and Security Requirements", RFC 4016, March
2005.
パルタサラティ、M.が「認証とネットワークアクセス(パーナ)脅威分析とセキュリティ要件を運ぶために議定書の中で述べる」[RFC4016]、RFC4016、2005年3月。
Informative References
有益な参照
[FMIPv4] Malki, K., "Low Latency Handoffs in Mobile IPv4", Work in
Progress, June 2004.
[FMIPv4] Malki、K.、「モバイルIPv4"の低遅延Handoffs、処理中の作業、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.bitに扱う」STD37、RFC826、1982年11月。
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC
1256, September 1991.
[RFC1256] デアリング、S.、「ICMPルータ発見メッセージ」、RFC1256、1991年9月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
Yegin, et al. Informational [Page 16] RFC 4058 PANA Requirements May 2005
Yegin、他 [16ページ]情報のRFC4058パーナ要件2005年5月
[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)のための隣人発見」、RFC2461、1998年12月。
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[RFC2716] AbobaとB.とD.サイモン、「ppp EAP TLS認証プロトコル」、RFC2716、1999年10月。
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2794] カルフーンとP.とC.パーキンス、「IPv4"、RFC2794、2000年3月のためのモバイルIPネットワークアクセス識別子拡張子。」
[RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/
Response Extensions", RFC 3012, November 2000.
[RFC3012] パーキンスとC.とP.カルフーン、「モバイルIPv4挑戦/応答拡大」、RFC3012、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"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3344] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、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
三星高度先端技術研究所75の西Plumeria Drive Alper E.Yegin(エディタ)カリフォルニア95134サンノゼ(米国)
Phone: +1 408 544 5656 EMail: alper.yegin@samsung.com
以下に電話をしてください。 +1 5656年の408 544メール: alper.yegin@samsung.com
Yegin, et al. Informational [Page 17] RFC 4058 PANA Requirements May 2005
Yegin、他 [17ページ]情報のRFC4058パーナ要件2005年5月
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA
芳広オオバ東芝アメリカ研究Inc.1Telcordia Driveニュージャージー08854ピスキャタウェイ(米国)
Phone: +1 732 699 5305 EMail: yohba@tari.toshiba.com
以下に電話をしてください。 +1 5305年の732 699メール: yohba@tari.toshiba.com
Reinaldo Penno Juniper Networks 10 Technology Park Drive Westford, MA 01886-3146 USA
レイナルドペンノ杜松ネットワーク10技術公園Drive MA01886-3146ウェストフォード(米国)
EMail: rpenno@juniper.net
メール: rpenno@juniper.net
George Tsirtsis Flarion Bedminster One 135 Route 202/206 South Bedminster, NJ 07921 USA
ルート202/206の南Bedminster、ジョージTsirtsis Flarion Bedminster One 135ニュージャージー07921米国
Phone: +44 20 88260073 EMail: G.Tsirtsis@Flarion.com
以下に電話をしてください。 +44 20 88260073はメールされます: G.Tsirtsis@Flarion.com
Cliff Wang ARO/NCSU 316 Riggsbee Farm Morrisville, NC 27560 USA
Riggsbee農場Morrisville、クリフワングARO/NCSU316NC27560米国
Phone: +1 919 548 4207 EMail: cliffwangmail@yahoo.com
以下に電話をしてください。 +1 4207年の919 548メール: cliffwangmail@yahoo.com
Yegin, et al. Informational [Page 18] RFC 4058 PANA Requirements May 2005
Yegin、他 [18ページ]情報のRFC4058パーナ要件2005年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Yegin, et al. Informational [Page 19]
Yegin、他 情報[19ページ]
一覧
スポンサーリンク
