CA Support Overview

With public/private key encryption technology, each key is a unique encryption device. If, in fact, no two keys are ever identical, it’s possible to use a key to identify its owner. Keys are always created and used in pairs: one is the private key; the other is the public key. You can then encrypt data with the public key, which only the corresponding private key can decrypt.

The public key can be distributed to anyone who needs to share secure information with the owner of the private key. The private key, on the other hand, is never duplicated or distributed to anyone: it remains secure on the owner’s computer or server. While not as secure as limiting keys to pairs, the same public key can be duplicated and distributed to multiple users who need to share information with the private key owner. The public key holders would be unable to exchange information using the shared key. The downside is the public key no longer identifies a unique host.

A fundamental problem with public key cryptosystems is this: all users must be careful to make sure they’re always encrypting to the correct person’s key. In an environment where keys can be physically exchanged in person or configured by a single administrator, this shouldn’t be a problem. Unfortunately, neither of these key-exchange methods scales well, particularly over large geographical areas. One common solution for key exchanges is to use public servers, such as e-mail servers. Unfortunately, the threat of man-in-the-middle attacks must be considered a potential threat. Figure 11-1 shows Rtr1 communicating securely with Rtr10, using a public key BCD sent to Rtr10. The attacker can see the traffic, but can’t decrypt it.

Figure 11-1: Rtr1 sharing secure data with Rtr10 using a public key

In the man-in-the middle scenario, the culprit posts a phony public key using the real name and user ID of the legitimate holder of the private key with whom the user expects to share data. Now any data encrypted using the phony public key can only be decrypted by the holder of the matching private key—the attacker. In Figure 11-2, the hacker has posted a new public key using Rtr1’s name and ID. Rtr10, not realizing the ruse, implements the new key. The attacker can now decrypt the traffic, but Rtr1 can’t.

Figure 11-2: The attacker and Rtr10 now share a key, allowing the attacker to decrypt the messages.

In a public key environment, it’s absolutely critical that the public key used to encrypt data is, in fact, a legitimate public key of the intended recipient and not a forgery. Common sense indicates that requiring an administrator to configure both devices or physically deliver the public keys won’t scale well. Even if this is physically possible, the process would present a significant cost burden, even in regional networks. There must be another way. Digital certificates (certs) can simplify the task of sharing public keys, while verifying the public key belongs to the “real” owner.

Digital Certificates

A digital certificate is a form of credential much like a driver’s license or a passport in the paper-based world. Like its paper counterparts, the digital certificate has information on it that identifies the holder, plus some uninvolved third-party authorization, which indicates they confirmed the holder’s identity.

A digital certificate has additional information included with the holder’s public key that helps others to verify the key is genuine. This additional information, like a person’s picture on a driver’s license or a passport, can thwart attempts to substitute an unauthorized public key.

A digital certificate contains the following three items:

Public key
Certificate information—Identifying information about the holder, such as ID, name, and so forth
One or more digital signatures

The digital signatures indicate the certificate information was verified and attested to by a trusted independent third party. Understanding that the digital signature doesn’t guarantee the authenticity of the certificate as a whole is important. What it verifies is only that the signed identity information belongs to or is bound to the attached public key. Don’t let this get too complicated. In the case of a passport, the government is verifying that the picture and identifying information belong to the passport number. But, the passport can be expired or revoked by a court order. Similarly, digital certificates can expire or be revoked.

Conceptually, a digital certificate is a public key with a tag containing one or more forms of ID, plus a seal of approval by a trusted third party. Figure 11-3 shows a conceptual representation of a digital certificate.

Figure 11-3: Conceptual representation of a digital certificate

Certificate Distribution

Chapter 10 looked at preshared public keys, but this manual distribution method is only practical to a certain point. After that, having an exchange system that can provide the necessary security, storage, and exchange mechanisms becomes necessary, so coworkers, business partners, and even strangers could establish secure communications, if necessary.

These public key exchange systems can take the form of storage-only repositories called Certificate Servers, or they can be much more structured systems providing additional key management features. These latter systems are called Public Key Infrastructures.

Certificate Servers

A certificate server, also called a cert server or a key server, is a database service running on an existing or dedicated server that allows users to submit and retrieve digital certificates. The cert server typically offers additional administrative features that allow the company to implement and maintain its security policies. For example, the cert server can be configured to allow only certain types of keys to be stored.

Public Key Infrastructures (PKI)

