by Lisa Phifer, Core Competence
This is the final column in our series on securing enterprise network access by PDAs. Previous columns described tunneling TCP/IP end-to-end, from wireless PDAs to VPN/firewalls located at the edge of the enterprise network. Today's column considers another alternative: tunneling to a wireless gateway.
Hosted gateways and WAP
Many public network operators offer secure tunneling from wireless handhelds (smart phones, two-way pagers, and PDAs) to a wireless gateway, hosted at the operator's NOC. Some of these gateways are based on Wireless Application Protocol (WAP), an architecture for communication between WAP-enabled devices and Internet Web servers.
First-generation WAP relayed traffic between wireless devices and Web servers through a proxy server, called a "WAP gateway." Lightweight protocols are exchanged between the device and gateway:
- Wireless Datagram Protocol (WDP) carries packets over circuit-switched wireless network services like CDMA, TDMA, and GSM;
- Wireless Transport Layer Security (WTLS) is an SSL-like tunneling service that provides authentication, encryption, and integrity for datagrams between the WAP device and gateway;
- Wireless Transaction Protocol (WTP) is a "wireless tuned" transport that falls somewhere between TCP and UDP, providing reliable delivery without connection establishment; and
- Wireless Session Protocol (WSP) is an HTTP-like application protocol capable of supporting either connection-oriented or connectionless wireless "sessions."
The WAP gateway decrypts incoming requests protected by WTLS, converts WSP/WTP into HTTP, and relays the re-encrypted request over SSL to the destination server. Similar translation occurs in the reverse direction, with HTML Web content converted into WML, a markup language for WAP "micro browsers."
Many manufacturers have released WAP 1.1 handsets, including Acer, Alcatel, Ericsson, Mitsubishi, Motorola, Nokia, Samsung, Siemens, and Telson. WAP 1.1 gateways include CMG's WSB and Openwave's Mobile Access Gateway. According to the WAP Forum, by late 2001, there were over 40 million WAP handsets, served by 139 carriers (including test and production services).
Building a better WAP
Despite these numbers, first-generation WAP was not as well received as supporters had hoped. Among the issues were the expense of transforming protocols at the WAP gateway, lack of support for new packet-switched data services, a limited application development environment, and the "WAP gap" -- the security "hole" caused by proxying between WTLS and SSL.
In response to these criticisms, WAP 2.0 specifications were released in July, 2001. The new WAP 2.0:
- uses "profiled" Internet-standard IP, TCP, and HTTP protocols over the air link;
- supports emerging high-speed data services like GPRS and CDMA2000 3XRTT;
- permits end-to-end data encryption with improved PKI support; and
- uses an expanded application environment.
The WAP 2.0 application environment (WAE) is based on XHTML. WAE 2.0 incorporates a number of extensions, including a "push proxy" (allows servers to send notifications to wireless devices), support for wireless telephony applications, the ability to add "plug-in" modules that go beyond WAP application services, interfaces to utilize persistent storage and synchronize data, and support for multi-media messaging services.
Clearly, the WAP Forum hopes that WAP 2.0 will be able to support more feature-rich applications on more diverse handheld devices -- including M-commerce, M-billing, and M-care enterprise applications for conducting business from your wireless PDA. Naturally, these kinds of applications demand tighter security, causing the whole idea of a WAP gateway to be reconsidered.
Avoiding the WAP gap
WAP 2.0 reduces dependence on WAP gateways. It is now possible for WAP-enabled devices to establish HTTP/TLS sessions directly with the destination Web server, providing end-to-end confidentiality, authentication and non-repudiation. Of course, there is still an intermediate system that provides internetworking between wireless and wired networks. The WAP 2.0 protocol stack is composed of:
- Any wireless network capable of delivering Internet-standard IP packets;
- Wireless Profiled TCP (WP-TCP), a "thin stack" flavor of Internet-standard TCP that has been optimized for wireless, yet interoperates with "regular" TCP implementations;
- Transport Layer Security (TLS), the Internet-standard version of the SSL tunneling protocol originally defined by Netscape, widely supported by Web browsers; and
- Wireless Profiled HTTP (WP-HTTP), Internet-standard HTTP, profiled with wireless extensions (for example, response compression) and interoperable with "regular" HTTP Web servers.
In this architecture, the WAP gateway can be reduced to a simple proxy, relaying TLS-tunneled data between WP-TCP on the wireless side and "regular" TCP on the wired Internet side. Of course, the WAP gateway can still do more -- for example, delivering push content and location-based services. But the 2.0 architecture no longer requires a content-aware, trusted gateway.
Note that the WAP 2.0 protocol stack cannot be used with wireless networks that do not deliver IP or operate at very low speed. Multi-mode devices may use WAP 2.0 over high-speed networks like GPRS, falling back to WAP 1.1 over older networks.
Is WAP 2.0 enough?
The first WAP 2.0 products are starting to emerge. For example, Opera Software has released a WAP 2.0 compliant version of the Opera browser, embedded in Nokia 9210i Communicator (Symbian OS) and Sharp Zaurus (Linux) devices. ACCESS added WAP 2.0 support to NetFront v3.0 Wireless Profile; this browser is being embedded in the Texas Instruments OMAP processor for 3G wireless phones and PDAs running Symbian OS. Openwave's Mobile Browser (Universal Edition) and Mobile Access Gateway products support WAP 2.0. Jataayusoft's jBrowser supports WAP 2.0 on Pocket PC devices.
Naysayers argue that WAP 2.0 may be too little, too late. According to Jane Zweig, CEO of The Shosteck Group, "Making the existing and generally quite poor WAP services easier to access will not, by itself, make them substantially more attractive to subscribers." Giga analyst Carl Zetie was just as blunt. "If WAP 2.0 just means news, stocks, sports and weather 2.0, it will be as big a disappointment in the U.S. as it was the first time around."
Clearly, the success of WAP 2.0 depends not just on beefing up the infrastructure, making wireless faster, and plugging security concerns. Ultimately, success depends on end-user satisfaction, usability, and accessibility. A better mousetrap is irrelevant if nobody can be bothered to catch mice anymore. WAP 2.0 must recapture those consumers who stopped browsing and checking email on their smart phone last year.
Parting thoughts
To conclude this series on securing wireless PDA access to enterprise networks, I would like to put all of the technologies we've covered back into context. Consumers don't really care whether a commercial service based on WAP 2.0 or a virtual private network based on IPsec carries their wireless data -- so long as they can reach the applications they need to reach, when they need to, on the device they're carrying, with acceptable performance.
Network planners and administrators are really the ones in the hot seat, trying to make some sense out the mish-mash of technologies, offering wireless access without compromising security. This five-part series examined alternatives for accomplishing this business goal. We drilled down into a few technologies, to get a better handle on capabilities and limitations.
Of course, there are many other technologies that we barely mentioned. There is no "magic bullet" or "one size fits all" solution. But I hope we have provided useful insight to those tasked with securing wireless PDA access to enterprise networks. Good luck!
Do you have comments about this article, or suggestions for Lisa to write about in future columns? Let us know!
