Using PEAP Wireless Authentication in a Cisco/Microsoft Network

Whether you're planning a new Cisco wireless network or upgrading your wireless encryption and authentication methods, you should consider the use of PEAP authentication. The Protected Extensible Authentication Protocol uses the RADIUS protocol and is easily integrated into Microsoft's Active Directory using the Microsoft Internet Authentication Service to validate user or machine credentials. This allows the authentication process between the wireless client and the authentication server, typically a RADIUS server, to be completely encrypted. It also utilizes signed certificate server validation which allows for the client device to verify the identity of the remote server before sending credentials, reducing the risk of hijacking of usernames and passwords.

PEAP is another flavor of EAP-TLS and is a method developed by Cisco, Microsoft and RSA. Because it is not an IETF or IEEE standard, there has not been a overwhelming push for the protocol to be universally supported by all 802.11-capable devices. PEAP works well with Cisco and Microsoft wireless client software; however, moving to PEAP does not eliminate the use of other 802.11 encryption protocols, including WPA/WPA2. In fact, you should plan on integrating an SSID with WPA/WPA2 encryption for basic devices such as PDAs, wireless printers and other thin-client type devices.

While many devices do not support PEAP, most devices I've tested do. I've have tested both Linux and Windows laptops with the protocol and even an iPhone. All were able to connect with little to no issue. For devices that did not support the encryption method, we set up a secondary network that uses the same SSID (multiple authentication methods on a signle SSID is available on Cisco wireless controllers beginning with version 4.1) and supports WPA with TKIP and WPA2 with AES. You can choose not to send your SSID in broadcasts, so end users are forced to manually create a connection profile. Based on supported encryption and authentication protocols, connections are created that prefer 802.1x PEAP authentication. Our network access policy allows WPA/WPA2 connections only if PEAP is not supported. By enabling the client exclusion feature, we can avoid brute force attacks on our passphrase-protected networks by banning devices after several failed authentication attempts.

The largest roadblock that was encountered was the validation of the server certificate. You can setup an Enterprise Certificate Authority (CA) in your domain and distribute a root certificate that is trusted by machines that are a member of your domain, but you'll still have the headache of installing the root certificate manually on any other computer. When one of our contractors tried to connect to our network using PEAP authentication, the server certificate was not signed by a certificate authority (CA) that was already in their certificate store. We had to create a certificate and have a well-known CA sign the certificate, which we found for less than a hundred dollars per year.

The most apparent benefits of PEAP deployment are:

• Increased security

PEAP utilizes WPA or WPA2 to encrypt packets, which can be customized to the administrator's needs. Passphrases are no longer shared with end users; and a single user's access can be revoked through Active Directory. Encryption keys are created on a per-session basis and changed periodically while connected. Authentication servers should send client devices a x.509 certificate signed from a certificate authority that the machine inherently trusts, greatly reducing the chance that a cilent will send usernames and passwords to a malicious access point.

• Reduction in cost for RADIUS server

Microsoft Windows Server 2003 and 2007 include the Internet Authentication Server at no charge. When installed on the current domain controllers in the enterprise, it eliminates the need for a separate RADIUS server in both hardware and licensing. I installed Microsoft's IAS on redundant Windows 2003 Servers running as virtual machines in a high-availability setup to give the networking staff access to the service without the requirement of the applications/systems team locking down a profile on a domain controller.

• SSO (Single Sign-On) for domain users

Users in a domain can use their credentials for authentication on any device that supports PEAP. If a client device is a member of the domain, Windows credentials can automatically be passed to the wireless system by a dot1x supplicant; eliminating the need to change and enter multiple passwords. The Group Polcy for the Windows domain can be altered to automatically pass SSID, authentication type and encryption protocol to domain devices, simplifying deployment in large enterprises.

For smooth integration, you will need to remember these items as crucial points in planning:

• You need an certificate signed by a certificate authority (CA) that your client devices will trust unless every client is a member of your Active Directory domain
  • You will still need another type of authentication and/or encryption for devices that do not support PEAP
  • PEAP is not recommended for guest wireless networks

If you're already using EAP-TLS, there may not be a major case for a migration to PEAP. With the deployment of any new technology, a fair amount of planning and testing should accompany the project. PEAP works best with Cisco wireless devices combined with Microsoft's IAS running on the Active Directory domain controllers, so implementation may not be possible under your current infrastructure and configuration. Single Sign-On and deployment through Active Directory's Group Policy entice shops with the current ability to proceed with PEAP, but the no-brainer decision to deploy will definitely be followed by a humdinger of a design phase.