Understanding the Caveats of Using a PKI
To this point we have discussed the strengths that a PKI can bring to an organization.
In addition to these strengths, it is important to understand the caveats involved in implementing a PKI in the enterprise so that you can make an informed decision.
Table 14-4 describes some of the caveats.
|
Caveat |
Description |
|
A user certificate is compromised (a private key is stolen) |
It is important that no user accept a compromised certificate. To prevent these from being used, it is important to maintain a list of all revoked certificates. This list is called the Certificate Revocation List (CRL). The RLA server, not necessarily the CA server, should be readily accessible to users so that they may periodically download the latest CRL. This list should then be used when authenticating other users. Authentication fails if the received certificate is on the CRL. |
|
The CA's certificate is compromised (the private key is stolen) |
A compromised CA invalidates all certificates signed by the CA. In a single CA environment, recovering from this requires the creation of a new CA certificate and new user certificates. Should this occur in a hierarchical CA environment, an Authority Revocation List (ARL) is needed. In this situation, all child certificates of the compromised CA become invalid if the CA is on the ARL. |
|
The CA administrator's process |
A further limitation is that the CA administrator must be involved in this process. To lessen the impact, it is important that the CA administrator follow strict rules when issuing certificates. You should define a security policy to address the steps needed to create certificates. This process should include mandatory out-of-band verification of all initial enrollment procedures. It should also detail all steps that the CA administrator should take before approving a certificate request. |
Even when certificates are employed in an IP network, they must be combined with another means of authentication. Using public-key authentication alone is not a wholly secure solution. In these instances, you should combine your public-key authentication with another authentication mechanism to provide greater security and more authorization options. An example of combining mechanisms might be something like working with IPsec using certificates for authentication and then combining this with Extended Authentication (XAUTH) that has one-time password hardware tokens. This combination provides a superior authentication scheme over using only certificates. Of course, some limitations exist.
One notable limitation should be mentioned. If an organization moves to digital certificates from Phase Shift Keying (PSK), a data modulation scheme that conveys data by changing or modulating the phase of a reference signal, it can experience an issue with a router. For instance, if it boots with incorrect time information, significant issues could occur. In a similar situation, if an internal battery dies, devices will think the current year is 1998. If you are working with a certificate that was issued in 2008 and it expires in 2010, the VPN will not be functional, and your site-to-site connection will go down. In a case like this, troubleshooting the issue is very hard, because the key areas that normally are examined, such as the routing table, appear normal and without issue, and users on the network can get out to the Internet. Because of this limitation, it is important that you understand that time—the correct time setting on your devices—now plays a critical role in the stability of VPN tunnels.
A second issue to be aware of is that if a router experiences such things as a random reboot, a power supply failure, or the interface going bad, when you replace this router with another one, you cannot simply paste in the former router's configuration and get it back online. This new device must first generate a certificate request and enroll with the CA. After the CA approves the request from the new router, you must install the certificates to bring the VPN tunnels back up. This is a little different than with PSKs. If you are working with PSKs, all the administrator must do is copy over the configuration, and the tunnel is up again.
Post a comment