Introduction to Windows IPSec

Brief Introduction

When you create an IPSec policy, you need to configure the IPSec rules that determine the behavior of IPSec and the settings that are not applied to the configured rules. After you configure the IPSEC policy, you must assign the policy to a computer to enforce the policy. Although multiple IPSec policies can exist on a single computer, one IPSec policy can only be assigned to a single computer at a time.

IPSec rules determine which types of traffic the IPSec must check for, whether to allow traffic, block traffic, or negotiate security, how to authenticate IPSec peers, and other settings. When you configure an IPsec rule, you can configure a filter list that contains one or more filters, filter actions, authentication methods, connection types, and IPsec encapsulation modes (transfer mode or tunnel mode). IPSEC rules are typically configured for a specific purpose (for example, "Block all inbound traffic from the Internet to TCP port 135").

The filter defines the traffic to check (this is similar to a firewall rule) and the source and destination IP addresses, protocols, and port numbers, if applicable. The filter action defines the security requirements for the network traffic flow. You can configure filter actions to allow traffic, block traffic, or negotiate security (Negotiate IPsec). If the filter action is configured to negotiate security, you must also configure various key exchange security measures (and the precedence of these methods), whether to accept the unsecured traffic that was originally passed in, whether to allow unsecured communication with non-IPSEC-enabled computers, and whether to use full forward secrecy (PFS).

Key exchange settings and key exchange security measures determine the IPSEC protocol line format (authentication Header (AH) or Encapsulating Security Payload (ESP)), encryption and hashing algorithms, key lifetimes, and the necessary to configure Internet Key Association (IKE) main mode and IPSEC Security Association (SA) He set. SA is the security settings protocol associated with the key data. The SA that was created during the first IKE negotiation phase is called the IKE main mode SA (also known as the ISAKMP main mode SA). The IKE main mode SA protects the IKE negotiation itself. The SA that was created during the second IKE negotiation phase is called an IPSec SA (also known as IKE quick mode SA because each IKE quick mode negotiation carries out IPsec SA negotiation for each direction). The IPsec SA protects the application traffic.

This section provides information about the following important IPsec policy concepts:

•	IKE negotiation Process
•	IPSEC Policy Filter
•	Security
•	IPSEC Protocol Line format
•	IKE Authentication
•	IKE authentication methods and security order precedence
•	Security negotiation Options

For more information about IPSEC policy concepts, see the Microsoft Windows server™2003 Help and Support Center. Back to the top of the page

IPsec Policy Filter

Filters are the most important component of an IPsec policy. If you do not specify the correct filter in the client policy or server policy, or if the IP address has changed, but the filter for that policy has not been updated, security is not guaranteed. IPsec filters are inserted into the IP layer of the TCP/IP network protocol stack on the computer, so these filters can be checked (filtered) for all inbound or outbound IP packets. IPsec is transparent to end user applications and operating system services, in addition to a slight delay (which inevitably causes delays in negotiating security relationships between two computers). The filter is associated with the corresponding filter action based on the security rules in the IPSEC policy. Windows IPSec also supports the option of using IPSec tunneling mode and IPSec transport mode as this rule. The configuration of IPSec tunneling pattern rules differs greatly from the configuration of IPSec transport mode rules.

The filtering rules associated with IPSEC policy are similar to firewall rules. By using the IP security policy to manage the graphical user interface (GUI) provided by the Microsoft Management Console (MMC) snap-in, IPsec can be configured to allow or block specific types of traffic based on the combination of source and destination addresses and specific protocols and ports.

Note: Windows IPsec is not a full-featured and host-based firewall, nor does it support dynamic filtering or stateful filtering, such as tracking established bits during a TCP handshake to control the flow of traffic that can flow. Understanding IPSEC Filtering

The filter list is just a list of known subnets and infrastructure IP addresses. It is important that you understand how all of the filters included in all the rules are grouped together to provide the required inbound and outbound access control. This section provides very important details that allow you to understand how IPSEC filters affect packet processing. "

