Microsoft security advisory: Vulnerability in IPsec could allow security feature bypass

1: Purpose of this security update

The security update strengthens how the identity of remote IPsec servers is validated if there is a remote connection from an IPsec client. The installation of this update is a three-step process. The process is outlined in this section and is documented in detail in this article.

To install this update, follow these steps:

1. Install the update on the client system that improves remote server validation. The update remains disabled after installation until the administrator follows step 2 and manually enables the update. (This is described in section 4.1.) If there is a client-to-gateway configuration, the update should be installed on the client computer. If there is a site-to-site configuration, both communication remote servers should receive the installation.
2. Update the certificate on the server whose identity has to be validated according to the new validation rules. (This is described in the "Deployment instructions" section.)
3. Update the registry on the validation computers to include the new validation rules. As soon as these rules are set in the registry, the update automatically starts enforcing the new rules while it establishes a tunnel with the remote party.

Note This update is applicable only for tunnel-mode connections. Transport-mode connections are not affected.

2: Who should install this security update?

Enterprise administrators who have the following configurations should consider updating their remote client and servers for improved security:

• DirectAccess with certificate-based AuthIP
  In this configuration, the update has to be installed on Windows 7-based client computers. The server whose certificate has to be updated in the configuration can be running Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2.
  
  This update will not have any effect if it is installed on a Windows 8 certificate-based deployment.
• DirectAccess with KerbProxy authentication AuthIP
  In this configuration, the update has to be installed on Windows 8-based or Windows 8.1-based client computers. No changes are required on the server.
• IPsec with certificate-based authentication
  This is the most versatile configuration. It may be configured as client-to-gateway or as site-to-site.

Important note: For certificate-based authentication (IPsec or DirectAccess):

•  Site-to-site: Windows Server 2012 and Windows Server 2012 R2 don’t have to be patched because the in-box certificate checks are sufficient.
•  Client to Gateway: Windows 8 and Windows 8.1 don’t have to be patched because the in-box certificate checks are sufficient.

For more information about how to configure certificate checks in Windows 8, 8.1, Server 2012, and Server 2012 R2, see the following Microsoft TechNet article:

3: Deployment scenarios

3.1: IPsec client to gateway

A typical client-to-gateway configuration is depicted in this section. The update will improve the check that computer C1 does on the validity of server R1.

3.2: IPsec site to site

A common traffic-triggered IPsec site-to-site tunnel is depicted here. Server R1 and server R2 will have to have this update and its related configuration in order to enforce more rigorous checks on other servers’ validity.

4: Deployment instructions

4.1: Description of the security update

As part of security update 2862152, IPsec enforces more checks in IPsec negotiation in certificate authentication methods (for Windows 7, Windows Server 2008 R2, Windows XP, and Windows Server 2003) and KerbProxy authentication (for Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012). During IPsec negotiation, IPsec also checks the listed attributes against the registry-configured values as follows:

Windows 7 and earlier operating systems

• If only the IP address and the EKU are configured, IPsec checks for destination IP address and EKU object identifier (also known as OID).
• If only the IP address and DNS are configured, IPsec checks for destination IP address and DNS (certificate) name.
• If the IP address, DNS, and EKU are configured, IPsec checks for destination IP address and EKU object identifier.

Notes

• DNS (certificate) s the certificate name on the server (or responder side).
• EKU object identifier is the Extended Key Usage identifier that is in the server certificate.

Windows 8 and Windows 8.1

• Destination IP address and SPN values
  
  The service principal name (SPN) is generally in the following format:
  
  host/<ComputerName>.<ComputerDomain>.com
  Administrators must provide the valid IP, DNS names/EKU object identifiers (in Windows 7 or earlier operating systems), or valid IP address and SPN values (in Windows 8 and later versions) through registry settings. Each keying module will have a separate registry that will have a subkey for each authentication method.
  
  The same settings can also be configured on the responder computer to help secure the responder. This is applicable only for Windows 7 and earlier versions. 
  
  In Windows 8 and later versions, only the initiator computer can be configured. The responder cannot be configured.

4.2: Certificate deployment - Windows 7 and earlier versions

4.2.1 IPsec scenario

4.2.1.1 EKU configuration on the client:

• If your IPsec client already has a certificate that has an EKU, you do not have to update or redeploy a new certificate on the IPsec client system. On the IPsec server, a new certificate with the EKU is set to be deployed.
  
  Note This certificate has to be chained to the same root certification authority (CA) that was configured in the IPsec policy. Configure this new EKU in the client's registry settings.
• Certificates that do not have an EKU are considered as "all-purpose certificates." When such certificates are used with this update, the new EKU checks will not be enforced. If you still want to enforce checks against a certificate, configure only DNS settings.

4.2.1.2 DNS configuration on the client:

