Menu
Is 802.1X authentication easy?

Is 802.1X authentication easy?

Using the 802.1X protocol to secure wired and wireless networks is supposed to be easy. So we grabbed some hardware and servers from our test lab to see how hard it would be in the real world. The challenge: Could we set up 802.1X authentication in one hour or less?

Before diving into any 802.1X project, start by answering the question, "Where is my user-authentication database stored?" You can't design any aspect of 802.1X until you've figured out how you're going to authenticate users. If you're going to use Secure Computing's SafeWord or RSA Security's SecurID or any other one-time password system, you'll need to find a RADIUS server that can talk to that authentication database. In our case, we decided to use our Windows 2000 server's built-in user database.

Start the odyssey

Once you know where your user data is stored, you can pick an authentication method. 802.1X is a framework that allows lots of ways to actually handle the authentication. If you use usernames and passwords, Protected Extensible Authentication Protocol (PEAP) and Tunneled Transport Layer Security (TTLS) are the two methods to care about. While similar, there's one huge difference: TTLS can work with one-way encrypted passwords, while PEAP cannot. So for example, if your usernames and passwords are locked up in a Unix-style database, you have to use TTLS. With Windows, passwords are not so tightly secured, and challenge-response authentication methods can be used, which means either PEAP or TTLS would work.

Although TTLS is more flexible, PEAP has one significant benefit: It's built into Windows XP (and is available as a Microsoft update to Win 2000). Because we wanted to get up and running as quickly as possible, we decided to use PEAP as an authentication method, with MS-CHAPv2 (Challenge Handshake Authentication Protocol) inside to carry the actual username and passwords.

With those two decisions made, life suddenly gets a lot easier. The next step is to find a RADIUS server that will talk to your 802.1X devices on one side and to your authentication database on the other. Although Microsoft includes a free one with Win 2000 server, called Internet Authentication Server (IAS), it only runs in a Windows domain environment.

Our server was stand-alone and converting it to be compatible with Microsoft's IAS wasn't going to happen in one hour. For that reason, we elected to use Funk Software Inc.'s Odyssey RADIUS server. Although Funk is known for industrial strength RADIUS software, Odyssey is a simpler product that does exactly what we needed and not more. Plus, with a free trial download at www.funk.com, it fit very nicely into our time requirement.

(Stopwatch: 8 minutes, including reboot)

Calculate the RADIUS

With wireless authentication, it's critical that both ends of the connection authenticate themselves. It's not a very good idea to give your username and password to just any access point that happens to be around. With PEAP and TTLS EAP authentication methods, the RADIUS server identifies itself using a digital certificate. Normally, getting a digital certificate is a long process, but we had a secret: RegisterFly. This little-known registrar sells certificates at a great price (US$16 per year), but most importantly, it will issue them immediately. You have to prove that you own the domain name in the certificate, but total elapsed time between hitting their Web site at www.registerfly.com and getting a certificate for our server was just under 10 minutes. If you don't care about having a trusted root sign your certificates, you can use CAcert (www.cacert.org), which is just as fast and free -- although CAcert doesn't have their certificate built into Windows. Because we wanted to go quickly and not worry about how we were going to get the CAcert server certificate to our clients, we opted to spend the $16.

One touchy part of getting the certificate for a RADIUS server to work with 802.1X is having all of the right attributes in the certificate. We used OpenSSL to generate the certificate request and get everything right. If you have to install OpenSSL just to request the certificate, that'll add to your time, but if you've got any Mac or Linux systems around, they'll have OpenSSL pre-installed and ready to go. Another option, if you have Windows Internet Information Server Web Server running, is to use the built-in wizard in the IIS management tool. A certificate that will work for IIS also should work fine for a RADIUS server because Microsoft stuffs the necessary Extended Key Usage attributes into its certificate request. (Stopwatch: 23 minutes)

With certificate in hand, you have to configure your RADIUS server. Although it won't all be as easy as Odyssey, the information you have to put in is fairly simple: the IP addresses of the access points, what authentication methods are allowed and what security policy to enforce. In the case of Odyssey, we turned on PEAP authentication with MS-CHAPv2, and that was about it. (Stopwatch: 28 minutes)

Determine the proximity

With the server side done, your next task is to get the wireless access point ready for 802.1X. It's possible to use "pure" 802.1X authentication, which was the earliest implementation of 802.1X over wireless. With pure 802.1X, you use 802.1X to authenticate, but then plain old Wired Equivalent Privacy for encryption. However, access points that support 802.1X will also support Wi-Fi Protected Access (WPAv1). A few also will support 802.11i, the IEEE final standard for wireless security, also called WPAv2.

Because WPAv1 is commonly available and considered very secure, your best bet is to dive right into WPAv1 with 802.1X authentication.

Our next step was making our access point 802.1X-aware and building a secure channel between the access point and the RADIUS server. We pulled an access point off the shelf, a Proxim AP-4000 802.11a/b/g device that received high praise in Network World's wireless security test in 2004 (www.nwfusion.com, DocFinder: 6533). With the AP-4000, adding 802.1X authentication requires going to two screens to fill out information. On one we put in our RADIUS server and the shared secret that authenticates the access points to the RADIUS server. If your access point does not have a fairly secure channel to the RADIUS server (for example, if they're not on the same LAN switch), it's important to pick a nice long shared secret of 20 characters or more.