The Windows Server 2003 IPSec Monitor MMC Snap-in provides the most detailed view of the IPSec filter order. When the IPSec service processes a set of IPSec policy rules, the filters are replicated as two types of filters, which control the two stages of the IKE negotiation:

1.

IKE Main mode filter . These filters use only the filter source and destination addresses defined in the IPSEC policy to control IKE main mode. Each of the filters dedicated to IKE main mode has an IKE main mode negotiation policy associated with it, which defines: • Use key exchange to set IKE main mode security defined for IPSEC policy, such as Diffie Hellman master key strength and cryptographic algorithms and integrity algorithms for protecting the IKE negotiation itself. • IKE main mode lifetime and restrictions on the number of session keys generated from the same master key. • Authentication methods.

2.

IKE Quick mode filters . These filters contain all the filter information about addresses, protocols, and ports. IKE Quick Mode negotiates this filter definition to determine which traffic can be protected internally by IPSEC security associations. Each specific filter has a corresponding weight value and a set of security measures that define: • AH or ESP encapsulation options in transfer mode or tunnel mode. • A list of cryptographic algorithms and integrity algorithms. • The lifetime (in kilobytes and seconds) of the IPsec Security association. • Full forward secrecy security settings.

The filters that are dedicated to IKE quick mode are the filters that are specified for the IPSEC driver to enforce. The IPsec driver matches all inbound and outbound IP traffic to these filters in the order specified by the highest weights. The following section on the IKE negotiation process describes how IKE uses these policy controls to negotiate and manage IPsec security associations.

Filters defined in IPSEC policies are considered "generic" filters because they may have been interpreted by the IPSec service when the policy is applied. When an IPSec policy is applied (or changed) on a computer, the IPSec service interprets all generic filters as specific filters. A particular filter has a built-in algorithm or order for calculating weights, and the order is also known as the specific degree of the filter when selecting a traffic flow. The larger the weight value, the more specific the filter is. All of these specific filters are sorted according to their weight values. The filter weights are computed sequentially based on the IP addresses, protocols, and ports that may be defined in the filter. This method ensures that the rule order in the policy, the filter order in each of the different filter lists, does not affect the filtering behavior enforced by the IPSEC driver during packet processing. Packets are first matched with the most specific filters to minimize the time required to process each packet based on all filters. The filter action that corresponds to the most specific filter that matches a packet is the only action that is performed on the packet. The most general filter that you can define is those that match any IP address, all protocols, and ports. For example, consider the following four filter definitions:

•	Any IP address <-> Any IP address, any protocol
•	Any IP address <-> 192.168.1.0/24, any agreement
•	Any IP address <-> 192.168.1.0/24, any agreement
•	Any IP address <-> 192.168.1.10/24, any TCP source port, Target port is 25

"Any IP address to any IP address" is the most general filter that can be defined. Only Windows Server 2003 and Windows XP Service Pack 2 (SP2) support this filter. This filter is typically used in conjunction with blocking operations to implement the default behavior of "Reject all". If you use this filter to block all traffic, the remaining more specific filters can be treated as exceptions to the first filter. For Windows 2000来, the most common filter that is supported is "Any IP address <-> subnet, any protocol" or "Any IP address <-> my IP address" (if no subnet is used).

All four filters match the inbound traffic from any IP address to the 192.168.1.10 using TCP port 25 and the corresponding outbound response from port 25. Because the fourth filter specifies the destination IP address, protocol, and port number, it is most specific. If the IPsec driver enforces all four filters, inbound packets destined for TCP Port 25 will match only the fourth filter (that is, the most specific filter). If the remote system uses a port other than port 25 to send TCP traffic to the 192.168.1.10, this traffic will match the third filter. Finally, if the traffic is sent to any IP address other than 192.168.1.10 in the 192.168.1.0 subnet, the second filter is the most specific filter for the traffic flow. Potential filter Design issues

