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

INTRODUCTION

Microsoft has released a Microsoft security advisory about this issue for IT professionals. The security advisory contains additional security-related information. To view the security advisory, go to the following Microsoft website:

Resolution

The following files are available for download from the Microsoft Download Center:


For all supported x86-based versions of Windows XP

Download Download the package now.

For all supported x64-based versions of Windows XP Professional x64 edition

Download Download the package now.

For all supported x86-based versions of Windows Server 2003

Download Download the package now.

For all supported x64-based versions of Windows Server 2003

Download Download the package now.

For all supported IA-64-based versions of Windows Server 2003

Download Download the package now.

For all supported x86-based versions of Windows Vista

Download Download the package now.

For all supported x64-based versions of Windows Vista

Download Download the package now.

For all supported x86-based versions Windows Server 2008

Download Download the package now.

For all supported x64-based versions of Windows Server 2008

Download Download the package now.

For all supported IA-64-based versions of Windows Server 2008

Download Download the package now.

For all supported x86-based versions of Windows 7

Download Download the package now.

For all supported x64-based versions of Windows 7

Download Download the package now.

For all supported x86-based versions of Windows 7 Embedded

Download Download the package now.

For all supported x64-based versions of Windows 7 Embedded

Download Download the package now.

For all supported x64-based versions of Windows Server 2008 R2

Download Download the package now.

For all supported IA-64-based versions of Windows Server 2008 R2

Download Download the package now.

For all supported x86-based versions of Windows 8

Download Download the package now.

For all supported x64-based versions of Windows 8

Download Download the package now.

For all supported x64-based versions of Windows Server 2012

Download Download the package now.

For all supported x86-based versions of Windows 8.1

Download Download the package now.

For all supported x64-based versions of Windows 8.1

Download Download the package now.

For all supported x64-based versions of Windows Server 2012 R2

Download Download the package now.

Release Date: November 10, 2013

For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base:
119591 How to obtain Microsoft support files from online services
Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.

More Information

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.
ScenarioProtocolAuthentication methodInstallation typePlatforms to be patched
IPsecIKEv1Certificate basedSite-to-site (for example, RRAS)Win 2003, Windows Server 2008, Windows Server 2008 R2
Client-to-serverWindows XP, Windows Vista, Windows 7
DirectAccessAuthIPCertificate basedClient-to-server (For example, DirectAccess)Windows 7
KerbProxyClient-to-server (For example, DirectAccess)Windows 8, Windows 8.1
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.
IPsec tunnel

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.
IPsec tunnel

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.
Figure 2. AuthIP (or IKEv1) Cert Based Registry settings - DNS approach

EKU approach:

Figure 3. AuthIP (or IKEv1) Cert Based Registry settings - 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.
 Figure 4. IKEv1 Cert Based Registry settings - DNS approach

EKU approach:

Figure 5. IKEv1 Cert Based Registry settings – 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.
Figure 1: AuthIP KerbProxy Based Registry settings - SPN approach

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.


Failure caseInitiatorResponder
IKEv1 An IPsec main mode negotiation failed. An IPsec main mode security association was established. Extended mode was not enabled. A certificate was used for authentication.
An IPsec main mode security association ended.
AuthIP An IPsec main mode negotiation failed. An IPsec main mode negotiation failed.
If there are responder-side failures, the following events are logged:


Failure caseInitiatorResponder
IKEv1 An IPsec main mode security association was established. Extended mode was not enabled. A certificate was used for authenticationAn IPsec main mode security association was established. Extended mode was not enabled. A certificate was used for authentication.
An IPsec quick mode negotiation failed. An IPsec main mode security association ended.
An IPsec main mode security association ended. An IPsec quick mode negotiation failed.
AuthIP An IPsec main mode negotiation failed. An IPsec extended mode negotiation failed. The corresponding main mode security association has been deleted.
An IPsec extended mode negotiation failed. The corresponding main mode security association has been deleted.

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:
Netsh IPsec dynamic set config ikelogging 1
Then, to reproduce the failure case, type the following command:
Netsh IPsec dynamic set config ikelogging 0
The Oakley log is generated in the following folder:
C:\winodws\Debug
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.

References

For more information about IPsec, go to the following Microsoft webpage:
For more information about CA, see the Advanced Deployment Guide webpage:
For more information about how to deploy a single remote access server, go to the following Microsoft Basic Remote Access deployment webpage:
For more information about site-to-site VPN, go to the following Microsoft Test Lab Guide webpage:

FILE INFORMATION

The English (United States) version of this software update installs files that have the attributes that are listed in the following tables. The dates and times for these files are listed in Coordinated Universal Time (UTC). The dates and times for these files on your local computer are displayed in your local time and with your current daylight saving time (DST) bias. Additionally, the dates and times may change when you perform certain operations on the files.

Windows XP and Windows Server 2003 file information
Windows Vista and Windows Server 2008 file information
Windows 7 and Windows Server 2008 R2 file information
Windows 8 and Windows Server 2012 file information
Windows 8.1 and Windows Server 2012 R2 file information
File hash information
Properties

Article ID: 2862152 - Last Review: Jul 10, 2014 - Revision: 1

Windows RT 8.1, Windows 8.1, Windows 8.1 Enterprise, Windows 8.1 Pro, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Essentials, Windows Server 2012 R2 Foundation, Windows Server 2012 R2 Standard, Windows RT, Windows 8, Windows 8 Enterprise, Windows 8 Pro, Windows Server 2012 Datacenter, Windows Server 2012 Datacenter, Windows Server 2012 Datacenter, Windows Server 2012 Datacenter, Windows Server 2012 Essentials, Windows Server 2012 Foundation, Windows Server 2012 Foundation, Windows Server 2012 Foundation, Windows Server 2012 Foundation, Windows Server 2012 Standard, Windows Server 2012 Standard, Windows Server 2012 Standard, Windows Server 2012 Standard, Windows 7 Service Pack 1, Windows 7 Enterprise, Windows 7 Professional, Windows 7 Ultimate, Windows 7 Home Premium, Windows 7 Home Basic, Windows Server 2008 R2 Service Pack 1, Windows Server 2008 R2 Standard, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Datacenter, Windows Server 2008 Service Pack 2, Windows Server 2008 for Itanium-Based Systems, Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Standard, Windows Web Server 2008, Windows Vista Service Pack 2, Windows Vista Business, Windows Vista Enterprise, Windows Vista Home Basic, Windows Vista Home Premium, Windows Vista Starter, Windows Vista Ultimate, Windows Vista Enterprise 64-bit Edition, Windows Vista Home Basic 64-bit Edition, Windows Vista Home Premium 64-bit Edition, Windows Vista Ultimate 64-bit Edition, Windows Vista Business 64-bit Edition, Microsoft Windows Server 2003 Service Pack 2, Microsoft Windows Server 2003, Standard Edition (32-bit x86), Microsoft Windows Server 2003, Enterprise Edition (32-bit x86), Microsoft Windows Server 2003, Datacenter Edition (32-bit x86), Microsoft Windows Server 2003, Web Edition, Microsoft Windows Server 2003, Datacenter x64 Edition, Microsoft Windows Server 2003, Enterprise x64 Edition, Microsoft Windows Server 2003, Standard x64 Edition, Microsoft Windows XP Professional x64 Edition, Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems, Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems, Microsoft Windows XP Service Pack 3, Microsoft Windows XP Home Edition, Microsoft Windows XP Professional

Feedback