WiFoo..The.Secrets.of.Wireless.Hacking [Electronic resources] نسخه متنی

802.1x: The Gates to Your Wireless Fortress

802.1x is the standard that defines port-based security within a heterogeneous networking environment. It was initially developed for wired networks and currently has been adopted in the wireless medium as a part of the 802.11i standard. The adaptation of this standard was mainly due to the need to authorize legitimate users and restrict unauthorized parties on the inherently insecure wireless broadcasting medium. 802.1x and EAP have become very popular with the growing number of wireless networks, and the joined solution is increasingly being adopted by many companies for several reasons:

It can be relatively easily implemented, as it utilizes an authentication and security structure that is already widely used, such as RADIUS.

It provides strong security levels.

It provides per-session and per-user-based authentication that can be based on PKI.

It has support for one-time passwords and smart cards.

It easily scales to accommodate dynamically growing networks.

The aim of this section is to demonstrate the architectural deployment of secure WLAN access based on 802.1x and a strong authentication Layer 2 protocol such as EAP-TLS. Additionally, we aim to illustrate in practice how the combination of 802.1x and EAP-TLS can be utilized in a variety of scenarios for a client/server base on Windows and UNIX-based operating systems.

Basics of EAP-TLS

RFC 2284 describes EAP in the following way:

The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication which supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism at Link Control Phase, but rather postpones this until the Authentication Phase. This allows the authenticator to request more information before determining the specific authentication mechanism. This also permits the use of a "backend" server which actually implements the various mechanisms while the PPP authenticator merely passes through the authentication exchange.

After the link has been established, EAP authentication is done in the following manner:

Initially the authenticator sends Requests to authenticate the peer. The Request has a type field to indicate what is being requested. Examples of Request types include identity, MD5-challenge, one-time passwords, generic token card, and so on. The authenticator will send an initial Identity Request followed by one or more Requests for authentication information.

Later, the peer sends a Response in reply to each Request. As with the Request packet, the Response packet contains a type field that corresponds to the type field of the Request packet.

The authenticator ends the authentication process with a Success or Failure packet.

Refer to Figure 13-3 for an illustration of the EAP-TLS authentication process.

There are many advantages of the EAP, including support for multiple authentication methods without having to establish a particular mechanism during the Link Control phase. Additionally, NAS equipment does not necessarily have to understand each request type and can simply act as a forwarding agent for a "backend" RADIUS server. Thus, the device only needs to monitor the success and failure responses to determine the outcome of the authentication process.

Packet Format

Accroding to RFC 2284, "One PPP EAP packet is encapsulated in the Information field of a PPP Data Link Layer frame, where the protocol field indicates type hex C227 (PPP EAP)." Figure 13-4 indicates the layout of the EAP packet.

The structure of the EAP message is similar to the RADIUS packet, which was addressed in the first section of this chapter; thus, it is not discussed in great detail. To get more information on EAP packet types, consult RFC 2284.

After examining the basics of the authentication concept, such as 802.1x with EAP, we are ready to move on to the next part, which can be considered more of a case study. The study addresses practical concerns about how to integrate this authentication method into a workable solution on wireless networks in a home or corporate environment. For this we consider using Debian Linux with a FreeRADIUS server and an Orinoco AP-2000 access point that acts as NAS equipment to authenticate Linux and Windows clients. We also need several other utilities and scripts that are addressed as we progress through the case study.

Creating Certificates

To build a user-based authentication mechanism based on the PKI architecture, we need to generate a set server/client-based certificate that will act as a foundation for the authentication process. This process involves the creation of a certificate authority (CA) and the generation of server and client certificates.

To accomplish this, we are going to use a set of scripts that were modified from Raymond McKay's EAP/TLS HOWTO. These scripts are called CA.root, CA.server, and CA.client, as well as a file called xpextensions. Prior to using these scripts, you need to ensure that you have installed the OpenSSL package and modified the location of the SSL directory in scripts to suit your server specifics, unless you have Debian Linux (woody, testing, or unstable distribution), for which the scripts have already been adjusted. Additionally, you are advised to change all the instances of the certificate challenge password from testing111 to something more appropriate.

First, we generate a root CA authority by running the CA.root script and answering questions about your organization, such as location, name, organizational unit, and so on. This generates the following files:

-rw-------  1 andrei   andrei  1164 Jun  4 14:46 root.der
-rw-------  1 andrei   andrei  2765 Jun  4 14:46 root.p12
-rw-------  1 andrei   andrei  3817 Jun  4 14:46 root.pem
-rw-------  1 andrei   andrei  1631 Jun  4 15:20 demoCA/cacert.pem
-rw-------  1 andrei   andrei  1743 Jun  4 15:20 demoCA/private/cakey.pem

After the CA has been generated, we are ready to create a server certificate by running the CA.server script followed by the server name, like this:

arhontus:~# ./CA.server radius.core.arhont.com

This creates a set of certificate files for your server, which are later integrated with the RADIUS server. The following files are generated:

