NETW 05A: APPLIED WIRELESS
SECURITY
Wireless LAN Authentication
By Mohammad Shanehsaz
Spring 2005
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Objectives
Explain the following types of authentication:
- Kerberos
- EAP / LEAP / PEAP
- WEP / TKIP
- VPN
- Certificates
- 2-factor & 3-factor authentication
- PAP / CHAP / MS-CHAP-V2
- LDAP / Directory Services
- RADIUS / AAA
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Kerberos
Developed at MIT under project Athena
Provides a trusted third party
authentication service for user
identification
Provides both user authentication and
encryption key management
Uses a ticketing system between clients
and servers which is managed by the
authentication server
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Kerberos
The components that make up a
Kerberos system are:




The Key Distribution Center
The client & server software components
Kerberos security policies
“Kerberized” applications
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Key Distribution Center
KDC is a single service running on a
server
Provides the Authentication Service and
Ticket-Granting Services
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Authentication Service (AS)
This service issues ticket-granting ticket
(TGTs) for connection to the ticketgranting service (TGS)
TGT can be reused until it expires
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Ticket–Granting Service (TGS)
This service issues tickets for connection to
services running on server computers
If clients want access to a service located on
another computer, it must request TGT from
the authentication service, present it to TGS
and ask for a ticket to the computer
See Figure 16.1 on page 384 for this process
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Kerberos
Supported by Microsoft Win2K and 2003
Windows Server platforms (KDC service
is started automatically by the domain
controller’s Local Security
Authority(LSA) )
Symbol calls their proprietary KDC
appliance the Spectrum24 Mobility
Server
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
The basic principles of Kerberos
operation
The Key Distribution Center (KDC) knows the secret
keys of all clients and servers on the network
The KDC initially exchanges information with the
client and server by using secret keys
Kerberos authenticates a client to requested service
on a server through TGS, and by issuing temporary
symmetric session keys for communications between
the client and KDC, the server and KDC, and the
client and server
Communication then takes place between the client
and the server using those temporary session keys
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Client to TGS server: Initial
Exchange
User enters an ID and password on the client
workstation
The client temporary generates the client’s secret key
from the password using a one-way hash function
The client sends a request for authentication to the TGS
server using the client’s ID in the clear (no password or
secret key is sent )
If TGS has the client in data base, it will returns an
encrypted client/TGS session key in the secret key of the
client and a TGT encrypted in the secret key of the TGS
server
The client decrypts the message containing the session
key with its secret key, and use it to communicate with
the TGS server, and erases its stored secret key
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Client to TGS Server: Request for
service
When requesting access, the client
sends two messages to the TGS server:
First it sends TGT, and the identification
of the server(s) from which service is
requested
Second message is an authenticator
(the client ID, timestamp, and optional
additional session key) encrypted in the
assigned session key
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
TGS Server to Client: Issuing Ticket
for service
The TGS server issues a ticket to the
client that is encrypted in the server’s
secret key, and a client/server session
key that is encrypted in the client/TGS
session key
Next to receive services, the client
sends the ticket and authenticator to
the server
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Kerberos Vulnerabilities
Kerberos addresses the confidentiality and integrity of
the information, but because all the secret keys are
held and authentication is performed on the Kerberos
TGS and authentication servers, they are vulnerable
to physical and malicious code attacks
Replay attacks can be accomplished if the
compromised tickets are used within an allotted time
window
A client’s secret key, can be compromised as well as
the session keys that are stored at the client’s
computer
In Kerberos IV, DES was used for encryption (DES
can be cracked), in current release (Kerberos V)
support is provided for “plug-in” symmetric
encryption algorithm (such as 3DES, IDEA)
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Remote Access Dial-In User
Service (RADIUS)
An authentication and accounting service
To access the network Username and
password passed by the Network Access
Server (NAS) to a RADIUS to be verified
In the wireless LAN, the APs play the roll of
the NAS
RADIUS may use an internal or external
database of users
RADIUS works just as well with VPNs in a
wireless environment as it does with
802.1x/EAP
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
RADIUS server features include:
Scalability
EAP Support (TLS, TTLS, LEAP, MD5 )
Clustering and Failover Support
Accounting
Legacy Authentication Protocol Support
Mutual Authentication Support
Multiple RAS Vendor Support
Software and Appliance
Implementations
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Scalability
RADIUS server’s ability to pass
authentication requests to another
authentication service such as another
RADIUS server or an LDAP compliant
user database
This is called Proxy Authentication
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
EAP support
RADIUS server should support the type
of EAP that will be used in an
organization
If not, choose the wireless
infrastructure devices that support an
EAP type matching the server
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Clustering and Failover
Clustering means that multiple servers
can run as a single computer where
each shares in the workload of the
application
Some RADIUS packages support
clustering
Depending on the OS vendor, this may
require additional licensing, upgrades
and more
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Accounting
The RADIUS server can maintain:


