Protected Extensible Authentication Protocol
The Protected Extensible Authentication Protocol (PEAP) is an authentication method that extends the Extensible Authentication Protocol (EAP) by encapsulating inner EAP authentication exchanges within an encrypted Transport Layer Security (TLS) tunnel, enabling secure credential transmission for network access control in environments such as wireless LANs and virtual private networks.[1] Although not formalized as an IETF RFC, PEAP was jointly developed by Microsoft, Cisco Systems, and RSA Security in the early 2000s (around 2002) as a response to the security limitations of prior EAP variants like LEAP, leveraging server-side digital certificates to authenticate the authentication server to the client, thereby mitigating risks like eavesdropping and man-in-the-middle attacks without requiring client-side public key infrastructure.[2][3] PEAP operates in a two-phase process: during Phase 1, a TLS handshake establishes the secure tunnel using the server's certificate, confirming the server's identity to the client; in Phase 2, the protected tunnel carries the inner authentication method, which verifies the client's identity using protocols such as MS-CHAPv2 or Generic Token Card (GTC).[4] This design ensures that sensitive user credentials, like passwords, remain encrypted and are not exposed to the network, enhancing protection against offline dictionary attacks and unauthorized access in IEEE 802.1X-based deployments.[4] PEAP supports integration with backend authentication servers via RADIUS, making it suitable for enterprise-scale implementations.[2] Two primary variants exist to accommodate different vendor preferences and inner methods: PEAPv0, the Microsoft-specified version typically paired with EAP-MSCHAPv2 for password-based authentication, and PEAPv1, favored in Cisco ecosystems and often combined with EAP-GTC for token or one-time password support.[5] While PEAPv0 encapsulates inner messages by stripping EAP-TLS headers for efficiency, PEAPv1 transmits them unchanged, allowing flexibility in protocol handling.[2] Widely adopted for its balance of security and deployability, PEAP remains a cornerstone of protected Wi-Fi authentication under WPA2-Enterprise and WPA3-Enterprise modes such as transition and 128-bit security, though it requires careful certificate management to prevent vulnerabilities like certificate spoofing.[6][7][8]Background and Development
History
The Protected Extensible Authentication Protocol (PEAP) was jointly developed by Microsoft, RSA Security, and Cisco Systems in the early 2000s to address vulnerabilities in existing wireless authentication mechanisms, particularly the exposure of credentials in protocols like LEAP.[3][9] The initial proposal for PEAP emerged around 2002 as an extension to the Extensible Authentication Protocol (EAP), designed to encapsulate and protect inner authentication methods within a secure tunnel. PEAP version 0 (PEAPv0) was outlined in the IETF Internet Draft draft-kamath-pppext-peapv0-00, published on October 25, 2002, which described Microsoft's implementation. This version gained early traction through integration into Microsoft Windows XP Service Pack 1, released on September 9, 2002, enabling native support for PEAP in enterprise wireless environments.[10] Cisco adopted PEAP in its wireless LAN controllers shortly thereafter, enhancing compatibility for secure access in networked deployments, while RSA Security contributed expertise on certificate-based authentication elements to strengthen the protocol's TLS foundation.[11] Subsequent drafts refined the protocol, with PEAP version 1 (PEAPv1) specified in draft-zhou-pppext-peapv1-00 around 2004, introducing support for additional inner methods.[11] Despite these efforts, PEAP drafts never advanced to full IETF RFC status, overshadowed by competing tunneled EAP methods such as EAP-TTLS, which gained broader consensus within the working group.[12] PEAP maintained significant relevance in enterprise Wi-Fi following the IEEE 802.11i (WPA2) standard ratification on June 24, 2004, where it served as a key authentication option for robust security networks, particularly in Microsoft-centric environments.[13]Related Protocols
The Extensible Authentication Protocol (EAP) provides a flexible framework for network access authentication, supporting a variety of authentication methods to accommodate different security needs. Defined in RFC 3748 in June 2004, EAP operates as a protocol that can run directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802.1X, enabling its use in diverse network environments including wired and wireless setups. A key component is EAP over LAN (EAPOL), which encapsulates EAP messages for transmission over Ethernet and Wi-Fi networks, facilitating secure authentication exchanges between clients and access points.[14] Transport Layer Security (TLS) serves as a cryptographic protocol that establishes secure communication channels, acting as a successor to the Secure Sockets Layer (SSL). Specified in RFC 2246 for TLS version 1.0 in January 1999, TLS creates encrypted tunnels through a handshake process that includes the client sending a "ClientHello" message, the server presenting its certificate for validation, and subsequent key exchange to derive session keys. Mutual authentication is optional in TLS, though server authentication is mandatory in PEAP implementations to verify the authenticity of the authentication server.[15] Together, EAP and TLS form foundational building blocks for extensible authentication by allowing EAP to transport diverse authentication payloads while TLS encapsulates and protects them from eavesdropping and tampering in untrusted networks, such as public Wi-Fi. This combination supports modular security architectures where inner authentication methods can be plugged into the EAP framework within a TLS-secured outer layer. EAP's extensibility is further leveraged in port-based access control mechanisms, as defined by IEEE 802.1X, a 2001 standard that employs EAP for interactions between supplicants (clients) and authenticators (network devices) to enforce controlled access to LAN ports.[14][15][16]Technical Overview
EAP Framework
The Extensible Authentication Protocol (EAP) provides a flexible framework for authentication in network access scenarios, particularly as utilized in Protected EAP (PEAP). The core components include the peer, which is the client or supplicant seeking network access and responds to authentication challenges; the authenticator, typically an access point or network switch that enforces access control by initiating and mediating the authentication exchange; and the authentication server, a backend system such as a RADIUS server that verifies the peer's credentials and may derive session keys.[17] In the request-challenge-response model, the authenticator sends challenges to the peer, which provides responses that are forwarded to the authentication server for validation, ensuring a lock-step exchange where only one outstanding request exists at a time to maintain ordering.[18] EAP operates through four primary message types to facilitate this exchange: EAP-Request (Code 1), sent by the authenticator to solicit information or issue challenges from the peer; EAP-Response (Code 2), the peer's reply matching the request's type or indicating an alternative method; EAP-Success (Code 3), notifying the peer of successful authentication; and EAP-Failure (Code 4), indicating rejection.[19] Each Request and Response packet includes a 1-octet Identifier field to pair corresponding messages and detect retransmissions, with the Identifier reused for duplicates but incremented for new requests.[19] The packet header also features a 2-octet Length field specifying the total packet size, including Code, Identifier, Length, Type, and variable Type-Data fields, enabling support for payloads of differing lengths without inherent fragmentation at the EAP layer.[19] Within this framework, EAP methods are encapsulated via a Type field in Request and Response packets, allowing selection of specific authentication mechanisms; PEAP is designated as Type 25, functioning as a tunneled method where an outer EAP layer establishes a secure channel, and an inner layer handles the actual authentication to protect sensitive credentials. This encapsulation ensures that the outer method manages initial negotiation while the inner method operates protected, adhering to guidelines for tunneled protocols to mitigate attacks like man-in-the-middle.[20] For deployment in local area networks, EAP integrates with IEEE 802.1X port-based access control, where EAP messages are transported via EAPOL (EAP over LAN) frames, including types such as EAPOL-Start for initiation, EAPOL-Logoff for termination, EAPOL-Key for key distribution, and EAPOL-Encapsulated-Frame for carrying the actual EAP packets between peer and authenticator.[21] Notably, the EAP layer itself provides no encryption or integrity protection, relying instead on the underlying transport or method-specific tunneling for security.[22]TLS Integration
In PEAP, Transport Layer Security (TLS) serves as the foundation for establishing a secure, encrypted tunnel during the outer authentication phase, providing server-only authentication through X.509 certificates while requiring no client certificate, distinguishing it from full mutual authentication methods like EAP-TLS.[23][24] The client verifies the server's identity by checking the presented certificate against a list of trusted certificate authorities (CAs) and, optionally, the server name to mitigate man-in-the-middle (MITM) attacks.[23] This server-centric approach simplifies deployment by eliminating the need for public key infrastructure (PKI) support on the client side.[24] The TLS handshake in PEAP follows a modified EAP-TLS sequence encapsulated within EAP messages, beginning with the client initiating a ClientHello message that specifies the TLS version, supported cipher suites, and random nonce.[23][24] The server responds with a ServerHello selecting a compatible version and cipher suite, followed by its X.509 certificate chain and a ServerHelloDone message.[23] Upon receiving these, the client performs certificate validation; if successful, it proceeds with the key exchange—typically using RSA encryption of a pre-master secret or Diffie-Hellman ephemeral keys—to enable symmetric session key generation.[24] The handshake concludes with Change Cipher Spec and Finished messages from both parties, confirming the tunnel's integrity and activating encryption.[23] PEAP implementations typically support TLS versions starting from 1.0, with modern deployments favoring TLS 1.2 or 1.3 for enhanced security, as TLS 1.3 is recommended when available to leverage its improved cipher suite requirements and forward secrecy.[23][25] For cipher suites, interoperability requires support for options like TLS_RSA_WITH_AES_128_CBC_SHA and TLS_DHE_RSA_WITH_AES_128_CBC_SHA, alongside legacy suites such as TLS_RSA_WITH_3DES_EDE_CBC_SHA, though deprecated algorithms like RC4 (e.g., TLS_RSA_WITH_RC4_128_SHA) must also be negotiable in base specifications.[23] Key derivation in PEAP begins with the generation of the TLS master secret from the pre-master secret using the TLS pseudorandom function (PRF):\text{Master Secret} = \text{TLS-PRF}(\text{pre_master_secret}, \text{"master secret"}, \text{client.random} \parallel \text{server.random})
This 48-byte master secret then seeds the derivation of session keys for inner tunnel encryption via TLS-PRF expansions.[24] For integration with 802.1X environments like Wi-Fi, the protocol exports a Master Session Key (MSK) of 64 bytes from the master secret:
\text{MSK} = \text{TLS-PRF}(\text{master_secret}, \text{"client EAP encryption"}, \text{client.random} \parallel \text{server.random})[0..63]
The first 32 bytes of this MSK serve as the Pairwise Master Key (PMK) for deriving link-layer security keys, ensuring end-to-end protection from the authentication server to the authenticator.[24]