|
|
Certification authorities (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). You can use a CA with a network containing multiple IPSec-compliant devices, such as with the Cisco Secure PIX Firewall units and Cisco routers.
 |
Note The PIX Firewall currently supports the CA servers from VeriSign, Entrust, Baltimore Technologies, and Microsoft. See "CA Configuration Examples," for a list of specific CA server versions the PIX Firewall supports. |
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 encryption 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. In simple terms, a 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.
In order 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 scaleably authenticate peer devices before setting up security associations.
Without digital signatures, one must either manually exchange public keys or secrets between each pair of peers that use IPSec to protect communications between them. Without certificates, every new peer added to the network requires a configuration change on every other peer it securely communicates with. However, by using digital certificates, each peer is enrolled with a CA. When two peers wish to communicate, they exchange certificates and digitally sign data to authenticate each other. When a new peer is added to the network, one simply enrolls that peer with a CA, and none of the other peers need modification. When the new peer attempts an IPSec connection, certificates are automatically exchanged and the peer can be authenticated.
The following sections are included in this chapter to provide background information you will need to know prior to configuring for interoperability with a CA. The CA configuration steps are provided in "Configuring CA."
Without a CA, if you want to enable IPSec services (such as encryption) between two peers, you must first ensure that each peer has the other's key (such as an RSA public key or a pre-shared key). This requires that you manually perform one of the following tasks at each peer:
In Figure 4-1, number 1 illustrates how each PIX Firewall uses the other's key to authenticate the identity of the other PIX Firewall; this authentication always occurs whenever IPSec traffic is exchanged between two IPSec peers. Number 2 illustrates encrypted data within an IPSec tunnel between two IPSec peers.
If you have multiple Cisco peers in a mesh topology, and wish to exchange IPSec traffic passing between all of the peers, you must first configure shared keys or RSA public keys between all of the peers.
Every time a new peer is added to the IPSec network, you must configure keys between the new peer and each of the existing peers. (In Figure 4-2, four additional 2-part key configurations would be required to add a single IPSec peer to the network.)
Consequently, the more peers there are that require IPSec services, the more involved the key administration becomes. This approach does not scale well for larger, more complex encrypting networks.
With a CA, you do not need to configure keys between all of the encrypting devices (peers). Instead, you individually enroll each participating device with the CA, requesting a certificate for the device. When this has been accomplished, each participating device can dynamically authenticate all of the other participating peers. This is illustrated in Figure 4-3.
To add a new IPSec device to the network, you only need to configure that new device to request a certificate from the CA, instead of making multiple key configurations with all the other existing IPSec peers.
When two IPSec peers want to exchange IPSec-protected traffic passing between them, they must first authenticate each other—otherwise, IPSec protection cannot occur. The authentication is done with IKE.
Without a CA, a device authenticates itself to the remote peer using either RSA-encrypted nonces or pre-shared keys. PIX Firewall currently does not support RSA-encrypted nonces. Both methods require that keys must have been previously configured between the two peers.
With a CA, a peer authenticates itself to the remote peer by sending a certificate to the remote peer and performing some public key cryptography. Each peer must send its own unique certificate which was issued and validated by the CA. This process works because each peer's certificate encapsulates the peer's public key, each certificate is authenticated by the CA, and all participating peers recognize the CA as an authenticating authority. This is called IKE with an RSA signature.
The peer can continue sending its own certificate for multiple IPSec sessions, and to multiple IPSec peers, until the certificate expires. When its certificate expires, the peer administrator must obtain a new one from the CA.
CAs can also revoke certificates for peers that will no longer participate in IPSec. Revoked certificates are not recognized as valid by other peers. Revoked certificates are listed in a Certificate Revocation List (CRL), which each peer may check before accepting another peer's certificate.
Some CAs have a Registration Authority (RA) as part of their implementation. An RA is essentially a server that acts as a proxy for the CA so that CA functions can continue when the CA is offline.
Posted: Thu Aug 31 19:37:09 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.