Interop Labs LAN Access Security panel notes

by Matthew Gast


On Thursday, May 13, I moderated the LAN Access Security panel at Interop. On the panel, we had (in alphabetical order) Paul Congdon of Hewlett-Packard, who is also vice chair of the 802.1 working group; Geoff Horne of Infoblox, who helps customers implement large-scale network services, including authentication; Christian MacDonald of Funk, who knows everything about Funk's RADIUS servers, and almost everything about what people plug in to them; and Rodney Thayer, an independent security consultant and author of the Network World article on the iLabs. We were up on stage to answer questions from conference attendees on the iLabs. Although the panel is free and open to the public, not everybody can make the trip to Las Vegas. For the benefit of those who couldn't make it (or chose not to visit), here's a rough summary of what we discussed.





Question: What are the relative merits of Protected EAP (PEAP) and Tunneled TLS (TTLS)?


  • The protocols themselves are very similar from an architectural perspective. Both use a TLS-encrypted channel to secure older authentication methods. Network-to-user authentication is handled with a server certificate, and the user-to-network authentication is done with a "legacy authentication method" that may include password-based authentication. The first (network-to-user) stage is sometimes referred to as the "outer" authentication because it establishes the tunnel used to protect the "inner" (user-to-network) authentication in the second stage.


  • Sometimes, one or the other may fit better into your network, based on the type of user database that you have. PEAP requires that your inner authentication method be defined as an EAP method, while TTLS imposes no such requirement. In practice, PEAP is useful for authenticating against Active Directories using EAP-MS-CHAP-V2 as the inner authentication method, while TTLS is useful for authenticating against reusable (plaintext) password databases. Many corporations use Windows and Active Directory, and PEAP is a natural choice. Reusable passwords are often stored in an LDAP directory; as a result, TTLS is often favored by universities.


  • The two methods differ in implementation complexity. Chris Hessing, the lead developer of xsupplicant, was part of the iLabs LAN Access Security team this year. He has written code for both TTLS and PEAP, and found that TTLS was much easier to implement. I had hoped for him to be on the panel to speak in more detail, but he was unable to do so.


  • Recent drafts of PEAP are adding support for features that make it more flexible. The current draft has support for Type/Length/Value (TLV) attributes, which can provide much more extensibility to the protocol. The use of TLV encoding also gives PEAP the ability to pass arbitrary data around, which has been part of TTLS from the beginning.





Question: Is cleartext password authentication a good idea or a bad idea?

First, a bit of background: There are many ways to use passwords to authenticate users. The simplest method is to submit a user name and a password to an authentication server, and wait for its response. More complex methods may perform challenge-response exchanges based on the password. In the former case, the password from the user is submitted to the authentication server in the clear (or using reversible encryption, so the authentication server can recover the password submitted for validation). Cleartext authentication is often used with passwords that are stored as one-way hashes such as MD5 or SHA-1. When the password is received, it is hashed and compared to the stored value. If the hashes match, the password was almost certainly correct and access can be granted. This type of authentication is typically used with LDAP directories, which often can only validate passwords given to them in cleartext.



  • As a general principle, it's better to authenticate, even weakly, than to leave connections unauthenticated, provided that the weak authentication cannot be spoofed. Wireless network authentication protocols were designed to protect older weaker authentication methods (including reusable passwords) with strong encryption to dramatically reduce the risk. Cleartext authentication, secured by TLS, is definitely better than giving up.


  • Cleartext authentication is not as bad an idea as it might sound at first glance. By using TTLS/PAP, the cleartext authentication is protected by a TLS tunnel and is not subject to eavesdropping. The key is to ensure that the password is protected all the way from the client to the server. On the front end, the password is secured by the TLS tunnel from the supplicant to the TTLS server. The cleartext password is recovered, and the back-end request with, say an LDAP client, can be secured by a second SSL session.


  • As another general principle, it is also good not to redefine user databases specifically for wireless networks. Depending on what the existing user database supports, you may need to do cleartext authentication. Many LDAP directories, for example, do not support anything other than cleartext authentication. (Though, it should be noted, every widely-used directory server implementation can secure the cleartext authentication requests inside of an SSL tunnel.) As a result, most directories need to be front-ended by TTLS/PAP.





