Scalable voip mobility intedration and deployment- P19 pdf

180 Chapter 5
www.newnespress.com
when the PSK had been in use. Furthermore, because preshared keys are text and are
common for all devices, they are easy to share and impossible to revoke. Good users can be
fooled into giving the PSK away, or bad users—such as employees who have left the
organization—can continue to use the preshared keys as often as they desire.
These problems are solved, however, by moving away from preshared keys to using 802.1X
and EAP. Recently, some vendors have been introducing the ability to create per-user
preshared keys. The advantage of having per-user keys is that one user’s access can be
revoked without allowing that user to compromise the rest of the network. The problem
with this scheme, however, is the continued lack of forward secrecy, meaning that a user
who has his password stolen can still have decrypted every packet ever sent or will send
using that key. For this reason, 802.1X is still recommended, using strong EAP methods
that provide forward secrecy.
5.6.2 802.1X, EAP, and Centralized Authentication
Up to now, we’ve discussed Wi-Fi’s self contained security mechanisms. With WPA2, the
encryption and integrity protection of the data messages can be considered strong. But
we’ve only seen preshared keys, or global passwords, as the method the network
authenticates the user, and preshared keys are not strong enough for many needs.
The solution is to rely on the infrastructure provided by centralized authentication using a
dedicated Authentication, Authorization, and Accounting (AAA) server. These servers
maintain a list of users, and for each user, the server holds the authentication credentials
required by the user to access the network. When the user does attempt to access the
network, the user is required to exercise a series of steps from the authentication protocol
demanded by the AAA server. The server drives its end of the protocol, challenging the
user, by way of a piece of software called a supplicant that exists on the user’s device, to
prove that the user has the necessary credentials. The network exists as a pipe, relaying the
protocol from the AAA server to the client. Once the user has either proven that she has
the right credentials—she apparently is who she says she is—the AAA server will then tell
the network that the user can come in.
The entire design of RADIUS was originally centered around providing password prompts

for dial-up users on old modem banks. However, with the addition of the Extensible
Authentication Protocol (EAP) framework on top of RADIUS, and built into every modern
RADIUS server, more advanced and secure authentication protocols have been constructed.
See Figure 5.22.
The concept behind EAP is to provide a generic framework where the RADIUS server and
the client device can communicate to negotiate the security credentials that the network
administrator requires, without having to concern or modify the underlying network access
technology. To accomplish this last feat, the local access network must support 802.1X.
Introduction to Wi-Fi 181
www.newnespress.com
5.6.2.1 What Is Authentication in 802.1X?
Let’s first define exactly what authentication is, and what the technology expects out of the
authentication process. We’ve mentioned credentials immediately preceding this section. An
authentication credential is something that one party to communication has that the other
parties can use to verify whether the user is really who he claims he is and is authorized to
join the network.
In the preshared key case, the authentication credential is just the preshared key, a global
password that every user shares. This is not very good, because every user appears identical,
and there is no way for users to know that their networks are also authentic. Authentication
should be a two-way street, and it is important for the clients to know that the network they
are connecting to is not a fraud. With preshared keys, anyone with the key can set up a
fraudulent rogue access point, install the key, and appear to be real to the users, just as they
can arbitrarily decrypt over-the-air traffic.
Normal computer account security, such as what is provided by email servers, enterprise
personal computers, and Active Directory (AD) networks, generally uses the notion that a
user has a unique, secret password. When the user wants to access the network, or the
machine, or the email account, she enters her password. If this password matches, then the
user is allowed in. Otherwise, he or she is not.
(In fact, to prevent the system administrators from having access to the user’s password,
which the user might use in other systems and might not want to share, these systems will

record a cryptographically hashed version of the password. This version, such as the MD5-
hashed one mentioned in the next section, prevents anyone looking at it from knowing what
the original password is, yet at the same time allows the user to type their password at any
time, which leads to a new MD5-hashed string that will be identical to the one recorded by
the system if and only if the passwords are identical.)
This identifies the user, but what about the network, which can’t type a password to prove
itself to the user? More advanced authentication methods use public key cryptography to
RADIUS Server
Phone
Wireless ControllerAccess Point
Supplicant
EAPOL EAP over RADIUS
User Credentials
Authenticator/
NAS
Figure 5.22: The Components of RADIUS Authentication Over Wi-Fi
182 Chapter 5
www.newnespress.com
provide more than a password. A thorough description of public key cryptography will be
given in Chapter 8 security for voice mobility, as it is such a crucial topic, and you may
want to skip ahead and read that part for the details. The background is quite simple,
however. Public key cryptography is based on the notion of a certificate. A certificate is a
very small electronic document, of an exact and precise format, containing some basic
information about the user, network, or system that the certificate represents. I might have
a certificate that states that it is written for , pretending for a
moment that that is the name of my user account at some company. The network might
have a certificate that states it is written for network.somecompany.com, using the DNS
name of the server running the network. To ensure that the contents of the certificate are not
downright lies made up in the moment, each certificate is signed using another certificate,
that of a certificate authority who both parties need to trust in advance. Finally, each

