Summary

At this point, you should be familiar with all of the cryptographic components used to create an IPsec VPN. Additionally, you should also be aware of the fundamental mechanics that underpin the establishment of an IPsec VPN itself. The material we've covered thus far is dissected into several major topics that build upon one another:

• Overview of Cryptographic Components

• Overview of IPsec Operation

• Overview of ISAKMP Operation

As we've discussed earlier in this chapter, IPsec relies on many fundamental cryptographic operations to provide authenticity, integrity, confidentiality, and nonrepudiation services to IP data transmissions. Examples of such cryptographic components discussed include hashing functions and message digest creations, Digital Signatures, asymmetric key encryption, and symmetric key encryption.

A secure hash ensures data integrity by performing a mathematical operation based on the original contents of the cleartext message. The resulting value of this mathematical operation is called a message-digest. The sender appends the message digest to the cleartext message and sends both to the receiver. The receiver then performs the same mathematical operation, or hash, on the received cleartext message. The results of this mathematical operation are then compared to the message digest sent from the sender. If the receiver's message digest compares to the sender's message digest, then the message's integrity has not been compromised. In this operation, data authenticity, sender nonrepudiation, or confidentiality have not been provided.

A Digital Signature provides data integrity, just as a hash function would. However, unlike a simple message digest, Digital Signatures also provide data authenticity and sender nonrepudiation. Digital Signatures do this by performing a hash based on the original message contents and a public cryptographic key (of a public/private asymmetric keypair). The resulting message digest is then encrypted with the private key of the asymmetric key pair, resulting in a Digital Signature. The sender sends its public key, the original cleartext message, and an appended Digital Signature to the receiver. The receiver then decrypts the Digital Signature with the public key received from the sender. At this point, the receiver performs the same hashing function on the cleartext message contents and the public key received from the sender. If the resulting message digest matches the decrypted message digest received from the sender, then the message is said to be authentic with preserved data integrity. Note that the original message was sent in the clear, and that Digital Signatures therefore do not provide data confidentiality services to the original message.

In different areas of the IPsec framework (including IKE), encryption and decryption can occur in one of two ways: symmetric key encryption and asymmetric key encryption. Symmetric key encryption refers to a cipher algorithm that uses the same key for encryption and decryption. Symmetric key encryption is therefore not suited for sharing keys over an untrusted medium. IPsec uses symmetric key transforms in its Phase II SA, as symmetric key transforms are better suited for bulk data transfer. Examples of symmetric key encryption ciphers include DES, 3DES, and AES.

Asymmetric key encryption refers to a cipher algorithm that uses one key for encryption (typically the public key) and one key for decryption (typically the private key). Asymmetric key encryption provides increased flexibility with key exchange, enabling a public key to be exchanged over a relatively untrusted medium. Asymmetric encryption, however, is computationally more expensive than symmetric encryption and is therefore less suited to performing bulk data transfer. IKE commonly uses asymmetric key encryption for Phase I SA authentication. Examples of such asymmetric key encryption techniques include RSA-encrypted nonces and RSA Signatures.

IPsec provides data authenticity, sender nonrepudiation, data integrity, and data confidentiality. At this point, we've discussed the mechanics of IPsec with and without IKE. Because IPsec ciphers require a symmetric key for bulk data encryption, keys must be defined manually on IPsec endpoints when IKE is not used. IPsec secures data by creating two unidirectional security associations between the two cryptographic endpoints. Those security associations specify the following components required to secure data transmissions between the endpoints:

• IPsec Transform Mode: IPsec operates in either tunnel or transport mode.

• IPsec Symmetric Transform: This is the cipher to be used when encrypting data. Examples include DES, 3DES, and AES.

• IPsec Peer: Defines the opposite end of the IPsec tunnel.

• Traffic Encryption/Decryption Sets (Crypto ACL): The two endpoints must agree on the encryption and decryption data sets to successfully negotiate an IPsec SA.

• Path MTU: Defines the MTU for the path along the IPsec SA.

• Security Parameter Index (SPI): The SPI is a unique identifier that the cryptographic endpoint uses to select an SA when processing cleartext data matching a valid crypto ACL

• Security Association Lifetimes: Lifetimes specify the useful life of an IPsec SA.

IPsec specifies two protocols for data transformation: ESP, IP Protocol 50 or AH IP Protocol 51. ESP provides data confidentiality, while AH does not. Yet AH provides a broader scope of data authenticity and integrity than does ESP. In addition to the symmetric transform executed with AH or ESP, optional HMAC authentication can be performed on the data cipher blocks using either MD5 or SHA-1 hash algorithms.

As we've discussed thus far, IPsec must use symmetric key transforms for bulk data ciphering. This requires that the symmetric key must be manually defined for every SA on each cryptographic endpoint. This presents substantial key and SA management scalability issues. The IKE protocol can be used in conjunction with IPsec to dynamically negotiate the elements required to establish an IPsec (Phase II) SA over an untrusted medium. IKE does this by first establishing an authenticated, secure channel across the untrusted medium using either one of three authentication methods:

• PSKs: Keys used to negotiate are manually defined by the administrator on the crypto endpoints.

• RSA Encrypted Nonces: public/private RSA keypairs are generated on the crypto endpoints. Public keys are then manually shared with remote endpoints.

• RSA Signatures: RSA public/private keypairs are generated on the crypto endpoints. Cryptographic endpoints then use a central, commonly trusted entity (a Certificate Authority) to facilitate key exchange.

The secure channel that IKE creates is referred to as the IKE security association (Phase I SA). This SA can be created using one of two modes: main mode or aggressive mode. Though main mode requires more exchanges to establish a Phase I SA, IKE main mode is more secure than aggressive mode as IKE aggressive mode sends both sender and receiver identities in cleartext. Once an IKE SA is established securely, an IPsec SA (Phase II) can be negotiated over the secure channel provided by IKE. This enables both cryptographic endpoints to agree upon Phase II lifetimes, SPIs, peers, cipher methods, and symmetric keys over the network. Unlike IPsec without IKE, cryptographic endpoints that have established a Phase I SA execute Diffie-Hellman over the Phase I SA to derive joint symmetric keys to use when ciphering data with their agreed-upon symmetric key transforms.

In this chapter, we use cryptographic building blocks to lay the foundation for building an understanding of IPsec and IKE mechanics. We've covered the fundamental operation of IPsec without IKE (manual keying) and the operation of IPsec with IKE. The information presented in this chapter on cryptographic components, IPsec, and IKE will serve as the foundation for developing an understanding of basic IPsec deployment topologies, common troubleshooting issues with IPsec VPNs, and resilient IPsec VPN design strategies presented in subsequent chapters.