Wireless Security Design

Best Practices
Revision 1.1
May 24, 2005

Aruba Networks
1322 Crossman Ave
Sunnyvale, CA 94089
+1 408 227 4500
http://www.arubanetworks.com

Table of Contents
Security Design................................................................................................................... 3
How to use this Guide..................................................................................................... 3
Authentication................................................................................................................. 4
Getting Started ............................................................................................................ 4
Open Network............................................................................................................. 4
Captive Portal.............................................................................................................. 5
Choosing between VPN and 802.1x ........................................................................... 6
VPN............................................................................................................................. 9
802.1x........................................................................................................................ 13
MAC Address Authentication................................................................................... 16
Authentication Recommendations ............................................................................ 16
Encryption..................................................................................................................... 17
Getting Started .......................................................................................................... 17
Open System ............................................................................................................. 17
WEP .......................................................................................................................... 18
WPA.......................................................................................................................... 19
WPA2........................................................................................................................ 19
WPA-PSK ................................................................................................................. 20
Encryption Recommendations .................................................................................. 20
User Segmentation ........................................................................................................ 20
Getting Started .......................................................................................................... 20
Firewall Segmentation .............................................................................................. 21
Physical Port Segmentation ...................................................................................... 22
VLAN Segmentation ................................................................................................ 23
User Segmentation Recommendations ..................................................................... 24
User Roles and Firewall Policies .................................................................................. 25
Getting Started .......................................................................................................... 25
Determining Roles .................................................................................................... 25
Firewall Basics.......................................................................................................... 26
Guest Firewall Policies ............................................................................................. 27
Employee and Contractor Policies............................................................................ 29
Device Policies.......................................................................................................... 31
Roles and Firewall Policies Recommendations........................................................ 32
Guest Access................................................................................................................. 32
Getting Started .......................................................................................................... 32
Low Security (Open Network).................................................................................. 32
Medium Security (Guest Registration without Validation) ...................................... 33
High Security (Guest Login with Validation)........................................................... 34
Guest Access Recommendations .............................................................................. 34

Security Design
A primary concern in wireless deployment is that of security. Security can broadly be
classified into three areas: privacy, integrity, and availability. Availability is generally
addressed by including high availability and redundancy features in the network design,
and through enterprise IT policy such as change management and maintenance
scheduling. Privacy and integrity, on the other hand, are directly addressed through
design of a wireless security policy.

How to use this Guide

This chapter provides an overview of planning and design guidelines for a wireless
security policy. Discussions are divided into the following general topics:

Authentication

Encryption

User Segmentation

User Roles and Firewall Policies

Guest Access

Within each topic is a Getting Started section, a full discussion of the topic, and a set of
recommendations. Read the Getting Started section if you are unfamiliar with the
technology or problem to be solved and need guidance in what questions to ask. The
bulk of each section is a full discussion of possible design choices, with the tradeoffs
between each highlighted. Finally, read the Recommendation section for a quick
cookie-cutter solution to each problem. The cookie-cutter approach is designed to get a
network up and running quickly, and may prove useful for evaluations, trials, and pilots
where a full design and analysis is not practical.

IN ALL CASES, IT IS IMPERATIVE THAT THE CUSTOMER

EVALUATE WIRELESS SECURITY IN THE CONTEXT OF AN
OVERALL ENTERPRISE SECURITY POLICY. RECOMMENDATIONS
MADE IN THIS GUIDE MAY NOT NECESSARILY MEET THE NEEDS
OF A PARTICULAR INSTALLATION. ARUBA WIRELESS
NETWORKS MAKES NO WARRANTY OR REPRESENTATION AS TO
THE SUITABILITY OF A PARTICULAR DESIGN OR PRODUCT OR
ITS FITNESS FOR ANY PARTICULAR PURPOSE OR USE.

Authentication
One of the first decisions that must be made when designing a wireless security strategy
is if and how to authenticate users on the network. Some networks will be completely
open, others will use no authentication but will use encryption, and some will use both.
This section will explain how to select an authentication scheme, the tradeoffs involved
in each, and the dependencies on external systems. The following topics are addressed:

Getting Started
To begin, consider the following questions. Answers to these questions form the basis of
the decision criteria that will be used to select an authentication scheme. After answering
each question, please see the appropriate section indicated in the table below. While
these questions are not comprehensive, they help serve as a starting point. A complete
discussion of each authentication method follows.
Decision Criteria
Do users and devices on the
wireless network need to be
explicitly and uniquely identified
(authenticated) by the wireless
network?
Do internal or external policies
mandate the use of IPSEC (i.e.
FIPS 140-2, HIPAA)?
Do you control and manage
software installed on all wireless
clients?
Do you require strong encryption
with automatic distribution of
encryption keys?
Do you have an existing VPNbased remote access infrastructure
that you prefer to make use of for
wireless?
Do you have dumb devices that
do not support secure forms of
authentication?

Yes

No
See Open Network

See VPN

See Captive Portal

See Choosing
between VPN and
802.1x
See VPN

See Captive Portal

See MAC Address

Authentication

Open Network
An open network is one that does not perform per-user or per-device authentication. An
open network does not necessarily imply that no encryption is used. The following are
all examples of open networks:
Unencrypted network providing free public Internet access
Network using static WEP encryption. Anyone who knows the WEP key has
access to the wireless network.

Network using WPA-PSK (Wi-Fi Protected Access with Pre-Shared Key)

encryption. Anyone who knows the pre-shared key has access to the wireless
network.

The key characteristic of an open network is that no identifying information is required

from the client before access to the network is granted. In the examples where encryption
is used, possession of the correct encryption key is sufficient evidence that the user is
authorized. Open networks should not be considered where even medium security is
required, for the following reasons:
Lack of per-user or per-device authentication means that a compromised device
cannot be locked out of the network quickly.
No per-user tracking is available, making it difficult to troubleshoot problems.
Use of static encryption keys does not scale to large networks, since the keys must
be updated on each device in the event of a re-key.
Finally, use of static WEP is discouraged when used alone, as the encryption
algorithm is widely known to be flawed.
In general, open networks should be used for providing public guest access or in smaller
low-risk networks where ten or fewer devices access the wireless network.
An open network is configured on a per-ESSID basis. It is possible to have one ESSID
make use of strong encryption and authentication, while another ESSID is set up as an
open network for the purpose of guest access. To configure an ESSID as open, use a role
derivation rule. A role derivation rule maps a particular parameter about the user in this
case the ESSID the user associates to with a user role in the system (see User Roles and
Firewall Policies). The role should be set up to allow appropriate access privileges to
users of the open network.

Captive Portal
Captive Portal authentication is familiar to anyone regularly utilizing public access
wireless hotspots or hotel in-room Internet access. After a user associates to the wireless
network, their device is assigned an IP address. The user must bring up a web browser
and pass an authentication check before access to the network will be granted. Portalbased authentication is the simplest form to use and requires no software installation or
configuration on the client. The username/password exchange is encrypted using
standard SSL encryption, preventing eavesdroppers from learning authentication
credentials. A sample portal login screen is shown below.

Portal-based authentication is ideal for enabling guest authentication (see Guest Access.)
However, portal authentication does not inherently provide any form of encryption
beyond the authentication process itself. In order to ensure privacy of user data, some
form of link-layer encryption such as WEP or WPA-PSK should be used when sensitive
data will be sent over the wireless network.

