|
|
< Day Day Up > |
|
802.1x: The Gates to Your Wireless Fortress802.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:
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-TLSRFC 2284 describes EAP in the following way:
After the link has been established, EAP authentication is done in the following manner:
Refer to Figure 13-3 for an illustration of the EAP-TLS authentication process. Figure 13.3. 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 FormatAccroding 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. Figure 13.4. EAP packet layout. 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 CertificatesTo 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 IntegrationAs 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.confLocate 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 usersFor 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. SupplicantsUntil 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. LinuxThese 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 XPThis 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). Figure 13.5. Certification installation.
Figure 13.6. Certification installation. Once finished, you should install the private certificate by double-clicking <clientname>.p12 and following the instructions to install it (see Figure 13-7). Figure 13.7. Certification installation. 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). Figure 13.8. Certification installation. 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. Figure 13.9. Certification installation.
Figure 13.10. Certification installation.
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/users.html and try to find a solution for your errors. An Example of Access Point Configuration: Orinoco AP-2000The 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. Figure 13.11. RADIUS configuration on Orinoco AP-2000. Figure 13.12. RADIUS accounting configuration on Orinoco AP-2000. 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. Figure 13.13. RADIUS and 802.1x configuration on Orinoco AP-2000. Figure 13.14. RADIUS and 802.1x configuration on Orinoco AP-2000. |
|
|
< Day Day Up > |
|
