PEAP

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

PEAP

Protected Extensible Authentication Protocol (PEAP) is a new member of the family of Extensible Authentication Protocol (EAP) protocols. PEAP uses Transport Level Security (TLS) to create an encrypted channel between an authenticating PEAP client, such as a wireless computer, and a PEAP authenticator, such as an Internet Authentication Service (IAS) or Remote Authentication Dial-In User Service (RADIUS) server. PEAP does not specify an authentication method, but provides additional security for other EAP authentication protocols, such as EAP-MSCHAPv2, that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for 802.11 wireless client computers, but is not supported for virtual private network (VPN) or other remote access clients.

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

• Protection for the EAP method negotiation that occurs between client and server through a TLS channel. This helps prevent an attacker from injecting packets between the client and the network access server (NAS) to cause the negotiation of a less secure EAP method. The encrypted TLS channel also helps prevent denial of service attacks against the IAS server.

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

• Wireless clients with the ability to authenticate the IAS or RADIUS server. Because the server also authenticates the client, mutual authentication occurs.

• Protection against the deployment of an unauthorized wireless access point (WAP) when the EAP client authenticates the certificate provided by the IAS 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 in time between an authentication request by a client and the response by the IAS or RADIUS server, and allows wireless clients to move between access points without repeated requests for authentication. This reduces resource requirements for both client and server.

PEAP authentication process

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

TLS encrypted channel

The wireless client associates with a wireless access point. An IEEE 802.11-based association provides an Open System or Shared Key Authentication before a secure association is created between the client and access point. 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. After authentication is successfully completed between the wireless client and the server (for example, an IAS server), the TLS session is negotiated between them. The key that is derived during this negotiation is used to encrypt all subsequent communication.

EAP-authenticated communication

Complete EAP communication, including EAP negotiation, occurs through the TLS channel. The IAS server authenticates the user and client computer with the method that is determined by the EAP type and selected for use within PEAP (either EAP-TLS or EAP-MS-CHAPv2). 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 end point.

802.11 wireless deployments using PEAP

You can choose between two EAP types for use with PEAP: EAP-MS-CHAPv2 or EAP-TLS. EAP-MS-CHAPv2 uses 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-CHAPv2

PEAP with EAP-MS-CHAPv2 (PEAP-EAP-MS-CHAPv2) is easier to deploy than EAP-TLS because user authentication is accomplished with password-based credentials (user name and password) instead of certificates or smart cards--only the IAS or RADIUS server is required to have a certificate. Additionally, the server certificate can be issued by a public certification authority (CA) that is trusted by the client computer (that is, the public CA certificate already exists in the Trusted Root Certification Authority folder on the client computer certificate store). In this case, the server certificate is not downloaded and added to the client trusted root certificate store, and the user is not prompted to make a decision about whether to trust the server.

PEAP-EAP-MS-CHAPv2 provides improved security over MS-CHAPv2 by using mutual authentication, preventing an unauthorized server from negotiating the least secure authentication method, and providing key generation with TLS. PEAP-EAP-MS-CHAPv2 requires that the client trust certificates provided by the server.

For server and client computer certificate requirements, see Network access authentication and certificates. For an example wireless access policy using PEAP-EAP-MS-CHAPv2, see Wireless access with secure password authentication.

PEAP with EAP-TLS

Public Key certificates provide a much stronger authentication method than those that use password-based credentials. PEAP with EAP-TLS (PEAP-EAP-TLS) uses certificates for server authentication and either certificates or smart cards for user and client computer authentication. To use PEAP-EAP-TLS, you must deploy a public key infrastructure (PKI).

For more information, see Network access authentication and certificates.

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.

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

If the original PEAP authenticator is unavailable, full authentication must occur between the client and the new authenticator. The new PEAP authenticator's TLS handle is cached by the client. The client can cache TLS handles for multiple PEAP authenticators. For smart carts or PEAP-EAP-MSCHAPv2 authentication, the user is asked to supply the PIN or credentials, respectively.

With PEAP-EAP-MS-CHAPv2 authentication:

With PEAP-EAP-TLS authentication:

For more information about RADIUS clients, see Components of a RADIUS infrastructure.

For more information about RADIUS proxy servers, see IAS as a RADIUS proxy.

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) in order 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 IAS RADIUS proxy with a preferred RADIUS server.

For more information, see Configure PEAP and EAP methods.

Notes

• When using the PEAP-EAP-TLS and EAP-TLS authentication methods with certificates, TLS uses cached certificate properties instead of reading the certificate from the certificate store. If a certificate is either changed or deleted and replaced by a new one, TLS continues using outdated cached certificate information until the cache expires or is refreshed. If you change or replace a certificate, you can refresh the TLS cache by restarting the server computer.

• PEAP does not support guest authentication, which has a blank user name and password.

• 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 with EAP-TLS (PEAP-EAP-TLS), do not also deploy EAP-TLS without PEAP. Deploying authentication methods with the same type -- one with and the other without the protection of PEAP -- creates a security vulnerability.

• You can configure IAS in Windows Server 2003, Standard Edition, with a maximum of 50 RADIUS clients and a maximum of 2 remote RADIUS server groups. You can define a RADIUS client using a fully qualified domain name or an IP address, but you cannot define groups of RADIUS clients by specifying an IP address range. If the fully qualified domain name of a RADIUS client resolves to multiple IP addresses, the IAS server uses the first IP address returned in the DNS query. With IAS in Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, you can configure an unlimited number of RADIUS clients and remote RADIUS server groups. In addition, you can configure RADIUS clients by specifying an IP address range.