Network Working Group S. Kelly
Internet-Draft Airespace
Expires: February 19, 2004 D. Molnar
Legra Systems
August 21, 2003
Security Requirements for a Light Weight Access Point Protocol
draft-kelly-ietf-lwapp-sec-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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-
Drafts.
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 http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 19, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
LWAPP defines the interactions of wireless lan infrastructure
components, including access points (APs) and access routers (ARs).
The AR represents a centralized point of management control in such
infrastructures, implying critical control signalling between APs and
ARs. Given the open nature of WLANs, a careful analysis of security
threats is required, and appropriate security countermeasures must be
defined. This document provides a security analysis and makes
recommendations for securing LWAPP
Kelly & Molnar Expires February 19, 2004 [Page 1]
Internet-Draft LWAPP Security Requirements August 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. LWAPP Architecture and Topology . . . . . . . . . . . . . 4
3. WLAN Security Termination . . . . . . . . . . . . . . . . 4
4. WLAN Security Architecture Naming Convention . . . . . . . 5
5. Topological Assumptions . . . . . . . . . . . . . . . . . 5
5.1 Directly Connected . . . . . . . . . . . . . . . . . . . . 6
5.2 Switched Connections . . . . . . . . . . . . . . . . . . . 7
5.3 Routed Connections . . . . . . . . . . . . . . . . . . . . 8
6. Capabilities of Adversary . . . . . . . . . . . . . . . . 10
6.1 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Packet Modification . . . . . . . . . . . . . . . . . . . 10
6.2.1 Packet Injection . . . . . . . . . . . . . . . . . . . . . 10
6.2.2 Packet Deletion . . . . . . . . . . . . . . . . . . . . . 10
6.2.3 Packet Reordering . . . . . . . . . . . . . . . . . . . . 10
6.2.4 Packet Redirection . . . . . . . . . . . . . . . . . . . . 10
6.2.5 Packet Reflection . . . . . . . . . . . . . . . . . . . . 10
6.2.6 Session Replay . . . . . . . . . . . . . . . . . . . . . . 11
6.3 Address Spoofing . . . . . . . . . . . . . . . . . . . . . 11
6.4 MiM Attack . . . . . . . . . . . . . . . . . . . . . . . . 11
6.5 Password Guessing/Dictionary Attacks . . . . . . . . . . . 11
6.6 Corruption of Auxiliary Network Services . . . . . . . . . 11
6.6.1 DCHP Takeover . . . . . . . . . . . . . . . . . . . . . . 11
6.6.2 DNS Takeover . . . . . . . . . . . . . . . . . . . . . . . 11
7. Adversary Goals . . . . . . . . . . . . . . . . . . . . . 11
7.1 Associate Unauthorized AP with Legitimate AR . . . . . . . 12
7.2 Associate Unauthorized AR with Legitimate AP . . . . . . . 12
7.3 De-associate authorized AP and AR . . . . . . . . . . . . 12
7.4 DoS attacks . . . . . . . . . . . . . . . . . . . . . . . 12
7.5 Eavesdropping on AP Control Data . . . . . . . . . . . . . 12
7.6 Modification of AP Control Data . . . . . . . . . . . . . 12
7.7 Eavesdropping on AR Control Data . . . . . . . . . . . . . 12
7.8 Modification of AR Control Data . . . . . . . . . . . . . 13
8. Adversary Scenarios . . . . . . . . . . . . . . . . . . . 13
8.1 Rogue AP . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2 Rogue AR . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.3 AP Takeover . . . . . . . . . . . . . . . . . . . . . . . 13
8.4 AR Takeover . . . . . . . . . . . . . . . . . . . . . . . 13
8.5 Passive Adversary between AR and AP . . . . . . . . . . . 13
8.6 Active Adversary between AR and AP . . . . . . . . . . . . 14
9. Countermeasures . . . . . . . . . . . . . . . . . . . . . 14
9.1 Secure Association . . . . . . . . . . . . . . . . . . . . 14
9.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 14
9.3 Secure Discovery . . . . . . . . . . . . . . . . . . . . . 15
9.4 Integrity Verification . . . . . . . . . . . . . . . . . . 15
9.4.1 Control Traffic . . . . . . . . . . . . . . . . . . . . . 16
9.4.2 Data Traffic . . . . . . . . . . . . . . . . . . . . . . . 16
Kelly & Molnar Expires February 19, 2004 [Page 2]
Internet-Draft LWAPP Security Requirements August 2003
9.5 Anti-replay . . . . . . . . . . . . . . . . . . . . . . . 16
9.5.1 Control Traffic . . . . . . . . . . . . . . . . . . . . . 17
9.5.2 Data Traffic . . . . . . . . . . . . . . . . . . . . . . . 17
9.6 Confidentiality . . . . . . . . . . . . . . . . . . . . . 17
9.6.1 Control Traffic . . . . . . . . . . . . . . . . . . . . . 17
9.6.2 Data Traffic . . . . . . . . . . . . . . . . . . . . . . . 18
10. Additional Security Requirements . . . . . . . . . . . . . 18
10.1 Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 18
10.1.1 Key Establishment . . . . . . . . . . . . . . . . . . . . 18
10.1.2 Key Naming . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1.3 Key Freshness . . . . . . . . . . . . . . . . . . . . . . 18
10.2 Privilege Separation . . . . . . . . . . . . . . . . . . . 18
10.3 Firewall/NAT Considerations . . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . 19
12. Intellectual Property . . . . . . . . . . . . . . . . . . 19
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . 21
Kelly & Molnar Expires February 19, 2004 [Page 3]
Internet-Draft LWAPP Security Requirements August 2003
1. Introduction
LWAPP defines the interactions of wireless lan infrastructure
components, including access points (APs) and access routers (ARs).
For a complete description of this protocol, see [LWAPP]. The
primary goal of LWAPP is to centralize much of the non-PHY WLAN
processing at the AR, thereby enabling scalable, manageable
deployments of lightweight APs.
The AR represents a centralized point of management control in such
infrastructures, implying critical control signalling between APs and
ARs. All WLAN data traffic must transit between ARs and APs as well.
Given the security concerns surrounding wireless access, it seems
prudent to consider the associated security vulnerabilities and
threats, and to define appropriate countermeasures. This document
provides a security analysis and makes recommendations for securing
LWAPP.
2. LWAPP Architecture and Topology
For a complete definition of the LWAPP architecture, see [LWAPP].
For convenience, the following figure is copied from that document:
---------------------------------------------------------------------
+-+ 802.11frames +-+
| |--------------------------------| |
| | +-+ | |
| |--------------| |---------------| |
| | 802.11 PHY/ | | LWAPP | |
| | MAC sublayer | | | |
+-+ +-+ +-+
STA AP AR
Figure 1: LWAPP Architecture
---------------------------------------------------------------------
LWAPP encompasses control and data traffic flowing bidirectionally
between the AP and the AR. Note that some topological subtleties
exist which are not called out by the above diagram. These are
discussed in the following sections.
3. WLAN Security Termination
The IEEE 802.11 specification family [802.11] defines multiple
security mechanisms, including WEP, 802.1x, and 802.11i. In
Kelly & Molnar Expires February 19, 2004 [Page 4]
Internet-Draft LWAPP Security Requirements August 2003
addition, the WiFi consortium defines WPA as an interim step between
WEP and 802.11i. In non-LWAPP deployments, these protocols interact
with the mobile station (STA) and the AP, and also with an
Authentication Server (AS) in the case of 802.1x. LWAPP entails
delegation of some or all of the AP's roles in these mechanisms to
the AR.
For example, WEP associations are historically between STA and AP,
but with LWAPP, the association may be between STA and AR if desired.
802.1x associations are historically a 3-way conversation between
STA, AP, and AS, but with LWAPP, these are more typically between
STA, AR and AS. Hence, the introduction of LWAPP entails
modifications to security termination points which may introduce new
security concerns.
4. WLAN Security Architecture Naming Convention
For convenience, we now define names for some possible WLAN security
architectures. This naming is not meant to be exhaustive; we only
give a few possible architectures that can help illustrate the
security impact of MAC-splitting decisions.
These architectures are:
SAAP - standalone AP terminates all L2 security
ARCH1 - terminate WEP/WPA/802.11i/802.1x at the AR
ARCH2 - terminate WEP/WPA/802.11i at the AP, 802.1x at the AR
ARCH3 - terminate WEP/WPA/802.11i/802.1x at the AP
Note that we could also define an architecture wherein WEP/WPA/
802.11i are terminated at the AR, and 802.1x is terminated at the AP,
but this seems nonsensical, and so it is not defined.
Note that LWAPP is irrelevant for the SAAP architecture, but that
architecture is included for completeness.
5. Topological Assumptions
LWAPP assumes that the AR and AP are within the same administrative
domain, i.e. they are owned/controlled by the same entity. LWAPP
makes no topological assumptions beyond these, meaning there are
several topologies which must be considered for our purposes. These
are discussed below, along with the interactions between each
topology and different WLAN security architectures
Kelly & Molnar Expires February 19, 2004 [Page 5]
Internet-Draft LWAPP Security Requirements August 2003
5.1 Directly Connected
The first topology we consider is one in which APs are directly
connected to an AR:
---------------------------------------------------------------------
-------+------ LAN
|
+-------+-------+
| + + AR + + |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +--+--+
| AP | | AP |
+--+--+ +--+--+
Figure 2: Directly Connected
---------------------------------------------------------------------
In this case, a direct layer 2 connection exists between the AP and
AR, and an adversary must penetrate the direct connection in order to
access the AP-AR traffic. While such physical access is possible,
the risk of such access may be low enough to be acceptable in
specific situations.
In the case of ARCH1, security for STA-AR data traffic is provided by
the WPA/802.11i MAC functionality in addition to physical access
control. Note that this effectively provides security for AP-AR data
traffic. Security for AP-AR control traffic is not provided by any
MAC layer functionality; additional mechanisms must be employed if
assurances beyond physical security are desired
In the case of ARCH2, security provided by 802.11i/WPA MAC
functionality for data traffic is strictly between STA and AP; data
and control traffic between AP and AR rely primarily on physical
access control. If assurances beyond physical security are desired
for this region, additional mechanisms must be employed for both data
and control traffic. For example, IPsec may be used between STA and
AR to secure AP-AR data traffic, but the issue remains for control
traffic. Because 802.1x traffic terminates at the AR, security of
this traffic depends on the EAP method used; if a method such as EAP-
TLS is employed, then access to the AP-AR traffic is less of a
concern
Kelly & Molnar Expires February 19, 2004 [Page 6]
Internet-Draft LWAPP Security Requirements August 2003
The case of ARCH3 is similar to the case of ARCH2, except now all
802.1x traffic terminates at the AP. This may imply that 802.1x
provisioning information is pushed from the AR to the AP, or it may
imply that the AP will form separate connections with back-end AAA
servers. In any case, physical security provides the primary
assurance for communications between AP and the rest of the network.
5.2 Switched Connections
---------------------------------------------------------------------
-------+------ LAN
|
+-------+-------+
| + + AR + + |
+----+-----+----+
| |
+---+ +---+
| |
+--+--+ +-----+-----+
| AP | | Switch |
+--+--+ +---+-----+-+
| |
+--+--+ +----+
| AP | |
+--+--+ +--+---+
| host |
+------+
Figure 3: Switched Connections
---------------------------------------------------------------------
This case is (almost) functionally identical to the directly
connected case. For all practical purposes, a direct layer 2
connection exists between the AP and AR. The primary difference is
that other systems may also be "directly" connected to the AR, and
intermingling traffic with the AP on that medium. In this case,
there are additional security considerations because these systems
potentially have access to the AP-AR traffic, and may be
indistinguishable from a valid AP or AR
In the case of ARCH1, security for STA-AR data traffic is provided by
the 802.11i MAC functionality in addition to physical access control.
Security for AP-AR control traffic is not provided by any MAC layer
functionality; additional mechanisms must be employed if assurances
beyond physical security are desired. Note that in this case,
Kelly & Molnar Expires February 19, 2004 [Page 7]
Internet-Draft LWAPP Security Requirements August 2003
security of control traffic relies on the security of all systems
with access to AP-AR traffic
In the case of ARCH2, security for the STA-AR data traffic relies on
the security of AP-AR data traffic,and both AP-AR data and control
traffic rely primarily on physical access control. If assurances
beyond physical security are desired, additional mechanisms must be
employed for both data and control traffic. For example, IPsec may
be used between STA and AR to secure user data traffic, but this does
nothing to secure AP-AR control traffic. Because 802.1x traffic
terminates at the AR, security of his traffic depends on the EAP
method used; if a secure method such as EAP-TLS is employed, then
access to the AP-AR traffic is perhaps less of a concern
The case of ARCH3 is similar to the case of ARCH2, except now all
802.1x traffic terminates at the AP. This may imply that 802.1x
provisioning information is pushed from the AR to the AP, or it may
imply that the AP will form separate connections with back-end AAA
servers. In any case, physical security provides the primary
assurance for communications between AP and the rest of the network;
if switches on the subnet are considered untrustworthy, additional
mechanisms will be required
5.3 Routed Connections
Kelly & Molnar Expires February 19, 2004 [Page 8]
Internet-Draft LWAPP Security Requirements August 2003
---------------------------------------------------------------------
+-------+-------+
| + + AR + + |
+-------+-------+
|
--------+------ LAN
|
+-------+-------+
| router |
+-------+-------+
|
-----+--+--+--- LAN
| |
+---+ +---+
| |
+--+--+ +--+--+
| AP | | AP |
+--+--+ +--+--+
Figure 4: Routed Connections
---------------------------------------------------------------------
This case is considerably different than the direct and switched
cases. Routed connections imply a layer 3 connection between the AP
and AR. Additionally, there may be other systems on either LAN
segment. If there are, this introduces additional security
considerations, because these systems have access to AP-AR traffic,
and may be indistinguishable from APs/ARs. It is also possible for a
mix of links with different security properties to be employed
between the AP and AR; some links may even be wireless. Under such
circumstances, it may be appropriate to treat the connection between
AP and AR as untrusted
In the case of ARCH1, security for STA-AR data traffic is provided by
the 802.11i MAC functionality. Security for AP-AR control traffic is
not provided by any MAC layer functionality; additional mechanisms
must be employed if security is desired
In the case of ARCH2, security for the STA-AR data traffic relies on
the security of AP-AR data traffic. If security is desired,
additional mechanisms must be employed for both control and data
traffic between the AP and AR. For example, IPsec may be used to
secure user data between STA and AR. In the case of 802.1x traffic
passing from STA to AR, protection depends on the EAP method used;
unencrypted methods such as EAP-MD5 should not be used under these
Kelly & Molnar Expires February 19, 2004 [Page 9]
Internet-Draft LWAPP Security Requirements August 2003
circumstances
The case of ARCH3 is similar to the case of ARCH2, except now all
802.1x traffic terminates at the AP. This may imply that 802.1x
provisioning information is pushed from the AR to the AP, or it may
imply that the AP will form separate connections with back-end AAA
servers. Additional mechanisms beyond physical security should then
provide the primary assurance for communications between AP and the
rest of the network.
6. Capabilities of Adversary
We now enumerate capabilities of adversaries in this setting.
Different adversaries may have different mixes of capabilities. When
specifying security mechanisms, it is important to state precisely
which adversaries are defended against
6.1 Eavesdropping
An adversary may read traffic on a link.
6.2 Packet Modification
An adversary may modify packets on a link. There are several special
cases of this capability
6.2.1 Packet Injection
The adversary may add arbitrary packets to the link. These packets
are not constrained to follow any particular standard format.
6.2.2 Packet Deletion
The adversary may delete a packet from the link; the packet is
dropped and never reaches its destination
6.2.3 Packet Reordering
The adversary may reorder packets or delay packets indefinitely.
6.2.4 Packet Redirection
The adversary may send a packet intended for one recipient to another
recipien
6.2.5 Packet Reflection
The adversary may re-address a packet to its original sender.
Kelly & Molnar Expires February 19, 2004 [Page 10]
Internet-Draft LWAPP Security Requirements August 2003
6.2.6 Session Replay
The adversary may record messages on a link between two parties and
then replay half the conversation later to one of the parties.
6.3 Address Spoofing
The adversary may change its network address (e.g. IP or MAC
address) arbitraril
6.4 MiM Attack
The adversary may pose as an AP or an AR and negotiate a connection
that "passes through" the adversary. This adversary may be situated
between a legitimate AP-AR pair, or it may terminate one end of the
AP-AR connection itself
6.5 Password Guessing/Dictionary Attacks
In scenarios where passwords are used, the adversary may attempt to
guess passwords and employ password dictionaries.
6.6 Corruption of Auxiliary Network Services
6.6.1 DCHP Takeover
The adversary may take over a DHCP server on any subnet it likes.
Alternatively, the adversary sets up its own DHCP server and responds
more quickly than the "real" DHCP server
6.6.2 DNS Takeover
The adversary may take over a DNS server or respond more quickly than
the real DNS server
7. Adversary Goals
This section contains an overview of some likely goals of an
adversary. While we cannot always know with certainty all the ways
in which an adversary might behave, we can anticipate certain actions
based on a knowledge of higher-level objectives in conjunction with
the constraints of the problem space.
We should note that it is sometimes difficult to anticipate precisely
how exploits might be combined to compromise a system, and so we must
exercise caution when considering dismissal of some goal which, taken
by itself, might seem trivial and uninteresting. With this in mind,
we review the following list of likely adversarial objectives
Kelly & Molnar Expires February 19, 2004 [Page 11]
Internet-Draft LWAPP Security Requirements August 2003
7.1 Associate Unauthorized AP with Legitimate AR
Such APs may be used in MiM attacks, or to facilitate unauthorized
network access
7.2 Associate Unauthorized AR with Legitimate AP
Unauthorized ARs may be used in MiM attacks on 802.1x, or may be used
to associate stations with unauthorized networks
7.3 De-associate authorized AP and AR
This attack could be used as part of a MiM scheme (de-associate
authorized device, re-associate with unauthorized device), or as a
DoS
7.4 DoS attacks
For this category, we concentrate on DoS attacks which are LWAPP-
specific, such as de-associating an AP-AR pair, corrupting LWAPP
protocol setup packets, and other actions which disrupt AP-AR (and by
extension, STA-AR) communications. This class does not include
general DoS attacks such as LAN saturation, ping floods, etc. which
LWAPP cannot address
7.5 Eavesdropping on AP Control Data
AP control data includes AP configuration, which might contain
credentials, security parameters, firmware, or RF parameters, to name
a few things. Knowledge of such values could provide an attacker
with facilitating information.
7.6 Modification of AP Control Data
Modification of AP control data may permit an attacker to take
control of the AP to varying degrees. This might be used to
facilitate DoS or MiM attacks, or takeover of an AP (if control data
includes AP firmware)
7.7 Eavesdropping on AR Control Data
AR control data includes AR configuration, which might contain
credentials, security parameters, and various other things.
Knowledge of such values could provide an attacker with facilitating
information
Kelly & Molnar Expires February 19, 2004 [Page 12]
Internet-Draft LWAPP Security Requirements August 2003
7.8 Modification of AR Control Data
Modification of AR control data may permit an attacker to take
control of the AR to varying degrees. This might be used to
facilitate DoS or MiM attacks
8. Adversary Scenarios
We now define specific adversary scenarios in which a network is
attacked. Documents defining LWAPP security mechanisms should be
able to "walk through" how the mechanism interacts with each of these
scenarios. In particular, adversary goals that the mechanism does
and does not permit in each scenario should be spelled out.
8.1 Rogue AP
The adversary obtains a "clean" AP and connects to the network
without being authorized by the network administrator
8.2 Rogue AR
The adversary obtains a "clean" AR and connects to the network
without being authorized by the network administrator.
8.3 AP Takeover
In the Rogue AP scenario, the AP has no preexisting relationship with
any STA or AR on the network. In the AP Takeover scenario, an
adversary gains control of an AP with existing security
relationships. This takeover may occur due to password leakage,
buffer overflow in the AP software, compromise or injection of an AP
firmware download, or other reasons
8.4 AR Takeover
In the Rogue AR scenario, the AR had no preexisting relationship with
any STA or AR on the network. In the AR Takeover scenario, an
adversary gains control of an AP with existing security
relationships. This takeover may occur due to password leakage,
buffer overflow in the AR software, or other reasons
8.5 Passive Adversary between AR and AP
In this scenario, an adversary has the capability of eavesdropping on
any link between AR and AP, but does not have the capability to
modify packets
Kelly & Molnar Expires February 19, 2004 [Page 13]
Internet-Draft LWAPP Security Requirements August 2003
8.6 Active Adversary between AR and AP
In this scenario, an adversary may eavesdrop and/or modify packets on
any link between AR and AP. Such modification may include injection,
deletion, reflection, reordering, or replay. The attacker may effect
a MiM attack or a DoS attack
9. Countermeasures
9.1 Secure Association
Just as strong authentication is a precursor for integrity
verification, a secure association mechanism is a precursor to
authentication. Assuming that an AR is always situated between an AP
and the wired network, prevention of Rogue AP/AR deployment comes
down to a single question: how do an AR and AP determine that they
should associate with each other? There must be a mechanism for
forming a "secure association" between AR and AP that has these
properties
1) Association between an AR and AP occurs only when intended by
the network administrator
2) Once formed, the secure association can only be torn down if
the administrator authorizes it, the AP fails, or the AR fails; no
third party can cause disassociation of the AR and AP
There are numerous ways in which a secure association might be
created, and a detailed discussion of such mechanisms is beyond the
scope of this document. However, such a mechanism is a prerequisite
to AP-AR authentication
9.2 Authentication
Strong AP-AR authentication is a precursor to per-packet integrity
verification, so to fully understand its impact, we must examine its
benefits alone and in conjunction with integrity verification. In
this section, we review it as a stand-alone mechanism only -
integrity verification is reviewed fully in section 6.4
- Associate Unauthorized AP with Legitimate AR (7.1)
- Associate Unauthorized AR with Legitimate AP (7.2)
- De-associate authorized AP and AR (7.3)
This provides protection against the following adversary scenarios:
Kelly & Molnar Expires February 19, 2004 [Page 14]
Internet-Draft LWAPP Security Requirements August 2003
- Rogue AP (8.1); if an AP-AR association is strongly
authenticated, the rogue AP cannot form an unauthorized
association.
- Rogue AR (8.2); if an AP-AR association is strongly
authenticated, the rogue AR cannot form an unauthorized
association.
Again, we must emphasize that due to the fact that it is required for
per-packet integrity verification and reliable cryptographic key
exchange, strong authentication has significant consequences beyond
these, and it must be considered in that context. Integrity
verification is reviewed below in section 6.x.
9.3 Secure Discovery
In addition to methods for creating a secure association, AP's and
AR's must have some method for dynamically discovering such
associations. An AP deployed in a network must discover at least one
AR with which it has established a secure association. The
mechanisms for this discovery should not return information
concerning ARs that cannot form a secure association with the AP. An
adversary should also be unable to use discovery to switch one AR
with another AR that also can securely associate with the AP.
9.4 Integrity Verification
At minimum, integrity verification mechanisms assure us that the data
has not been modified in transit. There are simple integrity
verification mechanisms which require no prior relationship between
the endpoints, e.g. a CRC checksum. While such mechanisms are
helpful in detecting transmission errors and the like in a non-
hostile environment, they are of little use in the face of an
adversary. This is because the adversary can modify the data and
then simple recompute the Integrity Check Value (ICV)
In order to protect against such malicious tampering, we must have a
mechanism for ICV computation which is not available to the attacker.
Typically, this is accomplished by adding some sort of secret which
is shared only by the authorized endpoints into the ICV computation.
An example of such a ICV method using a shared secret is HMAC-SHA1
HMAC [3]
Regardless of whether integrity-related secrets are manually
configured or dynamically created, associated integrity mechanisms
have an added benefit: they provide data origin authentication. This
means that when we verify the ICV associated with the data, not only
are we sure that the data was not modified in transit, but we also
Kelly & Molnar Expires February 19, 2004 [Page 15]
Internet-Draft LWAPP Security Requirements August 2003
have some assurance regarding its origin
Per-packet integrity verification may be applied to all traffic, or
it may be selectively applied to control traffic or data traffic.
Different attacker goals and scenarios are affected, depending on our
choice in this regard. These are treated separately below.
9.4.1 Control Traffic
Integrity protection for LWAPP signalling interferes with the
following adversary goals
- DoS attacks (7.4); some DoS attacks are prevented due to the data
origination verification provided as a benefit of integrity
verification
- Modification of AP Control Data (7.8); the ICV prevents
modification of in-transit packets, and also prevents injection of
invalid packets.
This provides protection against the following adversary scenarios:
- Rogue AP (8.1); this is prevented due to the data origination
verification provided as a benefit of integrity verification.
- Rogue AR (8.2); this is prevented due to the data origination
verification provided as a benefit of integrity verification.
9.4.2 Data Traffic
Integrity protection for LWAPP data traffic interferes with the
following adversary goals:
- Modification of user Data (7.6); the ICV prevents modification of
in-transit packets, and also prevents injection of invalid packets
This provides protection against the following adversary scenarios:
- Active Adversary Between AR and AP (8.6); this is prevented due
to the data origination verification provided as a benefit of
integrity verification.
9.5 Anti-replay
This feature entails a mechanism for preventing the replay of valid
traffic. It is typically implemented through inclusion of an
Kelly & Molnar Expires February 19, 2004 [Page 16]
Internet-Draft LWAPP Security Requirements August 2003
authenticated sequence number in each packet.
9.5.1 Control Traffic
Integrity-protected anti-replay protection for LWAPP control traffic
interferes with the following adversary goals:
- Replay of AP Control Data (7.8); replayed control data could be
used to cause the AP to revert to a previous (exploitable) state
This provides protection against the following adversary scenarios:
- Rogue AP (8.1); if an adversary can replay discovery and
association packets, it may be able to impersonate a valid AP.
- Active Adversary Between AR and AP (8.6)
9.5.2 Data Traffic
Integrity-protected anti-replay protection for LWAPP data traffic
interferes with the following adversary goals
- Replay of AP Control Data (7.8); replayed control data could be
used to cause the AP to revert to a previous (exploitable) state
This provides protection against the following adversary scenarios:
- Active Adversary Between AR and AP (8.6)
9.6 Confidentiality
Data confidentiality involves rendering the data unreadable to all
but the authorized parties. It should be noted that data
confidentiality cannot be effectively provided without also providing
a data integrity function.
9.6.1 Control Traffic
Confidentiality protection for LWAPP control traffic interferes with
the following adversary goals
- Eavesdropping on user data (7.5); an adversary could use
knowledge gained from control data to facilitate an attack on the
AP/AR
This provides protection against the following adversary scenarios:
Kelly & Molnar Expires February 19, 2004 [Page 17]
Internet-Draft LWAPP Security Requirements August 2003
- Passive Adversary Between AR and AP (8.5)
- Active Adversary Between AR and AP (8.6)
9.6.2 Data Traffic
Confidentiality protection for LWAPP data traffic interferes with the
following adversary goals
- Eavesdropping on user data (7.5); an adversary could use
knowledge gained from control data to facilitate an attack on the
AP/AR
This provides protection against the following adversary scenarios:
- Passive Adversary Between AR and AP (8.5);
- Active Adversary Between AR and AP (8.6)
10. Additional Security Requirements
10.1 Cryptographic Keys
10.1.1 Key Establishment
Confidentiality and integrity verification mechanisms require
cryptographic keys. It is possible to establish such keys via manual
configuration or dynamic key exchange. Given that some deployments
may be very large, scalability issues associated with manual
configuration imply the need to support dynamic key establishment
mechanisms along with manual mechanisms
10.1.2 Key Naming
Each key in a security mechanism must be explicitly named. This name
facilitates the management and revocation of keys
10.1.3 Key Freshness
Keys in a security mechanism should be refreshed. The exact details
of when to refresh may depend on adminstrator policy and the specific
security mechanisms used
10.2 Privilege Separation
Takeover of any component of the system (STA, AP, or AR) should
Kelly & Molnar Expires February 19, 2004 [Page 18]
Internet-Draft LWAPP Security Requirements August 2003
compromise the minimum possible number of additional components. In
particular, compromise of an AP should yield no key material or other
data protecting the control or data transport of any other AP
10.3 Firewall/NAT Considerations
Security mechanisms should strive to avoid bad interactions with
firewall and NAT techniques. When interactions exist, they should be
clearly documented
11. Security Considerations
The topic of this document is LWAPP security requirements, so no
separate security considerations discussion is required
12. Intellectual Property
Since this is strictly an informational requirements document, there
are no associated intellectual property rights
13. Acknowledgements
We thank Russ Housley for useful discussions about security protocol
requirements. Of course any shortcomings are our own. [DM]
References
[1] "Key words for use in RFCs to Indicate Requirement Levels",
March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119>.
[2] "IEEE Std 802.11i/3.0: Specification for Enhanced Security",
November 2003.
[3] "HMAC: Keyed-Hashing for Message Authentication", February 1997,
<ftp://ftp.isi.edu/in-notes/rfc2104>.
Authors' Addresses
Scott Kelly
Airespace
110 Nortech Parkway
San Jose, CA 95134
Phone: +1 408-635-2022
EMail: skelly@airespace.com
Kelly & Molnar Expires February 19, 2004 [Page 19]
Internet-Draft LWAPP Security Requirements August 2003
David Molnar
Legra Systems
3 Burlington Woods Dr
Burlington, MA 01803
Phone: +1 781-272-8400
EMail: dmolnar@legra.com
Kelly & Molnar Expires February 19, 2004 [Page 20]
Internet-Draft LWAPP Security Requirements August 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kelly & Molnar Expires February 19, 2004 [Page 21]