Introducing IPsec
IPsec is an Internet Engineering Task Force (IETF) standard that defines how a VPN can be set up using the IP addressing protocol; it was originally defined in RFCs 2401 to 2412. IPsec works at the network layer, protecting and authenticating IP packets between participating IPsec devices (peers). IPsec is not bound to any specific encryption, authentication, or security algorithms or keying technology. IPsec is a framework of open standards.
Because IPsec is not bound to specific algorithms, IPsec allows newer and better algorithms to be implemented without patching the existing IPsec standards. IPsec provides data confidentiality, data integrity, and origin authentication between participating peers at the IP layer. IPsec secures a path between a pair of gateways, a pair of hosts, or a gateway and host, as shown in Figure 5-7.
IPsec provides the following essential security functions:
-
Confidentiality: IPsec ensures confidentiality by using encryption. Data encryption prevents third parties from reading the data, especially data transmitted over public networks or over wireless networks.
-
Integrity: IPsec ensures that data arrives unchanged at the destination; that is, that the data has not been manipulated at any point along the communication path. IPsec ensures data integrity by using checksums, which are a simple redundancy check. The IPsec protocol adds up the basic components of a message, typically the number of bytes, and stores the total value. IPsec performs a checksum operation on received data and compares the result to the authentic checksum. If the sums match, the assumption is that the data has not been manipulated.
-
Authentication: Authentication ensures that the connection is made with the desired communication partner. IPsec uses Internet Key Exchange (IKE) to authenticate users and devices that can carry out communication independently.
Note IKE is discussed in more detail in the section “IKE Protocol,” later in the chapter.
IKE uses several types of authentication:
-
Username and password
-
One-time password
-
Biometric
-
Pre-shared keys (PSK)
-
Digital certificates
-
-
Antireplay protection: Antireplay protection verifies that each packet is unique and is not duplicated. IPsec packets are protected by comparing the sequence number of the received packets with a sliding window on the destination host or security gateway. A packet that has a sequence number that comes before the sliding window is considered either late or a duplicate packet. Late and duplicate packets are dropped.
Key Topic | Essential services provided by IPsec are as follows:
|
Encryption Algorithms
The degree of security depends on the length of the key of the encryption algorithm. The time that it takes to process all the possibilities is a function of the computing power of the computer. Therefore, the shorter the key, the easier it is to break the key.
The following are some of the encryption algorithms and key lengths that VPNs use:
-
DES: DES was developed by IBM. DES uses a 56-bit key, ensuring high-performance encryption. DES is a symmetric key cryptosystem.
-
3DES: The 3DES algorithm is a variant of the 56-bit DES. 3DES operates in a way that is similar to how DES operates, in that data is broken into 64-bit blocks. 3DES then processes each block three times, each time with an independent 56-bit key. 3DES provides significant encryption strength over 56-bit DES. 3DES is a symmetric key cryptosystem.
-
AES: The National Institute of Standards and Technology (NIST) has recently adopted AES to replace the existing DES encryption in cryptographic devices. AES provides stronger security than DES and is computationally more efficient than 3DES. AES offers three different key lengths: 128-, 192-, and 256-bit keys.
-
Rivest, Shamir, and Adleman (RSA): RSA is an asymmetrical key cryptosystem. It uses a key length of 512, 768, 1024, or larger. IPsec does not use RSA for data encryption. IKE uses RSA encryption only during the peer-authentication phase.
-
Software-Optimized Encryption Algorithm (SEAL) algorithm: SEAL is a stream cipher, developed in 1993 by Phillip Rogaway and Don Coppersmith, and uses a 160-bit key for encryption.
Refer to the release notes of your specific security appliance version to confirm which algorithms are supported.
Encryption algorithms, such as DES and 3DES, explained in Chapter 4, “Fundamentals of Cryptography,” require a symmetric shared-secret key to perform encryption and decryption. You can use email, courier, or overnight express to send the shared-secret keys to the administrators of the devices. But the easiest key-exchange method is a public-key exchange method between the encrypting and decrypting devices.
Diffie-Hellman Exchange
The Diffie-Hellman (DH) key agreement, explained in Chapter 4, is a cryptographic protocol that provides a way for two peers to establish a shared-secret key, which only they know, even though they are communicating over an unsecure channel.
That shared-secret key, created by Diffie-Hellamn, is then used as the encryption key to exchanged data.
Data Integrity
VPN data is typically transported over the public Internet. Potentially, this data could be intercepted and modified. To guard against this problem, you can use a data-integrity algorithm, explained in this previous chapter. A data-integrity algorithm adds a hash to the message, which guarantees the integrity of the original message. If the transmitted hash matches the received hash, the message has not been tampered with. However, if there is no match, the message was altered.
A Hashed Message Authentication Code (HMAC) is a data-integrity algorithm that guarantees the integrity of the message. At the local end, the message and a shared-secret key are sent through a hash algorithm, which produces a hash value. The message and hash are sent over the network.
As explained in this previous chapter, there are two common HMAC algorithms:
-
HMAC-Message Digest 5 (HMAC-MD5): HMAC-MD5 uses a 128-bit shared-secret key of any size. The variable-length message and shared-secret key are combined and run through the HMAC-MD5 hash algorithm. The output is a 128-bit hash. The hash is appended to the original message and is forwarded to the remote end.
-
HMAC-Secure Hash Algorithm 1 (HMAC-SHA-1): HMAC-SHA-1 uses a secret key of any size. The variable-length message and the shared-secret key are combined and run through the HMAC-SHA-1 hash algorithm. The output is a 160-bit hash. The hash is appended to the original message and is forwarded to the remote end.
Authentication
When you are conducting business long distance, it is necessary to know who is at the other end of the phone, email, or fax. The same is true of VPN networks. The device on the other end of the VPN tunnel must be authenticated before the communication path is considered secure. Three peer-authentication methods exist:
-
PSKs: A secret key value is entered into each peer manually and is used to authenticate the peer. This is a shared secret that both parties must exchange ahead of time. See it as the secret password that they will be offering to each other to confirm the identity of the other party. At each end, the PSK is combined with other information to form the authentication key.
-
RSA signatures: A hash value of the message, encrypted with the sender’s private key. The encrypted hash is attached to the message and is forwarded to the remote end, and acts like a signature. At the remote end, the encrypted hash is decrypted using the public key of the sender. If the decrypted hash matches the recomputed hash, the signature is genuine.
-
RSA encrypted nonces: A nonce is a random number generated by the peer. RSA encrypted nonces use RSA to encrypt the nonce value and other values. This method requires that the public key of the two peers be present on the other peer before the third and fourth messages of an IKE exchange can be accomplished. For this reason, public keys must be manually copied to each peer as part of the configuration process, and therefore this method is limited by the available memory of the receiver. This method is the least used of the three authentication methods.
IPsec Advantages
One of the greatest strengths of IPsec is that is implemented at Layer 3 of the Open Systems Interconnection (OSI) model. As a result, IPsec can protect nearly all application traffic because the protection is implemented irrespective of whether Layer 4, Layer 5, Layer 6, or Layer 7 is used.
Because in all the implementations of IPsec there is a plaintext Layer 3 header, there are no issues with routing. Therefore, IPsec runs over all Layer 2 protocols, too; ATM, Ethernet, Token Ring, Frame Relay, Synchronous Data Link Control (SDLC), High-Level Data Link Control (HDLC), and others all work with IPsec data. IPsec is truly a universal protocol that works in almost every circumstance.
IPsec is also extremely scalable, as proven by the innumerable large organizations that use it.
IPsec exceeds SSL in many significant ways:
-
The number of applications supported
-
Its encryption strength
-
Its authentication strength
-
Its overall security
The one area in which SSL excels is its ease of use and ease of deployment. When security is the issue, IPsec is the superior choice. If ease of deployment and support is the primary issue, you should consider SSL.
Cisco VPN products support both technologies to satisfy the largest number of customer requirements.
Table 5-3 summarizes the differences between SSL VPN and IPsec VPN.
SSL | IPsec | |
---|---|---|
Applications | Web-enabled applications, file sharing, email. | All IP-based applications. |
Encryption | Moderate. (Key lengths range from 40 bits to 128 bits.) | Stronger. (Key lengths range from 56 bits to 256 bits.) |
Authentication | Moderate. (One-way or two-way authentication.) | Strong. (Two-way authentication using shared secrets or digital certificates.) |
Ease of use | Very high. | Moderate. (Can be challenging to nontechnical users.) |
Overall security | Moderate. (Any device can connect.) | Strong. (Only specific devices with specific configurations can connect.) |
IPsec Protocol Framework
IPsec is a framework of open standards. IPsec spells out the messaging to secure the communications but relies on existing algorithms. There are two main IPsec framework protocols, as depicted in Figure 5-8:
-
Authentication Header (AH): AH, which is IP protocol 51, is the appropriate protocol to use when confidentiality is not required or permitted. It provides data authentication and integrity for IP packets passed between two systems. It is a means of verifying that any message that is passed from Router A to Router B has not been modified during transit. It verifies that the origin of the data was either Router A or Router B. AH does not provide data confidentiality (encryption) of packets. All text is transported in the clear. If the AH protocol is used alone, it provides weak protection. Consequently, Encapsulating Security Payload uses the AH protocol to provide data encryption and tamper-aware security features.
-
Encapsulating Security Payload (ESP): ESP is a security protocol that can provide confidentiality and authentication. ESP, which is IP protocol 50, provides confidentiality by performing encryption on the IP packet. IP packet encryption conceals the data payload and the identities of the ultimate source and destination. ESP provides authentication for the inner IP packet and ESP header. Authentication provides data-origin authentication and data integrity. Although both encryption and authentication are optional in ESP, at a minimum, one of them must be selected.
Note | Figure 5-9 provides a visual representation of where IPsec fits in the layered model. |
Authentication Header
AH achieves authenticity by applying a keyed one-way hash function to the packet to create a hash, or message digest. The hash is combined with the text and is transmitted. The receiver detects changes in any part of the packet that occur during transit by performing the same one-way hash function on the received packet and comparing the result to the value of the message digest that the sender has supplied. The fact that the one-way hash also involves the use of a shared-secret key between the two systems means that authenticity is ensured.
The AH function is applied to the entire datagram except for any mutable IP header fields that change in transit; for example, Time to Live (TTL) fields that are modified by the routers along the transmission path. Figure 5-10 illustrates the AH process as follows:
Step 1 | The IP header and data payload is hashed. |
Step 2 | The hash builds a new AH header, which is prepended to the original packet. |
Step 3 | The new packet is transmitted to the IPsec peer router. |
Step 4 | The peer router hashes the IP header and data payload, extracts the transmitted hash from the AH header, and compares the two hashes. The hashes must match exactly. Even if 1 bit is changed in the transmitted packet, the hash output on the received packet changes and the AH header will not match. |
AH supports the HMAC-MD5 and HMAC-SHA-1 algorithms.
Note | AH protects the entire IP packet, which includes the IP header, against tempering during transmission. Because NAT modifies the IP header, it is incompatible with AH. Fixes, such as tunnel mode, discussed later, remedies this problem. Also, note that the PIX and ASA 7.x does not offer the AH option. Only ESP can be performed. |
Encapsulating Security Payload
ESP provides confidentiality by encrypting the payload. It supports a variety of symmetric encryption algorithms. The lowest common algorithm for IPsec is 56-bit DES. Cisco products also support the use of 3DES and especially AES for stronger encryption.
ESP can also provide integrity and authentication of the datagrams. First, the payload is encrypted. Next, the encrypted payload is sent through a hash algorithm, HMAC-MD5 or HMAC-SHA-1. The hash provides authentication and data integrity for the data payload.
Optionally, ESP can also enforce antireplay protection by requiring that a receiving host set the replay bit in the header to indicate that the packet has been seen.
The original data is well protected by ESP because the entire original IP datagram is encrypted, as shown in Figure 5-11. An ESP header and trailer are added to the encrypted payload. With ESP authentication, the encrypted IP datagram and the ESP header and trailer are included in the hashing process. Lastly, a new IP header is prepended to the authenticated payload. The new IP address is used to route the packet through the Internet.
When both authentication (AH) and encryption (ESP) are selected, encryption occurs first. One reason for this order of processing is that it facilitates rapid detection and rejection of replayed or bogus packets by the receiving device. Before decrypting the packet, the receiver can authenticate inbound packets. By doing this, it can quickly detect problems and potentially reduce the impact of denial-of-service (DoS) attacks.
Tunnel Mode Versus Transport Mode
ESP and AH can be used in two different ways referred to as modes. The encapsulation can be done in tunnel mode or in transport mode. The encapsulation performed on an ESP packet with each mode is illustrated in Figure 5-12:
-
Transport mode: In transport mode, security is provided only for the transport layer and above. Transport mode protects the payload of the packet but leaves the original IP address in the clear. The original IP address is used to route the packet through the Internet. ESP transport mode is used between hosts.
Note Transport mode works well with GRE because GRE hides the addresses of the end stations by adding its own IP header.
-
Tunnel mode: Tunnel mode provides security for the complete original IP packet. The original IP packet is encrypted, and then it is encapsulated in another IP packet. The outside IP address is used to route the packet through the Internet.
Tunnel Mode
ESP tunnel mode is used between a host and a security gateway or between two security gateways, as shown in Figure 5-13. For gateway-to-gateway applications, rather than load IPsec on all the computers at the remote and corporate offices, it is easier to have the security gateways perform the IP-in-IP encryption and encapsulation.
ESP tunnel mode is used in the IPsec remote-access application. At a home office, there might be no router to perform the IPsec encapsulation and encryption. In this case, an IPsec client running on the PC performs the IPsec IP-in-IP encapsulation and encryption. At the corporate office, the router de-encapsulates and decrypts the packet.
IPsec Framework
IPsec is a framework of open standards that spells out the rules for secure communications. IPsec, in turn, relies on existing algorithms to implement the encryption, authentication, and key exchange. The following are some of the standard algorithms that IPsec uses:
-
DES: Encrypts and decrypts packet data
-
3DES: Provides significant encryption strength over 56-bit DES
-
AES: Provides stronger encryption, depending on the key length that is used, and faster throughput
-
MD5: Authenticates packet data, using a 128-bit message digest
-
SHA-1: Authenticates packet data, using a 160-bit message digest
-
DH: Allows two parties to establish a shared-secret key that is used by encryption and hash algorithms (for example, DES and MD5) over an unsecure communications channel
In Figure 5-14, there are four IPsec framework squares to be filled in. When you configure an IPsec gateway to provide security services, you must first choose an IPsec protocol. The choices are ESP or ESP with AH. AH can also be used alone. The second square is an encryption algorithm. Choose the encryption algorithm appropriate for the desired level of security: DES, 3DES, or AES. The third square is authentication. Choose an authentication algorithm to provide data integrity: MD5 or SHA. The last square is the DH algorithm group. Choose which group to use, DH Group 1 (DH1), DH Group 2 (DH2), or DH Group 5 (DH5). IPsec provides the framework, and the administrator chooses the algorithms that are used to implement the security services within that framework.
0 comments
Post a Comment