Article ID: 941123
Article Last Modified on 11/25/2007
APPLIES TO
- Windows Vista Ultimate
- Windows Vista Enterprise
- Windows Vista Business
- Windows Vista Home Premium
- Windows Vista Home Basic
- Windows Vista Starter
- Windows Vista Ultimate 64-bit Edition
- Windows Vista Enterprise 64-bit Edition
- Windows Vista Business 64-bit Edition
- Windows Vista Home Premium 64-bit Edition
- Windows Vista Home Basic 64-bit Edition
- Microsoft Windows Server 2003 R2 Datacenter Edition (32-Bit x86)
- Microsoft Windows Server 2003 R2 Datacenter x64 Edition
- Microsoft Windows Server 2003 R2 Enterprise Edition (32-Bit x86)
- Microsoft Windows Server 2003 R2 Enterprise x64 Edition
- Microsoft Windows Server 2003 R2 Standard Edition (32-bit x86)
- Microsoft Windows Server 2003 R2 Standard x64 Edition
- Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems
- Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
- Microsoft Windows Server 2003, Datacenter x64 Edition
- Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems
- Microsoft Windows Server 2003, Web Edition
- Microsoft Windows XP Professional
- Microsoft Windows XP Professional x64 Edition
- Microsoft Windows XP Home Edition
SUMMARY
This article describes scenarios in which potential risks may exist when you use Protected Extensible Authentication protocol (PEAPv0) on a computer that is running Windows Vista, Windows XP, Windows Server 2003, or Windows Server 2008 together with authentication servers. The article describes methods that you can use to limit or to possibly eliminate the risks.
MORE INFORMATION
Problem statement
Protected Extensible Authentication protocol (PEAPv0) is a Public Key Infrastructure (PKI)-based solution that is provided by Microsoft. This solution helps secure potentially vulnerable authentications against man-in-the-middle attacks and against password-based attacks. By default in Windows Vista and in Windows Server 2008, PEAPv0 is exposed to a potential risk through user interaction. This potential risk could enable a sophisticated man-in-the-middle attack. In this scenario, the attacker poses as the authentication server. Therefore, the attacker can bypass some added security that PEAPv0 provides. This vulnerability is exposed in the following situations:
- An entity obtains its PEAPv0 authentication by using an independent third-party root certification authority (CA) certificate. In this scenario, a malicious attacker could obtain a certificate that chains back to the same root CA. The authenticating computer is then exposed to this attacker because the authenticating computer already trusts this root CA.
- A certificate is issued by a root CA that is not already trusted by the authenticating computer. In this scenario, the user is exposed to a user interface (UI) that may be difficult for the user to understand. The UI lets the user decide to trust a root CA that is not already trusted by the authenticating computer. Therefore, this UI lets the user trust the attacker.
Problem details
PEAPv0 can be configured in two modes. "Partially configured mode" is susceptible to these vulnerabilities. "Fully configured mode" reduces these vulnerabilities. The following is a more detailed description of the two PEAPv0 configurations. Instructions are also included that explain how to help secure a deployment from the vulnerabilities that are described in the "Problem statement" section.
PEAPv0 can be configured in the following modes:
- Fully configured mode
In fully configured mode, administrators configure PEAPv0 so that the connection is permitted only with specified servers and with administrator-controlled Root Certificate Authorities.
In fully configured mode, PEAPv0 takes the following actions as part of server validation in phase 1 of the authentication process:
- PEAPv0 verifies that the server certificate is chained to a trusted root authority.
- PEAPv0 verifies that the server certificate appears in the NTAuth store or that is one of the root certificates that are selected in the Trusted Root Certificate Authorities list.
- PEAPv0 verifies that the name in the server certificate appears in the Connect to these servers list or that it matches the wildcard expression in the Connect to these servers list.
- Partially configured mode
In partially configured mode, the user provides the servers against which to authenticate and the Root Certificate Authorities that are to be trusted. By default, PEAPv0 uses partially configured mode. This results in the vulnerabilities that are described in the "Problem statement" section.
In partially configured mode, PEAPv0 takes the following actions as part of server validation in phase 1 of the authentication process:
- PEAPv0 verifies that the server certificate is chained to a trusted root authority.
- PEAPv0 verifies that the server certificate appears in the NTAuth store or that it is one of the root certificates that are selected in the Trusted Root Certificate Authorities list. If this validation fails, a dialog box prompts the user to verify that the root of the server’s certificate is to be trusted. If the user clicks OK, validation goes to the next step. Otherwise, validation fails.
- PEAPv0 verifies that the name on the server certificate appears in the Connect to these servers list or that it matches the wildcard expression in the Connect to these servers list. If this validation fails, a dialog box prompts the user to verify that the server is to be trusted. If user clicks OK, validation succeeds. Otherwise, validation fails.
Solutions
Each of following proposed solutions (Method 1, Method 2, and Method 3) can be applied separately or together with the other methods. All these methods require configuration of the client-side PEAPv0 properties. This configuration must be done for the specific network supplicant in question. For example, this configuration must be done for wireless, for wired 802.1X, and so on. Configuration changes can be made locally or by using Group Policy. The following examples assume that you are using a Windows Vista wireless network supplicant.
"PEAPv0 Properties" dialog box examples
To open the PEAPv0 Properties dialog box, follow the steps that are appropriate for your situation:
- Local configuration
- Open the Protected EAP Properties dialog box. To do this, click Start, click Connect to, and then click Show all connections.
- Right-click the wireless network icon, and then click Properties.
- Click the Authentication tab.
- In the EAP type box, select Protected EAP (PEAP).
- Click Properties.
- Group Policy configuration
- Open the Default Domain Policy in the Group Policy Management Console (GPMC) snap-in, expand Computer Configuration, expand Windows Settings, expand Security Settings, and then expand Wireless Network (IEEE 802.11) Policies. The group policies are listed in the details pane.
- Right-click the policy that you want to edit, and then click Properties.
- Click the Preferred Networks tab.
- Click the network name Service Set Identifier (SSID) that you want to edit, and then click Edit.
- Click the IEEE 802.1X tab.
- In the EAP type box, select Protected EAP (PEAP), and then click Settings.
Method 1: Limit the trusted root CAs that are available to the user
Overall, the best way to reduce these potential risks is to limit the trusted root CAs that are permitted for PEAPv0. To do this, click to clear the check boxes for all non-applicable CAs in the Trusted Root Certification Authorities list. This prevents the user from trusting new root CAs, because the user is presented with an explicit list of permitted authentication servers.
Method 2: Prevent the user from being prompted for certificate validation
PEAPv0 configuration includes an option that prevents the user from being prompted for certificate validation. This is the Do not prompt user to authorize new servers or trusted root certification authorities option. By default, this option is disabled. If you enable this option, the user is not presented with the UI that may be difficult for the user to understand. Therefore, the user cannot select an unapproved root certification authority.
To enable this option, follow these steps:
- In the Protected EAP Properties dialog box, click to select the Validate server certificate check box.
- Click to select the Do not prompt user to authorize new server or trusted certification authorities check box.
- Install the root certificate of the server in the NTAuth store, or click to select the root certificate in Trusted Root Certificate Authorities list.
If you cannot use this method, you can educate users to make sure that they reject the request to authorize any new servers or certification authority.
Method 3: Limit authentication servers
PEAPv0 configuration lets you limit the servers that can be trusted for an authentication. The Connect to these servers option uses a comma-delimited list of domain names to explicitly define the servers against which the client may authenticate. When you enable this option and use the strict list of accepted servers, this man-in-the-middle attack is much more difficult to execute. Or, this attack may be impossible to execute, depending on the specific PKI structure that your organization uses.
To enable the Connect to these servers option, follow these steps:
- In the Protected EAP Properties dialog box, click to select the Validate server certificate check box.
- Click to select the Connect to these servers check box.
- In the Connect to these servers box, type a list of all back-end authentication servers. Separate each server name with a semicolon. For example, type the following for the domain contoso.com and for authentication servers auth1 and auth2:
auth1.contoso.com; auth2.contoso.com
Keywords: kbinfo kbhowto KB941123
