[要約] 要約：RFC 5418は、IEEE 802.11デプロイメントにおけるCAPWAPの脅威分析を提供しています。 目的：このRFCの目的は、CAPWAPプロトコルを使用したワイヤレスアクセスポイントの制御とプロビジョニングに関連するセキュリティ上の脅威を特定し、対策を提案することです。
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
IEEE 802.11展開のワイヤレスアクセスポイント（CAPWAP）脅威分析の制御とプロビジョニング
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
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.
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）の展開は、テクノロジーが成熟し、ワイヤレスインターフェイスチップがラップトップとさまざまなハンドヘルドコンピューティングデバイスの標準装備になるにつれてますます一般的になります。最も単純な展開では、WLANアクセスは、クライアントシステム（ステーションまたは「STA」）と配電システム（DS）または有線ネットワークを橋渡しするワイヤレスアクセスポイント（AP）によって完全に提供されます。
+------+
|client| +--------+ |
|(STA) | | Access | | +------+
+------+ ) ) ) ) | Point |-----| /optional\ +-------+
/ / +--------+ |--( L3 )---| AAA |
+------+ | \ cloud / +-------+
| +------+
Figure 1: IEEE 802.11 Deployment Using RSN
図1：IEEE 802.11 RSNを使用した展開
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プロトコルは、半径[RFC3579]および直径[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]は、APを2つのピース、ワイヤレス終端ポイント（WTP）とアクセスコントローラー（AC）に分割し、2つの新しいコンポーネント間の通信リンクを作成することにより、このアーキテクチャを変更します。このモデルでは、WTPはユーザー（ワイヤレス送信/受信）に関してWLANエッジ関数を実装し、ACは有線側のエッジ関数を実装します。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.
私たちの目的のために、CapWapシステム全体を一種の「AP相当」と考えると便利であり、上記の図はこの概念を示しています。このモデルを念頭に置いて、私たちの理想は、CAPWAPが元のFAT 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の管理のために明示的に設計されたプロトコルに由来していますが、他のタイプのネットワークデバイスの展開を管理するのに役立つことが判明する可能性があります。これにより、わずかな拘束力のある変動を除いて、単一のセキュリティ分析で十分である可能性があると結論付けることができます。ただし、これまでCapWapの候補と呼ばれる可能性が高い追加の関連シナリオの限られた数に基づいて、たとえば無線周波数識別（RFID）センサーで使用すると、これは単純なバイナリ決定ではないようです。
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）スプリッティングの動作の結果として、WLANの場合には、RFIDには存在しないことは明確なセキュリティ関連の考慮事項があります。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-高度な暗号化標準 - カウンターモード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 cert -x509v3証明書
o DIAMETER - proposed successor to RADIUS protocol (see below)
o 直径 - RADIUSプロトコルの後継者提案（以下を参照）
o DoS - Denial of Service (attack)
o DOS-サービス拒否（攻撃）
o DTLS - Datagram Transport Layer Security
o DTLS -Datagramトランスポートレイヤーセキュリティ
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
o RADIUS - Remote Authentication Dial-In User Service
o RADIUS-リモート認証ダイヤルインユーザーサービス
o STA - (wireless) STAtion
o STA-（ワイヤレス）ステーション
o TK - Transient Key
o
o TKIP - Temporal Key Integrity Protocol
o TKIP-一時的なキー整合性プロトコル
o WEP - Wired Equivalent Privacy
o WEP-有線同等のプライバシー
o WLAN - Wireless Local Area Network
o WLAN-ワイヤレスローカルエリアネットワーク
o WTP - Wireless Termination Point
o WTP-ワイヤレス終了点
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はFAT APシナリオと比較してシステムセキュリティの劣化を導入しないようにする必要があります。ただし、AP機能をWTPとACの間で分割することにより、CAPWAPは、以前はAPの内部がACとWTPの間のレイヤー3（L3）ネットワークに潜在的に敏感なプロトコル相互作用を配置します。したがって、この新しいシステムのセキュリティプロパティは、介入ネットワークのセキュリティプロパティと、分割の詳細に依存します。
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は802.LLリンクセキュリティメカニズムと認証サーバー通信の間に挿入されているため、サポートコンテキストを提供するために、IEEE 802.11とAAAセキュリティの非常に簡単な概要を説明します。私たちの議論に関連するこれらのトピックのみをカバーすることに注意することは非常に重要です。そのため、以下は決して網羅的ではありません。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).
この認証は、共有秘密を使用して実装できます。そのような場合、認証はリンクセキュリティメカニズムに暗黙的に結び付けられる可能性があります（たとえば、有線等価プライバシー（WEP）がオープン認証で使用される場合）、またはWi-Fi保護アクセスがで使用される場合、明示的である場合があります。事前に共有キー（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.
それ以外の場合、認証には明示的な暗号化交換が必要であり、この操作Bootstrapsリンクセキュリティが必要です。ほとんどの場合、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:
1. WTP and AC establish secure link
1.
2. AC establishes secure link with AAA server
2. ACは、AAAサーバーとの安全なリンクを確立します
3. STA and AAA server conduct EAP, produce PMK
3. STAおよびAAAサーバーはEAPを実施し、PMKを生成します
4. AAA server pushes PMK to AC
4. AAAサーバーはPMKをACにプッシュします
5. AC and STA conduct 4-way handshake (producing TK, among other keys)
5. ACとSTAは4ウェイハンドシェイクを実施します（他のキーの中でもTKを生成）
6. AC pushes TK to WTP (if decentralized encryption is used)
6. ACはTKをWTPにプッシュします（分散化された暗号化が使用されている場合）
7. WTP/STA use TK for IEEE 802.11 link security
7. WTP/STA IEEE 802.11リンクセキュリティに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.
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.
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].
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.
capwapは、IEEE 802.11のようにAAAに直接拘束されていないため、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プロトコルは、AuthenticatorとAAAサーバーの間でEAP通信を輸送するために、半径[RFC3579]または直径[RFC4072]のいずれかの使用を指す用語です。ここでは、AuthenticatorはACです。したがって、AAAプロトコルはACとAAAサーバーの間のリンクを保護します。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モデルの両方の重要な欠点の1つは、本質的に2パーティモデルであることです。CapWapの展開では、IEEE 802.11 WLANクライアントセッションが確立されたときに、さまざまなセキュリティ協会に依存しています。これらには以下が含まれます：
o WTP-AC (CAPWAP Authentication)
o wtp-ac（capwap認証）
o AC-AAA (AAA Authentication)
o AC-AAA（AAA認証）
o STA-AAA (EAP Method Execution)
o sta-aaa（EAPメソッド実行）
o STA-AC (AAA pushes keys to AC)
o
o STA-WTP (AC pushes keys to WTP)
o STA-WTP（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がWTPを信頼するACを信頼するAAAサーバーを信頼しているからといって、STAがWTPを信頼することを必ずしも意味するわけではありません。WTPは侵害され、ACとの信頼関係を維持するために彼の資格情報を使用している可能性がありますが、ネットワークに関する誤った情報をSTAに宣伝します。
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標準では、いくつかのフレームタイプについて説明し、WLANアーキテクチャのバリエーションは、これらのフレームタイプがどこで発生および/または終了するかを決定します（つまり、WTPまたはAC）。現在定義されている3つの基本的な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 制御：これらは、トランスミッション媒体（つまり、電波）を管理するためです。例には、RT、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:
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間で分割される方法は、「MACSplitting」特性に関して集合的に言及されています。以下のさまざまな形式のMac-Splittingについて簡単に説明します。詳細については、[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シナリオは、一部のIEEE 802.11 MacメッセージがWTPによって処理され、一部はACによって処理されるという事実によって特徴付けられます。たとえば、スプリットMACの実装では、IEEE 802.11フレーム処理を次のように分割する場合があります。
WTP
WTP
* Beacons
* ビーコン
* Probes
* プローブ
* RTS, CTS, ACK, PS-POLL, CF-POLL,CF-END, CF-ACK
* RTS、CTS、ACK、PSPOLL、CF-POLL、CF-END、CF-CACK
AC
交流
* 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.
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.
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.
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によって局所的に橋渡しされます。リモートMACの実装が常にACにデータパケットをトンネルに戻すことを期待するかもしれませんが、ローカルおよび分割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.
それ以外の場合、WTPは既存の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:
インターネットホットスポットシナリオは、カフェ、ホテル、または空港で見つける可能性のあるより一般的な展開モデルの代表です。また、会議、慣習などのために作成された一時的な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
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.
分散型展開の1つには、通常、1つの大きな建物内に物理的に含まれている単一の大規模な組織が含まれます。ネットワークは、論理的に異なる（たとえば、デパートごとまたは床ごとの）ネットワークセグメントを特徴とする場合があり、場合によっては、アクセス制御のためにセグメント間にファイアウォールがある場合があります。このような展開では、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.
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 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.
一般的な展開モデルには、本部と1つ以上の支店で構成されるエンタープライズが含まれ、支店は中央本部に接続されています。場合によっては、サイトからサイトへの接続はプライベートWANリンクを介して行われ、他の場合はインターネット上にあります。潜在的に敵対的なホップ（たとえば、インターネット）を横切る接続の場合、ある種の仮想プライベートネットワーク（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.
いくつかの単純な支店シナリオでは、リモートサイトにはWTPのみがあり、これらは中央サイトに居住するコントローラーによって管理されています。それ以外の場合、ブランチサイトには独自の下位コントローラーがあり、マスターコントローラーが再び中央サイトに住んでいます。最初のケースでは、レイテンシとリンク容量の問題により、多くの場合、ローカルブリッジングがユーザーデータに最適です。2番目のケースでは、トラフィックは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など）を提供する場合がありますが、代替アプローチが可能です。たとえば、WTPとインターネットの間にはスタンドアロンのVPNゲートウェイがあり、すべての組織に縛られたトラフィックを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をホテルのブロードバンド接続に接続することがますます一般的になっています。多くの場合、これらのWTPはスタンドアロンの脂肪APSですが、場合によっては、本社にある集中コントローラーへの安全な接続を作成するように構成され、基本的に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リンクの厳格な物理的セキュリティを提供する）を通じて敵ができることを制限することが可能ですが、そのような制限は単に必ずしも実行可能ではありません。たとえば、Telecommuterシナリオのさまざまな側面に厳格な物理的セキュリティを提供することはできません。したがって、敵が最悪の場合にどのような能力を持つかを考慮し、それに応じて計画する必要があります。
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通信と対話する能力の観点からです。たとえば、受動的な敵は、トラフィックを観察し、おそらく記録することができるが、それと相互作用することができない人です。彼らはそれが通過するときにトラフィックを「見る」ことができますが、彼らは決して干渉することはできず、彼らは自分のトラフィックを注入することはできません。そのような敵は必ずしもすべてのトラフィックを見るわけではないことに注意してください - たとえば、一部のパケットが別のパスを横断するため、またはネットワークが非常に忙しくて敵が追いつくことができないため（そしてドロップパケットがあるため、通信の一部を見逃す可能性があります。結果として）。
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)
*
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：アクティブな中間者攻撃者
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通信に関する2つの一般的な「存在状態」、つまりセッション確立段階または状態、および「接続された」（またはセッションが確立された）状態に関心があります。これらのそれぞれについては、以下でさらに説明します。また、CapWap通信にはあらゆる種類のセキュリティがないと仮定して、最初に脆弱性を説明することに注意することが重要です。その後、CapWapのために現在計画されているセキュリティメカニズムを考慮して、プロトコルを評価します。
The session establishment phase consists of two subordinate phases: discovery, and association or joining. These are treated individually in the following sections.
セッションの確立段階は、発見、関連または結合の2つの下位段階で構成されています。これらは、次のセクションで個別に扱われます。
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の可能性：発見中に、インド敵が本質的に利用できるものを超えて、サービス拒否（DOS）の機会がいくつかあります。たとえば、敵は有効なACよりも速くWTPに応答する可能性があり、WTPが存在しないACまたは現在最大負荷になっているACとの結合を試みます。
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.
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).
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:
Associationフェーズは、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.
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: 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.
WTPとACが関連性を確立すると、敵の注意はネットワーク接続に変わります。受動的な敵を想定している場合、確立されたつながりの主な関心は盗聴です。アクティブな敵を想定している場合、他にもいくつかの潜在的な暴露領域があります。接続ハイジャック：敵は、接続の一端のアイデンティティを引き受け、会話を引き継ぐことができます。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 ACSはどこにありますか？
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 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.
さらに、Tunneledユーザーデータへのアクセスにより、攻撃者はアプリケーション（たとえば、金融取引）によって交換されている機密情報を見ることができます。盗聴者は、おそらくより洗練された別の攻撃の基礎を提供するか、独自の本質的な価値を持つ貴重な情報にアクセスすることができます。
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
o WLANユーザーに対するMITM攻撃を促進する
o to leak/inject or otherwise compromise WLAN data
o
o to give an inaccurate view of the state of the WLAN
o WLANの状態の不正確な見解を与えるには
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)
o ACへの信頼できるチャネルにアクセスするために、さまざまなプロトコル攻撃が開始される可能性があります（例：他のWTPSからのハイジャッククライアントセッション）
o to facilitate Denial-of-Service attacks against WLAN users or the network
o WLANユーザーまたはネットワークに対するサービス拒否攻撃を促進する
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
o WLANに対するDOS攻撃を促進するため
o to facilitate MitM attacks against WLAN users
o WLANユーザーに対するMITM攻撃を促進する
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 1つ以上のWTPの選択的制御を促進するため
* modify WTP configuration
* WTP構成を変更します
* load tainted firmware onto WTP
* 汚染されたファームウェアをWTPにロードします
o to assist in controlling which AC associates with which WTP
o WTPとどのAC関連付けを制御するのを支援する
o to facilitate IEEE 802.11 association of unauthorized WLAN user(s)
o IEEE 802.11不正なWLANユーザーの協会を促進する
o to exploit inter-AC trust in order facilitate attacks on other ACs
o 他のACSへの攻撃を容易にするためにinter-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 インジェクション/変更/削除Tunneled 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.
前のセクションでは、AP機能を2つに分割することから生じる多くの脆弱性について説明し、それらの脆弱性の1つ以上を利用することで実現できる多くの敵の目標についても議論しました。このセクションでは、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プロトコルバインディングは、選択された認証方法に応じて、承認に対してかなり単純なアプローチを採用しています。事前に共有キーを使用する場合、承認は広く粗いです。デバイスが事前に共有キーを知っている場合、デバイスは「信頼されています」。つまり、それが主張するもの（AC対WTP）であると考えられていることを意味します。また、そのデバイスクラスに関連付けられたすべての特権/アクセスが付与されます。
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
o CommonName（CN）：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ビット（[RFC5415を参照]を参照）を使用して、ACとWTPを明示的に区別します。これらのビットの使用が厳密に強制されている場合、これはデバイスをAC対WTPクラスに分離し、AC/WTPのなりすまし、MITM攻撃の防止を支援し、DOS攻撃の制限にも役立ちます。ただし、CNベースのアクセスコントロールがない限り、RogueデバイスにはWTPまたはACであると主張する能力があるため、ID-kp-anyextededKeyUsage keypurposeIDがサポートされている場合、このメカニズムは事前に共有キーと同等になる可能性があります。タンデムで採用。
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は、どのWTPがこの展開の一部であるかを知る必要があります（敵によって購入および制御されたWTPとは対照的に）。
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.
このドキュメントの脅威分析は、WTPが正しいACを識別できることを前提としており、ACは正しいWTPを識別できると想定しています。これらのいずれかが保持されない状況の分析は、このドキュメントの範囲を超えています。
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:
データ起源の認証は通常、最初にチャネルの反対側でパーティを認証し、その認証プロセスから派生したIDをデータオリジン認証プロセスにバインドすることに依存します。データ起源の認証は、主に攻撃者が通信チャネルにデータを注入することを防ぎ、有効なエンドポイントから発信されたふりをします。これは、次のことを防ぐことでリスクを軽減します。
o packet injection
o
o connection hijacking
o 接続ハイジャック
o modification of control and/or user data
o
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:
Datagram TLS（DTLS）は、現在提案されているCAPWAPのセキュリティソリューションです。DTLSは、次のセキュリティ機能をサポートしています。
o Mutual Authentication (pre-shared secrets or X.509 Certificates)
o
o Mutual Authorization (pre-shared secrets or X.509 Certificates)
o 相互承認（事前に共有された秘密またはx.509証明書）
o Data Origin Authentication
o データ起源認証
o Data Integrity Verification
o データの整合性検証
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.
制御チャネルとデータチャネルの両方にDTLを使用すると、AP関数を2つに分割することに起因するほぼすべてのリスクが軽減されます。
Unfortunately, DTLS does not solve all of our CAPWAP security concerns. There are some things it just cannot prevent. These are enumerated below.
残念ながら、DTLは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
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.
o 暗号化DOS：敵は、GARBAGEを含む適切に形成された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.
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.
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キャッシュを毒したりすることができる場合があります。このような攻撃はCapWapの範囲を超えており、根底にあるLANセキュリティの問題を指し示しています。
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.
著者は、ダン・ロマスカヌ、ジョー・サロウィー、サム・ハートマン、マハリンガム・マニ、パシ・エロネンのレビューと有益なコメントに感謝します。
[80211I] "IEEE Std 802.11i: WLAN Specification for Enhanced Security", April 2004.
[80211i]「IEEE STD 802.11i：強化されたセキュリティのためのWLAN仕様」、2004年4月。
[80211SEC] Edney, J. and W. Arbaugh, "Real 802.11 Security - Wi-Fi protected Access and 802.11i", 2004.
[80211sec]エドニー、J。およびW.アーボー、「Real 802.11セキュリティ-Wi -Fi保護アクセスおよび802.11i」、2004年。
[8021X] "IEEE Std 802.1X-2004: Port-based Network Access Control", December 2004.
[8021x]「IEEE STD 802.1x-2004：ポートベースのネットワークアクセス制御」、2004年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Yang、L.、Zerfos、P。、およびE. Sadot、「ワイヤレスアクセスポイントの制御とプロビジョニングのための建築分類（CAPWAP）」、RFC 4118、2005年6月。
[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] Calhoun、P.、Ed。、Montemurro、M.、ed。、およびD. Stanley、ed。、「ワイヤレスアクセスポイント（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] Calhoun、P.、Ed。、Montemurro、M.、ed。、およびD. Stanley、ed。、「IEEE 802.11のワイヤレスアクセスポイント（CAPWAP）プロトコル結合の制御とプロビジョニング」、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. Calhoun、「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.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、Hiller、T。、およびG. Zorn、「直径拡張可能な認証プロトコル（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。and 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] Petroni、N。and W. Arbaugh、「セキュリティデザインの欠陥を緩和することの危険：ワイヤレスケーススタディ」、2003年1月。
Authors' Addresses
著者のアドレス
Scott G. Kelly Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089 US
EMail: scott@hyperthought.com
T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 US
T.チャールズ・クランシー・ドッド・ラボ・フォー・テレコミュニケーション・サイエンス8080グリーンミード・ドライブ・カレッジ・パーク、メリーランド州20740米国
EMail: clancy@LTSnet.net