Digital Certificate Advantages

Digital certificates offer a significant advantage over preshared keys. Relevant to this discussion, digital certificates allow IPSec device and client identities to be bound to their own public/private key pair. This is the equivalent to providing a digital ID card for each IPSec device on the network.

A digital certificate is a signed digital ID that contains identification information and the owner's public key. Illustrated in Figure 5.1, the digital certificate contains identity information from the client requesting the certificate (located in the Subject field), as well as the identity of the certificate's issuing authority. Furthermore, the issuing authority digitally signs the certificate (in the MD5 Fingerprint field) so that authenticating devices can substantiate that it came from a trusted authority. Notice that the certificate also contains validity dates and a serial number. Devices receiving this certificate use these fields to verify that the certificate has not expired or been revoked. Finally, a key (no pun intended) component of the digital certificate is the certificate owner's public key. This key can be exchanged among peers for asymmetric encryption, as well as to validate digital signatures.

Figure 5.1. X.509v3 digital certificate.

These certificates can be encoded in several formats, but the most prevalent of supported formats is the ITU-T Recommendation X.509 specification. The Cisco VPN 3000 Concentrator and clients support version 1, 2, and 3 of the X.509 certificate.

Recall that digital signatures can be used during IKE negotiations as a means to authenticate a connecting device or client. This device-level negotiation occurs directly after IKE SA negotiations and the Diffie-Hellman key exchange as illustrated in Figure 5.2. As previously discussed, both sides of a tunnel endpoint must contain each other's public key to verify received signed messages. When both sides send a hash of their identity information, they digitally sign the hash with their own private key. To validate the signed message, the tunnel endpoints send a digital certificate containing their public key along with the identity hash data. When the IPSec peer receives the certificate, it ensures that the certificate is valid and uses the contained public key to verify the digital signature of the identity data. Because the recipient of the signed data authenticates the sender by using the sender's public key to decrypt the data, only the owner of the private key could have truly signed the data. However, because a public key has no intrinsic association to the source, you have to rely on a trusted third-party authority, known as a certificate authority (CA), to endorse the identity of the sender.

Figure 5.2. IKE negotiations entailing digital signatures and digital certificates.

Certificate Authorities

Imagine you are friends with a famous rock band (like so many of us are). One day, at one of their concerts, you decide to go backstage and catch up on old times. Unfortunately, there is a bouncer there who will not allow anybody backstage who is not on his list. Lucky for you, the drummer of the band walks by and the bouncer asks the drummer whether he knows you. Because the drummer recognizes you as an old friend and the bouncer trusts the drummer, you are allowed to go backstage.

Certificate authorities work in the same manner as the drummer of the band. When all IPSec devices are registered with this trusted third-party, they can look toward the certificate authority to be a trusted agency for verifying the identity of the user. As long as your digital certificate is valid from a trusted CA, authenticating devices that also trust that CA have to assume that the authenticating party is who it claims to be. The more reputable the CA, the more likely it is to have IPSec peers trust that same CA. Obviously, the trust relationship between the bouncer and the drummer diminishes the relevance of this point; however, it is important to note that the security measures, policies, and operations that a CA provides is the basis of the trust relationship with that CA.

The CA is responsible for creating digital certificates, and thus, forms trust relationships with all other peers. When a device wants to enroll with a certificate authority, it provides identity credentials that the CA certifies as authentic. The CA issues an identity certificate containing the requestor's information, the requestor's public key, and some of the CA's information. When the certificates are created, the CA signs them with its own private key. All devices that wish to validate this certificate (including the requestor) must contain the CA's certificate and use its enclosed public key to verify the CA signature.

