[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-capwap-threat-analysis

Network Working Group                                           S. Kelly
Internet-Draft                                   Aruba Wireless Networks
Intended status: Informational                                 T. Clancy
Expires: February 2, 2007              Laboratory for Telecommunications
                                                             August 2006

             CAPWAP Threat Analysis for 802.11 Deployments

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on February 2, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   Early Wireless LAN (WLAN) deployments feature a "fat" Access Point
   (AP) which serves as a standalone interface between the wired and
   wireless network segments.  However, this model raises scaling,
   mobility, and manageability issues, and the CAPWAP protocol [CAPWAP]
   is being developed in reponse.  CAPWAP effectively splits the fat AP
   functionality into two network elements, and the communication

Kelly & Clancy          Expires February 2, 2007                [Page 1]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   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 CAPWAP implementations and deployments.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  CAPWAP Security Goals  . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview of 802.11 and AAA Security  . . . . . . . . . . . . .  5
     3.1.  802.11 Authentication and AAA  . . . . . . . . . . . . . .  6
     3.2.  802.11 Link Security . . . . . . . . . . . . . . . . . . .  8
   4.  Structure of the Analysis  . . . . . . . . . . . . . . . . . .  8
   5.  Representative CAPWAP Deployment Scenarios . . . . . . . . . .  9
     5.1.  Preliminary Definitions  . . . . . . . . . . . . . . . . .  9
       5.1.1.  Split MAC  . . . . . . . . . . . . . . . . . . . . . . 10
       5.1.2.  Local MAC  . . . . . . . . . . . . . . . . . . . . . . 10
       5.1.3.  Remote MAC . . . . . . . . . . . . . . . . . . . . . . 11
       5.1.4.  Data Tunneling . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Example Scenarios  . . . . . . . . . . . . . . . . . . . . 11
       5.2.1.  Localized Modular Deployment . . . . . . . . . . . . . 11
       5.2.2.  Internet Hotspot or Temporary Network  . . . . . . . . 12
       5.2.3.  Distributed Deployments  . . . . . . . . . . . . . . . 13
   6.  General Adversary Capabilities . . . . . . . . . . . . . . . . 15
     6.1.  Passive vs Active Adversaries  . . . . . . . . . . . . . . 15
   7.  Vulnerabilities Introduced by CAPWAP . . . . . . . . . . . . . 17
     7.1.  The Session Establishment Phase  . . . . . . . . . . . . . 17
       7.1.1.  The Discovery Phase  . . . . . . . . . . . . . . . . . 17
       7.1.2.  Forming an Association (Joining) . . . . . . . . . . . 18
     7.2.  The Connected Phase  . . . . . . . . . . . . . . . . . . . 18
   8.  Adversary Goals in CAPWAP  . . . . . . . . . . . . . . . . . . 19
     8.1.  Eavesdrop on AC-WTP Traffic  . . . . . . . . . . . . . . . 19
     8.2.  WTP Impersonation  . . . . . . . . . . . . . . . . . . . . 20
     8.3.  AC Impersonation . . . . . . . . . . . . . . . . . . . . . 20
     8.4.  Other Goals  . . . . . . . . . . . . . . . . . . . . . . . 21
   9.  Countermeasures and Their Effects  . . . . . . . . . . . . . . 22
     9.1.  Communications Security Elements . . . . . . . . . . . . . 22
       9.1.1.  Mutual Authentication  . . . . . . . . . . . . . . . . 22
       9.1.2.  Data Origin Authentication . . . . . . . . . . . . . . 22
       9.1.3.  Data Integrity Verification  . . . . . . . . . . . . . 23
       9.1.4.  Antireplay . . . . . . . . . . . . . . . . . . . . . . 23
       9.1.5.  Confidentiality  . . . . . . . . . . . . . . . . . . . 23
     9.2.  Putting the Elements Together  . . . . . . . . . . . . . . 23
       9.2.1.  Control Channel Security . . . . . . . . . . . . . . . 23
       9.2.2.  Data Channel Security  . . . . . . . . . . . . . . . . 23
   10. Countermeasures Provided By DTLS . . . . . . . . . . . . . . . 24
   11. Issues Not Addressed By DTLS . . . . . . . . . . . . . . . . . 24

Kelly & Clancy          Expires February 2, 2007                [Page 2]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

     11.1. DoS Attacks  . . . . . . . . . . . . . . . . . . . . . . . 24
     11.2. Passive Monitoring (Sniffing)  . . . . . . . . . . . . . . 25
     11.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 25
     11.4. Active MitM Interference . . . . . . . . . . . . . . . . . 25
     11.5. Other Active Attacks . . . . . . . . . . . . . . . . . . . 25
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     12.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 28

Kelly & Clancy          Expires February 2, 2007                [Page 3]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

1.  Introduction

   Wireless LAN (WLAN) deployments are increasingly common as the
   technology matures and wireless interface chips become standard
   equipment in laptops and various handheld computing devices.  In the
   simplest deployments, WLAN access is entirely provided by a wireless
   Access Point (AP), which is essentially a bridge between the client
   system (the "STA") and the Distribution System (DS) or wired network.

        |client|         +--------+     |
        |(STA) |         | Access |     |    +------+
        +------+ ) ) ) ) | Point  |-----|   /optional\    +-------+
       /      /          +--------+     |--(    L3    )---|  AAA  |
      +------+                          |   \ cloud  /    +-------+
                                        |    +------+

                             figure 1

   In this architecture the AP serves as a gatekeeper, facilitating
   client access to the wired LAN.  Typically, the client must somehow
   authenticate prior to being granted access, and in enterprise
   deployments this is frequently accomplished using 802.1X [8021X].  In
   the parlance of 802.1X, the client is 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 in

   From the perspective of the network administrator, the wired LAN to
   which the AP is attached is typically considered to be trusted,
   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.

   CAPWAP modifies this architecture, and perhaps the simplest way to
   think of this is in terms of splitting the AP into two pieces (the
   Wireless Termination Point or WTP, and the Access Controller or 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].

