Protected Extensible Authentication Protocol (PEAP) is part of the Extensible Authentication Protocol (EAP) protocols.

PEAP uses Transport Layer Security (TLS) to create an encrypted channel between an authenticating PEAP client, such as a wireless computer, and a PEAP authenticator, such as a server running Network Policy Server (NPS) or other Remote Authentication Dial-In User Service (RADIUS) server.

PEAP and NPS

PEAP does not specify an authentication method, but provides additional security for other EAP authentication protocols, such as Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (EAP-MS-CHAP v2), that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for access clients connecting to your organization network through the following types of network access servers:

  • 802.1X wireless access points

  • 802.1X authenticating switches

  • Virtual private network (VPN) servers running Windows Server® 2008 or Windows Server® 2008 R2 and the Routing and Remote Access service

  • Computers running Windows Server 2008 and Terminal Services Gateway (TS Gateway) or Windows Server® 2008 R2 and Remote Desktop Gateway (RD Gateway).

To enhance both the EAP protocols and network security, PEAP provides:

  • A TLS channel that provides protection for the EAP method negotiation that occurs between client and server. This TLS channel helps prevent an attacker from injecting packets between the client and the network access server to cause the negotiation of a less secure EAP type. The encrypted TLS channel also helps prevent denial-of-service attacks against the NPS server.

  • Support for the fragmentation and reassembly of messages, allowing the use of EAP types that do not provide this functionality.

  • Clients with the ability to authenticate the NPS server or other RADIUS server. Because the server also authenticates the client, mutual authentication occurs.

  • Protection against the deployment of an unauthorized wireless access point at the moment when the EAP client authenticates the certificate provided by the NPS server. In addition, the TLS master secret created by the PEAP authenticator and client is not shared with the access point. Because of this, the access point cannot decrypt the messages protected by PEAP.

  • PEAP fast reconnect, which reduces the delay between an authentication request by a client and the response by the NPS or other RADIUS server. PEAP fast reconnect also allows wireless clients to move between access points that are configured as RADIUS clients to the same RADIUS server without repeated requests for authentication. This reduces resource requirements for both client and server, and minimizes the number of times that users are prompted for credentials.

The following table lists the strengths of PEAP-MS-CHAP v2 and compares it to MS-CHAP v2.

Feature/function MS-CHAP v2 PEAP-MS-CHAP v2

Provides client authentication using passwords.

Yes

Yes

Ensures that the server has access to credentials.

Yes

Yes

Authenticates the server.

Yes

Yes

Prevents wireless access point spoofing.

No

Yes

Prevents an unauthorized server from negotiating the least secure authentication method.

No

Yes

Uses TLS keys generated with a public key.

No

Yes

Provides end-to-end encryption.

No

Yes

Prevents dictionary or brute force attacks.

No

Yes

Prevents replay attacks.

No

Yes

Allows chaining of authentication methods.

No

Yes

Requires client trust of certificates provided by the server.

No

Yes

PEAP authentication process

There are two stages in the PEAP authentication process between the PEAP client and the authenticator. The first stage establishes a secure channel between the PEAP client and the authenticating server. The second stage provides EAP authentication between the PEAP client and authenticator.

TLS encrypted channel

In the first stage of PEAP authentication, the TLS channel is created between the PEAP client and the NPS server. The following steps illustrate how this TLS channel is created for wireless PEAP clients.

  1. The PEAP client associates with a wireless access point that is configured as a RADIUS client to a server running NPS. An IEEE 802.11-based association provides an Open System or Shared Key Authentication before a secure association is created between the PEAP client and the access point.

  2. After the IEEE 802.11-based association is successfully established between the client and access point, the TLS session is negotiated with the access point.

  3. After computer-level authentication is successfully completed between the wireless PEAP client and the NPS server, the TLS session is negotiated between them. The key that is derived during this negotiation is used to encrypt all subsequent communication, including network access authentication that allows the user to connect to the organization network.

EAP-authenticated communication

Complete EAP communication, including EAP negotiation, occurs through the TLS channel and is the second stage of PEAP authentication. The following steps extend the previous example and illustrate how wireless clients complete authentication with the NPS server using PEAP.

After the TLS channel is created between the NPS server and the PEAP client, the client passes the credentials (user name and password or a user or computer certificate) to the NPS server through the encrypted channel.

The access point only forwards messages between wireless client and RADIUS server; the access point (or a person monitoring it) cannot decrypt these messages because it is not the TLS endpoint.

The NPS server authenticates the user and client computer with the authentication type that is selected for use with PEAP. The authentication type can be either EAP-TLS (smart card or other certificate) or EAP-MS-CHAP v2 (secure password).

Note

You can configure PEAP as the authentication method in NPS network policy.

EAP types

