Introduction to PKI

As previously mentioned, PKI is a security architecture that provides a higher level of confidence for exchanging information over insecure networks. PKI is based on public key cryptography, a technology that was first created to encrypt and decrypt data involving two different types of keys: a public and a private key. A user gives their public key to other users, keeping the private key. Data that is encrypted with the public key can be decrypted only with the corresponding private key, and vice versa. Figure 17-1 illustrates how this works.

Figure 17-1. Private and Public Keys

The following is the sequence in Figure 17-1:

  1. User A obtains User B's public key and uses it to encrypt a message destined for User B.

  2. User A sends the encrypted message over the unsecured network.

  3. User B receives the encrypted message and decrypts it using his own private key.

The following are several key terms and concepts used in PKI:

The following subsections define each of these terms and concepts in turn.

Certificates

Digital certificates are commonly used to authenticate and validate users and devices while securing information exchanged over unsecured networks. Certificates can be issued for a user or a network device. Certificates securely bind the user's or device's public key and other information that identifies them.

The certificate syntax and format are defined in the X.509 standard of the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T). An X.509 certificate includes the public key and information about the user or device, information about the certificate itself, and optional issuer information. Generally, certificates contain the following information:

Digital certificates can be used in many implementations, such as IPSec and Secure Sockets Layer (SSL), secure e-mail using Secure/Multipurpose Internet Mail Extensions (S/MIME), and many others. The same certificate might have different purposes. For example, a user certificate can be used for remote access VPN, accessing application servers, and for S/MIME e-mail authentication.

Note

Cisco ASA supports digital certificates for remote-access and site-to-site IPSec VPN session authentication, as well as for WebVPN and SSL administrative sessions.

The CA that issues the certificate determines the implementations for each certificate. The usage of the certificate is recorded to the CA (e.g., SSL, IPSec, etc.)

Certificate Authority

A CA is a device or entity that can issue a certificate to a user or network device. Before any PKI operations can begin, the CA generates its own public key pair and creates a self-signed CA certificate. A fingerprint in the certificate is used by the end entity to authenticate the received CA certificate. The fingerprint is created by calculating a hash (MD5 or SHA-1) on the whole CA certificate. This corresponds to the ultimate root certificate, in cases in which multiple level of CA exists.

CAs can be configured in a hierarchy. The CA at the top of a certification hierarchy is usually referred as the main root CA. Figure 17-2 illustrates this concept.

Figure 17-2. Certification Hierarchy

In the example in Figure 17-2, the root CA server has two subordinate CAs, US and Australia. The US CA server also has two subordinates, New York and Los Angeles. Each CA server grants or denies certificate enrollment requests from its corresponding users and network devices (Cisco ASAs in this example).

A user or network device chooses the certificate issuer as a trusted root authority by accepting the issuer CA's self-signed certificate containing the issuer's public key. The certificate information from all trusted CAs within the hierarchy is often referred to as the certificate chain of trust.

There are several CA vendors. The following are some of the CAs supported by Cisco ASA:

Several PKI implementations also include the use of registration authorities (RAs). An RA acts as an interface between the client (user or network device) and the CA server. An RA verifies and identifies all certificate requests and requests the CA to issue them. RAs can be configured within the same CA (server) or in a separate system. Microsoft CA server, RSA Keon, and Entrust are examples of PKI servers that utilize RA.

A certificate is valid only for the period of time specified by the issuing CA. Once a certificate expires, a new certificate must be requested. You also have the ability to revoke a specific user and device certificate. The inventory of serial numbers of revoked certificates is maintained on a certificate revocation list (CRL).

Certificate Revocation List

When you revoke a certificate, the CA publishes its serial number to the CRL. This CRL can be maintained on the same CA or a separate system. The CRL can be accessed by any entity trying to check the validity of any given certificate. LDAP and HTTP are the most commonly used protocols when publishing and obtaining a CRL. Storing CRLs in a separate system other than the CA server is often recommended for large environments, for better scalability and to avoid single points of failure.

Figure 17-3 illustrates how a certificate can be revoked on a CA and subsequently published to a CRL server.

Figure 17-3. Certificate Revocation and CRL Example

The following is the sequence of events in Figure 17-3:

  1. The user certificate is revoked in the CA server. The CA server updates the CRL/LDAP server.

  2. The user attempts to establish an IPSec VPN connection to the Cisco ASA.

  3. The Cisco ASA is configured to query the CRL server. It downloads the CRL and finds the certificate serial number on the list of revoked certificates.

  4. The Cisco ASA denies access to the user and sends an IKE delete message.

There are several reasons why you need to use CRLs. Revoking a certificate is crucial if it might have been compromised or if the user might not have authority to use such certificate. For example, you should always revoke certificates when employees leave your organization.

Simple Certificate Enrollment Protocol

Simple Certificate Enrollment Protocol (SCEP) is a protocol developed by Cisco. SCEP provides a secure issuance of certificates to users and network devices in a scalable manner. It uses HTTP for the transport mechanism for enrollment and uses LDAP or HTTP for CRL checking. SCEP supports the following operations:

Cisco ASA supports enrollment via SCEP and manually via a cut-and-paste method.

Tip

Using SCEP is recommended for better scalability. The manual cut-and-paste method is normally used when the CA server does not support SCEP or an HTTP connection is not possible.

Related

Категории