On the second screen of the AP-4000, we enabled WPA with 802.1X authentication and rebooted the access point. Because the access point doesn't participate actively in the 802.1X authentication, you don't have to configure in all of the miscellaneous 802.1X parameters, such as authentication method, when you set up the access point. (Stopwatch: 33 minutes)

Turn on the Inspiron

Because XP already has WPA and 802.1X built in for wireless security, we didn't have to install any software on the Windows laptop. However, we had to wade through the XP client configuration menus. These are attached to the wireless adapter. Our test laptop, a Dell Inspiron with a built-in wireless card, saw the AP-4000 but didn't know how to connect. By default, Windows will want to use a digital certificate to authenticate. That's good security, but didn't fit into our deployment plans. Next, in Windows preferences, is using the credentials you used to log on to XP -- again, not what we wanted. Setting up 802.1X authentication took clicking on a few property pages. (Stopwatch: 38 minutes)

One for the Aegis

If you use the built-in Windows client, you'll also have to create instructions for users to add the wireless network to their list of networks. We didn't count that in our time, but our quick cheat sheet would add up to about two pages of instructions. Fortunately, it's a one-time effort, and if you have users already using the Windows wireless client, you've already done about half of the work in getting them set up. For a more elegant solution, you can use a third-party 802.1X and WPA client that lets you easily pre-load profiles.

Most wireless cards include 802.1X capability in their built-in tools, typically using the Meetinghouse Communications Aegis 802.1X client and a vendor-provided configuration GUI. Cisco Systems is one of the few that don't use Meetinghouse, but it does provide its own 802.1X client as part of the Cisco wireless driver kit. The problem with using a third-party client is that not everyone will have the same wireless card, and every vendor makes up its own GUI to drive the 802.1X supplicant configuration. As laptops with built-in wireless approach the 100 percent mark, you might find that the slightly greater complexity of the built-in Windows client balances out the necessity to maintain instructions for every brand of wireless card anyone has ever bought.

With RADIUS server, access point and client configured, it's time for the smoke test: Will it work? In our case, the answer was a resounding "no." We wasted 14 minutes looking for ways to increase the debugging on the built-in Windows client. Fortunately, looking at the logs on the RADIUS server solved our problem -- we forgot to set up a list of Windows groups that were allowed to log on. With a few clicks, we were finally up and running with XP. Without disappointment, you cannot appreciate victory -- and we were victorious with time to spare. (Stopwatch: 52 minutes)

Tweaks of the trade

Flush with success, we discovered that we had cheated a little bit. It turns out that the Microsoft 802.1X client wasn't fully configured. As part of our debugging, we disabled certificate verification, a serious no-no in any 802.1X environment. When we turned that feature back on, the client behaved erratically. The laptop we tested had Dell's own wireless configuration tool in it. We were able to use the Dell-provided version of the Meetinghouse Aegis client to connect with certificate validation. After finishing the last stage of our speed implementation of 802.1X, we went back and tested further with the Microsoft built-in client. Eventually, it started working but the behavior wasn't 100 percent predictable and might prove frustrating for some users. You'll have to make your own decision on the trade-off between the convenience of one client for all Windows users, whether wireless or wired, vs. the more sophisticated, but every-company-is-different user interfaces that each wireless card vendor provides. (Stopwatch: 56 minutes)

A bite of the Apple

With 4 minutes to spare, you might want to tackle Mac clients. Apple Computer Inc. included 802.1X capability in the base operating system. The Apple client is even easier to use than Windows. Selecting our test 802.1X network out of the list of wireless networks brought up a dialog box asking for a username and password. The OS X server identified our test wireless network as "WPA Enterprise," which is one of the marketing terms for the combination of WPA and 802.1X. The OS X system then showed us the digital certificate we had received for the RADIUS server and asked us to approve it. That's a critical step, because if you don't know what you're connecting to, you're just handing your username and password over. A few seconds later, we were merrily surfing away - a little tired, a little wired and very secure. (Stopwatch: 59 minutes)

Switching into overtime

If you've got 5 more minutes, you can also turn on wired 802.1X on LAN switches from all major vendors. In a wired environment, 802.1X doesn't give you encryption, but it does give strong authentication. With 802.1X in a wired world, the switch is configured much like an access point. It needs to know where the RADIUS server is and a shared secret, and that's about it. Do it right and champagne falls from the heavens, doors open and velvet ropes will part. Plus you get a more secure wired LAN.

We started with an HP 2524 switch already configured into our network. With our Hewlett-Packard switch, enabling 802.1X took five commands, because we wanted the simple case. Many wired switch vendors have a variety of scenarios for different virtual LANs, depending on whether a port is unauthenticated, successfully authenticated or fails authentication. We resisted this complication and got 802.1X up very quickly.

On the Windows laptop, we again used Microsoft's built-in 802.1X supplicant. This time, we didn't have the option of using the add-on client provided by Dell Inc. because the Dell client only worked with wireless cards. Microsoft's client can handle either case using the exact same interface.

In the world of Macintosh, 802.1X on a wired LAN requires on additional step. We launched a program called Internet Connect that is used to define 802.1X connections and Point-to-Point Tunneling Protocol, IPSec and Layer 2Tunneling Protocol VPNs. With Internet Connect, we defined an 802.1X connection, selecting the Ethernet port and gave our username and password. Once that's in place, all we had to do is click "Connect" to successfully authenticate to the HP switch.


Follow Us

Join the newsletter!

Error: Please check your email address.
Show Comments