Before secured data can be exchanged, a contract must be established between the two computers. In this contract, called a security association (SA), both agree on how to exchange and protect information.

A key is a secret code or number that is required to read, modify, or verify secured data. Keys are used in conjunction with algorithms (a mathematical process) to secure data. In IPsec, there are two phases or modes that use keys. Main mode occurs first and generates a shared master key that the two parties can use to exchange keying information in a secure way. Quick mode uses the master key to secure the establishment of one or more session keys that are used for data integrity or encryption.

Windows handles key generation automatically and implements the following keying properties that maximize protection:

Important

The IP Security Policy snap-in can be used to create IPsec policies that can be applied to computers running Windows Vista and later versions of Windows, but this snap-in does not use the new security algorithms and other new features available in computers running those later versions of Windows. To create IPsec polices for these computers, use the Windows Firewall with Advanced Security snap-in. The Windows Firewall with Advanced Security snap-in does not create policies that can be applied to earlier versions of Windows.

Dynamic rekeying

IPsec uses a method called dynamic rekeying to control how often a new key is generated during communication. The communication is sent in blocks; each block of data is secured with a different key. This prevents an attacker who has obtained part of a communication and the corresponding session keys from obtaining the remainder of the communication. This on-demand security negotiation and automatic key management service is provided using Internet Key Exchange (IKE), as defined in RFC 2409.

IPsec allows you to control how often a new key is generated. If no values are configured, keys are regenerated automatically at default intervals.

Key lengths

Every time the length of a key is increased by one bit, the number of possible keys doubles, making it exponentially more difficult to determine the key. IPsec provides multiple algorithms to allow for short or long key lengths.

Key material generation: Diffie-Hellman algorithm

To enable secure communication, two computers must be able to gain the same shared key (quick mode, or session key), without sending the key across a network and compromising the secret.

The Diffie-Hellman algorithm (DH) is one of the oldest and most secure algorithms used for key exchange. The two parties publicly exchange keying information, which Windows additionally protects with a hash function signature. Neither party ever exchanges the actual key; however, after their exchange of keying material, each is able to generate the identical shared key.

DH keying material exchanged by the two parties can be based on 768, 1024, or 2048 bits of keying material, known as DH groups. The strength of the DH group is proportional to the strength of the key computed from the DH exchange. Strong DH groups combined with longer key lengths increase the degree of computational difficulty involved in determining the key.

Note

On the IKE Security Algorithms dialog box, 768 bits corresponds to the Low (1) setting and 1024 bits to the Medium (2) setting.

IPsec uses the DH algorithm to provide the keying material for all other encryption keys. DH does not provide authentication. The Microsoft Windows implementation of IPsec authenticates identities after the DH exchange takes place, providing protection against man-in-the-middle attacks.

Key protection

The following features enhance the base prime numbers (keying material) and the strength of the keys for the master and session keys.

Key lifetimes

Key lifetimes determine when, rather than how, a new key is generated. Also known as dynamic rekeying or key regeneration, a key lifetime allows you to force a key regeneration after a specified interval. For example, if a communication takes 10,000 seconds and you specify a key lifetime of 1,000 seconds, 10 keys are generated to complete the communication. This ensures that even if an attacker is able to decipher part of a communication, the remainder of the communication is protected. Key lifetimes can be specified for both the master and session keys. Whenever a key lifetime is reached, the SA is also renegotiated. In addition, the key is refreshed or regenerated. The amount of data processed by a single key should not exceed 100 megabytes (MB).

Session key refresh limit

A quick mode session key refresh limit is used because the repeated rekeying from a quick mode session key can compromise the Diffie-Hellman shared secret.

For example, Alice on Computer A sends a message to Bob on Computer B, and then sends another message to Bob a few minutes later. Because an SA was recently established, the same session key material might be reused. If you want to limit the number of times this occurs, set the session key refresh limit to a low number.

If you have enabled master key perfect forward secrecy (PFS), the quick mode session key refresh limit is not used. Setting a session key refresh limit to 1 is identical to enabling master key PFS. If both a main mode master key lifetime and a quick mode session key refresh limit are specified, the limit reached first causes the subsequent rekey. By default, IPsec policy does not specify a session key refresh limit.

Diffie-Hellman groups

Diffie-Hellman (DH) groups are used to determine the length of the base prime numbers (key material) for the DH exchange. The strength of any key derived from a DH exchange depends, in part, on the strength of the DH group on which the prime numbers are based.

