Integrity Algorithms
Applies To: Windows Server 2008
Configuring data integrity settings
Hash message authentication codes (HMAC) sign packets to verify that the information received is exactly the same as the information sent. This is called integrity and it is critical when data is exchanged over unsecured media. Using a hash of the transmitted message makes it computationally infeasible to change the message without a resulting mismatch with the HMAC. This provides a way to know that the message was not changed during transit.
The hash is a cryptographic checksum or message integrity code (MIC) that each party must compute to verify the message. For example, the sending computer uses a hash function and shared key to compute the checksum for the message, including it with the packet. The receiving computer must perform the same hash function on the received message and shared key and compare it to the original (included in the packet from the sender). If the message has changed in transit, the hash values are different and the packet is rejected.
ESP
Encapsulating Security Payload (ESP) provides confidentiality (in addition to authentication, integrity, and anti-replay) for the IP payload. ESP in Transport Mode does not sign the entire packet. Only the IP payload (not the IP header) is protected. ESP can be used alone or in combination with AH. With ESP, the hash calculation only includes the ESP header, trailer, and payload. ESP provides data confidentiality services by encrypting the ESP payload with the Data Encryption Standard (DES) or triple DES (3DES) encryption algorithms. Packet replay services are provided through the inclusion of a sequence number for each packet.
AH
Authentication Header (AH) provides authentication, integrity, and anti-replay for the entire packet (both the IP header and the data payload carried in the packet). It does not provide confidentiality, which means that it does not encrypt the data. The data is readable, but protected from modification. (Some fields that are allowed to change in transit are excluded.) Packet replay services are provided through the inclusion of a sequence number for each packet.
Important
The AH protocol is not compatible with network address translation (NAT) because NAT devices need to change information in the packet headers. To allow IPsec-based traffic to pass through a NAT device, you must ensure that IPsec NAT-T is supported on your IPsec peer computers.
SHA1
Secure Hash Algorithm 1 (SHA1) was developed by the National Institute of Standards and Technology, as described in Federal Information Processing Standard (FIPS) PUB 180-1. The SHA process is closely modeled after MD5. The SHA1 computation results in a 160-bit hash that is used for the integrity check. Because longer hash lengths provide greater security, SHA is stronger than MD5.
MD5
Message Digest 5 (MD5) is based on RFC 1321. It was developed in response to a weakness found in MD4. MD5 completes four passes over the data blocks (MD4 completes three passes), using a different numeric constant for each word in the message on each pass. The number of 32-bit constants used during the MD5 computation equates to 64, ultimately producing a 128-bit hash that is used for the integrity check. While MD5 is more resource-intensive, it provides stronger integrity than MD4.
Warning
The MD5 algorithm is no longer considered secure because the key can be computationally derived.
Key regeneration
Lifetime settings determine when a new key is generated. Lifetimes allow you to force the generation of a new key (regeneration) after a specified interval or after a specified amount of data has been transmitted. For example, if the communication takes 100 minutes and you specify a key lifetime of 10 minutes, 10 keys will be generated (one every 10 minutes) during the exchange. Using multiple keys ensures that if an attacker manages to gain the key to one part of a communication, the entire communication is not compromised.
Note
This key regeneration is for data integrity only. These settings do not affect the key lifetime settings for key exchange. To change these settings, on the IPsec Settings dialog box, under Key Exchange, use the Custom option.
Key lifetime (in minutes)
You can use this setting to configure how long the key used to perform data integrity lasts, in minutes. After this interval, the key will be regenerated. Subsequent communications will use the new key.
The maximum lifetime is 2,879 minutes (48 hours). The minimum lifetime is 5 minutes.
Key lifetime (in KB)
You can use this setting to configure how many megabytes (MB) of data are sent using the key. After this threshold is reached, the counter is reset, and the key is regenerated. Subsequent communications will use the new key.
The maximum lifetime is 2,147,483,647 KB. The minimum lifetime is 20,480 KB.