Encrypting Windows Traffic Using IPSec PART1
Dear Security Kaizen magazine readers, As part of the Defense-in-Depth strategy, I chose to introduce the topic in this issue to you by taking an excerpt from one of my favorite references in my library, “Microsoft Windows Security Resource Kit, Ben Smith and Brian Komar with Microsoft Security Team, Microsoft Press 2003, ISBN 0-7356-1868-2
Using IPSec
By its design, TCP/IP is an open protocol created to connect heterogeneous computing environments with the least amount of overhead possible. As is often the case, interoperability and performance design goals do not generally result in security—and TCP/IP is no exception to this. TCP/IP provides no native mechanism for the confidentiality or integrity of packets. To secure TCP/IP, you can implement IP Security. IPSec implements encryption and authenticity at a lower level in the TCP/IP stack than application-layer protocols such as Secure Sockets Layer (SSL) and Transport Layer Security (TLS). Because the protection process takes place lower in the TCP/IP stack, IPSec protection is transparent to applications. IPSec is a well- defined, standards-driven technology.
The IPSec process encrypts the payload after it leaves the application at the client and then decrypts the payload before it reaches the application at the server. An application does not have to be IPSec aware because the data transferred between the client and the server is normally transmitted in plaintext. IPSec is comprised of two protocols that operate in two modes with three different authentication methods. IPSec is policy driven and can be deployed centrally by using Group Policy. To deploy IPSec, you must determine the
• Protocol
• Mode
• Authentication methods
• Policies
Using AH
IPSec AH provides authentication, integrity, and anti-replay protection for the entire packet, including the IP header and the payload. AH does not provide confidentiality. When packets are secured with AH, the IPSec driver computes an Integrity Check Value (ICV) after the packet has been constructed but before it is sent to the computer. With Microsoft Windows XP or later, you can use either the HMAC SHA1 or HMAC MD5 algorithm to compute the ICV. Figure 9-3 shows how AH modifies an IP packet.
Figure 9-3. AH modifications to an IP packet
The fields in an AH packet includes these:
• Next Header
Indicates the protocol ID for the header that follows the AH header. For example, if the encrypted data is transmitted using TCP, the next header value would be 6, which is the protocol ID for TCP.
• Length: Contains the total length of the AH.
• Security Parameters Index (SPI)
Identifies the security association (the IPSec agreement between two computers) that was negotiated in the Internet Key Exchange (IKE) protocol exchange between the source computer and the destination computer.
• Sequence Number
Protects the AH-protected packet from replay attacks in which an attacker attempts to resend a packet that he has previously intercepted, such as an authentication packet, to another computer. For each packet issued for a specific security association (SA), the sequence number is incremented by 1 to ensure that each packet is assigned a unique sequence number. The recipient computer verifies each packet to ensure that a sequence number has not been reused. The sequence number prevents an attacker from capturing packets, modifying them, and then retransmitting them later.
• Authentication Data
Contains the ICV created against the signed portion of the AH packet by using either HMAC SHA1 or HMAC MD5. The recipient performs the same integrity algorithm and compares the result of the hash algorithm with the result stored within the Authentication Data field to ensure that the signed portion of the AH packet has not been altered in transit. Because the TTL, Type of Service (TOS), Flags, Fragment Offset, and Header Checksum fields are not used in the ICV, packets secured with IPSec AH can cross routers, which can change these fields.
Using ESP
ESP packets are used to provide encryption services to transmitted data. In addition, ESP provides authentication, integrity, and antireplay services. When packets are sent using ESP, the payload of the packet is encrypted and authenticated. In Windows XP or later, the encryption is done with either Data Encryption Standard (DES) or 3DES, and the ICV calculation is done with either HMAC SHA1 or HMAC MD5.
TIP
When designing an IPSec solution, you can combine AH and ESP protocols in a single IPSec SA. Although both AH and ESP provide integrity protection to transmitted data, AH protects the entire packet from modification, while ESP protects only the IP payload from modification.
ESP encrypts the TCP or UDP header and the application data included within an IP packet. It does not include the original IP header unless IPSec tunnel mode is used. Figure 9-4 shows how ESP modifies an IP packet.
Figure 9-4. ESP modifications to an IP packet
The ESP header has two fields that are inserted between the original IP header and the TCP or UDP header from the original packet:
• Security Parameters Index (SPI)
Identifies the SA that was negotiated between the source computer and the destination computer for IPSec communication. The combination of the SPI, the IPSec protocol (AH or ESP), and the source and destination IP addresses identifies the SA used for the IPSec transmission within the ESP packet.
• Sequence Number
Protects the SA from replay attacks. This field is incremented by 1 to ensure that packets are never received more than once. If a packet is received with a previous sequence number, thatbpacket is dropped.
The ESP trailer is inserted after the application data from the original packet and includes the following fields:
• Padding
A variable length from 0–255 bytes that brings the length of the application data and ESP trailer to a length divisible by 32 bits so that they match the required size for the cipher algorithm.
• Padding Length
Indicates the length of the Padding field. After the packet is decrypted, this field is used to determine the length of the Padding field.
• Next Header
Identifies the protocol used for the transmission of the data, such as TCP or UDP.
• Authentication Data
Contains the ICV, which verifies the originating host that sent the message and ensures that the packet was not modified in transit. The ICV uses the defined integrity algorithm to calculate the ICV. The integrity algorithm is applied to the ESP header, the TCP/UDP header, the application data, and the ESP trailer.
ESP provides integrity protection for the ESP header, the TCP/UDP header, the application data, and the ESP trailer. ESP also provides inspection protection by encrypting the TCP/UDP header, the application data, and the ESP trailer.
*********** WAIT FOR PART2 ************
About The Author
Amr Amin, Chief Architect, IT Compliance Andromeda Labs