certificate includes some cryptographic material: a public key, that is shouted out in the
certificate, and a private key, which the owner of the certificate keeps hidden and tells no
one. This private key is like a very big, randomly generated password. The difference is that
the private key can be used to encrypt data that the public key can decrypt, and the public
key can be used to encrypt data that the private key can decrypt. This allows the holder of
the certificate to prove his or her identity by encrypting something using his or her private
key. It also allows anyone else in the world to send the holder of the certificate a private
message that only the holder can decrypt.
Certificates are necessary for network authentication. When the user tries to authenticate to
the network, the network will prove its identity by using its private key and certificate, and
the client will accept it only if the network gives the right information based on that
certificate. Certificates are also useful for user authentication, because the same properties
work in reverse. The EAP method known as EAP-TLS requires client certificates. Most of
the other Wi-Fi-appropriate EAP methods use only server certificates, and require client
passwords instead.
To recap, authentication over Wi-Fi means that the user enters a password or sends his
certificate to the AAA server, which proves his identity, while the network sends its
certificate to the client, whose supplicant automatically verifies the network’s identity—just
like how web browsers using HTTPS verify the server’s identity.
It is the EAP method’s job to specify whether passwords or certificates are required, how
they are sent, and what other information may be required. The EAP method also is
required to allow the AAA server and the client to securely agree to a master key—the
PMK—which is used long after authentication to encrypt the user’s data. The EAP method
also must ensure that the authentication process is secure even though it is sent over an
open, unencrypted network, as you will see in the following section on 802.1X.
The administrator is allowed to control quite a bit about what types of authentication
methods are supported. The AAA administrator (not, you may note, the network
Introduction to Wi-Fi 183
www.newnespress.com
administrator, unless this is the same person) determines the EAP methods, and thus the

certificate and authentication requirements. The AAA administrator also chooses how long a
user can keep network access until he or she has to reauthenticate using EAP. The network
administrator controls the encryption algorithm—whether to use WPA or WPA2. Together,
the two administrators can use extensions to RADIUS to also introduce network access
policies based on the results of the AAA authentication.
5.6.2.2 802.1X
802.1X, also known as EAPOL, for EAP over LAN, is a basic protocol supported by
enterprise-grade Wi-Fi networks, as well as modern wired Ethernet switches and other
network technologies. The idea behind 802.1X is to allow the user’s device to connect to
the network as if the RADIUS server and advanced authentication systems did not exist, but
to then block the network link for the device for all other protocols except 802.1X, until
authentication is complete. The network’s only requirements are twofold: prevent all data
traffic from or to the client except for EAPOL (using Ethernet protocol 0x888E) from
passing; and taking the EAPOL frames, removing the EAP messages embedded within, and
tunneling those over the RADIUS protocol to the AAA server.
The job of the network, then, is rather simple. However, the sheer number of protocols can
make the process seem complex. We’ll go through the details slowly. The important thing to
keep in mind is that 802.1X is purely a way of opening what acts like a direct link between
the AAA server and the client device, to allow the user to be authenticated by whatever
means the AAA server and client deem necessary. The protocols are all layered, allowing
the highest-level security protocols to ride on increasingly more specific frames that each
act as blank envelopes for its contents.
Once the AAA server and the client have successfully authenticated, the AAA server will
use its RADIUS link to inform the network that the client can pass. The network will tear
down its EAPOL-only firewall, allowing generic data traffic to pass. In the same message
that the AAA server tells the network to allow the client (an EAP Success), it also passes
the PMK—the master key that the client also has and will be used for encryption—to the
network, which can then drop into the four-way handshake to derive the PTK and start the
encrypted channel. This PMK exchange goes in an encrypted portion of the EAP response
from the RADIUS server, and is removed when the EAP Success is forwarded over the air.