Choosing between VPN and 802.1x

In a wireless network where both encryption and authentication are needed, both can be
accomplished in multiple ways. The most common standards-based methods utilize
either 802.1x with one of multiple encryption types, or Virtual Private Network (VPN)
technologies utilizing either IPSEC or PPTP. While some users choose to utilize both
methods at the same time, this is an uncommon scenario. Because the implementation of
an authentication protocol often involves configuration of the client devices,
understanding and choosing the authentication method up front is a critical planning step.
802.1x
802.1x is an IEEE standard used for authenticating client devices on any IEEE 802
network. It is an open authentication framework, allowing multiple authentication
protocols to operate within the framework. 802.1x operates as a Layer-2 protocol.
Successful authentication must complete before any higher-layer communication with the
network is allowed, such as a DHCP exchange to assign an IP address. 802.1x is also
key-generating, meaning that the output of the 802.1x process can be used to assign
dynamic per-user encryption keys (see Encryption for more details.) These encryption
protocols also operate at Layer-2, meaning that all data beyond the MAC header will be
encrypted.

802.1x is ideally suited for wireless deployments, both because of the tie-in with dynamic
L2 encryption protocols and because of the native support in many operating systems.
Use of 802.1x also blocks all communication with the network until authentication has
succeeded, allowing for greater perimeter security. 802.1x authentication tends to be less
intrusive to the user, allowing a single entry of username/password (single sign-on) to
authenticate them to the local computer, the wireless network, and server resources.
However, 802.1x requires work at times, significant work to install or upgrade the
back-end authentication infrastructure and configure the client devices. Many users opt
to use VPN technology instead, because they can leverage existing remote access
infrastructure already in place.
VPN
VPN technology has been in use for Internet-based remote access for a number of years.
Client and server components are available from many manufacturers, including Check
Point, Cisco, Nortel, Microsoft, and Netscreen. In general, the VPN client is installed on
mobile devices and is used to provide secure communication with the corporate network
across a non-secure network such as the Internet. Some users view a wireless network as
any other non-secure network and choose to utilize the same VPN technology to secure
wireless access as well. VPN technology operates at Layer 3, meaning that an IP address
is required on the end device before the VPN client can operate. From an encryption
standpoint, the MAC and outer IP headers are transmitted cleartext, while the inner
IP header and data are encrypted. Because the IP layer is unprotected while using VPN
technology, some form of L2 encryption such as WEP should always be used on a
wireless network.
VPN is normally chosen as an authentication method when users wish to utilize an
existing remote access infrastructure to provide wireless access. In many cases, client
devices already have VPN software installed, and this software can be used un-modified
to provide wireless access. In addition, existing authentication servers can be used, and
in some cases, the existing VPN hardware can also be used. A further discussion of these
design principles can be found in the VPN section below. The downside of using VPN
technology to secure the wireless network is that it is more intrusive to the user
typically a VPN client must be launched and authentication credentials supplied before
the user can get access to the network. This complicates (but does not preclude) single
sign-on, since ideally a network connection needs to exist before Network Operating
System (NOS) authentication can take place. Still, VPN is popular in wireless networks
because of the perceived time-proven safety of the protocol, as well as the ability to
install quickly without excessive modification of either the client or the authentication
back-end.
Comparison Table
To aid in the decision between the two technologies, the following table provides a
comparison between 802.1x and VPN as applied to an Aruba wireless deployment.
Feature
Client OS Support

802.1x
Windows 98, 2000, XP

VPN
Windows 95, 98, 2000,

Authentication Backend

Authentication Passthrough
Aruba controller does not
provide
authentication/encryption,
but passes traffic through
to another device
Single Sign-On
A user need only enter
authentication credentials
once for access to the
local computer, wireless
network, and network
resources
Encryption

ME, XP
PocketPC 2002, 2003
MacOS
PalmOS
Linux/FreeBSD/OpenBSD
Solaris, other commercial
Unix
Can make use of many
types of authentication
servers, including
RADIUS, LDAP, Unix
password, Windows NT,
ActiveDirectory,
TACACS, etc. Protocol
does not define a specific
back-end technology
Aruba controller contains
built-in user database that
can also be used for VPN
authentication
Supported

Supported, client-specific
Windows has built-in
support, other clients vary

Supported, client-specific
In general, more difficult
to implement than for
802.1x

Chosen EAP type

provides encryption for
exchange of authentication
credentials
Generates key material to
support WEP, TKIP,
AES-CCM for user data
encryption
Password
RSA token cards (not yet

VPN protocol contains

built-in encryption support
DES, 3DES, MPPE, AESCBC, others are available
client-dependent
Aruba controller supports
DES, 3DES, MPPE, AESCBC
Password
RSA token cards

Authentication
Credentials

PocketPC 2003
MacOS
Linux/FreeBSD/OpenBSD
3rd-party software for
Windows 98, 2000, ME,
XP, CE, PocketPC 2002,
PocketPC 2003
Novell
RADIUS server is
required.
RADIUS server must have
explicit support for
802.1x, including the
specific EAP type.
Many commercial and
open-source RADIUS
servers available
To use ActiveDirectory or
other databases, a
RADIUS server must
provide the interface
Not supported. Standard
requires that 802.1x
exchange be done between
client MAC address and
AP MAC address

How a user proves his or

her identity to the
network
Client Performance
Impact
Performance impact to
the client of using the
technology. Can be
important when older or
lower-powered devices
are used.
Government Approval
Suitability for use where
government agencies
require standards such as
FIPS or Common Criteria

widely supported)
Digital certificates

Digital certificates

Low. Authentication can

be demanding because of
public-key cryptography,
but user data encryption is
done hardware

Moderate to high. All

encryption typically done
in software performance
depends on power of
client device

As of this writing,
encryption based on WEP,
TKIP, or AES-CCMP
(802.11i) is not approved
for use where FIPS 140-2
or CC is required
Approval process for
AES-CCMP is underway.
Uncertain outcome at this
time.
802.1x required for WPA
and upcoming 802.11i
standards
802.1x will likely see
growing usage in wired
networks for port-based
authentication
Built-in client OS support
is growing
Ties in with other security
technology, such as client
remediation
Some use today in public
wireless hotspots, but
uncertain future in that
market

3DES and AES-CBC can

be used, when equipment
is appropriately certified,
where FIPS 140-2 or CC
is required

Will continue to be used

for providing Internetbased remote access

Future Applicability

VPN
VPN technology has been in use for Internet-based remote access for a number of years.
Client and server components are available from many manufacturers, including Check
Point, Cisco, Nortel, Microsoft, and Netscreen. In general, the VPN client is installed on
mobile devices and is used to provide secure communication with the corporate network
across a non-secure network such as the Internet. Some users view a wireless network as

any other non-secure network and choose to utilize the same VPN technology to secure
wireless access as well. VPN technology operates at Layer 3, meaning that an IP address
is required on the end device before the VPN client can operate. From an encryption
standpoint, the MAC and outer IP headers are transmitted cleartext, while the inner
IP header and data are encrypted. Because the IP layer is unprotected while using VPN
technology, some form of L2 encryption such as WEP should always be used on a
wireless network.
Discussion of VPN design is broken up into the following categories:

