Ultimate wireless security guide: An introduction to PEAP authentication

Enterprise wireless LAN security is a persistent concern for every system administrator and CIO. This article, part of the TechRepublic ultimate guide to enterprise wireless LAN security, introduces you to Protected Extensible Authentication Protocol (PEAP) Authentication, which is a secure password-based authentication protocol created for the purpose of simplifying secure authentication.

The complete TechRepublic Ultimate Wireless Security Guide is available as a download in PDF form.

Protected Extensible Authentication Protocol (PEAP) Authentication is a secure password-based authentication protocol created for the purpose of simplifying secure authentication. PEAP is primarily used in Wireless LAN networks though it can also be used for wired authentication, Network Access Protection (NAP), or even VPN authentication in Vista. While there are other suitable authentication protocols like Funk Software's EAP-TTLS that operate nearly identically to PEAP, PEAP enjoys native Windows operating system support along with Windows Group Policy management, which makes it extremely easy to deploy.

Why PEAP and not proprietary authentication protocols

Although PEAP has garnered a sizable market share for non-Cisco shops, it has not weaned a large portion of Cisco customers from the weaker LEAP protocol which commanded the lion's share of the Enterprise WLAN market. More recently, Cisco customers began moving to the newer Cisco EAP-FAST protocol which is almost as insecure as Cisco LEAP and a nightmare to deploy securely. What's worse is that even older Cisco wireless adapters cannot run Cisco EAP-FAST but they can all run PEAP. Because PEAP is universally compatible with virtually any hardware from any vendor, offers "machine level authentication" which is critical for the Enterprise, and can be automatically deployed in Active Directory,* PEAP is the ideal choice in authentication protocols. Note that I am not saying you shouldn't use Cisco hardware since I've had plenty of luck with Cisco's hardware reliability. I'm only recommending the use of standardized protocols for maximum flexibility, compatibility, capability, and ease of deployment.

* Only with Microsoft's built-in Windows XP/Vista PEAP client


Public Key Infrastructure (PKI) is a component of Public Key Cryptography (PKC) that uses Digital Certificates (x.509 format) and Certificate Authorities. PEAP uses PKI to secure user authentication from man-in-the-middle (hacker listening in the middle) attacks much the same way that SSL uses PKI to secure Websites for e-commerce or other sensitive applications.

Although PEAP and SSL operate on different layers of the OSI model (layer 2 vs. layer 5), they both use a server-side digital certificate to facilitate a secure key exchange to start a secure encryption session even if the entire session was being monitored by hostile eyes. This secure session not only protects the key exchange, but even more importantly it protects the authentication session which left unprotected may compromise the user's password.

The PKI model achieves secure key exchange by using Digital Certificates which are simply digital documents that assert their owners identity. Digital Certificates by themselves are worthless unless they are signed by a trusted entity called a Certificate Authority (CA). In order for a CA to be trusted by a client in the form of a wireless laptop using PEAP or a home computer used to shop online using SSL, a "root certificate" containing the public key of that CA must be installed in the user's Certificate Trust List (CTL).

All modern operating systems contain a preinstalled list of trusted Root Certificates in their CTL, and this is what gives a company like VeriSign the authority to sign digital certificates for servers world wide. Using a publicly trusted company like VeriSign makes PKI deployment very simple because it is already trusted by every computer or PDA device in the world off the factory floor, but the server certificate may cost hundreds of dollars per year. Using EAP-TLS with a public CA is even more costly because you would also need to shell out an additional $60 per user per year for client side digital certificates.

Private CAs allow you to sign your own digital certificates if you possessed the knowledge and the infrastructure to house your own private CA. This is why there are so many organizations that simply don't want to bother building a CA infrastructure and they don't want to spend $300 a year dealing with public CAs. This is why so many organizations choose LEAP and live under the illusion that their passwords strength alone will protect them. Convincing these customers to embrace PKI is usually an uphill battle and I speak from first hand experience. To make life easier on you, I'm going to teach you how to avoid dealing with public or private certificate authorities in this wireless LAN series by using self-signed digital certificates.

Authentication server requirements

To implement PEAP, the organization needs to implement a RADIUS Authentication Server. There are many ways to do this no matter your software preference. There are options for Microsoft Windows Server 2003 with SP1 or Windows Server 2003 R2 with IAS, 3rd party RADIUS servers such as Funk Odyssey which allows you to tie in non-Microsoft directories like Novell, and Open Source solutions like FreeRADIUS. Windows Server 2000 also had IAS but only supports EAP-TLS authentication and not PEAP authentication.

To run PEAP, the RADIUS server must have a server side x.509 digital certificate. This certificate can be purchased from a third-party Certificate Authority such as VeriSign, or it can be issued from an organization's internal Certificate Authority. These two options are conventional wisdom but neither option is particularly appealing to small businesses since they won't like paying $300/year for a third-party Digital Certificate and they probably don't have a PKI Certificate Authority server in-house. An excellent way to get around this problem is to use a Self Signed Certificate on your RADIUS server. To implement Microsoft IAS, you can follow my IAS Server configuration guide.

Hardware and Software requirements on PEAP

Every single enterprise class Access Point will support generic RADIUS authentication which is compatible with all the WPA/WPA2 certified EAP types which includes PEAP authentication. Cisco Access Points support a proprietary form of authentication that is used for proprietary Cisco LEAP and EAP-FAST protocols which isn't supported by non-Cisco access points, so I cannot recommend it. Cisco refers to their proprietary authentication method as "Network EAP" and the open authentication method as "Open EAP". As for client side hardware requirements, any client adapter that supports the Windows Wireless Client will support PEAP authentication and most Wi-Fi adapters fall in to this category.

Recent versions of Windows Mobile and CE also support PEAP authentication. Windows XP Wireless Client added PEAP support with SP1 (Service Pack 1) and enhanced it further with Service Pack 2. There was even a WPA2 update for Windows XP. Windows Vista has all the Wireless Client features.

The latest Windows 2000 Service Pack also added PEAP support but WPA grade TKIP or AES encryption capability was never added, nor can you manage Windows 2000's Wireless Client through group policy. You can get a free WPA client for Windows 2000 and many Wi-Fi adapters with Intel or Atheros come with their own Wireless Clients with WPA support for most Windows operating systems. But only the Windows XP and Vista's wireless client can be managed centrally through Active Directory Group Policy. You can learn how to manually configure Windows XP here or automatically configure Windows XP and Vista through Group Policy.

Editor's Picks