September 2003

Wireless Security -- A VoIP Challenge

BY RICH WATSON

Utilizing the installed 802.11 wireless LAN (WLAN) for both data and voice applications makes a lot of sense. Mobile wireless connections to the PBX afford some real productivity enhancements not possible with traditional �desk bound� telephony products. But, if you�ve read any of the articles about WLANs in the past year, you are acutely aware of a well-documented and widespread security concern. The initial RC4-based encryption scheme adopted as part of the IEEE 802.11 specification was WEP (Wired Equivalent Privacy). When enabled, all packets transmitted between a WLAN access point and mobile units are encrypted with a specified 40- or 128-bit key. In the early stages of the WLAN deployment, most users felt secure in knowing that the information being transmitted on their WLAN was encrypted and secure. So unconcerned was the WLAN community about wireless security that many WLAN sites had no security enabled at all. It was the seminal RC4 analysis article that documented the weakness in the WEP architecture and the fact that hackers with the right tools and enough patience could crack even the highest level of the WEP security encryption.

While WLANs open up a new world of un-tethered capabilities and enhanced employee productivity, the threat of valuable corporate data being stolen right out of the �air� made most enterprise CIO�s pause when considering deploying a production WLAN. Industry backlash at the apparent weakness in the WEP architecture forced WLAN vendors and the IEEE 802.11 working group to go back into session and redefine new, more rigorous wireless security schemes that would be embraced by the market.

The IEEE standards body, industry alliances, and individual WLAN vendors have responded by proposing multiple options for more rigorous and �bullet-proof� security schemes. While the IEEE has yet to ratify the final enhanced 802.11i security standard, most WLAN vendors currently offer �safe� WLAN solutions with some form of enhanced security that attempts to address WEP�s weaknesses. Now, WLAN customers can breath a sigh of relief with these strengthened security features, but there may be repercussions with regards to the support of specific WLAN applications. This article explores the challenges posed in implementing a wireless VoIP solution in a secure environment.

CUSTOMER RESPONSES
Facing the documented security problems with WEP, enterprises that had already deployed an 802.11 WLAN took many different steps to maximize security within the established standards framework. This included imposing alternate security policies that minimized the overall security risk of running a production WLAN. Besides imposing the use of 128-bit WEP (a step that did increase the difficulty of cracking the key), other corporate policies have been enforced, such as:

� Virtual Private Networks (VPNs)
� Virtual LANs (VLANs)
� Access Control Lists (ACLs)
� Disabling broadcast ESSID

Even though the WEP/RC4 security standard is flawed, it still takes some concerted effort of tracing traffic to crack a static WEP key. iLabs reported that it could take up to a week (or more) of �sniffing� on a heavily loaded network to get enough of the weak Initialization Vectors to crack a 128-bit WEP key. Thus, enabling WEP is still far better than no WEP at all.

Deploying an off-the-shelf VPN does enhance the security of data because it is an end-to-end encryption scheme, which impacts more than just the RF security domain. A large number of corporations have taken this approach because it is commercially available, already under their IT department control and provides security to satisfy their concerns about wireless hacker intervention. However, because a VPN is a Layer 4 service, this has the potential for introducing additional latency in end-to-end transmissions. This has little affect on data applications, but can have a severe impact on voice quality in a wireless VoIP application.

Isolation of voice traffic by using VLANs is another approach to eliminate or minimize any security policy impact on a voice application. If a corporation deems that voice traffic is low risk for sabotage, it can limit all voice traffic on the network to specific, non-secure devices by placing all �voice� traffic on its own VLAN segment within the network. Additionally, most current WiFi access points support the concept of VLANs, which further simplifies use of the wireless infrastructure by having different security policies for the various VLANs, while also segregating voice and data traffic. Typically, well-implemented VLANs have no impact on a wireless VoIP application because of the extremely low latency in VLAN switching.

Implementing an ACL involves configuring each access point within the wireless network with a list of authorized MAC addresses. This provides an inclusive list of all pre-authorized devices that can associate with the network and blocks rogue devices from accessing the network. While this prevents rogue devices from access to the network, it also places a large management burden on the network administrator to keep the access points up to date each time a device is added or removed from the pool. It also doesn�t prevent illegal use of a valid device on the network. There is, however, no impact on a wireless VoIP application with respect to implementing ACL policies.

Another �security� policy often recommended by consultants is to �disable broadcast ESSID.� The purpose of this policy is to prevent the ESSID string from being placed in the beacon that was sent out from the access point. The theory is that no one using a wireless �sniff� tool could detect the ESSID (sent in clear text) if it was not in the beacon frame, thus keeping secret the identity of the WLAN. The flaw with this approach is that, by turning off the ESSID in the beacon, this requires the client to place the ESSID in its �association� request. Now, instead of the access point publishing the ESSID value, all the mobile clients would be forced to publish it in their association request. So, instead of only having one device publishing the ESSID, tens or perhaps hundreds of devices would be broadcasting the ESSID, making it far easier to find the wireless network identity, thus defeating the purpose of the policy.

Until the IEEE 802.11 standards body or vendor provides stronger security options, it is still recommended that WEP be enabled with the possibility of using VPN, VLANs, ACLs, or placing the WLAN on an unsecured portion of the corporate network and running only non-critical applications. How these security policies and practices impact wireless VoIP applications will be discussed further.
 

INDUSTRY RESPONSES
The wireless industry recognized the critical need for providing strong security services and has reacted ahead of the �standards� bodies. The IEEE is working on the 802.11i standard that will define a robust security standard for WiFi products, but this standard has not yet been ratified. So, in advance of the 802.11i standard, many vendors have stepped up and offered their own solutions. The current pre-802.11i options offered by vendors for consideration are:

� VPNs
� LEAP/RADIUS
� Kerberos w/KDC

Use of a VPN seems to be a straightforward solution to wireless security problems because it provides security control at the highest level -- end-to-end encryption across the network. VPNs meet the requirement of authentication and data security, but can impose a severe penalty on a real-time application like VoIP. Without an assist from a high-end processor or co-processor, applying the encryption policy at the transport level can degrade the resultant voice quality of a wireless PDA class device. The �tunneling� of the packet flow through a VPN can also add to the overall latency of the system and further degrade voice quality.

It almost seems that VPNs and wireless VoIP are mutually exclusive. This is not quite true, but great care must be taken in implementing and deploying a wireless VPN solution. Consideration for the computing power of the handheld, battery capacity and the VPN design within the network fabric must all be considered in an attempt to guarantee a secure, high-quality VoIP solution.

Most of the industry is familiar with Cisco Systems� LEAP/Radius wireless security solution. In this architecture, each time a device re-inserts itself into the network (i.e., roams), it must have full re-authentication via the RADIUS server. Depending upon the complexity of the hosting network, such an operation can add 150-250msec (or longer) of latency on a roam. Such a small fraction of a second is not significant to a data application, but will result in a degradation of the voice quality with dropped packets when roaming.

Kerberos is a security architecture developed at MIT and implemented in most Unix releases. Used as a standard security scheme for over 20 years in the Unix market, Kerberos provides a method of unit authentication plus encryption key management. It can be implemented to support mutual authentication, whereby every device within the network fabric (including access points) are authenticated. Once authenticated within a secured network, roaming from access point to access point is made secure through the exchange of pre-secured credentials that can be verified between parties. This architectural approach supports the concept of fast, secure roaming and doesn�t require a complete re-authentication upon each roam. Additionally, Kerberos goes beyond a simple authentication scheme and provides for dynamic key management for compliant devices.

STANDARDS BODY RESPONSES
The wireless industry is working, both in standards bodies and through collaborative associations, to enhance the wireless security options and attempt to ensure cross-vendor interoperability of products. Good examples of these in-process works are:

� WiFi Protected Access (WPA)
� Temporal Key Integrity Protocol (TKIP)
� Advanced Encryption Standard (AES)

These works are mostly derived from the on-going efforts of the IEEE 802.11i task group and are focused at defining two categories of wireless security schemes:

1. Enhancing the standards-defined security that is compatible with current hardware products. That is, a security model that can be implemented without changing the hardware.
2. Defining a more rugged security standard that may require additional hardware to be built into future devices.

Implementations of TKIP (see definition below) and WPA architectures have been defined to fit into category #1 of the new security offerings. AES is a more robust security algorithm that has already been adopted by the military and the federal government for their encryption standard and is the driving technology for security category #2.

WPA is a security offering backed by the WiFi Alliance and is this body�s definition of how 802.11i�s TKIP components can be implemented, while assuring vendor interoperability. All of the TKIP elements of 802.11i (encryption, authentication, and message validation) have been included in the definition of WPA and guarantee interoperable wireless security schemes through firmware updates to current industry-standard hardware. It is anticipated that the industry will conform to WPA and the deployment of secure WLANs will proceed. When 802.11i is ratified, new firmware may overlay the WPA modules, while retaining vendor interoperability.

TKIP is an extension to the WEP standard which �plugs the hole� in the original RC4-based encryption standard. In this scheme, the scope of the key management scheme (Initialization Vector) has been significantly extended along with a new requirement that each packet transmitted be encrypted with a new key. TKIP also includes the implementation of a �message integrity code (MIC)� that adds a per-packet source validation mechanism. When completed and ratified, this component of the 802.11i standard will significantly strengthen the encryption mechanism to be supported by all WiFi vendors.

With both WPA & TKIP, there is some concern within the wireless industry whether a voice application can be supported without additional hardware assistance. This concern is due to the potential latency induced by the enforcement of the MIC portion of these standards. Without hardware assistance, handheld devices may not be able to provide the toll quality voice that is expected by the market.

The complete 802.11i standard includes AES, which is perhaps the ultimate strong encryption scheme. Generally accepted as the strongest encryption method available today, AES does provide stronger encryption services than RC4, but may also require hardware (ASIC) assistance when implemented on low-end, battery-powered devices. Implementing this level of the 802.11i standard may require new hardware platforms to be developed in order to provide optimal voice quality.
 

SUMMARY
Consideration of the security requirements for a mixed data/voice wireless network is key to a successful deployment, as imposing overly stringent security policies can jeopardize voice quality. Therefore, it is important that businesses first assess their risks with regard to wireless telephony applications, and then apply the minimal security policy to safeguard against that risk.

The advantages of wireless VoIP can be lowered TCO (Total Cost of Ownership), enhanced productivity of associates and, possibly, lowered headcount because of a streamlined operation. The decision that must be faced is: �do the advantages outweigh the risk?� Commercially available security options may vary from vendor to vendor, further complicating any final decision regarding wireless infrastructure and mobile units. Even with the ratification of 802.11i, however, defining a configuration that balances between maximized voice quality, minimized security risk and acceptable network management overhead will be crucial in making the final deployment decision.

Richard Watson is director of telephony product marketing for Symbol Technologies� Wireless Systems Division in San Jose, CA. Prior to taking on the marketing role for Symbol�s NetVision family of WiFi Telephony products, he managed the software engineering team for three years and was responsible for developing Symbol�s WiFi Telephony products.

[ Return To The September 2003 Table Of Contents ]