Tunnel Termination
Selection of VPN Protocol
Client Selection
Selection of Authentication Credentials

Tunnel Termination
In an Aruba network, VPN technology can be deployed in one of two ways. In the first
method, the Aruba controller acts as the VPN concentrator, terminating VPN sessions
from client devices. In the second method, the Aruba controller acts as a pass-through
device, allowing VPN traffic to reach another VPN concentrator located somewhere
inside the network. The Aruba controller will be set up in this case to allow only VPN
traffic through all other traffic will be dropped by the Aruba firewall. Either method
achieves the goal of authenticating users and encrypting data, though in general
terminating the sessions on the Aruba controller leads to better security by pushing the
VPN concentrator to the edge of the network and providing for the performance needs of
a large wireless network. The two approaches are shown in the figure below.

When an existing VPN concentrator is already in use for remote access, often the choice
is made to continue using this for wireless. However, the best security, performance, and

management integration is achieved when using the Aruba controller for VPN
termination. The following table summarizes the tradeoffs between each approach.
Feature

External VPN
Concentrator
User data protected
from eavesdroppers
Users authenticated
Small vulnerability
exists that could allow
an attacker to send
unauthorized data to
portions of the internal
network between the
Aruba controller and
VPN concentrator.
Can be counteracted
by using L2 encryption
such as WEP
L2 encryption such as
WEP should be used
to prevent attacks such
as DHCP spoofing
Split between Aruba
controller and VPN
concentrator
Aruba controller has
no visibility into user
identity. Users
identified in the
wireless network only
by MAC/IP address
Username visibility
only at VPN
concentrator
Limited by VPN
concentrator. Varies
by make and model

Aruba Controller VPN

Termination
User data protected from
eavesdroppers
Users authenticated
Any attack limited to the
wireless network only.
No leakage of
unauthorized traffic to
the internal network.
L2 encryption such as
WEP should be used to
prevent attacks such as
DHCP spoofing

Troubleshooting

Split between Aruba

controller and VPN
concentrator

Interoperability

Best. Typically VPN

Security

User Management

Performance

Integrated in Aruba
controller. Wireless
association state tied to
user identity and security
state.
Aruba firewall can be
used to enforce per-user
policies

Limited by Aruba
controller. Aruba 5000
rated up to 2Gbps of
encrypted throughput
Integrated in Aruba
controller. Single
location for all wirelessrelated troubleshooting
and management.
Good. Aruba can

Installation

clients are made by the

same manufacturer as
the VPN concentrator
Proprietary value-add
features may be

available

If VPN clients are

already installed, bestcase scenario is that no
installation or
configuration is
required

emulate many types of

VPN concentrators,
including Cisco and
Nortel.
Proprietary features most
likely not available
Aruba provides VPN
front-end dialer for
Windows 2000/XP
clients. This automates
deployment when the
VPN client embedded
with the OS is used.
This dialer can also
operate alongside many
popular commercial
clients without causing
interference.

Selection of VPN Protocol

Three protocols may be used for VPN termination:
L2TP over IPSEC This protocol is used by the Microsoft Windows 2000/XP
embedded VPN client. If the Aruba VPN dialer is used on a Windows device,
this is the protocol that will be used. It is a combination of L2TP for tunneling
and IPSEC for encryption and transport.
IPSEC/Xauth - This protocol is used by many 3rd-party VPN clients such as
Nortel and Cisco. Xauth provides for group-based authentication keys.
PPTP Point to Point Tunneling Protocol (RFC 2637) is supported by a number
of vendors, including Microsoft and Apple. There are also open-source
implementations. PPTP is encrypted using MPPE (Microsoft Point-to-Point
Encryption) and operates over UDP. PPTP is generally considered weaker than
IPSEC from a security standpoint, but is sometimes the only available option
depending on the client device in use.
While the client device in use will generally determine which protocol is used,
L2TP/IPSEC or IPSEC/Xauth are the recommended protocols. IPSEC and PPTP can be
supported simultaneously, if desired.
Client Selection
The choice to use VPN in the first place is often guided by the fact that a VPN client
installation already exists. In this case, the choice of a VPN client is already made. If
there is no existing VPN installation, or if the existing installation is not usable for
wireless, the Microsoft Windows 2000/XP built-in VPN client is recommended, in
conjunction with the Aruba VPN Dialer application. Platforms other than Windows
2000/XP must be evaluated on a case-by-case basis.

Selection of Authentication Credentials

The selection of authentication credentials in a wireless VPN deployment is identical to
the selection in a standard Internet VPN deployment both the wireless network and the
Internet-connected VPN concentrator are exposed to untrusted networks.
When using PPTP, the only authentication credentials available are username and
password. When using IPSEC, however, a number of different choices are available. For
IKE, both pre-shared key and certificate-based authentication are available. Certificatebased authentication is unpopular because it requires a PKI deployment and requires each
client to enroll a certificate. Pre-shared key authentication, however, could expose a
network to vulnerability in the event that an employee was to leave the company and still
possess the shared key. Note that this does not mean that an ex-employee would be able
to authenticate to the wireless network, only that the ex-employee would be able to
establish an IPSEC tunnel.
Once an IPSEC tunnel is established, typically a higher-layer authentication takes place
involving a username and password. A common and secure method of implementing
password-based authentication is the use of token cards such as RSA SecurID. Aruba
supports a SecurID token caching feature that enhances such deployments by making it
possible for a user to authenticate once per day. Subsequent authentications within a
defined time period will not require accessing the token card again.

802.1x
802.1x is an IEEE standard used for authenticating client devices on any IEEE 802
network. It is an open authentication framework, allowing multiple authentication
protocols to operate within the framework. 802.1x operates as a link-layer protocol.
Successful authentication must complete before any higher-layer communication with the
network is allowed, such as a DHCP exchange to assign an IP address. 802.1x is also
key-generating, meaning that the output of the 802.1x process can be used to assign
dynamic per-user encryption keys (see Encryption for more details.) These encryption
protocols also operate at the link-layer, meaning that all data beyond the MAC header
will be encrypted. One encryption choice with 802.1x is Dynamic WEP. A better choice
is WPA.
There are three components to any 802.1x network:

Supplicant The 802.1x supplicant is the client portion of the authentication

system. An 802.1x supplicant communicates with the rest of the network using
the EAPOL (Extensible Authentication Protocol over LAN) protocol.
Authentication is carried out using one of a variety of EAP types.
Authenticator An 802.1x authenticator is a gate-keeper, preventing
unauthenticated devices from accessing the network while allowing authenticated
traffic through. The authenticator relays link-layer EAPOL messages on one side
of the network to RADIUS messages traveling across an IP network on the other
side. In an Aruba wireless network, the Aruba controller acts as the authenticator.

Authentication Server In an 802.1x network, the authentication server must

use the RADIUS protocol. RADIUS servers have been used for many years to
provide authentication services for dialup and other remote access networks.
802.1x communication involves encrypted communication between the supplicant
and the authentication server using a particular EAP type. For this reason, both
the supplicant and the authentication server must support the same EAP type.

High-level 802.1x operation is shown in the figure below.

Selection of an EAP Type