Some source and destination address combinations should not be used when defining filters. As mentioned above, for a host running Windows 2000, you should avoid using a filter that specifies "Any IP address to any IP address."

In general, the more filters a policy contains, the greater the impact on packet processing performance. This performance impact is typically manifested in reduced throughput, increased non-paged pool kernel memory utilization, and increased CPU utilization. The impact on performance is difficult to estimate precisely because the impact depends on the overall traffic flow on the computer, the IPsec-protected traffic being processed, and the CPU load. Therefore, when planning, you should consider performance testing of IPSEC policy design. In addition to very high throughput computers, the impact of hundreds of filters is unlikely to be noticed.

Windows 2000 does not provide optimized measures for handling large numbers of filters. The IPsec driver must scan the entire filter list sequentially to find a matching filter.

In Windows XP and Windows Server 2003, there are many optimizations that improve the speed of filter processing, so IPSEC policies can use a large number of filters. The Universal Packet Classifier (GPC) driver is optimized for filters (not limited to protocols and ports) with the "from <ip address > to <IP address >" format, so it is extremely fast to find. The GPC can handle almost any number of these filters, and throughput does not degrade. Therefore, if you have enough non-paged kernel memory to hold the entire list of filters, you can easily support a large exemption list that uses the "My IP address to < specific exempt IP address >" format. GPC cannot optimize the source and destination filters that do not have a specific IP address, which means that the "Any IP address <-> specific IP address (or subnet)" filter will require sequential searches to be performed. However, implementation measures are already improving compared to Windows 2000.

Using my IP address may be appropriate in many cases, but it may cause problems for hosts with many IP addresses, such as Web servers hosting many virtual Web sites. If you have a large number of filters using my IP address, the IPSEC driver packet filtering operation may be delayed. The IPSEC service needs to process those filters during service startup and when an IP address Change event occurs. Latency issues can cause security vulnerabilities or delay the establishment of IPSEC secure connections. Similarly, test performance should be used to verify that the impact of a particular policy design is acceptable.

When you allow or deny traffic to a specific port or protocol, you might be best suited to use my IP address. For example, in the IPSEC policy design of the Woodgrove Bank, a more specific filter was created using the "My IP address" filter, which allows the use of plaintext to send and receive Internet Control Message Protocol (ICMP) traffic between all computers.

If you assign a "My IP address <-> any IP address" rule to a mobile client in your organization and then place it in the extranet, this mobile client may not be able to communicate in that environment. If the client is allowed to fall back to the use of clear text, it will have a delay of three seconds or longer when connecting to each target. If the target responds with an IKE response, the IKE negotiation fails because IKE will not be able to authenticate using domain trust (Kerberos). Obviously, if the RFC 1918 private address is used as an internal network subnet, the mobile client will be affected when connecting to the hotel, home network, and other possible internal networks. If mobile clients experience connectivity problems, they may need local administrator privileges to stop the IPSEC service when they are connected to another network. Therefore, when a mobile client connects to an internal network, it may be necessary to use a domain logon script to check that the IPSEC service is running.

