In the complex world of wireless LAN security protocols, two major open-source development projects are serving as "standards cops": xsupplicant and wpa_supplicant. I first met Chris Hessing, the lead developer of xsupplicant, at Interop in 2003. Since then, he has continued to develop xsupplicant in his spare time away from his day job as the wireless network architect at the University of Utah in Salt Lake City. I recently had a chance to talk with Chris by phone about xsupplicant, his views on wireless security protocols and what he's trying to do on the one of the largest decentralized secure wireless networks in existence.

Linux Journal: Which standards bodies and meetings do you attend?

Chris Hessig: I regularly attend Interop to participate in the Interop Labs, which is the closest I can get to a plugfest. Many of the industry plugfests don't always know how to contact open-source projects, so the best opportunity I have to shake bugs out of xsupplicant is the hot stage event that happens a month before the show.

I attended IETF 60 in San Diego last fall, where I ran the wireless network with Chris Elliott of Cisco.

LJ: How did you design the security of the network at the IETF? Many engineers who attend the IETF are security experts and probably wanted encryption on the radio link.

CH: We tried to design an encrypted network that allowed anonymous access, which isn't something that the currently implemented standards really were designed for. We supported both Tunneled TLS [TTLS, a Funk proposal for authentication] and Protected EAP [PEAP, a Microsoft/Cisco proposal for authentication], though it was much easier with TTLS.

In TTLS, the protocol has a pretty clean design. We configured the RADIUS server to accept any user name and password, and we sent back a success message to allow access to the network. With PEAP, it was not possible because of the design of the protocol. PEAP commonly is used with a Microsoft CHAP authentication inside the TLS tunnel, and the design of the Microsoft CHAP protocol requires sharing a secret between both ends. We encouraged Windows users to use the SecureW2 plug-in to do TTLS, but we also set up a well-known common account and password for people who just wanted to do PEAP. In effect, it was anonymous, but it just wasn't as slick.

LJ: How important is the standards work to your ongoing development?

CH: For xsupplicant, it's very important, especially in the IETF. Most of the interesting work in wireless security is things like new EAP types and solving the compound binding problem, and that has a strong influence on the direction my code takes. The IEEE is much less important--most of the interesting work is in the IETF.

For my day job at the university, the IETF is also important. We're very interested in pushing authentication throughout the network, and new EAP types will provide a way to use user names and passwords and come up with encryption keys without TLS. Most of our users are comfortable with user names and passwords, but it can be hard for many of them to understand how a "magical" certificate file gives you access.

There are two EAP methods that work to allow network access without TLS. One was designed by Florent Bersani at France Telecom. He had friends visiting and wanted to allow them on his wireless LAN, but he didn't want to do anything beyond a user name and password. As a result, he developed "EAP-PSK," which I should point out is different from WPA-PSK. At the same time, T. Charles Clancy was trying to achieve the same thing at the University of Maryland. His proposed protocol is EAP-PAX.

LJ: When you say that you want to push authentication throughout the network, how far does that go? Will every port on the university campus demand credentials?

CH: Yup. With every wireless deployment on campus, we push 802.1X out farther. It's clearly the direction we're heading. The downside is that somebody needs to spend time keeping on top of all the new authentication methods.

LJ: What are you hoping to address in future wireless standards?

CH: Well, I want to make sure that we address all the security problems we're not aware of yet!

I feel like the security available right now is pretty good, assuming you're running WPA2 with AES. There are some weaknesses in various EAP flavors that need to be addressed, but that's well underway for the most part. What I'd like to do--and I don't know whether we can--is to get a universal EAP type. Something that allows you to use passwords, allows the storage of passwords in secure form and doesn't lock you in to any particular authentication server.

LJ: What are the interesting problems in wireless security? There's a big drumbeat right now that everything is all worked out, so you should just go ahead and start building your network. How much do you agree with that?

CH: For the most part, I do. The problems are not in the fundamental security of the protocols. The problem is in how to deploy the protocols. There are a lot of different ways to use 802.1X, many different types of encryption that can be used and so many client platforms. Managing complexity is the biggest problem we face in wireless security today. Before we move on and continue to develop protocols, we need to fix what we've already got out there.

