http://www.nwfusion.com/news/2004/0112wlansecurity.html By Ellen Messmer Network World 01/12/04 This is supposed to be the year that the industry addresses the serious security shortcomings that are holding back enterprise wireless LAN rollouts. But looming implementation issues and vendor disagreement are raising questions about just how soon the security dilemma will be solved. The 802.11i protocol for wireless encryption is on track to become an IEEE standard by June, but it looks like existing WLAN customers seeking to adopt it will need to swap out hardware instead of just upgrading software. In addition, Cisco and Microsoft have gone their separate ways on a WLAN authentication technology called Protected Extensible Authentication Protocol (PEAP), creating a schism that could result in interoperability issues. The 802.11i protocol for shielding wireless data from over-the-air attacks is intended to replace the Wi-Fi Protected Access (WPA) specification that the Wi-Fi Alliance put forward in late 2002 as an interim replacement for the flawed Wired Equivalent Privacy (WEP) encryption standard. But however promising 802.11i seems, it won't be as simple to adopt as say, WPA, which only called for a software upgrade. Because of its more intensive encryption processing, 802.11i will require an entirely new wireless access point in many cases. That has WLAN vendors and customers discussing migration strategies as "802.11i-upgradeable" access points start to hit the market in advance of the standard's completion. "This is a huge issue right now," says Jon Allen, coordinator of IT security at Baylor University in Waco, Texas, which has a campuswide WLAN based on Enterasys Networks gear. "It's very important that with limited university funds we not get dead-ended with hardware." Baylor wants to expand its WLAN campus network and still be prepared to adopt 802.11i security as soon as possible after the standard is approved. The older Enterasys R2 model of WLAN equipment that Baylor uses might be able to support 802.11i through a swap-out of radio and chipset, but it might not. Enterasys "can't guarantee it until the standard is set," Allen says. This uncertainty is forcing Baylor into a wait-and-see approach as regards 802.11i, which uses the 128-bit government-sanctioned Advanced Encryption Standard (AES), approved by the National Institute of Standards and Technology as the replacement for the Digital Encryption Standard. Vendor warnings And this uncertainty is prompting vendors - which don't want to see the market for WLAN equipment dry up as everyone waits on the finalization of 802.11i based on AES - to explain their migration strategies. Enterasys says its new model AP3000, which is set to ship next month, will be based on more powerful hardware that can operate in "dual-mode" WPA/WEP and 802.11i draft-compliant AES. "The chipsets of the older R2 were never made to support the type of key technology in 802.11i," says Jeff Manning, marketing manager for wireless at Enterasys. Cisco and Intel, also big backers of 802.11i, agree that the emerging standard will require a new generation of WLAN equipment and that customers need to be aware of that. "You want to install the access point once, not twice," says Duncan Glendinning, wireless program manager for Intel's mobile platforms group. "The change is the AES encryption, which takes a lot more computing power." Intel - which uses WLANs extensively and is struggling with the same upgrade questions that Baylor has - is working to ensure future versions of its Centrino WLAN hardware are "802.11i-upgradeable," Glendinning says. Cisco also has started educating customers on its 802.11i product plans. "On the access point side, you'll need new radios or a whole new access point for good performance for 802.11i," says Chris Bollinger, product manager for Cisco's WLAN business. "And the new network interface cards will also have AES on board." Though a time frame has not yet been announced, Cisco plans to include AES-based processors in the Cisco 1000 and 1200 WLAN access points before the 802.11i standard is finalized. Cisco will provide a way to activate 802.11i with these models once the standard is set. "In the Cisco product family, you could have several different security schemes on one access point," Bollinger says. However, for customers that spent millions of dollars on Cisco WLAN equipment that supports WEP/WPA but not 802.11i, Cisco wouldn't necessarily advise swapping it all out for 802.11i, especially if used in retail sales or warehouse environments where worry about WLAN sniffing and cracking might be minimal. "If the highest level of support is WPA," Bollinger says, "that's not bad." As 802.11i gets closer to being finalized, testing equipment for interoperability across vendor lines will become a bigger issue. The Wi-Fi Alliance and TruSecure's ICSA Laboratory are among the organizations planning to conduct such tests. PEAP problems Even if 802.11i turns out well this year, there are other simmering WLAN security issues that show no signs of cooling down. Cisco and Microsoft over a year ago teamed on a client/server-based authentication protocol called PEAP (see story). The goal was to include PEAP in WLAN gear as well as client software, authentication servers and online directories where an end-to-end authentication protocol was needed to approve user access to a WLAN. Microsoft and Cisco submitted the work done on PEAP to the Internet Engineering Task Force, hoping it would become a standard. However, Cisco and Microsoft are now sharply split on what PEAP is supposed to be, with each supporting separate versions but confusing customers by still calling their own implementations PEAP. "There are two flavors since Cisco and Microsoft PEAP haven't come together," says Kevin Walsh, director of product management at Funk Software, which has endeavored to support multiple WLAN security methods in its client/server authentication products. "The Cisco [PEAP] client can't be authenticated by the Microsoft server and vice versa." "PEAP, when it first came out, everyone said, 'This is it!'" Cisco's Bollinger says. "PEAP was defined in a fairly flexible way. It works much like your browser when you go to a Web page. PEAP uses Secure Sockets Layer under the covers, and you can encrypt from the client to the server and then authenticate." But the flexibility in the model allowed for variants that have split Cisco and Microsoft in this area. Microsoft has supported its version of PEAP in Windows XP, Windows 2003 and Active Directory in a way that Cisco terms a "lock-in." "It works great for Active Directory and NT domains, but doesn't work with [Lightweight Directory Access Protocol], Novell Directory, SecurID or one-time passwords," Bollinger says. "It works great for Microsoft databases and nothing else." Cisco's version is broader, according to Bollinger. With its Microsoft alliance foundering, Cisco has turned to Funk, Intel, MeetingHouse Communications and others to ensure its version of PEAP is supported in client software. Cisco also still supports an older proprietary protocol, Lightweight Extensible Authentication Protocol, specific to its own WAP and authentication server. Microsoft declined to provide a spokesman on the issue of PEAP, but did answer questions via e-mail. "Both companies support PEAP, but each with different methods of authentication," Microsoft wrote. "In comparing Microsoft's version and Cisco's version, we believe our implementation offers several important advantages." Among these would be a feature Microsoft calls "fast reconnect," supposedly a speedier method of authentication. Microsoft's e-mail also said: "The Cisco approach is not an open standard and is available only from Cisco partners, potentially limiting future network infrastructure choices and potentially leading to higher long-term deployment costs." Meanwhile, both versions of PEAP languish in the IETF without making any progress as a common standard. - ISN is currently hosted by Attrition.org To unsubscribe email majordomo@private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Tue Jan 13 2004 - 05:34:40 PST