Because the IKE negotiation cannot be used to protect packet traffic using multicast addresses and broadcast addresses, Windows 2000 was not originally designed to provide filtering for such packets. Therefore, multicast packet types and broadcast packet types are part of the initial default exemption (bypassing IPsec filters). See the Microsoft Knowledge Base (KB) article 811832 "IPSec Default exemptions Can be Used to Bypass IPSec Protection in Some scenarios" (http:/ /support.microsoft.com/kb/811832) to understand the default exemptions for in-depth explanation of the security impact and the changes that are made by default for Service Pack 3 to remove certain exemptions. In Windows XP and Windows Server 2003, the Integration of TCP/IP with IPSEC has been enhanced to enable filtering of all types of IP packets. However, because IKE cannot negotiate security for multicast and broadcast, only limited filtering support is available. See the KB article 810207 "IPSEC default exemptions are removed in Windows Server 2003" (http://support.microsoft.com/kb/810207) to learn Details on how to remove the default exemption and how much support is filtered for multicast and broadcast traffic. Windows XP SP2 and Windows Server 20,031 all support the "Any IP address <-> any IP address" filtering feature. Back to the top of the page

IKE Negotiation Process

The IKE protocol is designed to help securely establish trust relationships between each computer, negotiate security options, and dynamically generate shared, cryptographic key data. To ensure successful and secure communication, IKE performs two-stage operations: the first stage (main mode) negotiation and the second phase (quick mode) negotiation. In each phase, confidentiality and authentication are ensured by using encryption algorithms and authentication algorithms that are approved by two computers during security negotiations. Main Mode Negotiation

During main mode negotiation, two computers establish a secure and authenticated channel. First, the following IPsec policy parameters are negotiated: The encryption Algorithm (DES or 3DES), the integrity algorithm (MD5 or SHA1), the Diffie-hellman group for the base key material (group 1, Group 2, or group 2048 in Windows Server 2003) ) and authentication Methods (Kerberos V5 protocol, public key certificate, or preshared key). After the IPSEC policy parameters are negotiated, the Diffie-hellman exchange of the common values is complete. The Diffie-hellman algorithm is used to generate shared keys, symmetric keys, and cryptographic keys between computers. After the Diffie-hellman Exchange is complete, the IKE service on each computer generates a master key to help protect authentication. With the negotiation algorithm and negotiation method, the master key is used to authenticate the identity. The originator of the communication then provides the potential SA to the responder. The responder sends a reply or other reply that accepts the content. A successful IKE main mode negotiation will get the main mode SA. Quick Mode Negotiation

During quick mode negotiation, a pair of IPsec SAS is established to help protect the application traffic, which can include packets sent over TCP, User Datagram Protocol (UDP), and other protocols. First, the following policy parameters are negotiated: The IPSEC Protocol line format (AH or ESP), the hash algorithm to ensure integrity and authentication (MD5 or SHA1), and the encryption algorithm (DES or 3DES) to use when encryption is required. During this time, a public protocol is reached on the type of IP packets that are transmitted in the established IPSEC SA pair. After the IPSEC policy parameters have been negotiated, the session keying material (the encryption key and the key lifetime of each algorithm, in kilobytes and seconds, respectively) is refreshed or exchanged.

Each IPSec SA is identified by the Security parameter Index (SPI), which is inserted into the IPSEC header of each packet that is sent. One SPI identifies the inbound IPSec SA, and the other SPI identifies the outbound IPSec SA. IKE main mode SA and IPsec sa

Each time IPSec is used to help secure traffic, an IKE main mode SA and two IPSec SAs are established. In the example scenario, the following SAS are established in order to conduct IPSEC-protected communication between CORPCLI and Corpsrv:

CORPCLI [IP1] <-------- IKE main mode SA [IP1, IP2] -----> [IP2] Corpsrv

CORPCLI [IP1] ---------- IPsec SA [spi=x] ------------------> [IP2] Corpsrv

CORPCLI [IP1] ---------- IPsec SA [spi=x] ------------------> [IP2] Corpsrv

which

•	IP1 is the IP address of the CORPCLI.
•	IP2 is the IP address of the corpsrv.
•	X represents the SPI, which identifies the inbound IPsec SA that corpsrv obtained from CORPCLI.
•	Y represents the SPI, which identifies the outbound IPSec SA that Corpsrv sends to CORPCLI.