Multiple EAP types are available inside of the 802.1x protocol. The following table
compares features of each one. A full discussion of each protocol follows.
Feature
Native support by Microsoft
Add-on support for
Windows by 3rd-party
software
Mutual authentication
Username protected from
eavesdropping
Server-side digital
certificate required
Client-side digital certificate
required
Client-side digital certificate
available
Supports SecurID token
cards

PEAP
X
X

EAP-TLS
X
X

TTLS

X
X

X
X
X

X
X

PEAP Protected EAP is a proposed standard put forth by Microsoft and Cisco.
It is widely deployed, mainly due to native support in Windows 2000 (SP3 or
later) and Windows XP. On the server side, Microsoft IAS, Cisco ACS, Funk

Odyssey/SBR, and many other RADIUS servers support the protocol. PEAP
typically uses a username and password for client authentication. At the time of
this writing, there are slight differences between the Microsoft version of the
protocol and the Cisco version of the protocol. The Cisco version of PEAP
allows SecurID token cards to be used for password authentication, while the
Microsoft version of PEAP does not. It is expected that these differences will be
resolved in the future.
EAP-TLS EAP with Tunneled Layer Security is supported by all major 802.1x
supplicants and authentication servers. It is ideal for device level authentication
or authentication using removable smart cards. Using EAP-TLS, client
authentication is accomplished using a digital certificate installed on each client
device. If a PKI (Public Key Infrastructure) is already implemented in the
network (i.e. for VPN remote access), EAP-TLS may be a good choice. For new
deployments, the overhead involved with setting up a PKI usually precludes its
use. EAP-TLS is specified in RFC 2716.
TTLS Tunneled Transport Layer Security is a proposed standard primarily
backed by Funk Software. PEAP and TTLS are very similar, but differ slightly in
that the username need not be sent clear-text in a TTLS network. This provides a
security advantage over PEAP. However, at the time of this writing, TTLS is
only available as commercial software from Funk Software. While Funk
deployments are highly recommended, there is a monetary cost involved.

Selection of a RADIUS Server

The choice of an EAP type as well as the currently installed base of servers often
determines the choice of a RADIUS server. All servers have their relative merits, and
respective manufacturers should be consulted for assistance. The following table
presents a non-exhaustive list of the more popular RADIUS servers available, along with
EAP types supported.
For pilots or trials, Microsoft IAS is a good choice, as it is included in Windows Server
2000 and Windows Server 2003. For large deployments, Funk Odyssey is the
recommended choice as it provides enhanced troubleshooting and diagnostic capabilities.
RADIUS Server
Microsoft IAS
Funk Steel-Belted RADIUS
Funk Odyssey
Cisco ACS
FreeRADIUS

PEAP
X
X
X
X
X

EAP-TLS
X
X
X
X
X

TTLS
X
X

Selection of an 802.1x Client (Supplicant)

The choice of an EAP type as well as the currently installed base of clients often
determines the choice of an 802.1x supplicant. In general, there are three classes of
802.1x supplicants:

Supplicants built into the operating system Many operating systems, such as
Microsoft Windows XP, Microsoft PocketPC 2003, MacOS, and others include
an 802.1x supplicant as a part of the operating system. These make a good choice
because of their integrated nature and lack of additional monetary cost. However,
at times they do not have as much flexibility as may be available in add-on
software.
Supplicants built into the wireless NIC utility Many wireless interface cards
include a client utility that acts as a radio manager and optionally as an 802.1x
supplicant. These are not recommended for large-scale deployments. The
primary focus of a client utility is on radio and driver management most are
lacking advanced features or troubleshooting capabilities of other supplicants.
Purpose-built add-on supplicants These include software packages such as
Funk Odyssey or Meetinghouse. These clients will optionally function as radio
managers as well, but their primary focus is on 802.1x supplicant functionality.
These often make the best choice for large enterprise deployments, but advantages
should be weighed against monetary cost and the support costs of adding
additional software to client devices.

MAC Address Authentication

MAC address authentication refers to the practice of examining the MAC address of an
associating device, comparing it to an internal or RADIUS database, and changing the
user role to an authenticated state. MAC address authentication is not a secure form of
authentication, as it is a simple process on most devices to change a NICs MAC address
in software.
MAC address authentication is useful for dumb devices that cannot support a more
secure form of authentication. Examples of such devices may include barcode scanners,
voice handsets, some types of printers or print servers, and many types of manufacturing
instrumentation sensors. User roles mapped using MAC address authentication should be
linked to extremely restrictive firewall policies to permit only the minimum required
communication. Wherever possible, WEP encryption should also be employed to
prevent unauthorized devices from joining the network.

Authentication Recommendations
The following recommendations are listed in order of the amount of labor required.
1. To quickly get a network up and running, use captive portal authentication
combined with static WEP encryption. For the back-end database, use the
Aruba controller internal database, populated with usernames and
passwords. For a longer-term solution, use an external RADIUS or LDAP
server for the authentication back-end.
2. Where stronger encryption and authentication is needed, use VPN with
Windows clients. Captive portal authentication is initially used to
distribute the Aruba VPN dialer to clients in a secure manner. Following
dialer installation, VPN access is used for all wireless activity.

3. Use 802.1x for deployments where little end-user intervention is desired.

Up-front installation and support requirements will be higher than with
other methods, but long-term requirements will be lower. Where possible,
implement WPA.

Encryption
Authentication ensures that only authorized users are able to access the network;
encryption ensures that unauthorized users are not able to intercept or make use out of
intercepted data. Encryption is a critical component of privacy on a wireless network,
since radio waves can and do travel outside of building walls.

Getting Started
The choice of encryption method often follows naturally from the choice of
authentication method. To begin, consider the following questions. Answers to these
questions form the basis of the decision criteria that will be used to select an encryption
scheme. After answering each question, please see the appropriate section indicated in
the table below. While these questions are not comprehensive, they help serve as a
starting point. A complete discussion of each encryption method follows.
Decision Criteria
Will the network be open to the
public or to outside visitors?
(open network)
Have you selected VPN
authentication?

Have you selected captive portal

authentication?
Have you selected 802.1x
authentication?

Yes
See Open System

No

See Static WEP or

WPA-PSK. Less
secure: see Open
System
See Static WEP or
WPA-PSK
See Dynamic WEP,
WPA, or WPA2.

Open System
In an open system, no link-layer encryption is used. This does not necessarily mean that
no encryption is used at all VPN can be used on top of open systems, though this is not
recommended (see Static WEP for more details on why.) An open system is used when
the IT staff has no control over the client for example, public-access hotspots or visitor
networks. Open systems are also used when client devices are incapable of encryption
for example, manufacturing facility instrumentation sensors.

Be aware that in an open system, anyone with some basic equipment (a laptop and
wireless card, for example) can eavesdrop on all communication over the wireless
network.