The encryption is rather simple, and is based on the shared password that the RADIUS
server and controller or access point have. Along with the PMK comes a session lifetime.
The RADIUS server tells the controller or access point how long the authentication, and
subsequent use of the keys derived from it, is valid. Once that time expires, both the access
point and the client are required to erase any knowledge of the key, and the client must
reauthenticate using EAP to get a new one and continue using the network.
184 Chapter 5
www.newnespress.com
For network administrators, it is important to keep in mind that the EAP traffic in EAPOL is
not encrypted. Because the AAA server and the client have not agreed on the keys yet, all
of the traffic between the client and the RADIUS server can be seen by passive observers.
This necessarily limits the EAP methods—the specific types of authentication—that can be
used. For example, in the early days of 802.1X, an EAP method known as EAP-MD5 was
used, where the user typed a password (or the client used the user’s computer account
password), which was then hashed with the MD5 one-way cryptographic hash algorithm,
and then sent across the network. Now, MD5 is flawed, but is still secure enough that an
attacker would have a very hard time reverse-engineering the password from the hash of it.
However, the attacker wouldn’t need to do this, as he could just replay the same MD5
hashed version himself, as if he were the original user, and gain access to the network. For
this reason, no modern wireless device supports EAP-MD5 for wireless authentication.
5.6.2.3 Key Caching
Because the work required establishing a PMK when 802.1X and RADIUS are used is
significant, WPA2 provides for a way for the PMK to be cached for the client to use, if it
should leave the access point and return before the PMK expires.
This is done using key caching. Key caching works because each PMK is given a label,
called a PMKID, that represents the name of the RADIUS association and the PMK that
was derived from it. The PMKID is specifically a 128-bit string, produced by the function
PMKID = HMAC-SHA1-128(PMK, “PMK Name” || AA || SPA),
where AA is the BSSID Ethernet address, SPA is the Ethernet address of the client, and
HMAC-SHA1-128 is the first 128 bits of the well-known SHA1-based HMAC function for

producing a cryptographic one-way signature with the PMK as the key. The double-pipes
(“||”) represent bitwise concatenation. The “PMK Name” ASCII string is used to prevent
implementers from putting the wrong function results in the wrong places and having it
work by accident.
From this, it is pretty clear to see that a client and access point can share the same PMKID
only if they have the same PMK and are referring to each other.
When the client associates, it places into its Reassociation message’s RSN information
element (Table 5.16) the PMKID it may have remembered from a previous association to
the access point. If the access point also remembers the previous association, and still has
the PMK, then the access point will skip starting 802.1X and will proceed to sending the
first message in the four-way handshake, basing it on the remembered PMK.
This caching behavior is not mandatory, in the sense that either side can forget about the
PMK and the connection will still proceed. If the client does not request a PMKID, or the
access point does not recognize or remember the PMKID, the access point will still send an
Introduction to Wi-Fi 185
www.newnespress.com
EAP Request Identity message, and the 802.1X protocol will continue as if no caching had
taken place.
5.6.3 Putting It All Together: An Example
The client passes through a number of phases when associating to a Wi-Fi network that uses
enterprise-grade security. To help understand how everything fits together, we will go
through one example authentication, using WPA2 and the EAP method EAP-PEAP, which
requires each mobile device to have a username and password. The password will be sent,
securely tunneled through PEAP, to the RADIUS server, which is usually attached to a
Microsoft Active Directory server.
Each message that is sent will be represented by a table, showing the relevant contents of
the message. The aim is to allow the reader to follow along, when analyzing wireless packet
capture traces, what the individual steps mean, when a client associates to the network. As a
matter of presentation, when information that might be important is repeated in subsequent
messages, it will be omitted for those messages.