Identity certificates are used during the IKE negotiations to bind a public key to a device. As soon as two IPSec peers want to authenticate each other, they exchange their CA-signed digital certificates. Each device needs to validate the CA's signature by using the trusted CA's public key (derived from the CA's digital certificate). After the certificate is validated with a known CA, the device can use the sender's public key (contained in the identity certificate) to authenticate signed messages or to encrypt outgoing data destined for that peer. When new IPSec devices are added to the network, they only need to enroll with the trusted CA. This, in turn, enables them to authenticate with all other IPSec peers.

Several third-party vendors exist for fulfilling this role as a CA for your network. Vendors such as Verisign, Baltimore Technologies, Thawte, and Entrust all provide public certificate authority services. It is also possible to provide your own internal CA by utilizing Windows 2000 as a certificate server.

Public Key Infrastructures

A public key infrastructure (PKI) is a set of security services that entail the certificate authorities and all their client applications working in a unified framework. A small PKI infrastructure might use a single CA server to perform all certificate functions. This single CA server, known as the root CA server, is the point of common trust and is capable of signing its own certificates. In this flat design (known as a central or stand-alone CA structure), the root CA is responsible for issuing, signing, and revoking identity certificates. However, it is common within large infrastructures to contain a hierarchy of CA servers, which can help manage and control certificate distribution, as well as certificate revocation. These are often referred to as Enterprise or tiered hierarchy CAs. In this hierarchical design, the certificate authorities form what is called a certificate chain, in which subordinate CAs enroll with the root CA. The root CA maintains a hierarchy of trust by validating the subordinate CAs and signing and issuing their digital certificates. Requesting devices, in turn, request identity certificates that are signed and issued by their local subordinate CAs. To authenticate an IPSec peer's identity certificate, they use the subordinate CA's public key to verify the signed certificate.

Likewise, the subordinate CA is validated with the public key of the root CA thus the chain effect. Figure 5.3 provides an example of the two types of certificate authority designs.

Figure 5.3. Central and hierarchical CA designs.

It is quite common for the root CA to be taken offline and physically secured, only to be brought back online when a subordinate CA certificate needs to issued, renewed, or revoked. In addition, CAs often delegate identification and authentication of subscribers to entities known as Registration Authorities (RAs). RAs act as a proxy to the CA and offload the tedious identity verification so the CA can concentrate on issuing, signing, and revoking certificates. Furthermore, RAs typically are not empowered to sign or issue certificates.

Certificate Revocation and Validation

Certificate authorities not only have to create and administer certificates, they also are responsible for revoking any invalid certificates. These certificates are revoked in instances such as an organization change, service removal, name change, or security compromise. When these occurrences take place, the CA must generate a list known as a certificate revocation list (CRL), which contains a list of certificate serial numbers and their revocation dates. This list is digitally signed from the CA and enables the hosts to be notified of these revoked certificates.

When a device receives a certificate, it must ensure that the certificate is valid. To guarantee the certificate is legitimate, the device must inspect the contents of the certificate and ensure that it has not expired. When a certificate is created from a CA, it sets a "valid from" and a "valid to" date. If the device's localtime is not in between these times, the host does not allow the certificate for authentication.

Recall that the Quick Configuration asks you to set the time and date in the opening dialogue. This step is imperative to ensure proper validation of digital certificates. Because the certificate validity ranges are compared to the system clock, you must ensure that the clock is always configured correctly.

The CA root (or subordinate) certificate must be installed on the device to validate the identity certificate. Root or subordinate certificates contain the CA's public keys, which are used to verify installed or proposed identity certificates. The device uses the public key of the CA to validate the digitally signed identity certificate that was issued from that CA. The local concentrator who receives a certificate from the subordinate CA uses the subordinate CA's public key to validate the identity certificate, but the root CA public key is used to validate the subordinate CA's public key. When climbing this certificate chain, you eventually reach the root certificate, which is self-signed and is trusted solely on the fact that it is the root CA.

A final validation step, if enabled, is when the device checks against a Certificate Revocation List (CRL) to ensure that an issued certificate has not been revoked by a certificate authority. When the device receives a digital certificate for authentication, it compares the serial number of the certificate to the CRL that was provided by the CA or subordinate CA. If the serial number appears on the list, the peer is not authenticated.