Secure Handover in Enterprise WLANs

1
Secure Handover in Enterprise WLANs:
CAPWAP, HOKEY, and IEEE 802.11r
T. Charles Clancy
Electrical and Computer Engineering
University of Maryland, College Park
tcc@umd.edu
Abstract— As Wireless LANs become more and more ubiquitous, the number and types of applications they are supporting
is ever-increasing. As real-time performance requirements begin
to emerge, the latency involved in a handover from one access
point to another becomes crucial. CAPWAP and HOKEY are
two suites of protocols being defined and standardized within
the IETF that include support for fast handover. IEEE 802.11r
is implementing extensions to the IEEE 802.11 base specification
to directly support fast handover in the MAC protocol. This
article details all three protocols, and compares their relative
security properties, performance, and use cases.
I. I NTRODUCTION
The IEEE 802.11 standards [1] specifying Wireless Local
Area Networks (WLANs) have significantly changed the way
we work and access information. They were the birth of highrate wireless access to portable computers.
IEEE 802.11 has also had its share of hiccups, most notably
the specification of the Wired Equivalence Protocol (WEP).
The original designers of IEEE 802.11 had no idea the level
of security provided by WEP would be severely insufficient for
its eventual applications. As a result, Task Group i produced
the revision IEEE 802.11i [2] to provide enterprise-level
security, based on the IEEE 802.1X protocols, specifically the
Extensible Authentication Protocol (EAP) [3].
One drawback to IEEE 802.11i, however, is the length of
time it takes to authenticate to an access point (AP), due to
the execution of complex cryptographic algorithms between
the client (also known as a “station” or “STA”), AP, and backend Authentication, Authorization, and Accounting (AAA)
server. This makes it difficult to support real-time networking
protocols, such as streaming multimedia, as a mobile user
transitions from one AP to another.
A number of new protocols are working to address this
problem, each with a unique approach. Within the IETF, the
Control and Provisioning of Wireless Access Points (CAPWAP) working group is finalizing the design of a protocol
to support distributed management of an enterprise WLAN,
and one of the incorporated features is the ability to perform
fast handover between APs [4]. Also within the IETF, the
Handover Keying (HOKEY) working group is seeking to
extend the AAA architecture to support deriving and distributing security credentials without requiring a full EAP
authentication [5]. Lastly, within the IEEE, Task Group r has
developed a protocol to support passing credentials directly
between APs as a mobile STA transitions from one to the
other [6].
Each of these protocols offers a complementary approach
to solving the problem of fast handover. This article describes
each, and outlines their relative security properties. Section
II gives a quick introduction to IEEE 802.11i security, as
it is currently defined. Section III describes the CAPWAP,
HOKEY, and IEEE 802.11r protocols. Section IV investigates
their security and performance. Section V concludes.
II. IEEE 802.11 I S ECURITY
IEEE 802.11i defines the operation of a Robust Security
Network (RSN). Authentication to an AP consists of a number
of phases. The first is initial discovery between the STA and
AP, which is followed by an EAP authentication executed
between the STA and AAA server, proxied by the AP. With
respect to EAP terminology, the AP is called the authenticator, because it is responsible for using AAA protocols to
communicate with the AAA server, and is also responsible
for receiving the derived session key.
EAP supports a wide variety of authentication protocols
called methods, which are transported over EAP. These methods support a large variety of credential types, ranging from
shared keys to passwords to certificates.
Upon successful authentication, the EAP method derives a
Master Session Key (MSK) which the AAA server delivers to
the AP. The first 256 bits of the 512-bit MSK becomes the
Pairwise Master Key (PMK), and is used to derive traffic keys
(TKs) using a cryptographic handshake between the STA and
AP, called the four-way handshake.
The goal of a fast-handover protocol is to reduce the number
of round trips required in each of these stages to as few
as possible, while still preserving the security properties of
the network. The initial authentication can still follow the
full IEEE 802.11i-specified protocol, but future authentications
within the same session should be simplified, and bootstrapped
by the trust relationship established during the initial authentication.
The following section describes three new protocols that
each simplify the cryptographic handover process in different
ways.
2
TABLE I
TABLE OF HANDOVER - RELATED ACRONYMS
Acronym
AAA
AC
DSRK
EAP
EMSK
ERP
HRK
PMK
PMK-R0
PMK-R1
TK
WTP
Meaning
Authentication, Authorization, and Accounting
Access Controller
Domain-Specific Root Key
Extensible Authentication Protocol
Extended Master Session Key
EAP Reauthentication Protocol
Handover Root Key
Pairwise Master Key
Pairwise Master Key, Root Zero
Pairwise Master Key, Root One
Traffic Key
Wireless Termination Point
III. N EW P ROTOCOL S TANDARDS
In this section we detail three new protocols supporting
fast handover in mobile WLANs: CAPWAP, HOKEY, and
IEEE 802.11r. CAPWAP and HOKEY do not change the IEEE
802.11 protocol, but rather operate on the wired side of the
network, running over the Internet Protocol (IP). As such, they
are being standardized by the Internet Engineering Task Force
(IETF) in the form of Request for Comments (RFCs). IEEE
802.11r is a change to the IEEE 802.11 protocol itself, and is
therefore being completed by the IEEE.
A. CAPWAP
The goal of CAPWAP is to provide a protocol to support
enterprise WLAN environments, from corporate networks to
university campuses. It assumes all APs will be managed by
a central authority.
To support this management architecture, APs are split into
two logical components. A traditional “fat AP” implements
both the Physical (PHY) and Medium Access Control (MAC)
layers of the IEEE 802.11 protocol. With CAPWAP, the PHY
and lower portions of the MAC protocol are implemented in
“thin APs” called Wireless Termination Points (WTPs), while
the upper-MAC functionality for all APs in the enterprise
network is implemented by a centralized controller called the
Access Controller (AC).
After this split, the authentication and access control features of the IEEE 802.11 protocol now reside in the centralized
AC, allowing it to connect clients to any of the WTPs without
an EAP re-authentication. In CAPWAP, the AC acts as the
authenticator, and the AAA server has no knowledge of the
split nature of the WLAN deployment.
During an initial authentication, the STA executes an EAP
conversation with the AAA server, per standard IEEE 802.11i.
Once it completes, the resulting session key is delivered to
the AC. The AC then executes the four-way handshake with
the STA, via the WTP. Once the traffic keys are derived, the
AC securely delivers them to the WTP using the CAPWAP
protocol.
When a STA wishes to roam to a new WTP, after performing the discovery phase the AC executes a new four-way
handshake with the STA and simply delivers a new traffic key
without derivation of a new session key. Figure 1 depicts the
entire authentication and handover process.
Description
Server responsible for back-end network authentication
Network controller for CAPWAP
Root key for derivation of usage keys within a domain
IETF protocol for network authentication
Key derived by EAP used as the root HOKEY key
Protocol extending EAP to support fast reauthentication
ERP root key
Key derived by EAP used as the root IEEE 802.11 RSN key
Root key used by IEEE 802.11r
IEEE 802.11r per-AP key derived from PMK-R0
Key used to encrypt packets traversing a wireless network
Light-weight access point used in CAPWAP
B. HOKEY
Another working group of the IETF is standardizing protocols for handover keying (HOKEY). The goal is to support
both handover from one AP to another, but also support roaming between different operators. To accomplish this, HOKEY
has extended EAP to natively support fast re-authentication,
independent of the EAP method that performed the original
authentication.
The EAP Re-authentication Protocol (ERP) [7] allows a
STA to use keys derived during an initial EAP authentication to
perform a one-round-trip re-authentication to derive a session
key for a new AP. This AP then performs the IEEE 802.11i
four-way handshake with the STA to derive the traffic key.
Here, each AP in the WLAN is an independent authenticator,
and ERP allows AAA protocols to be used to generate multiple
new session keys for each, without re-executing the original
EAP method.
Another key feature of HOKEY is its ability to support
roaming. When a client tries to associate to an AP from
another network, if that network has a roaming relationship
with the STA’s home network it can proxy the authentication
to the STA’s home AAA server. HOKEY also supports fast
re-authentication to the visited network, drastically cutting the
handover time between APs in that visited network, since
credentials can be cached in a local AAA server and used
to rapidly and locally derive new session keys.
During a re-authentication to a visited network, the AAA
protocols are used to pass keys to a local HOKEY server,
typically collocated with that visited network’s AAA server.
The protocol exchange is depicted in Figure 2.
Rather than reusing any of the existing keys in the IEEE
802.11i keying hierarchy, HOKEY makes use of the Extended
Master Session Key (EMSK) which is derived during the
initial EAP authentication, and until now unused. Part of the
HOKEY group’s charter is to define a keying hierarchy based
on the EAP EMSK that can be used for generating applicationspecific keys [8]. Keys are grouped into key management
domains, each rooted by a domain-specific root key (DSRK)
generated from the EMSK, and from the DSRK we can
generate a handover root key (HRK) for re-authentication.
3
C. IEEE 802.11r
In the IEEE 802.11r protocol, the first AP a STA authenticates to will cache its PMK, and use it to derive session
keys for other APs in the same “mobility domain”. This AP
is called the R0 Key Holder (R0KH) as it holds the PMKR0, symbolizing level 0 the PMK keying hierarchy. When a
STA transitions to a different AP, the R0KH will derive a
PMK-R1 which is a new session key from the PMK-R0, and
forward that to the new AP. The new AP is termed the R1
Key Holder (R1KH). To ensure key orthogonality, the R0KH
uses the second half of the PMK, not used by the standard
four-way handshake.
The protocol between the STA and APs is a new MAClevel protocol defined by IEEE 802.11r. The exchange consists
of an initial round-trip between the AP to which the STA
is currently associated, signaling the desire to perform the
handover, followed by another single round-trip between the
STA and the new AP to confirm the proper key was derived
and delivered. This exchange also serves to derive the traffic
key, and is depicted in Figure 3.
With IEEE 802.11r, the initial AP acts as the authenticator,
communicating with the AAA server. After that, each AP
interacts with the initial AP, rather than directly with the AAA
server.
An important property of IEEE 802.11r is key management.
There needs to be a key transfer protocol between the R0KH
and the R1KH; in other words, there is either a star configuration of security associations between the key holder and
a centralized entity that serves as the R0KH, or if the first
authenticator is the default R0KH, there will be a full-mesh
of security associations between all authenticators. This could
require up to O(n2 ) keys to be managed between n APs,
and since no protocol has been defined to accomplish this it’s
unlikely that IEEE 802.11r will scale to large networks.
IV. P ROTOCOL P ROPERTIES
In this section, the relative properties of each of the three
protocols are compared and contrasted.
A. Key Hierarchies
Each protocol changes the standard IEEE 802.11i keying
hierarchy in one way or another. Figure 4 shows the keying
hierarchies for each of the three protocols, including the
original hierarchy for IEEE 802.11i. The left-most column of
the diagram indicates the purpose of the keys at that particular
level in the hierarchy.
Per RFC 4962 [9], any system that uses EAP or AAA must
have a strong set of security principles guiding its use of
keying material. One specific requirement is that the scope
and context must be defined for all keys. Scope specifies
who is authorized to possess a key, and context specifies the
intended use for that key. This motivates the key purposes
column in Figure 4. All keys are scoped for the STA, whereas
root keys are scoped for home AAA servers, domain keys are
scoped for visited AAA servers, application keys are scoped
for specific services, and traffic keys are scoped for APs.
Likewise, the context for root keys is to derive all keys in the
system, while the context for domain keys is to derive keys
within a specific domain. Application keys’ context is for that
specific service, which in this case is network authentication
or re-authentication. Traffic keys’ context is to encrypt and
authenticate network traffic.
From the diagram, we can see the relative complexity and
features of the hierarchies. HOKEY is the only hierarchy to
support domain-level keys, and as such it’s the only handover
scheme which can natively support inter-enterprise roaming.
At the application level, we can see that CAPWAP is the
simplest. Since the PMK resides at the centralized AC, it can
use it to easily derive multiple traffic keys. HOKEY generates
a handover key for each domain, which can be used to derive
the traffic keys. In IEEE 802.11r, we can see the self-forming
hierarchical nature of its application-level keys, with the R0KH
getting promoted to application root key holder to support a
particular user’s handovers.
Additionally, for all protocols we can see traffic keys are
derived from the application-level keys, whether it’s via the
four-way handshake as in CAPWAP or HOKEY, or a new
MAC protocol as in IEEE 802.11r.
Key hierarchies have a big influence in overall system
security. Any entity involved in the creation or delivery of
a key may be able to use it for unauthorized purposes. While
the protocols themselves are secure, network entities may be
attacked via other means, and their software compromised.
CAPWAP centralizes security in the AC, and compromise
of an AC yields to compromise of all session keys in the
network. HOKEY distributes keys along the AAA hierarchy,
thus compromise of any AAA entity will compromise all keys
benieth it in the keying hierarchy. IEEE 802.11r centralizes
keys in the R0KH, which could be an AP on a wall, which
would be by far the easiest to compromise. Thus from an architectural perspective, IEEE 802.11r has the weakest security
model since it pushes root keys out to the edge of the network
where the probability of compromise is greatest.
B. Handover Performance
Each protocol offers different performance benefits. First
let’s compare relative handover times for handover within
one’s home domain. Let Ne be the number of round trips
required for the execution of any particular EAP method. Let
Tw be the transmission latency between the STA and AP (or
WTP). Let Tc be the latency between any two relative close
devices in a wired LAN, including AP to AP communications
and WTP to AC communications. Finally, let Ta be the latency
between the various infrastructure components and the local
AAA server.
An initial IEEE 802.11i handover requires
2Ne (Tw + Ta ) + Ta + 4Tw
(1)
Breaking down each term, the first represents the time to
complete the EAP authentication, the second is the time to
distribute the MSK to the AP, and the third is the time for the
four-way handshake.
Examining a CAPWAP handover, we obtain
4(Tw + Tc ) + Tc
(2)
4
which covers the four-way handshake executed between the
STA and AC, and then key distribution to the WTP.
For HOKEY, we have
2(Tw + Ta ) + 4Tw
(3)
which includes the single round trip execution of ERP, which
automatically delivers the HRK, followed by the four-way
handshake.
Lastly, for IEEE 802.11i we have
2Tw + 2Tc + 2Tw
(4)
representing the initial handover request, back-end key distribution, and final key handshake at the destination AP.
Using numbers typical of many network deployments, Tw =
15µs, Tc = 5µs, and Ta = 20µs [10], we get a CAPWAP
handover time of 85µs, HOKEY handover time of 130µs,
and an IEEE 802.11r handover time of 70µs (see Figure 5).
IEEE 802.11r and CAPWAP are the clear winners, but if you
compare that to a full IEEE 802.11i authentication using an
EAP method that requires 4 round trips, you’ll see that all
those numbers are far less than 360µs.
While HOKEY may have worse intra-domain handover
performance than CAPWAP and IEEE 802.11r, it really shines
when it comes to cross-domain handovers. No other protocol
supports handing credentials from one authenticator to another,
whether that authenticator is in the same domain or a remote
one. With intercontinental latencies across the Internet ranging
from 100 ms to 300 ms [11], local handover using a local
AAA server that has cached your credentials is a significant
improvement in wireless handover times. Also, no protocol
other than HOKEY could support cross-technology handover,
e.g. WLAN to WMAN, or WLAN to 3G handover.
An important thing to conclude is that all three handover
protocols have roughly similar performance, and all perform
significantly better than systems without handover. All three
will offer end users a similar experience; however, each has
substantially different requirements on the back-end infrastructure. Thus network operators should select a handover protocol
based on their usage model, and not based on which one
performs handovers in the least amount of time.
C. Usage Scenarios
All handover protocols require the same order of magnitude
of time to execute, thus time cannot be a major distinguishing
factor. However, given the unique security properties of each
protocol, each is geared for use in a different environment. A
summary of the use cases is presented in Table II.
CAPWAP is designed to simplify deployment and management of an enterprise WLAN infrastructure. The ability to
do fast handover is a side effect of centralizing access point
control. There are a variety of other use cases for CAPWAP,
but they all generally involve extending an enterprise network
to some other geographic location by tunneling CAPWAP over
the Internet, allowing a telecommuter, for example, to have an
AP at home that provides them direct access to their corporate
network.
HOKEY, on the other hand, is more geared for serviceprovider networks, rather than enterprise networks. Its inherent
support for roaming makes it well suited for that environment.
Additionally, there are some specifics about how HOKEY
deals with the AAA protocol, and its inability to easily prevent
exposure of STA keying material to AAA proxies makes it less
appropriate for an enterprise network where these proxies are
at a greater risk of compromise. In a service-provider network
these proxies are inherently trusted, which makes any possible
attack less probable.
IEEE 802.11r is well suited for WLAN environments that
are not centrally managed, or require extremely-low-latency
handover performance. Requiring pairwise keys between all
APs participating in the mobility domain makes it difficult to
scale to a large number of APs.
Lastly, there is no reason you couldn’t use HOKEY in
conjunction with either CAPWAP or IEEE 802.11r. HOKEY
can derive application keys for a particular domain, and deliver
them to either an AC or an R0KH.
V. C ONCLUSION
This article provided a high-level introduction to three
emerging protocols for WLANs to support fast mobile handover between access points. Each protocol operates differently, and seeks to optimize different parts of the authentication process, and consequently they have different security
properties, performance characteristics, and use cases. Over
the next 12 months, all three standards should be finalized
and should start appearing in commercial equipment soon
thereafter.
R EFERENCES
[1] IEEE 802.11, “Wireless LAN medium access control and physical layer
specification,” 2007.
[2] IEEE 802.11i, “Wireless LAN medium access control and physical layer
specification: Ammendment for enhanced security,” 2004.
[3] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz,
“Extensible authentication protocol,” RFC 3748.
[4] B. O’Hara, P. Calhoun, and J. Kempf, “Configuration and provisioning
for wireless access points problem statement,” RFC 3990.
[5] T. Clancy, M. Nakhjiri, V. Narayanan, and L. Dondeti, “Handover key
management and re-authentication problem statement,” RFC 5169.
[6] IEEE 802.11, “Wireless LAN medium access control and physical layer
specification: Ammendment for fast bss transition,” Draft D-7, 2007.
[7] V. Narayanan and L. Dondeti, “Eap extensions and eap re-authentication
protocol,” draft-ietf-hokey-erx-14.
[8] J. Salowey, L. Dondeti, V. Narayanan, and M. Nakhjiri, “Specification
for the derivation of root keys from an extended master sesssion key,”
draft-ietf-hokey-emsk-hierarchy-05.
[9] R. Houseley and B. Aboba, “Guidance for authentication, authorization,
and accouting key management,” RFC 4962, BCP 132.
[10] A. Mishra, M. Shin, and W. Arbaugh, “An emperical analysis of the
ieee 802.11 mac-layer handoff process,” ACM SIGCOMM Computer
and Communications Review, 2003.
[11] J. Ledlie, P. Gardner, and M. Selter, “Network coordinates in the wild,”
USENIX Symposium on Networked System Design and Implementation
2007.
— Dr. Charles Clancy is a senior researcher with the
Laboratory for Telecommunications Sciences, and an adjunct
professor of Electrical Engineering at the University of
Maryland. He received his M.S. in Electrical Engineering
5
TABLE II
S UMMARY OF THE USE CASES FOR VARIOUS HANDOVER PROTOCOLS
Protocol
Approach
Use Case
HOKEY
AAA extension
CAPWAP
MAC centralization
IEEE 802.11r
MAC extension
service provider wireless networks
e.g. WLAN hotspot providers, 3G/4G cellular networks
enterprise WLAN wireless networks
e.g. large corporate or university networks
unmanaged WLAN wireless networks
e.g. residential or small office networks
from the University of Illinois and Ph.D. in Computer Science
from the University of Maryland. He chairs the HOKEY
working group and is the security advisor to the CAPWAP
and EAP working groups of the IETF. His research interests
include next-generation wireless networks and security.
Deployment
Requirements
new STA drivers,
APs, AAA server
new APs
new STA hardware,
STA drivers, and APs
Key Features
support for roaming and
intertechnology handover
easiest to deploy
best performance
6
1) Execution of EAP method between STA and
AAA server
2) Key distribution from the AAA server to the
authenticator, the AC
3) Four-way handshake executed between STA
and AC
4) CAPWAP Add-Mobile message from AC to
WTP1 with traffic key
5) STA wishes to handover to WTP2 ; executes
four-way handshake with AC via WTP2
6) CAPWAP Add-Mobile message from AC to
WTP2 with traffic key
7) STA wishes to handover to WTP3 ; executes
four-way handshake with AC via WTP3
8) CAPWAP Add-Mobile message from AC to
WTP3 with traffic key
Fig. 1.
CAPWAP architecture, showing an initial authentication followed by a handover of a STA from one WTP to another
1) Execution of EAP method between STA and
home AAA server
2) Key distribution from the AAA server to the
AP1
3) Four-way handshake executed between STA
and AP1
4) STA wishes to handover to AP2 in another
domain; executes ERP with local AAA server
5) Local AAA server requests and receives a
domain-specific re-authentication key
6) Local AAA server generates session key and
delivers it to AP2
7) STA executes four-way handshake with AP2
8) STA wishes to handover to AP3 ; executes ERP
with local AAA server
9) Local AAA server uses domain-specific reauthentication key to derive a session key for
AP3 , and delivers it
10) STA executes four-way handshake with AP3
Fig. 2.
HOKEY authentication, re-authentication, and re-authentication to a visited network
7
1) Execution of EAP method between STA and
home AAA server
2) Key distribution from the AAA server to the
AP1 , termed R0 Key Holder (R0KH)
3) Four-way handshake executed between STA
and AP1
4) STA wishes to handover to AP2 ; requests handover from AP1 to AP2
5) AP1 generates session key for AP2 , termed the
R1KH, and transfers it
6) STA completes handover by executing protocol
with AP2 and derives traffic key
7) STA wishes to handover to AP3 ; requests handover from AP2 to AP3
8) AP2 asks AP1 to generate a session key for AP3
9) AP1 transfers session key to AP3
10) STA completes handover by executing protocol
with AP3 and derives traffic key
Fig. 3.
Protocol exchanges for handing over between APs in an IEEE 802.11r-enabled WLAN
Fig. 4.
Keying hierarchies for CAPWAP, HOKEY, and IEEE 802.11r, as compared to the original IEEE 802.11i hierarchy
8
Fig. 5.
Comparison of handover times of CAPWAP, HOKEY and IEEE 802.11r, as compared to IEEE 802.11