Kelly & Clancy          Expires February 2, 2007                [Page 4]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

  +------+        +=================================+
  |client|        |            +------+             |   |    +------+
  |(STA) |        | +-----+   /        \   +------+ |   |   /optional\    +-------+
  +------+ ) ) ) )|)| WTP |--(    L3    )--|  AC  |-|---|--(    L3    )---|  AAA  |
 /      /         | +-----+   \ cloud  /   +------+ |   |   \ cloud  /    +-------+
+------+          |            +------+             |   |    +------+
                        AP equivalence boundary

                        figure 2

   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.  This view is something of an over-simplification, but it is
   still quite useful.  With this model in mind, our ideal is to ensure
   that CAPWAP introduces no vulnerabilities which 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.

2.  CAPWAP Security Goals

   As noted above, it should be the aim of CAPWAP to avoid introducing
   any degradation of the system security properties when compared to
   the fat AP scenario which is being replaced.  In the ideal case, the
   simple act of splitting AP functions between the WTP and AC
   introduces no new security considerations beyond those relating to
   the added complexity of the split.  However, in actuality this
   depends on the security properties of the cloud between the AC and

   Limiting our goals in this way implies that over-the-air security is
   largely out of scope for this analysis, as is AC-AAA security.  This
   is appropriate, as CAPWAP generally does not directly interact with
   these protocols (at least, no more so than a fat AP does).  However,
   it is important to note that CAPWAP interacts indirectly with these
   in a number of ways which could potentially introduce subtle new
   security exposures.  Hence, before commencing with the threat
   analysis, we briely overview the relevant elements of 802.11 and AAA
   infrastructure security.

3.  Overview of 802.11 and AAA Security

   While this document is not directly concerned with 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

Kelly & Clancy          Expires February 2, 2007                [Page 5]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   these.  The following figure illustrates some of the complex
   relationships between the various protocols, and illustrates where
   CAPWAP sits in this mix:

                             +-----+    RADIUS
                             | AAA |<==============\\
                             +-----+               ||
                                |                  ||
                    +-----------+------------+     ||
                    |                        |     ||
                 +-----+                  +----+   ||
                 | AC  |                  | AC |<==//
                 +-----+                  +----+
              +---|  |---+             +---|  |---+
              |          |             |          |
              |          |             |  CAPWAP  |
           +-----+    +-----+       +-----+    +-----+
           | WTP |    | WTP |       | WTP |    | WTP |
           +-----+    +-----+       +-----+    +-----+
           ^                       ^^^
          ^^                      ^^^  802.11i,
          ^^                      ^^  802.1X, WPA,
      +-----+              +-----+     WEP
      | STA |              | STA |
      +-----+              +-----+
     /     /              /     /
    +-----+              +-----+

   As you can see, CAPWAP is being inserted directly in between the
   802.ll link security mechanism and the authentication server
   communication, so to provide supporting context, we give a very brief
   overview of 802.11 and AAA security below.  It is very important to
   note that we only cover those topics which are relevant to our
   discussion, so what follows is not by any means exhaustive.  For more
   detailed coverage of 802.11-related security, topics see e.g.