-rw------- 1 andrei   andrei    950 Jun  4 15:36 radius.der
-rw------- 1 andrei   andrei   2549 Jun  4 15:36 radius.p12
-rw------- 1 andrei   andrei   3530 Jun  4 15:36 radius.pem
-rw------- 1 andrei   andrei    132 Jun  4 15:36 demoCA/index.txt
-rw------- 1 andrei   andrei   4234 Jun  4 15:36 demoCA/newcerts/01.pem

The last step to undertake in this process is to create certificates for each of the participating users by running the CA.client script followed by a user name without any spaces, which is used as a user name in the RADIUS server users file:

arhontus:~# ./CA.client arhont

When you are finished generating client certificates, you should see the following files for each of the users you have created:

-rw-------  1 andrei   andrei   917 Jun  4 15:54 arhont.der
-rw-------  1 andrei   andrei  2517 Jun  4 15:54 arhont.p12
-rw-------  1 andrei   andrei  3446 Jun  4 15:54 arhont.pem
-rw-------  1 andrei   andrei  4158 Jun  4 15:54 demoCA/newcerts/02.pem

After you have created all the required certificates, you need to copy root.der and <username>.p12 to each of the client computers and install them to all Windows clients. The installation of client certificates is addressed in the "Supplicants" section later in this chapter. Additionally, root.pem and <servername>.pem are used for your FreeRADIUS setup, which is addressed in the next section. For compatibility reasons, you are also advised to place a copy of generated certificates into the OpenSSL directory, specified in the openssl.cnf file, which is usually found in /etc/ssl/.

FreeRADIUS Integration

As with practically everything in the UNIX world, the configuration process of the Linux FreeRADIUS server is nice, easy, and logical. From the previous section of this chapter you should understand the RADIUS protocol, and hopefully you have installed and configured the Free-RADIUS server. This section instructs you on how to enable EAP-TLS support of your server, so that mobile users can be authorized to use your wireless network on the basis of PKI authentication.

In this example we assume that you have created the /etc/1x directory with permissions, allowing read access to the FreeRADIUS server. Place a copy of root.pem and <servername>.pem in /etc/1x and make them readable by the RADIUS server as well. Because you have already edited the clients.conf file to allow your NAS equipment to connect to the server, you only need to edit the users and radiusd.conf files to finalize the 802.1x/EAP/RADIUS integration.

radiusd.conf

Locate the beginning of EAP configuration by the part that starts as shown here:

#  Extensible Authentication Protocol
#
#  For all EAP related authentications
eap {
.....
.....

And change it to look like this:

#  Extensible Authentication Protocol
#
#  For all EAP related authentications
eap {
default_eap_type = tls
timer_expire     = 60
# EAP-TLS is highly experimental EAP-Type at the
#  moment. Please give feedback on the mailing list.
tls {
private_key_password = testing111
private_key_file = /etc/1x/radius.pem
#       If Private key & Certificate are located
#         in the same file, then &
private_key_file certificate_file
#       must contain the same file name.
#      certificate_file = /etc/1x/radius.pem
#       Trusted Root CA list
CA_file = /etc/1x/root.pem
dh_file = /etc/1x/DH
random_file = /etc/1x/random
fragment_size = 1024
include_length = yes
}
}

Then edit the Authentication section and comment out the references to EAP. Before editing the users file, you should create two files with random data and make it readable by the FreeRADIUS process. These files are referenced as dh_file and random_file in the radiusd.conf. One way of generating these files would be as follows:

arhontus:~# dd if=/dev/urandom of=/etc/1x/DH bs=1K count=2048
arhontus:~# dd if=/dev/urandom of=/etc/1x/random bs=1K count=2048

users

For each user to be authenticated against EAP-TLS certifications, add the following line, where the <clientname> is the exact entry as entered in the Common Name when you were creating client certificates:

"<clientname>" Auth-Type := EAP

You are now ready to restart the FreeRADIUS server. Continue reading to find out how to configure client authentication procedures.

Supplicants

Until now we have been mainly dealing with the server side of the authentication procedure; now we need to address the client's side. First we cover the Linux client configuration using the Xsupplicant application, and then we consider the tedious clicking session needed to enable Windows clients. Don't tell me, I know, life isn't fair! Not only do you have to pay for this "stable," "user friendly," and "it just works" piece of software, you also have to waste your precious time clicking your way through it like a monkey (no offense to monkey.org folks)! Oh, well, isn't that what administrators are paid to do? We will not enter the great Windows versus UNIX debate here.

Linux

These guidelines should work on every distribution of Linux. First you need to download and install the Xsupplicant tool found at http://www.open1x.org. At the time of writing, the latest stable release was 0.6, but you can use the CVS version, which should have more features and usually works just as well. After downloading, do the following to extract, build, and install the package:

arhontus:~$ tar zxvf xsupplicant-0.6.tar.gz
arhontus:~$ cd xsupplicant
arhontus:~$ ./configure
arhontus:~$ make
arhontus:~# make install

Once successfully installed, you should copy ./etc/1x.conf into /etc/1x/ and edit it to look like this, replacing <clientname> with the exact string that was used for Common Name during certificate creation:

default:id = <clientname>
## the path to the certificate file to be used for the above user
default : cert = /etc/1x/arhont.der
## the path to the private key of the user for that cert
default : key = /etc/1x/arhont.pem
## the path to file containing all valid CA roots
default :root = /etc/1x/root.pem
default:auth = EAP
## Force this connection to wired or wireless.
## Needed in situations where wired drivers answer ioctls for
## wireless cards.
## Specifically, some intel cards with current drivers.
default:type = wireless
#default:type = wired
## preferred auth type
default :  pref = tls
## chunk size
default : chunk_size = 1398
## random file to use
default : random_file = /etc/1x/random
## Shell command to run after the FIRST successful authentication
## command MUST begin with a "/" (absolute path)
default : first_auth = "/sbin/dhcpcd eth1"
## shell command to run after ALL successful authentications
## the current semantics are that if first_auth is also defined,
## only it is run the first time and after_auth is run ever other
## time if first_auth is not defined, after_auth is run after ALL
## authentications including the first.
## command MUST begin with a "/" (absolute path)
default : after_auth = "/bin/echo I am alive"

Once this is done, you should read the later section on Orinoco AP-2000 to find out how to configure the example access point used for RADIUS and 802.1x. If your access point is already configured, you can simply run the following commands to authenticate yourself:

arhontus:~# /sbin/iwconfig eth1 essid l33t-wi-foo-net
arhontus:~# /sbin/ifconfig eth1 up
arhontus:~# xsupplicant -i eth1

where eth1 is your wireless interface and l33t-wi-foo-net is the ESSID of your wireless network.

If you run a DHCP server on your network, you should be automatically configured to use the network by now, otherwise you will need to manually configure the settings suitable for your network interface. This concludes the installation procedure for the Xsupplicant Linux client.

Windows 2000 and Windows XP

This part discusses the process of certificate installation as well as setting up the network connection that will use 802.1x/EAP-TLS authentication. Luckily enough, Windows XP has built-in support for 802.1x authentication, so if you are a Windows XP user, you don't have to download any additional patches.

Windows 2000 users need to apply the patch that enables you to perform 802.1x authentication. You can download it from the Microsoft Web site at http://www.microsoft.com/Windows2000/downloads/recommended/q313664/download.asp. After you download, install, and restart, you are now ready to enable this service by going to Control Panel, Administrative Tasks, Services and setting Wireless Configuration to Automatic and starting the service.

The following instructions should be similar for both Windows 2000 and Windows XP. After enabling the Wireless Configuration Service, you can import your root.der and <clientname>.p12 certificates by doing the following: Double-click root.der and follow the instructions to install it in Trusted Root Certificate Authorities (see Figures 13-5 and 13-6).

Once finished, you should install the private certificate by double-clicking <clientname>.p12 and following the instructions to install it (see Figure 13-7).

Note:
If you do not want your clients to enter a passphrase each time they use this certificate, leave the Enable Strong Private Key Protection check box cleared. For security reasons we strongly recommend enabling this option for mobile clients (see Figure 13-8).

Once the certificate is installed, you should enable the network connection to utilize the 802.1x/EAP feature by going to Control Panel, Network and Dial-up Connections, right-clicking on your wireless connection, such as the Local Area Connection icon, selecting Properties, going to the Authentication tab, and selecting the options shown in Figures 13-9 and 13-10.

After following these instructions, you should have automatically authenticated your certificate against the RADIUS server. If you are having difficulties, you should run the FreeRADIUS server with debugging options like freeradius -X -A and fix any inconsistencies and errors that can be traced. If debugging doesn't help, contact the FreeRADIUS user group at http://www.freeradius.org/list/usersl and try to find a solution for your errors.

An Example of Access Point Configuration: Orinoco AP-2000

The methodology for enabling 802.1x/EAP authentication on your NAS equipment should be similar for different manufacturers. As an example, we refer to the setup procedures on the Orinoco AP-2000 access point that was kindly provided to Arhont for testing purposes by Proxim.

Now, log in to your access point, go to Configure, and click RADIUS. Enter your FreeRADIUS server details, including the shared secret that you have specified in the clients.conf file of your FreeRADIUS configuration directory. You should also enable RADIUS accounting. The settings should look similar to what is shown in Figures 13-11 and 13-12.

Now, go to the Security tab and enable Mixed Mode in 802.1X Security Mode, which includes compatibility with existing WEP users and 802.1x-enabled clients. If you prefer not to use WEP at all, only enable 802.1x authentication protocol and completely disable WEP encryption. You'll need to restart your access point to enable the new settings and you are all sorted out (see Figures 13-13 and 13-14). Enjoy your EAP-TLS authentication scheme.