Go to:

IT Jobs

There’s no doubt that the biggest scares we’ve had to deal with when trying to deploy wireless networks are to do with health and security. The health issues we’ll deal with another day (suffice to say that the mobile phone jammed to your ear is of significantly more concern and most of that is to do with ergonomics and shoulder-strain), but security - if it’s done properly - really shouldn’t be an issue these days.

But you try writing a paper for your manager describing the security measures you plan to put in place and you’re heading straight for acronym city. EAP, LEAP, PEAP, TLS - what are all these and which ones should you be interested in?

Extensible Authentication Protocol
You need to be dealing with EAP, of one type or another, to give you a suitable level of security - the weaknesses of basic WEP are all too well publicised. The Extensible Authentication Porotocol, EAP (RFC 2284) relies on another protocol to carry it, such as 802.1x or RADIUS, and enables authentication between a client device and the authentication server that controls access to the network.

There are three devices involved:

• Client supplicant - the end user device that requires access
• Authenticator - the wireless access point
• Authentication Server - the AAA server that will allow or disallow access to the network.

The three main elements of the EAP approach are:

• Mutual authentication between client and authentication server
• Encryption keys dynamically derived after authentication
• Centralised policy control, where session time-out triggers reauthentication and new encryption key generation

There’s a good reason for these three objectives to be met. Mutual authentication is important because we not only need to be sure that anyone trying to access our network has the right to do so, but we need to be confident that we are logging into the real network, and someone hasn’t installed a rogue AAA server somewhere that’s merrily picking up all our login details.

Dynamically working out encryption keys after you’ve authenticated means that you’re sure both ends are valid before you go any further and the keys aren’t statically configured anywhere for anyone to pick up.

The central control is essential for scalability. Even with dynamic keys, eavesdroppers on your WLAN could figure out keys if they can gather enough data. By changing keys regularly (as a minimum, at the start of every login session) this threat can be removed.

EAP Process
The sequence of events is as follows:

• A wireless client associates with an access point, which will block the client from gaining access to anything (except the authentication server) on the network until it has logged in and authenticated.
• The client supplies network login credentials (e.g. user ID and password). Using 802.1X and EAP, the wireless client and AAA server perform mutual authentication through the access point, so that the server verifies the client credentials and the client verifies the server credentials.
• The server and the client then agree on a WEP key specific to that client. The client loads this key and prepares to use it for the logon session.
• The server sends the WEP key, called a session key, to the access point. The access point encrypts its broadcast key with the session key and sends the encrypted key to the client, which uses the session key to decrypt it.
• The client and access point activate WEP and use the session and broadcast WEP keys for all communications during the remainder of the session or until a time-out is reached and new WEP keys are generated.
• Both the session key and broadcast key are changed at regular intervals. The AAA server specifies a session key time-out to the access point and the broadcast key rotation time can be configured directly on the access point. Key changes are invisible to the network user.

LEAP
Lightweight EAP is a Cisco-proprietary version of EAP that, despite not being a standard (it was brought out before any client systems supported EAP within the OS) is very widely used. It works much as described above. The main perceived restriction to LEAP, apart from its non-standardness, is the fact that only user id and password can be used as login credentials: there is no support for One-Time Password (OTP) mechanisms. In its favour, it offers a single sign-on: i.e. as a user you login to the network once, as LEAP can use your existing backend directories for authentication. After risks were pointed out, Cisco has announced a new protocol, EAP-FAST.

EAP-TLS
EAP-TLS (RFC 2716) is an EAP authentication algorithm based on the Transport Layer Security protocol that provides mutual authentication based on digital certificates on both client and server. In operation pretty much the same as already described, the use of certificates does potentially make things more secure. However, the added burden of certificates on all client end devices can be difficult to administer, and CPU-intensive, so this approach isn’t particularly widely used.

PEAP
Protected EAP seems to offer the best approach. A digital certificate on the AAA server is used for server-side authentication: for client authentication, one of the EAP authentication mechanisms is then used within the TLS-protected tunnel which is set up. The big advantage here is that One-Time Passwords (eg SecureId tokens) can be supported in addition to just user id and password and you don’t need certificates on clients. PEAP is being supported by Cisco and Microsoft, who, along with RSA, have submitted an IETF draft.

The consensus seems to be that this is the way forward, certainly if you’re a Microsoft or Cisco (who was the first to offer support for PEAP in its ACS AAA server) house. Of course, rather than make things too easy, Cisco PEAP is not exactly the same as MS PEAP, as they support different ways of authenticating the client through the TLS tunnel. The Microsoft PEAP supplicant supports client authentication by MS-CHAP, as used by Windows NT Domains and Active Directory. The Cisco PEAP supplicant supports client authentication by OTPs and logon passwords, enabling support for OTP databases from vendors such as RSA Security, and logon password databases such as LDAP and Novell NDS, in addition to Microsoft databases. Fortunately the AAA servers can work with both.

PEAP’s not ideal either though. If you use it, you no longer have single sign on capabilities. As a user you will have to authenticate to the wireless network using PEAP, and then login to your Windows domain, for instance (unless you run the MS variant). And while Microsoft and Cisco offer PEAP supplicants, that’s about it for now.

There are other EAP variants, such as EAP-TTLS, from Funk software, and EAP-SIM, but with the big hitters supporting the options detailed above, they are the ones you need to be comfortable with. Of course when 802.11i is finalised by the IETF in the next few months, it may well be a case of all change!

Latest White Papers

The future of enterprise mobility in Europe
>> Download whitepaper

Top 10 lessons learned for corporate 3G mobile broadband deployments
>> Download whitepaper

Lowering 3G bills and increasing availability with wi-fi
>> Download whitepaper