Question: How can you choose an appropriate EAP method?



  • This is one of the major challenges facing the industry. There are a number of EAP methods, and there is not a great deal of guidance for users. There is very little written guidance for users on the how the plethora of methods differ and how to select an appropriate protocol.


  • Paul Congdon of HP stated that this was a usability problem, and that the Wi-Fi Alliance could address it through the WPA certification program. Rather than the free-for-all it is now, WPA certification could require certain EAP methods (as well as inner authentication methods) to be implemented before granting certification to products.


  • (This was not mentioned on the panel, but I include it for completeness.) During the LAN Access Security class, I included a reference to an Internet-Draft that reviews shared-secret authentication EAP methods written by Florent Bersani at France Telecom. After the show, I found an Internet-Draft that reviewed requirements for EAP methods for use on 802.11 networks, written by Jesse Walker, of "Unsafe at Any Key Length Fame."





Question: What is the high-level summary of the interoperability test results?



  • Interoperability is generally quite good. We had several RADIUS servers, more than a dozen APs, and several supplicants. We tested over 150 (supplicant, AP, authentication server) tuples and found that most of them worked flawlessly on the first try.


  • Most of our testing was with WPA, with some exceptions. xsupplicant does not yet support WPA because it depends on lower-level primitive operations to set link-layer encryption keys dynamically. Those operations are in place for WEP, but not for WPA. Additionally, most of the testing used TKIP, the RC4-based replacement for dynamic WEP. Only a few products supported CCMP, the new AES-based privacy algorithm. We did have a demonstration in the booth, but we were not able to test enough devices with support for CCMP to offer opinions on its interoperability.


  • The major interoperability problem we had was with VLAN assignment. At the 2003 iLabs, there were only two products that could dynamically assign users to VLANs. There was no standard for how to assign users to VLANs, though RFC 3580 had almost emerged from the IETF as a final document. (It was on draft 26, if my memory is correct.) This year, nearly every access point supported some form of dynamic VLAN assignment, though many did not follow the standard. RFC 3580 says that a user may be assigned to a VLAN by taking the ASCII representation of the VLAN tag number and passing that to the access point in the Tunnel-Private-Group-ID attribute. Some vendors required a vendor-specific attribute rather than Tunnel-Private-Group-ID, and many vendors used the Tunnel-Private-Group-ID in the wrong way. By far, the most common incorrect use was to expect the VLAN number, but as an integer rather than a string. (To deal with this common incorrect use, I wrote code for Radiator.)





Question: What is the state of the art on security? Have the security problems been "fixed"?


  • The panel agreed that substantial progress has been made in addressing the outstanding security issues. TKIP is substantially better than anything based on WEP, including WEP with dynamic keys. With two exceptions (which, for the record, includes me), the panel felt that TKIP (WPA version 1) was good enough for large-scale deployment.


  • My personal opinion on WPA is that there are still substantial theoretical weaknesses in TKIP. TKIP was designed for backwards-compatibility with WEP-based hardware, and it shows. For example, TKIP includes countermeasures that are invoked upon detection of certain types of attacks against the new integrity check, called Michael. I do not consider the existence of countermeasures to be a feature. Rather, they indicate how weak the revised integrity check is. (I should note that Michael is as good as it can be, given that it was designed to be compatible with WEP-based hardware. Its flaws are inherited from backwards-compatibility. Within its design constraint, Michael is quite clever.) Instead of implementing TKIP (WPA 1), I recommend using CCMP, the AES-based algorithm in 802.11i.