You can choose between two EAP types, also called authentication types, for use with PEAP: EAP-MS-CHAP v2 or EAP-TLS. EAP-MS-CHAP v2 uses password-based credentials (user name and password) for user authentication, and a certificate in the server computer certificate store for server authentication. EAP-TLS uses either certificates installed in the client computer certificate store or a smart card for user and client computer authentication, and a certificate in the server computer certificate store for server authentication.

PEAP with EAP-MS-CHAP v2

PEAP with EAP-MS-CHAPv2 (PEAP-MS-CHAP v2) is easier to deploy than EAP-TLS because user authentication is accomplished by using password-based credentials (user name and password) instead of certificates or smart cards. Only the NPS server or other RADIUS server is required to have a certificate. The NPS server certificate is used by the NPS server during the authentication process to prove its identity to PEAP clients.

Successful PEAP-MS-CHAP v2 authentication requires that the client trust the NPS server after examining the server certificate. For the client to trust the NPS server, the certification authority (CA) that issued the server certificate must have its own different certificate in the Trusted Root Certification Authorities certificate store on client computers.

The server certificate used by NPS can be issued by either the trusted root CA of your organization or by a public CA, such as VeriSign or Thawte, that is already trusted by the client computer.

Note

PEAP-MS-CHAP v2 provides greatly improved security over MS-CHAP v2 by providing key generation with TLS and by using mutual authentication, which prevents an unauthorized server from negotiating the least secure authentication method with the PEAP client.

PEAP with EAP-TLS

When you deploy a public key infrastructure (PKI) with Active Directory Certificate Services (AD CS), you can use PEAP with EAP-TLS (PEAP-TLS). Certificates provide a much stronger authentication method than the methods that use password-based credentials. PEAP-TLS uses certificates for server authentication and either smart cards, which contain an embedded certificate, or certificates enrolled to client computers that are stored on the local computer in the certificate store, for user and client computer authentication. To use PEAP-TLS, you must deploy a PKI.

PEAP fast reconnect

PEAP fast reconnect enables wireless clients to move between wireless access points on the same network without being reauthenticated each time they associate with a new access point.

Wireless access points are configured as RADIUS clients to RADIUS servers. If a wireless client roams between access points that are configured as clients to the same RADIUS server, the client is not required to be authenticated with each new association. When a client moves to an access point that is configured as a RADIUS client to a different RADIUS server, although the client is reauthenticated, this process occurs much more efficiently and quickly.

PEAP fast reconnect reduces the response time for authentication between client and authenticator because the authentication request is forwarded from the new access point to the NPS server that originally performed authentication and authorization for the client connection request. Because both the PEAP client and NPS server use previously cached TLS connection properties (the collection of which is named the TLS handle), the NPS server can quickly determine that the client connection is a reconnect.

The client can cache TLS handles for multiple PEAP authenticators. If the original NPS server is unavailable, full authentication must occur between the client and the new authenticator. The TLS handle for the new PEAP authenticator is cached by the client. For smart cards or PEAP-MS-CHAP v2 authentication, the user is asked to supply the PIN or credentials, respectively.

With PEAP-MS-CHAP v2 authentication:

When the new access point is a client to the same RADIUS server When the new access point is a client to a new RADIUS server

The user is not prompted for credentials each time the client computer associates with a new access point.

The user is prompted for credentials on this initial association. The next time the client computer associates with an access point that is a client to this server, user credentials are not required.

The RADIUS server is not required to provide a certificate.

The RADIUS server provides a certificate on this initial association so that the wireless client can authenticate to the RADIUS server. The next time the client computer associates with an access point that is a client to this server, the server is not required to be reauthenticated.

With PEAP-TLS authentication:

When the new access point is a client to the same RADIUS server When the new access point is a client to a new RADIUS server

The client and server are not required to exchange certificates.

The client and server exchange certificates on this initial association. The next time the client computer associates with an access point that is a client to this server, certificates are not exchanged.

The user is not prompted for a smart card personal identification number (PIN) each time the client computer associates with a new access point.

The user is prompted for a smart card PIN on this initial association. The next time the client computer associates with an access point that is a client to this server, the user is not prompted for the PIN.

To enable PEAP fast reconnect:

  • Both the PEAP client (802.11 wireless client) and PEAP authenticator (RADIUS server) must have fast reconnect enabled.

  • All access points to which the PEAP client roams must be configured as RADIUS clients to a RADIUS server (the PEAP authenticator) for which PEAP is configured as the authentication method for wireless connections.

  • All access points to which the PEAP client associates must be configured to prefer the same RADIUS server (PEAP authenticator) to avoid being prompted for credentials from every RADIUS server. If the access point cannot be configured to prefer a RADIUS server, you can configure an NPS RADIUS proxy with a preferred RADIUS server.

Additional information
  • PEAP does not support guest authentication.

  • When you deploy both PEAP and EAP unprotected by PEAP, do not use the same EAP authentication type with and without PEAP. For example, if you deploy PEAP-TLS, do not also deploy EAP-TLS without PEAP. Deploying authentication methods with the same type creates a security vulnerability.


Table Of Contents