RFC4016 日本語訳
4016 Protocol for Carrying Authentication and Network Access (PANA)Threat Analysis and Security Requirements. M. Parthasarathy. March 2005. (Format: TXT=36104 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Parthasarathy Request for Comments: 4016 Nokia Category: Informational March 2005
コメントを求めるワーキンググループM.パルタサラティの要求をネットワークでつないでください: 4016年のノキアカテゴリ: 情報の2005年3月
Protocol for Carrying Authentication and Network Access (PANA)
Threat Analysis and Security 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
要約
This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol.
このドキュメントはネットワークアクセサリーのための認証を運ぶのに使用されるプロトコルへの脅威について議論します。 IPを設計するためのNetwork Access(パーナ)作業部会のためのCarrying Authenticationのためのプロトコルへの追加入力がネットワークアクセス認証プロトコルを基礎づけて、これらの脅威から起こるセキュリティ要件は使用されるでしょう。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology and Definitions. . . . . . . . . . . . . . . . . . 2
4. Usage Scenarios. . . . . . . . . . . . . . . . . . . . . . . . 3
5. Trust Relationships. . . . . . . . . . . . . . . . . . . . . . 4
6. Threat Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. PAA Discovery. . . . . . . . . . . . . . . . . . . . . . 6
6.2. Authentication . . . . . . . . . . . . . . . . . . . . . 6
6.3. PaC Leaving the Network. . . . . . . . . . . . . . . . . 9
6.4. Service Theft. . . . . . . . . . . . . . . . . . . . . . 10
6.5. PAA-EP Communication . . . . . . . . . . . . . . . . . . 11
6.6. Miscellaneous Attacks. . . . . . . . . . . . . . . . . . 12
7. Summary of Requirements. . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 キーワード. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 用語と定義。 . . . . . . . . . . . . . . . . . 2 4. 用法シナリオ。 . . . . . . . . . . . . . . . . . . . . . . . 3 5. 関係を信じてください。 . . . . . . . . . . . . . . . . . . . . . 4 6. 脅威シナリオ. . . . . . . . . . . . . . . . . . . . . . . 5 6.1。 PAA発見。 . . . . . . . . . . . . . . . . . . . . . 6 6.2. 認証. . . . . . . . . . . . . . . . . . . . . 6 6.3。 ネットワークを出るPaC。 . . . . . . . . . . . . . . . . 9 6.4. 窃盗を修理してください。 . . . . . . . . . . . . . . . . . . . . . 10 6.5. PAA-EPコミュニケーション. . . . . . . . . . . . . . . . . . 11 6.6。 その他は攻撃されます。 . . . . . . . . . . . . . . . . . 12 7. 要件の概要。 . . . . . . . . . . . . . . . . . . . 13 8. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 13 9. 引用規格. . . . . . . . . . . . . . . . . . . . . 14 10。 有益な参照. . . . . . . . . . . . . . . . . . . . 14 11。 承認. . . . . . . . . . . . . . . . . . . . . . . 14作者のアドレスの.14の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 15
Parthasarathy Informational [Page 1] RFC 4016 PANA Threat Analysis March 2005
2005年の[1ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
1. Introduction
1. 序論
The Protocol for Carrying Authentication for Network Access (PANA) Working Group is developing methods for authenticating clients to the access network using IP based protocols. This document discusses the threats to such IP based protocols.
Network Access(パーナ)作業部会のためのCarrying AuthenticationのためのプロトコルはIPのベースのプロトコルを使用することでアクセスネットワークにクライアントを認証するためのメソッドを開発しています。 このドキュメントはそのようなIPのベースのプロトコルへの脅威について議論します。
A client wishing to get access to the network must carry on multiple steps. First, it needs to discover the IP address of the PANA authentication agent (PAA) and then execute an authentication protocol to authenticate itself to the network. Once the client is authenticated, there might be other messages exchanged during the lifetime of the network access. This document discusses the threats in these steps without discussing any solutions. The requirements arising out of these threats will be used as input to the PANA Working Group. The use of word co-located in this document means that the referred entities are present on the same node.
ネットワークに近づく手段を得たがっているクライアントは複数のステップで続けなければなりません。 まず最初に、それは、パーナ認証エージェント(PAA)のIPアドレスを発見して、次に、ネットワークにそれ自体を認証するために認証プロトコルを実行する必要があります。 クライアントがいったん認証されると、ネットワークアクセサリーの生涯交換された他のメッセージがあるかもしれません。 どんなソリューションについても議論しないで、このドキュメントはこれらのステップにおける脅威について議論します。 これらの脅威から起こる要件はパーナ作業部会に入力されるように使用されるでしょう。 本書では共同見つけられた単語の使用は、参照された実体が同じノードに存在していることを意味します。
2. Keywords
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 [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?
3. Terminology and Definitions
3. 用語と定義
Client Access Device
クライアントアクセスデバイス
A network element (e.g., notebook computer, PDA) that requires
access to a provider's network.
プロバイダーのネットワークへのアクセスを必要とするネットワーク要素(例えば、ノートパソコン、PDA)。
Network Access Server (NAS)
ネットワークアクセス・サーバー(NAS)
Network device that provides access to the network.
ネットワークへのアクセスを提供するデバイスをネットワークでつないでください。
PANA Client (PaC)
パーナクライアント(PaC)
An entity in the edge subnet that seeks to obtain network access
from a PANA authentication agent within a network. A PANA client
is associated with a device and a set of credentials to prove its
identity within the scope of PANA.
ネットワークの中でパーナの認証エージェントからネットワークアクセスを得ようとする縁のサブネットにおける実体。 パーナクライアントは、パーナの範囲の中でアイデンティティを立証するためにデバイスと資格証明書のセットに関連づけられます。
PANA Authentication Agent (PAA)
パーナの認証エージェント(PAA)
An entity whose responsibility is to authenticate the PANA client
and to grant network access service to the client's device.
パーナクライアントを認証して、クライアントのデバイスへのネットワークアクセス・サービスを承諾する責任がことである実体。
Parthasarathy Informational [Page 2] RFC 4016 PANA Threat Analysis March 2005
2005年の[2ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
Authentication Server (AS)
認証サーバ(AS)
An entity that authenticates the PANA client. It may be
co-located with the PANA authentication agent or part of the
back-end infrastructure.
パーナクライアントを認証する実体。 それはバックエンドインフラストラクチャのパーナの認証エージェントか部分で共同見つけられるかもしれません。
Device Identifier (DI)
デバイス識別子(ディ)
The identifier used by the network to control and police the
network access of a client. Depending on the access technology,
the identifier might contain the IP address, link-layer address,
switch port number, etc., of a device. The PANA authentication
agent keeps a table for binding device identifiers to the PANA
clients. At most one PANA client should be associated with a DI
on a PANA authentication agent.
クライアントのネットワークアクセスを制御して、取り締まるのにネットワークによって使用された識別子。 アクセス技術によって、識別子はIPアドレス、リンクレイヤアドレス、デバイスのスイッチポートナンバーなどを含むかもしれません。 パーナの認証エージェントは結束装置識別子のためにパーナクライアントにテーブルを保ちます。 1人のパーナクライアントがパーナの認証エージェントの上のDIに高々、関連しているべきです。
Enforcement Point (EP)
実施ポイント(EP)
A node capable of filtering packets sent by the PANA client by
using the DI information authorized by PANA authentication agent.
パーナの認証エージェントによって認可されたDI情報を使用することによってパーナクライアントによって送られたパケットをフィルターにかけることができるノード。
Compound methods
合成メソッド
Authentication protocol in which methods are used in a sequence
one after another or in which methods are tunneled inside another
independently established tunnel between the client and server
[TUN-EAP].
メソッドが次々に相次いで使用されるか、または別のものの中で独自にメソッドにトンネルを堀る認証プロトコルはクライアントとサーバ[TUN-EAP]の間のトンネルを確立しました。
4. Usage Scenarios
4. 用法シナリオ
PANA is intended to be used in an environment where there is no a
priori trust relationship or security association between the PaC
and other nodes, such as the PAA and EP. In these environments,
one may observe the following:
PaCと他のノードとの先験的な信頼関係かセキュリティ協会が全くない環境でパーナが使用されることを意図します、PAAやEPのように。 これらの環境で、以下を観測するかもしれません:
o The link between PaC and PAA may be a shared medium (e.g.,
Ethernet) or may not be a shared medium (e.g., DSL network).
o PaCとPAAとのリンクは、共有された媒体であるかもしれない(例えば、イーサネット)か共有された媒体でないかもしれません(例えば、DSLネットワーク)。
o All the PaCs may be authenticated to the access network at
layer 2 (e.g., 3GPP2 CDMA network) and share a security
association with a layer 2 authentication agent (e.g., BTS).
The PaCs still don't trust each other; any PaC can pretend to
be a PAA, spoof IP addresses, and launch various other attacks.
o すべてのPaCsが層2(例えば、3GPP2 CDMAネットワーク)のアクセスネットワークに認証されて、層2の認証エージェント(例えば、BTS)とセキュリティ協会を共有するかもしれません。 PaCsはまだ互いを信じていません。 どんなPaCもPAAであるふりをして、IPアドレスを偽造して、他の様々な攻撃に着手できます。
The scenarios mentioned above affect the threat model of PANA. This document discusses the various threats in the context of the above network access scenarios for a better understanding of the threats. In the following discussion, any reference to a link that is not
前記のようにシナリオはパーナの脅威モデルに影響します。 このドキュメントは脅威の、より良い理解のために上のネットワークアクセスシナリオの文脈における様々な脅威について議論します。 以下の議論、リンクのそうしないどんな参照でも
Parthasarathy Informational [Page 3] RFC 4016 PANA Threat Analysis March 2005
2005年の[3ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
shared (or non-shared) is assumed to be physically secure. If such an assumption cannot be made about the link, then the case becomes the same as that for a link being shared by more than one node.
共有されるのと(非共有される)、肉体的に安全であると思われます。 リンクの周りでそのような仮定をすることができないなら、ケースは1つ以上のノードによって共有されるリンクへのそれと同じになります。
5. Trust Relationships
5. 信頼関係
PANA authentication involves a client (PaC), a PANA agent (PAA), an Authentication server (AS), and an Enforcement point (EP). The AS here refers to the AAA server that resides in the home realm of the PaC.
パーナの認証はクライアント(PaC)、パーナのエージェント(PAA)、Authenticationサーバ(AS)、およびEnforcementポイント(EP)にかかわります。 ここのASはPaCのホーム分野にあるAAAサーバを示します。
The entities that have a priori trust relationships before PANA begins are as follows:
パーナが始まる前に先験的な信頼関係がある実体は以下の通りです:
1) PAA and AS: The PaC belonging to the same administrative domain
that the AS does often has to use resources provided by a PAA
that belongs to another administrative domain. A PAA
authenticates the PaC before providing local network access.
The credentials provided by the PaC for authentication may or
may not be understood by the PAA. If the PAA does not
understand the credentials, it needs to communicate with the AS
in a different domain to verify the credentials. The threats
in the communication path between the PAA and AS are already
covered in [RAD-EAP]. To counter these threats, the
communication between the PAA and AS is secured by using a
static or dynamic security association.
1) PAAと: ASがするのと同じ管理ドメインに属すPaCはしばしば別の管理ドメインに属すPAAで調達資金を使用しなければなりません。 企業内情報通信網アクセサリーを提供する前に、PAAはPaCを認証します。 PaCによって認証に提供された資格証明書はPAAに解釈されるかもしれません。 PAAが資格証明書を理解していないなら、それは、資格証明書について確かめるために異なったドメインでASとコミュニケートする必要があります。 PAAとASの間の通信路での脅威は[RAD-EAP]で既にカバーされています。 これらの脅威に対抗するために、静的であるかダイナミックなセキュリティ協会を使用することによって、PAAとASとのコミュニケーションを保証します。
2) PAA and EP: The PAA and EP belong to the same administrative
domain. Hence, the network operator can set up a security
association to protect the traffic exchanged between them.
This document discusses the threats in this path.
2) PAAとEP: PAAとEPは同じ管理ドメインに属します。 したがって、ネットワーク・オペレータはそれらの間で交換されたトラフィックを保護するセキュリティ協会を設立できます。 このドキュメントはこの経路で脅威について議論します。
3) PaC and AS: The PaC and AS belong to the same administrative
domain and share a trust relationship. When the PaC uses a
different domain than its home for network access, it provides
its credentials to the PAA in the visited network for
authentication. The information provided by the PaC traverses
the PaC-PAA and PAA-AS paths. The threats in the PAA-AS path
are already discussed in [RAD-EAP]. This document discusses
the threats in the PaC-PAA path.
3) PaCと: PaCとASは同じ管理ドメインに属して、信頼関係を共有します。 PaCがネットワークアクセスのためのホームと異なったドメインを使用すると、それは認証のために訪問されたネットワークにおけるPAAに資格証明書を供給します。 PaCによって提供された情報はPaC-PAAとPAA-AS経路を横断します。 [RAD-EAP]で既にPAA-AS経路の脅威について議論します。 このドキュメントはPaC-PAA経路で脅威について議論します。
It is possible that some of the entities such as the PAA, AS, and EP are co-located. In those cases, it can be safely assumed that there are no significant external threats in their communication.
PAAや、ASや、EPなどの実体のいくつかが共同見つけられているのは、可能です。 それらの場合では、安全にそれらのコミュニケーションにはどんな重要な外的脅威もないと思うことができます。
The entities that do not have any trust relationship before PANA begins are as follows:
パーナが始まる前に少しの信頼関係もない実体は以下の通りです:
Parthasarathy Informational [Page 4] RFC 4016 PANA Threat Analysis March 2005
2005年の[4ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
1) PaC and PAA: The PaC and PAA normally belong to two different
administrative domains. They do not necessarily share a trust
relationship initially. They establish a security association
in the process of authentication. All messages exchanged
between the PaC and PAA are subject to various threats, which
are discussed in this document.
1) PaCとPAA: 通常、PaCとPAAは2つの異なった管理ドメインに属します。 彼らは初めは、必ず信頼関係を共有するというわけではありません。 彼らは認証の途中にセキュリティ協会を設立します。 PaCとPAAの間で交換されたすべてのメッセージが様々な脅威を受けることがあります。(本書では脅威について議論します)。
2) PaC and EP: The EP belongs to the same administrative domain as
the PAA. Hence, the PaC and EP do not necessarily share a
trust relationship initially. When the PaC is successfully
authenticated, it may result in key establishment between the
PaC and PAA, which can be further used to secure the link
between the PaC and EP. For example, the EAP keying framework,
[EAP-KEY], defines a three party EAP exchange in which the
clients derive the transient sessions keys to secure the link
between the peer and NAS in their final step. Similarly, PANA
will provide the ability to establish keys between the PaC and
EP that can be used to secure the link further. This is
discussed further in Section 6.4 below.
2) PaCとEP: EPはPAAと同じ管理ドメインに属します。 したがって、PaCとEPは初めは、必ず信頼関係を共有するというわけではありません。 PaCが首尾よく認証されるとき、それはPaCとPAAの間の主要な設立をもたらすかもしれません。さらに、PaCとEPとのリンクを固定するのにPAAを使用できます。 例えば、フレームワークを合わせるEAP[EAP-KEY]はクライアントが彼らの最終的なステップに同輩とNASとのリンクを固定するために一時的なセッションキーを引き出す3パーティーEAP交換を定義します。 同様に、パーナはさらにリンクを固定するのに使用できるPaCとEPの間にキーを設立する能力を供給するでしょう。 以下のセクション6.4で、より詳しくこれについて議論します。
6. Threat Scenarios
6. 脅威シナリオ
First, the PaC needs to discover the PAA. This involves either sending solicitations or waiting for advertisements. Once it has discovered the PAA, the two will enter authentication exchange. Once the access is granted, the PaC will most likely exchange data with other nodes in the Internet. These steps are vulnerable to man-in- the-middle (MITM), denial of service (DoS), and service theft attacks, which are discussed below.
まず最初に、PaCは、PAAを発見する必要があります。 これは、懇願を送るか、または広告を待つことを伴います。 一度、それは、PAA、2が認証交換に入ると発見したことがあります。 アクセスがいったん承諾されると、PaCはたぶんインターネットで他のノードとデータを交換するでしょう。 中の男性にとって、これらのステップが被害を受け易い、-、-、中央、(MITM)、サービス(DoS)の否定、およびサービス窃盗(以下で議論する)は攻撃されます。
The threats are grouped by the various stages the client goes through to gain access to the network. Section 6.1 discusses the threats related to PAA discovery. Section 6.2 discusses the threats related to authentication itself. Section 6.3 discusses the threats involved when leaving the network. Section 6.4 discusses service theft. Section 6.5 discusses the threats in the PAA-EP path. Section 6.6 discusses the miscellaneous threats.
脅威はクライアントがネットワークへのアクセスを得るために直面している様々な段階によって分類されます。 セクション6.1はPAA発見に関連する脅威について論じます。 セクション6.2は認証自体に関連する脅威について論じます。 セクション6.3はネットワークを出るときかかわる脅威について論じます。 セクション6.4はサービス窃盗について論じます。 セクション6.5はPAA-EP経路で脅威について論じます。 セクション6.6は種々雑多な脅威について論じます。
Some of the threats discussed in the following sections may be specific to shared links. The threat may be absent on non-shared links. Hence, it is only required to prevent the threat on shared links. Instead of specifying a separate set of requirements for shared links and non-shared links, this document specifies one set of requirements with the following wording: "PANA MUST be able to prevent threat X". This means that the PANA protocol should be capable of preventing threat X. The feature that prevents threat X may or may not be used depending on the deployment.
以下のセクションで議論した脅威のいくつかが共有されたリンクに特定であるかもしれません。 脅威は非共有されたリンクで欠けているかもしれません。 したがって、それが、共有されたリンクの上に脅威を防ぐのに必要であるだけです。 共有されたリンクと非共有されたリンクのための別々のセットの要件を指定することの代わりに、このドキュメントは以下の言葉遣いで1セットの要件を指定します: 「パーナは脅威Xを防ぐことができなければなりません。」 これは、パーナプロトコルを脅威Xを防ぐ特徴が防ぐ脅威X.を防ぐことができないべきですし、展開によって、使用できないことを意味します。
Parthasarathy Informational [Page 5] RFC 4016 PANA Threat Analysis March 2005
2005年の[5ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
6.1. PAA Discovery
6.1. PAA発見
The PAA is discovered by sending solicitations or receiving advertisements. The following are possible threats.
PAAは、懇願を送るか、または広告を受け取ることによって、発見されます。 ↓これは可能な脅威です。
T6.1.1: A malicious node can pretend to be a PAA by sending a spoofed
advertisement.
T6.1.1: 悪意があるノードは、偽造している広告を送るのによるPAAであるふりをすることができます。
In existing dial-up networks, the clients authenticate to the network but generally do not verify the authenticity of the messages coming from Network Access Server (NAS). This mostly works because the link between the device and the NAS is not shared with other nodes (assuming that nobody tampers with the physical link), and clients trust the NAS and the phone network to provide the service. Spoofing attacks are not present in this environment, as the PaC may assume that the other end of the link is the PAA.
既存のダイアルアップ・ネットワークで、ネットワークに認証しますが、一般に、クライアントはメッセージがNetwork Access Server(NAS)から来る信憑性について確かめません。 NASと電話ネットワークがサービスを提供するとデバイスとNASとのリンクが他のノードと共有されないので(だれも物理的なリンクをいじらないと仮定して)、これはほとんど働いて、クライアントは、信じます。 スプーフィング攻撃はこの環境で存在していません、PaCが、リンクのもう一方の端がPAAであると仮定するとき。
In environments where the link is shared, this threat is present, as any node can pretend to be a PAA. Even if the nodes are authenticated at layer 2, the threat remains present. It is difficult to protect the discovery process, as there is no a priori trust relationship between the PAA and PaC. In deployments where EP can police the packets that are sent among the PaCs, it is possible to filter out the unauthorized PANA packets (e.g., PAA advertisements sent by PaC) to prevent this threat.
リンクが共有される環境で、どんなノードも、PAAであるふりをすることができるので、この脅威は存在しています。 ノードが層2で認証されても、脅威は存在していたままで残っています。 発見プロセスを保護するのは難しいです、PAAとPaCとの先験的な信頼関係が全くないとき。 展開では、EPがPaCsの中で送られるパケットを取り締まることができるところでこの脅威を防ぐために、権限のないパーナパケット(例えばPaCによって送られたPAA広告)を無視するのは可能です。
The advertisement may be used to include information (such as supported authentication methods) other than the discovery of the PAA itself. This can lead to a bidding down attack, as a malicious node can send a spoofed advertisement with capabilities that indicate authentication methods less secure than those that the real PAA supports, thereby fooling the PaC into negotiating an authentication method less secure than would otherwise be available.
広告は、PAA自身の発見を除いて、情報を含むこと(認証方法であるとサポートされるように)に使用されるかもしれません。 これは攻撃の下側への入札に通じることができます、悪意があるノードが本当のPAAがサポートするものほど安全でない認証方法を示す能力がある偽造している広告を送ることができるとき、その結果、PaCがそうでなければ、利用可能であるだろうというほど安全でない認証方法を交渉するようにだまします。
Requirement 1
要件1
PANA MUST not assume that the discovery process is protected.
パーナは、発見プロセスが保護されると仮定してはいけません。
6.2. Authentication
6.2. 認証
This section discusses the threats specific to the authentication protocol. Section 6.2.1 discusses the possible threat associated with success/failure indications that are transmitted to PaC at the end of the authentication. Section 6.2.2 discusses the man-in-the- middle attack when compound methods are used. Section 6.2.3 discusses the replay attack, and Section 6.2.4 discusses the device identifier attack.
このセクションは認証プロトコルに特定の脅威について論じます。 セクション6.2 .1 認証の終わりにPaCに伝えられる成功/失敗指摘に関連している可能な脅威について議論します。 セクション6.2.2が中の男性について議論する、-、-合成メソッドが使用されているとき、中央は攻撃されます。 セクション6.2.3は反射攻撃について議論します、そして、セクション6.2.4はデバイス識別子攻撃について議論します。
Parthasarathy Informational [Page 6] RFC 4016 PANA Threat Analysis March 2005
2005年の[6ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
6.2.1. Success or Failure Indications
6.2.1. 成否指摘
Some authentication protocols (e.g., EAP) have a special message to indicate success or failure. An attacker can send a false authentication success or failure message to the PaC. By sending a false failure message, the attacker can prevent the client from accessing the network. By sending a false success message, the attacker can prematurely end the authentication exchange, effectively denying service for the PaC.
いくつかの認証プロトコル(例えば、EAP)には、成否を示す特別教書があります。 攻撃者は誤った認証成否メッセージをPaCに送ることができます。 誤った失敗メッセージを送ることによって、攻撃者は、クライアントがネットワークにアクセスするのを防ぐことができます。 誤った成功メッセージを送ることによって、攻撃者は早まって、認証交換を終わらせて、事実上、PaCのためにサービスを否定できます。
If the link is not shared, then this threat is absent, as ingress filtering can prevent the attacker from impersonating the PAA.
リンクが共有されないなら、この脅威は欠けています、攻撃者がイングレスフィルタリングによってPAAをまねることができないとき。
If the link is shared, it is easy to spoof these packets. If layer 2 provides per-packet encryption with pair-wise keys, it might make it hard for the attacker to guess the success or failure packet that the client would accept. Even if the node is already authenticated at layer 2, it can still pretend to be a PAA and spoof the success or failure.
リンクが共有されるなら、これらのパケットを偽造するのは簡単です。 層2が1パケットあたりの暗号化に対状キーを提供するなら、それで、クライアントが受け入れるだろうというのが攻撃者が成否パケットを推測しにくいようになるかもしれません。 ノードが層2で既に認証されても、それは、PAAであり、成否を偽造するまだふりをすることができます。
This attack is possible if the success or failure indication is not protected by using a security association between the PaC and the PAA. In order to avoid this attack, the PaC and PAA should mutually authenticate each other. In this process, they should be able to establish keys to protect the success or failure indications. It may not always be possible to protect the indication, as the keys may not be established prior to transmitting the success or failure packet. If the client is re-authenticating to the network, it can use the previously established security association to protect the success or failure indications. Similarly, all PANA messages exchanged during the authentication prior to key establishment may not be protected.
成否指示がPaCとPAAとのセキュリティ協会を使用することによって保護されないなら、この攻撃は可能です。 この攻撃を避けるために、PaCとPAAは互いに互いを認証するはずです。 このプロセスでは、彼らは、成否指摘を保護するためにキーを設立できるべきです。 指示を保護するのはいつも可能であるかもしれないというわけではありません、成否パケットを伝える前にキーが設立されないとき。 クライアントがネットワークに再認証しているなら、それは成否指摘を保護する以前に設立されたセキュリティ協会を使用できます。 同様に、主要な設立の前に認証の間に交換されたすべてのパーナメッセージは保護されないかもしれません。
Requirement 2
要件2
PANA MUST be able to mutually authenticate the PaC and PAA. PANA MUST be able to establish keys between the PaC and PAA to protect the PANA messages.
パーナは互いにPaCとPAAを認証できなければなりません。 パーナは、パーナメッセージを保護するためにPaCとPAAの間のキーを設立できなければなりません。
6.2.2. MITM Attack
6.2.2. MITM攻撃
A malicious node can claim to be the PAA to the real PaC and claim to be the PaC to the real PAA. This is a man-in-the-middle (MITM) attack, whereby the PaC is fooled to think that it is communicating with the real PAA and the PAA is fooled to think that it is communicating with the real PaC.
悪意があるノードは、本当のPaCへのPAAであり、本当のPAAへのPaCであると主張すると主張できます。 これは中央の男性(MITM)攻撃です。(PaCは本当のPAAとコミュニケートしていると思うためにだまされて、PAAは、本当のPaCとコミュニケートしていると思うためにその攻撃でだまされます)。
Parthasarathy Informational [Page 7] RFC 4016 PANA Threat Analysis March 2005
2005年の[7ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
If the link is not shared, this threat is absent, as ingress filtering can prevent the attacker from acting as a man-in-the- middle.
リンクが共有されないなら、この脅威は欠けています、攻撃者がイングレスフィルタリングによって中の男性として務めることができないとき-、-、中央。
If the link is shared, this threat is present. Even if the layer 2 provides per-packet protection, the attacker can act as a man-in- the-middle and launch this attack. An instance of MITM attack, in which compound authentication methods are used is described in [TUN-EAP]. In these attacks, the server first authenticates to the client. As the client has not proven its identity yet, the server acts as the man-in-the-middle, tunneling the identity of the legitimate client to gain access to the network. The attack is possible because there is no verification that the same entities participated among the compound methods. It is not possible to do such verification if compound methods are used without being able to create a cryptographic binding among them. This implies that PANA will be vulnerable to such attacks if compound methods are used without being able to cryptographically bind them. Note that the attack does not exist if the keys derived during the tunnel establishment are not used to authenticate the client (e.g., tunnel keys are used for just protecting the identity of the client).
リンクが共有されるなら、この脅威は存在しています。 層2が1パケットあたりの保護を提供しても、攻撃者が中の男性として務めることができる、-、-、中央、そして、これが攻撃する着手。 MITM攻撃のインスタンスであり、認証方法がどの飯場で使用されているかは[TUN-EAP]で説明されます。 中では、これらは攻撃されて、サーバは1番目です。クライアントに、認証します。 クライアントがまだアイデンティティを立証していないとき、サーバは中央の男性として機能します、ネットワークへのアクセスを得るために正統のクライアントのアイデンティティにトンネルを堀って。 攻撃は検証が全くないのでそんなに同じ実体が合成メソッドの中で参加したのが可能です。 合成メソッドがそれらの中で暗号の結合を作成できないで使用されるなら、そのような検証をするのは可能ではありません。 これは、合成メソッドが暗号でそれらを縛ることができないで使用されるならパーナがそのような攻撃に被害を受け易くなるのを含意します。 トンネル設立の間に引き出されたキーがクライアントを認証するのに使用されないなら(例えばトンネルキーはただクライアントのアイデンティティを保護するのに使用されます)攻撃が存在しないことに注意してください。
Requirement 3
要件3
When compound authentication methods are used in PANA, the methods MUST be cryptographically bound.
合成認証方法がパーナで使用されるとき、暗号でメソッドを縛らなければなりません。
6.2.3. Replay Attack
6.2.3. 反射攻撃
A malicious node can replay the messages that caused authentication failure or success at a later time to create false failures or success. The attacker can also potentially replay other messages of the PANA protocol to deny service to the PaC.
悪意があるノードは誤った失敗か成功を作成するために後で認証失敗か成功を引き起こしたメッセージを再演できます。 また、攻撃者は潜在的にパーナプロトコルがPaCに対するサービスを否定する他のメッセージを再演できます。
If the link is not shared, this threat is absent, as ingress filtering can prevent the attacker from impersonating the PAA to replay the packets.
リンクが共有されないなら、この脅威は欠けています、攻撃者がイングレスフィルタリングによってパケットを再演するためにPAAをまねることができないとき。
If the link is shared, this threat is present. If the packets are encrypted at layer 2 by using pair-wise keys, it will make it hard for the attacker to learn the unencrypted (i.e., original) packet that needs to be replayed. Even if layer 2 provides replay protection, the attacker can still replay the PANA messages (layer 3) for denying service to the client.
リンクが共有されるなら、この脅威は存在しています。 パケットが対状キーを使用することによって層2に暗号化されると、それで、攻撃者が再演される必要がある非暗号化された(すなわち、オリジナルの)パケットを学ぶのが困難になるでしょう。 層2が反復操作による保護を提供しても、攻撃者はまだ、クライアントに対するサービスを否定することへのパーナメッセージ(層3)を再演できます。
Requirement 4
要件4
PANA MUST be able to protect itself against replay attacks.
パーナは反射攻撃に対して我が身をかばうことができなければなりません。
Parthasarathy Informational [Page 8] RFC 4016 PANA Threat Analysis March 2005
2005年の[8ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
6.2.4. Device Identifier Attack
6.2.4. デバイス識別子攻撃
When the client is successfully authenticated, the PAA sends access control information to the EP for granting access to the network. The access control information typically contains the device identifier of the PaC, which is either obtained from the IP headers and MAC headers of the packets exchanged during the authentication process or carried explicitly in the PANA protocol field. The attacker can gain unauthorized access into the network by taking the following steps.
クライアントが首尾よく認証されるとき、PAAは、ネットワークへのアクセスを承諾するためにアクセス制御情報をEPに送ります。 アクセス制御情報はIPヘッダーから入手されるPaCに関するデバイス識別子と認証過程の間、交換するか、またはパーナプロトコル分野で明らかに運ぶパケットのMACヘッダーを通常含んでいます。 攻撃者は、以下の方法を取ることによって、不正アクセスをネットワークに獲得できます。
o An attacker pretends to be a PAA and sends advertisements. The
PaC is fooled and starts exchanging packets with the attacker.
o 攻撃者は、PAAであるふりをして、広告を送ります。 PaCはだまされて、攻撃者とパケットを交換し始めます。
o The attacker modifies the IP source address on the packet,
adjusts the UDP/TCP checksum, and forwards the packet to the
real PAA. It also does the same on return packets.
o 攻撃者は、パケットに関するIPソースアドレスを変更して、UDP/TCPチェックサムを調整して、本当のPAAにパケットを送ります。 また、それはリターンパケットで同じようにします。
o When the real PaC is successfully authenticated, the attacker
gains access to the network, as the packets contained the IP
address (and potentially the MAC address also) of the attacker.
o 本当のPaCが首尾よく認証されるとき、攻撃者はネットワークへのアクセスを得ます、パケットが攻撃者のIPアドレス(そして、潜在的にMACアドレスも)を含んだので。
If the link is not shared, this threat is absent, as the attacker cannot impersonate the PAA and intercept the packets from the PaC.
リンクが共有されないなら、この脅威は欠けています、攻撃者がPAAをまねて、PaCからパケットを妨害できないとき。
If the link is shared, this threat is present. If the layer 2 provides per-packet protection, it is not possible to change the MAC address, and hence this threat may be absent in such cases if EP filters on both the IP and MAC address.
リンクが共有されるなら、この脅威は存在しています。 層2が1パケットあたりの保護を提供するなら、そのような場合EPが両方でIPとMACアドレスをフィルターにかけるならMACアドレスを変えて、したがって、この脅威を変えるのが休んでいるのは、可能ではありません。
Requirement 5
要件5
PANA MUST be able to protect the device identifier against spoofing when it is exchanged between the PaC and PAA.
パーナは、PaCとPAAの間でそれを交換するときだまさないようにデバイス識別子を保護できなければなりません。
6.3. PaC Leaving the Network
6.3. ネットワークを出るPaC
When the PaC leaves the network, it can inform the PAA before disconnecting from the network so that the resources used by PaC can be accounted properly. The PAA may also choose to revoke the access anytime it deems necessary. The following are possible threats:
PaCがネットワークを出るとき、それは適切にPaCによる運用資金を説明できるようにネットワークから切断する前に、PAAに知らせることができます。 また、PAAは、いつでもアクセスを取り消すのを選ぶかもしれません。それは、必要であると考えます。 ↓これは可能な脅威です:
T6.3.1: A malicious node can pretend to be a PAA and revoke the
access to PaC.
T6.3.1: 悪意があるノードは、PAAであり、PaCへのアクセスを取り消すふりをすることができます。
T6.3.2: A malicious node can pretend to be a real PaC and transmit a
disconnect message.
T6.3.2: 悪意があるノードは、本当のPaCであり、分離メッセージを送るふりをすることができます。
Parthasarathy Informational [Page 9] RFC 4016 PANA Threat Analysis March 2005
2005年の[9ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
T6.3.3: The PaC can leave the network without notifying the PAA or EP
(e.g., the Ethernet cable is unplugged, system crash). An
attacker can pretend to be the PaC and start using the
network.
T6.3.3: PAAかEPに通知しないで、PaCはネットワークを出ることができます(例えば、イーサネットケーブルはアンプラグド、システムクラッシュです)。 攻撃者は、PaCであり、ネットワークを使用し始めるふりをすることができます。
If the link is not shared, threats T6.3.1 and T6.3.2 are absent. Threat T6.3.3 may still be present. If there is no layer 2 indication, or if the layer 2 indication cannot be relied upon, then threat T6.3.3 is still present on non-shared links.
リンクが共有されないなら、脅威T6.3.1とT6.3.2は欠けています。 脅威T6.3.3はまだ存在しているかもしれません。 層であるなら2指示を当てにすることができません、そして、次に、あれば、いいえが2指示を層にするか、または脅威T6.3.3は非共有されたリンクにまだ存在しています。
If the link is shared, all of the above threats are present, as any node on the link can spoof the disconnect message. Even if layer 2 has per-packet authentication, the attacker can pretend to be a PaC (e.g., by spoofing the IP address) and disconnect from the network. Similarly, any node can pretend to be a PAA and revoke the access to the PaC. Therefore, T6.3.1 and T6.3.2 are possible even on links where layer 2 is secured. Threat T6.3.3 can be prevented if layer 2 provides per-packet authentication. The attacker cannot subsume the PaC that left the network without knowing the keys that protect the packet at layer 2.
リンクが共有されるなら、上の脅威のすべてが出席しています、リンクの上のどんなノードも分離メッセージを偽造することができるとき。 層2に1パケットあたりの認証があっても、攻撃者は、PaCであるふりをして(例えば、IPアドレスを偽造することによって)、ネットワークから切断することができます。 同様に、どんなノードも、PAAであり、PaCへのアクセスを取り消すふりをすることができます。 したがって、T6.3.1とT6.3.2は層2が固定されているリンクでさえ可能です。 層2が1パケットあたりの認証を提供するなら、脅威T6.3.3を防ぐことができます。 層2にパケットを保護するキーを知らないで、攻撃者はネットワークを出たPaCを包括できません。
Requirement 6
要件6
PANA MUST be able to protect disconnect and revocation messages. PANA MUST NOT depend on the PaC sending a disconnect message.
パーナは分離と取消しメッセージを保護できなければなりません。 パーナは分離メッセージを送るPaCによってはいけません。
6.4. Service Theft
6.4. サービス窃盗
An attacker can gain unauthorized access into the network by stealing the service from another client. Once the real PaC is successfully authenticated, the EP will have filters in place to prevent unauthorized access into the network. The filters will be based on something that will be carried on every packet. For example, the filter could be based on the IP and MAC addresses, where the packets will be dropped unless the packets coming with certain IP addresses also match the MAC addresses. The following are possible threats:
攻撃者は、別のクライアントからサービスを横取りすることによって、不正アクセスをネットワークに獲得できます。 本当のPaCがいったん首尾よく認証されると、EPは、ネットワークに不正アクセスを防ぐために適所にフィルタを持つでしょう。 フィルタはあらゆるパケットの上で運ばれる何かに基づくでしょう。 例えば、フィルタはIPとMACアドレスに基づくことができました。そこでは、また、あるIPアドレスと共に来るパケットがMACアドレスに合っていないと、パケットが下げられるでしょう。 ↓これは可能な脅威です:
T6.4.1: An attacker can spoof both the IP and MAC addresses of an
authorized client to gain unauthorized access. The attacker
can launch this attack easily by just sniffing the wire for
IP and MAC addresses. This lets the attacker use the network
without any authorization, getting a free service.
T6.4.1: 攻撃者は、IPと獲得する認可されたクライアントのMACアドレスの両方が権限のないアクセスであると偽造することができます。 IPとMACアドレスに関してただワイヤをかぐことによって、攻撃者は容易にこの攻撃に着手できます。 これで、無料奉仕を得て、攻撃者は少しも承認なしでネットワークを使用できます。
T6.4.2: The PaC can leave the network without notifying the PAA or EP
(e.g., the Ethernet cable is unplugged, system crash). An
attacker can pretend to be the PaC and start using the
network.
T6.4.2: PAAかEPに通知しないで、PaCはネットワークを出ることができます(例えば、イーサネットケーブルはアンプラグド、システムクラッシュです)。 攻撃者は、PaCであり、ネットワークを使用し始めるふりをすることができます。
Parthasarathy Informational [Page 10] RFC 4016 PANA Threat Analysis March 2005
2005年の[10ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
Service theft allows the possibility of exploiting the weakness in other authentication protocols that use IP address for authentication. It also allows the interception of traffic destined for other nodes by spoofing the IP address.
サービス窃盗は認証にIPアドレスを使用する他の認証プロトコルの弱点を開発する可能性を許容します。 また、それは他のノードのためにIPアドレスを偽造することによって運命づけられたトラフィックの妨害を許します。
If the link is not shared, T6.4.1 is absent, as there is only one client on the link, and ingress filtering can prevent the use of the authorized IP and MAC addresses by the attacker on another link. Threat T6.4.2 exists, as the attacker can use the IP or MAC address of the real PaC to gain access to the network.
リンクが共有されないなら、T6.4.1は欠けています、1人のクライアントしかリンクの上にいないで、イングレスフィルタリングが別のリンクの上に攻撃者による認可されたIPとMACアドレスの使用を防ぐことができるとき。 脅威T6.4.2は存在しています、攻撃者がネットワークへのアクセスを得るのに本当のPaCのIPかMACアドレスを使用できるとき。
If the link is shared, both the threats are present. If layer 2 provides per-packet protection using pair-wise keys, both the threats can be prevented.
リンクが共有されるなら、両方の脅威は存在しています。 層2が対状キーを使用することで1パケットあたりの保護を提供するなら、両方の脅威を防ぐことができます。
Requirement 7
要件7
PANA MUST securely bind the authenticated session to the device identifier of the client, to prevent service theft. PANA MUST be able to bootstrap a shared secret between the PaC and PAA that can be further used to set up a security association between the PaC and EP to provide cryptographic protection against service theft.
パーナは、サービス窃盗を防ぐためにしっかりとクライアントのデバイス識別子に認証されたセッションを縛らなければなりません。 パーナはサービス窃盗に対する暗号の保護を提供するためにPaCとEPとのセキュリティ協会を設立するのにさらに使用できるPaCとPAAの間の共有秘密キーを独力で進むことができなければなりません。
6.5. PAA-EP Communication
6.5. PAA-EPコミュニケーション
After a successful authentication, the PAA needs to communicate the access control information of the PaC to the EP so that the PaC will be allowed to access the network. The information communicated would contain at least the device identifier of the PaC. If strong security is needed, the PAA will communicate a shared secret known only to the PaC and PAA, for setting up a security association between the PaC and EP. The following are possible threats:
うまくいっている認証の後に、PAAは、PaCがネットワークにアクセスできるようにPaCに関するアクセス制御情報をEPに伝える必要があります。 伝えられた情報は少なくともPaCに関するデバイス識別子を含んでいるでしょう。 強いセキュリティが必要であるなら、PAAはPaCとPAAだけにおいて知られている共有秘密キーを伝えるでしょう、PaCとEPとのセキュリティ協会を設立するために。 ↓これは可能な脅威です:
T6.5.1: An attacker can eavesdrop to learn the information
communicated between the PAA and EP. The attacker can
further use this information to spoof the real PaC and also
to set up security association for gaining access to the
network. This threat is absent if the attacker cannot
eavesdrop on the link; e.g., the PAA and EP communicate on a
link separate from that of visiting PaCs.
T6.5.1: 攻撃者は、PAAとEPの間で伝えられた情報を学ぶために盗み聞くことができます。 攻撃者は、本当のPaCを偽造して、また、ネットワークへのアクセスを得るためにセキュリティ協会を設立するのにさらにこの情報を使用できます。 攻撃者がリンクを立ち聞きできないなら、この脅威は欠けています。 例えば、PAAとEPは訪問PaCsのものから別々のリンクについて話し合います。
T6.5.2: An attacker can pretend to be a PAA and send false
information to an EP to gain access to the network. In the
case of stronger security, the attacker has to send its own
device identifier and also a shared secret, so that the EP
will let the attacker access the network.
T6.5.2: 攻撃者は、ネットワークへのアクセスを得るためにPAAであり、偽情報をEPに送るふりをすることができます。 より強いセキュリティの場合では、攻撃者はそれ自身のデバイス識別子と共有秘密キーも送らなければなりません、EPが攻撃者をネットワークにアクセスさせることができるように。
Parthasarathy Informational [Page 11] RFC 4016 PANA Threat Analysis March 2005
2005年の[11ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
If the communication between the PAA and EP is protected, these threats are absent.
PAAとEPとのコミュニケーションが保護されるなら、これらの脅威は欠けています。
Requirement 8
要件8
The communication between the PAA and EP MUST be protected against eavesdropping and spoofing attacks.
盗聴に対して保護されて、攻撃を偽造することであるPAAとEP MUSTとのコミュニケーション。
6.6. Miscellaneous Attacks
6.6. 種々雑多な攻撃
T6.6.1: There are various forms of DoS attacks that can be launched
on the PAA or AS. A few are mentioned below. As it is hard
to defend against some of the DoS attacks, the protocol
should be designed carefully to mitigate or prevent such
attacks.
T6.6.1: PAAかASで着手できる様々な形式のDoS攻撃があります。 いくつかは以下に言及されます。 DoS攻撃のいくつかに対して防御しにくいので、プロトコルはそのような攻撃を緩和するか、または防ぐように入念に設計されるべきです。
o An attacker can bombard the PAA with lots of
authentication requests. If the PAA and AS are not co-
located, the PAA may have to allocate resources to store
some state about the PaC locally before it receives the
response from the back-end AS. This can deplete memory
resources on the PAA.
o 攻撃者は多くの認証要求をPAAに砲撃できます。 PAAとASが共同見つけられていないなら、PAAは、バックエンドASから応答を受ける前にPaCに関して局所的に何らかの状態を保存するためにリソースを割り当てなければならないかもしれません。 これはPAAに関するメモリリソースを使い果たすことができます。
o With minimal effort, an attacker can force the PAA or AS
to make computationally intensive operations with minimal
effort, that can deplete the CPU resources of the PAA or
AS.
o 最小量の取り組みで、攻撃者はPAAかASに最小量の取り組みで計算上徹底的な操作を強制的にさせることができて、それはPAAかASに関するCPUリソースを使い果たすことができます。
T6.6.2: PaC acquires an IP address by using stateful or stateless
mechanisms before PANA authentication begins [PANAREQ]. When
the IP addresses are assigned before the client
authentication, it opens up the possibility of DoS attacks in
which unauthenticated malicious nodes can deplete the IP
address space by acquiring multiple IP addresses or deny
allocation to others by responding to every duplicate address
detection (DAD) query.
T6.6.2: PaCは、パーナの認証が[PANAREQ]を始める前にstatefulであるか状態がないメカニズムを使用することによって、IPアドレスを習得します。 IPアドレスがクライアント認証の前に割り当てられるとき、それは非認証された悪意があるノードが複数のIPアドレスを習得することによってIPアドレス空間を使い果たす場合があるか、または他のものに対してあらゆる写しアドレス検出(DAD)質問に応じることによって配分を否定する場合があるDoS攻撃の可能性を開けます。
Depleting a /64 IPv6 link-local address space or a /8 RFC1918
private address space requires a brute-force attack. Such an
attack is part of a DoS class that can equally target the
link capacity or the CPU cycles on the target system by
bombarding arbitrary packets. Therefore, solely handling the
IP address depletion attack is not going to improve the
security, as a more general solution is needed to tackle the
whole class of brute-force attacks.
/64IPv6リンクローカルアドレススペースか/8RFC1918プライベート・アドレススペースを使い果たすのは全数探索法を必要とします。 そのような攻撃は目標システムの上で任意のパケットを砲撃することによって等しくリンク容量かCPUサイクルを狙うことができるDoSのクラスの一部です。 したがって、唯一IPアドレス減少攻撃を扱う場合、セキュリティは向上しないでしょう、より一般的なソリューションが全体のクラスの全数探索法に取り組むのに必要であるときに。
The DAD attack can be prevented by deploying secure address
resolution that does not depend on the client authentication,
安全なアドレスがクライアント認証によらない解決であると配布することによって、DAD攻撃を防ぐことができます。
Parthasarathy Informational [Page 12] RFC 4016 PANA Threat Analysis March 2005
2005年の[12ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
such as [SEND]. The attack may also be prevented if the EP
is placed between the PaCs to monitor the ND/ARP activity and
to detect DAD attacks (excessive NA/ARP replies). If none of
these solutions are applicable to a deployment, the PaCs can
send arbitrary packets to each other without going through
the EP, which enables a class of attacks that are based on
interfering with the PANA messaging (See T6.1.1). Since
there will always be a threat in this class (e.g., insecure
discovery), it is not going to improve the overall security
by addressing DAD.
[SEND]などのように。 また、EPがノースダコタ/ARP活動をモニターして、DAD攻撃(過度のNA/ARP回答)を検出するためにPaCsの間に置かれるなら、攻撃は防がれるかもしれません。 これらのソリューションのいずれも展開に適切でないなら、EPを通らないで、PaCsは任意のパケットを互いに送ることができます(T6.1.1を見てください)。(EPはパーナメッセージングを妨げるのに基づいている攻撃のクラスを可能にします)。 このクラス(例えば、不安定な発見)には脅威がいつもあるので、それはDADを扱うことによって、総合的なセキュリティを向上させないでしょう。
7. Summary of Requirements
7. 要件の概要
1. PANA MUST not assume that the discovery process is protected.
1. パーナは、発見プロセスが保護されると仮定してはいけません。
2. PANA MUST be able to mutually authenticate the PaC and PAA. PANA
MUST be able to establish keys between the PaC and PAA to protect
the PANA messages.
2. パーナは互いにPaCとPAAを認証できなければなりません。 パーナは、パーナメッセージを保護するためにPaCとPAAの間のキーを設立できなければなりません。
3. When compound authentication methods are used in PANA, the methods
MUST be cryptographically bound.
3. 合成認証方法がパーナで使用されるとき、暗号でメソッドを縛らなければなりません。
4. PANA MUST be able to protect itself against replay attacks.
4. パーナは反射攻撃に対して我が身をかばうことができなければなりません。
5. PANA MUST be able to protect the device identifier against
spoofing when it is exchanged between the PaC and PAA.
5. パーナは、PaCとPAAの間でそれを交換するときだまさないようにデバイス識別子を保護できなければなりません。
6. PANA MUST be able to protect disconnect and revocation messages.
PANA MUST NOT depend on whether the PaC sends a disconnect
message.
6. パーナは分離と取消しメッセージを保護できなければなりません。 パーナはPaCが分離メッセージを送るかどうかによってはいけません。
7. PANA MUST securely bind the authenticated session to the device
identifier of the client, to prevent service theft. PANA MUST be
able to bootstrap a shared secret between the PaC and PAA that can
be further used to set up a security association between the PaC
and EP to provide cryptographic protection against service theft.
7. パーナは、サービス窃盗を防ぐためにしっかりとクライアントのデバイス識別子に認証されたセッションを縛らなければなりません。 パーナはサービス窃盗に対する暗号の保護を提供するためにPaCとEPとのセキュリティ協会を設立するのにさらに使用できるPaCとPAAの間の共有秘密キーを独力で進むことができなければなりません。
8. The communication between the PAA and EP MUST be protected against
eavesdropping and spoofing attacks.
8. 盗聴に対して保護されて、攻撃を偽造することであるPAAとEP MUSTとのコミュニケーション。
8. Security Considerations
8. セキュリティ問題
This document discusses various threats with IP based network access authentication protocol. Though this document discusses the threats for shared and unshared links separately, it may be difficult to make such a distinction in practice (e.g., a dial-up link may be a point- to-point IP tunnel). Hence, the link should be assumed to be a shared link for most of the threats in this document.
このドキュメントはIPのベースのネットワークアクセス認証プロトコルと様々な脅威について議論します。 このドキュメントは別々に共有されて非共有されたリンクのための脅威について議論しますが、実際にはそのような区別をするのは難しいかもしれません(例えば、ダイヤルアップリンクはある程度ポイントIPトンネルであるかもしれません)。 したがって、リンクは本書では脅威の大部分の共有されたリンクであると思われるべきです。
Parthasarathy Informational [Page 13] RFC 4016 PANA Threat Analysis March 2005
2005年の[13ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
9. Normative References
9. 引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
10. Informative References
10. 有益な参照
[PANAREQ] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and
C. Wang, "Protocol for Carrying Authentication for
Network Access (PANA) Requirements and Terminology",
Work in Progress, August 2004.
[PANAREQ]Yegin、A.(エド)、オオバ、Y.、ペンノ、R.、Tsirtsis(G.、およびC.ワング)は「ネットワークアクセス(パーナ)要件と用語のための認証を運ぶために議定書を作ります」、処理中の作業、2004年8月。
[EAP-KEY] Aboba, B., et al., "EAP keying framework", Work in
Progress.
[EAP-KEY] Aboba、B.、他、「フレームワークを合わせるEAP」、ProgressのWork。
[RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote
Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)", RFC 3579,
September 2003.
[rad-EAP] Aboba、B.とP.カルフーン、「拡張認証プロトコル(EAP)の半径(ユーザサービスにおけるリモート認証ダイヤル)サポート」RFC3579(2003年9月)。
[TUN-EAP] Puthenkulam, J., et al., "The compound authentication
binding problem", Work in Progress.
[TUN-EAP] Puthenkulam、J.、他、「合成認証結合問題」、ProgressのWork。
[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March
2005.
[発信します] Arkko、J.、エド、ケンフ、J.、Zill、B.、およびP.Nikander、「安全な隣人発見(発信する)」、RFC3971、3月2005日
11. Acknowledgements
11. 承認
The author would like to thank the following people (in no specific order) for providing valuable comments: Alper Yegin, Basavaraj Patil, Pekka Nikander, Bernard Aboba, Francis Dupont, Michael Thomas, Yoshihiro Ohba, Gabriel Montenegro, Tschofenig Hannes, Bill Sommerfeld, N. Asokan, Pete McCan, Derek Atkins, and Thomas Narten.
作者は貴重なコメントを提供して頂いて、以下の人々(特定のオーダーでないのにおける)に感謝したがっています: Alper Yegin、Basavarajパティル、ペッカNikander、バーナードAboba、フランシス・デュポン、マイケル・トーマス、芳広オオバ、ガブリエル・モンテネグロ、Tschofenigハンネス、ビル・ゾンマーフェルト、N.Asokan、ピートMcCan、デリック・アトキンス、およびトーマスNarten。
Author's Address
作者のアドレス
Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA-94303
モハンパルタサラティノキア313フェアチャイルド・Driveマウンテンビュー、カリフォルニア-94303
EMail: mohanp@sbcglobal.net
メール: mohanp@sbcglobal.net
Parthasarathy Informational [Page 14] RFC 4016 PANA Threat Analysis March 2005
2005年の[14ページ]RFC4016パーナの脅威分析行進の情報のパルタサラティ
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機能のための基金は現在、インターネット協会によって提供されます。
Parthasarathy Informational [Page 15]
パルタサラティInformationalです。[15ページ]
一覧
スポンサーリンク