WEP
WEP (Wired Equivalency Privacy) is an encryption protocol that was part of the original
802.11 specification. WEP is considered a flawed standard with weak security protection,
and should not be used in an enterprise network unless absolutely required. Despite the
flaws of WEP, it is still widely deployed because of ubiquitous availability. WEP is
available in two forms static WEP and dynamic WEP. Of the two, static WEP is
considered the worst from a security standpoint, while dynamic WEP is considered
slightly more safe.
A recent demonstration by the FBI showed that WEP can be broken in less then five
minutes.
Static WEP
In a static WEP deployment, every client and every AP share the same encryption key.
There are a number of problems with this model in a large enterprise deployment. First,
once the WEP key has been distributed, every user has the key. If one user leaves the
company, he or she might keep this key, configure a new device with that key, and use it
to obtain unauthorized access to the network. To prevent this problem, the IT staff may
choose to re-key the network by setting up a new WEP key on every device. This brings
up the second problem with static WEP key distribution and re-keying is virtually
unmanageable in a large network, as it involves touching each device. The third problem
is a privacy concern as long as one device has the WEP key, it can intercept data for
any other device on the network. Although all users will in theory be authorized users,
not all users within an enterprise network should have access to all data. Confidential
data such as human resources records should obviously not be available to unauthorized
people.
Despite these problems, there is one common use for static WEP providing link-layer
encryption for a VPN deployment. VPN deployments rely on IPSEC or other networklayer protocols for encryption and authentication. However, using VPN alone allows
potential attackers to obtain access to the Layer 2 network, along with valid clients. This
could enable an attacker to hijack DHCP or launch worm or virus attacks against
enterprise clients. Although ArubaOS provides mechanisms to prevent client-to-client
communication, use of static WEP or WPA-PSK is recommended for a greater degree of
protection.
Static WEP can be used in a captive portal deployment, but should be restricted only to
smaller networks with few devices. WPA-PSK is a better alternative when available.
When no other alternatives are available, use of static WEP is highly preferable to using
no encryption at all.

Dynamic WEP
Dynamic WEP still uses the same encryption algorithm as static WEP. However, key
distribution is automated, with each device getting a different encryption key. This
makes dynamic WEP more suitable for a large enterprise deployment. Dynamic WEP
still suffers from protocol deficiencies relating to the weak encryption implementation,
but many of the deployment issues relating to static WEP are solved. Whenever possible,
WPA should be used instead of dynamic WEP.
Dynamic WEP requires 802.1x authentication in order to operate, as the key generation
and distribution mechanisms of 802.1x are used. Most clients that support 802.1x also
support dynamic WEP. They should be configured by enabling WEP encryption, then
selecting an option similar to Encryption keys are provided automatically. Note that
there is no standard specifying how dynamic WEP operates compatibility is primarily
by general industry consensus. Thus interoperability issues do occur at times. Dynamic
WEP implementations should be tested before deployment. As a stronger alternative to
dynamic WEP, consider WPA or WPA2. WPA accomplishes the same purpose as
dynamic WEP, but is standardized and utilizes a stronger encryption protocol that solves
many issues of WEP.

WPA
WPA (Wi-Fi Protected Access) is an interoperability standard put forth by the Wi-Fi
Alliance to solve immediate security needs of enterprise networks. It is an early snapshot
of the IEEE 802.11i specification and is designed to be forward compatible with that
standard. WPA consists of two components:
802.1x authentication, as described in the previous section. Any EAP type is
available, and has no ultimate bearing on use of WPA. RADIUS servers must
have support for 802.1x and the specific EAP type in use.
TKIP encryption. TKIP (Temporal Key Integrity Protocol) is a new encryption
standard designed as a replacement for WEP. TKIP is based on the same
encryption algorithm used by WEP (RC4) but utilizes a different implementation.
TKIP is supported on many available wireless interface cards. Because TKIP is
based on the same underlying algorithm as WEP, older wireless interface cards
can be upgraded through software to support TKIP. TKIP involves a complex
hierarchy of encryption keys, but key distribution is automatic through 802.1x so
they are never entered directly by a user.
WPA requires support from the client operating system, as well as a driver update from
the NIC manufacturer. In some cases, a new firmware update to the NIC is also required.
Windows XP Service Pack 2 currently supports WPA, as do a number of other operating
systems and wireless clients.

WPA2
WPA2 (Wi-Fi Protected Access version 2) is an interoperability standard from the Wi-Fi
Alliance that establishes sections of the final ratified 802.11i standard required for
interoperability. WPA2 is very similar to WPA, and consists of the following
components:

802.1x authentication, as described in the previous section. Any EAP type is

available, and has no ultimate bearing on use of WPA2. RADIUS servers must
have support for 802.1x and the specific EAP type in use.
AES-CCM (Advanced Encryption Standard Counter with CBC MAC)
encryption. AES-CCM is a new protocol with no concessions to WEP.
WPA2, like WPA, requires support from the client operating system as well as a
driver and NIC that is capable of running AES-CCM. As of this writing, WPA2 is
supported by a Windows XP Service Pack 2 hotfix, by Funk Odyssey Client 4.0, and
by several popular NIC manufacturers.

WPA-PSK
WPA-PSK (Wi-Fi Protected Access with Pre-Shared Keys) is also known as WPA
Personal. It is best thought of as a replacement for static WEP, using TKIP instead of
WEP for encryption. The same key distribution issues inherent with static WEP apply to
WPA-PSK, though the standard goes one step further by encrypting each users data with
different derived keys. WPA-PSK is best suited for a small office or home office
deployment with a small number of devices attached. In an enterprise setting, WPA-PSK
may be useful as link-layer protection for VPN.
WPA2-PSK is also available. WPA2-PSK is equivalent to WPA-PSK, except that AES
replaces TKIP as the encryption algorithm. If WPA2-PSK is available, it is preferred
over WPA-PSK.

Encryption Recommendations
1. For ease and speed of deployment, use WPA-PSK or WPA2-PSK.
Combine it with a supplemental encryption mechanism such as VPN.
Understand the key distribution issues with pre-shared keys when using
them in an enterprise environment.
2. If 802.1x can be used for authentication, wherever possible utilize WPA or
WPA2.
3. Avoid use of WEP unless absolutely required. WEP is not safe for
enterprise deployments.

User Segmentation
Getting Started
Many enterprise wireless LANs provide access to multiple classes of users. Most often,
this includes employee access and guest access, and may optionally include multiple
classes of employee access (see Determining Roles). Aruba AirOS provides two main
approaches to separating user traffic, one based on an internal firewall and the other
based on logical link-layer (Layer 2) separation. To a large extent, how this is done
depends on how the overall network is built and addressed. Examine the table below to
determine which method, if any, applies.

Decision Criteria
Will the network provide service
to multiple classes of users whose
traffic needs to remain separated?
Will different classes of traffic
need to be directed to physically
different pieces of equipment?
Will the uplink equipment accept
VLAN tags, and will the client
devices be assigned to different IP
subnets based on the class of
user?
Does the uplink network lack the
ability to separate user traffic?

Yes

No
Skip this section
and move to User
Roles and Firewall
Policies

See Physical Port

Segmentation
See VLAN
Segmentation

See Firewall
Segmentation

Firewall Segmentation
When using the Aruba embedded firewall, network traffic belonging to different user
classes will be forwarded across the same IP network to the same uplink device. The
uplink device does not provide separation of traffic, and typically has no knowledge that
different user classes exist. This is typical in smaller networks, such as in branch offices,
where only a single IP subnet is assigned to the entire network and the network is flat.
When firewall segmentation is used, different classes of users are assigned to different
roles. Each role has an associated firewall policy that determines which destination hosts,
networks, and services the clients in that role may access. Firewall policies can be
specified by source address, destination address or network, IP protocol, and TCP or
UDP port numbers. The figure below shows all traffic belonging to employees being
permitted, while traffic belonging to guests is restricted to Internet traffic only. Any
traffic coming from a guest user destined to a restricted destination will be dropped and
optionally logged.