As described in this summary, the IKE main mode SA between CORPCLI and Corpsrv is bidirectional. Both computers can start quick mode negotiation by using the protection provided by the IKE main mode SA. The IPsec SA is not dependent on the state of the upper protocol. For example, when a TCP connection is established and terminated, the work of the IPSec SA is not interrupted, and the IPSec SA can expire before the end of the TCP connection. Before the lifetime of an existing IPSec SA pair expires, IKE will attempt to negotiate with a quick mode negotiation to establish two new IPsec sa pairs to help prevent connection disruptions. Although this process is often referred to as regenerating the IPSec SA key, two new IPSec SAs are actually established. IKE Main mode SA is only measured in time and the number of IPsec SAS attempted (not measured by the number of data bytes transmitted through the IKE protocol). The IKE main mode SA's expiration is independent of the IPsec SA pair. If a new IPsec SA pair is required, the IKE main mode SA is automatically renegotiated as needed (after the main mode SA expires). In accordance with the design of the Internet Engineering Task Force (IETF), IKE must be able to regenerate the main mode SA key in either direction and negotiate IKE quick mode. Therefore, the authentication method configured for the IKE main mode SA in the IPsec policy on both computers should ensure successful authentication in the direction in which IKE main mode negotiation is initiated. Similarly, IPsec policy settings in the Quick Mode filter action should ensure that two-way quick mode negotiation succeeds. Back to the top of the page

Security measures

During IKE main mode negotiation, security measures are used to define cryptographic algorithms, hashing algorithms, and Diffie-hellman groups, and the Diffie-hellman group is used to create main mode SAS and to help ensure the security of the IKE negotiation channel. During quick mode negotiation, the security measures are also used to define the encapsulation mode (transfer mode or tunnel mode), the IPSEC Protocol line format (AH or ESP), the cryptographic algorithm and the hashing algorithm, and the key lifetimes used to create the quick mode inbound and outbound SA. Back to the top of the page

IPSec encapsulation mode and IPSec protocol line format

IPsec protects the data in an IP packet by encrypting the IP payload. The protection provided depends on how IPSec is used and the format of the IPSec protocol line. You can use IPSEC in either transfer mode or tunnel mode. IPsec Encapsulation Mode

IPSec tunneling mode is most commonly used to protect a site to site (also known as a gateway to gateway or router to router) traffic between a network, such as a site to a site that is implemented over the Internet. When using IPsec tunneling mode, the gateway that sends the packet encapsulates the entire original IP packet by creating a new IP packet and protecting it through one of the IPSEC protocol line formats (AH or ESP). For information about IPsec tunneling mode, see the "Deploying IPsec" chapter of "Deploying Network Services" in the Windows Server 2003 Department Toolkit, Http://go.microsoft . com/fwlink/? linkid=8195.

The IPSEC transport mode is used to protect the host to the host's traffic, and it is the default mode for Windows IPsec. When using IPSec transport mode, IPSec encrypts only the IP payload and does not encrypt the IP header. In transport mode, Windows IPsec is primarily used to help secure end-to-end traffic, such as communication between clients and servers. IPsec Protocol Line format

IPSEC supports two types of protocol line formats: AH and ESP. IPSec transport mode encapsulates the original IP payload with an IPSec header (AH or ESP). AH

AH provides data source authentication, data integrity, and replay protection for the entire packet including both the IP header and the data payload contained in the packet, except for fields that are allowed to change during transmission in the IP header. AH does not provide data confidentiality, which means it does not encrypt the data. The data can be read but cannot be modified to prevent spoofing. As the following illustration shows, integrity and authentication are provided by placing an AH header between the IP header and the TCP data.

Figure A.1 The authentication header in the packet
View larger image

To use AH, in the properties of the appropriate rule, in the Custom Security Method Settings dialog box, select the data and address unencrypted integrity (AH) check box, and then specify the integrity algorithm to use. ESP

ESP provides data source authentication, data integrity, replay protection, and confidentiality options for IP-only payloads. In transport mode, ESP does not protect the entire packet by encrypting checksums. IP headers are not protected. As the following illustration shows, the ESP header is placed before the TCP data, and the end of the ESP end and the ESP authentication are placed behind the TCP data.

Figure A.2 ESP data in a packet
View larger image

To use ESP, in the properties of the appropriate rule, in the Custom Security Method Settings dialog box, select the data integrity and encryption (ESP) check box, and then specify the integrity algorithm and encryption algorithm to use. Back to the top of the page