3.1.  802.11 Authentication and AAA

   In general, 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 whatsover'.  However, if 802.11 link security
   (described further below) is to be provided, then in general, some
   sort of authentication is required in order to bootstrap the trust
   relationship which underlies the associated key establishment

Kelly & Clancy          Expires February 2, 2007                [Page 6]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006


   In some cases, this authentication is 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).

   In other cases, authentication requires an explicit cryptographic
   exchange, and from this operation link security is bootstrapped.  In
   most such cases, 802.1X is used in conjunction with the Extensible
   Authentication Protocol [EAP1] to authenticate either the client or
   both the client and the authentication server, and this exchange
   produces cryptographic keying material for use with 802.11 security

   The resulting trust relationships are complex, as can be seen from
   the following (simplified) figure:

             |                      PTK (6)               | EAP Credentials,
             V                  /--------------\          | PMK (3)
          +------+              |  PSK/Cert(1) |          |
          |client|              V              |          V
          |(STA) |         +--------+     |    |        +-----+
          +------+ ) ) ) ) |  WTP   |-----|  +----+  |--| AAA |
         /      /          +--------+     |--| AC |--|  +-----+
        +------+              ^           |  +----+  |      ^
          ^  ^                |               ^  ^ (2,4)    |
          |  |    PTK (7)     |               |  \----------/
          |  \----------------/               |   Radius PSK,
          \-----------------------------------/       PMK
                  4-Way Handshake (w/PMK) (5)

                          figure 3

   1.  WTP and AC establish secure link

   2.  AC establishes secure link with AAA server

   3.  STA and AAA server conduct EAP, produce PMK

   4.  AAA server pushes PMK to AC

   5.  AC and STA conduct 4-way handshake (producing PTK)

Kelly & Clancy          Expires February 2, 2007                [Page 7]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   6.  AC pushes PTK to WTP

   7.  WTP/STA use PTK-derived keys for 802.11 security

3.2.  802.11 Link Security

   [This section is TBD...]

4.  Structure of the Analysis

   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  What are the risks?

      *  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 the exloit
         vs. the value of attack?

   o  What potential mitigation strategies are available to us?

   o  What kinds of trade-offs do these mitigation strategies offer, and
      do they introduce any new risks?

   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.

Kelly & Clancy          Expires February 2, 2007                [Page 8]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   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 which are not (or cannot be) completely
   addressed, and we give recommendations for mitigating the resulting

5.  Representative CAPWAP Deployment Scenarios

   In this section, we describe some representative CAPWAP deployment
   scenarios, and in particular, those scenarios which 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 which span
   multiple scenarios.  Following this is a sampling of individual
   deployment scenarios.

5.1.  Preliminary Definitions

   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 802.11 frame types currently defined:

   o  Control - in general, these are for managing the transmission
      medium (i.e. the airwaves).  Examples include RTS, CTS, ACK, PS-

   o  Management - in general, 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  Data - transit data (network packets)

   There are a number of other services provided by the WLAN
   infrastructure, including these:

   o  Packet distribution

   o  Synchronization

   o  Retransmissions

   o  Transmission Rate Adaptation