Physical Port Segmentation

When physical port separation is used, different classes of users will be separated into
different port-based VLANs inside the Aruba controller. These VLANs are internal to
the Aruba controller and have no bearing on 802.1q VLANs outside the controller. Two
or more uplink ports will be connected to the Aruba controller, one in each VLAN. All
traffic from clients in one class will be directed to their respective uplink. For guest
traffic, the uplink often directs traffic to the DMZ outside the firewall. This is depicted in
the figure below.

It is important to note that when using port-based segregation, the following caveats
apply:
1. Clients in different classes must be assigned IP addresses from different
subnets.
2. The optimal authentication scheme for this type of deployment is 802.1x,
since authentication completes before the client is assigned an IP address.
3. If clients in different user classes also use different authentication and
encryption schemes, the clients should associate to different ESSIDs. If
this is not done, it is possible that broadcast traffic from a private
network could be flooded to a public network and inadvertently leaked.

VLAN Segmentation
When VLAN segmentation is used, traffic from different user classes will be forwarded
to a single uplink device but will have different 802.1q VLAN tags prepended. In this
manner, logical link-layer separation of traffic is maintained, but multiple dedicated
physical connections are not required. Functionality is equivalent to physical port
segmentation, but this method achieves logical separation rather than physical. Often,
this type of segregation will have guest traffic placed on a dedicated VLAN whose exit
point is a port on the firewall. VLAN segmentation is shown in the figure below.

It is important to note that when using VLAN-based segmentation, the following caveats
apply:
1. Clients in different classes must be assigned IP addresses from different
subnets.
2. The optimal authentication scheme for this type of deployment is 802.1x,
since authentication completes before the client is assigned an IP address.
3. If clients in different user classes also use different authentication and
encryption schemes, the clients should associate to different ESSIDs. If
this is not done, it is possible that broadcast traffic from a private
network could be flooded to a public network and inadvertently leaked.

User Segmentation Recommendations

The following general recommendations apply:
1. Firewall-based segregation of users is more flexible, scales better, and
makes no assumptions about underlying authentication schemes. If no
VLAN tagging is used as part of the network design, use firewall-based
segmentation.
2. Link-layer segregation of users is less prone to error, but also is less
scalable in a large network particularly where multiple controllers exist.
Use link-layer segregation if local security policy requires it or if VLAN
tagging is already being performed for network design reasons. Physical

port segmentation and VLAN segmentation provide equivalent

functionality.

User Roles and Firewall Policies

Getting Started
In the earlier days of wireless LAN deployment, many enterprises took all wireless traffic
back outside the corporate firewall, where users had to come back in just as though they
were coming from the Internet. This was a good approach security-wise, but led to suboptimal network design and poor performance as WAN-grade firewalls were suddenly
forced to support multiple air-speed access points. This technique also suffered from a
one size fits all approach to access control, giving all wireless users the same rights on
the network. Typically a wireless user would get full access to the entire network in this
model, as traditional corporate firewalls were built to protect networks from other
networks, rather than identify individual users.
Today, a better alternative is available. Aruba Networks has built a stateful applicationaware firewall into every mobility controller, with different firewall policies available for
each wireless user. This firewall is implemented in hardware, giving it the performance
to support enterprise wireless speeds. The firewall is compliant with ICSA corporate
firewall certification standard 4.0, giving security administrators the confidence needed to
deploy it in critical locations such as a wireless entry point to the network.
Why are firewalls important? Aruba believes that even after strong encryption has been
used and authentication has been successful, wireless users should still be fundamentally
less trusted than wired users. Wired users have a physical location that can be easily
traced, since they sit at the end of a cable. There is no such principle in a wireless
network a user could be in the parking lot, using a stolen laptop with a stolen password.
In such a network, there is no reason to treat all users the same a sales employee does
not have the same access needs as a finance employee, who does not have the same
access needs as someone working in the mail room. Firewalls are an effective layer of
protection and should be a mandatory part of a multi-layer security strategy.

Determining Roles
All firewall policies depend on the role of the user. A role can be employee versus
guest, or more granular such as sales user, marketing user, finance user, IT staff.
Ultimately, the role of a user determines all access privileges in the wireless network, so
some thought should be given to how best to provision these policies.
One framework for designing roles is to use the employee, contractor, guest model.
This is the simplest security model, and can allow roles to be determined without any
reliance on an external authentication server. Typically, an employee is given access
(either full or restricted) to the entire network, a guest is given limited Internet access
only, and a contractor has varying privileges depending on their requirements. The
simplest method of splitting up access by role is to use default role settings in the
controller. A different default role is configured for each authentication method, and in

the absence of role information from an external authentication server, a user

authenticating through a given authentication mechanism will be assigned the
corresponding role. For a basic configuration, use captive portal authentication for both
guests and contractors, and a more secure authentication scheme such as 802.1x or VPN
for employees. The role for a guest login through captive portal will automatically be
guest, the default role for an authenticated captive portal user will be configured as
contractor, and the default role for any 802.1x or VPN user will be configured as
employee. In some cases, a separate contractor role may not be needed, simplifying
the design even further.
The above approach is a good starting point, but still suffers from the one size fits all
problem discussed in the introduction. A better approach is to segment users by their role
in the enterprise, through use of role or group membership features already built into
many authentication servers. A typical enterprise using Windows may run a domain
controller that performs authentication for Windows users based on an Active Directory
server. The Active Directory server allows users to be segmented into groups, typically
for controlling access to network storage and applications. If this infrastructure already
exists, it makes sense to re-use the group identity to provide role information to the
wireless network. This is accomplished through a feature known as role derivation. Role
derivation allows group membership or role information to be determined for a user,
either through a local parameter such as ESSID or AP location or, as described here, from
an authentication server.
Another use for roles is in restricting network activity of devices that cannot perform
more secure authentication, such as VoIP handsets or barcode scanners. These devices
typically have no ability to authenticate, and at best, can support static WEP. These
devices can be allowed on the network using MAC address authentication, and can be
given a role with extremely restricted firewall policies. For example, a VoIP handset can
be allowed to communicate using SIP only to the VoIP gateway.
Once a role framework has been established, corresponding firewall policies can be
created.

Firewall Basics
Firewall policies are often confused with access control lists (ACLs), but the two have
some major differences.
Firewalls are stateful, meaning they understand flows in a network and keep track
of the state of sessions. If a policy is enabled to allow telnet outbound from a
client, a firewall will understand that inbound traffic associated with that session
should be allowed. ACLs have no memory of what came before at best, ACLs
can look at the SYN flag in a TCP packet, treating the session as new if the flag
is set and treating the session as established if it is not. This works for
normal traffic but is ineffective against many types of attacks.
Firewalls in an Aruba mobility controller are dynamic, meaning that address
information in the rules can change as the policies are applied to users. For
example, a firewall policy containing the alias user can be created. After the