IKE Authentication

IKE uses mutual authentication between computers to establish trusted traffic, and IKE requires one of the following authentication methods: The Kerberos V5 protocol, the computer X.509 V3 public Key Infrastructure (PKI) certificate, or the preshared key. Two communication endpoints must have at least one common authentication method, or the communication will fail. IKE Authentication Process

During the IKE negotiation, the IKE initiator provides the responder with a list of authentication methods. The responder uses the originator's source IP address to determine which filter is controlled by the IKE negotiation. The authentication method that corresponds to the filter in the responder's IPsec policy is used to select an authentication method from the initiator's list. The responder then responds by notifying the initiator of the mutually agreed authentication method. IKE does not provide a way to attempt to use another authentication method, even if the authentication method you select fails. If authentication succeeds and the main mode negotiation completes successfully, the main mode SA will be available within 8 hours. If data is still being transferred at the end of 8 hours, the main mode SA will be automatically renegotiated. IKE authentication Method

It is important to select an authentication method that is appropriate for the IPSEC policy. The IPsec policy rule causes each IP address in the filter to be associated with an authentication method list so that IKE can determine the list of authentication methods to use with each IP address. Kerberos V5 Authentication Protocol

The Kerberos V5 protocol is the default authentication standard for Windows 2000 and Windows Server 2003 Active Directory domains. This authentication method can be used by any computer in a domain or a trusted domain.

When using the Kerberos authentication method, each IPSEC peer sends its computer identity to another pair of parties in an unencrypted format during the main mode negotiation. The computer identity is unencrypted until the authentication phase of the main mode negotiation encrypts the entire identity payload. An attacker can send an IKE packet to expose its computer identity and domain membership to the corresponding IPSEC peer. Therefore, to ensure the security of computers connected to the Internet, it is recommended that you use certificate authentication.

By default, IPSEC filtering does not process the Kerberos protocol traffic in Windows 2000 to Windows Service Pack 3 and Windows XP. To perform IPsec filtering on the Kerberos protocol traffic, you must modify the registry and then add the appropriate IPSEC filters to ensure that the traffic is secure. For information about the default exemptions in Windows 2000 and Windows Server 2003, see "Special IPSec Considerations" on the Microsoft Web site to create, modify, and assign IPSec policies at:
www.microsoft.com/resources/documentation/WindowsServ/
2003/standard/proddocs/en-us/sag_ipsecbpspecial.asp. Public Key certificate authentication

In Windows Server, you can use Certificate Services to automate the management of those certificates for IPsec throughout the life cycle of a computer certificate. Certificate Services integrates with Active Directory and Group Policy to simplify certificate deployment by enabling certificate autoenrollment and renewal, and by providing some default certificate templates that are compatible with IPSEC. To use certificates for IKE authentication, you need to define the list of acceptable root Certification authorities (CAs) that you want to use, rather than the specific certificate you want to use. Both computers must have a common root CA in their IPsec policy configuration, and the client must have an associated computer certificate.

During the certificate selection process, IKE performs a series of checks to ensure that the specific requirements of the computer certificate are met. For example, a computer certificate must have a public key with a length greater than 512 bits and use a digital signature key usage.

Note: certificates obtained from Certificate Services with the Advanced option "Enable strong private key protection" do not apply to IKE authentication because you cannot enter a required personal identification number (PIN) during an IKE negotiation and therefore cannot access the private key of the computer certificate. pre-shared secret key