For compatibility reasons, the university has stayed away from WPA, and the more I get involved with WPA, the more I want to stay away from it. We've had tremendous problems because we have so many Macintoshes. The initial WPA specification allowed you to only have one crypto method for encryption for unicast frames. Apple took that to heart, and their software enforces it. If you have multiple unicast encryption types, you can't get on the network. Unfortunately, most APs in WPA mode specify multiple encryption types. We got stuck between our AP vendor and Apple. I'm hoping that WPA2 resolves this, even if it's just that WPA2 is newer and better and Apple pays better attention to it.

LJ: Although security gets most of the attention, wireless networks are changing the types of applications that you can run, too. As an example, Voice on 802.11 is becoming increasingly popular. How much are you doing with voice at your day job right now? Many of the voice phones I've seen on the market can't do strong authentication and are only capable of using manual WEP keys for security, which must not fit in well with your campus-wide secure wireless network.

CH: We're not doing too much with it yet. The lack of security has certainly slowed us down from a wireless voice perspective, but a bigger barrier is figuring out to use the flexibility that VoIP gives us. I've started playing with VoIP on 802.11 with a couple of phones that offer security, but they are still early enough in the development cycle that the code is so raw that it sometimes has trouble associating to the wireless network and getting an IP address.

LJ: How else are you pushing the boundaries of wireless LANs? What are you working on in addition to simply pushing out wireless coverage as far as possible?

CH: We're trying to build a wireless LAN to cover all of our campus outdoors. The public safety department needed a network to communicate over the entire campus and research park. They evaluated some cellular data services, as well as licensed equipment in a radio band dedicated to public safety. Both of them had very low data rates, so the public safety department asked about the 802.11 blanket we were putting over the entire campus and whether it would be possible to cover all the outdoor areas. After evaluating the alternatives, they decided against building an expensive licensed network for their exclusive use in favor of building a much higher-speed campus-wide 802.11 network, keeping the capacity they need and allowing the rest of the campus community to use it.

We have some obvious challenges with this. The campus is quite hilly--if it were flat, the network engineering would be much easier--and there are many tall buildings that lead to "concrete canyons." Plus, there are obvious challenges with being unlicensed. Several wireless ISPs have set up antennas on the mountains above campus, so we may have some coordination efforts ahead of us to ensure that we're not stomping all over one another's spectrums.

LJ: As the campus network evolves, I certainly hope you continue to find time to develop xsupplicant. In your free time, what are you working on coding right now?

CH: The framework for wireless security is pretty well set at this point, with most of the action being in EAP methods. I'd like to implement EAP-PSK, EAP-PAX and maybe EAP-FAST.

Basic implementation is only a small part of the battle, though. A lot of APs have weird idiosyncrasies that come out in testing, so I need to find as many as possible and work around them. With the number of APs on the market, just testing them is a pretty tall order. It will get harder as more cards support WPA2 under Linux, too.

After all that is done, I want to implement a little bit of eye candy. Ever since I started on this project, I've wanted something that sits in the corner of the screen and changes colors depending on whether you're authenticated. But I've been too busy developing the engine to develop GUI tools yet.

Under the hood, xsupplicant may change, too. Right now, it uses OpenSSL for cryptography. It's a very powerful library, but it's difficult to program for. It tries to be an all-purpose cryptographic bullet that works in all situations, which means that sorting through the API is challenging for developers. Because I only need basic TLS functionality, I'm thinking of moving to GNU TLS because it has a much simpler API.

LJ: As an open-source project, your code can be incorporated into all sorts of other projects. Do you have an idea of other neat places where your code is used?

CH: People don't actually talk to me all that much about how they're using the code. I usually find out when they ask questions on our mailing list, but I often have to chase down what they're doing. At least one 802.11 phone reference design uses xsupplicant, but it also incorporates Jouni Malinen's wpa_supplicant.

Although it's neat to hear about xsupplicant being used in other projects, I'm not writing the code to see it become popular. I started writing the code because it was the best way to learn how the protocols work, and I think I've certainly accomplished that goal.