not logged in | [Login]
Always use radiusd -X when debugging!
This document is intended as a practical document with a view to getting WPA authentication up-and-running as quickly and as easily as possible. We therefore gloss over most of the theory behind 802.1x, WPA, cryptosystems, digital signatures and certificates, etc.
Note: This guide is primarily focused on windows users. For a linux-focused (Rasberry Pi running Raspbian) install guide, check out: http://binaryheartbeat.blogspot.com/2013/12/raspberry-pi-based-freeradius-server.html
In short — security. Wi-Fi Protected Access implements a sub-set (or instance, if you like) of the IEEE's 802.1x authentication standards for wireless networks, and does so in a method compliant with the (at time of writing) forthcoming 802.11i standard. WPA provides for both authentication (assuring the identity of a client machine, the supplicant) and encryption (ensuring exchanges between the wireless access point and client are secure).
The encryption provided by WPA is considered to be much more secure than traditional WEP. WEP uses RC4 cryptography usually with a fixed key of 64 to 256 bits in length, and because of this an attack on a WEP-secured network can be mounted by collecting packets for analysis and extracting the key from them. Such a crack can take as long as a matter of days on a small, household network, to a few hours on a busy corporate system. WPA, on the other hand, uses the Temporal Key Integrity Protocol system, TKIP. This has a number of fancy features (with names like "per-packet mixing") that I don't understand, but most importantly the keys are changed over time to make an attack difficult. Some "unofficial" extensions to WPA (that I've found on my hardware, and will probably be on others' as well) also allow AES (alias "Rijndael") encryption, which I believe to the strongest of the lot (although I might be wrong here).
WPA Pre-Shared Key (WPA-PSK, or "WPA Personal") is the first kind of WPA, and is trivial to set up (so it's not covered in this document). This uses a password (which can be up to 63 characters in length) to shared between access point and client (a "shared secret") to authenticate, and act as the starting point for the cryptographic process.
WPA with 802.1x and EAP authentication ("WPA Enterprise") is the second form, and it's what we'll be setting up in this document. The Extensible Authentication Protocol is a provision of 802.1x that allows a variety of means of authenticating clients, and in our case we will be using TLS. This involves issuing potential client machines with digital certificates which have been signed by some authority in such a way that they cannot (for all practical purposes) be forged by an attacker. The access point achieves this by requesting the client's certificate and passing it to a RADIUS server, which then checks the certificate is genuine and whether the named client is allowed access. These certificates are also used as a starting point for the cryptographic process.
Personally, I chose WPA because I realised I had all the necessary hardware and software to hand — i.e. I did it because I could. I'm currently under the impression that WPA with RADIUS is the most secure way to tie down a wireless LAN. It's also more convenient for me as I don't have to cook up and distribute new WPA-PSK keys every so often; I can also allow friends to use my network with a centrally-managed database and time-limited certificates, and thereby avoid having to divulge network secrets.
OK, so I'm a geek and I did it because I could.
For more information on WPA, visit the Wi-Fi Alliance's WPA official home-page at wi-fi.org, in particular their "WPA Overview" (from which much of this section was researched).
I am assuming a basic level of competence/experience with UNIX/Linux system administration (i.e., no less basic than my own despotic experience as a home sysadmin), so all the usual cp, mv business, basic TCP/IP, networking, etc. I also assume that you, like I, might not know much about FreeRADIUS or the full extent of its capabilities except that it can be used to control access to wireless networks, and wish to use it exclusively for this purpose.
I assume that you have built and/or installed:
The machine on which the RADIUS server resides started out as a stock Fedora Core 1 install. The software on it that as listed above, obtained as RPMs from the FC1 CDs, Fedora Updates, etc. You won't need a monster to run FreeRADIUS: my machine dates from 1998 and uses an 233 MHz AMD K6 CPU with 64 Mb EDO RAM and a 3.2 Gb HDD. It's no speed demon, but it manages to provide RADIUS, Samba, DNS, DHCP, IP routing/firewalling and printing services to a small bevy (of order 10) clients; you may need to scale specification in accordance with load.
My client is a Hewlett-Packard Pavilion zx5000-series notebook running Windows XP SP1 with a Broadcom 54g MaxPerformance 802.11g wireless ethernet adapter. In contrast, this has a 2.8 GHz Pentium 4 CPU with 512 Mb RAM, and still doesn't even know it's born.
I use a U.S. Robotics SureConnect 9106 ADSL Wireless Gateway as a AP. It turns out that this is actually three separate devices rolled into one. Firstly, the DSL modem; secondly, an Ethernet switch. Finally, there is a computer in its own right in the unit running BusyBox Linux 0.60.4 (2.4 series kernel), complete with tools like IPTables for firewalling, etc. This computer has two physical network interfaces, eth0, hard-wired onto the switch, and wl0, the wireless interface. A bridge device br0 sits across these two, facilitating wireless access.
My RADIUS authentication server also acts as the local DNS server and DHCP server. It has two Ethernet cards in it: eth0 is connected to the wired network, and eth1 goes into the back of the AP, both on different Class C subnets. The machine has a number of IPTables rules configured to negotiate traffic between these two subnets.
OK, here's what we'll do get our WPA Authentication working:
Here, we create and install the digital certificates used to authenticate clients on the wireless network.
In Version 2 of the server, the certificate creation scripts are located in raddb/certs/. The README file in that directory describes how to create temporary certs for testing, and how to replace those certs with real ones.
Copy the files ca.der and p12/client-name.p12 to the XP box.
First, install the root certificate to establish ourselves as an authority.
The certficates are stored in the raddb/certs/ directory. We suggest leaving them there.
See also http://deployingradius.com. That web page contains a simple series of steps that guide you through certificate creation.
You'll need to create some files and know some parameters before proceeding to configure FreeRADIUS.
The TLS element of FreeRADIUS's EAP module (the bit that does the real authentication, EAP itself is just a wrapper) requires two files with random data: /etc/wireless-auth/DH and /etc/wireless-auth/random. Any random data will do for this, and I use the dns-keygen program.
In Version 2, the scripts in the raddb/certs/ directory do this for you.
You will need to know the password for the server's private key. This was established in §3.2, where you either passed the password to the scripts as arguments or it was found or generated and stored in pass/server-name.pass.
In addition, you will need a shared secret known only to the RADIUS server and the AP allowing the latter to identify itself to the former. This can be up to 31 characters long and anything you like, but obviously the longer and crazier the better. So I used:
$ '''/usr/sbin/dnskeygen | head -c 31'''
The following scheme assumes you will be using FreeRADIUS exclusively for WPA authentication, and as such it's pretty minimal (FreeRADIUS gurus in all likelihood won't be reading this HOWTO). I arrived at it by taking the advice in McKay's HOWTO, and then deleting bits until it broke FreeRADIUS.
You will need to adjust the following files in /etc/raddb/ (or wherever your FreeRADIUS is configured to search for its config files):
Please note that there are several settings in this file you will have to enter in accordance with your local network.
In Version 2, the default configuration works with EAP. The only file you may need to edit is raddb/eap.conf, to update the password to the private keys. If you have put the certificates in a non-standard location, the filenames need to be updated, too.
See the "tls" subsection of eap.conf. All of the filenames, directories, and certificate passwords are located there.
Here you will need the shared secret mentioned in §§4.1.2. Also, try looking in the FreeRADIUS README file to see if there is a known NAS type for your AP. If it's not listed, try a NAS type of other, or keep trying different ones to see which works best (I find the USR 9106 seems to be OK with either other or tc).
Listing 4.2 - /etc/raddb/clients.conf
# clients.conf
# Network access points that authenticate through RADIUS specified here.
#
# IMPORTANT: THIS FILE CONTAINS SECRETS.
# This file should have -rw-r----- root:radiusd permissions.
# The wireless access point
client "(the AP's IP address)" {
secret = (RADIUS shared secret)
shortname = (a name for logging, etc.)
nastype = (your AP's NAS type; if unknown, try "other")
}
Simply add a user with a "known good' password to the "users" file. The server will use that to authenticate the user.
Note that setting Auth-Type is nearly always wrong.
Listing 4.3 - /etc/raddb/users
# users # a sample user and password username Cleartext-Password := "password"
If you are confident in this configuration, you can start the radiusd service as normal:
# '''/sbin/service radiusd start'''
If not, or this fails, invoke radiusd directly with the debugging options enabled to see what's going on:
# '''/usr/sbin/radiusd -X -A'''
This is perhaps the easiest step, but because APs vary in their configuration, the one I can talk on the least. However, most APs I've seen claim to have a web-based interface for configuration, and I assume you've accessed yours on a number of occasions when installing the device or bored. Here I'll try and describe things in terms as broad as possible.
This section assumes that you have:
Note Hotfix Q815485 does not provide WPA support and wireless encryption through TKIP and AES. As far as I understand, this provides the mechanisms for Windows XP to configure and manage such features (as opposed to manufacturer-specific utilities). You'll still need WPA support from your wireless hardware drivers.
As an example of this, I normally use a built-in Broadcom 54g MaxPerformance 802.11g with my notebook. The drivers for this provide WPA support with WEP, TKIP and AES encryption, and this can be configured either with the standard Windows XP property boxes, or through Broadcom's own utility.
The configuration of a WPA-authenticated connection can normally be carried out in in two ways. Firstly, many wireless adapter manufacturers provide utilities to manage wireless connections on their hardware. As this method depends on exactly what card one is using, it is not covered here; furthermore, I guess that those who plan on taking this route will probably not need to read this section!
The second route is to let Windows XP manage the authentication. This I can describe.
That's it!
Start radiusd directly with the debugging options, as per §§4.3.2. When setting up FreeRADIUS, I found I made the following common errors:
You've done all the steps above, and after about five minutes of waiting, Windows XP has popped up a little bubble (or put a flag in the "Network Connections" pseudo-folder) saying "Cannot log onto the network" (or "Authentication failed"). Maybe, if you're using DHCP, it's even gone ahead with that crazy "Zero Configuration" business.
First, try setting up a "dummy account" to test authentication. Add the following group to /etc/raddb/clients.conf:
Listing 7.1 - Added to /etc/raddb/users
Listing 7.2 - Added to /etc/raddb/users
$ '''radtest test test localhost 0 test-secret'''
Amongst the reams of RADIUSspeak produced, you should see a message informing you that an Accept-Accept message has been returned. If not, go through the configuration files again. Some things that could go wrong include:
Still not working? Take a look at the client. Windows XP clearly wasn't designed with the dollar-prompt-and-dot-conf type in mind — things break, and you're lucky if you get an error message telling you even vaguely what has gone wrong. Try:
Easily. Simply configure the additional APs as described herein, and add corresponding blocks for their IP addresses in the FreeRADIUS clients.conf file. In the interest of security, I advise you use a different shared secret for each.
Yes. In the properties box for a given wireless network in Windows XP, you can choose from Open, Shared, WPA and WPA Pre-Shared Key. Provided you choose some from of encryption, you will be able to use 802.1x authentication in conjunction with it. As far as I have played with this, no adjustments need to be made with RADIUS, but you might need to adjust your AP's encryption settings and tell it to use 802.1x.
Check the following:
If this is of no help, you could try using something other than WPA in the meantime (see above).
Last edited by Chad Furman (shadesoflight), 2014-07-16 00:36:33
Sponsored by Network RADIUS 