With a rapidity that belies their decades of gestation, cheap hardware and standard software has made the wireless network not only one of the most popular access methods for portable computing but an essential part of many company's plans. Public access points and home wireless access to work VPNs are extending the reach of 802.11b into every aspect of network use -- speed, convenience and cost mandate this. Security is now a priority.
Wireless networks have a poor reputation for safety. Unlike wired networks, wireless systems have little or no physical security: anyone within three hundred feet of a basestation can undetectably monitor the traffic. If they have access codes, they can connect without arousing suspicion. Wireless networks must therefore prevent user authentication details from being stolen during log-in, protect the privacy of data transmitted subsequently and make sure that users establish the right connection no matter where they are physically stationed.
Most access control systems work by sending a challenge to a client, which then uses that information to encode a password. The encoded password is sent back, the server checks this against its private copy of the password and decides access accordingly. The big problem with this approach is that if an eavesdropper sees both the challenge and the encoded reply, it can try many different passwords until it too generates the same reply. On wired networks, the chances of eavesdropping is small -- on wireless, the chance is unknown.
The first 802.11b access control systems, published in 1999, relied on the client's MAC address -- unique to every Ethernet device -- being known to the server. If the MAC was in the server's database, the user was let in. As the MAC was sent across the wireless link in clear, it was trivial to find and fake this. Data encryption -- the wired equivalent privacy, WEP, system -- used a 40-bit key shared between client and server, modified by a 24-bit additional key. This has proved flimsy: the latest attacks can reliably break WEP in under quarter of an hour.
The benefits to fixing this -- and to adding strong authorisation that lets users authenticate from remote access points not necessarily controlled by the target network -- will be huge. Thus 802.1x has evolved, a system designed to work with 802.11b and related protocols that authenticates users at the place they attach to the network, as well as providing additional management, billing and control features. It specifies a protocol -- EAPOL -- that connects supplicants -- devices wanting access -- to those devices providing access, as well as different levels of access control and SNMP management operations. Developed by a small group from 3Com, HP and Microsoft, it achieved IEEE status in January 1999 and was approved in June 2001. It's already in Windows XP and is appearing in a number of other operating systems, as well as in switches, gateways and access control devices.
802.1x works in conjunction with remote authentication servers, normally -- although not compulsorily -- Radius devices. Before authentication takes place, a wireless node has all its ports closed to clients except those used by 802.1x's protocol, EAP (extensible authentication protocol, RFC 2284). The supplicant client sends a request to the node -- called an authenticator -- which replied with a request for the supplicant's identity. This is then forwarded by the authenticator to the Radius server, which passes back an access challenge, via the authenticator, to the supplicant. If the supplicant's response to this is acceptable to the Radius server, access is allowed -- and the authenticator opens such ports as the Radius server opines are allowed for that particular client. A variety of encryption methods can be used for every step of this transaction, which can be dynamically agreed by the participants during the process.
By using Radius servers, the protocol profits from many extant management and security services: directory services, billing, dynamic key management and so on. It copes with roaming in public spaces (RFC 2607), integrates well with virtual private networks (VPNs) and can optionally cope with new users signing up for services and paying securely for access via credit cards, etc.
802.1x has had its problems, most notably when a paper by two researchers, Arbaugh and Mishra, claimed that it was vulnerable to man-in-the-middle attacks, when an intruder poses as an authenticator and invisibly mediates traffic between client and server. A number of claims in that paper subsequently turned out to be less dramatic than at first thought, and other issues arose through ambiguities and imprecision with the first version of the 802.1x specification.
The next version of 802.1x will have a number of small changes that clarify some ambiguities, improve the API for the supplicant and specifiy how to carry out certain operations. Stronger cryptography is also recommended: this is going through the approval mill and should be an approved standard by March 2003.