Step 1: Associate with the Wi-Fi Network
The mobile device, having scanned for the SSID of the network desired—let’s call it voice
for this example—has found an access point that is advertising the voice SSID.
The client requests a connection with the access point by sending an 802.11 Authentication
message, requesting open authentication, meaning that the client does not want to use WEP.
See Table 5.19.
Table 5.19: 802.11 Authentication message from client to AP
Frame Control Destination
Address
Source Address BSSID Algorithm
Number
Authentication
Sequence
Authentication AP Address Client Address AP Address 0 (Open System)
1
Table 5.20: 802.11 Authentication message from AP to client
Frame
Control
Destination
Address
Source
Address
BSSID Algorithm
Number
Authentication
Sequence
Status Code
Authentication Client
Address
AP Address Client

Address
0 (Open
System)
1
0 (Success)
The access point accepts the open connection by responding with its own 802.11
Authentication message, to the client, simply stating that the request is a success. See Table
5.20.
186 Chapter 5
www.newnespress.com
The access point accepts the association request and sends an 802.11 Association Response
message to the client, announcing success, providing the client with the access point’s
capabilities and its network-wide configuration parameters.
At this point, the client cannot speak to any other access point without disconnecting or
being disconnected, but it cannot send or receive any real data traffic. The client must first
use EAPOL to authenticate.
Step 2: Authenticate with the AAA Server
The sends an EAPOL Start message (Table 5.22), encoded as a Wi-Fi Data frame with
Ethernet protocol 0x888E, sent to the Ethernet address of the access point. This message is
optional, but when sent is meant to request that the access point should start the EAP
exchange.
Table 5.21: 802.11 Association request message from client to AP
Frame
Control
Destination
Address
Source
Address
BSSID Capabilities SSID Information
Elements

Association
Request
AP Address Client
Address
AP Address Capabilities
voice Radio, Security,
and QoS
Capabilities
Table 5.22: 802.11 EAPOL start message
Frame Control Destination
Address
Source
Address
BSSID EtherType EAPOL Type
Data AP Address Client Address AP Address
0x888E Start
Table 5.23: 802.11 EAP request identity
Destination
Address
Source
Address
Ether-type EAPOL Type EAP Code EAP Type Identity
Client Address AP Address
0x888E
0=EAP 1=Request 1=Identity
hello
At around the same time, the access point will usually voluntarily send an EAPOL message
with an EAP Request Identity message inside (Table 5.23), triggering the start of the
authentication process. The Request Identity message is the EAP way of asking the client to
announce who he or she is.

The client then sends an 802.11 Association Request message to the access point, informing
the access point of its Wi-Fi capabilities, supported extensions and 802.11 features (Table
5.21).
Introduction to Wi-Fi 187
www.newnespress.com
This response triggers the start of the PEAP protocol, tunneled over EAP, tunneled over
EAPOL, carried over 802.11. The first message is from the RADIUS server, through the
access point, and informs the client that PEAP is beginning (Table 5.25).
PEAP uses TLS as the outer tunnel, within which the encrypted username and password are
passed. The first message in the TLS exchange is what is known as a TLS Client Hello
(Table 5.26). The Client Hello passes the client’s nonce, used as a part of the key derivation
protocol. The client will specify a number of cipher suites, but must specify RSA public key
encryption with RC4 stream encryption and either MD5 or SHA hashes.
Table 5.24: 802.11 EAP response identity
Destination
Address
Source
Address
Ether-type EAPOL
Type
EAP Code EAP Type Identity
AP
Address
Client Address
0x888E EAP
2=Response
Identity LOCATION\
user
Table 5.25: 802.11 EAP request PEAP
Destination

Address
Source
Address
Ether-type EAPOL Type EAP Code EAP Type Flags
Client
Address
AP Address
0x888E EAP Request
25=PEAP
Start
Table 5.26: 802.11 PEAP client hello
Destination
Address
Source
Address
EAP Code EAP Type TLS Type Handshake
Type
Nonce Cipher
Suites
AP Address Client
Address
Response PEAP
22=Handshake 1=Client
Hello
random Many
The client receives the request for the identity and responds with identity to use (Table
5.24). Let’s call the user “user”, in the domain “LOCATION”. PEAP uses a separate
protocol (MSCHAPv2) for the presentation of the real username and password. The identity
given in the outer protocol may or may not matter, depending on the RADIUS server. In
this example, the outer identity is the same one given as the real, inner identity:

“LOCATION\user”.
The server will respond with a Server Hello. The Server Hello message will specify the
server’s nonce, a session ID (which is usually not taken advantage of by wireless clients),
one of the client’s cipher suite to use for the rest of the process, and the beginning of a
chain of certificates for the RADIUS server, which identifies itself as being valid. The client
will usually verify that the server is signed by a valid certificate authority somewhere along
the path and is allowed to serve the role it does, unless the client’s administrator has
188 Chapter 5
www.newnespress.com
explicitly disabled this check. Because certificates are much longer than the maximum
EAPOL packet, the PEAP Server Hello and Certificate will be divided up over many
consecutive EAPOL frames from the access point. After the certificate, the server may
include a request for the client to send a certificate. This would be used by PEAP to short-
circuit the inner tunnel and revert to plain TLS, if the client has a certificate. Usually, PEAP
is not used with client certificates, so the client will ignore this request and trigger the
password exchange. If requested, the types of certificates and distinguished names of
acceptable certificate authorities, one of whom needed to have signed any client certificate
given, will be provided. The message ends with a Server Hello Done. See Table 5.27.
Table 5.27: 802.11 PEAP server hello and certificate, usually split across multiple
EAPOL messages
Destination
Address
Source
Address
EAP
Code
Flags TLS Type Handshake
Type
Session ID Nonce
Client

Address
AP Address
Request
0x40 =
More
Handshake
2=Server
Hello
arbitrary random
…
Handshake
Type
Server
Certificate
Handshake
Type
Certificate
Types
Distinguished
Names
Handshake
Type
…
11=Certificate
X509 Certificate
13=Certificate
Request
RSA, DSS… Any Names
14=Server
Hello Done

Table 5.28: 802.11 EAP response PEAP
Destination
Address
Source
Address
Ether-type EAPOL Type EAP Code EAP Type
AP Address Client Address
0x888E EAP Response PEAP
The client will respond to the intermediate server certificate messages with empty responses,
to keep the request/response protocol going (Table 5.28).
When the Server Hello Done message arrives at the client, the client will kick off the
second, inner phase of PEAP. First, the client responds with a Certificate handshake
message. If the client were going to provide a certificate, it would do so here. However,
with normal PEAP, the certificate message will be empty. Following this is the Client Key
Exchange. Let’s assume that the server and client agreed to RSA public key encryption. The
client chooses a random 48-byte premaster key, which is encrypted by the server
certificate’s RSA public key, and then packaged in the key field. Following this comes the
Change Cipher Spec message (Table 5.29), to inform the server that all future
communications will take place using encryption based on the key. Finally, the first
encrypted message is introduced, which is a marker, encrypted by the key, that states that
the cipher change is done.
Introduction to Wi-Fi 189
www.newnespress.com
Table 5.29: 802.11 PEAP client change cipher spec
Destination
Address
Source
Address
EAP Code Flags TLS Type Handshake
Type

Client
Certificate
AP Address Client Address
Response
none
Handshake Certificate
none
…
Handshake
Type
Key Handshake Type Handshake Type Encrypted
Handshake
…
22=Client Key
Exchange
Pre-master Key
20=Change
Cipher Spec
32=Encrypted
Handshake Message
Finished (encrypted
with TLS PRF)
Table 5.30: 802.11 PEAP server change cipher spec
Destination
Address
Source
Address
EAP Code TLS Type Handshake
Type
Handshake

Type
Encrypted
Handshake
Client
Address
AP Address
Request Handshake Change
Cipher Spec
Encrypted
Handshake
Message
Finished
(encrypted
with TLS
PRF)
Table 5.31: 802.11 EAP response PEAP
Destination
Address
Source
Address
Ether-type EAPOL Type EAP Code EAP Type
AP Address Client
Address
0x888E EAP Response PEAP
Table 5.32: 802.11 PEAP encrypted request identity
Destination
Address
Source
Address
EAP Code TLS Type EAP Code

(encrypted with
RC4)
EAP Type
(encrypted)
Client Address AP Address
Request
23=Application
Data
Request Identity
The server now responds with a Change Cipher Spec and Finished message (Table 5.30), to
mark the switch over of the protocol completely to the inner TLS tunnel.
The client, once again, sends an empty response (Table 5.31).
Now, the inner MSCHAPv2 protocol can take place. Table 5.32 will peel back the inner
TLS tunnel and reveal the contents. The inner tunnel will also present an EAP exchange,
but using MSCHAPv2, rather than TLS.