Each DH group defines the length of the keying material to be used. Group 1 protects 768 bits of keying material; Group 2 protects 1024 bits; Group 3 protects 2048 bits. When a larger group is used, the resulting key that is determined from a DH exchange is larger and more difficult to determine by an attacker.

IKE negotiates which group to use, based on settings you configure on the IKE Security Algorithms dialog box, ensuring that there are not any negotiation failures that result from a mismatched DH group between the two peers.

If session key PFS is enabled, a new DH key is negotiated in the first Quick Mode SA negotiation. This new DH key removes the dependency of the session key on the DH exchange that is performed for the master key.

If the initiator is using session key PFS, the responder is not also required to use session key PFS. However, if the initiator is not using session key PFS and the responder is using session key PFS, negotiation fails.

The DH group is the same for both the main mode and quick mode SA negotiations. When session key PFS is enabled, even though the DH group is set as part of the main mode SA negotiation, it affects any rekeys during quick mode session key establishment.

Perfect forward secrecy

Unlike key lifetimes, PFS determines how, rather than when, a new key is generated. Specifically, PFS ensures that the compromise of a single key permits access only to data that is protected by it, not necessarily to the entire communication. To achieve this, PFS ensures that a key used to protect a transmission, in either mode, cannot be used to generate additional keys. In addition, if the key used was derived from specific keying material, that material cannot be used to generate other keys.

Main mode master key PFS requires a reauthentication and is resource-intensive. When it is enabled, IKE must reauthenticate identities, increasing overhead for domain controllers when the Kerberos V5 authentication protocol is used for authentication. It requires a new main mode negotiation for every quick mode negotiation that occurs.

Quick mode session key PFS can be used without a reauthentication and is less resource-intensive. Session key PFS results in a DH exchange to generate new keying material. It requires only four messages and no authentication.

PFS does not have to be enabled on both peers because it is not part of the SA negotiation. If the responder requires PFS and the sender's quick mode SA expires, it simply rejects the sender's message and requires a new negotiation. The sender causes the main mode SA to expire and then renegotiates. PFS can be individually set for both the master (main mode) and session (quick mode) keys.

Key exchange

Before secured data can be exchanged, a contract between the two computers must be established. In this contract (SA), both agree on how to exchange and protect information.

To build this contract between the two computers, the Internet Engineering task Force (IETF) has established the IKE method of security association and key exchange resolution, which:

  • Centralizes security association management, reducing connection time.

  • Generates and manages shared, secret keys that are used to secure the information.

This process not only protects communication between computers, it also protects remote computers that request secure access to a corporate network. In addition, this process works whenever the negotiation for the final destination computer is performed by a security gateway.

Security association defined

An SA is the combination of a negotiated key, security protocol, and security parameters index (SPI), which together define the security used to protect the communication from sender to receiver. The SPI is a unique, identifying value in the SA that is used to distinguish among multiple security associations that exist at the receiving computer. For example, multiple associations might exist if a computer is securely communicating with multiple computers at the same time. This is a common occurrence when the computer is a file server or a remote access server that serves multiple clients. In these situations, the receiving computer uses the SPI to determine which SA is used to process the incoming packets.

Main mode SA

To ensure successful and secure communication, IKE performs a two-phase operation. Confidentiality and authentication are ensured during each phase by the use of encryption and authentication algorithms that are agreed upon by the two computers during security negotiations. With the duties split between two phases, key creation can be rapidly accomplished.

During the first phase, the two computers establish a secure, authenticated channel. This is called the main mode SA. IKE automatically provides required identity protection during this exchange.