• If you want to use DNS-based validations, you can configure the DNS name (certificate name) of the server certificate in the client's registry settings.
  
  Note If EKU is configured, DNS settings will not be considered. Therefore, if you want to use DNS-based validations, configure only DNS settings.

4.2.2 Site-to-site scenario

4.2.2.1 EKU configuration:

• If your initiator or responder already has a certificate that has an EKU, you do not have to update or redeploy any certificate on the initiator or responder. Just configure the peer certificate's EKU in the registry settings on both ends.
• If your initiator or responder certificate has no EKU, this means that it is an "all-purpose certificate" and that the new EKU checks will not be enforced. If you still want to enforce checks against a certificate, configure only DNS settings.

4.2.2.2 DNS configuration:

• If you want to use DNS-based validations, you can configure the DNS name (certificate name) of the peer certificate in the registry on both sides.
  
  Note If EKU is configured, DNS settings will not be considered. Therefore, if you want to use DNS-based validations, configure only DNS settings.

4.3: Registry settings in Windows 7, Windows Server 2008 R2, Windows Vista, and Windows Server 2008

The validations will be enabled only when the registry keys are configured.

Note The validation will be forced even if the registry key has no value or data.

• 4.3.1: Certification authentication by using AuthIP

  • Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\Cert
  • Registry name: This can be any name (for example, Tunnel1).
  • Type: REG_MULTI_SZ
  • Data: <IPv4Address or IPv6Address> <DNS1> <DNS2> <DNS3> <custom EKU OID>
  Data separators can be "space" or "tab" or "new line." For example, the data can also be configured as follows:
  
  Data: <IPv4Address or IPv6Address>
  
  <DNS1>
  <DNS2>
  <DNS3>
  <custom EKU OID>
  
  The custom EKU OID should be configured by using the "EKU:" prefix format as shown in the following:
  EKU:<EKU OID>
  
  
  The registry can have more than one registry name:
  
  • Registry name: This can be any name (for example, Tunnel2).
  • Type: REG_MULTI_SZ
  • Data: <IPv4Address or IPv6Address> <DNS4> <DNS5> <DNS6> <custom EKU OID>

• 4.3.2: Certification authentication by using IKEv1

  • Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\IKEV1\Cert
  • Registry name: This can be any name (for example, Tunnel1).
  • Type: REG_MULTI_SZ
  • Data: <IPv4Address or IPv6Address> <DNS1> <DNS2> <DNS3> <custom EKU OID>
  
  Data separators can be "space" or "tab" or "new line." For example, the data can also be configured as follows:
  
  Data: <IPv4Address or IPv6Address>
  
  <DNS1>
  <DNS2>
  <DNS3>
  <custom EKU OID>
  
  The custom EKU OID should be configured by using the "EKU:" prefix format as shown in the following:
  EKU:<EKU OID>
  
  
  The registry can have more than one registry name:
  
  • Registry Name: This can be any name (for example, Tunnel2).
  • Type: REG_MULTI_SZ
  • Data: <IPv4Address or IPv6Address> <DNS4> <DNS5> <DNS6> <custom EKU OID>
  Each entry can have no more than 10 DNS names and only one custom EKU specified.
  
  The maximum number of DNS names configured per entry is 10.
  
  Note If the size of the entry exceeds 16,384 characters, that entry will be ignored. This includes the IP address size and EKU size.
  
  Only one EKU can be considered per tunnel destination (for example, per IP). The search is iterative. If there are more than one "IP" entries configured, the first configured EKU for that IP address entry will be considered for validation.
  
  The maximum number of tunnels that can be configured under the registry path is 1,024.
  
  Notes
  • "IP" values must be configured. Administrators can configure either DNS or EKU based on their needs.
  • If only EKU is configured, we validate the EKU that is present in the peer certificate and enable or disallow authentication based on the validation result.
  • If only DNS name is configured, we validate only the subjectAltName present in the certificate and enable or disallow authentication based on the validation result.
  • If EKU and DNS are configured, we validate only EKU and enable or disallow authentication based on the validation.

DNS approach:

• You can specify any string in the Name field.
• If your server has an IPv6 address, you can specify the same IPv6 address instead of the IPv4 address.

EKU approach:

4.4: Registry settings in Windows XP and Windows Server 2003

The validations will be enabled only when the registry keys are configured.

Note The validations will be forced even if the registry keys have no value or data.

4.4.1: Certification authentication by using Oakley

• Registry key: HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley\Cert
• Registry name: This can be any name (for example, Tunnel1).
• Type: REG_MULTI_SZ
• Data: <IPv4Address> <DNS1> <DNS2> <DNS3> <custom EKU OID>
  
  Data separators can be "space" or "tab" or "new line." For example, the data can also be configured as follows:
  
  Data: <IPv4Address>
  
  <DNS1>
  <DNS2>
  <DNS3>
  <custom EKU OID>
  
  The custom EKU OID should be configured by using the "EKU:" prefix format as shown in the following:
  EKU:<EKU OID>
  
  
  The registry can have more than one registry name:

• Registry name: This can be any name (for example, Tunnel2).
• Type: REG_MULTI_SZ
• Data: <IPv4Address> <DNS4> <DNS5> <DNS6> <custom EKU OID>

The IP address is the address of the tunnel destination and should be the first string in the entry.

Each entry can have no more than 10 DNS names and only one custom EKU specified.

The maximum number of DNS names configured per entry is 10.


Note If the size of the entry exceeds 16,384 characters, that entry will be ignored. This includes the IP address size and EKU size.

Only one EKU can be considered per a tunnel destination (for example, per IP). The search is iterative. If there are more than one "IP" entries configured, the first configured EKU for that IP address entry will be considered for validation.

The maximum number of tunnels that can be configured under the registry path is 1,024.

Notes

• "IP" values must be configured. Administrators can configure either DNS or EKU based on their needs.
• If only EKU is configured, we validate the EKU present in the peer certificate and allow for or disallow authentication based on the validation result.
• If only DNS name is configured, we validate only the subjectAltName present in the certificate and allow for or disallow authentication based on the validation result.
• If both are configured, we validate only EKU and allow for or disallow authentication based on the validation.
  
  

DNS approach:

• You can specify any string in the Name field.
• If your server has an IPv6 address, you can specify the same IPv6 address instead of the IPv4 address.

EKU approach:

4.5: Windows 8 and Windows 8.1

Validations will be enabled only if the registry key is configured. Be aware that the checks will be enforced by just adding the key even without any registry values or data.

4.5.1: KerbProxy authentication by using AuthIP:

• Registry key: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters\IPsecTunnelConfig\AuthIP\kerberos
• Registry name: This can be any string (for example, Tunnel1).
• Type: REG_MULTI_SZ
• Data: <IPv4Address or IPv6Address> <SPN1> <SPN2> <SPN3>
  
  Data separators can be "space" or "tab" or "new line." For example, the data can also be configured as follows:
  
  Data: <IPv4Address or IPv6Address>
  
  <SPN1>
  <SPN2>
  <SPN3>
  
  
  The registry can have more than one registry name:
  

• Registry name: This can be any string (for example, Tunnel2).
• Type: REG_MULTI_SZ
• Data: <IPv4Address or IPv6Address> <SPN4> <SPN5> <SPN6>

The IP address is the address of the tunnel destination and should be the first string in the entry.

The maximum number of SPNs configured per entry is 10.


Note If the size of the entry (including the IP address size) exceeds 16,384 characters, that entry will be ignored. The maximum number of tunnels that can be configured under the registry path is 1,024.

SPN approach:

• You can specify any string in the Name field.
• If your server has an IPv6 address, you can specify the same IPv6 address instead of the IPv4 address.

5: Troubleshooting

If IPsec connection failures occur, follow these steps to troubleshoot the issue:

1. Make sure that the correct configuration is performed as described in the earlier sections.
2. Examine the event logs to determine whether the failure is thrown at the initiator or the responder.
3. In Windows 8 and later versions, there are no changes on the responder side. So, the failure can only be from the initiator. If a failure occurs, IKE traces will show a message that resembles the following in the log:
   
   
   AuthIP peer SPN did NOT match configured SPN
4. In Windows 7 and earlier versions, the failure can be generated from the initiator or the responder.

If there are initiator-side failures, the following events are logged.


If there are responder-side failures, the following events are logged:

IKE traces

1. Enable the IKE tracing, and reproduce the issue.
2. Stop the IKE tracing.
3. Share the Ikeext.etl file from C:\windows\system32 to the Microsoft support team.

If there are failures, IKE traces will display the following logs.

Failure because of EKU:

• Peer certificate custom EKU did NOT match with configured EKU for AUTHIP
• Peer certificate custom EKU did NOT match with configured EKU for IKE

Failure because of Cert:

• IKE peer certificate DNS Name did NOT matched with configured DNS names
• AUTHIP peer certificate DNS Name did NOT match with configured DNS names

Windows XP and Windows Server 2003

Oakley logs help identify the cause of IPsec-related failures.

To enable IPsec logging, at a command prompt, type the following command, and then press Enter:
Then, to reproduce the failure case, type the following command:
The Oakley log is generated in the following folder:
If there are failures, IKE traces will display the following logs.

Failure because of EKU:

• Peer certificate custom EKU did NOT matched with configured EKU for IKEv1

Failure because of Cert:

• Peer certificate DNS Name did NOT match with configured DNS name for IKEv1

Note In the message information listed here, "did NOT matched" is a typographic error that appears in the code.