This section walks you through some of the steps of building open source applications that you can use for setting up and evaluating a WPA or RSN network. "There is no such thing as a free lunch" and the hidden cost of using the open source projects is that you need substantial system knowledge and, to some extent, an understanding of computer programming. The vast majority of people choose instead to purchase commercial solutions and obtain professional support for installation. However, we'll take the time here to show how you can set up a test environment and even create a real operating network from tools that can be downloaded over the Internet, and we're also going to show you how to build an access point yourself using UNIX.
Our goals are to help anyone who likes to tinker and is somewhat familiar with UNIX. If that does not describe you, consider skipping this section.
We cover two versions of UNIX in this section. For the open source access point, we use the OpenBSD operating system (www.openbsd.org), and for the infrastructure, we use Red Hat Linux. For more information please see our Web site (www.wpa-security.org).
This section shows how to use open source projects to create your own infrastructure. There are two reasons for this step. First, you may find that the open source project actually provides what you need to protect your network. Second, even if you eventually plan to use a commercial server, the exercise of seeing how the open source project is structured should be informative.
There are two specific projects that we're going to discuss: OpenSSL and FreeRADIUS:
OpenSSL provides cryptographic primitives as well as some command line tools for creating and manipulating public key certificates. We use OpenSSL to help build a limited PKI.
We use FreeRADIUS to provide the authentication server using the RADIUS protocol as the central point of our infrastructure.
If you're going to be using WPA with server-based keys in a medium to large organization, you'll need a public key infrastructure. There are several commercial products available, but fortunately, there are also a few open source projects. The most significant is the OpenCA effort found at www.openca.org/, but it is somewhat wanting, unfortunately. Rather than focus on the details of establishing an entire certificate authority, we're going to show you how to build self-signed certificates using OpenSSL. This approach is sufficient for testing, or for a small-to-medium-sized network. The point is to show you what is involved without having to get lost in the details of a PKI.
You can download the latest version of the OpenSSL from www.openssl.org. At the time of this writing, the most recent version was 0.9.7a. This is the version we'll use in our examples, but you should be able to use later versions when they are released. Before using a newer version, check with the FreeRADIUS site to see whether an older version of OpenSSL is required; the two projects are not well synchronized at the moment. You also only need the base OpenSSL distribution; you don't need the OpenSSL-engine file unless you plan on using specialized cryptographic support. In that case, you probably don't need these instructions anyway.
Once you download the file, you need to change your working directory to the location where you place source code, in other words, /usr/local/src, and check the digital signature on the following file and untar it.
cd /usr/local/src tar xvfz openssl-0.9.7a.tar.gz
The OpenSSL development team has made the compilation of OpenSSL easy and straightforward, as shown in the following syntax. This syntax works using Red Hat 7.3 and 8.0. But, you must use a different method for OpenBSD; see www.cs.umd.edu/~arunesh/bsd/openssl.html. Also, you need to be careful not to overwrite the current installation of OpenSSL when using Red Hat because that will break some of the precompiled programs in your operating system distribution. The following commands install OpenSSL in the /usr/local directory so you don't overwrite the previous installed version.
cd openssl-0.9.7a ./config shared --prefix=/usr/local/openssl make make install
All of the previous commands should complete without error messages.
Once OpenSSL is installed, you need to make some minor changes to the configuration files to make it easier to make certificates (see the next section). The file that requires editing is /usr/local/openssl/ssl/openssl.cnf. The changes only involve modifying the default values for some of the options in certificate requests. If you're going to generate only one or two certificates, you don't really have to make these changes. If you're going to generate more certificates than that, you definitely should make these changes. You may also want to consider increasing the length of time a certificate is valid as well. The changes you want to make are all in the lines that have "default" as a portion of the identifier in the first column. An excerpt from the openssl.cnf file follows, with the changes we made in bold.
# req_extensions = v3_req # The extensions to add to a certificate request [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = US countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default= Maryland localityName = Locality Name (eg, city) localityName_default = College Park 0.organizationName = Organization Name (eg, company) 0.organizationName_default= University of Maryland # we can do this but it is not needed normally :-) #1.organizationName = Second Organization Name (eg, company) #1.organizationName_default= World Wide Web Pty Ltd organizationalUnitName= Organizational Unit Name (eg, section) organizationalUnitName_default= Department of Computer Science commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 # SET-ex3 = SET extension number 3 [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 challengePassword_default= ChangeMe! unstructuredName = An optional company name
There are several steps involved in created certificates that you can use with 802.1X. First, you need to create a certificate authority certificate. This is self-signed; in other words, the certificate authority attests to the validity of itself. While this might surprise you, it is the commonly accepted method for creating a root certificate. Once the certificate authority, or root, is created, you need to create a server certificate for your RADIUS server. Then, you create certificates for all of your clients.
Several people, most recently Raymond McKay (www.impossiblereflex.com/8021x/eap-tls-HOWTO.htm), have created scripts to automate the commands needed to create a certificate authority using OpenSSL. The following script creates the self-signed root certificate.
CA.root file
#!/bin/sh
SSL=/usr/local/openssl
export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH}
export LD_LIBRARY_PATH=${SSL}/lib
# private key into the CA directories
rm -rf demoCA
echo "**************************************************************"
echo "Creating self-signed private key and certificate"
echo "When prompted change the default value for the Common Name field"
echo "**************************************************************"
echo
# Generate a new self-signed certificate.
# After invocation, newreq.pem will contain a private key and certificate
# newreq.pem will be used in the next step
openssl req -new -x509 -keyout newreq.pem -out newreq.pem ?passin \
pass:whatever -passout pass:whatever
echo "**************************************************************"
echo "Creating a new CA hierarchy (used later by the "ca" command)"
echo "and private key created in the last step"
echo "**************************************************************"
echo
echo "newreq.pem" | CA.pl -newca >/dev/null
echo "**************************************************************"
echo "Creating ROOT CA"
echo "**************************************************************"
echo
# Create a PKCS#12 file, using the previously created CA certificate/key
# The certificate in demoCA/cacert.pem is the same as in newreq.pem.
# Instead of using "-in demoCA/cacert.pem" we could have
# used "-in newreq.pem" and then omitted
# the "-inkey newreq.pem" because newreq.pem contains both the
# private key and certificate
openssl pkcs12 -export -in demoCA/cacert.pem -inkey newreq.pem ?out\
root.p12 -cacerts -passin pass:whatever -passout pass:whatever
# parse the PKCS#12 file just created and produce a PEM format
# certificate and key in root.pem
openssl pkcs12 -in root.p12 -out root.pem -passin pass:whatever \
-passout pass:whatever
# Convert root certificate from PEM format to DER format
openssl x509 -inform PEM -outform DER -in root.pem -out root.der
#Clean Up
rm -rf newreq.pem
You create the self-signed root certificate now by executing:
/bin/bash CA.root
and answering all of the questions.
To perform a mutual authentication between the RADIUS server and the supplicant, you must have a public key certificate for the server. This section provides the set of commands that you must execute to request a certificate and then have it signed by your root certificate.
An important part of creating the server certificate, and the client certificate that you create in a few moments, is ensuring that the certificate has the appropriate OIDs to support Microsoft Windows XP. Now, you're probably asking, "What is an OID?" Well, don't worry, all you really need to know about them is that they're essentially a capability, indicating what type of service the holder of the certificate may use.
The OIDS needed for certificates for use with Windows XP follow. The script creating both the client and server certificates assumes that the OIDs are included in a file named xpextensions located in the same directory as you run the script.
xpextensions file [ xpclient_ext] extendedKeyUsage = 1.3.6.1.5.5.7.3.2 [ xpserver_ext ] extendedKeyUsage = 1.3.6.1.5.5.7.3.1 CA.server file #!/bin/sh SSL=/usr/local/openssl export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH} export LD_LIBRARY_PATH=${SSL}/lib echo "*****************************************************************" echo "Creating server private key and certificate" echo "When prompted enter the server name in the Common Name field." echo "*****************************************************************" echo # Request a new PKCS#10 certificate. # First, newreq.pem will be overwritten with the new certificate request openssl req -new -keyout newreq.pem -out newreq.pem ?passin \ pass:whatever -passout pass:whatever # Sign the certificate request. The policy is defined in the # openssl.cnf file. # The request generated in the previous step is specified with the # -infiles option and # the output is in newcert.pem # The -extensions option is necessary to add the OID for the extended # key for server authentication openssl ca -policy policy_anything -out newcert.pem ?passin \ pass:whatever -key whatever -extensions xpserver_ext ?extfile \ xpextensions -infiles newreq.pem # Create a PKCS#12 file from the new certificate and its private # key found in newreq.pem # and place in file specified on the command line openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out $1.p12 \ -clcerts -passin pass:whatever -passout pass:whatever # parse the PKCS#12 file just created and produce a PEM format # certificate and key in certsrv.pem openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:whatever ?passout \ pass:whatever # Convert certificate from PEM format to DER format openssl x509 -inform PEM -outform DER -in $1.pem -out $1.der # Clean Up rm -rf newcert.pem newreq.pem
Save the script above to the file CA.server, and then create the server certificate by invoking the script with the name of the server (without spaces or special characters) as follows.
/bin/bash CA.server <servername>
When you are asked to enter the common name, you must enter the same name as you used in executing the script, for example, <servername>.
Now that you've created the certificate for the RADIUS server, you can create your client certificates (we'll discuss installing them on clients shortly). The following script shows the commands necessary to request and sign individual client certificates. Remember to have the proper OID file so you can use the resultant certificate with a Windows XP client as well.
CA.client file #!/bin/sh SSL=/usr/local/openssl export PATH=${SSL}/bin/:${SSL}/ssl/misc:${PATH} export LD_LIBRARY_PATH=${SSL}/lib echo "****************************************************************" echo "Creating client private key and certificate" echo "When prompted enter the client name in the Common Name field." echo " This is the same name used as the Username in FreeRADIUS" echo "****************************************************************" echo # Request a new PKCS#10 certificate. # First, newreq.pem will be overwritten with the new certificate request openssl req -new -keyout newreq.pem -out newreq.pem ?passin \ pass:whatever -passout pass:whatever # Sign the certificate request. The policy is defined in the # openssl.cnf file. # The request generated in the previous step is specified with # the -infiles option and # the output is in newcert.pem # The -extensions option is necessary to add the OID for the # extended key for client authentication openssl ca -policy policy_anything -out newcert.pem ?passin \ pass:whatever -key whatever -extensions xpclient_ext ?extfile \ xpextensions -infiles newreq.pem # Create a PKCS#12 file from the new certificate and its private # key found in newreq.pem # and place in file specified on the command line openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out $1.p12 \ -clcerts -passin pass:whatever -passout pass:whatever # parse the PKCS#12 file just created and produce a PEM format # certificate and key in certclt.pem openssl pkcs12 -in $1.p12 -out $1.pem -passin pass:whatever ?passout \ pass:whatever # Convert certificate from PEM format to DER format openssl x509 -inform PEM -outform DER -in $1.pem -out $1.der # clean up rm -rf newcert.pem newreq.pem
You use the previous script, saved to the file ca.client, to generate your client certificates by invoking the script with the following command without spaces or special characters in <username>.
/bin/bash ca.client <username>
Be sure to use the <username> as the common name when you create the certificate. You'll also use the same name when you create the RADIUS files.
Make a copy of the files created by executing the previous scripts, root.pem and <servername>.pem, and copy them to the directory /usr/local/1x/etc/. You'll probably have to make that directory first. You also need to save the files root.der and <username>.p12 for installation on the client machine. We describe that process a bit later in this chapter when we describe how to set up the client.
FreeRADIUS is the most widely used open source RADIUS server found at www.freeradius.org. RADIUS is a complicated protocol that can be configured in a large number of different ways. In this section, we discuss only a very basic configuration. If you're planning on using FreeRADIUS as part of your infrastructure, you definitely want to obtain a more detailed guide such as the O'Reilly book RADIUS by Jonathan Hassell (2003).
You can download the most recent version of FreeRADIUS from the Web site www.freeradius.org/getting.html. The most recent version at the time of writing is 0.8.1. This version has complete support for both authentication and dynamic keys. Make sure you download the signature of FreeRADIUS as well. The developers of FreeRADIUS used a detached signature (file ending in .sig) rather than an ASCII armored signature (file ending in .asc). Verifying this signature is very similar to the approach shown in Appendix B. The only difference is that you will be asked to enter the name of the file you want verified.
Now, change your working directory to your source directory and untar the FreeRADIUS source.
cd /usr/local/src tar xvfz freeradius-0.8.1.tar.gz
Compiling FreeRADIUS is similar to compiling OpenSSL except that you have to make a few changes to the files to support EAP-TLS. First, you configure the source code by using the configure program.
cd freeradius-0.8.1 ./configure --prefix=/usr/local/radius
Once the source is configured, you must make one small change to a makefile included with the source to ensure that FreeRADIUS can find your version of OpenSSL and compile EAP-TLS properly. The file that you must modify is the subdirectory src/modules/rlm_eap/types/rlm_eap_tls/ under your main FreeRADIUS directory. The changes you need to make are to ensure that the header and library files from OpenSSL can be found. A modified makefile follows.
# Generated automatically from Makefile.in by configure. TARGET = rlm_eap_tls SRCS = rlm_eap_tls.c eap_tls.c cb.c tls.c RLM_CFLAGS = $(INCLTDL) -I../.. ?I/usr/local/openssl/include HEADERS = eap_tls.h RLM_INSTALL = # NOTE: You may have to switch the order of ?lssl and ?lcrypto below RLM_LIBS += -lssl -lcrypto RLM_LDFLAGS += -L/usr/local/openssl/lib $(STATIC_OBJS): $(HEADERS) $(DYNAMIC_OBJS): $(HEADERS) RLM_DIR=../../ include ${RLM_DIR}../rules.mak
You'll end up adding "-I/usr/local/openssl/include" to the line beginning with RLM_CFLAGS, and an entirely new line beginning with RLM_LDFLAGS, and you may have to switch the order of ?lssl and ?lcrypto.
Now, you can compile the FreeRADIUS source just like we did OpenSSL with the following two commands from the main FreeRADIUS directory.
make make install
The compile and install should complete without errors.
Now, you're ready to make the changes to the various FreeRADIUS configuration files. There are three files that you must modify (remember you're only doing a basic setup here), and they are all located in the directory /usr/local/radius/etc/raddb. The files are clients.conf, radiusd.conf, and users.
The clients.conf file is responsible for determining who/what can connect to the RADIUS server to authenticate users. In your case, you want the access points to be able to connect. There are two ways to enter the access point information. First, list each access point individually. Second, list a subnet. A key point for security here is that if you decide to use the subnet approach, all of the access points will use the same password?not the best idea from the standpoint of security; however, if you have hundreds of access points, a separate password for each becomes a management nightmare. The choice is yours.
You can specify an access point at a time by using the following template.
client <ipaddress> { secret = <password> shortname = <descriptive_name_for_accounting_purposes> }
You would create a copy of the template, above, for each access point, entering the IP address, password, and name for each into your clients.conf file.
The second approach is to use a single entry for an entire local area network of access points. You do this using the following template.
client <subnet>/<mask> { secret = <password> shortname = LAN }
You enter the subnet and mask along with the globally shared password into the previous template and place it in the clients.conf file. Remember, you need to use only one of the approaches we outlined.
You need to change only a few parts of this file. But, you need to create two new files, /usr/local/radius/etc/raddb/DH and /usr/local/radius/etc/raddb/random, as part of the changes. The contents of both of these files need to be random so you use the Linux random device to create files with the following commands.
dd if=/dev/random of=/usr/local/radius/etc/raddb/random count=1 bs=128 dd if=/dev/random of=/usr/local/radius/etc/raddb/DH count=1 bs=128
This creates two files with 128 random bytes each. The device /dev/random may block if there is insufficient entropy (randomness) available. If one of these commands hang, you can do one of two things. First, you can wait a while until the entropy pool is refreshed, or second, you can use the /dev/urandom device instead, which will not block (at the cost of the bytes being generated by a pseudorandom function).
Once you've created these two files, you need to make your changes to radiusd.conf. The first set of changes is to the following Extensible Authentication Protocol section. The items in bold were changed from the original file.
# Extensible Authentication Protocol # # For all EAP related authentications eap { # Invoke the default supported EAP type when # EAP-Identity response is received default_eap_type = tls # Default expiry time to clean the EAP list, # It is maintained to co-relate the # EAP-response for each EAP-request sent. timer_expire = 60 # Supported EAP-types # md5 { # } ## FIXME: EAP-TLS is highly experimental EAP-Type at the moment. # Please give feedback. tls { private_key_password = whatever# CHANGE THIS TO YOUR PASSWORD private_key_file = /usr/local/1x/etc/<servername>.pem # Sometimes Private key & Certificate are located # in the same file, then private_key_file & certificate_file # must contain the same file name. certificate_file = /usr/local/1x/etc/<servername>.pem # Trusted Root CA list CA_file = /usr/local/1x/etc/root.pem dh_file = /usr/local/1x/etc/DH random_file = /usr/local/1x/etc/random # # This can never exceed MAX_RADIUS_LEN (4096) # preferably half the MAX_RADIUS_LEN, to # accomodate other attributes in RADIUS packet. # On most APs the MAX packet length is configured # between 1500 - 1600. In these cases, fragment # size should be <= 1024. fragment_size = 1024 # include_length is a flag which is by default set to yes # If set to yes, Total Length of the message is included # in EVERY packet we send. # If set to no, Total Length of the message is included # ONLY in the First packet of a fragment series. include_length = yes } }
Change your EAP section to match the previous script, being sure to change the private_key_password and the names of the private_key_file and certificate_file attributes to your file names. You also need to ensure that the paths are set to where you've placed the files you generated using OpenSSL.
Now, you need to make changes to the authorization section and uncomment the eap line so the section looks like the one that follows. The important part is that eap must be added as supported.
# Authorization. First preprocess (hints and huntgroups files),
# then realms, and finally look in the "users" file.
# The order of the realm modules will determine the order that
# we try to find a matching realm.
# Make *sure* that 'preprocess' comes before any realm if you
# need to setup hints for the remote radius server
authorize {
#
# The preprocess module takes care of sanitizing some bizarre
# attributes in the request, and turning them into attributes
# which are more standard.
#
# It takes care of processing the 'raddb/hints' and the
# 'raddb/huntgroups' files.
#
# It also adds a Client-IP-Address attribute to the request.
#
preprocess
#
# The chap module will set 'Auth-Type := CHAP' if we are
# handling a CHAP request and Auth-Type has not already been set
#
# chap
# counter
# attr_filter
eap
suffix
files
# etc_smbpasswd
}
Now, you make your last change to the Authentication section, uncommenting the reference to EAP. Again, the important part is that EAP (eap in bold above) be uncommented.
# Authentication.
#
# This section lists which modules are available for authentication.
# Note that it does NOT mean 'try each module in order'. It means
# that you have to have a module from the 'authorize' section add
# a configuration attribute 'Auth-Type := FOO'. That authentication type
# is then used to pick the appropriate module from the list below.
#
# The default Auth-Type is Local. That is, whatever is not included
# inside
# an authtype section will be called only if Auth-Type is set to Local
#
# So you should do the following:
# Set Auth-Type to an appropriate value in the authorize section. For
# example chap
# will set Auth-Type to CHAP, ldap to LDAP etc
# After that create corresponding authtype sections in the authenticate
# section below
# and call the appropriate modules (chap for CHAP etc)
authenticate {
# pam
unix
# Uncomment it if you want to use ldap for authentication
# authtype LDAP {
# ldap
# }
# mschap
eap
# Uncomment it if you want to support CHAP
# authtype CHAP {
# chap
# }
# Uncomment the following if you want to support PAP and you
# extract user passwords from the user database (LDAP,SQL, etc).
# You should use the 'files'module to set 'Auth-Type := PAP' for
# this to work.
# authtype PAP {
# pap
# }
#
}
Open the users file in your favorite editor and search for the string "John Doe". Now, enter a line for each of your client certificates using their full name, as follows:
"<clientsfullname>" Auth-Type := EAP
You can also add the following line for testing purposes, but make sure to remove it after your testing is completed.
"test" Auth-Type := Local, User-Password == "test"
Now, you're ready to test your installation. Because FreeRADIUS may be using a different version of OpenSSL than the one installed on your system, you need to build a custom shell to start the FreeRADIUS daemon in a way that it can find the OpenSSL libraries. Use the run-radiusd script created by Adam Sulmicki, as follows.
#!/bin/bash -x export LD_LIBRARY_PATH=/usr/local/openssl/lib export LD_PRELOAD=/usr/local/openssl/lib/libcrypto.so /usr/local/radius/sbin/radiusd $@
Now, start FreeRADIUS in debug mode from a shell, as follows:
run-radiusd ?X ?A
You'll see a great deal of output, and eventually the last line should read "Ready to process requests." You can now test the installation with the following command:
/usr/local/radius/bin/radtest test test localhost 0 testing123
If you get Access-Accept, everything is configured properly and you can delete the test line from the users file. You may also want to delete the entry for localhost in the clients.conf file. If, however, you get no response or Access-Reject, you need to review the configuration files. You may also have to either disable your packet filtering firewall (in other words, iptables), with the command service iptables stop or add a rule to permit the RADIUS requests to work on port 1812.
In this section, we're going to show you how to build an access point yourself using UNIX. The access point you'll build won't have WPA support (it wasn't completed at the time this book was written), but we'll provide links and how-to's on our Web page, www.wpa-security.org, once the work is finished.
If you are building your own access point, there's a limited amount of hardware you can use. The easiest, and most expensive, is to use a laptop. An alternative is to use a low-cost single-board computer running an Intel-compatible CPU such as those available at www.soekris.com.
In the next section, we're going to assume that you're using a laptop.
Linux, FreeBSD, and OpenBSD all have the capability of running as an access point using a WLAN card based on the Intersil Prism2 chipset. These cards are the most common cards available, with manufacturers such as Samsung, Compaq, and others shipping PCMCIA WLAN cards based on the Prism2 or Prism2.5 chipsets. At the time of writing, a list of companies using the Intersil Prism 2 chipset was available at: www.intersil.com/design/prism/prismuser/index.asp
We cover how to use both OpenBSD and Linux as access points.
For the first step, you need to install the latest version of the OpenBSD operating system. The installation files and instructions can be found at www.openbsd.org. Once the operating system is installed, you can begin setting the system up as an access point. You're going to be amazed at how easy it is to turn a laptop into an access point, albeit an expensive one.
The first step is to set up your wired network connection, assuming that you'll be using your access point to connect to a wired network and not as a stand-alone server. Details on how to do this can be found at the OpenBSD Web site.
The second step is to insert your Prism2 WLAN card into the laptop. The console window should display several lines of information about wi0. This is the operating system kernel recognizing the card you just inserted. One of the lines should start with "wi0: PRISM 2". If not, the card you are using may not be a PRISM2-based card, and these instructions will not work for you.
At this point, it would probably help if you familiarized yourself with the manual page for the wicontrol command by typing:
man wicontrol
The command wicontrol configures Prism2-based wireless cards. As you could see from the manual entry, you are able to select normal station mode, ad-hoc mode, or hostap mode. The last mode, hostap, is what we're discussing here. wicontrol also allows you to set the channel, MAC address (remember earlier when we said it was easy to clone MAC addresses? You use wicontrol.), WEP, and the WEP keys. Unfortunately, right now the default distribution of OpenBSD (and the other open source UNIX-based projects) supports only vanilla WEP. The University of Maryland MISSL group, however, is working on incorporating WPA into OpenBSD. While it is too early to describe this work in this book, we'll have more details on the MISSL Web page (www.missl.cs.umd.edu), and on the Web page for this book (www.wpa-security.org).
Okay. Now that you're familiar with wicontrol, we can configure and turn on our home brew access point using the following commands as root.
wicontrol wi0 ?e 1 ?k "Hello" ?p 6 ?f 11 ?n myap # Make sure the IP_address is on the same subnet as your wired device ifconfig wi0 inet <IP_address> netmask <Net_mask> # Or you can use DHCP to configure the IP address brconfig bridge0 add <wired_device> add wi0 up
The first command enables WEP encryption using the key "Hello" as well as hostap mode on channel 11, and the command assigns the network name of "myap". In the second command, we're manually configuring the IP address for the machine. You could also use DHCP for this as well. The third and final command enables bridging between the wireless interface (our AP) and the wired interface just like the commercial access points.
That's it. We're done. If you set up the wired device with routing and so on, and you have a DHCP server running, you can start up a client and associate and start using your new AP!
You should, however, add additional security to the AP by using the built-in IPsec implementation. You can start learning about this from the OpenBSD documentation, and several how-to's that you'll find linked to our Web site.
You can also use Linux as your base operating system, and we've used Linux Red Hat 8.0 and the hostap software by Jouni Malinen at www.hostap.epitest.fi/. The hostap software is another implementation of a prism2/2.5/3 driver for UNIX. Hostap, however, includes support for MAC access control lists, IEEE 802.1x, dynamic WEP rekeying, RADIUS, and minimal support for interaccess point protocol support (IAPP).
The hostap software has a large number of capabilities, and covering them all here would be difficult. Therefore for the sake of brevity, we won't cover much about hostap here. But, we will post more information on our Web site (www.wpa-security.org).
Now that your server infrastructure is built, we can talk about configuring your access points to use your servers. Given the large number of access points available on the market today, we can't present configuration information for all of them. Therefore, we've picked one of the more common access points. While we're not covering many access points, we will include links to sources of information about other access points on our Web site.
We're also only going to describe configuring Microsoft Windows XP for the very same reasons, but again we will provide links to a how-to for configuring an open source supplicant, Xsupplicant, at the end of this chapter and on our Web site.
Currently, not all of the commercial access points support IEEE 802.1X. That will change as WPA becomes more widely available. Until then, IEEE 802.1X is currently only supported by the major wireless vendors such as Cisco, Agere, and a few others. If you're going to buy a new access point, you must be certain that it supports IEEE 802.1X if you want to use the best security available.
The following sections give some practical examples of configuring the Cisco products via their Web interface. Note that we cannot guarantee the accuracy of this information because products change, and you should consult the documentation provided with the product for definitive information.
Configuring a Cisco AP to use IEEE 802.1X is straightforward and involves only a few changes to the AP configuration. This section uses the Web management interface, but you can do this configuration via the console as well.
First make sure that you're running at least firmware version 11.08T to ensure that IEEE 802.1X support is available.
From the home page of the Web-based interface, select Setup to open the menu shown in Figure 17.2.
Select Security at the bottom of the screen to open the screen shown in Figure 17.3.
Select the fifth item from this screen, Authentication Server, to set up the server, as shown in Figure 17.4.
This screen is the first of the two screens in which you do all of your work. In the first column, enter the IP address for your FreeRADIUS server. Now select RADIUS from the Server Type dropdown menu. Enter the port number, 1812, into the Port column, followed by the shared secret that you used when you set up the file clients.conf as part of the FreeRADIUS configuration earlier. Finally, set the timeout to the default 20 seconds. Click OK, and return to the Security Setup screen. Now select Radio Data Encryption (WEP) (Figure 17.5).
Select Open for both Accept Authentication Type and Require EAP. Now, go back to the Security Setup screen, and select Radio Data Encryption (WEP) again. You should see the screen shown in Figure 17.6.
In the first dropdown menu, make sure you select Full Encryption; if you do not make this selection, Windows XP will not associate with your access point. Now, you need to select the first WEP key and enter a value for the key. This key is the multicast key only, and will be used only when the AP transmits multicast data. Clients will still negotiate pairwise keys.
802.1X supplicant (or client) support is currently only built into Windows XP. However, several vendors are now supporting previous versions of Windows, and an open source implementation is available for most open source UNIX-based operating systems.
There are two steps in configuring Windows XP SP1. The configuration for XP SP1 is slightly different from that for XP, but you should be able to work through those differences. The how-to's listed at the end of this chapter cover XP configuration, so XP SP1 configuration is covered here to show you how to use 802.1X with your infrastructure. In the first step, the certificates you generated earlier are installed on the client. The second step involves configuring the wireless device on Windows XP.
You should update your version of Windows XP to Service Pack 1. SP1 contains an important security patch that can prevent a man-in-the-middle attack due to a malformed packet. Therefore, the remaining instructions assume a SP1 installation.
For this step, we need the root.der and <clientusename>.p12 files you created earlier. Copy both files to the Windows XP client. Now, double-click the root.der file to display the popup window shown in Figure 17.7.
Click the Install Certificate button to open the Certificate Import Wizard. Click the Next button to open the window shown in Figure 17.8.
Select the option Place all certificates in the following store and click Browse to open a browser, as shown in Figure 17.9.
Select Trusted Root Certificate Authorities and click OK and then Next and Finish. Answer Yes when you're asked if you want to import the certificate. Now, you should see a message that the certificate was imported successfully.
Now, double-click the <clientusername>.p12 file. The Certificate Import Wizard appears once again. Click Next and leave the filename alone and click Next again. Now, you are asked to enter the challenge password you used when generating the certificate. Click Next. Select the option "Automatically select the certificate store based on type of certificate" and click Next. Wait for a message indicating that the certificate was imported successfully, and then click Finish. A popup window will tell you that you imported the certificate correctly.
Now you can set up the wireless device.
Open the Wireless Configuration Panel by double-clicking on one of the terminals icon in the lower-right corner of your screen. You can find the correct icon by moving your mouse over the icons until one says "Wireless Network". That is the icon you need to double-click (see Figure 17.10).
Select your network, and check the Advanced tab to open the panel shown in Figure 17.11.
Select your network and click the Authentication tab to open the window shown in Figure 17.12.
Now select the Enable network access control using IEEE 802.1X radio button and ensure that the EAP type is listed as Smart Card or other Certificate. Click the Properties button to open the Smart Card or Other Certificate Properties window shown in Figure 17.13.
Select the options Use a certificate on this computer and Validate server certificate, and ensure that the Trusted root certificate authority option is set to the root certificate you imported earlier.
If everything works (which we know always is the case), you'll be connected to your network using WPA.