and higher layer protocols, but leaves the original IP address unprotected. The original IP address is used to route the packet through the Internet. ESP transport mode is used between two hosts. When IPsec tunnel mode is used, IPsec encrypts the IP header and the payload. Tunnel mode provides the protection of an entire IP packet by treating the packet as an AH or ESP payload. With tunnel mode, an entire IP packet is encapsulated with an AH or ESP header and an additional IP header. ESP tunnel mode is used between a host and a security gateway or between two security gateways. 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. In the IPsec remote access application, ESP tunnel mode is used. At a home office, there may be no router or firewall to perform the IPsec encapsulation and encryption. In the example in Figure , the 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.
Content 3.2 Understanding IPsec Components and IPsec VPN Features 3.2.9 Message Authentication and Integrity Check VPN data can be transported over the public Internet. Potentially, this data could be intercepted and modified. To guard against the chance of interception, each message has a hash attached to the message. A hash provides a way to guarantee the integrity of the original message: If the transmitted hash matches the received hash, the message has not been tampered with. However, if the hashes do not match, the message was altered. The HMAC is used for message authentication and integrity check. HMAC can be used with any iterative cryptographic hash function, such as MD5 or SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. HMAC also uses a secret key to calculate and verify the message authentication values. MD5 and SHA-1 are examples of such hash functions. The two commonly used IPsec hash functions are shown in Figure . MD5 is well known from various uses in Cisco components, such as hashing passwords in the Cisco IOS software. Both hash functions take some variable length input message and create a fixed-length hash. MD5 creates a 128-bit hash, while SHA-1 creates a 160-bit hash. In the case of SHA-1, only 96 bits of this hash are used for IPsec. The initialization vector (IV) is used as an initial value to start creating a hash.
Content 3.2 Understanding IPsec Components and IPsec VPN Features 3.2.10 PKI Environment A public key infrastructure (PKI) enables Internet users to securely and privately exchange data and money using a public and a private cryptographic key pair that is obtained and shared through a trusted authority. A PKI provides a hierarchical framework for managing digital security attributes of entities that will engage in secured communications. In addition to human users, there are encryption gateways, secure web servers, and other resources that require close control of identity and encryption. As shown in Figure , the PKI environment can sometimes appear as a jigsaw puzzle. A PKI consists of these entities: PKI provides customers with a scalable, secure mechanism for distributing, managing, and revoking encryption and identity information in a secured data network. Every entity (a person or device) participating in the secured communications is enrolled in the PKI in a process in which the entity generates an RSA key pair (one private key and one public key) and has its identity validated by a trusted entity (also known as a CA or trust point). After enrolling in a PKI, each peer (also known as end host) in a PKI is granted a digital certificate that has been issued by a CA. When peers must negotiate a secured communication session, they exchange digital certificates. Based on the information in the certificate, a peer can validate the identity of another peer and establish an encrypted session with the public keys that are contained in the certificate. Certificate Authority
A CA, or trustpoint, manages certificate requests and issues certificates to participating network devices. Managing certificate requests and issuing certificates provide centralized key management for the participating devices. The CA is explicitly trusted by the receiver to validate identities and to create digital certificates. Before any PKI operations can begin, the CA generates a public key pair for itself and creates a self-signed CA certificate; thereafter, the CA can sign certificate requests and begin peer enrollment for the PKI. You can use a CA provided by a third-party CA vendor, or you can use an internal CA, which is the Cisco IOS Certificate Server. Hierarchical PKI: Multiple CAs
You can set up a PKI in a hierarchical framework to support multiple CAs. At the top of the hierarchy is a root CA, which holds a self-signed certificate. The trust within the entire hierarchy is derived from the RSA key pair of the root CA. The subordinate CAs within the hierarchy can be enrolled with either the root CA or with another subordinate CA. These enrollment options enable multiple tiers of CAs to be configured. Within a hierarchical PKI, all enrolled peers can validate the certificate of each other if the peers share a trusted root CA certificate or a common subordinate CA. Multiple CAs provide users with added flexibility and reliability. For example, subordinate CAs can be placed in branch offices while the root CA is at the office headquarters. Also, different granting policies can be implemented per CA, so you can set up one CA to automatically grant certificate requests while another CA within the hierarchy requires each certificate request to be manually granted. There are two scenarios in which at least a two-tier CA is recommended: X.509 v3 Certificate
Certificates can be used for the large-scale use of public key cryptography. Securely exchanging secret keys among users becomes impractical for large networks.
A certificate can be revoked if the certificate’s related private key is discovered to be compromised, or if the relationship between an entity and a public key, embedded in the certificate, is discovered to be incorrect or has changed. Any of these corruptions might occur, for example, if a person changes jobs or names. A revocation is a rare occurrence, but the possibility of revocation means that even when a certificate is trusted, the user should always check its validity. You can check certificate validity by comparing the certificate against a CRL, a list of revoked or cancelled certificates. Ensuring that such a list is up to date and accurate is a core function in a centralized PKI. To be effective, the certificate must be readily available to anyone and must be updated frequently. The other way to check certificate validity is to query the CA using the Online