Question: How is wireless driving the standards process?



  • I answered a slightly different version of the question than the one posed by the audience member. Wireless networks are causing changes in the standards, but they are also causing network engineers to re-think the way they build networks. For example, one of the organizations I worked with started off with two VLANs on their network. A VLAN for the users, and a VLAN for the servers. That way, the server network would be isolated from any problems on the user network. When they initially deployed a wireless LAN, anybody who could authenticate successfully was attached to the user network. However, the equipment they selected for their wireless network was capable of dynamic VLAN assignment, and could do much more than attach everybody to the same VLAN. As part of a later core network upgrade, they redesigned the network so that there was a VLAN for each department. Then, in Active Directory, they associated each VLAN with a user group. As a result, when a user authenticates to a network, he or she is attached to a network that was built to serve departmental needs only. Access control between the different functional groups can be built into the core network equipment, enhancing security of the network from internal attacks.


  • Paul Congdon answered the real question. There are notable gaps in the specifications that have appeared because of the differences between wireless and wired networks, and working groups have formed to close those gaps. 802.1X was originally intended for wired networks, and the 802.1X state machine reflects that. A working group called 802.1X-rev (formerly 802.1aa) is revising the state machine to better fit on wireless networks. He also mentioned two other groups. 802.1ae is working on MAC security, and 802.1af is working on "key agreement." Key management has been a problem on wireless networks. Right now, the generation and distribution of link layer keys is not formally specified anywhere. Keys are sent from authentication servers to access points through the use of Microsoft vendor-specific attributes in an ad hoc standard that the industry has adopted. By formally specifying where keys come from and how they are transported, it should be possible to make more interoperable products as well as enhance the security of keying mechanisms.





Question: What will the state of the art in wireless LANs be next year?



  • User identity will become a larger component of network engineering, especially as it relates to policy. User identification has traditionally been absent from the LAN world because it has been assumed that if you can connect, you are authorized. Policies have usually been based on location or IP address. With user identity available, more tools will develop to use the identity to control and direct traffic.


  • In a related point, the RADIUS clients in access points will need to grow up and become much more feature-rich. RADIUS is a AAA (authentication, authorization, and accounting) server implementation. 802.1X is the first A in AAA, and every AP in our testbed supports authenticating users. With the implementation of dynamic VLAN assignment, APs are moving towards a more active role with the second A as well. Nearly every AP in the iLabs network supported dynamic VLAN assignment. VLANs can be used to assign network privileges, but there is a large list of other authorization attributes that can be enforced. It would be possible, given a suitable set of RADIUS attributes, to restrict access to particular physical locations, APs that support certain types of encryption (e.g. WPA but not WEP), and apply additional traffic filters to a user. A few advanced products have already begun to extend authorization beyond VLANs, and we expect that number to grow in the coming year.


  • As an additional type of authorization attribute, the panel discussed something which we broadly called "network integrity protection." Authorization depends on two factors: the user identity, plus the machine's configuration. Obviously, the user must be identified as an authorized network user before granting access. However, the level of access can be made to depend on the state of the machine. Users sessions coming from machines that have up-to-date software are given the full privileges the user is entitled to. If the machine is not up to date with required operating system patches and additional security software, such as anti-virus with current signatures, then the session will be connected to a "quarantine" network with less access. Typically, quarantine networks have captive web portals that offer instructions on how to update software to bring them in to line with the policies. At the iLabs, we had products from Sygate and ZoneLabs to demonstrate this; they are both part of a larger organization called the Trusted Computing Group. TCG's work is the first step towards more extensive protection at the edge from user machines.


  • VLAN assignment will be worked out. Next year, most, if not all, products should comply with the relevant standards. There was, admittedly, a hint of irony in our tone because we said the same thing last year. Last year, however, the standards were still in draft form. Next year, RFC 3580 will be a year and a half old, so there is no excuse for not complying with it.





What else should the panel audience have asked?