policy is applied to a particular user, thisalias is automatically changed to match

the IP address assigned to the user. An ACL is typically a static packet filter, with
IP addresses hard coded into the rule.
Firewalls are bi-directional. While ACLs are normally applied either to traffic
inbound to an interface or outbound from an interface, firewalls automatically
work in both directions. Firewall configuration can be simpler than ACL
configuration for this reason, since the administrator does not need to worry about
building consistent input and output ACLs.

At a basic level, a firewall rule is defined using the following format:

<source> <destination> <service> <action(s)>
Field definitions are as follows:
Source- this field represents an IP source address either a single address or a
range of addresses
Destination this field represents an IP destination address either a single
address or a range of addresses
Service this field represents the type of traffic being carried. It could represent
an IP protocol type (TCP, UDP, ESP, ICMP, etc) or a TCP/UDP port number. In
the case of TCP or UDP port numbers, the service field can represent a single port
number or a range of port numbers.
Action this field tells the firewall what to do with packets that match the rule.
Examples can be simple, permit or deny for example, or can contain more
complex actions such as setting QoS fields, logging the packet to a logfile, or
performing a NAT operation.

Guest Firewall Policies

One of the most compelling uses of wireless technology is to enable guest access to the
Internet. Visitors to a company often appreciate being able to check email, show a
demonstration, or pull down a critical file from a server. Using wireless, employees in
the same room can also have access to their own resources, all while security and
network administrators remain comfortable that visitors are not plugging into a wired
Ethernet port and getting access to internal networks. Strategies for deploying guest
access are discussed in more depth in the Guest Access section.
There are two main ways to segment guest access. One is through the use of Layer 2
VLANs or physical ports. In this model, guest traffic is forwarded over a special guest
VLAN, or out a physical port attached directly to the corporate DMZ. Guest traffic never
touches the internal network in this model. Firewall policies are used in this model only
to restrict the types of traffic visitors are able to send for example, restricting SMTP
access so that the enterprise network is not used as a launch point for spam.
The VLAN method of guest segmentation is a secure one, but in some cases can lead to
more complex network configuration, particularly when multiple mobility controllers are
deployed. The need to string cables or configure VLANs can be reduced or eliminated

by allowing the firewall to perform guest segmentation. In this model, guest data
traverses the same network as employee data, but is restricted by firewall policies.
For a basic guest firewall policy, first define a netdestination containing all IP subnets
that make up the corporate internal network, as shown in the figure below. This example
assumes that the internal network is made up of 10.0.0.0/8 and 172.16.0.0/16.

Internal Network Definition

Next, build the firewall policy. This policy will perform the following actions:
1. Allow DHCP traffic between the guest user and two DHCP servers at 10.1.1.13
and 10.1.2.13. The initial DHCP address will be assigned through a control
firewall policy, and this rule allows DHCP renewal messages to pass.
2. Allow DNS traffic between the guest user and two DNS servers at 10.1.1.14 and
10.1.2.14. This enables DNS lookups to work properly.
3. Allow HTTPS traffic from the user to the Aruba controller. This allows captive
portal functionality to work properly.
4. Block all other traffic to the internal network
5. Allow HTTP and HTTPS traffic to and from the Internet
6. Allow POP3 and POP3S traffic to and from the Internet
7. Allow VPN tunnels to be established
8. Block all other traffic.
This policy provides what most visitors need Web access along with the ability to
establish a VPN tunnel back to their corporate location. Notably absent from the list is
SMTP. Opening SMTP access to visitors could allow the network to become a launch
point for spam a headache that can easily be avoided. Most corporate users do not send
email directly through SMTP, or if they do, they send it through their own mail server
located behind their corporate VPN concentrator.
A sample firewall policy is shown in the figure below.

Guest Firewall Configuration

Finally, apply the firewall policy to the guest role. The only policy applied to the guest
role should be the one just created. By default, guests also have the control and
cplogout policy applied to them be sure to remove these. The components of these
policies necessary for guest access have been incorporated into the policy above. The
order of policy application is important, as policies are executed from top to bottom.

Employee and Contractor Policies

The same general configuration principles described above for guest access can also be
applied to employees and contractors. A basic employee firewall policy may be as
simple as any any any permit. However, in many ways such a policy defeats the
purpose of using a firewall in the first place. It is a much better practice to determine
which protocols, applications, and destinations users need to access while using wireless
connections, and permit only what is necessary. In some cases, wireless users may be
provided less access to the network than wired users, depending on the overall risk level.
Some enterprises in fact choose to permit only email and Internet access over wireless,
preferring not to provide access to financial systems or network storage at all. While
such a policy is extremely restrictive and will be unpopular with users, overall security
risks must be balanced with business needs for the wireless network.

As discussed above, an employee or contractor firewall policy can be applied universally

to all employees or segmented based on role. Using role-based access policies is a better
choice from a security standpoint, but may not make sense in the overall environment.
Each of the sample approaches below may be deployed in either a universal access
manner, or in a role-based access manner.
Protocols Restricted, Destinations Unrestricted
Using this approach, wireless users are given the ability to use only specific protocols
such as HTTP, HTTPS, Exchange, DNS, and others required for common applications to
function. A mail room employee may not need access to SAP, while a finance employee
would. Using this approach with role-based access, a mail room employee could still
contact the SAP server, but only using HTTP, DNS, or some other permitted protocol
in theory, this would not allow access to sensitive information since the SAP server
would not respond on those ports.

This approach is simple because the destination field in all firewall rules will be
set to any.
It does not require the firewall policy to be updated when a server is moved or a
new server is added.
This approach works well at restricting certain applications that the administrator
has deemed undesirable or too bandwidth-hungry for the wireless network, such
as FTP or streaming video.
Finally, the approach can help contain the spread of some viruses and worms,
since it may block ports the worm or virus needs to spread.

The protocol-restriction approach does not provide the highest degree of security, either
in a universal access configuration or in a role-based configuration, since destinations for
traffic are not restricted. However, it provides a good balance between security and
administrative requirements.
Destinations Restricted, Protocols Unrestricted
This approach is the exact opposite of the previous one. Using this approach, wireless
users are permitted access to specific destinations (networks, servers, etc.) using any
protocol. This approach could be used in a universal access design, but makes much
more sense in a role-based design.

Using this approach, mail room employees would be denied access to the finance
SAP server entirely, while finance employees would be denied access to servers
collecting barcode scanning data from the mail room.
The wireless firewall must be updated each time a server is added, removed, or
changed. If such changes happen often, this requirement could be a large
administrative overhead compared to the previous approach without necessarily
providing a corresponding gain in security. If departmental servers are segmented
by subnet, the use of address ranges can ease this burden.

This approach is not as effective as the previous one at protecting against worms
and viruses.

Destinations and Protocols Restricted

This approach, combined with the use of role-base access control, provides the greatest
level of security.

Continuing the previous example, finance employees would be able to access the
finance SAP server only on ports used by SAP. Mail room employees would be
able to access only the server collecting barcode scanning data on its required
ports. The two groups would not be able to access each others servers.
The greatest protection against viruses and worms is provided by this approach,
since communication is restricted to specific servers and specific protocols.
The wireless firewall must be updated each time a server is added, removed, or
changed. If departmental servers are segmented by subnet, the use of address
ranges can ease this burden. However, the gain in security provided by this
approach may offset the administrative overhead.