Kelly & Clancy          Expires February 2, 2007                [Page 9]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   o  Privacy/Confidentiality/Integrity (e.g. 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.  For convenience, we briefly describe various forms
   of MAC-splitting below.  For further detail, see [RFC4118] and

5.1.1.  Split MAC

   Split-MAC scenarios are characterized by the fact that some 802.11
   MAC messages are processed by the WTP, while some are processed by
   the AC.  For example, a split MAC implementation might divide 802.11
   frame processing as follows:


      *  Beacons

      *  Probes



      *  Association/Reassociation/Disassociation

      *  Authentication/Deauthentication

      *  Key Management

      *  802.11 Link Security (WEP, TKIP, 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 802.11 functionality.

5.1.2.  Local MAC

   Local-MAC scenarios are characterized by the fact that all 802.11 MAC
   messages are processed by the WTP.  Copies of some may be forwarded
   to the AC as a matter of convenience (i.e. when the AC needs to
   record some info from the frame, for example when providing
   accounting services), but the primary function of CAPWAP in local MAC
   scenarios is to provide centralized control and management for the
   WTPs, and STA packets are generally bridged locally.

Kelly & Clancy          Expires February 2, 2007               [Page 10]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

5.1.3.  Remote MAC

   Remote MAC scenarios are characterized by the fact that all 802.11
   MAC messages are forwarded to the AC - the WTP does not process any
   of these locally.  This model supports very light-weight WTP's which
   need be little more than smart antennas.

5.1.4.  Data Tunneling

   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 which
   rigidly define these terms and associated handling.  Data tunneling
   is further discussed for each scenario below.

5.2.  Example Scenarios

   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.

5.2.1.  Localized Modular Deployment

   The localized modular model describes a WLAN which 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.

   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.

   In other cases, the WTPs may be mingled with the existing LAN
   elements, perhaps sharing address space, or perhaps somehow logically

Kelly & Clancy          Expires February 2, 2007               [Page 11]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   isolated from other wired elements (e.g. by VLAN).  Under these
   circumstances, it is possible that traffic destined to/from the WLAN
   is mixed with traffic to/from the 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.

5.2.2.  Internet Hotspot or Temporary Network

   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:

   o  Primary function is to provide Internet access

   o  Authentication may be very weak

   o  There frequently is no 802.11 link security

   Sometimes, the local-MAC model is used.  In such cases the AC may be
   "in the cloud" (out on the Internet somewhere), and user data traffic
   will typically be locally bridged, rather than tunneled back to the
   AC.  Some 802.11 management traffic may be tunneled back to the AC,
   but frequently the authentication consists in simply knowing the SSID
   and perhaps a shared key for use with WEP or 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 which
   requires verification with some back-end infrastructure prior to
   access.  In these cases, 802.11 management frames are tunneled back
   to the AC (e.g. user authentication), and stronger 802.11 link
   security may be provided (e.g.  WPA), but user data is still
   typically locally bridged, as the primary goal is to provide Internet

   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 scenarios, 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

Kelly & Clancy          Expires February 2, 2007               [Page 12]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   at which policy may be applied to the traffic.

5.2.3.  Distributed Deployments

   The distributed deployment model describes a more complex WLAN
   topology which 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.  Large Physically-Contained Organization

   One distributed deployment example involves a single large
   organization which 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.  Campus Deployments

   Some large organizations have networks which 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 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 AC, as this
   facilitates mobility and centralized policy enforcement.  Branch Offices

   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.

Kelly & Clancy          Expires February 2, 2007               [Page 13]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   the Internet), some sort of VPN is typically employed as a protective

   In some simple branch office scenarios, there are only WTP's 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.  Telecommuter or Remote Office

   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
   standalone VPN gateway between the WTP and the Internet which
   forwards all organization-bound traffic to the VPN gateway.

   Similarly, it is becoming increasingly common for travelers to plug a
   WTP into a hotel broadband connection.  While in many cases, these
   WTPs are standalone fat AP's, 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 suppported (i.e. only data traffic destined for the
   headquarters is tunneled back to the controller, with Internet-bound
   traffic locally bridged).  Tactical Networks

   In some instances, there is a need to quickly establish a temporary
   network "in the field".  For example, during disaster relief
   operations (such as might occur following a natural disaster), it
   would be very helpful to be able to quickly establish secure
   connectivity between a temporary location in the field and a central
   office.  In some cases, it may be possible to quickly establish an
   insecure uplink of some sort (e.g.  DSL/cable modem, satellite
   uplink, cellular modem, etc), and then to create a WLAN at the site
   for convenient access.  This is very similar to telecommuter

Kelly & Clancy          Expires February 2, 2007               [Page 14]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   scenarios, except that there may be far more people using the WLAN.

   A typical configuration for such scenarios might utilize split MAC,
   with all user data tunneled back to the controller in the datacenter.
   Again, a separate VPN gateway might be placed between the WTP and the
   device providing Internet connectivity, or the WTP may be expected to
   provide its own channel security.

6.  General Adversary Capabilities

   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

6.1.  Passive vs Active Adversaries

   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

   An active adversary, on the other hand, can directly interact with
   the traffic in realtime.  There are two modes in which an active
   adversary might operate:

   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)

