Wireless Security and the Open1X Projectby Matthew Gast
Editor’s note -- Open1X is an open-source project focusing on network security. The wireless adoption of this technology is referred to as 802.1X. In this interview, Matthew Gast travels to the University of Utah to talk to Chris Hessing and Terry Simons, who are intent on bringing standards-based wireless security to Linux, Mac OS X, and Windows clients.
Earlier this year, I volunteered to be a part of the Interop Labs LAN Access Security technology initiative. We tested interoperability of 802.1X-based systems by collecting the major 802.1X supplicants (client software) and authentication servers, running a test plan, and seeing what happened. In addition to the commercial products from the usual suspects, we made an effort to use as much open-source software as possible. On the client side, the major open-source project is Open1X, and we were fortunate to have two developers, Chris Hessing and Terry Simons, in attendance at the staging event and show.
Sadly, volunteering at the Interop Labs does not pay any bills, which is why all of us have day jobs. For food, shelter, and the electronic toys that make life worthwhile, Chris and Terry work in the networking group at the Marriott Library at the University of Utah, one of the earliest adopters of the cutting-edge wireless security standards based on 802.1X. Most users of 802.11 have benefited from their work, either directly or indirectly. When working with 802.1X, I've found their database of card compatibility to be an invaluable reference.
I recently had the opportunity to sit down with them at their offices at the library, where I asked questions about their network, the state of the Open1X project, and the future of wireless networking, all the while typing furiously to keep up with the rapid-fire answers.
Matthew Gast: How many people use the library's wireless network?
Terry Simons: We had 2,500 or 3,000 unique users on the wireless LAN last semester. We authenticate users with 802.1X, and use a RADIUS mesh to work with any user account anywhere on campus. We don't maintain most of the user accounts that are used in the library--they're stored on other servers across campus.
At the start of every semester, there's a rush of people who come for help in getting set up. Last semester, 300 people came for help in the first two weeks of the semester, and we're expecting at least that many this semester. It looks like the rush has already started. Recently, we had 15 people at the desk downstairs trying to get set up, and classes have not started yet!
Matthew Gast: (laughs) Is this why parking was so bad this morning?
Chris Hessing: We wouldn't have expected so many people before the first day of classes. I'm sure some of them came to get set up on the wireless network, but they probably were taking care of other business as well.
Matthew Gast: Why did you choose to use 802.1X so early? You were putting systems in production when many people derided it as "security by the same people who brought you WEP, so it can't be that good." That was the predominant feeling on the Slashdot thread last year. [Note: Terry posted to the comments following the story as galimore.]
Chris Hessing: We'd been involved in wireless before any start-up companies were trying to address the problems of "wireless security." The first wave of companies all suffered from the same problem: none of them could provide encryption on the link. The authentication might be done through an encrypted web page, but after that, there was no additional security provided for the connection itself. Our campus wireless policy had a mandate to use encryption on wireless links, so wte couldn't use any of these products. When 802.1X finally began shipping, it was the best way to provide both the encryption required by our policy and the authentication we wanted to have.
We were on board with 802.1X very early, and everything has evolved from there. We started by getting dynamic WEP running, and supporting it on the common platforms our users have: Mac OS, Windows, and Linux. Right now, we're working on getting WPA hammered out so that we can move to TKIP across the board. Eventually, we'd like to move to AES-based encryption with 802.11i.
Matthew Gast: 802.1X-based dynamic keying isn't the only way to encrypt traffic over a network. Did you consider using other forms of encryption on the wireless LAN, such as a VPN?
Chris Hessing: We did, but it was cost-prohibitive. We have 30,000 students on campus, and over 10,000 staff and faculty. We looked at purchasing a VPN system, but getting something with capabilities to serve that size user population was far too expensive.
Terry Simons: With a VPN, client software is still required, so we still have to support client configuration. You also can't do a VPN inside a VPN. We're a commuter campus, and many students need to use VPNs to off-site locations. We needed an encryption protocol that didn't limit functionality to the students.
We were also concerned about scalability of the network in the future. Centralized encryption has a performance limit. Every AP has its own encryption engine, though, so we decided to use the encryption hardware we already own.
Matthew Gast: The major advantage of 802.1X is that it's based on EAP, the Extensible Authentication Protocol. That E (for extensibility) is both a blessing and a curse, since there are several authentication protocols that you can choose. How did you select an authentication protocol?
Chris Hessing: We use TTLS, with PAP as the inner authentication method. As a security measure, our user accounts are stored in Kerberos, which encrypts user passwords on the server. Kerberos allows you to give it a user name and unencrypted password for validation, but it does not store the password in a way that the unencrypted form can be recovered. We needed an EAP method worked with a user name and an unencrypted password. Kerberos can validate a password, but it doesn't work with challenge/response systems like PEAP.
[Interviewer's note: PEAP actually can work with an unencrypted authentication string, by using EAP-GTC as the inner method. However, PEAP/EAP-GTC is not widely supported by clients, and it is not implemented by the supplicant built in to Windows.]
Matthew Gast: If you're required to store passwords encrypted, why couldn't you store the MD4 hash of the user password? That form would be compatible with an MS-CHAP-V2 inner authentication, and could be used with PEAP.
Chris Hessing: Well, first of all, you're assuming the RADIUS server knows what to do with an MD4 hash. I also don't consider MD4 to be encryption. More importantly, though, there are several different PEAP implementations on the client, and it's hard to come up with an option that would be well supported across all the clients, especially if there are non-Windows clients. TTLS works on all the major computing platforms, and we don't have to worry about different flavors of TTLS on the client. Plus, we're interested in working more tightly with Kerberos, and the flexibility of the TTLS inner exchange is likely to make that easier in the future.
Terry Simons: We really wanted to come at our choice of EAP method from the standpoint of "What is the best solution for the campus?" instead of "Let's use what everybody else uses."
Matthew Gast: How do you want to integrate the wireless authentication more tightly with Kerberos?
Terry Simons: We want to get the Kerberos tickets all the way back to the client. Right now, our RADIUS server just requests a ticket from the server. If it can grab a ticket from Kerberos, then you're allowed in. Pushing tickets to the client would provide more security than TTLS/PAP, which we use right now. The University of Pennsylvania is organizing a consortium of universities to work on this problem.
Matthew Gast: If you'll pardon my ignorance about Kerberos, what is the point of pushing tickets all the way back to the client? 802.1X authentication occurs at the link layer, but Kerberos tickets are bound to an IP address, right?
Chris Hessing: Yes, you're right. Our network right now requires two sign-ons: one to bring up the wireless network, and one to use any Kerberos-based services on campus. We'd like to move forward with the single-sign-on concept so that the wireless sign-on can be used for service authorization later. I attended the IETF meeting in San Diego recently to talk with other users about this and drum up interest. At the next IETF, I plan to corner the serious Kerberos geeks to start moving the idea forward.
Matthew Gast: Kerberos integration is a ways off. What changes would you like to make to the library's network in the near term? Or, to put it another way, what would you do right now in a world where there were no implementation errors because software was perfect?
Terry Simons: We're very interested in using "mixed mode" encryption where WPA and WEP are used at the same time. In that mode, every station on the network shares a dynamic WEP key to encrypt broadcast and multicast frames, but stations that are capable of using TKIP will use it for unicast frames, which provides additional security. We've found that many drivers and a few supplicants don't support mixed mode--they want to use the same keying method for both broadcast and unicast data. We're also looking for 802.11 SIP phones that support 802.1X.
Chris Hessing: Well, there's an implementation lesson: I love features, but I need to be able to turn them off!
In the longer term, I'd like to be able to work on authenticated guest access. I'd like to be able to authenticate guests of the university using their "home" credentials. With 802.1X, I can pass an authentication request from, say, a visiting faculty member, back to that person's own institution, so they can use the same password as they do in their office. That way, access is granted to a well-defined set of people and we don't have to manage user accounts for visitors. Likewise, when University of Utah community members visit other institutions, they would be able to use that university's network without any special setup.
Matthew Gast: That's a neat idea. What are the major challenges you face in pulling it off? It seems that the protocols can support this goal in a relatively straightforward manner, and that most of the hard work is going to be political, rather than technical.
Terry Simons: Yup. It has been done before, though. There's a European project called EduRoam (http://www.eduroam.nl/ in Dutch; http://www.eduroam.nl/en/index.shtml in English) that started off in the Netherlands. Several schools have built an inter-university RADIUS mesh. There are proxy relationships between RADIUS servers at the various schools, so authentication requests can be passed back to the right place. It's a reasonably trusted network. You have to apply for the right to connect to the mesh.
Chris Hessing: There's interest in extending the project over to the U.S. EduRoam is also doing some other interesting work. They are partnering with cellular providers, and they're very interested in EAP-SIM. I think that EAP-SIM is going to get very big in the next few years.
Matthew Gast: If I could switch gears a bit to the Open1X project itself, how did your involvement with the project start?
Chris Hessing: It all started about three years ago when we were thinking of doing 802.1X on campus, specifically in the library, which is our network. Naturally, we decided that we needed to understand how 1X worked, and the best way to do that was to write an implementation! The xsupplicant project had already started at the University of Maryland, so we started working with the code and sending patches. After sending patches weekly, the UMD team gave us CVS access, and a monster was born.
Terry Simons: At the same time, we were trying to make 1X the standard authentication protocol in the library. At the time, there wasn't a Mac OS X client, so we ported xsupplicant to OS X. When I was working on the OS X port, I posted to a Darwin developer list to get some help, and I received a response from Xerox PARC because they were also trying to get xsupplicant running on OS X.
Matthew Gast: What's the current status of the Mac OS X port? Is it still supported?
Terry Simons: No, it's not. Panther [Mac OS X 10.3] was released with a built-in client, and the built-in client is much easier to use. Also, the xsupplicant code has been rewritten since then to depend on a low-level frame handler native to the OS. We have the Linux frame handler written, of course, but the BSD native frame handler still needs to be written. We haven't had time to develop it.
Matthew Gast: What are the major features that you're working on right now?
Chris Hessing: We're spending most of our time writing code to implement WPA and 802.11i. The BSD frame handler is also on the short list, but we are spending more time on WPA and 802.11i. If somebody were to write the BSD frame handler, we would be more than happy to take it, though.
Matthew Gast: One of the difficulties that many organizations face when implementing 802.1X is that it is an integrated system that requires components on the client, in the AP, and also an authentication backend. How much of the integration do you see in developing a client? As a network application, how much do you depend on the OS, especially for something like WPA?
Chris Hessing: For WPA, there's two pieces. One piece allows the wireless card to associate to a WPA or 802.11i network, and that needs to happen in software below us. The driver for the card needs to support Linux wireless extensions, and the wireless extensions need to provide standard APIs for everybody to use, both drivers and applications like xsupplicant. Right now, everybody and their dog has their own way of performing the association, typically using private system calls, so there's no practical way for xsupplicant to track all the changes in every driver.
The second piece of WPA support is something that occurs within xsupplicant. We need to have visibility into the association process to provide keys for the connection. WPA uses a 4-way handshake to derive keys, and we need to get information from the association to use in the 4-way handshake.
Matthew Gast: For those thinking of running xsupplicant, what cards would you recommend they use?
Terry Simons: It's really a matter of preference. Pick a card with a native Linux driver that you like. Intel has sponsored the project creating drivers for the Intel Pro cards, and they're working with us on a test suite for 802.1X. The Intel-sponsored driver is a good driver to use with Centrino chipsets, which are becoming increasingly popular on campus. Atheros is supporting the madwifi driver, which can be used with most of the a/b+g cards on the market.
[Interviewer's note: At one point during the conversation when we were walking through the building, somebody stopped Terry in the hallway to report that the Intel Pro 2200 works with the Intel driver.]
Chris Hessing: The HostAP driver is probably the most stable driver for use with 802.1X, and it is also usually the first driver to implement new features. HostAP already has driver support for WPA and 802.11i.
Terry Simons: I recently tested the Prism54 driver, and it worked right out of the box. There are a few common driver issues that we normally see, like the re-key problem, but the Prism54 driver didn't have any of them.
Matthew Gast: Could you elaborate on the re-key problem?
Terry Simons: Many Linux drivers will reset the card when you configure WEP keys. If you are running dynamic WEP, that's a problem. xsupplicant will install keys, which causes the card to reset, which causes 802.1X to run again, which derives keys for xsupplicant to install, which causes the card to reset…
Most drivers have this problem, and we need to create patches for the driver to take out the reset when keys are installed. We distributed a patch to the orinoco_cs driver with xsupplicant to work around this problem. The latest Cisco driver distributed with the 2.6.8 kernel has this problem as well. It passes frames to xsupplicant correctly, but it resets when keys are configured.
Chris Hessing: The latest Hermes driver now incorporates the re-key patch. I've personally patched three or four drivers. Generally, it's not too hard, and it's obvious where you need to fix it. Although a USB device I've been working with has been very hard to fix, and I still haven't been able to make it work.
Matthew Gast: Open source software can serve a valuable role as a "standards cop." In the past, I wrote a technical comparison of TTLS and PEAP. I did so by reading the standards documents and comparing them, but I don't write much code. Can you compare the implementation of the two protocols?
Chris Hessing: Well, they're very similar protocols. In fact, the first phase of both protocols, where the TLS tunnel is set up, is nearly identical between the two protocols. The only difference in the TLS tunnel establishment is that Microsoft uses a couple of reserved bits to indicate the version of PEAP in use. They took two bits in the TLS header to indicate the version of PEAP. When we get to version four, we'll be in trouble because there are only two bits!
Once you get to the second phase, where the TLS tunnel is used to perform the user authentication, all bets are off. TTLS packages up its inner authentication as a stream of RADIUS attribute-value pairs (AVPs) and passes them through the tunnel. PEAP uses the tunnel and starts another EAP exchange inside the tunnel. Part of the benefit of using AVPs is that TTLS tends to use fewer round-trips to authenticate, and the connection comes up faster.
PEAP allows you to use any EAP type, but I should note that "any" is not always "any." For example, in PEAP version zero, it's hard to distinguish whether you are getting an EAP message or if you are getting a request to do a specific type of EAP authentication. EAP-MD5 has an EAP method value of 4, but the EAP-Failure packet has a type code of four as well. When you get an EAP-MD5 challenge, it might be interpreted as a failure by the supplicant.
Matthew Gast: Can you make a qualitative comparison of the implementation effort for both TTLS and PEAP?
Chris Hessing: Microsoft's supplicant doesn't follow any published draft. In that respect, TTLS was much easier to implement. The draft was well-written, straightforward, and easy to follow.
Matthew Gast: One claim I've heard is that the PEAP state machine is easier to implement because it uses the EAP state machine for its inner authentication. I've even heard the claim that because it's less complex, it should be more secure. Can you shed some light on the argument for those of us who don't write code?
Chris Hessing: The argument is that since you already wrote the EAP state machine to handle the first phase, then you can just call into the same code a second time for the second phase. In practice, that's easier said than done. Microsoft simplified their client by locking it down to a particular EAP method, possibly to reduce the complexity of the state engine. If you select PEAP, you'll run PEAP. The software isn't capable of negotiating an EAP type by using NAKs like other clients. If you compare it to TTLS, where there's a relatively simple exchange, there just isn't a complex inner state machine, so it's a bit of a spurious argument.
Matthew Gast: Whether you call it "open source" or "free" software, there's still a cost to develop it. I value your effort, and I'm sure that many other people do as well. How can we show it? What resources have been helpful to you this far?
Chris Hessing: Obviously, we've spent a lot of time reading RFCs and the IEEE pages. A few organizations have helped out with patches and donations. Open System Consultants, the developers of Radiator, have submitted a large number of patches, and have been the single largest help. The Internet Foundation Austria (http://www.nic.at/de/company/internetaustria/ia_internetaustria.asp in German; http://www.nic.at/en/company/internetaustria/ia_internetaustria.asp in English) has provided financial assistance and equipment to help develop our implementations of EAP-SIM and EAP-AKA. 3Com and HP have also donated equipment to the project.
Terry Simons: Donations from vendors are always useful and welcome. We can never know what cards will be popular with our users, so we like to have one of everything. We come close, but there are always gaps. When vendors send us cards, we're always happy to test cards and help them work on Linux support.
More than cards, though, we need native Linux drivers. The DriverLoader software package is supposed to allow an NDIS driver from Windows to run under Linux. We've been unable to get it running with xsupplicant, though. Emulation is generally problematic, so we strongly prefer to have a driver with source that we can debug, especially since xsupplicant needs to work closely with the driver. Our experience is that the Linux drivers supported by the chipset manufacturers are more stable and useful than other drivers. We would be more than happy to work with manufacturers to shake bugs out of Linux drivers.
Matthew Gast: As an open source project, your code is probably used quite widely. What are a couple of the more interesting applications that your code has been used in?
Terry Simons: Toby Collett from the University of Auckland in New Zealand is involved in a robotics research group. The robots are controlled over 802.11, and they're using 802.1X to authenticate control connections to robots.
Chris Hessing (laughing): We'd actually talked about robotics ourselves. We wanted to get single-board computers, put them in Lego Mindstorms, and have battlebots in the office!
Terry Simons: Xerox PARC was interested in Open1X because they're working on a project that requires a two-step authentication. They have custom-built APs that require you to get within a line of sight of the AP to authenticate over infrared before you're allowed to make a connection over the radio network. There was also a company that was building a tool that would do 802.1X performance benchmarking, like SmartBits for 802.1X, but I think they're no longer with us.
Chris Hessing: We've used much of the same code in the wEAP project. wEAP is a series of Windows EAP plug in modules. We've released Windows EAP modules that implement EAP-SIM and EAP-AKA. I'm sure that the code is also being used in a number of projects we don't know about, too.
Matthew Gast is the director of product management at Aerohive Networks responsible for the software that powers Aerohive's networking devices.
Return to MacDevCenter.com.