If you are not using Kerberos authentication and you do not have access to the CA, you can use a preshared key. For example, in some cases, a stand-alone computer on a network may need to use a pre-shared key because of Kerberos authentication (through the computer's domain account) and the certificate that the CA provides cannot successfully perform IKE authentication.

Important : Pre-shared keys are easy to implement, but improper use can have a negative impact. Microsoft recommends that you do not use preshared key authentication in Active Directory because the key value is not securely stored and is therefore difficult to keep secret. Pre-shared key values are stored in plaintext in the IPsec policy. Any member of the local Administrators group can view the local IPSec policy, and any system service that has local system user rights can read the native IPSec policy. By default, any authenticated user in a domain can view a pre-shared key stored in an IPSEC policy based on Active Directory. In addition, if an attacker could capture an IKE negotiation packet, an attacker could exploit a published method to discover a preshared key value.
For more information, see "Authentication Vulnerabilities in IKE and Xauth with Weak pre-shared Secrets", Web site: http://go.microsoft.com/ fwlink/? linkid=18769.

Pre-shared key authentication is provided for interoperability purposes and is compliant with RFC standards. If you must use preshared key authentication, use a 25-character or longer random key value, and use a different preshared key for each IP address pair. These measures cause different security rules to be generated for each target, ensuring that the compromised preshared key only endangers the security of the computer that shares the key. IPsec CRL Check

If you are using certificate-based authentication, you can also enable IPSEC certificate revocation list (CRL) checking. By default, in Windows 2000, IPsec CRL checking is not automatically performed during IKE certificate authentication.

to enable IPsec CRL checking

Note : Incorrectly editing the registry can severely damage your system. Before making changes to the registry, you should back up any valuable data on your computer.

1.	In hkey_local_machine/system/currentcontrolset/ Add a new Oakley registry key under services/policyagent/ and create a double-byte item named Strongcrlcheck.
2.	Specify a value between 0 and 2 for this item, where: • A value of 0 disables CRL checking (this is the default value in Windows 2000). • A value of 1will attempt CRL checking and will cause certificate validation to fail only if the certificate has been revoked (this is the default value in Windows XP and Windows Server 2003). Other failures encountered during CRL checking, such as the inability to access revocation URLs, do not cause the authentication certificate operation to fail. • A value of 2enables strong CRL checking, which means that CRL checking is required, and any errors encountered during CRL processing can cause the certificate validation operation to fail. Please set this registry value to enhance security.
3.	Perform one of the following actions: • Restart your computer. • Stop and then restart the IPsec service by running the net stop policyagent and net start policyagent commands from the command prompt. Note : IPsec CRL checking does not guarantee that the certificate validation operation fails immediately when the certificate is revoked. There is a delay between when a revoked certificate is placed in an updated published CRL and when the computer that performs the IPSEC CRL check retrieves the CRL. The computer does not retrieve a new CRL until the current CRL expires or the next time the CRL is published. CryptoAPI caches CRLs in memory and/documents and settings/username/local settings/temporary Internet Files. Because CRLs are not lost because of a computer reboot, restarting the computer does not resolve the problem if a CRL cache problem occurs.

Back to the top of the page

IKE authentication methods and security order precedence

You can configure an IPSEC rule that specifies only one authentication method or one security measure. In addition, you can specify a priority list of authentication methods and security measures. Precedence will be applied to authentication methods or security measures, so you can specify each method in the order from highest to least priority. For example, you can specify both the Kerberos V5 protocol and public key certificate authentication as the authentication method, but specify a higher precedence for the Kerberos protocol, as shown in the following illustration.

Figure A.3 Authentication method Precedence

If the client attempts to connect to CORPSRV but only accepts the use of a public key certificate for authentication, CORPSRV uses this authentication method and continues to communicate. When you use the selected authentication method, the IKE negotiation must succeed or the communication will be blocked. IKE does not attempt to use a different authentication method even if the negotiation fails. The same principle applies to security measures, for example, ESP may take precedence over AH. Back to the top of the page

Security Negotiation Options

In the properties of the filter action, you can configure the IPSEC policy in the Security tab to allow fallback to plaintext (fallback to unprotected traffic), to allow inbound pass and session key PFS. In the Key Exchange Settings dialog box, you can configure master key PFS in the general properties of the rule. Fall back to use plaintext

If fallback to clear text is allowed, IPSec protects the traffic as much as possible (if the computer that is connected to the other end supports IPSec for the Supplemental filter Action and filter), but if the peer does not have an IPSec policy corresponding to the security negotiation request, The traffic is sent in an insecure manner. If the peer does not respond to a security negotiation request within three seconds, the SA (soft SA) is created for the plaintext communication stream. Soft SAS allow normal TCP/IP traffic without IPsec encapsulation. Keep in mind that although IPsec may not be able to protect such traffic, other applications may be able to secure this traffic (for example, traffic flows may be protected by Lightweight Directory Access Protocol (LDAP) encryption or remote procedure call (RPC) authentication mechanisms). If the peer does not respond within three seconds and the security negotiation fails, the traffic that matches the corresponding filter is blocked.

The fallback to clear setting allows interoperability with the following computers:

•	A computer running an older operating system than Wndows 2000
•	Computers running Wndows 2000 or older systems that do not have IPSEC policy configured
•	Running computers that do not support IPSEC-enabled non-Microsoft operating systems

To enable or disable fallback to clear, on the Security tab, in the properties of the filter action, select or clear the Allow unsecured communication with non-IPSEC-aware computers check box.

For client policy, you can enable or disable this option. If this option is enabled and the server does not respond to client negotiation security requests, you can allow this client to "fall back to clear". If this check box is cleared and the server does not respond to client negotiation security requests, the communication is blocked. In some cases, it is useful to allow fallback to clear. However, IKE allows fallback to clear only if a reply is not received. To ensure security, Windows IPsec does not allow unprotected communication when an IKE negotiation fails, or when an error such as authentication fails or a security parameter agreement cannot be reached during an IKE negotiation (after receiving a reply).

For the initial deployment, it is recommended that you select this check box so that clients can "fall back to clear" and establish an initial connection when IPSEC is disabled on the server. Inbound through

If the inbound Pass feature is enabled, it is accepted for normal inbound TCP/IP traffic (IPsec-protected traffic, such as TCP SYN packets), if it matches the associated inbound filter for the filter action. The upper layer protocol response packet (for example, a TCP SYN ACK packet) matches the corresponding outbound filter and triggers security negotiation. After two IPSec SAs are negotiated, the traffic flows in the two directions are protected by IPsec. The inbound through option allows the server to use the default response rule to initiate security negotiation for the client. If the default response rule is enabled in the client IPsec policy, the client does not need to maintain a filter that contains the server's IP address. If the default response rule is not enabled in the client IPSec policy, you do not need to enable the "Inbound Pass" option in the server IPSec policy. Also, you should never enable this option on computers that are connected to the Internet.

To enable or disable inbound passes, in the Security tab of the properties of the filter action, select or clear the Allow unsecured communication but always respond with IPsec check box. session key and master key PFS

PFS is a mechanism that determines whether existing key data for a master key can be used to derive a new session key. PFS ensures that the compromise of a single key affects only the data that is protected by PFS and does not affect the entire communication. To do this, PFS ensures that the keys used to secure data transfer cannot be used to generate additional keys. Session key PFS does not need to be validated when used, and requires fewer resources than master key PFS. If session key PFS is enabled, a new Diffie-hellman key exchange is performed to generate a new rebuild key information for the master key.

If session key PFS is enabled in the server policy, it must also be enabled in the client policy. You can enable session key PFS by using the following: In the Key Exchange Settings dialog box, in the general properties of the rule, select the use session key perfect forward secrecy (PFS) check box. Master key PFS requires a re validation, which consumes more resources. For each quick mode negotiation, master key PFS requires a new main mode negotiation. You can configure master key PFS by selecting the master key perfect forward secrecy (PFS) check box. If master key PFS is enabled in the server policy, you do not need to enable it in the client policy. Because enabling this option can incur significant overhead, it is recommended that you enable session key PFS or master key PFS only in dangerous environments. In those environments, IPSec traffic can be exposed to sophisticated attackers who attempt to compromise the strong encryption protection provided by IPSec