Internet Key Exchange

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Internet Key Exchange

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

ISAKMP/Oakley Service

To build this agreement between the two computers, the IETF has established a standard method of security association and key exchange resolution named Internet Key Exchange (IKE) 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 (endpoint) is performed by a security gateway.

Security association (SA) defined

A security association (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.

Phase I or main mode SA

In order 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 phase I or main mode SA. IKE automatically provides necessary identity protection during this exchange.

Phase I or main mode negotiation

The following are the steps that comprise 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 integrity algorithm (MD5 or SHA1)

    • The Diffie-Hellman group to be used for the base keying material: Group 1 (768 bits of keying material) Group 2 (1,024 bits), or Group 2048 (2,048 bits)

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

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

      Important

      For enhanced security, do not use Diffie-Hellman Group 1. For maximum security, use Group 2048 whenever possible. Use Group 2 when required for interoperability with Windows 2000 and Windows XP.

      For more information about Diffie-Hellman groups, see Key exchange methods. For more information about preshared key authentication, see Preshared key authentication.

  2. Diffie-Hellman exchange (of public values)

    At no time are actual keys exchanged. Only the base information required by the Diffie-Hellman 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

    To prevent a successful man-in-the-middle attack, the computers attempt to authenticate the Diffie-Hellman key exchange. Without successful authentication, communication will not proceed. The master key is used, in conjunction with the negotiation algorithms and methods, to authenticate identities. The entire identity payload is hashed and encrypted using the keys generated from the Diffie-Hellman exchange in the second step. The payload includes the identity type (for authentication), port, and protocol. IPSec uses the following identity types for authentication: For certificate authentication, the certificate distinguished name and general name; for Kerberos V5 and preshared key authentication, IPv4 addresses, the fully qualified domain name (FQDN) of the computer, and FQDN of the user. 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. If unsecured communications begin, after five minutes of idle time (during which no messages are sent), secured communication negotiation is attempted the next time messages are sent. If messages are sent continuously, the communication remains unsecured during the lifetime set for the main mode policy. After the policy time has elapsed, a new secured communication negotiation attempt is made.

There is no preset limit to the number of exchanges that can take place. The number of SAs established is only limited by system resources. When estimating the number of SAs that can be established without significantly degrading computer performance, consider the CPU processing strength and RAM of the computer, the lifetime of the SA, and how much traffic is being sent over the SAs.

For more information about unsecured communications, see Filter action.

Phase II or quick mode SA

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

Phase II or quick mode negotiation

The following are the steps that comprise 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 (3DES or DES)

      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 Diffie-Hellman exchange (as described in main mode negotiation) occurs, or a refresh of the original Diffie-Hellman key is used.

  3. The SAs and keys, along with the SPI, are passed to the IPSec driver.

The second 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 phase provides protection by refreshing the keying material prior to sending data. IKE can accommodate a key exchange payload for an additional Diffie-Hellman exchange if a rekey is necessary--that is, master key perfect forward secrecy (PFS) is enabled. Otherwise, IKE refreshes the keying material from the Diffie-Hellman 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.

Notes

  • Although there are two separate quick mode SAs established, IP Security Monitor only displays a single quick mode SA.

  • Computers running Windows 2000 must have the High Encryption Pack or Service Pack 2 (or later) installed in order to use the 3DES algorithm. If a computer running Windows 2000 receives a 3DES setting, but does not have the High Encryption Pack or Service Pack 2 (or later) installed, the 3DES setting in the security method is set to the weaker DES, to provide some level of confidentiality for communication, rather than blocking all communication. However, you should only use DES as a fallback option if not all computers in your environment support the use of 3DES. Computers running Windows XP or a Windows Server 2003 operating system support 3DES and do not require installation of the High Encryption Pack.

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 necessary. The number of quick mode SA negotiations that can be performed is determined by IPSec policy settings.

Note

  • Excessive rekeying off of 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 time-out 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 expire the main mode SA. This prevents additional new quick mode SAs from being created from the expired main mode SA. IKE does not expire the quick mode SA, 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 master key lifetime of eight hours and a 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.

It is generally recommended that all of the IKE settings (for example, master key PFS and key lifetime) and security methods remain at their defaults to avoid unnecessary administrative overhead. This provides a standard (medium) level of security. If your security plan calls for a high level of security, you should consider modifying the default security methods.