Kelly & Clancy          Expires February 2, 2007               [Page 15]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

      *  Can cause redirection (e.g. via ARP/DNS poisoning)

   Inline (Man in the Middle, or MitM)

      *  Can observe/record traffic

      *  Can inject packets

      *  Can replay packets

      *  Can reflect packets (with or without duplication)

      *  Can delete packets

      *  Can modify packets

   A passive adversary could be located anywere along the path between
   the AC and WTP, and is characterized by the fact that it only

        |client|         +--------+     |
        |(STA) |         |   WTP  |     |     +------+
        +------+ ) ) ) ) |        |-----|    /        \    +------+
       /      /          +--------+     |-x-( optional )---|  AC  |
      +------+                          | |  \ cloud  /    +------+
                                        | |   +------+
                                          |  +-----------+
                                          +--|  pass-by  |
                                             |  listener |

   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):

        |client|       +--------+   |
        |(STA) |       |   WTP  |   | +------+    +------+
        +------+ ) ) ) |        |---| |active|   /        \    +------+
       /      /        +--------+   |-| MitM |--( optional )---|  AC  |
      +------+                      | +------+   \ cloud  /    +------+
                                    |             +------+

   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.

Kelly & Clancy          Expires February 2, 2007               [Page 16]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   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
   a MitM attack is not so difficult as it might first appear.

7.  Vulnerabilities Introduced by CAPWAP

   In this section we discuss vulnerabilities which 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 and/or AC, we do consider the potential effects
   of such compromises with respect to CAPWAP and the operational
   changes it introduces when compared to standalone AP deployments.

   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 vulnerabilites assuming that the CAPWAP
   communications lack security of any kind.  Later, we will evaluate
   the protocol given the security mechanisms currently planned for

7.1.  The Session Establishment Phase

   The session establishment phase consists of two subordinate phases:
   discovery, and association or joining.  These are treated
   individually in the following sections.

7.1.1.  The Discovery Phase

   Discovery consists of an information exchange between the AC and WTP.
   There are several potential areas of exposure:

   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.

   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

Kelly & Clancy          Expires February 2, 2007               [Page 17]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   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).

7.1.2.  Forming an Association (Joining)

   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:

   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.

   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.

7.2.  The Connected Phase

   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

Kelly & Clancy          Expires February 2, 2007               [Page 18]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   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
      offline, including DoS or MitM attacks.

   Eavesdropping:  An adversary may glean useful information from
      knowledge of the contents of CAPWAP control and/or data traffic.

   Modification of User Data:  An adversary with MitM capabilities could
      modify, delete, or insert user data frames.

   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.

8.  Adversary Goals in CAPWAP

   This section gives an sampling of potential adversary goals.  It is
   not exhaustive, and makes no judgement 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.

8.1.  Eavesdrop on AC-WTP Traffic

   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:

   o  Where are the ACs?

   o  Where are the WTPs?

   o  Who owns them?

   o  Who manufactured them?

   o  What version of firmware do they run?

   o  What cryptographic capabilities do they have?

Kelly & Clancy          Expires February 2, 2007               [Page 19]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   o  etc...

   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  When, and for how long?

   o  What addresses are they using?

   o  What protocols are they using?

   o  What over-the-air security are they using?

   o  Who/what are they talking to?

   o  etc...

   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.

8.2.  WTP Impersonation

   An adversary might want to impersonate 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:

   o  to facilitate MitM attacks against WLAN users

   o  to give an inaccurate view of the state of the 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)

8.3.  AC Impersonation

   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:

   o  to facilitate DoS attack against WLAN

Kelly & Clancy          Expires February 2, 2007               [Page 20]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   o  to facilitate MitM attacks against WLAN users

   o  to intercept user mobility context (possibly including security-
      sensitive information such as cryptographic keys)

   o  to facilitate selective control of one or more WTPs

      *  modify WTP configuration

      *  load tainted firmware onto WTP

   o  to assist in controlling which AC associates with which WTP

   o  to facilitate 802.11 association of unauthorized WLAN user(s)

   o  to exploit inter-AC trust in order facilitate attacks on other ACs

   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.

8.4.  Other Goals

   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 undesireable
   consquences.  Here are some examples:

   o  cause CAPWAP de-association of WTP/AC

   o  cause 802.11 deassociation of authorized user

   o  inject/modify/delete tunneled 802.11 user traffic

      *  to interact with a specific application

      *  to launch various attacks on WLAN user systems

      *  to launch protocol fuzzing or other attacks on the AC which
         bridges between 802.11 and 802.3 frame formats

   o  control DNS responses

   o  control DHCP/BOOTP responses

   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

Kelly & Clancy          Expires February 2, 2007               [Page 21]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   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

9.  Countermeasures and Their Effects

   In the previous sections we described numerous vulnerabilities which
   result from splitting the AP function in two, and also discussed a
   number of adversary goals which 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.

9.1.  Communications Security Elements