A Public Key Infrastructures (PKI) includes the storage capabilities of a certificate server, but it also provides additional certificate management functions, such as the capability to issue, store, retrieve, revoke, and trust certificates. A powerful feature of a PKI system is the concept of a Certification Authority (CA). CAs are responsible for managing certificate requests and issuing certificates to participating IPSec network peers. These services provide centralized key management for the participating peers. CAs simplify the administration of IPSec network devices (peers) in networks containing multiple IPSec-compliant devices, such as with the Cisco Secure PIX Firewall units and Cisco routers.

The CA creates the digital certificate, and then digitally signs it using its own private key. Any CA client can then use the shared CA public key to authenticate a certificate’s digital signature and, thereby, the integrity of the certificate contents, including the certificate holder public key and the identity of the certificate holder.

Conceptually, the CA functions in the digital environment much like the government passport or driver’s license office in the nondigital world.

IPSec with CAs

When using IPSec with a CA, configuring keys among all the potential IPSec peers isn’t necessary. Instead, each participating device is individually enrolled with the CA, requesting a certificate for the device. Once this is done, each participating device can dynamically authenticate itself to all the other participating peers.

Adding a new IPSec device to an existing network is similarly simplified. In each case, it’s only necessary to configure the new device to request a certificate from the CA.

How CA Certs Are Used by IPSec Peers

As you learned in Chapter 9, any time two IPSec peers want to establish an IPSec-protected communication session between them, they must first authenticate each other. This authentication is done with IKE and, without it, IPSec protection can’t occur.

Without a CA, the peers authenticate themselves to the remote peer, using either preshared keys (Chapter 10) or RSA-encrypted nonces (see the section “RSA Encrypted Nonces Overview.”) Both methods require previously configured keys on both peers. PIX Firewall devices currently don’t support RSA-encrypted nonces.

With a CA, each peer authenticates itself by sending a valid digital certificate to the remote peer. The peer’s unique certificate was issued and validated by the CA, encapsulates the peer’s public key and IDs, and works because all participating peers recognize the CA as an authenticating authority. This process is called IKE with an RSA signature.

Each peer can continue sending its own certificate for additional IPSec sessions, as well as to additional IPSec peers, until the certificate expires. When a certificate expires, the peer administrator must request a new one from the CA.

Certificate Revocation List (CRL)

CAs can revoke otherwise valid certificates for peers that will no longer participate in IPSec. These revoked certificates are listed in a certificate revocation list (CRL), which each peer can check before accepting another peer’s certificate. Revoked certificates, like expired passports or driver’s licenses, aren’t recognized as valid by other peers.

Registration Authority (RA)

Some CAs extend their reliability and availability by supporting registration authority (RA) as part of their implementation. An RA is a server that acts as a proxy for the CA, so CA functions can continue when the CA is offline or otherwise unavailable.

Cisco IOS CA Standards

Cisco IOS supports the following open CA standards:

Internet Key Exchange (IKE) A hybrid protocol that implements Oakley and Skeme key exchanges inside the ISAKMP framework. IKE is covered in Chapters 9 and 10.
Public-Key Cryptography Standard #7 (PKCS #7) A standard developed by RSA Data Security, Inc. used to encrypt and sign certificate enrollment messages.
Public-Key Cryptography Standard #10 (PKCS #10) A standard syntax developed by RSA Data Security, Inc. for certificate requests.
RSA Keys RSA is the public-key cryptographic system developed by RSA Data Security, Inc. RSA keys come in pairs: one public key and one private key.
X.509v3 Certificates An X.509 certificate is a collection of a standard set of fields containing information about a user or device and their corresponding public key. The X.509 standard defines what information goes into the certificate and describes how to encode it (the data format). The encoded information is used with the IKE protocol when authentication requires public keys.

Simple Certificate Enrollment Protocol (SCEP)

Developed by a Cisco, Verisign, Entrust, Microsoft, Netscape, and Sun Microsystems initiative, Simple Certificate Enrollment Protocol (SCEP) provides a standard way of managing the certificate lifecycle. This initiative is important for furthering open development for certificate handling protocols that can help ensure interoperability with devices from many vendors.

SCEP provides the following two authentication methods:

Manual authentication
Authentication based on a preshared secret

Manual Mode

In the Manual mode, the entity that submits the request is required to wait until the CA operator can verify its identity, using any reliable out-of-band method. An MD5 hash “fingerprint” generated by and included in the PKCS10 must be compared out-of-band between the SCEP clients and CAs (or RAs, if appropriate) to enable verification.

Preshared Secret Mode

With a preshared secret method, the CA server distributes a shared secret to the end entity, which can then be used to associate an enrollment request uniquely with the end entity. To maintain the integrity of the method, the distribution of the shared secret must be private, allowing only the end entity to know the secret.