A history of all user dial-in sessions,
indicating start time, stop time, and various
statistics for the session
A current user list indicating which users
are currently connected to which Remote
Access Servers (RAS)
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Legacy Authentication
Protocols
Up-to-date RADIUS server software typically
supports MS-CHAP, MS-CHAPv2, multiple EAP
types, and other types of authentication
Support for legacy authentication protocols is
sometimes desirable because of legacy RAS
devices that are in place
Integrating both legacy and leading edge
authentication protocols makes the transition
between older and newer systems easier
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Mutual Authentication
Both the client and the server must
authenticate each others (two-way login)
In some cases mutual authentication also
refers to both the client and access point
having to authenticate to the
authentication server
Mutual authentication eliminates man-inthe-middle and rogue access point attacks
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Multiple RAS Vendors
When purchasing a RADIUS server
package, make sure that the
administrator can configure the server
with the proper “dialect” RADIUS
protocol that will work with the
organization’s NAS
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Various Implementations
RADIUS servers come in various forms:



Hardware appliances (suitable for large
enterprises where distributed proxy RADIUS
devices alleviate congested WAN links)
Software packages (Unix, Linux, Windows 2000
professional) for scalability and redundancy
Integrated into wireless infrastructure devices
appropriate for SOHO environments where there
are a small number of users
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Authentication Design
Considerations
Single Site deployment
Distributed autonomous sites
Distributed Sites, Centralized
authentication & Security
Distributed Sites & Security, Centralized
Authentication
Combination Architectures
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Single Site Deployment
All WLAN users are located at a single
site
A central authentication database
handles all user authentication
One or more RADIUS servers manage
WLAN and/or remote access use,
authenticating users and setting up
secure WLAN connections
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Advantages of Single Site
Deployment
You can authenticate your WLAN users
against any back-end authentication
database your RADIUS server supports
To scale, add access points and
RADIUS/AAA servers to authenticate
users against the central authentication
database
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Distributed Autonomous Sites
Distributed autonomous sites or networks
The authentication database is replicated from the central
site downstream to each autonomous site or network, so
that all user authentication happens locally
One or more RADIUS servers managing WLAN and/or
remote access use are located at each autonomous site or
network.
Each RADIUS server performs the following tasks:



Handles user authentication locally
Sets up secure WLAN connections
If required, records accounting data
Availability of central site network or hub is not an issue
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Distributed Autonomous Sites
This architecture presents the following
benefits:


Access to network is governed locally, and is not
subject to the reliability of a link back to a
central authentication store
The distributed RADIUS servers handle the full
computational load associated with setting up
the secure WLAN connection (you can easily add
servers to absorb the performance hit associated
with adding new WLAN users)
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Distributed Sites, Centralized
Authentication & Security
Distributed sites, networks or clusters of access points
WLAN access points at each site or on each network
authenticate users against an authentication database
located at a central site or operating hub
One or more RADIUS servers at the central site manage all
WLAN and/or remote access use.
The central site RADIUS server:



