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: - Peers communicating on a secure
network
- At least one certificate authority (CA) to
grant and maintain certificates
- Digital certificates,
which contain information such as the certificate validity
period, peer identity information, encryption keys that are
used for secure communications, and the signature of the
issuing CA
- An optional registration authority (RA) to
offload the CA by processing enrollment requests (Certificate
enrollment is the process of obtaining a certificate from a
CA.)
- A distribution mechanism, such as Lightweight
Directory Access Protocol (LDAP) or HTTP, for certificate
revocation lists (CRLs)
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:
- Large and very active networks in which a large number of
certificates are revoked and reissued. A multiple tier CA helps
to control the size of the CRLs.
- When online
enrollment protocols are used, the root CA can be kept offline
with the exception of issuing subordinate CA certificates. This
scenario provides added security for the root CA.
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