Scalable voip mobility intedration and deployment- P19 pdf

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 t

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

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 Controller Access Point

Supplicant

User Credentials

Authenticator/

NAS

Figure 5.22: The Components of RADIUS Authentication Over Wi-Fi

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 jepstein@somecompany.com, 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

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

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

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

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

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

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

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

Table 5.23: 802.11 EAP request identity

Destination

Address

Source Address

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)

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

Type

AP

Address

user

Table 5.25: 802.11 EAP request PEAP

Destination

Address

Source Address

Client

Address

Table 5.26: 802.11 PEAP client hello

Destination

Address

Source

Address

Type

Nonce Cipher

Suites

AP Address Client

Address

Response PEAP 22=Handshake 1=Client

Hello

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

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

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

Table 5.29: 802.11 PEAP client change cipher spec

Destination

Address

Source Address

Type

Client Certificate

AP Address Client Address Response none Handshake Certificate none

…

Handshake

Type

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

Type

Handshake Type

Encrypted Handshake

Client

Address

Cipher Spec Handshake Encrypted

Message

Finished

(encrypted with TLS PRF)

Table 5.31: 802.11 EAP response PEAP

Destination

Address

Source Address

AP Address Client

Address

Table 5.32: 802.11 PEAP encrypted request identity

Destination

Address

Source Address

(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