Mixed Approach
Depending on the security needs of the enterprise, it may make sense to use a mixed
approach to firewall policies. Users who travel frequently, such as sales employees, may
need highly restrictive policies to counteract the risk associated with their laptops being
subject to theft or hacking. IT staff may have a completely open firewall policy, while
finance employees may have a lightly restrictive policy. Mixed use policies are best
addressed in the context of an overall enterprise security policy.

Device Policies
When devices such as barcode scanners do not support secure authentication, MAC
address authentication may be used along with static WEP. It is important to remember
that MAC addresses can be easily spoofed, so MAC address authentication should never
be considered a secure form of access control. When MAC address authentication is
used, devices should be placed into a role with very limited firewall policies. This
ensures that even if the WEP key is cracked and a MAC address is spoofed, the potential
for damage will be limited. In addition, Weak WEP Detection should be enabled to
ensure that devices are not using a poor implementation of WEP. This will help
minimize exposure to WEP cracking.
To construct a firewall policy for these devices, determine the bare minimum protocols
and destination addresses required for the devices to function. Construct a policy that
allows only these protocols and destinations. In addition, set the final rule in the policy
to:
any any any deny log

By setting this policy to log firewall violations, administrators will be notified if an attack
is underway, and can then change the WEP key if required.

Roles and Firewall Policies Recommendations

4. As a quick-start method, set up one role called employee, and apply the
allowall firewall policy. Have all authenticated users map to this role.
5. Add additional roles, such as a guest role, as necessary.

Guest Access
One of the primary benefits of having a wireless network is the ability to provide Internet
or limited Intranet access for authorized visitors to a corporate location. This can be done
without need for extensive conference room cabling or designated visitor-only wall
jacks, and without regard to the number of people needing access. Because guest access
involves outside persons utilizing enterprise network resources, it is important to design
how guest access will be provided

Getting Started
All guest access should be restricted using firewall policies (see Guest Firewall Policies
for more information) to prevent unnecessary use of resources. Firewall policies may be
augmented with time-based restrictions such that guest access only functions during
normal business hours. In addition, guest access may be rate-limited using bandwidth
contracts to prevent a visitor from over-utilizing wireless bandwidth.
There are three general approaches to guest networking. A summary of the three
methods, in increasing order of security, follows:
Low Security This network provides open access to anyone associating to the
network. No form of authentication or registration is required.
Medium Security This network provides access to users who register for access
using a portal website. Registration is not validated.
High Security This network provides access only to validated guest users.

Low Security (Open Network)

The open network is the simplest type to set up, because no authentication of any type is
needed. The following recommendations apply for an open guest network:
1. Set up a separate ESSID for guest access. Map all users on the guest
ESSID into the guest role as described in Open Network.
2. Apply a guest firewall policy to the guest role. Configure the firewall
policy to be extremely restrictive for example, only allowing HTTP,
HTTPS, and VPN traffic (see Guest Firewall Policies).
3. Ensure that appropriate user segmentation is in place, either through the
firewall or through link-layer segmentation, to prevent mixing of guest
and employee traffic.

4. Configure a rate-limiting bandwidth contract and apply it to the guest role.

A good starting value is 1Mbps.
5. Consider configuring the guest firewall policy with time ranges so that it is
active only during business hours.
6. Consider configuring the guest ESSID so that it is only active on APs near
conference rooms or other areas where visitors will be. Consider also
deploying dedicated APs in each conference room and setting transmit
power to the lowest level on those APs. While this is not a foolproof
solution, it will minimize access outside the building.
7. Be prepared for the fact that war drivers will likely find the network,
map it, and at times use it for free Internet access.

Medium Security (Guest Registration without Validation)

In the medium security guest network, guests will need to register for access through a
captive portal web page. Registration consists of providing their email address. The
email address is not verified or validated by the system, but can be stored and manually
validated, if desired. For example, the email address registered by each guest could be
automatically emailed to a front desk receptionist. If the receptionist does not recognize
the email address as valid, he or she could disconnect the user through a web form. From
a security standpoint, however, the medium-security model is not significantly better than
the open network, since any email address can be entered.
The following recommendations apply for the medium-security guest network:
1. Set up a separate ESSID for guest access. Do not use a role-derivation
rule to automatically map users to the guest role. Instead, enable captive
portal along with the captive portal allow guest logon option.
2. Apply a guest firewall policy to the guest role. Configure the firewall
policy to be extremely restrictive for example, only allowing HTTP,
HTTPS, and VPN traffic (see Guest Firewall Policies).
3. Ensure that appropriate user segmentation is in place, either through the
firewall or through link-layer segmentation, to prevent mixing of guest
and employee traffic.
4. Configure a rate-limiting bandwidth contract and apply it to the guest role.
A good starting value is 1Mbps.
5. Consider configuring the guest firewall policy with time ranges so that it is
active only during business hours.
6. Consider configuring the guest ESSID so that it is only active on APs near
conference rooms or other areas where visitors will be. Consider also
deploying dedicated APs in each conference room and setting transmit
power to the lowest level on those APs. While this is not a foolproof
solution, it will minimize access outside the building.
7. Be prepared for the fact that war drivers will likely find the network,
map it, and at times use it for free Internet access.

High Security (Guest Login with Validation)

In the high-security model, guests must provide a valid username and password through
the captive portal web page before obtaining access to the network. The username and
password may be obtained in a number of different ways:
A guest login and password may be set up with access information posted in
conference rooms and other areas where guests may be present. Usernames and
passwords may change on a daily or weekly basis.
A guest login and password may be set up with access information provided by a
front-desk receptionist. The receptionist may hand out different login information
to each visitor, thus keeping a record of which person used which login. Access
information may change on a daily or weekly basis.
With a small amount of software development, a visitor sign-in computer in a
lobby area could print visitor badges that would contain, among other things, a
wireless network username and password. This username and password could be
taken from a pool, or could be automatically provisioned in a RADIUS server at
the time of registration.
Frequent visitors or contractors could be given a permanent username and
password for the guest network.
The following recommendations apply for the high-security guest network:
1. Set up a separate ESSID for guest access. Do not use a role-derivation
rule to automatically map users to the guest role. Instead, enable captive
portal. Do not enable the captive portal allow guest logon option.
2. Apply a guest firewall policy to the guest role. Configure the firewall
policy to be extremely restrictive for example, only allowing HTTP,
HTTPS, and VPN traffic (see Guest Firewall Policies).
3. Ensure that appropriate user segmentation is in place, either through the
firewall or through link-layer segmentation, to prevent mixing of guest
and employee traffic.
4. Configure a rate-limiting bandwidth contract and apply it to the guest role.
A good starting value is 1Mbps.
5. Consider configuring the guest firewall policy with time ranges so that it is
active only during business hours.
6. Consider configuring the guest ESSID so that it is only active on APs near
conference rooms or other areas where visitors will be. Consider also
deploying dedicated APs in each conference room and setting transmit
power to the lowest level on those APs. While this is not a foolproof
solution, it will minimize access outside the building.

Guest Access Recommendations

1. For the easiest and fastest method of setting up guest access, implement
the medium-security model using captive portal.