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.