Challenge Passwords

When an enrollment request is initiated, the end entity is asked to provide a challenge password. With the preshared secret method, the end entity must type in the distributed secret as the password. With the manual authentication method, the challenge password is also required because the server might challenge an end entity for a password before any certificate can be revoked. Eventually, the challenge password is included as a PKCS#10 attribute and is sent to the CA server as encrypted data. The PKCS#7 envelope protects the privacy of the challenge password using DES encryption.

CA Servers Interoperable with Cisco Routers

CA interoperability permits Cisco IOS devices, PIX Firewalls, Cisco VPN Hardware devices, and CA servers to communicate so the VPN device can obtain and use digital certificates supplied by the CA. While IPSec can be implemented in the network without using a CA, the CA with SCEP provides enhanced manageability and scalability for IPSec.

The list of CAs supported could vary from VPN platform to platform, for example, PIX Firewalls might not support the same options as IOS devices or VPN hardware devices. A good idea is always to check the Cisco online documentation for the particular device and version of the operating system (OS) to confirm support and appropriate version numbers. The following are CA providers that support SCEP to interoperate for enrolling Cisco IOS routers:

VeriSign
Entrust Technologies, Inc.
Baltimore Technologies
Microsoft Corporation

VeriSign OnSite 4.5

The VeriSign’s OnSite 4.5 solution provides a fully integrated enterprise PKI to issue, control, and manage IPSec certificates for PIX Firewalls and Cisco routers. VeriSign administers the CA themselves, providing the certificates as a service. VeriSign OnSite service specifics include the following:

Requirements—No local server requirements. Routers must be running IOS v 12.0.6 or higher and must have a retry count set to greater than 60.
Standards supported—SCEP, x509 certificate format, and PKCS# 7, 10, 11, and 12.

For more information on VeriSign products and features, consult their web site at www.verisign.com.

Entrust Technologies

One major difference between CA servers is where the server is located and who administers it. Entrust is a software solution that’s installed and administered by the user on a local network server. The Entrust/PKI service is able to issue digital IDs to any device or application supporting the X.509 certificate standard. This implementation offers a secure, flexible, and low-cost solution from one PKI. Entrust/PKI service specifics include the following:

Requirements—Entrust software runs on the Windows servers (for Cisco interoperability), Solaris 2.6, HP-UX 10.20, and AIX 4.3 OSs. Requires RSA usage-keys configured on the routers. Cisco IOS release 11.(3)5T and later.
Standards supported—CA services, RA capabilities, SCEP, and PKCS#10.

For more information on Entrust products and features, consult their web site at www.entrust.com.

Baltimore Technologies

Baltimore Technologies supports SCEP in UniCERT, its CA server, as well as the PKI Plus toolkit, making it easy for customers to implement certificates in their networks. UniCERT is a software solution installed and administered by the user on a local network server. Baltimore Technologies service specifics include the following:

Requirements—The current release of the UniCERT CA software module is available for Windows servers. Must use Cisco IOS release 12.0(5)T and later.
Standards Supported—The following standards are supported with this CA server: X509 v3, CRL version 2, PKCS# 1, 7, 10, 11, and 12, and many more protocols.

For more information on Baltimore products and features, consult their web site at www.baltimore.com.

Microsoft Windows 2000 Certificate Services

Microsoft has integrated SCEP support into the Windows 2000 CA server via the Security Resource Kit for Windows 2000. This SCEP support allows Microsoft clients to obtain certificates and certificate revocation information from Microsoft Certificate Services for all of Cisco’s VPN security solutions.

Requirements—Intel-based PC running Windows 2000 Server. Cisco IOS release 12.0(5)T or later.
Standards Supported—The following standards are supported with this CA server: X.509 version 3, CRL version 2, PKCS #7, #10, and #12, and many more protocols.

For more information on Microsoft products and features, consult their web site at www.microsoft.com.

Enroll a Device with a CA

The basic process for enrolling an IPSec peer with a CA includes the following steps. Most of these steps have been automated using the SCEP protocol supported by many CA server providers. Each CA vender determines how long certificates are valid.

Step 1 Configure the router for CA support.
Step 2 Generate a public and private key pair on the router.
Step 3 The router authenticates the CA server.
Step 4 The router sends a certificate request to the CA.
Step 5 The CA creates and signs an identity (ID) and root certificate and, optionally, an RA certificate.
Step 6 The CA sends the certificates to the router and posts the certificates in its public repository (directory).