9.1.1.  Mutual Authentication

   Mutual authentication consists in each side proving its identity to
   the other.  There are numerous authentication protocols which
   accomplish this, typically using either a shared secret (e.g. a
   preshared key) or by relying on a trusted third party (e.g. with
   digital credentials such as X.509 certificates).

   Strong mutual authentication accomplishes the following:

   o  helps prevent AC/WTP impersonation

   o  helps prevent MitM attacks

   o  can be used to limit DoS attacks

9.1.2.  Data Origin Authentication

   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  connection hijacking

Kelly & Clancy          Expires February 2, 2007               [Page 22]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   o  modification of control and/or user data

   o  impersonation

9.1.3.  Data Integrity Verification

   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.

9.1.4.  Antireplay

   Antireplay 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.

9.1.5.  Confidentiality

   Data confidentiality prevents eavesdropping by protecting data as it
   passes over the network.  This is typically accomplished using

9.2.  Putting the Elements Together

   Above we described various security elements and their properties.
   Below, we discuss combinations of these elements in terms of CAPWAP.

9.2.1.  Control Channel Security

   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 which mitigates almost all of
   the vulnerabilities described above.

9.2.2.  Data Channel Security

   The CAPWAP data channel contains some 802.11 management traffic
   including association/disassociation, reassociation, and
   deathentication.  It also may contain potentially sensitive user
   data.  If we assume that threats to this channel exist (i.e. it

Kelly & Clancy          Expires February 2, 2007               [Page 23]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   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.

10.  Countermeasures Provided By DTLS

   Datagram TLS (DTLS) is the currently proposed security solution for
   CAPWAP.  DTLS supports the following security functionality:

   o  Mutual Authentication (preshared secrets or X.509 Certificates)

   o  Data Origin Authentication

   o  Data Integrity Verification

   o  Antireplay

   o  Confidentiality (supports strong cryptographic algorithms)

   Using DTLS for both the control and data channels mitigates nearly
   all risks resulting from splitting the AP function in two.

11.  Issues Not Addressed By DTLS

   Unfortunately, DTLS is not a magic elixir that dispenses with all of
   our CAPWAP security concerns.  There are some things it just cannot
   prevent.  These are enumerated below.

11.1.  DoS Attacks

   Even with the security provided by DTLS, CAPWAP is still susceptible
   to various types of DoS attack:

   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  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

Kelly & Clancy          Expires February 2, 2007               [Page 24]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   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.

   These attacks can be mitigated thorugh 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.

   Session interference is probably the most difficult of DoS attacks.
   It is very difficult to detect in realtime, although it may be
   detected if exceeding a lost packet threshhold triggers an alert.
   However, this depends on the MitM not being in a position to delete
   the alert before it reaches it's appropriate destination.

11.2.  Passive Monitoring (Sniffing)

   CAPWAP protocol security cannot prevent (or detect) passive
   monitoring.  The best we can do is provide a confidentiality

11.3.  Traffic Analysis

   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

11.4.  Active MitM Interference

   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
   which 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.

11.5.  Other Active Attacks

   In addition to the issues raised above, there are other active
   attacks that can be mounted if the adversary has access to the wired

Kelly & Clancy          Expires February 2, 2007               [Page 25]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   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.

12.  References

12.1.  Normative References

   [8021X]    "IEEE Std 802.1X: Port-based Network Access Control",
              June 2001.

   [CAPWAP]   Calhoun, P., Montemurro, M., and D. Stanley, "CAPWAP
              Protocol Specification",
              draft-ietf-capwap-protocol-specification-02 (work in

   [EAP1]     Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4118]  Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy
              for Control and Provisioning of  Wireless Access Points
              (CAPWAP)", June 2005.

12.2.  Informative References

              Edney, J. and W. Arbaugh, "Real 802.11 Security - Wi-Fi
              protected Access and 802.11i", 2004.

Authors' Addresses

   Scott G. Kelly
   Aruba Wireless Networks
   1322 Crossman Ave
   Sunnyvale, CA  94089

   Email: scott@hyperthought.com

Kelly & Clancy          Expires February 2, 2007               [Page 26]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

   T. Charles Clancy
   Laboratory for Telecommunications Sciences
   8080 Greenmeade Drive
   College Park, MD  20740

   Email: clancy@ltsnet.net

Kelly & Clancy          Expires February 2, 2007               [Page 27]

Internet-Draft        CAPWAP 802.11 Threat Analysis          August 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Kelly & Clancy          Expires February 2, 2007               [Page 28]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/