IPSec accomplishes IP traffic security by adding IPSec headers to original IP datagrams. These new IPSec headers, such as AH and ESP, can be used separately or combined together depending on the desired degree of security requirements. Essentially, the headers are added selectively to an original IP packet for the purpose of authenticating the packet as a trusted packet or encrypting the packet for ultimate data protection, or both.
Security associations (SAs) are an important part of the IPSec process as they define a level of trust between two devices in an IPSec peer-to-peer relationship. Through SAs, end devices agree on the security policies that will be used and identify the SA by an IP address, a security protocol identifier, and a unique security parameter index value. There are two types of SAs. A key exchange SA is formed first to authenticate the peers, exchange keys, and manage the keys afterward. Once this SA is formed, the IPSec SAs (one per traffic direction) are negotiated and formed, each agreeing on an authentication method, a hashing algorithm, and an encryption algorithm.
Authentication Header (AH)
The AH uses a keyed-hash function, implemented in hardware application-specific integrated circuits (ASICs) for speed, to apply integrity and authenticity functions to the transmitted data. AH authenticates an origin host with a destination host through the establishment of a key authentication exchange. A variety of complex authentication key methods and options are available with which to establish IPSec communications. Some of these are listed here:
•
IKE based on ISAKMP/OAKLEY—The IKE is a hybrid key exchange protocolwhich uses part Oakley and part of another protocol called SKEME within the Internet Security Association and Key Management Protocol (ISAKMP) framework. Keys are preshared either manually or via a certificate authority, and the key exchange and validation is performed by IKE. Peers validate each other based on the IKE process and form an IKE security association. This happens before any IPSec SAs are negotiated and before traffic can pass over the established link.
IP Security (IPSec) 167
•
Diffie-Hellmann 1, 2, and 5—Diffie-Hellman is a key agreement protocol forderiving a shared secret key between two IPSec parties. It is a method for secure exchange of keys that are subsequently used for the data encryption process. Diffie- Hellman is the basic mechanism of the Oakley key exchange protocol used in the IKE process. There is an extended version called authenticated Diffie-Hellman or Station- to-Station (STS) protocol, which allows two parties to authenticate themselves to each other through the use of digital signatures and public key certificates. This mitigates the “man-in-the-middle” attack exposure of the original Diffie-Hellman protocol.
•
Preshared key—A preshared key is manually configured on each end of a device thatwill create an IPSec SA. The preshared key is used as a seed to generate a secret key. This is the simplest form of creating the public key and is used with each party’s private key for deriving the shared secret keys for the IPSec SAs. Preshared keys have exposure to key intercept by attackers and are more difficult to scale in large IPSec implementations.
•
RSA digital certificates—These are digital documents that bind a public key to aparticular individual or other entity. These are third-party certifications to validate a user as the original certificate issuer and deny any key exchange that appears to be an impersonation using a phony key. Digital certificates are often used to help scale IPSec implementations much more easily than through the use of preshared keys.
•
Perfect Forward Secrecy (PFS) rekeying—The use of PFS allows more security inthe event that a secret key was broken by an attacker. It separates the IKE-derived secret key from the process used to create the keys for the IPSec SAs. That is, the IKE key for the IKE SA can be broken, but this will not help reveal the secret keys that make up the IPSec SAs in either traffic direction. The rekeying option allows for this key association to change on a very frequent interval—essentially keys are changing all the time while keeping the sessions alive.
The result of establishing a key exchange between two IPSec peer devices creates both an IKE SA and a pair of IPSec SAs, typically one for each traffic direction. This provides a secure transmission framework to provide an IP packet with data integrity, because it is validated by the resident AH as a true, originating IP packet from the source IP host. Although the AH doesn’t make the IP packet’s data payload undecipherable, it does create a sort of tamper-evident seal so that you can ensure the originality and authenticity of the transmitted data.
For IPSec to maintain data integrity as it crosses public networks, the AH uses hash methods such as Message Digest 5 (MD5) from RSA Data Security or the Secure Hash Algorithm 1 (SHA-1) as defined by the U.S. government. These are applied to the origin packet’s IP header, which conceals things like the host IP address and other parameters from public view. The hash method is reversed at the destination end to restore the original IP header to full view so that the packet can be routed within the destination IP subnet. The extra processing of these security algorithms, necessary for every packet, is normally hardware accelerated to increase IPSec performance.
Encapsulating Security Payload (ESP)
If absolute confidentiality of the IP packet’s data payload is required, then data encryption is necessary. In this case, an ESP header and encryption algorithms such as DES or Triple DES (3DES) are added for this level of data fortification. As a result, ESP completely encapsulates user data. The Data Encryption Algorithm (DEA), more commonly referred to as the Data Encryption Standard (DES)—specifically the 168-bit version known as 3DES—is the most commonly used encryption algorithm. Blowfish is another example of a data encryption algorithm. Due to stronger encryption (128 bit, 192 bit, and 256 bit) and faster performance, the newer AES, introduced to the market in November of 2002, is gaining popularity and deployment.
ESP can be used in combination with AH, but ESP contains the same data origin authenti- cation and antireplay mechanisms that are present in AH. As such, ESP can use the same key exchange techniques used for AH. This allows ESP to be solely used for IPSec traffic when robust data confidentiality is desired. An example of when to use both the AH and ESP headers is when you need the strongest confidentiality (ESP) and the strongest authen- tication (AH), because AH will additionally protect the new IP header field, while ESP doesn’t.