Handles user authentication locally
Sets up secure WLAN connections
If required, records accounting data
Availability of central site network or hub is an issue
Link bandwidth usage may be an issue
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Two issues that need consideration
when DSCA&S is used
1. Ability of a WLAN user to connect to the
network is dependent on the status of the
link between the distributed networks and
central site or operating hub
2. RADIUS/AAA server at central site
responsible for authenticating users, it must
also perform the cryptographic computations
necessary to set up the secure WLAN
connection (performance bottleneck!)
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Distributes Sites & Security
Centralized Authentication
Distributed sites, networks or clusters of
access points
The authentication database is located at the
central site or network hub
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Distributes Sites & Security
Centralized Authentication
One or more RADIUS servers managing WLAN
and/or remote access use are located at each site,
network, or AP cluster
The distributed RADIUS server performs the
following tasks:



Queries the central site for user authentication
Handles setting up the secure connection itself
If required, records accounting data locally, or forwards
data to the central site
Availability of central site network is an issue
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Combined Architectures
802.1x is very flexible
You can mix and match the different
architectures presented before
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
EAP Types
EAP-MD5 LEAP
EAP-TLS
EAPTTLS
PEAP
Server
Authentication
None
Password
Hash
Public Key
(Certificate)
Public Key
(Certificate)
Public Key
(Certificate)
Supplicant
Authentication
Password
Hash
Password
Hash
Public Key
(Certificate
or Smart
Card)
CHAP, PAP,
MSCHAP(v2),
EAP
Any EAP, like
EAP-MSCHAPv2 or
Public Key
Dynamic Key
Delivery
No
Yes
Yes
Yes
Yes
Security Risks
Identity
exposed,
Dictionary
attack, Manin-theMiddle
(MitM)
attack,
Session
hijacking
Identity
exposed,
Dictionary
attack
Identity
exposed
MitM attack
MitM attack;
Identity
hidden in
Phase 2 but
potential
exposure in
Phase 1
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
LDAP
LDAP is lightweight version of the X.500
Directory Access Protocol
LDAP is a simple protocol that acts as a
storehouse of information for
applications
LDAP contains small records of
information in a hierarchical structure
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Native LDAP servers
OpenLDAP server (Linux )
Innosoft’s Distributed Directory Server (Linux)
Netscape Directory server (Linux)
Sun Microsystems’s Directory Service (Solaris)
IBM’s DS Series LDAP Directory (AIX)
University of Michigan’s SLAPD (various forms
of Unix)
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
LDAP applications and use
There are a number of other directory service
systems that also support LDAP queries,
where they use proprietary APIs with
interfaces for LDAP communications
They are:



Novell’s eDirectory
Microsoft’s Active Directory
Lotus Domino
Many EWGs can query LDAP compliant
databases directly rather than go through
RADIUS
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Uses for LDAP
A data retrieval protocol - used directly as an
application server to retrieve information from a
directory
An application service protocol - used by
different applications to retrieve the information
these applications require
An inter-application data exchange interface used by one application to exchange data with
another, or as a gateway between two incompatible
applications
A system service protocol - used by an OS to
communicate information between its different
resources or components
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
LDAP Communications
Client-to-server communications allow user
applications to contact an LDAP server to
create, retrieve, modify, and delete data with
the standard LDAP commands
Server-to server communications define how
multiple servers on a network share the
contents of an LDAP directory information
tree and how they update and replicate
information between themselves
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
LDAP Architecture
The basic structure is a simple tree called the directory
information tree (DIT)
Every node in the tree is known as an entry, or
directory service entry (DSE)
There is a special entry called the root directory
specific entry or rootDSE, that contains a description
of the whole tree, its layout, and its contents, but this is
not really the root (root does not exist)
To refer to each entry in the DIT uniquely, you must use
a distinguished name (DN)
If you know the subset, you need only specify the name
relative to it (RDNs relative distinguished names)
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Multi-factor Authentication
There are three different types of authentication
criteria that can be combined to create a multifactor solution:



Knowledge-username/passwords (something you know)
Possessions- token, secureID, SmartCard (something you
have)
Biometrics- fingerprints, eye scan, hand scan (something
you are)
When choosing a solution you must consider


Management & integration , and
proven technology
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.
Resources
CWSP certified wireless security
professional, from McGraw-Hill
This work is supported by the National Science
Foundation under Grant Number DUE-0302909.
Any opinions, findings and conclusions or recommendations expressed in this material are
those of the author(s) and do not necessarily reflect those of the National Science Foundation.