Network Working Group S. Kelly
Request for Comments: 5418 Aruba Networks
Category: Informational T. Clancy
LTS
March 2009
Control And Provisioning of Wireless Access Points (CAPWAP)
Threat Analysis for IEEE 802.11 Deployments
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP), which serves as a stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments.
初期の無線ローカルエリアネットワーク（WLAN）の展開は、有線および無線ネットワークセグメント間のスタンドアロンインターフェースとして機能する「脂肪」アクセスポイント（AP）を備えています。しかし、このモデルは拡大縮小、移動性、および管理性の問題を提起し、ワイヤレスアクセスポイント（CAPWAP）プロトコルの制御およびプロビジョニングは、これらの問題に対処するためのものです。 CAPWAPを効果2つのネットワーク要素に脂肪APの機能を分割し、これらのコンポーネント間の通信チャネルは、潜在的に敵対的なホップを横断することができます。この文書では、CAPWAPを導入したセキュリティリスクを分析し、IEEE 802.11ベースのCAPWAPの実装と展開に関連するセキュリティ上の考慮事項をまとめたもの。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Rationale for Limiting Analysis Scope to IEEE 802.11 .......5
1.2. Notations ..................................................6
2. Abbreviations and Definitions ...................................7
3. CAPWAP Security Goals for IEEE 802.11 Deployments ...............8
4. Overview of IEEE 802.11 and AAA Security ........................8
4.1. IEEE 802.11 Authentication and AAA .........................9
4.2. IEEE 802.11 Link Security .................................11
4.3. AAA Security ..............................................11
4.4. Cryptographic Bindings ....................................12
5. Structure of the Analysis ......................................13
6. Representative CAPWAP Deployment Scenarios .....................14
6.1. Preliminary Definitions ...................................14
6.1.1. Split MAC ..........................................15
6.1.2. Local MAC ..........................................15
6.1.3. Remote MAC .........................................15
6.1.4. Data Tunneling .....................................16
6.2. Example Scenarios .........................................16
6.2.1. Localized Modular Deployment .......................16
6.2.2. Internet Hotspot or Temporary Network ..............17
6.2.3. Distributed Deployments ............................18
6.2.3.1. Large Physically Contained Organization ...18
6.2.3.2. Campus Deployments ........................18
6.2.3.3. Branch Offices ............................18
6.2.3.4. Telecommuter or Remote Office .............19
7. General Adversary Capabilities .................................19
7.1. Passive versus Active Adversaries .........................20
8. Vulnerabilities Introduced by CAPWAP ...........................22
8.1. The Session Establishment Phase ...........................22
8.1.1. The Discovery Phase ................................22
8.1.2. Forming an Association (Joining) ...................23
8.2. The Connected Phase .......................................23
9. Adversary Goals in CAPWAP ......................................24
9.1. Eavesdrop on AC-WTP Traffic ...............................24
9.2. WTP Impersonation and/or Rootkit Installation .............25
9.3. AC Impersonation and/or Rootkit Installation ..............26
9.4. Other Goals or Sub-Goals ..................................26
10. Countermeasures and Their Effects .............................27
10.1. Communications Security Elements .........................27
10.1.1. Mutual Authentication .............................27
10.1.1.1. Authorization ............................27
10.1.2. Data Origin Authentication ........................29
10.1.3. Data Integrity Verification .......................29
10.1.4. Anti-Replay .......................................29
10.1.5. Confidentiality ...................................29
10.2. Putting the Elements Together ............................30
10.2.1. Control Channel Security ..........................30
10.2.2. Data Channel Security .............................30
11. Countermeasures Provided by DTLS ..............................30
12. Issues Not Addressed By DTLS ..................................31
12.1. DoS Attacks ..............................................31
12.2. Passive Monitoring (Sniffing) ............................32
12.3. Traffic Analysis .........................................32
12.4. Active MitM Interference .................................32
12.5. Other Active Attacks .....................................32
13. Security Considerations .......................................32
14. Acknowledgements ..............................................32
15. References ....................................................33
15.1. Normative References .....................................33
15.2. Informative References ...................................33
Wireless Local Area Network (WLAN) deployments are increasingly common as the technology matures and wireless interface chips become standard equipment in laptops and various hand-held computing devices. In the simplest deployments, WLAN access is entirely provided by a wireless Access Point (AP), which bridges the client system (station or "STA") and the Distribution System (DS) or wired network.
技術が成熟するにつれてワイヤレスローカルエリアネットワーク（WLAN）の展開はますます一般的であり、無線インタフェースチップは、ノートPCや、さまざまなハンドヘルドコンピューティングデバイスに標準装備となります。最も単純な展開では、WLANアクセスは完全にクライアント・システム（ステーションまたは「STA」）と配布システム（DS）または有線ネットワークをブリッジする無線アクセスポイント（AP）、によって提供されます。
+------+
|client| +--------+ |
|(STA) | | Access | | +------+
+------+ ) ) ) ) | Point |-----| /optional\ +-------+
/ / +--------+ |--( L3 )---| AAA |
+------+ | \ cloud / +-------+
| +------+
Figure 1: IEEE 802.11 Deployment Using RSN
図1：RSNを使用したIEEE 802.11の展開
In this architecture, the AP serves as a gatekeeper, facilitating client access to the network. Typically, the client must somehow authenticate prior to being granted access, and in enterprise deployments, this is frequently accomplished using [8021X]. When using IEEE 802.11, this mode is called a Robust Security Network (RSN) [80211I]. Here, the client is called the "supplicant", the AP is the "authenticator", and either the AP or an external Authentication, Authorization, and Accounting (AAA) server fulfill the role of "authentication server", depending on the authentication mechanism used.
このアーキテクチャでは、APはクライアントにネットワークへのアクセスを容易にする、ゲートキーパーとして役立ちます。一般的に、クライアントは何とかアクセス権が付与される前に認証する必要があり、エンタープライズ展開で、これは頻繁に[8021X]を使用して達成されます。 IEEE 802.11を使用する場合は、このモードでは、堅牢なセキュリティネットワーク（RSN）[80211I]と呼ばれています。ここでは、クライアントは「サプリカント」と呼ばれ、APは「オーセンティケータ」で、APまたは外部認証のいずれか、認可、アカウンティング（AAA）サーバが認証機構に応じて、「認証サーバ」の役割を果たし中古。
From the perspective of the network administrator, the wired LAN to which the AP is attached is typically considered to be more trusted than the wireless LAN, either because there is some physical boundary around the wired segment (i.e., the building walls), or because it is otherwise secured somehow (perhaps cryptographically). The AAA server may reside within this same physical administrative domain, or it may be remote. Common AAA protocols are RADIUS [RFC3579] and Diameter [RFC4072].
ネットワーク管理者の観点から、APが接続されている有線LANは、典型的には、無線LANよりも信頼できると考えられる、いずれかの有線セグメント（すなわち、建物の壁）の周りにいくつかの物理的境界が存在するため、又はためそれは、そうでない場合は（おそらく、暗号）何とか確保されています。 AAAサーバは、同じ物理的管理ドメイン内に存在してもよく、またはそれは離れていてもよいです。一般的なAAAプロトコルはRADIUS [RFC3579]とDiameter [RFC4072]です。
The CAPWAP protocol [RFC5415] modifies this architecture by splitting the AP into two pieces, the Wireless Termination Point (WTP), and the Access Controller (AC), and creating a communications link between the two new components. In this model, the WTP implements the WLAN edge functions with respect to the user (wireless transmit/receive), while the AC implements the wired-side edge functions. For a complete description of CAPWAP architecture, see [RFC4118].
CAPWAPプロトコル[RFC5415]は二枚、ワイヤレス終端ポイント（WTP）、及びアクセスコントローラ（AC）にAPを分割し、2つの新たなコンポーネント間の通信リンクを作成することによって、このアーキテクチャを変更します。 ACは、有線側エッジ機能を実現しながら、このモデルでは、WTPは、ユーザ（無線送信/受信）に対してWLANエッジ機能を実現します。 CAPWAPアーキテクチャの詳細については、[RFC4118]を参照してください。
+------+ +==========================+
|client| | +---+ | | +------+
|(STA) | | +-----+ / L3 \ +----+ | | /optional\ +-----+
+------+ ) )|)| WTP |-( cloud )-| AC |-|---|--( L3 )--| AAA |
/ / | +-----+ \ / +----+ | | \ cloud / +-----+
+------+ | +---+ | | +------+
+==========================+
AP equivalence boundary
Figure 2: WLAN Deployment utilizing CAPWAP
図2：CAPWAPを利用WLAN展開
For our purposes, it is useful to think of the entire CAPWAP system as a sort of "AP equivalent", and the figure above illustrates this concept. With this model in mind, our ideal is to ensure that CAPWAP introduces no vulnerabilities that aren't present in the original fat AP scenario. As we will see, this is not entirely possible, but from a security perspective, we should nonetheless strive to achieve this equivalence as nearly as we can.
私たちの目的のためには、「AP相当」の一種として、全体のCAPWAPシステムを考えるために有用であり、上記の図は、この概念を示しています。念頭に置いて、このモデルでは、私たちの理想は、CAPWAPは、元の脂肪APシナリオに存在しない全くの脆弱性を導入していないことを確認することです。私たちが見るように、これは完全に可能ではありませんが、セキュリティの観点から、我々はそれにもかかわらずとほぼたちができるように、この等価性を達成するために努力すべきです。
Although CAPWAP derives from protocols that were designed explicitly for management of IEEE 802.11 wireless LANs, it may also turn out to be useful for managing other types of network device deployments, wireless and otherwise. This might lead one to conclude that a single security analysis, except for minor per-binding variations, might be sufficient. However, based on a limited number of additional related scenarios that have been described as likely candidates for CAPWAP thus far, e.g., use with Radio Frequency Identification (RFID) sensors, this does not seem to be a simple, binary decision.
CAPWAPは、IEEE 802.11無線LANの管理のために明示的に設計されたプロトコルから派生しますが、それはまた、ネットワークデバイスの展開の他のタイプを管理するための便利な無線およびそれ以外になるかもしれません。これは、単一のセキュリティ分析と結論するの1を導くかもしれない、マイナーあたりの結合のバリエーションを除いて、十分かもしれません。しかしながら、例えば、無線周波数識別（RFID）センサを使用し、これまでCAPWAPための有望な候補として記載されている追加の関連シナリオの限定された数に基づいて、これは、単純な、二分決定であるとは思われません。
Contrasting RFID and IEEE 802.11 deployment scenarios, IEEE 802.11 users typically authenticate to some a back-end AAA server, and as a result of that exchange, derive cryptographic keys that are used by the STA and WTP to encrypt and authenticate over-air communications. That is, the threat environment is such that the following typically holds:
対照的なRFIDとIEEE 802.11の展開シナリオは、IEEE 802.11のユーザは、典型的には、いくつかのバックエンドAAAサーバに認証し、その交換の結果として、暗号化および過空気通信を認証するためにSTAとWTPによって使用される暗号鍵を導出します。それは、脅威環境は以下が一般的に成り立つようになっている、次のとおりです。
o The user is not immediately trusted, and therefore must authenticate.
Oユーザーはすぐに信頼されていないので、認証する必要があります。
o The WTP is not immediately trusted, and therefore must indirectly authenticate to the user via the AAA server.
oをWTPはすぐに信頼されていないので、間接的にAAAサーバを介してユーザに認証する必要があります。
o The AAA server is not necessarily trusted, and therefore must authenticate.
O AAAサーバは、必ずしも信頼されていないので、認証する必要があります。
o The medium is not trusted, and therefore communications must be secured.
O媒体が信頼されていないので、通信が確保されなければなりません。
RFID tags, on the other hand, typically do not have the same authentication, confidentiality, and integrity requirements as the principals in a WLAN deployment, and are not, generally speaking, well suited to environments in which similar threats exist. As a result of the combination of WLAN security requirements and the Medium Access Control (MAC)-splitting behavior that epitomizes the IEEE 802.11 binding for CAPWAP, there are definite security-related considerations in the WLAN case that simply do not exist for an RFID-based adaptation of CAPWAP.
RFIDタグは、他の一方で、一般的にWLAN展開のプリンシパルと同じ認証、機密性、および整合性の要件を持っていない、と一般的に同様の脅威が存在する環境に適し、話す、ではありません。 WLANセキュリティ要件とCAPWAPのバインディングIEEE 802.11を具現化する媒体アクセス制御（MAC）-splitting行動の組み合わせの結果として、単にRFID-のために存在していないWLANの場合、明確なセキュリティ関連の考慮事項がありますCAPWAPのベースの適応。
Now, there certainly are similarities and overlapping security considerations that will apply to any CAPWAP deployment scenario. For example, authentication of the AC for purposes of WTP device management operations is probably always important. Even so, the threats to RFID are different enough to suggest the need for a separate security analysis in that case. For example, since RFID tags commonly deployed today implement no over-air authentication, integrity, or confidentiality mechanisms, the need for similar mechanisms between the WTP and AC for RFID tag data communications is not clearly indicated -- that is, the threats are different.
今、確かに任意のCAPWAPの展開シナリオに適用されます類似点と重複セキュリティの考慮事項があります。例えば、WTPデバイス管理業務の目的のためにACの認証は、おそらく常に重要です。そうであっても、RFIDへの脅威は、その場合の個別のセキュリティ分析の必要性を示唆するのに十分異なっています。一般的に、今日配備RFIDタグが無過空気認証、完全性、または機密性のメカニズムを実装するので、例えば、RFIDタグのデータ通信用のWTPとACとの間の同様の機構の必要性が明確に示されていない - つまり、脅威が異なっています。
We have limited visibility into the varied ways in which CAPWAP might be adapted in the future, although we may observe that it seems to provide the basis for a generalized scalable provisioning protocol. Given our currently limited view of the technologies for which it might be used, it seems prudent to recognize that our current view is colored by the IEEE 802.11 roots of the protocol, and make that recognition explicit in our analysis. If newly added bindings turn out to be substantially similar to IEEE 802.11, then the associated binding documents can simply reference this document in their security considerations, while calling out any substantive differences. However, it does appear, based on our current limited visibility, that per-binding threat analyses will be required.
我々は一般的なスケーラブルなプロビジョニングプロトコルの基礎を提供するように見えることを観察することができるが、我々は、CAPWAPは、将来的に適合させる可能性のある様々な方法の可視性が限られています。それが使用されるかもしれないための技術の私達の現在の限られたビューを考えると、私たちの現在のビューは、プロトコルのIEEE 802.11根によって着色されていることを認識し、我々の分析でその認識を明示的にするために慎重なようです。新しく追加されたバインディングはIEEE 802.11と実質的に同様であることが判明した場合は任意の実質的な違いを呼び出しながら、その後、関連する結合の文書は、単に、彼らのセキュリティの考慮事項でこの文書を参照することができます。しかし、私たちの現在の限られた可視性に基づいて、そのあたりの結合脅威が必要になります分析し、表示されません。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
o AAA - Authentication Authorization and Accounting
O AAA - 認証認可およびアカウンティング
o AC - Access Controller
O AC - アクセスコントローラ
o AES-CCMP - Advanced Encryption Standard - Counter-mode CBC MAC Protocol
O AES-CCMP - のAdvanced Encryption Standard - カウンターモードCBC MACプロトコル
o AP - (wireless) Access Point
O AP - （無線）アクセスポイント
o CAPWAP - Control And Provisioning of Wireless Access Points
O CAPWAP - ワイヤレスアクセスポイントの管理とプロビジョニング
o Cert - X509v3 Certificate
O証明書 - 書X509v3証明書
o DIAMETER - proposed successor to RADIUS protocol (see below)
O DIAMETER - RADIUSプロトコルに提案後継（下記参照）
o DoS - Denial of Service (attack)
O DoS攻撃 - サービス拒否（攻撃）
o DTLS - Datagram Transport Layer Security
O DTLS - データグラムトランスポート層セキュリティ
o EAP - Extensible Authentication Protocol
O EAP - 拡張認証プロトコル
o MitM - Man in the Middle
OのMitM - 中間者
o PMK - Pairwise Master Key
O PMK - ペアワイズマスターキー
o PSK - Pre-Shared Key
O PSK - 事前共有キー
o RADIUS - Remote Authentication Dial-In User Service
O RADIUS - リモート認証ダイヤルインユーザーサービス
o STA - (wireless) STAtion
お Ｓた ー （うぃれぇっｓ） Ｓたちおん
o TK - Transient Key
OのTK - 過渡キー
o TKIP - Temporal Key Integrity Protocol
一時的なキー統合プロトコル - TKIP O
o WEP - Wired Equivalent Privacy
OのWEP - 有線と同等のプライバシー
o WLAN - Wireless Local Area Network
OのWLAN - ワイヤレスローカルエリアネットワーク
o WTP - Wireless Termination Point
WTP O - ワイヤレスターミネーションポイント
When deployed for use with IEEE 802.11, CAPWAP should avoid introducing any system security degradation as compared to the fat AP scenario. However, by splitting the AP functions between the WTP and AC, CAPWAP places potentially sensitive protocol interactions that were previously internal to the AP onto the Layer 3 (L3) network between the AC and WTP. Therefore, the security properties of this new system are dependent on the security properties of the intervening network, as well as on the details of the split.
IEEE 802.11で使用するために展開されるとき、CAPWAP脂肪APシナリオと比較して任意のシステムセキュリティの低下を導入避けるべきです。しかし、WTPとACとの間にAP機能を分割することにより、CAPWAP場所ACとWTP間のレイヤ3（L3）ネットワークに以前にAPに内部た機密プロトコル相互作用。したがって、この新しいシステムのセキュリティ・プロパティは、介在するネットワークのセキュリティの性質に依存するだけでなく、分割の詳細について。
Since CAPWAP does not directly interact with over-air or AAA protocols, these are mostly out of scope for this analysis. That is, we do not analyze the basic AAA or IEEE 802.11 security protocols directly here, as CAPWAP does not modify these protocols in any way, nor do they directly interact with CAPWAP. However, by splitting AP functionality, CAPWAP may expose security elements of these protocols that would not otherwise be exposed. In such cases, CAPWAP should explicitly avoid degrading the security of these protocols in any way when compared to the fat AP scenario.
CAPWAPは直接過剰空気やAAAプロトコルと相互作用しないので、これらは、この分析の範囲外ほとんどです。 CAPWAPはどのような方法でこれらのプロトコルを変更しない、また彼らが直接CAPWAPと対話しないようつまり、私たちは、ここで直接、基本的なAAAまたはIEEE 802.11セキュリティプロトコルを解析しません。しかし、AP機能を分割することによって、CAPWAPは、そうでなければ露出されないこれらのプロトコルのセキュリティ要素を露出させることができます。このような場合には、CAPWAPは、明示的に脂肪APシナリオと比べてどのような方法でこれらのプロトコルのセキュリティを低下することは避けてください。
While this document is not directly concerned with IEEE 802.11 or AAA security, there are some subtle interactions introduced by CAPWAP, and there will be related terminology we must touch on in discussing these. The following figure illustrates some of the complex relationships between the various protocols, and illustrates where CAPWAP sits:
このドキュメントは、IEEE 802.11またはAAAセキュリティに直接関係はありませんが、CAPWAPにより導入されたいくつかの微妙な相互作用があり、私たちはこれらの議論に上に触れなければなりません関連の専門用語が存在します。次の図は、様々なプロトコル間の複雑な関係の一部を示しており、CAPWAPが座る場所を示しています。
+-----+ RADIUS/Diameter
| AAA |<==============\\
+-----+ ||
| ||
+-----------+------------+ ||
| | ||
+-----+ +----+ ||
| AC | | AC |<==//
+-----+ +----+
+---| |---+ +---| |---+
| | | |
| | | CAPWAP |
+-----+ +-----+ +-----+ +-----+
| WTP | | WTP | | WTP | | WTP |
+-----+ +-----+ +-----+ +-----+
^ ^^^
^^ ^^^ 802.11i,
^^ ^^ 802.1X, WPA,
+-----+ +-----+ WEP
| STA | | STA |
+-----+ +-----+
/ / / /
+-----+ +-----+
Figure 3: CAPWAP Protocol Hierarchy
図3：CAPWAPプロトコル階層
CAPWAP is being inserted between the 802.ll link security mechanism and the authentication server communication, so to provide supporting context, we give a very brief overview of IEEE 802.11 and AAA security below. It is very important to note that we only cover those topics that are relevant to our discussion, so what follows is not by any means exhaustive. For more detailed coverage of IEEE 802.11-related security topics, see e.g., [80211SEC].
CAPWAPは、私たちは以下のIEEE 802.11およびAAAセキュリティの非常に簡単な概要を与え、支援するコンテキストを提供するために、802.llリンクセキュリティ・メカニズムと認証サーバ間の通信の間に挿入されています。我々が唯一の私たちの議論に関連しているこれらのトピックをカバーすることに注意することが非常に重要であるので、以下は、いかなる手段によっても網羅しているわけではありません。 IEEE 802.11に関連するセキュリティトピックの詳細なカバレッジのために、[80211SEC]、例えば参照。
IEEE 802.11 provides for multiple methods of authentication prior to granting access to the network. In the simplest case, open authentication is used, and this is equivalent to no authentication. However, if IEEE 802.11 link security is to be provided, then some sort of authentication is required in order to bootstrap the trust relationship that underlies the associated key establishment process.
IEEE 802.11は、ネットワークへのアクセスを許可する前に、複数の認証方法を提供します。最も単純なケースでは、オープン認証が使用され、これは認証なしに相当します。 IEEE 802.11リンクのセキュリティが提供される場合は、その後、認証のいくつかの並べ替えは、関連する鍵確立プロセスの基礎となる信頼関係をブートストラップするために必要とされます。
This authentication can be implemented through use of a shared secret. In such cases, the authentication may be implicitly tied to the link security mechanism, (e.g., when Wired Equivalent Privacy (WEP) is used with open authentication), or it may be explicit, e.g., when Wi-fi Protected Access is used with a Pre-Shared Key (WPA-PSK).
この認証は、共有秘密鍵を使用して実装することができます。 Wi-Fiの保護アクセスが一緒に使用されたときにそのような場合には、例えば、認証が暗黙的に（例えば、有線同等プライバシー（WEP）は、オープン認証で使用されている場合）、リンクのセキュリティ・メカニズムに接続することができ、またはそれは、明示的であり事前共有キー（WPA-PSK）。
In other cases, authentication requires an explicit cryptographic exchange, and this operation bootstraps link security. In most such cases, IEEE 802.1X is used in conjunction with the Extensible Authentication Protocol [RFC3748] to authenticate either the client or both the client and the authentication server. This exchange produces cryptographic keying material for use with IEEE 802.11 security mechanisms.
他の例では、認証は、明示的な暗号の交換を必要とし、この操作のブートストラップは、セキュリティをリンクします。ほとんどのこのような場合には、IEEE 802.1Xは、クライアントのいずれかまたは両方のクライアントおよび認証サーバを認証するために拡張認証プロトコル[RFC3748]と組み合わせて使用されます。この交換はIEEE 802.11セキュリティメカニズムで使用する暗号化キーイングマテリアルを生成します。
The resulting trust relationships are complex, as can be seen from the following (simplified) figure:
下記（簡体字）の図から分かるように、得られた信頼関係は、複雑です。
/--------------------------------------------\
| TK (6) | EAP Credentials,
V /--------------\ | PMK (3)
+------+ | PSK/Cert(1) | |
|client| V | V
|(STA) | +--------+ | v | +-----+
+------+ ) ) ) ) | WTP |-----| +----+ |--| AAA |
/ / +--------+ |--| AC |--| +-----+
+------+ ^ | +----+ | ^
^ ^ | ^ ^ (2,4) |
| | PTK (7) | | \----------/
| \----------------/ | Radius PSK,
\-----------------------------------/ PMK
4-Way Handshake (w/PMK) (5)
Figure 4: Trust Relationships
図4：信頼関係
The following describes each of the relationships:
以下は、関係の各について説明します。
5. AC and STA conduct 4-way handshake (producing TK, among other keys)
5. AC及びSTA行為4ウェイハンドシェイク（製造TK、他のキーのうち）
The current CAPWAP binding for IEEE 802.11 primarily supports the use of IEEE 802.11i [80211I] security on the wireless link. However, since IEEE 802.11i does not prohibit the use of WEP for link security, neither does CAPWAP. Nonetheless, use of WEP with CAPWAP is NOT RECOMMENDED.
現在のCAPWAP IEEE 802.11のための結合は、主に無線リンク上のIEEE 802.11i規格[80211I]セキュリティの使用をサポートしています。 IEEE 802.11i規格は、リンクのセキュリティのためのWEPの使用を禁止していないので、どちらもCAPWAPは行いません。それにもかかわらず、CAPWAPとWEPの使用が推奨されていません。
If WEP is used with CAPWAP, the CAPWAP system will inherit all the security problems associated with the use of WEP in any wireless network. In particular, 40-bit keys can be subject to brute-force attacks, and statistical attacks can be used to crack session keys of any length after enough packets have been collected [WEPSEC]. As of late 2008, such attacks are trivial, and take mere seconds to accomplish.
WEPはCAPWAPで使用されている場合は、CAPWAPシステムは、任意の無線ネットワークでWEPの使用に関連するすべてのセキュリティ問題を継承します。具体的には、40ビットの鍵は、ブルートフォース攻撃を受けることができ、十分なパケットが[WEPSEC]収集された後、統計的攻撃は、任意の長さのセッションキーを解読するために使用することができます。 2008年後半のように、このような攻撃は簡単であり、達成するための単なる秒かかります。
Newer link security mechanisms described in IEEE 802.11i, including TKIP and AES-CCMP, significantly improve the security of wireless networks. It is strongly RECOMMENDED that CAPWAP only be used with these newer techniques.
TKIPとAES-CCMPを含むIEEE 802.11i規格に記載され、新しいリンクのセキュリティメカニズムは、大幅にワイヤレスネットワークのセキュリティを向上させます。強くCAPWAPのみがこれらの新しい技術を用いて使用することをお勧めします。
The only slight insecurity introduced by CAPWAP when using it with IEEE 802.11i is the handling of the KeyRSC counter. When performing decentralized encryption, this value is maintained by the WTP, but needed by the AC to perform the 4-way handshake. The value used during the handshake initializes the counter on the client. In CAPWAP, this value is initialized to zero, allowing the possibility for replay attacks of broadcast traffic in the window between initial authentication and the client receiving the first valid broadcast packet from the WTP. This slight window of attack has been documented in [RFC5416].
IEEE 802.11i規格でそれを使用するときにCAPWAPにより導入されたわずかな不安はKeyRSCカウンタの扱いです。分散型の暗号化を行う場合、この値はWTPによって維持するが、4ウェイハンドシェイクを実行するためにACによって必要とされます。ハンドシェーク中に使用される値は、クライアント上のカウンタを初期化します。 CAPWAPでは、この値はWTPからの最初の有効なブロードキャストパケットを受信した初期認証とクライアント間のウィンドウ内のブロードキャストトラフィックのリプレイ攻撃の可能性をできるように、ゼロに初期化されます。攻撃のこのわずかなウィンドウには、[RFC5416]で文書化されています。
CAPWAP has very little control over how AAA security is deployed, as it's not directly bound to AAA as it is to IEEE 802.11. As a result, CAPWAP can only provide guidance on how to best secure the AAA portions of a CAPWAP-enabled wireless network.
それはIEEE 802.11にあるとして、それが直接AAAにバインドされていないようCAPWAPは、AAAセキュリティが配備されている方法で非常にほとんど制御を持っています。その結果、CAPWAPは唯一の最高のCAPWAP対応のワイヤレスネットワークのAAA部分を保護する方法に関するガイダンスを提供することができます。
The AAA protocol is a term that refers to use of either RADIUS [RFC3579] or Diameter [RFC4072] to transport EAP communications between the authenticator and the AAA server. Here the authenticator is the AC, thus the AAA protocol secures the link between the AC and AAA server. Use of non-unique or low-entropy long-term credentials to secure the AC-AAA link can severely impact the overall security of a CAPWAP deployment, and consequently is NOT RECOMMENDED. Each AC should have a mutually authenticated link that provides robust data confidentiality and integrity. The AAA protocols and keys used SHOULD be consistent with the guidance in [RFC4962].
AAAプロトコルは、オーセンティケータとAAAサーバの間でEAP通信を輸送するためにRADIUS [RFC3579]または直径[RFC4072]のいずれかの使用を指す用語です。ここで、オーセンティケータは、このようにAAAプロトコルは、ACとAAAサーバとの間のリンクを確保し、ACです。 AC-AAAのリンクを確保するための非一意または低エントロピー長期の資格情報の使用は厳しくCAPWAP展開の全体的なセキュリティに影響を与えることができ、結果的にはお勧めしません。各ACは、堅牢なデータの機密性と完全性を提供し、相互認証されたリンクを持っている必要があります。使用されるAAAプロトコルとキーは、[RFC4962]のガイダンスと一貫しているべきです。
Since CAPWAP does not directly interact with AAA, it does not affect the overall security of a AAA network. In fact, by decreasing the number of devices that communicate with the AAA server, we can actually decrease its exposure and risk of attack.
CAPWAPは、直接AAAと相互作用しないので、それはAAAネットワーク全体のセキュリティに影響を与えません。実際には、AAAサーバと通信するデバイスの数を減少させることによって、私たちは、実際にその暴露と攻撃のリスクを減らすことができます。
One key shortcoming of both the EAP and AAA models is that they are inherently two-party models. In CAPWAP deployments, we rely on a variety of security associations when an IEEE 802.11 WLAN client session is established. These include:
EAPとAAAモデルの両方の一つの重要な欠点は、本質的に二者モデルであるということです。 IEEE 802.11 WLANクライアントセッションが確立されると、CAPWAPの展開では、我々は、セキュリティアソシエーションのさまざまなに依存しています。これらは、次のとおりです。
o WTP-AC (CAPWAP Authentication)
O WTP-AC（CAPWAP認証）
o AC-AAA (AAA Authentication)
ああ、10月-乳母（ベビーシッターanthentikesan）
o STA-AAA (EAP Method Execution)
O STA-AAA（EAPメソッド実行）
o STA-AC (AAA pushes keys to AC)
STA-DP（AAAどのように多くのキッシュNE）
o STA-WTP (AC pushes keys to WTP)
STA-WTP O（ACはWTPにキーを押します）
Each of these security associations involve a pairwise trust relationship, and none result from a multi-party key agreement protocol such as Kerberos. In particular, just because an STA trusts a AAA server who trusts an AC who trusts a WTP doesn't necessarily mean that the STA should trust the WTP. The WTP may be compromised and using his credentials to maintain a trust relationship with an AC, while advertising false information about the network to an STA.
これらのセキュリティアソシエーションのそれぞれは、Kerberosなどのマルチパーティ鍵合意プロトコルからペアごとの信頼関係、およびなしの結果を伴います。具体的には、理由だけでSTAは必ずしもSTAは、WTPを信用すべきであるという意味ではありませんWTPを信頼ACを信頼AAAサーバを信頼します。 STAにネットワークに関する虚偽の情報を宣伝しながら、WTPは、ACとの信頼関係を維持するために彼の資格情報を使用して危険にさらされてもよいです。
Protection against attacks like these can be very difficult, while maintaining scalable trust relationships with other entities in the network. Since multiple protocols are being used, multi-party keying to derive end-to-end trust relationships is infeasible.
ネットワーク内の他のエンティティとのスケーラブルな信頼関係を維持しながら、このような攻撃に対する保護は、非常に困難な場合があります。複数のプロトコルが使用されているので、エンドツーエンドの信頼関係を導出するキーイング、マルチパーティが実行不可能です。
Since CAPWAP is a collection of pairwise trust relationships, in order to claim CAPWAP is secure, we must believe in the transitivity of these trust relationships. Its hierarchal nature mitigates the domino effect, but any compromised device in the hierarchy can affect those below it in the hierarchy.
CAPWAPはペアごとの信頼関係の集まりですので、CAPWAPが安全であると主張するために、我々はこれらの信頼関係の推移を信じなければなりません。その階層的性質は、ドミノ効果を軽減するが、階層内の任意の妥協のデバイスは、階層内でその下にそれらに影響を与えることができます。
In order to conduct a comprehensive threat analysis, there are some basic questions we must answer:
総合的な脅威分析を行うために、我々は答えなければならないいくつかの基本的な質問があります。
o Exactly what are we trying to protect?
Oまさに私たちが保護しようとしていますか？
o What are the risks?
Oリスクは何ですか？
* What are the capabilities of would-be attackers?
*-だろう攻撃の機能は何ですか？
* What might be goals of would-be attackers?
*-だろう攻撃の目標かもしれませんか？
* What are the vulnerabilities or conditions they might attempt to exploit?
*彼らは活用しようとするかもしれない脆弱性や条件は何ですか？
* For various attackers, what is the likelihood of attempting to exploit a given vulnerability given the cost of the exploit versus the value of attack?
*様々な攻撃について、攻撃の値に対するエクスプロイトのコスト与えられている特定の脆弱性を悪用しようとする可能性は何ですか？
o What potential mitigation strategies are available to us?
Oどのような潜在的な緩和策は、私たちにありますか？
o What kinds of trade-offs do these mitigation strategies offer, and do they introduce any new risks?
Oトレードオフのどのようなこれらの緩和策は提供していますか、そして、彼らは新たなリスクを紹介していますか？
This is a very simplistic overview of what we must accomplish below, but it should give some insight into the manner in which the discussion proceeds.
これは、我々は以下を達成しなければならないものの非常に単純化した概要ですが、それは形で議論が進むいくつかの洞察を与える必要があります。
As a preliminary, we describe some representative CAPWAP deployment scenarios. This helps to frame subsequent discussion, so that we better understand what we are trying to protect. Following this, we describe a threat model in terms of adversary capabilities, vulnerabilities introduced by the CAPWAP functionality split, and a representative sampling of adversary goals. Note that we do not spend a lot of time speculating about specific attackers here, as this is a very general analysis, and there are many different circumstances under which a WLAN might be deployed.
予備として、我々はいくつかの代表的なCAPWAPの展開シナリオについて説明します。これは、私たちはより良い私たちが保護しようとしているかを理解するように、その後の議論をフレームに役立ちます。これに続いて、我々は敵の能力、CAPWAPの機能分割によって導入された脆弱性の面で脅威モデル、および敵目標の代表サンプリングを説明します。これは非常に一般的な分析であると私たちは、ここで特定の攻撃についての推測に多くの時間を費やしていないことに注意してください、とWLANが展開されるかもしれないの下で、多くの異なる状況があります。
Following the development of the general threat model, we describe appropriate countermeasures, and discuss how these are implemented through various means within the CAPWAP protocol. Finally, we discuss those issues that are not (or cannot be) completely addressed, and we give recommendations for mitigating the resulting exposure.
一般的な脅威モデルの開発に続いて、我々は適切な対策を説明し、これらはCAPWAPプロトコル内の様々な手段を介して実装されている方法について説明します。最後に、我々は完全に対処されていない（またはすることはできません）これらの問題を議論し、我々は結果のエクスポージャーを軽減するための勧告を与えます。
In this section, we describe some representative CAPWAP deployment scenarios, and in particular, those scenarios that have been taken into consideration for the current CAPWAP protocol security design. For clarity, we first provide some preliminary definitions, along with descriptions of common deployment configurations that span multiple scenarios. Following this is a sampling of individual deployment scenarios.
このセクションでは、我々はいくつかの代表的なCAPWAPの展開シナリオ、および現在のCAPWAPプロトコルのセキュリティ設計のために考慮されている具体的には、これらのシナリオについて説明します。明確にするために、我々は最初に複数のシナリオにまたがる一般的な展開構成の説明と一緒に、いくつかの予備的な定義を提供します。続いて、これは、個々の展開シナリオのサンプリングです。
The IEEE 802.11 standard describes several frame types, and variations in WLAN architectures dictate where these frame types originate and/or terminate (i.e., at the WTP or AC). There are three basic IEEE 802.11 frame types currently defined:
IEEE 802.11規格は、いくつかのフレームタイプを記述し、これらのフレームタイプ（すなわち、WTPまたはACで）発信および/または終了ここでWLANアーキテクチャのばらつきが決定します。現在定義されている三つの基本的なIEEE 802.11フレームの種類があります。
o Control: These are for managing the transmission medium (i.e., the airwaves). Examples include RTS, CTS, ACK, PS-POLL, CF-POLL, CF-END, and CF-ACK.
O制御：これらは、伝送媒体（すなわち、電波）を管理するためのものです。例としては、RTS、CTS、ACK、PS-POLL、CF-POLL、CF-END、およびCF-ACKが含まれます。
o Management: These are for managing access to the logical network, as opposed to the physical medium. Example functions include association/disassociation, reassociation, deauthentication, Beacons, and Probes.
O管理：物理媒体とは対照的に、これらは、論理ネットワークへのアクセスを管理するためのものです。例関数は結合/解離、再結合、認証解除、ビーコンおよびプローブを含みます。
o Data: Transit data (network packets).
Oデータ：トランジットデータ（ネットワークパケット）。
There are a number of other services provided by the WLAN infrastructure, including these:
これらを含むWLANインフラストラクチャが提供する他のサービスの数があります。
o Packet distribution
Oパケット振分
o Synchronization
O同期
o Retransmissions
O再送
o Transmission Rate Adaptation
O伝送レートアダプテーション
o Privacy/Confidentiality/Integrity (e.g., IEEE 802.11i)
Oプライバシー/機密性/完全性（例えば、IEEE 802.11i規格の）
The manner in which these (and other) services are divided among the AC and WTP is collectively referred to in terms of "MAC-splitting" characteristics. We briefly describe various forms of MAC-splitting below. For further detail, see [RFC5415] and [RFC5416].
これらの（および他の）サービスは、ACとWTPの間で分割される方法を総称して「MAC-分割」特性の用語で呼ばれています。当社は、以下に簡単にMAC-分裂の様々な形態を説明します。さらに詳しくは、[RFC5415]及び[RFC5416]を参照。
Split MAC scenarios are characterized by the fact that some IEEE 802.11 MAC messages are processed by the WTP, while some are processed by the AC. For example, a Split MAC implementation might divide IEEE 802.11 frame processing as follows:
スプリットMACのシナリオは、いくつかは、ACによって処理されている間、いくつかのIEEE 802.11 MACメッセージは、WTPによって処理されていることを特徴としています。例えば以下のように、スプリットMAC実装は、IEEE 802.11フレーム処理を分割することがあります。
WTP
WTP
* Beacons
*ビーコン
* Probes
*プローブ
* RTS, CTS, ACK, PS-POLL, CF-POLL,CF-END, CF-ACK
* RTS、CTS、ACK、PS-POLL、CF-POLL、CF-END、CF-ACK
AC
AM
* Association/Reassociation/Disassociation
*協会/再アソシエーション/ディスアソシエーション
* Authentication/Deauthentication
*認証/認証解除
* Key Management
*キー管理
* IEEE 802.11 Link Security (WEP, TKIP, IEEE 802.11i)
* IEEE 802.11リンクセキュリティ（WEP、TKIP、IEEE 802.11i規格）
The Split MAC model is not confined to any one particular deployment scenario, as we'll see below, and vendors have considerable leeway in choosing how to distribute the IEEE 802.11 functionality.
私たちは以下を参照してくださいますよう、スプリットMACモデルは、いずれか1つの特定の展開シナリオに限定されず、ベンダーはIEEE 802.11機能を分配する方法を選択する際にかなりの余裕を持っています。
Local MAC scenarios are characterized by the fact that most IEEE 802.11 MAC messages are processed by the WTP. Some IEE 802.11 MAC frames must be forwarded to the AC (i.e., IEEE 802.11 Association Request frames), but in general, the WTP manages the MAC interactions. Data frames may also be forwarded to the AC, but are generally bridged locally.
ローカルMACシナリオが最もIEEE 802.11 MACメッセージは、WTPによって処理されていることを特徴としています。いくつかのIEE 802.11 MACフレームは、AC（すなわち、IEEE 802.11アソシエーション要求フレーム）に転送する必要がありますが、一般的には、WTPは、MAC相互作用を管理します。データフレームはまた、ACに転送することができるが、一般的にローカルにブリッジされています。
Remote MAC scenarios are characterized by the fact that all IEEE 802.11 MAC messages are forwarded to the AC. The WTP does not process any of these locally. This model supports very lightweight WTPs that need be little more than smart antennas. While Remote MAC scenarios are not addressed by the current IEEE 802.11 protocol binding for CAPWAP, the description is included here for completeness.
リモートMACのシナリオは、すべてのIEEE 802.11 MACメッセージがACに転送されていることを特徴としています。 WTPは、ローカルにこれらのいずれかを処理しません。このモデルは、スマートアンテナよりも少しである必要は非常に軽量WTPsをサポートしています。リモートMACのシナリオはCAPWAPのバインディング現在のIEEE 802.11プロトコルによって対処されていませんが、説明は完全を期すためにここに含まれています。
Regardless of the approach to MAC splitting, there is also the matter of where user data packets are translated between wired and wireless frame formats, i.e., where the bridging function occurs. In some cases, user data frames are tunneled back to the AC, and in others, they are locally bridged by the WTP. While one might expect Remote MAC implementations to always tunnel data packets back to the AC, for Local and Split MAC modes the decision is not so clear. Also, it's important to note that there are no rules or standards in place that rigidly define these terms and associated handling. Data tunneling is further discussed for each scenario below.
かかわらず、MAC分割へのアプローチの、ブリッジ機能が生じる、すなわち、ユーザ・データ・パケットは、有線および無線フレームフォーマット間翻訳される場合の問題もあります。いくつかのケースでは、ユーザデータフレームはバックACにトンネリングされ、そして他の人に、彼らはローカルでWTPによってブリッジされています。 1が戻ってACに常にトンネルのデータパケットにリモートMACの実装を期待するかもしれませんが、ローカルおよびスプリットMACのための決定はそれほど明確ではないモードがあります。また、それは厳格にこれらの用語と関連する処理を定義場所にはルールや基準が存在しないことに注意することが重要です。データ・トンネリングは、さらに以下の各シナリオに関して説明されています。
In this section, we describe a number of example deployment scenarios. This is not meant to be an exhaustive enumeration; rather, it is intended to give a general sense of how WLANs currently are or may be deployed. This will provide important context when we discuss adversaries and threats in subsequent sections below.
このセクションでは、例の展開シナリオの数を記述する。これは、網羅的な列挙であることを意味していません。むしろ、WLANは現在または展開されることができるかの一般的な意味を与えることを目的としています。私たちは、以下の後のセクションで敵と脅威を議論するとき、これは重要なコンテキストを提供します。
The localized modular model describes a WLAN that is deployed within a single domain of control, typically within either a single building or some otherwise physically contained area. This would be typical of a small to medium-sized organization. In general, the LAN enjoys some sort of physical security (e.g., it's within the confines of a building for which access is somehow limited), although the actual level of physical security is often far less than is assumed.
ローカライズされたモジュラーモデルは、典型的には、単一の建物またはいくつかそうでなければ物理的に含まれている領域のいずれかの内に、制御の単一ドメイン内に配置されているWLANを記載しています。これは、中規模の組織に小さなの典型的です。物理的なセキュリティの実際のレベルは、多くの場合、想定されるよりもはるかに少ないですが、一般的には、LANは、物理的なセキュリティのいくつかの並べ替えを（例えば、それはアクセスが何らかの形で制限されている建物の範囲内です）楽しんでいます。
In such deployments, the WLAN is typically an extension of a wired LAN. However, its interface to the wired LAN can vary. For example, the interconnection between the WTPs and ACs can have its own wiring, and its only connection to the LAN is via the AC's Distribution System (DS) port(s). In such cases, the WLAN frequently occupies its own distinct addressing partition(s) in order to facilitate routing, and the AC often acts as a forwarding element.
このような展開では、WLANは、典型的には、有線LANの拡張です。しかし、有線LANへのインターフェースは変えることができます。例えば、WTPsとACSとの間の相互接続は、独自の配線を持つことができ、およびLANへの接続のみがACの分配システム（DS）ポート（複数可）を介してです。このような場合、WLANはしばしばルーティングを容易にするために、それ自身のアドレッシング異なるパーティションを占有し、そしてACは、多くの場合、転送要素として作用します。
In other cases, the WTPs may be mingled with the existing LAN elements, perhaps sharing address space, or perhaps somehow logically isolated from other wired elements (e.g., by Virtual LAN). Under these circumstances, it is possible that traffic destined to/from the WLAN is mixed with traffic to/from the LAN.
他の場合には、WTPsは、おそらくアドレス空間を共有し、またはおそらく何とか論理的に他の有線の要素（例えば、バーチャルLANによる）から単離された、既存のLAN要素を混ぜてもよいです。こうした状況下では、WLANからLANへ/からのトラフィックと混合されるに/トラフィックが宛先とすることが可能です。
Localized deployments such as these could potentially choose any one of the MAC-splitting scenarios, depending on the size of the deployment, mobility requirements, and other considerations. In many cases, any one of the various MAC-splitting approaches would be sufficient. This implies that user data may be bridged by either the WTP or the AC.
このようなローカライズ展開は潜在的に展開、モビリティ要件、およびその他の考慮事項のサイズに応じて、MAC-分割シナリオのいずれかを選択することができます。多くの場合、様々なMAC分割手法のいずれかが十分であろう。これは、ユーザデータがWTPまたはACのいずれかによって架橋されていてもよいことを意味します。
The Internet hotspot scenario is representative of a more general deployment model one might find at cafes, hotels, or airports. It is also quite similar to temporary WLANs, which are created for conferences, conventions, and the like. Some common characteristics of these networks include the following:
インターネットホットスポットシナリオは、1つのカフェ、ホテル、または空港で見つけるかもしれない、より一般的な展開モデルの代表です。また、会議、コンベンション、などのために作成される一時のWLAN、と非常によく似ています。これらのネットワークのいくつかの一般的な特徴は次のとおりです。
o Primary function is to provide Internet access
O主な機能は、インターネットアクセスを提供することです
o Authentication may be very weak
O認証は非常に弱いことができます
o There frequently is no IEEE 802.11 link security
Oがあり、頻繁に何のIEEE 802.11リンクのセキュリティはありません
Sometimes, the Local MAC model is used. In such cases, the AC may be "in the clouds" (out on the Internet somewhere), and user data traffic will typically be locally bridged, rather than tunneled back to the AC. Some IEEE 802.11 management traffic may be tunneled back to the AC, but frequently the authentication consists in simply knowing the Service Set Identifier (SSID) and perhaps a shared key for use with WEP or WPA-PSK.
時には、ローカルMACモデルが使用されています。このような場合には、ACは（どこかにインターネット上から）「雲の中」であってもよく、およびユーザデータトラフィックは通常、ローカルブリッジするのではなく、バックACにトンネリングされます。いくつかのIEEE 802.11管理トラフィックは、バックACにトンネリングすることができるが、しばしば認証は、単に、おそらくサービスセット識別子（SSID）とWEP又はWPA-PSKで使用するための共有キーを知っていることにあります。
In other cases, a Split MAC model may be used. This is more common in airport and hotel scenarios, where users may have an account that requires verification with some back-end infrastructure prior to access. In these cases, IEEE 802.11 management frames are tunneled back to the AC (e.g., user authentication), and stronger IEEE 802.11 link security may be provided (e.g., RSN), but user data is still typically locally bridged, as the primary goal is to provide Internet access.
他の例では、スプリットMACモデルを使用することができます。これは、ユーザーがアクセスする前に、いくつかのバックエンドインフラストラクチャとの検証が必要でアカウントを持っていることがあり、空港やホテルシナリオにおいてより一般的です。これらの例では、IEEE 802.11管理フレームは、AC（例えば、ユーザ認証）に戻ってトンネリングされ、そしてより強力なIEEE 802.11リンクのセキュリティは（例えば、RSN）に提供することができるが、ユーザデータはまだ一般的にローカルにブリッジ、第一の目標があるようですインターネットへのアクセスを提供します。
A third variation on this scenario entails tunneling user data through a local AC in order to apply centralized policy. For example, in a hotel or airport scenario, there is no reason to provide direct access between WLAN users (who typically are within a private address space), and in fact, allowing such access might invite various sorts of malicious behavior. In such cases, tunneling all user data back to the (local) AC provides a security choke point at which policy may be applied to the traffic.
このシナリオ上の第3の変形例は、集中ポリシーを適用するために局所ACを通してトンネリングユーザデータを伴います。例えば、ホテルや空港のシナリオでは、（通常はプライベートアドレス空間内にある）WLANユーザー間の直接アクセスを提供する理由はありません、実際には、可能なアクセスは、悪意のある動作の各種を招待することがあります。このような場合には、（ローカル）ACに戻し、すべてのユーザ・データをトンネルするポリシーがトラフィックに適用することができるでセキュリティチョークポイントを提供します。
The distributed deployment model describes a more complex WLAN topology that features network segments that are typically somehow spatially separated, although not necessarily so. These segments might be connected in a physically secure manner, or (if they are widely separated) they might be connected across potentially hostile hops. Below we discuss several subgroups of this model.
分散展開モデルは、必ずしも必要ではないので、典型的には何らかの形で空間的に分離されているネットワーク・セグメントを備えて、より複雑なWLANトポロジを記述する。これらのセグメントは、物理的に安全な方法で接続されるかもしれない、または（それらが広く分離している場合）、彼らは、潜在的に敵対的なホップの両端に接続されるかもしれません。以下は、私たちは、このモデルのいくつかのサブグループを議論します。
One distributed deployment example involves a single large organization that is physically contained, typically within one large building. The network might feature logically distinct (e.g., per-department or per-floor) network segments, and in some cases, there might be firewalls between the segments for access control. In such deployments, the AC is typically in a centralized datacenter, but there might also be a hierarchy of ACs, with a master in the datacenter, and subordinate ACs distributed among the network segments. Such deployments typically assume some level of physical security for the network infrastructure.
一の分散配置の例は、物理的に、典型的には一つの大きな建物内に、含まれている単一の大規模な組織を含みます。ネットワークは、論理的に別個の（例えば、部門ごとまたは床）ネットワーク・セグメントを備えて可能性があり、いくつかのケースでは、アクセス制御のためのセグメントの間にファイアウォールがあるかもしれません。このような配置では、ACは、集中型データセンターに典型的であるが、データセンター内のマスタ、及びネットワークセグメント間に分散下位ACSの場合、ACSの階層があるかもしれません。このような展開では、通常、ネットワークインフラストラクチャの物理的なセキュリティのいくつかのレベルを想定しています。
Some large organizations have networks that span multiple buildings. The interconnections between these buildings might be wired (e.g., underground cables), or might be wireless (e.g., a point-to-point Metropolitan Area Network (MAN) link). The interconnections may be secured, but sometimes they are not. The organization may be providing outdoor wireless access to users, in which case some WTPs will typically be located outdoors, and these may or may not be within physically secure space. For example, college campuses frequently provide outdoor wireless access, and the associated WTPs may simply be mounted on a light post.
いくつかの大規模な組織では、複数の建物にまたがるネットワークを持っています。これらの建物間の相互接続（例えば、地下ケーブル）に配線されるかもしれない、または無線（例えば、ポイント・ツー・ポイント・メトロポリタンエリアネットワーク（MAN）リンク）かもしれません。相互接続性を確保することができるが、時にはそうではありません。組織は、いくつかのWTPsは、一般的に屋外にされる場合には、ユーザーに屋外での無線アクセスを提供することができ、これらは、あるいは物理的に安全な空間内であってもなくてもよいです。例えば、大学のキャンパスは、しばしば、屋外の無線アクセスを提供し、関連WTPsは、単に光ポストに取り付けることができます。
For such deployments, ACs may be centrally located in a datacenter, or they may be distributed. User data traffic may be locally bridged, but more frequently it is tunneled back to the AC, as this facilitates mobility and centralized policy enforcement.
このような展開では、ACSは、中央データセンターに配置することができる、またはそれらは分散されてもよいです。ユーザデータトラフィックはローカルにブリッジすることができるが、これは、モビリティおよび集中ポリシー適用を容易にするより頻繁に、それは、バックACにトンネリングされます。
A common deployment model entails an enterprise consisting of a headquarters and one or more branch offices, with the branches connected to the central HQ. In some cases, the site-to-site connection is via a private WAN link, and in others it is across the
一般的な展開モデルは、本社と中央HQに接続された分岐を有する1つまたは複数の支店からなる企業を伴います。いくつかのケースでは、サイト間の接続には、専用のWANリンクを介してであり、それ以外ではそれが全体であります
Internet. For connections crossing potentially hostile hops (e.g., the Internet), some sort of Virtual Private Network (VPN) is typically employed as a protective measure.
インターネット。接続が潜在的に敵対的なホップを横断するために（例えば、インターネット）、仮想プライベートネットワーク（VPN）のいくつかの並べ替えは、通常の保護対策として採用されています。
In some simple branch office scenarios, there are only WTPs at the remote site, and these are managed by a controller residing at the central site. In other cases, a branch site may have its own subordinate controller, with the master controller again residing at the central site. In the first case, local bridging is often the best choice for user data, due to latency and link capacity issues. In the second case, traffic may be locally bridged by the WTPs, or it may be forwarded to the local subordinate controller for centralized policy enforcement. The choice depends on many factors, including local topology and security policy.
いくつかの簡単なブランチオフィスのシナリオでは、唯一のWTPsは、リモートサイトにある、そしてこれらは、中央サイトに常駐しているコントローラによって管理されています。他の例では、ブランチサイトは、マスタコントローラが再び中央サイトに常駐して、独自の下位のコントローラを有することができます。最初のケースでは、ローカルブリッジが原因待ち時間とリンク容量の問題に、多くの場合、ユーザデータのための最良の選択です。第二のケースでは、トラフィックは、ローカルWTPsによって架橋することができる、またはそれは、集中ポリシー施行のためのローカル下位コントローラに転送することができます。選択はローカルトポロジーとセキュリティポリシーを含む多くの因子に依存します。
It is becoming increasingly common to send WTPs home with employees for use as a telecommuting solution. While there are not yet any standards or hard rules for how these work, a fairly typical configuration provides Split MAC with all user data tunneled back to the controller in the organization's datacenter so that the WTP is essentially providing wireless VPN services. These devices may in some cases provide their own channel security (e.g., IPsec), but alternative approaches are possible. For example, there may be a stand-alone VPN gateway between the WTP and the Internet, which forwards all organization-bound traffic to the VPN gateway.
在宅勤務ソリューションとして使用するための従業員とWTPsホームを送信することがますます一般的になりつつあります。どのようにこれらの作業のための任意の規格やハードのルールがまだ存在しませんが、かなり典型的な構成は、WTPは、本質的にワイヤレスVPNサービスを提供しているように、組織のデータセンターに戻って、コントローラにトンネリングされたすべてのユーザーデータとのスプリットMACを提供します。いくつかのケースでもよいこれらの装置は、（例えば、IPsec）の独自のチャネルのセキュリティを提供するが、別のアプローチが可能です。たとえば、VPNゲートウェイにすべての組織が結合したトラフィックを転送WTPとインターネットとの間のスタンドアロンのVPNゲートウェイがあるかもしれません。
Similarly, it is becoming increasingly common for travelers to plug a WTP into a hotel broadband connection. While in many cases, these WTPs are stand-alone fat APs, in some cases they are configured to create a secure connection to a centralized controller back at headquarters, essentially forming a VPN connection. In such scenarios, a Split MAC approach is typical, but split-tunneling may also be supported (i.e., only data traffic destined for the headquarters is tunneled back to the controller, with Internet-bound traffic locally bridged).
旅行者はホテルのブロードバンド接続にWTPをプラグインするために同様に、それはますます一般的になっています。多くの場合、これらのWTPsは、スタンドアロンの脂肪のAPですが、いくつかのケースでは、彼らは基本的にVPN接続を形成し、バック本社で集中管理コントローラへの安全な接続を作成するように構成されています。そのようなシナリオでは、スプリットMACアプローチは典型的であるが、スプリットトンネリングもサポートすることができる（すなわち、本社宛のデータのみトラフィックがインターネットに結合トラフィックがローカルブリッジと、バックコントローラにトンネリングされます）。
This section describes general capabilities we might expect an adversary to have in various CAPWAP scenarios. Obviously, it is possible to limit what an adversary can do through various deployment restrictions (e.g., provide strict physical security for the AC-WTP link), but such restrictions are simply not always feasible. For example, it is not possible to provide strict physical security for various aspects of the telecommuter scenario. Thus, we must consider what capabilities an adversary might have in the worst case, and plan accordingly.
このセクションでは、我々は敵が様々なCAPWAPシナリオで持つことが予想される一般的な機能について説明します。もちろん、敵が様々な展開の制限（例えば、AC-WTPリンクのための厳格な物理的セキュリティを提供）を通じて何ができるかを制限することが可能であるが、そのような制限は、常に単純に実現可能ではありません。例えば、在宅勤務者シナリオの様々な態様のための厳密な物理的セキュリティを提供することは不可能です。したがって、我々は敵が最悪の場合に持って、それに応じて計画するかもしれないものの能力を考慮する必要があります。
One way to classify adversaries is in terms of their ability to interact with AC/WTP communications. For example, a passive adversary is one who can observe and perhaps record traffic, but cannot interact with it. They can "see" the traffic as it goes by, but they cannot interfere in any way, and they cannot inject traffic of their own. Note that such an adversary does not necessarily see all traffic -- they may miss portions of a communication, e.g., because some packets traverse a different path, or because the network is so busy that the adversary can't keep up (and drops packets as a result).
敵を分類する1つの方法は、AC / WTP通信と相互作用する能力という点です。例えば、受動的な敵は観察することができます1、おそらくレコードのトラフィックですが、それと対話することはできません。それが経つにつれて彼らは、トラフィックを「見る」ことができますが、彼らはどのような方法で干渉することができない、と彼らは自分のトラフィックを注入することはできません。彼らはコミュニケーションの部分を見逃す可能性、例えば、いくつかのパケットが別のパスを通過するため、またはネットワークは、敵が追いつかないほど多忙なので（とパケットを廃棄します - そのような敵が、必ずしもすべてのトラフィックを見ていないことに注意してください結果として）。
An active adversary, on the other hand, can directly interact with the traffic in real-time. There are two modes in which an active adversary might operate:
アクティブな敵は、他の一方で、直接、リアルタイムでトラフィックと対話することができます。アクティブな敵が作動する可能性のある2つのモードがあります。
Pass-by (or sniffer)
バイパス（またはスニファ）
* Can observe/record traffic
* /レコードトラフィックを観察することができます
* Can inject packets
*パケットを注入することができ
* Can replay packets
*パケットを再生することができます
* Can reflect packets (i.e., send duplicate packets to a different destination, including the to the packet source)
*パケットを反映することができる（すなわち、パケットの送信元に含め、異なる宛先に重複パケットを送信）
* Can cause redirection (e.g., via Address Resolution Protocol (ARP)/DNS poisoning)
*（アドレス解決プロトコル（ARP）/ DNSポイズニングを経て、例えば）のリダイレクトを引き起こす可能性があります
Inline (Man-in-the-Middle, or MitM)
インライン（マン・イン・ザ・ミドル、またはのMitM）
* Can observe/record traffic
* /レコードトラフィックを観察することができます
* Can inject packets
*パケットを注入することができ
* Can replay packets
*パケットを再生することができます
* Can reflect packets (with or without duplication)
*（または重複なし）パケットを反映することができます
* Can delete packets
*パケットを削除できます
* Can modify packets
*パケットを変更することができます
* Can delay packets
*パケットを遅らせることができます
A passive adversary could be located anywhere along the path between the AC and WTP, and is characterized by the fact that it only listens:
パッシブ敵はACとWTPとの間の経路に沿ってどこにでも配置することができ、それだけリッスンことを特徴とします。
+------+
|client| +--------+ |
|(STA) | | WTP | | +------+
+------+ ) ) ) ) | |-----| / \ +------+
/ / +--------+ |-x-( optional )---| AC |
+------+ | | \ cloud / +------+
| | +------+
|
| +-----------+
+--| pass-by |
| listener |
+-----------+
Figure 5: Passive Attacker
図5：パッシブ攻撃
An active adversary may attach in the same manner as the passive adversary (in which case it is in pass-by mode), or it may be lodged directly in the path between the AC and WTP (inline mode):
アクティブ敵は（それがパス・モードにある場合に）受動敵と同様にして取り付けることができる、またはそれはACとWTP（インラインモード）との間の経路内に直接提出することができます。
+------+
|client| +--------+ |
|(STA) | | WTP | | +------+ +------+
+------+ ) ) ) | |---| |active| / \ +------+
/ / +--------+ |-| MitM |--( optional )---| AC |
+------+ | +------+ \ cloud / +------+
| +------+
Figure 6: Active Man-in-the-Middle Attacker
図6：アクティブなman-in-the-middle攻撃
If it is not inline, it can only observe and create traffic; if it is inline, it can do whatever it wishes with the traffic it sees.
それがインライン化されていない場合は、それだけで観察し、トラフィックを作成することができます。それは、インラインであれば、それはそれは見ているトラフィックを希望するものは何でも行うことができます。
It is important to recognize that becoming a MitM does not necessarily require physical insertion directly into the transmission path. Alternatively, the adversary can cause traffic to be diverted to the MitM system, e.g., via ARP or DNS poisoning. Hence, launching an MitM attack is not so difficult as it might first appear.
のMitMになってきても、必ずしも伝送路に直接物理的挿入を必要としないことを認識することが重要です。また、敵はARPまたはDNSポイズニングを経由して、例えば、トラフィックがのMITMシステムに転用される可能性があります。したがって、のMITM攻撃を開始することは、最初に表示される場合がありますように難しいことではありません。
In this section, we discuss vulnerabilities that arise as a result of splitting the AP function across potentially hostile hops. We primarily consider network-based vulnerabilities, and while in particular we do not address how an adversary might affect a physical compromise of the WTP or AC, we do consider the potential effects of such compromises with respect to CAPWAP and the operational changes it introduces when compared to stand-alone AP deployments.
このセクションでは、潜在的に敵対的なホップを越えAP機能を分割した結果として生じる脆弱性を議論します。私たちは、主にネットワークベースの脆弱性を考慮し、特に、我々は敵がWTPまたはACの物理的な妥協に影響を与える可能性がどのように対応していませんが、我々はCAPWAPに関して、それが導入されて運用上の変更で、このような妥協の潜在的な影響を考慮しませんスタンドアローンのためにAPの展開を比較しました。
Functionally, we are interested in two general "states of being" with respect to AC-WTP communications: the session establishment phase or state, and the "connected" (or session established) state. We discuss each of these further below. Also, it is important to note that we first describe vulnerabilities assuming that the CAPWAP communications lack security of any kind. Later, we will evaluate the protocol given the security mechanisms currently planned for CAPWAP.
機能的に、我々は、AC-WTP通信に対して二つの一般的「であるの状態」に興味を持っている：セッション確立フェーズまたは状態、および状態を「接続」（またはセッションが確立します）。私たちは、さらに以下にこれらのそれぞれについて説明します。また、我々が最初のCAPWAP通信は、あらゆる種類のセキュリティを欠いていることと仮定した脆弱性を記述することに注意することが重要です。その後、我々は現在、CAPWAPのために計画セキュリティメカニズム特定のプロトコルを評価します。
The session establishment phase consists of two subordinate phases: discovery, and association or joining. These are treated individually in the following sections.
発見、および会合または接合：セッション確立フェーズは、二つの下位段階から成ります。これらは、以下のセクションで個別に扱われます。
Discovery consists of an information exchange between the AC and WTP. There are several potential areas of exposure:
発見は、ACとWTP間の情報交換から成ります。露出のいくつかの潜在的な領域があります。
Information Leakage: During Discovery, information about the WTP and AC hardware and software are exchanged, as well as information about the AC's current operational state. This could provide an adversary with valuable insights.
情報漏洩は：ディスカバリー中に、WTPとACのハードウェアおよびソフトウェアに関する情報は、同様にACの現在の動作状態に関する情報として、交換されます。これは貴重な洞察力を持つ敵を提供することができます。
DoS Potential: During Discovery, there are several opportunities for Denial of Service (DoS), beyond those inherently available to an inline adversary. For example, an adversary might respond to a WTP more quickly than a valid AC, causing the WTP to attempt to join with a non-existent AC, or one which is currently at maximum load.
DoS攻撃の可能性：Discoveryの実行中に、インライン敵に対して本質的に利用できるものを超えてサービス拒否（DoS）のためのいくつかの機会が、あります。例えば、敵が存在しないAC、または最大負荷時に現在あるものに参加しようとするWTPを引き起こし、有効なACよりも早くWTPに反応することがあります。
Redirection Potential: There are multiple ways in which an adversary might redirect a WTP during Discovery. For example, the adversary might pretend to be a valid AC, and entice the WTP to connect to it. Or, the adversary might instead cause the WTP to associate with the AC of the adversary's choosing, by posing as a DNS or DHCP server, injecting a spoofed Discovery Response, or by modifying valid AC responses.
リダイレクト可能性：敵は発見時のWTPをリダイレクトする可能性のある複数の方法があります。例えば、敵は有効なACのふりをし、それに接続するためのWTPを誘惑することがあります。それとも、敵ではなく、偽装されたディスカバリ応答を注入し、または有効なAC応答を変更することで、DNSやDHCPサーバーを装ったことで、敵の選んだのACに関連付けるWTPが発生することがあります。
Misdirection: An adversary might mislead either the WTP or AC by modifying the Discovery Request or Response in flight. In this way, the AC and/or WTP will have a false view of the other's capabilities, and this might cause a change in the way they interact (e.g., they might not use important features not supported by earlier versions).
ミスディレクション：敵は飛行中のディスカバリー要求または応答を変更することによって、WTPまたはACのいずれかを誤解させるかもしれません。このように、ACおよび/またはWTPは相手の能力の偽のビューを持つことになり、これは、彼らが（例えば、彼らは以前のバージョンでサポートされていない重要な機能を使用しない場合があります）関わり方の変化を引き起こす可能性があります。
The association phase begins once the WTP has determined with which AC it wishes to join. There are several potential areas of exposure during this phase:
WTPは、それが参加を希望するACと決定するとアソシエーションフェーズが始まります。このフェーズでの露出のいくつかの潜在的な領域があります。
Information Leakage: During association, the adversary could glean useful information about hardware, software, current configuration, etc. that could be used in various ways.
協会の間に、敵は様々な方法で使用することができ、ハードウェア、ソフトウェア、現在の設定などについての有用な情報を収集できます。情報漏洩。
DoS Potential: During formation of a WTP-AC association, there are several opportunities for Denial of Service (DoS), beyond those inherently available to an inline adversary. For example, the adversary could flood the AC with connection setup requests. Or, it could respond to the WTP with invalid connection setup responses, causing a connection reset. An adversary with MitM capability could delete critical session establishment packets.
DoS攻撃の可能性：WTP-AC協会の形成中、インライン敵に対して本質的に利用できるものを超えてサービス拒否（DoS）のためのいくつかの機会が、あります。例えば、敵は接続設定要求でACをあふれさせることができました。それとも、それは接続リセットを引き起こし、不正な接続設定応答とWTPに応答することができます。 MITM能力を持つ敵は、重要なセッション確立パケットを削除することができます。
Misdirection: An adversary might mislead either the WTP or AC by modifying the association request(s) or response(s) in flight. In this way, the AC and/or WTP will have an inaccurate view of the other's capabilities, and this might cause a change in the way they interact.
誤った方向：敵対者は、飛行中のアソシエーション要求（複数可）または応答（複数可）を変更することにより、WTPまたはACのいずれかを欺く可能性があります。このように、ACおよび/またはWTPは相手の能力の不正確なビューを持つことになり、これは、彼らが対話する方法に変化を引き起こす可能性があります。
Some of these types of exposure are extremely difficult to prevent. However, there are things we can do to mitigate the effects, as we will see below.
露出のこれらのタイプのいくつかは予防することが極めて困難です。しかし、我々は以下を参照してくださいますよう、影響を緩和するためにできることがあります。
Once the WTP and AC have established an association, the adversary's attention will turn to the network connection. If we assume a passive adversary, the primary concern for established connections is eavesdropping. If we assume an active adversary, there are several other potential areas of exposure:
WTPとACが関連を確立したら、敵の注意は、ネットワーク接続に変わります。我々は受動的な敵を想定すると、確立された接続のための主要な関心事は、盗聴です。我々はアクティブな敵を想定した場合、露出のいくつかの他の潜在的な領域があります。
Connection Hijacking: An adversary may assume the identity of one end of the connection and take over the conversation. There are numerous ways in which the true owner of the identity may be taken off-line, including DoS or MitM attacks.
接続のハイジャック：敵は、接続の一端のアイデンティティを仮定して、会話を引き継ぐことがあります。 DOSまたはのMitM攻撃を含むアイデンティティの真の所有者がオフラインにすることができる、さまざまな方法があります。
Eavesdropping: An adversary may glean useful information from knowledge of the contents of CAPWAP control and/or data traffic.
盗聴：敵CAPWAP制御および/またはデータトラフィックの内容の知識から有用な情報を収集することができます。
Modification of User Data: An adversary with MitM capabilities could modify, delete, or insert user data frames.
ユーザーデータの変更：のMITM機能を持つ敵、変更、削除、またはユーザデータフレームを挿入することができます。
Modification of Control/Monitoring Messages: An adversary with MitM capability could modify control traffic such as statistics, status information, etc. to create a false impression at the recipient.
制御/監視メッセージの変更：のMITM能力を持つ敵は、受信者に誤った印象を作成するなどの統計情報、ステータス情報、などの制御トラフィックを変更することができます。
Modification/Control of Configuration: An adversary with MitM capability could modify configuration messages to create unexpected conditions at the recipient. Likewise, if a WTP is redirected during Discovery (or joining) and connects to an adversary rather than an authorized AC, the adversary may exert complete control over the WTPs configuration, including potentially loading tainted WTP firmware.
設定の変更/制御：のMITM能力を持つ敵は、受信者の予期しない条件を作成するために、構成メッセージを修正することができます。 WTPを発見中にリダイレクト（または接合）と敵ではなく、承認ACに接続されている場合も同様に、敵対者は、潜在的に汚染されたWTPファームウェアをロードするなど、WTPs構成を完全に制御を発揮することができます。
This section gives an sampling of potential adversary goals. It is not exhaustive, and makes no judgment as to the relative likelihood or value of each individual goal. Rather, it is meant to give some idea of what is possible. It is important to remember that clever attacks often result when seemingly innocuous flaws or vulnerabilities are combined in some non-intuitive way. Hence, we don't rule out some goal that, taken alone, might not seem to make sense from an adversarial perspective.
このセクションでは、潜在的な敵の目標のサンプリングを提供します。それは網羅的ではなく、それぞれの個々の目標の相対的な可能性や価値について何ら判断を行うものではありません。むしろ、可能であるもののいくつかのアイデアを与えることを意味しています。一見無害な傷や脆弱性がいくつかの非直感的な方法で結合されるとき巧妙な攻撃が頻繁になることを覚えておくことが重要です。したがって、我々は敵対的な観点から意味をなすように見えないかもしれません、単独で、いくつかの目標を排除していません。
There are numerous reasons why an adversary might want to eavesdrop on AC-WTP traffic. For example, it allows for reconnaissance, providing answers to the following questions:
敵がAC-WTPのトラフィックを盗聴することがありますなぜ、多くの理由があります。たとえば、以下の質問に対する回答を提供し、偵察することができます：
o Where are the ACs?
OのACどこにいますか？
o Where are the WTPs?
O WTPsどこにいますか？
o Who owns them?
oだれがそれらを所有していますか？
o Who manufactured them? o What version of firmware do they run?
oだれがそれらを製造しますか？ O彼らは、ファームウェアのバージョンは何を実行するのですか？
o What cryptographic capabilities do they have?
O彼らは、暗号何の能力を持っていますか？
Similarly, snooping on tunneled data traffic might potentially reveal a great deal about the network, including answers to the following:
同様に、トンネリングされたデータトラフィックにスヌーピングは、潜在的に次のように答えを含むネットワーク、について多くを明らかにするかもしれません。
o Who's using the WLAN?
O WLANを使用しています誰ですか？
o When, and for how long?
Oとき、およびどのくらいか？
o What addresses are they using?
O何アドレス彼らが使用していますか？
o What protocols are they using?
Oプロトコルは何彼らが使用していますか？
o What over-the-air security are they using?
O彼らは何空中セキュリティを使用していますか？
o Who/What are they talking to?
oだれ/何彼らが話していますか？
Additionally, access to tunneled user data could allow the attacker to see confidential information being exchanged by applications (e.g., financial transactions). An eavesdropper may gain access to valuable information that either provides the basis for another perhaps more sophisticated attack, or which has its own intrinsic value.
また、トンネリングされたユーザーデータへのアクセスは、攻撃者がアプリケーション（例えば、金融取引）によって交換される機密情報を見ることができる可能性があります。盗聴者は別の、おそらくより洗練された攻撃のための基礎を提供するのどちらかということ、あるいは独自の本質的な価値を持つ貴重な情報へのアクセスを得ることができます。
An adversary might want to impersonate or control an authorized WTP for many reasons, some of which we might realistically imagine today, and perhaps others about which we have no clue at this point. Examples we might reasonably imagine include the following:
敵は、我々はこの時点では見当もつかないかについて多くの我々は現実的に今日を想像するかもしれないそのうちのいくつかの理由、そしておそらく他の人のために認可さWTPを偽装または制御したいかもしれません。例として、我々は合理的に想像する次のようなものがあります
o to facilitate MitM attacks against WLAN users
WLANユーザに対してのMITM攻撃を容易にするために、O
o to leak/inject or otherwise compromise WLAN data
O /漏れ注入または他の方法でWLANデータを侵害します
o to give an inaccurate view of the state of the WLAN
WLANの状態の不正確なビューを提供するために、O
o to gain access to a trusted channel to an AC, through which various protocol attacks might be launched (e.g., hijack client sessions from other WTPs)
様々なプロトコル攻撃が起動されるかもしれない、それを通してAC、に高信頼チャネルにアクセスするためのO（例えば、他のWTPsからクライアント・セッションをハイジャック）
o to facilitate Denial-of-Service attacks against WLAN users or the network
WLANユーザまたはネットワークに対するサービス拒否攻撃を容易にするために、O
For reasons similar to the WTP impersonation discussed above, an adversary might want to impersonate an authorized AC for many reasons. Examples we might reasonably imagine include the following:
上記のWTP偽装と同様の理由で、敵は多くの理由のために許可されたACを偽装することができます。例として、我々は合理的に想像する次のようなものがあります
o to facilitate DoS attacks against WLANs
無線LANに対するDoS攻撃を容易にするために、O
o to facilitate MitM attacks against WLAN users
WLANユーザに対してのMITM攻撃を容易にするために、O
o to intercept user mobility context from another AC (possibly including security-sensitive information such as cryptographic keys)
oは別のAC（おそらくは例えば暗号鍵などの機密性の高い情報を含む）からユーザモビリティコンテキストを遮断します
o to facilitate selective control of one or more WTPs
Oは、一つ以上のWTPsの選択的制御を容易にします
* modify WTP configuration
* WTPの設定を変更
* load tainted firmware onto WTP
*負荷WTPにファームウェアを汚染されました
o to assist in controlling which AC associates with which WTP
制御においてWTPとそのAC会合を支援するO
o to facilitate IEEE 802.11 association of unauthorized WLAN user(s)
不正WLANユーザ（複数可）のIEEE 802.11アソシエーションを容易にするためにO
o to exploit inter-AC trust in order facilitate attacks on other ACs
oは他のACへの攻撃を容易ために、相互交流の信頼を悪用します
In general, AC impersonation opens the door to a large measure of control over the WLAN, and could be used as the foundation to many other attacks.
一般的には、ACの偽装は、WLANのコントロールの大規模な措置への扉を開き、他の多くの攻撃を基盤として使用することができます。
There are many less concrete goals an adversary might have which, taken alone, might not seem to have any purpose, but when combined with other goals/attacks, might have very definite and undesirable consequences. Here are some examples:
多くのあまり具体的な目標がありますが、敵は、単独でこれ、持っている可能性のある目的を持っているように見えるではないかもしれないが、他の目標/攻撃と組み合わせると、非常に明確かつ望ましくない結果をもたらす可能性があります。ここではいくつかの例を示します。
o cause CAPWAP de-association of WTP/AC
O WTP / ACのCAPWAPデ会合を引き起こします
o cause IEEE 802.11 de-association of authorized user
O許可されたユーザのIEEE 802.11デ会合を引き起こします
o inject/modify/delete tunneled IEEE 802.11 user traffic
O注入/変更/削除、トンネリングIEEE 802.11ユーザトラフィック
* to interact with a specific application
*特定のアプリケーションと対話します
* to launch various attacks on WLAN user systems
* WLANユーザシステム上のさまざまな攻撃を開始します
* to launch protocol fuzzing or other attacks on the AC that bridges between IEEE 802.11 and 802.3 frame formats
* IEEE 802.11および802.3フレームフォーマット間のブリッジプロトコルファジングまたはAC上の他の攻撃を開始します
o control DNS responses
O制御DNS応答
o control DHCP/BOOTP responses
O制御DHCP / BOOTP応答
Anticipating all of the things an adversary might want to do is a daunting task. Part of the difficulty stems from the fact that we are analyzing CAPWAP in a very general sense, rather than in a specific deployment scenario with specific assets and very specific adversary goals. However, we have no choice but to take this approach if we are to provide reasonably good security across the board.
敵がやりたいかもしれないもののすべてを予測することは困難な作業です。難しさの一部は、我々は非常に一般的な意味ではなく、特定の資産と非常に特定の敵の目標と具体的な展開シナリオでCAPWAPを分析しているという事実から生じます。しかし、我々は軒並み適度に良好なセキュリティを提供する場合は、このアプローチを取るしかありません。
In the previous sections, we described numerous vulnerabilities that result from splitting the AP function in two, and also discussed a number of adversary goals that could be realized by exploiting one or more of those vulnerabilities. In this section, we describe countermeasures we can apply to mitigate the risks that come with the introduction of CAPWAP into WLAN deployment scenarios.
前のセクションでは、我々は2つにAP機能を分割から生じる多数の脆弱性を説明し、そしてまた、これらの脆弱性の一つ以上を利用することによって実現することができる敵目標の数を検討しました。このセクションでは、我々はWLAN展開シナリオへのCAPWAPの導入が付属してリスクを軽減するために適用することができます対策について説明します。
Mutual authentication consists in each side proving its identity to the other. There are numerous authentication protocols that accomplish this, typically using either a shared secret (e.g., a pre-shared key) or by relying on a trusted third party (e.g., with digital credentials such as X.509 certificates).
相互認証は、他にその身元を証明するそれぞれの側にあります。通常、共有（例えば、事前共有キー）、秘密または（例えばX.509証明書などのデジタル資格情報を使用して、例えば）信頼できるサードパーティに依存することによってのいずれかを使用して、これを実現する数々の認証プロトコルがあります。
Strong mutual authentication accomplishes the following:
強力な相互認証には、以下を達成します。
o helps prevent AC/WTP impersonation
oはAC / WTPのなりすましを防ぐことができます
o helps prevent MitM attacks
oはのMITM攻撃を防ぐことができます
o can be used to limit DoS attacks.
oはDoS攻撃を制限するために使用することができます。
While authentication consists in proving the identity of an entity, authorization consists in determining whether that entity should have access to some resource. The current IEEE 802.11i CAPWAP protocol binding takes a rather simplistic approach to authorization, depending on the authentication method chosen. If pre-shared keys are used, authorization is broad and coarse: if the device knows the pre-shared key, the device is "trusted", meaning the that it is believed to be what it claims to be ( AC versus WTP), and it is granted all privilege/access associated with that device class.
認証は、エンティティの身元を証明して構成されていますが、承認は、その実体は、いくつかのリソースへのアクセスを持っているかどうかを決定することにあります。結合現在のIEEE 802.11iのCAPWAPプロトコルが選択された認証方法に応じて、承認にかなり単純なアプローチを取ります。事前共有キーを使用する場合は、許可が広く、粗いです：デバイスは、事前共有キーを知っている場合、デバイスは「信頼」で、それは（WTP対AC）であることを主張するものであると考えられていることを意味し、そしてそれは、その装置クラスに関連付けられたすべての権限/アクセス権が付与されます。
When using pre-shared keys, some granularity may be achieved by creating classes, each with their own pre-shared key, but this still has drawbacks. For example, while possession of the key may suffice to identify the device as a member of a given group or class, it cannot be used to prove a device is either a WTP or an AC. This means the key can be abused, and those possessing the key can claim to be either type of device.
事前共有キーを使用する場合、いくつかの細かさは、自分の事前共有鍵を持つクラス、それぞれを作成することによって達成することができるが、これはまだ欠点を有しています。鍵の所有が所与のグループまたはクラスのメンバとしてデバイスを識別するのに十分かもしれないが、例えば、装置がWTPまたはACのいずれかであることを証明するために使用することができません。これは、キーが悪用されることを意味し、そしてキーを持つものは、デバイスのいずれかのタイプであると主張することができます。
When X.509v3 certificates are used for authentication, much more granular authorization policies are possible. Nonetheless, the current IEEE 802.11i protocol binding remains simplistic in its approach (though this may be addressed in future revisions). As currently defined, the X.509v3 certificates facilitate the following authorization checks:
X.509v3証明書を認証に使用されている場合は、より多くの粒状の許可ポリシーが可能です。 （これは将来の改訂に対処することができるが）それにもかかわらず、結合現在のIEEE 802.11i規格のプロトコルは、そのアプローチに単純残ります。現在定義されているように、のX.509v3証明書は、次の権限のチェックを容易：
o CommonName (CN): the CN contains the MAC address of the device; if the relying party (AC or WTP) has a method for determining "acceptability" of a given MAC address, this helps prevent AC/WTP impersonation, MitM attacks, and may help in limiting DoS attacks
CommonName（CN）O：CNは、デバイスのMACアドレスを含みます。証明書利用者（ACまたはWTP）指定されたMACアドレスの「受容性」を決定するための方法を持っている場合、これは、AC / WTPのなりすましを防ぐことができますのMITM攻撃、DoS攻撃を制限するに役立つかもしれません
o Extended Key Usage (EKU) key purpose ID bits: CAPWAP uses specific key purpose ID bits (see [RFC5415] for more information) to explicitly differentiate between an AC and a WTP. If use of these bits is strictly enforced, this segregates devices into AC versus WTP classes, and assists in preventing AC/WTP impersonation, MitM attacks, and may also help in limiting DoS attacks. However, if the id-kp-anyExtendedKeyUsage keyPurposeID is supported, this mechanism may be on a par with pre-shared keys, as a rogue device has the ability to claim it is either a WTP or AC, unless CN-based access controls are employed in tandem.
O拡張キー使用法（EKU）キー目的のIDビットは：CAPWAPは、特定のキー目的IDビットを使用して明示的にACとWTPを区別する（詳細については[RFC5415]を参照します）。これらのビットの使用は厳格に実施された場合、これはWTPクラス対ACにデバイスを分離し、AC / WTPの偽装、のMITM攻撃を防ぐことに役立ち、また、DoS攻撃を制限するに役立つかもしれません。 ID-KP-anyExtendedKeyUsage keyPurposeIDがサポートされている場合CNベースのアクセス制御がない限り、不正なデバイスは、それがWTPまたはACのいずれかであると主張する能力を有するしかし、このメカニズムは、事前共有鍵と同等であってもよいですタンデムで採用。
It should be noted that certificate-based authorization and zero configuration are not fully compatible. Even if the WTPs and the ACs are shipped with manufacturer-provided certificates, the WTPs need a way to identify the correct AC is in this deployment (as opposed to other ACs from the same vendor, purchased and controlled by an adversary), and the AC needs to know which WTPs are part of this deployment (as opposed to WTPs purchased and controlled by an adversary).
証明書ベースの認証およびゼロコンフィギュレーションが完全に互換性がないことに留意すべきです。 WTPsおよびACSは、メーカーが提供する証明書と一緒に出荷されていても、WTPs正しいACこの展開である特定する方法が必要（同じベンダーから他のACSに対照的に、敵対者が購入及び制御される）、及びACは、この展開の一部（WTPsは対照的に購入し、敵によって制御される）であるWTPs知っている必要があります。
The threat analysis in this document assumes that WTPs can identify the correct AC, and the AC can identify the correct WTPs. Analysis of situations where either of these do not hold is beyond the scope of this document.
このドキュメントの脅威分析はWTPsが正しいACを識別することができ、かつACが正しいWTPsを識別できることを前提としています。これらのいずれかが成立しない状況の分析は、このドキュメントの範囲を超えています。
Data origin authentication typically depends on first authenticating the party at the other end of the channel, and then binding the identity derived from that authentication process to the data origin authentication process. Data origin authentication primarily prevents an attacker from injecting data into the communication channel and pretending it was originated by a valid endpoint. This mitigates risk by preventing the following:
データ発信元認証は、通常、最初のチャネルの他端にパーティーを認証し、データ発信元認証プロセスへの認証プロセス由来のアイデンティティを結合に依存します。データ発信元認証は、主に通信チャネルにデータを注入し、それが有効なエンドポイントで発信されたふりから攻撃を防ぐことができます。これは、次のことを防止することにより、リスクを軽減します：
o packet injection
Oパケット注入
o connection hijacking
O接続ハイジャック
o modification of control and/or user data
制御および/またはユーザデータの入出力修飾
o impersonation
Oの偽装
Data integrity verification provides assurance that data has not been altered in transit, and is another link in the trust chain beginning from mutual authentication, extending to data origin authentication, and ending with integrity verification. This prevents the adversary from undetectably modifying otherwise valid data while in transit. It effectively prevents reflection and modification, and in some cases may help to prevent re-ordering.
データの整合性の検証は、データが途中で変更されていないという保証を提供し、データ発信元認証まで延び、かつ整合性の検証で終わる、相互認証から始まる信頼チェーン内の別のリンクです。これは、転送中に検出できないほどそうでない場合は、有効なデータを修正するから敵を防ぐことができます。これは、効果的に反射し、変更を防止し、場合によっては再発注を防ぐのに役立つかもしれません。
Anti-replay is somewhat self-explanatory: it prevents replay of valid packets at a later time, or to a different recipient. It may also prevent limited re-ordering of packets. It is typically accomplished by assigning monotonically increasing sequence numbers to packets.
アンチリプレイはやや自明である：それは後で、または別の受信者に有効なパケットのリプレイを防ぐことができます。また、パケットの制限された再発注を防ぐことができます。それは、典型的には、パケットにシーケンス番号を増加させる単調に割り当てることによって達成されます。
Data confidentiality prevents eavesdropping by protecting data as it passes over the network. This is typically accomplished using encryption.
データの機密性は、それがネットワーク上を通過するように、データを保護することにより盗聴を防止します。これは通常、暗号化を使用して達成されます。
Above we described various security elements and their properties. Below, we discuss combinations of these elements in terms of CAPWAP.
とりわけ、私たちは、さまざまなセキュリティ要素とそのプロパティを説明しました。以下では、CAPWAPの面でこれらの要素の組み合わせを議論します。
The CAPWAP control channel is used for forming an association between a WTP and AC, and subsequently it allows the AC to provision and monitor the WTP. This channel is critical for the control, management, and monitoring of the WLAN, and thus requires all of the security elements described above. With these elements in place, we can effectively create a secure channel that mitigates almost all of the vulnerabilities described above.
CAPWAP制御チャネルは、WTPとACとの間の関連付けを形成するために使用され、続いてそれが提供するACを可能にし、WTPを監視します。このチャネルは、WLANの制御、管理、および監視のために重要であるので、上述したセキュリティ要素の全てを必要とします。代わりに、これらの要素により、我々は、効果的に、ほぼ上記の脆弱性のすべてを軽減する安全なチャネルを作成することができます。
The CAPWAP data channel contains some IEEE 802.11 management traffic including association/disassociation, reassociation, and deauthentication. It also may contain potentially sensitive user data. If we assume that threats to this channel exist (i.e., it traverses potentially hostile hops), then providing strong mutual authentication coupled with data origin/integrity verification would prevent an adversary from injecting and/or modifying transit data, or impersonating a valid AC or WTP. Adding confidentiality would prevent eavesdropping.
CAPWAPデータチャネルは協会/解離、再会合、および認証解除を含むいくつかのIEEE 802.11管理トラフィックが含まれています。また、潜在的に敏感なユーザーデータが含まれていてもよいです。私たちは、このチャネルへの脅威が存在すると仮定した場合、有効なACまたはを注入および/または輸送データを変更、または偽装から敵を妨げるデータ発信元/整合性の検証と相まって強力な相互認証を提供する、（すなわち、それは潜在的に敵対的なホップを横断します） WTP。機密性を追加すると、盗聴を防止するであろう。
Datagram TLS (DTLS) is the currently proposed security solution for CAPWAP. DTLS supports the following security functionality:
データグラムTLS（DTLS）は、CAPWAPのために現在提案されているセキュリティソリューションです。 DTLSは、次のセキュリティ機能をサポートしています。
o Mutual Authentication (pre-shared secrets or X.509 Certificates)
O相互認証（事前共有秘密またはX.509証明書）
o Mutual Authorization (pre-shared secrets or X.509 Certificates)
O相互認証（事前共有秘密またはX.509証明書）
o Data Origin Authentication
データ発信元認証
o Data Integrity Verification
データのインテグリティ検証
o Anti-replay
Oアンチリプレイ
o Confidentiality (supports strong cryptographic algorithms)
Oの機密性（強力な暗号化アルゴリズムをサポートしています）
Using DTLS for both the control and data channels mitigates nearly all risks resulting from splitting the AP function in two.
制御とデータの両方のチャネルに対してDTLSを使用して二つにAP機能を分割から生じるほぼ全てのリスクを軽減します。
Unfortunately, DTLS does not solve all of our CAPWAP security concerns. There are some things it just cannot prevent. These are enumerated below.
残念ながら、DTLSは、私たちのCAPWAPのセキュリティ上の問題のすべてを解決していません。それだけで防ぐことができないいくつかのものがあります。これらは、以下に列挙されています。
Even with the security provided by DTLS, CAPWAP is still susceptible to various types of DoS attack:
でもDTLSによって提供されるセキュリティと、CAPWAPはまだDoS攻撃の様々なタイプの影響を受けやすいです。
o Session Initialization: an adversary could initiate thousands of DTLS handshakes simultaneously in order to exhaust memory resources on the AC; DTLS provides a mitigation tool via the HelloVerifyRequest, which ensures that the initiator can receive packets at the claimed source address prior to allocating resources. However, this would not thwart a botnet-style attack.
Oセッション初期化：同時にACのメモリリソースを排気するためにDTLSハンドシェークの数千を開始することができる敵。 DTLSは、イニシエータが前のリソースを割り当てるに記載のソースアドレスにパケットを受信できることを保証HelloVerifyRequestを介して軽減ツールを提供します。しかし、これはボットネットスタイルの攻撃を阻止しません。
o Cryptographic DoS: an adversary could flood either the AC or WTP with properly formed DTLS records containing garbage, causing the recipient to waste compute cycles decrypting and authenticating the traffic.
暗号DoS攻撃○：敵は、受信者がトラフィックを復号化し、認証する計算サイクルを無駄にさせ、ゴミを含む適切に形成されDTLSレコードでACまたはWTPのいずれかをあふれさせることができました。
o Session interference: a MitM could either drop important session establishment packets or inject bogus connection resets during session establishment phase. It could also interfere with other traffic in an established session.
Oセッション干渉：のMitMは重要セッション確立パケットをドロップするか、セッション確立フェーズの間に偽の接続のリセットを注入する可能性のいずれか。また、確立されたセッションでは、他の交通を妨げる可能性があります。
These attacks can be mitigated through various mechanisms, but not entirely avoided. For example, session initialization can be rate-limited, and in case of resource exhaustion, some number of incompletely initialized sessions could be discarded. Also, such events should be strictly audited.
これらの攻撃は、様々なメカニズムによって軽減、しかし完全に回避することができません。たとえば、セッションの初期化は、レート制限することができ、およびリソースの枯渇の場合には、不完全に初期化されたセッションの一部の数は、廃棄することができます。また、このようなイベントは厳密に監査済みでなければなりません。
Likewise, cryptographic DoS attacks are detectable if appropriate auditing and monitoring controls are implemented. When detected, these events should (at minimum) trigger an alert. Additional mitigation might be realized by randomly discarding packets.
適切な監査および監視制御が実装されている場合も同様に、暗号DoS攻撃が検出可能です。検出された場合には、これらのイベントは、（少なくとも）アラートをトリガーする必要があります。追加の緩和策は、ランダムにパケットを廃棄することによって実現される可能性があります。
Session interference is probably the most difficult of DoS attacks. It is very difficult to detect in real-time, although it may be detected if exceeding a lost packet threshold triggers an alert. However, this depends on the MitM not being in a position to delete the alert before it reaches its appropriate destination.
セッション干渉はおそらく、DoS攻撃の最も困難です。失われたパケットのしきい値を超えるとアラートをトリガーする場合、それは検出することができるが、リアルタイムで検出することは非常に困難です。しかし、これは、その適切な宛先に到達する前のMitMはアラートを削除する立場にないに依存します。
CAPWAP protocol security cannot prevent (or detect) passive monitoring. The best we can do is provide a confidentiality mechanism.
CAPWAPプロトコルのセキュリティは受動的監視を妨げる（または検出）することができません。私たちができる最善のは、機密性のメカニズムを提供しています。
DTLS provides no defense for traffic analysis. If this is a concern, there are traffic generation and padding techniques designed to mitigate this threat, but none of these are currently specified for CAPWAP.
DTLSは、トラフィック分析のための防衛を提供していません。これが懸念される場合は、そこにこの脅威を緩和するために設計されたトラフィック生成とパディングの技術があるが、これらのどれもが、現在CAPWAPのために指定されていません。
This was discussed in more limited scope in the section above on DoS attacks. An active MitM can delete or re-order packets in a manner that is very difficult to detect, and there is little the CAPWAP protocol can do in such cases. If packet loss is reported upon exceeding some threshold, then perhaps detection might be possible, but this is not guaranteed.
これは、DoS攻撃に上記のセクションでは、より限定された範囲で説明しました。活性のMitM削除または再注文のパケットを検出することは非常に困難であるように、およびCAPWAPプロトコルは、このような場合に行うことができるほとんどがあることができます。パケットロスがある閾値を超えたときに報告されている場合は、おそらく検出が可能かもしれないが、これは保証されません。
In addition to the issues raised above, there are other active attacks that can be mounted if the adversary has access to the wired medium. For example, the adversary may be able to impersonate a DNS or DHCP server, or to poison either a DNS or ARP cache. Such attacks are beyond the scope of CAPWAP, and point to an underlying LAN security problem.
上記提起された問題に加えて、敵が有線媒体へのアクセスを有する場合、実装することができる他の活性な攻撃があります。例えば、敵はDNSやDHCPサーバを偽装することができたり、DNSまたはARPキャッシュのどちらかを毒殺します。このような攻撃は、根本的なLANのセキュリティ問題へのCAPWAP、およびポイントの範囲を超えています。
This document outlines a threat analysis for CAPWAP in the context of IEEE 802.11 deployments, and as such, no additional CAPWAP-related security considerations are described here. However, in some cases additional management channels (e.g., Simple Network Management Protocol (SNMP)) may be introduced into CAPWAP deployments. Whenever this occurs, related security considerations MUST be described in detail in those documents.
このドキュメントでは、IEEE 802.11の展開の文脈でCAPWAPのための脅威分析の概要を説明し、そのように、追加のCAPWAP関連のセキュリティの考慮事項は、ここに記載されていません。しかし、いくつかのケースでは、追加の管理チャネル（例えば、簡易ネットワーク管理プロトコル（SNMP））CAPWAP展開に導入することができます。これが発生するたびに、関連するセキュリティの考慮事項は、それらの文書で詳細に説明されなければなりません。
The authors gratefully acknowledge the reviews and helpful comments of Dan Romascanu, Joe Salowey, Sam Hartman, Mahalingham Mani, and Pasi Eronen.
作者は感謝ダンRomascanu、ジョーSalowey、サム・ハートマン、Mahalinghamマニ、およびパシEronenの口コミや有益なコメントを認めます。
[80211I] "IEEE Std 802.11i: WLAN Specification for Enhanced Security", April 2004.
[80211I] "IEEE 802.11i規格STD：セキュリティ強化のためのWLAN仕様"、2004年4月。
[80211SEC] Edney, J. and W. Arbaugh, "Real 802.11 Security - Wi-Fi protected Access and 802.11i", 2004.
[80211SEC] Edney、J.とW. Arbaugh、 - 、2004年 "レアル802.11セキュリティは、Wi-Fiはアクセスと802.11iの保護しました"。
[8021X] "IEEE Std 802.1X-2004: Port-based Network Access Control", December 2004.
[8021X] "IEEE 802.1X STD-2004：ポートベースのネットワークアクセスコントロール"、2004年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4118]ヤン、L.、Zerfos、P.、およびE. Sadot、RFC 4118、2005年6月の "コントロールおよびワイヤレスアクセスポイントのプロビジョニング（CAPWAP）のためのアーキテクチャ分類学"。
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009.
[RFC5415]カルフーン、P.、エド。、モンテムッロ、M.、エド。、およびD.スタンレー、エド。、 "コントロールおよびワイヤレスアクセスポイント（CAPWAP）プロトコル仕様のプロビジョニング"、RFC 5415、2009年3月。
[RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009.
[RFC5416]カルフーン、P.、エド。、モンテムッロ、M.、エド。、およびD.スタンレー、エド。、 "コントロールおよびワイヤレスアクセスのプロビジョニングポイント（CAPWAP）IEEE 802.11のためのプロトコルバインディング"、RFC 5416、2009年3月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B.およびP.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、ヒラー、T.、およびG.ゾルン、 "直径拡張認証プロトコル（EAP）アプリケーション"、RFC 4072、2005年8月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley氏、R。およびB. Aboba、 "認証、許可、アカウンティング（AAA）キー管理のための指針"、BCP 132、RFC 4962、2007年7月。
[WEPSEC] Petroni, N. and W. Arbaugh, "The Dangers of Mitigating Security Design Flaws: A Wireless Case Study", January 2003.
[WEPSEC]ペトローニ、N.およびW. Arbaugh、「問題を緩和する要素セキュリティ設計上の欠陥の危険性：ワイヤレスケーススタディ」、2003年1月。
Authors' Addresses
著者のアドレス
Scott G. Kelly Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089 US
スコットG.ケリー・アルバネットワークス1322クロスマンアベニューサニーベール、CA 94089米国
EMail: scott@hyperthought.com
メールアドレス：scott@hyperthought.com
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 US
テレコミュニケーション科学T.チャールズ・クランシー国防総省研究所8080 Greenmeadドライブカレッジパーク、メリーランド州20740米国
EMail: clancy@LTSnet.net
メールアドレス：clancy@LTSnet.net