The following steps describe a main mode negotiation.

  1. Policy negotiation. The following four mandatory parameters are negotiated as part of the Main Mode SA:

    • The encryption algorithm (DES or 3DES).

    • The hash algorithm (MD5 or SHA1).

    • The authentication method (the Kerberos V5 authentication protocol, certificate, or preshared key authentication).

    • The Diffie-Hellman (DH) group to be used for the base keying material (768 bits Low (Group 1), 1024 bits Medium (Group 2), or 2048 bits High (Group 3)).

    • If certificates or preshared keys are used for authentication, the computer identity is protected. However, if the Kerberos V5 authentication protocol is used, the computer identity is unencrypted until encryption of the entire identity payload takes place during authentication.

  2. DH exchange (of public values). At no time are actual keys exchanged. Only the information required by the DH key determination algorithm to generate the shared, secret key is exchanged. After this exchange, the IKE service on each computer generates the master key that is used to protect authentication.

  3. Authentication. The computers attempt to authenticate the DH key exchange. Without authenticating the DH key exchange, the communication is vulnerable to a man-in-the-middle attack. Without successful authentication, communication cannot proceed. The master key is used, in conjunction with the negotiation algorithms and methods, to authenticate identities. The entire identity payload (including the identity type, port, and protocol) is hashed and encrypted using the keys generated from the DH exchange in the second step. The identity payload, regardless of which authentication method is used, is protected from both modification and interpretation.

    The sender presents an offer for a potential security association to the receiver. The responder cannot modify the offer. Should the offer be modified, the initiator rejects the responder's message. The responder sends either a reply accepting the offer or a reply with alternatives.

    Messages sent during this phase have an automatic retry cycle that is repeated five times. If a response is received before the retry cycle ends, standard SA negotiation begins. If allowed by IPsec policy, unsecured communications will begin after a brief interval. This behavior is known as fall back to clear. Even if the communication falls back to clear, secure communication negotiation is attempted at five-minute intervals.

    There is no limit to the number of exchanges that can take place. The number of SAs established is limited only by system resources.

Quick mode SA

In this phase, SAs are negotiated on behalf of the IP Security driver.

The following steps describe a quick mode negotiation.

  1. Policy negotiation occurs. The IPsec computers exchange the following requirements for securing the data transfer:

    • The IPsec protocol (AH or ESP)

    • The hash algorithm for integrity and authentication (MD5 or SHA1)

    • The algorithm for encryption, if requested (DES or 3DES)

    A common agreement is reached and two SAs are established. One SA is for inbound communication and the other is for outbound communication.

  2. Session key material is refreshed or exchanged. IKE refreshes the keying material and new shared keys are generated for packet integrity, authentication, and encryption (if negotiated). If rekeying is required, either a second DH exchange (as described in main mode negotiation) occurs, or a refresh of the original DH key is used.

  3. The SAs and keys, along with the SPI, are passed to the IP Security driver. The quick mode negotiation of security settings and keying material (for the purpose of securing data) is protected by the main mode SA. As the first phase provided identity protection, the second, quick mode phase provides protection by refreshing the keying material before sending data. IKE can accommodate a key exchange payload for an additional DH exchange if a rekey is required—that is, master key PFS is enabled. Otherwise, IKE refreshes the keying material from the DH exchange completed in main mode.

    Quick mode results in a pair of security associations, each with its own SPI and key. One SA is used for inbound communication, and the other for outbound communication.

    The retry algorithm for a message is similar to the process described in main mode negotiation. However, if this process times out for any reason during the second or higher negotiation off of the same main mode SA, a renegotiation of the main mode SA is attempted. If a message for this phase is received without an established main mode SA, it is rejected.

    Using a single main mode SA for multiple quick mode SA negotiations increases the speed of the process. As long as the main mode SA does not expire, renegotiation and reauthentication are not required. The number of quick mode SA negotiations that can be performed is determined by IPsec policy settings.

    Note

    Excessive rekeying from the same main mode SA might make the shared, secret key vulnerable to a known plaintext attack. A known plaintext attack is a sniffer attack in which the attacker attempts to determine the encryption key from encrypted data based on known plaintext.

SA lifetimes

The main mode SA is cached to allow multiple quick mode SA negotiations (unless master key PFS is enabled). When a key lifetime is reached for the master or session key, the SA is renegotiated. In addition, the key is refreshed or regenerated.

When the default timeout period elapses for the main mode SA, or the master or session key lifetime is reached, a delete message is sent to the responder. The IKE delete message tells the responder to cause the main mode SA to expire. This prevents additional new quick mode SAs from being created from the expired main mode SA. IKE does not cause the quick mode SA to expire because only the IPsec driver contains the number of seconds or bytes that have passed to reach the key lifetime.

Use caution when setting very different key lifetimes for master and session keys. For example, setting a main mode master key lifetime of eight hours and a quick mode session key lifetime of two hours might leave a quick mode SA in place for almost two hours after the main mode SA has expired. This occurs when the quick mode SA is generated shortly before main mode SA expiration.

Table Of Contents