This chapter is from the book
This chapter is from the book
This chapter is from the book
CA Support Overview
With a CA, you do not need to configure keys among all of the encrypting IPSec peers. Instead, you individually enroll each participating peer with the CA and request a certificate. When this has been accomplished, each participating peer can dynamically authenticate all of the other participating routers. To add a new IPSec peer to the network, you only need to configure that new peer to request a certificate from the CA, instead of making multiple key configurations with all the other existing IPSec peers.
This section presents an overview of how CA support works.
CA servers are responsible for managing certificate requests and issuing certificates to participating IPSec network devices. These services provide centralized key management for the participating devices. CAs simplify the administration of IPSec network devices so that IPSec keys do not have to be manually configured on each peer. You can use a CA with a network containing multiple IPSec-compliant devices, such as PIX Firewalls, Cisco routers, the Cisco VPN 3000 Concentrator series, the Cisco Secure VPN Client, and other vendors' IPSec products, as shown in Figure 1-24.
){kind=link}
Figure 1-24 CA Support
Digital signatures, enabled by public key cryptography, provide a means to digitally authenticate devices and individual users. In public key cryptography, such as the RSA signature system, each user has a key pair containing both a public and a private key. The keys act as complements, and anything encrypted with one of the keys can be decrypted with the other. An RSA signature is formed when data is encrypted with a user's private key. The receiver verifies the signature by decrypting the message with the sender's public key.
The fact that the message could be decrypted using the sender's public key indicates that the holder of the private key—the sender—must have created the message. This process relies on the receiver having a copy of the sender's public key and knowing with a high degree of certainty that it really does belong to the sender, and not to someone pretending to be the sender.
A digital certificate contains information to identify a user or device, such as the name, serial number, company, department, or IP address. It also contains a copy of the entity's public key. A CA signs the certificate. The CA is a third party that is explicitly trusted by the receiver to validate identities and to create digital certificates.
To validate the CA's signature, the receiver must first know the CA's public key. Normally this is handled out-of-band or through an operation done at installation. For instance, most Web browsers are configured with the public keys of several CAs by default. The IKE, a key component of IPSec, can use digital signatures to authenticate peer devices before setting up SAs, while simultaneously providing scalability.
Without digital signatures, you must manually exchange either public keys or secret keys between each pair of devices that use IPSec to protect communications between them. Without certificates, every new device added to the network requires a configuration change on every other device with which it securely communicates. However, by using digital certificates, each device is enrolled with a CA. When two devices wish to communicate, they exchange certificates and digitally sign data to authenticate each other. When a new device is added to the network, one simply enrolls that device with a CA, and none of the other devices need modification. When the new device attempts an IPSec connection, certificates are automatically exchanged and the device can be authenticated. Without CA interoperability, devices could not use CAs when deploying IPSec. CAs provide a manageable, scaleable solution for IPSec networks.
Digital Signatures
The digital signature provides a form of digital credentials that authenticate the identity of the sending party, whoever that may be. In other words, digital signatures are used to link data with the holder of a specific private key and consist of the following:
At the local end, a private key is used to encrypt the hash.
At the remote end:
The hash is produced by running the original message through a algorithm.
The hash that was appended to the original message is decrypted using the sender's public key.
If the hashes match, the message is signed by a private key.
Only a specific private key could have produced the digital signature.
Figure 1-25 shows the digital signature process.
){kind=link}
Figure 1-25 Digital Signatures
A key pair has no intrinsic ties to any person or entity. It could be sourced from Alice, Tom, or Harry Hacker masquerading as Alice or Tom. A solution is necessary to reliably tie a person or entity to a key pair. Digital signatures provide a way to "guarantee" the source of the message. The solution is digital signatures and digital certificates.
Digital signatures—Tie a message to a sender's private key. The hash can only be decrypted by the sender's public key.
Digital certificates—Bind a person or entity to a private key.
Certificate-Based Authentication
Digital certificates are used to authenticate users. They can be used to identify a person, a company, or a server. They are the equivalent of a digital passport or driver's license. The following example and Figure 1-26 illustrate how this works.
){kind=link}
| Step 1 |
Users A and B register separately with the CA.
|
|
| Step 2 | User A sends the certificate to User B. |
|
| Step 3 |
User B checks the authenticity of the CA signature on the certificate.
|
|
| Step 4 |
User B sends the certificate to User A.
|
NOTE
Certificates are exchanged during the IPSec negotiations.
Figure 1-26 Certificate-Based Authentication
CAs
CAs hold the key to the public key infrastructure (PKI). A CA is a trusted third party whose job is to certify the authenticity of users to ensure that you are who you say you are.
Authenticity is guaranteed by the CA digital signature created with the CA private key. You can verify a digital signature using the CA public key. Only the CA public key can decrypt the digital certificate. The job of a CA is to
- Create certificates
- Administer certificates
- Revoke invalid certificates
The CA can be a corporate network administrator or a recognized third party. Trusted sources supported by the Cisco VPN 3000 Concentrator Series include the following:
- Entrust
- GTE Cybertrust
- Network Associates PGP
- Baltimore
- Microsoft
- Verisign
Some CAs also use a Registration Authority (RA) to provide certificate enrollment services. An RA is server software that acts as a proxy for the CA, providing essential CA functions, such as certificate enrollment and distribution.
PKI
PKI is the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates. PKI makes it possible to generate and distribute keys within a secure domain and enables CAs to issue keys and associated certificate and certificate revocation lists (CRLs) in a secure manner. There are two PKI models, as shown in the following list and Figure 1-27.
){kind=link}
Central authority
All certificates are signed by a single authority.
All certificates can be checked with that CA's public key.
Hierarchical authority
The ability to sign a certificate is delegated through a hierarchy. The top of the hierarchy is the root CA. It signs certificates for subordinate authorities.
Subordinate CAs sign certificates for lower-level CAs.
To validate a user's certificate, the certificate must be validated up through the chain of authority.
Figure 1-27 PKI