RFC5193 日本語訳
5193 Protocol for Carrying Authentication for Network Access (PANA)Framework. P. Jayaraman, R. Lopez, Y. Ohba, Ed., M. Parthasarathy, A.Yegin. May 2008. (Format: TXT=24474 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Jayaraman
Request for Comments: 5193 Net.Com
Category: Informational R. Lopez
Univ. of Murcia
Y. Ohba, Ed.
Toshiba
M. Parthasarathy
Nokia
A. Yegin
Samsung
May 2008
Jayaramanがコメントのために要求するワーキンググループP.をネットワークでつないでください: 5193年のNet.Comカテゴリ: エドムルシアY.オオバの情報のR.ロペス大学、東芝M.パルタサラティノキアA.Yegin三星2008年5月
Protocol for Carrying Authentication for Network Access (PANA) Framework
ネットワークアクセス(パーナ)フレームワークのための認証を運ぶためのプロトコル
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document defines the general Protocol for Carrying Authentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments.
このドキュメントはNetwork Access(パーナ)フレームワーク機能要素、ハイレベルの呼び出し流動、および展開環境のためにCarrying Authenticationのために一般的なプロトコルを定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. General PANA Framework ..........................................2
3. Call Flow .......................................................5
4. Environments ....................................................6
5. Security Considerations .........................................8
6. Acknowledgments .................................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................9
1. 序論…2 1.1. 要件の仕様…2 2. 一般パーナフレームワーク…2 3. 流れに電話をしてください…5 4. 環境…6 5. セキュリティ問題…8 6. 承認…8 7. 参照…8 7.1. 標準の参照…8 7.2. 有益な参照…9
Jayaraman, et al. Informational [Page 1] RFC 5193 PANA Framework May 2008
Jayaraman、他 [1ページ]情報のRFC5193パーナフレームワーク2008年5月
1. Introduction
1. 序論
PANA (Protocol for carrying Authentication for Network Access) is a link-layer agnostic network access authentication protocol that runs between a client that wants to gain access to the network and a server on the network side. PANA defines a new Extensible Authentication Protocol (EAP) [RFC3748] lower layer that uses IP between the protocol end points.
パーナ(Network AccessのためにAuthenticationを運ぶためのプロトコル)はネットワーク側でネットワークへのアクセスを得たがっているクライアントとサーバの間で稼働するリンクレイヤ不可知論者ネットワークアクセス認証プロトコルです。 パーナはプロトコルエンドポイントの間でIPを使用する新しい拡張認証プロトコル(EAP)[RFC3748]の低級層を定義します。
The motivation to define such a protocol and the requirements are described in [RFC4058]. Protocol details are documented in [RFC5191]. Upon following a successful PANA authentication, per- data-packet security can be achieved by using physical security, link-layer ciphering, or IPsec [PANA-IPSEC]. The server implementation of PANA may or may not be colocated with the entity enforcing the per-packet access control function. When the server for PANA and per-packet access control entities are separate, a protocol (e.g., [ANCP-PROTO]) may be used to carry information between the two nodes.
そのようなプロトコルを定義する動機と要件は[RFC4058]で説明されます。 プロトコルの詳細は[RFC5191]に記録されます。 うまくいっているパーナの認証に続くことに関して-、物理的なセキュリティを使用するか、リンクレイヤ暗号、またはIPsec[パーナ-IPSEC]がデータ・パケットセキュリティを達成できます。 実体が1パケットあたりのアクセス制御機能を実施している状態で、パーナのサーバ実装はcolocatedされるかもしれません。 パーナへのサーバと1パケットあたりのアクセス制御実体が別々であるときに、プロトコル(例えば、[ANCP-プロト])は、2つのノードの間まで情報を運ぶのに使用されるかもしれません。
PANA is intended to be used in any access network regardless of the underlying security. For example, the network might be physically secured, or secured by means of cryptographic mechanisms after the successful client-network authentication. While it is mandatory for a PANA deployment to implement behavior that ensures the integrity of PANA messages when the EAP method produces MSK, it is not mandatory to implement support for network security at the link-layer or network-layer.
基本的なセキュリティにかかわらずどんなアクセスネットワークにもパーナが使用されることを意図します。 例えば、うまくいっているクライアントネットワーク認証の後の暗号のメカニズムによってネットワークを物理的に保証するか、または保証するかもしれません。 パーナの展開がEAPメソッドがMSKを生産するときパーナメッセージの保全を確実にする振舞いを実装するのが、義務的ですが、リンクレイヤかネットワーク層におけるネットワークセキュリティのサポートを実装するのは義務的ではありません。
This document defines the general framework for describing how these various PANA and other network access authentication elements interact with each other, especially considering the two basic types of deployment environments (see Section 4).
このドキュメントはこれらの様々なパーナの、そして、他のネットワークアクセス認証要素がどう対話するかを互いに説明するために一般的なフレームワークを定義します、2人の基本型の展開環境を特に考える場合(セクション4を見てください)。
1.1. Specification of Requirements
1.1. 要件の仕様
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. General PANA Framework
2. 一般パーナフレームワーク
PANA is designed to facilitate the authentication and authorization of clients in access networks. PANA is an EAP [RFC3748] lower layer that carries EAP authentication methods encapsulated inside EAP between a client node and a server in the access network. While PANA
パーナは、アクセスネットワークでクライアントの認証と承認を容易にするように設計されています。 パーナはクライアントノードとアクセスネットワークにおけるサーバの間までEAPの中でカプセル化されたEAP認証方法を運ぶEAP[RFC3748]の低級層です。 パーナをゆったり過ごしてください。
Jayaraman, et al. Informational [Page 2] RFC 5193 PANA Framework May 2008
Jayaraman、他 [2ページ]情報のRFC5193パーナフレームワーク2008年5月
enables the authentication process between the two entities, it is only a part of an overall AAA (Authentication, Authorization and Accounting) and access control framework. A AAA and access control framework using PANA is comprised of four functional entities.
可能にする、2つの実体の間の認証過程であり、唯一のそれは総合的なAAA(認証、Authorization、およびAccounting)とアクセス制御フレームワークの一部です。 AAAとアクセス制御フレームワーク使用パーナは4つの機能的な実体から成ります。
Figure 1 illustrates these functional entities and the interfaces (protocols, APIs) among them.
図1はそれらの中でこれらの機能的な実体とインタフェース(プロトコル、API)を例証します。
RADIUS,
Diameter,
+-----+ PANA +-----+ LDAP, API, etc. +-----+
| PaC |<----------------->| PAA |<------------------->| AS |
+-----+ +-----+ +-----+
^ ^
| |
| +-----+ |
IKE, +-------->| EP |<--------+ ANCP, API, etc.
4-way handshake, +-----+
etc. .
.
.
v
Data traffic
半径、直径、+-----+ パーナ+-----+ LDAP、APIなど +-----+ | PaC| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| PAA| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| as| +-----+ +-----+ +-----+ ^ ^ | | | +-----+ | イケ、+-------->| EP| <、-、-、-、-、-、-、--+ ANCP、APIなど 4ウェイ握手、+-----+ など . . . Dataトラフィックに対して
Figure 1: PANA Functional Model
図1: パーナの機能論的モデル
PANA Client (PaC):
パーナクライアント(PaC):
The PaC is the client implementation of PANA. This entity resides
on the node that is requesting network access. PaCs can be end
hosts, such as laptops, PDAs, cell phones, desktop PCs, or routers
that are connected to a network via a wired or wireless interface.
A PaC is responsible for requesting network access and engaging in
the authentication process using PANA.
PaCはパーナのクライアント実装です。 この実体はネットワークアクセサリーを要求しているノードの上にあります。 PaCsは終わりのホストであるかもしれません、ワイヤードであるかワイヤレスのインタフェースを通してネットワークに接続されるラップトップ、PDA、携帯電話、デスクトップパソコン、またはルータなどのように。 PaCはパーナを使用することで、ネットワークアクセスを要求して、認証過程に従事しているのに責任があります。
PANA Authentication Agent (PAA):
パーナ認証エージェント(PAA):
The PAA is the server implementation of PANA. A PAA is in charge
of interfacing with the PaCs for authenticating and authorizing
them for the network access service.
PAAはパーナのサーバ実装です。 ネットワークアクセス・サービスのために彼らを認証して、認可するためにPaCsに連結することを担当してPAAがあります。
The PAA consults an authentication server in order to verify the
credentials and rights of a PaC. If the authentication server
resides on the same node as the PAA, an API is sufficient for this
interaction. When they are separated (a much more common case in
public access networks), a protocol needs to run between the two.
AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are
commonly used for this purpose.
PAAは、PaCの資格証明書と権利について確かめるために認証サーバに相談します。 認証サーバがPAAと同じノードの上にあるなら、APIはこの相互作用に十分です。 それらが切り離されるとき(パブリックアクセスネットワークのはるかに一般的なケース)、プロトコルは、2つの間で稼働する必要があります。 RADIUS[RFC2865]とDiameter[RFC3588]のようなAAAプロトコルは一般的にこのために使用されます。
Jayaraman, et al. Informational [Page 3] RFC 5193 PANA Framework May 2008
Jayaraman、他 [3ページ]情報のRFC5193パーナフレームワーク2008年5月
The PAA is also responsible for updating the access control state
(i.e., filters) depending on the creation and deletion of the
authorization state. The PAA communicates the updated state to
the Enforcement Points (EPs) in the network. If the PAA and EP
are residing on the same node, an API is sufficient for this
communication. Otherwise, a protocol is required to carry the
authorized client attributes from the PAA to the EP.
また、PAAも承認状態の作成と削除によって、アクセス制御状態(すなわち、フィルタ)をアップデートするのに責任があります。 PAAはネットワークでEnforcement Points(EPs)にアップデートされた状態を伝えます。 PAAとEPが同じノードの上に住んでいるなら、APIはこのコミュニケーションに十分です。 さもなければ、プロトコルが、PAAからEPまで認可されたクライアント属性を運ぶのに必要です。
The PAA resides on a node that is typically called a NAS (network
access server) in the access network. For example, on a BRAS
(Broadband Remote Access Server) [DSL] in DSL networks, or PDSN
(Packet Data Serving Node) [3GPP2] in 3GPP2 networks. The PAA may
be one or more IP hops away from the PaCs.
PAAはアクセスネットワークで通常NAS(ネットワークアクセス・サーバー)と呼ばれるノードの上に住んでいます。 例えばDSLネットワークにおけるBRAS(ブロードバンドRemote Access Server)[DSL]、または3GPP2ネットワークにおけるPDSN(パケットData Serving Node)[3GPP2]で。 PAAはPaCsから遠くの1つ以上のIPホップであるかもしれません。
Authentication Server (AS):
認証サーバ(AS):
The server implementation that is in charge of verifying the
credentials of a PaC that is requesting the network access
service. The AS receives requests from the PAA on behalf of the
PaCs, and responds with the result of verification together with
the authorization parameters (e.g., allowed bandwidth, IP
configuration, etc). This is the server that terminates the EAP
and the EAP methods. The AS might be hosted on the same node as
the PAA, on a dedicated node on the access network, or on a
central server somewhere in the Internet.
ネットワークアクセス・サービスを要求しているPaCの資格証明書について確かめることを担当してあるサーバ実装。 ASはPaCsを代表してPAAから要求を受け取って、承認パラメタと共に検証の結果で応じます(例えば、帯域幅、IP構成などを許します)。 これは、EAPを終えるサーバとEAPメソッドです。 ASはPAAと同じノードの上で接待されるかもしれません、インターネットのどこかのアクセスネットワークの上、または、セントラルサーバーの上の専用ノードの上で。
Enforcement Point (EP):
実施ポイント(EP):
The access control implementation that is in charge of allowing
access (data traffic) of authorized clients while preventing
access by others. An EP learns the attributes of the authorized
clients from the PAA.
他のものによるアクセスを防いでいる間、認可されたクライアントのアクセス(データ通信量)を許すことを担当してあるアクセス制御実装。 EPはPAAから認可されたクライアントの属性を学びます。
The EP uses non-cryptographic or cryptographic filters to
selectively allow and discard data packets. These filters may be
applied at the link layer or the IP layer [PANA-IPSEC]. When
cryptographic access control is used, a secure association
protocol [RFC3748] needs to run between the PaC and EP. After
completion of the secure association protocol, link- or network-
layer per-packet security (for example TKIP, IPsec ESP) is enabled
for integrity protection, data origin authentication, replay
protection, and optionally confidentiality protection.
EPは、選択的にデータ・パケットを許容して、捨てるのに非暗号の、または、暗号のフィルタを使用します。 これらのフィルタはリンクレイヤかIP層[パーナ-IPSEC]に適用されるかもしれません。 暗号のアクセスコントロールが使用されているとき、安全な協会プロトコル[RFC3748]は、PaCとEPの間で稼働する必要があります。 保全保護、データ発生源認証のために可能にされます、任意に保護を再演してください。安全な協会プロトコルの完成の後に1パケットあたりの層のセキュリティをリンクするか、またはネットワークでつないでください、(例えば、TKIP、IPsec、超能力)、秘密性保護。
An EP is located between the access network (the topology within
reach of any client) and the accessed network (the topology within
reach of only authorized clients). It must be located
strategically in a local area network to minimize the access of
unauthorized clients. It is recommended but not mandated that the
EPはアクセスネットワーク(どんなクライアントの範囲の中のトポロジー)とアクセスされたネットワーク(認可されたクライアントだけの範囲の中のトポロジー)の間に位置しています。 それは、権限のないクライアントのアクセスを最小にするためにローカル・エリア・ネットワークで戦略上位置しなければなりません。 それは、お勧めですが、それを強制しませんでした。
Jayaraman, et al. Informational [Page 4] RFC 5193 PANA Framework May 2008
Jayaraman、他 [4ページ]情報のRFC5193パーナフレームワーク2008年5月
EP be on the path between the PaC and the PAA for the
aforementioned reason. For example, the EP can be hosted on the
switch that is directly connected to the clients in a wired
network. That way the EP can drop unauthorized packets before
they reach any other client node or nodes beyond the local area
network.
経路でEPはそうです。前述の理由によるPaCとPAAの間で。 例えば、有線ネットワークで直接クライアントに接続されるスイッチの上にEPを接待できます。 そのように、ローカル・エリア・ネットワークを超えていかなる他のクライアントノードかノードにも達する前にEPは権限のないパケットを下げることができます。
Some of the entities may be colocated depending on the deployment scenario. For example, the PAA and EP would be on the same node (BRAS) in DSL networks. In that case, a simple API is sufficient between the PAA and EP. In small enterprise deployments, the PAA and AS may be hosted on the same node (access router) that eliminates the need for a protocol run between the two. The decision to colocate these entities or otherwise, and their precise location in the network topology, are deployment decisions that are out of the scope of this document.
展開シナリオによって、実体のいくつかがcolocatedされるかもしれません。 例えば、DSLネットワークにおける同じノード(BRAS)の上にPAAとEPがあるでしょう。 その場合、簡単なAPIはPAAとEPの間で十分です。 小企業展開では、PAAとASは2つの間で実行されたプロトコルの必要性を排除するのと同じノード(アクセスルータ)の上で接待されるかもしれません。 そうでなければこれらの実体をcolocateするという決定、およびネットワーク形態のそれらの正確な位置はこのドキュメントの範囲の外にある展開決定です。
3. Call Flow
3. 流れに電話をしてください。
Figure 2 illustrates the signaling flow for authorizing a client for network access.
図2は、ネットワークアクセサリーのためにクライアントに権限を与えるためにシグナリング流動を例証します。
PaC EP PAA AS
| | | |
IP address ->| | | |
config. | PANA | | AAA |
|<------------------------------>|<-------------->|
| | Provisioning | |
(Optional) | |<-------------->| |
IP address ->| | | |
reconfig. | Sec.Assoc. | | |
|<------------->| | |
| | | |
| Data traffic | | |
|<-----------------> | |
| | | |
PaC EP PAA| | | | IPアドレス、->|、|、|、| コンフィグ。| パーナ| | AAA| |<------------------------------>|<-------------->| | | 食糧を供給すること| | (任意)です。 | | <、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| IPアドレス、->|、|、|、| 「再-コンフィグ」。| 秒のAssoc。 | | | | <、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、| データ通信量| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|
Figure 2: PANA Signaling Flow
図2: パーナのシグナリング流動
The EP on the access network allows general data traffic from any authorized PaC, whereas it allows only a limited type of traffic (e.g., PANA, DHCP, router discovery, etc.) for the unauthorized PaCs. This ensures that the newly attached clients have the minimum access service to engage in PANA and get authorized for the unlimited service.
アクセスネットワークのEPはどんな認可されたPaCからも一般データトラフィックを許容しますが、それは権限のないPaCsのための限られたタイプのトラフィック(例えば、パーナ、DHCP、ルータ発見など)だけを許容します。 これは、パーナに従事して、無制限なサービスのために認可させるために新たに添付のクライアントには最低輸入義務サービスがあるのを確実にします。
The PaC dynamically or statically configures an IP address prior to running PANA. After the successful PANA authentication, depending on
PaCは実行しているパーナの前にダイナミックか静的にIPアドレスを構成します。 うまくいっているパーナの認証、依存の後にオンです。
Jayaraman, et al. Informational [Page 5] RFC 5193 PANA Framework May 2008
Jayaraman、他 [5ページ]情報のRFC5193パーナフレームワーク2008年5月
the deployment scenario, the PaC may need to re-configure its IP address or configure additional IP address(es). For example, a link-local IPv6 address may be used for PANA and the PaC may be allowed to configure additional global IPv6 address(es) upon successful authentication. Another example: A PaC may be limited to using an IPv4 link-local address during PANA, and allowed to reconfigure its interface with a non-link-local IPv4 address after the authentication. General-purpose applications cannot use the interface until PANA authentication succeeds and appropriate IP address configuration takes place.
展開シナリオであり、PaCは、IPアドレスを再構成するか、または追加IPアドレス(es)を構成する必要があるかもしれません。 例えば、リンクローカルのIPv6アドレスはパーナに使用されるかもしれません、そして、PaCはうまくいっている認証のときに追加グローバルなIPv6アドレス(es)を構成できるかもしれません。 別の例: PaCはパーナの間、IPv4リンクローカルアドレスを使用するのに制限されて、認証の後に非リンクのローカルIPv4アドレスとのインタフェースを再構成できるかもしれません。 パーナの認証が成功して、適切なIPアドレス構成が行われるまで、汎用アプリケーションはインタフェースを使用できません。
An initially unauthorized PaC starts PANA authentication by discovering the PAA, followed by the EAP exchange over PANA. The PAA interacts with the AS during this process. Upon receiving the authentication and authorization result from the AS, the PAA informs the PaC about the result of its network access request.
初めは権限のないPaCは、EAP交換がパーナの上であとに続いたPAAを発見することによって、パーナの認証を始めます。 PAAはこのプロセスの間、ASと対話します。 ASから認証と承認結果を受けると、PAAはネットワークアクセス要求の結果に関してPaCに知らせます。
If the PaC is authorized to gain access to the network, the PAA also sends the PaC-specific attributes (e.g., IP address, cryptographic keys, etc.) to the EP by using another protocol. The EP uses this information to alter its filters to allow data traffic from and to the PaC to pass through.
また、PaCがネットワークへのアクセスを得るのが認可されるなら、PAAは、別のプロトコルを使用することによって、PaC特有の属性(例えば、IPアドレス、暗号化キーなど)をEPに送ります。 EPは、PaCとPaCへのデータ通信量が通り抜けるのを許容するフィルタを変更するのにこの情報を使用します。
In case cryptographic access control needs to be enabled after PANA authentication, a secure association protocol runs between the PaC and the EP. Dynamic parameters required for that protocol (e.g., endpoint identity, shared secret) are derived from successful PANA authentication; these parameters are used to authenticate the PaC to the EP and vice-versa as part of creating the security association. For example, see [PANA-IPSEC] for how it is done for IKE [RFC2409] [RFC4306] based on using a key-generating EAP method for PANA between the PaC and PAA. The secure association protocol exchange produces the required security associations between the PaC and the EP to enable cryptographic data traffic protection. Per-packet cryptographic data traffic protection introduces additional per- packet overhead but the overhead exists only between the PaC and EP and will not affect communications beyond the EP.
暗号のアクセスコントロールが、パーナの認証の後に可能にされる必要があるといけないので、安全な協会プロトコルはPaCとEPの間で稼働しています。 うまくいっているパーナの認証からそのプロトコル(例えば、終点のアイデンティティ、共有秘密キー)に必要である動的パラメータを得ます。 これらのパラメタはEPにPaCを認証するのに使用されます、そして、セキュリティ協会を創設する一部として逆もまた同様です。 例えば、パーナにPaCとPAAの間でキーを生成するEAPメソッドを使用することに基づいてIKE[RFC2409][RFC4306]のためにどうそれをするかために[パーナ-IPSEC]を見てください。 安全な協会プロトコル交換は、暗号のデータ通信量保護を可能にするためにPaCとEPとの必要なセキュリティ協会を生産します。 1パケットあたりの暗号のデータ通信量保護が導入する、追加、-、パケットオーバーヘッドにもかかわらず、オーバーヘッドは、PaCとEPだけの間に存在していて、EPを超えてコミュニケーションに影響しないでしょう。
Finally, filters that are installed at the EP allow general purpose data traffic to flow between the PaC and the intranet/Internet.
最終的に、EPにインストールされるフィルタで、汎用のデータ通信量はPaCとイントラネット/インターネットの間を流れます。
4. Environments
4. 環境
PANA can be used on any network environment whether there is a lower-layer secure channel between the PaC and the EP prior to PANA, or one has to be enabled upon successful PANA authentication.
パーナの前に、PaCとEPの間には、下層の安全なチャンネルがあるか否かに関係なく、どんなネットワーク環境でもパーナを使用できますか、または1つはうまくいっているパーナの認証のときに可能にされなければなりません。
Jayaraman, et al. Informational [Page 6] RFC 5193 PANA Framework May 2008
Jayaraman、他 [6ページ]情報のRFC5193パーナフレームワーク2008年5月
With regard to network access authentication, two types of networks need to be considered:
ネットワークアクセス認証に関して、2つのタイプのネットワークは、考えられる必要があります:
a. Networks where a secure channel is already available prior to
running PANA
a。 安全なチャンネルが実行しているパーナの前に既に利用可能であるネットワーク
This type of network is characterized by the existence of
protection against spoofing and eavesdropping. Nevertheless, user
authentication and authorization is required for network
connectivity.
このタイプのネットワークはスプーフィングと盗聴に対する保護の存在によって特徴付けられます。 それにもかかわらず、ユーザー認証と承認がネットワークの接続性に必要です。
a.1. One example is a DSL network where lower-layer security is
provided by a physical means. Physical protection of the
network wiring ensures that practically there is only one
client that can send and receive IP packets on the link.
a.1。 1つの例が下層セキュリティが物理的な手段で提供されるDSLネットワークです。 ネットワーク配線の物理的防護は、リンクの上にIPパケットを送って、受けることができる1人のクライアントしか実際にいないのを確実にします。
a.2. Another example is a cdma2000 network where the lower-layer
security is provided by means of cryptographic protection.
By the time the client requests access to the network-layer
services, it is already authenticated and authorized for
accessing the radio channel, and link-layer ciphering is
enabled.
a.2。 別の例は下層セキュリティが暗号の保護によって提供されるcdma2000ネットワークです。 クライアントがネットワーク層サービスへのアクセスを要求する時までには、それは、ラジオチャンネルにアクセスするために既に認証されて、認可されます、そして、リンクレイヤ暗号は可能にされます。
The presence of a secure channel before the PANA exchange
eliminates the need for executing a secure association protocol
after PANA. The PANA session can be associated with the
communication channel it was carried over. Also, the choice of
EAP authentication method depends on the presence of this security
while PANA is running.
パーナの交換の前の安全なチャンネルの存在はパーナの後に安全な協会プロトコルを実行する必要性を排除します。 それが及んだ通信チャネルであったのにパーナのセッションを関連づけることができます。また、パーナが稼働している間、EAP認証方法のこの選択はこのセキュリティの存在次第です。
b. Networks where a secure channel is created after running PANA
b。 パーナを実行した後に安全なチャンネルが創造されるネットワーク
These are the networks where there is no lower-layer protection
prior to running PANA. Successful PANA authentication enables the
generation of cryptographic keys that are used with a secure
association protocol to enable per-packet cryptographic
protection.
これらは実行しているパーナの前に、下層保護が全くないネットワークです。 うまくいっているパーナの認証は、安全な協会プロトコルと共に使用される暗号化キーの世代が1パケットあたりの暗号の保護を可能にするのを可能にします。
PANA authentication is run on an insecure channel that is
vulnerable to eavesdropping and spoofing. The choice of EAP
method must be resilient to the possible attacks associated with
such an environment. Furthermore, the EAP method must be able to
create cryptographic keys that will later be used by the secure
association protocol.
パーナの認証は、盗聴に被害を受け易い不安定なチャンネルに実行されて、だまされています。 EAPメソッドの選択はそのような環境に関連している可能な攻撃に立ち直りが早いに違いありません。 その上、EAPメソッドは後で安全な協会プロトコルによって使用される暗号化キーを作成できなければなりません。
Jayaraman, et al. Informational [Page 7] RFC 5193 PANA Framework May 2008
Jayaraman、他 [7ページ]情報のRFC5193パーナフレームワーク2008年5月
Whether to use
使用に
b.1. link-layer per-packet security or
またはb.1 1パケットあたりのリンクレイヤセキュリティ。
b.2. network-layer per-packet security
b.2 1パケットあたりのネットワーク層セキュリティ
is a deployment decision and outside the scope of this document.
This decision also dictates the choice of the secure association
protocol. If link-layer protection is used, the protocol would be
link-layer specific. If IP-layer protection is used, the secure
association protocol would be IKE and the per-packet security
would be provided by IPsec AH/ESP regardless of the underlying
link-layer technology.
展開決定とこのドキュメントの範囲の外にあります。 また、この決定は安全な協会プロトコルの選択を決めます。 リンクレイヤ保護が使用されているなら、プロトコルはリンクレイヤ特有でしょう。 IP-層の保護が使用されているなら、安全な協会プロトコルはIKEでしょう、そして、IPsec AH/超能力は基本的なリンクレイヤ技術にかかわらず1パケットあたりのセキュリティを提供するでしょう。
5. Security Considerations
5. セキュリティ問題
Security is discussed throughout this document. For protocol- specific security considerations, refer to [RFC4016] and [RFC5191].
このドキュメント中でセキュリティについて議論します。 プロトコルの特定のセキュリティ問題について、[RFC4016]と[RFC5191]を参照してください。
6. Acknowledgments
6. 承認
We would like to thank Bernard Aboba, Yacine El Mghazli, Randy Turner, Hannes Tschofenig, Lionel Morand, Mark Townsley, Jari Arkko, Pekka Savola, Tom Yu, Joel Halpern, Lakshminath Dondeti, David Black, and IEEE 802.11 Working Group for their valuable comments.
彼らの貴重なコメントについてバーナードAboba、ヤシーヌEl Mghazli、ランディ・ターナー、ハンネスTschofenig、ライオネル・モラン、マークTownsley、ヤリArkko、ペッカSavola、トム・ユー、ジョエル・アルペルン、Lakshminath Dondeti、デヴィッドBlack、およびIEEE802.11作業部会に感謝申し上げます。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[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, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC3748] AbobaとB.とBlunkとL.とVollbrechtとJ.とカールソン、J.とH.Levkowetz、エド、「拡張認証プロトコル(EAP)」、RFC3748(2004年6月)
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[RFC4058] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and
C. Wang, "Protocol for Carrying Authentication for
Network Access (PANA) Requirements", RFC 4058, May 2005.
[RFC4058]Yegin、A.(エド)、オオバ、Y.、ペンノ、R.、Tsirtsis(G.、およびC.ワング)は「ネットワークアクセス(パーナ)要件のための認証を運ぶために議定書を作ります」、RFC4058、2005年5月。
Jayaraman, et al. Informational [Page 8] RFC 5193 PANA Framework May 2008
Jayaraman、他 [8ページ]情報のRFC5193パーナフレームワーク2008年5月
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, May 2008.
[RFC5191]フォルスバーグ、D.、オオバ、Y.(エド)、パティル、B.、Tschofenig(H.、およびA.Yegin)は「ネットワークアクセス(パーナ)のための認証を運ぶために議定書を作ります」、RFC5191、2008年5月。
[DSL] DSL Forum Architecture and Transport Working Group, "DSL
Forum TR-059 DSL Evolution - Architecture Requirements
for the Support of QoS-Enabled IP Services", September
2003.
[DSL] DSLフォーラムアーキテクチャと輸送作業部会、「DSLフォーラムTR-059 DSL発展--、QoSによって可能にされたIPサービスのサポートのためのアーキテクチャ要件、」、9月2003日
7.2. Informative References
7.2. 有益な参照
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[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月。
[ANCP-PROTO] Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., and
N. Voigt, "Protocol for Access Node Control Mechanism in
Broadband Networks", Work in Progress, November 2007.
[ANCP-プロト]Wadhwa(S.、Moisand、J.、Subramanian、S.、ハーグ、T.、およびN.フォークト)は「アクセスノード制御機構のために広帯域ネットワークで議定書を作ります」、処理中の作業、2007年11月。
[PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access
Control", Work in Progress, July 2005.
[パーナ-IPSEC] パルタサラティ、M.、「パーナEnabling IPsecはAccess Controlを基礎づけた」Progress、2005年7月のWork。
[3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless
IP Network Standard", 3GPP2 P.S0001-B/v2.0, September
2004.
[3GPP2]第3世代パートナーシッププロジェクト2、「cdma2000のワイヤレスのIPネットワーク規格」、3GPP2P.S0001-B/v2.0、2004年9月。
Jayaraman, et al. Informational [Page 9] RFC 5193 PANA Framework May 2008
Jayaraman、他 [9ページ]情報のRFC5193パーナフレームワーク2008年5月
Authors' Addresses
作者のアドレス
Prakash Jayaraman Network Equipment Technologies, Inc. 6900 Paseo Padre Parkway Fremont, CA 94555 USA
プラカシュJayaramanネットワーク装置Technologies Inc.6900Paseo神父Parkwayフレモント(カリフォルニア)94555米国
Phone: +1 510 574 2305 EMail: prakash_jayaraman@net.com
以下に電話をしてください。 +1 2305年の510 574メール: prakash_jayaraman@net.com
Rafa Marin Lopez University of Murcia 30100 Murcia Spain
Rafaマリン・ロペス・ムルシア大学30100ムルシアスペイン
Phone: +34 968 398 501 EMail: rafa@um.es
以下に電話をしてください。 +34 968 398 501はメールされます: rafa@um.es
Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA
TelcordiaドライブPiscateway、芳広オオバ東芝アメリカ研究Inc.1ニュージャージー08854米国
Phone: +1 732 699 5305 EMail: yohba@tari.toshiba.com
以下に電話をしてください。 +1 5305年の732 699メール: yohba@tari.toshiba.com
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
モハンパルタサラティノキア313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 408 734 8820 EMail: mohanp@sbcglobal.net
以下に電話をしてください。 +1 8820年の408 734メール: mohanp@sbcglobal.net
Alper E. Yegin Samsung Istanbul, Turkey
Alper E.Yegin三星イスタンブール(トルコ)
EMail: a.yegin@partner.samsung.com
メール: a.yegin@partner.samsung.com
Jayaraman, et al. Informational [Page 10] RFC 5193 PANA Framework May 2008
Jayaraman、他 [10ページ]情報のRFC5193パーナフレームワーク2008年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんな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に情報を扱ってください。
Jayaraman, et al. Informational [Page 11]
Jayaraman、他 情報[11ページ]
一覧
スポンサーリンク
