The life of a public key certificate in a PKI depends largely on the implementation and design of the PKI itself. For example, the life of a certificate would change if one were to offload PKI functionality from a CA to a series of RAs. Likewise, the life of a certificate would change if one were to deploy a hierarchy of CAs, as opposed to using a single CA. However, the high-level process of creating and obtaining public key certificates is fairly consistent. Implementation-specific considerations are covered later in the chapter, but to fully appreciate them, we must first understand the general process of creating and obtaining public key certificates. RSA Signatures and X.509v3 CertificatesRSA signatures are a form of Digital Signature, the operation of which is described previously in this chapter and in Chapter 2, "IPsec Fundamentals." RSA signatures combine the strength of a standard digital signature with the strength of the RSA encryption algorithm, also described above, to yield an RSA signature. Crypto-enabled network devices oftentimes will use RSA signatures when exchanging X.509-based certificates with a X.509 compliant certificate authority. Note that, unlike Internet Security Association and Key Management Protocol (ISAKMP) authentication designs that use preshared keys, the RSA signatures authentication method uses an RSA keypair. ITU-T X.509 certificates and certificate authorities were developed to aid administrative burden in asymmetric cryptographic deployments through leveraging a central point of administration, or a trustpoint, for cryptographic endpoints to register their public keys and to obtain the public keys of their peers. Such a trustpoint is commonly referred to as a certificate authority. In order to effectively exchange this information, the certificate authority must communicate certificates in a standard format that is agreed upon with by its peers. ITU-T X.509-formatted certificates are commonly accepted as the standard for this type of public key cryptosystem. Figure 11-2 illustrates the format of an X.509-formatted certificate. Certificate authorities allow network administrators to effectively manage large-scale crypto deployments by concentrating the administration of public key distribution into a single source. In doing so, administrators can be assured that keys are exchanged with authentic sources and destinations. Note The use of CA-based PKI does not enhance the level of confidentiality exchanged in an asymmetric key crypto deployment. It does, however, enforce data authentication in a fashion that allows for enhanced scalability in the number of encrypting/decrypting peers. The following sequence illustrates the process of two endpoints, James and Charlie, communicating with one another using the RSA-signatures method of IKE authentication, as illustrated in Figure 11-3:
Note Encryption with RSA signatures is only used for IKE. A Diffie-Hellman shared secret key is negotiated over the IKE channel encrypted with the RSA signatures. The IPSec SA then uses the Diffie-Hellman shared secret key to encrypt data between the two endpoints. Because only authentic endpoints have the CA public key, all of the authentic endpoints receiving a CA-signed public key certificate can be assured that the enclosed public key is authentic if the CA's signature is successfully validated. Additionally, only authentic cryptographic endpoints, such as James and Charlie in this case, can use their private keys to decrypt communications between one another. In the preceding exchange, James and Charlie will enroll using Simple Certificate Enrollment Protocol (SCEP) as defined by the X.509 standard. The transport used to distribute certificates in the exchange described above using a client/server application such as HTTP, FTP, or LDAP. Cisco Systems manufactures a full set of network devices and appliances that utilize X.509-based PKI cryptosystems that leverage protocols such as HTTP for certificate transport, including firewalls, intrusion detection systems, routers, switches, and VPN concentrators. Generating Asymmetric Keypairs on Cryptographic EndpointsThe main component of a public key certificate is the public key itself. Because of this, cryptographic endpoints must generate asymmetric keys, which would include the public key, before a public key certificate can be created. As we have discussed before, the effectiveness of a public key cryptosystem depends on the difficulty of deriving a private key from a compromised public key. Therefore, the effectiveness of a public key cryptosystem is directly related to the strength, or modulus, of the asymmetric keypair itself. Most Cisco devices will support RSA keys modulus sizes between 512 and 2048. The stronger the keys, the harder it is to compromise the keypair. The tradeoff in selecting a large key modulus is that they consume more computational resources when ciphering messages. Additionally, a larger key modulus consumes more computational resources during the generation of the keys themselves. Registration and Endpoint AuthenticationThe life of a public key certificate begins when a cryptographic endpoint registers with the PKI. On Cisco devices, this process is initiated when the device is configured with the CA IP and certificate path. When a device attempts to enroll with the CA, an optional step can be executed to verify the authenticity of the cryptographic endpoint before it is registered with the PKI. Authenticating cryptographic endpoints during the registration phase can be bypassed on certain CA implementations. For example, a Microsoft Windows 2000 server running Certificate Services can be configured to automatically issue the CA certificate to the cryptographic endpoint without authentication. Alternatively, Windows 2000 Server can also be configured to wait until the CA administrator manually examines the request from the endpoint and instructs the CA to issue its certificate to the cryptographic endpoint. Receipt and Authentication of the CA's CertificateOnce an endpoint has registered with the CA, the CA forwards its certificate, containing its public key, to the cryptographic endpoint. This step is critical to the endpoint's ability to verify the CA's signature when receiving public key certificates from other cryptographic endpoints, since the CA's certificate contains the public key that corresponds to the private signing key. When the CA forwards its certificate to the endpoint, a step of authenticating the CA is typically executed. The CA's certificate has a unique fingerprint that can be checked for authenticity. Alternatively, this authentication step can be skipped if such authentication is not needed. Forwarding and Signing of Public KeysOnce the CA and cryptographic endpoints have established a relationship of trust with one another, the cryptographic endpoint forwards its public key to the CA to be stored for other cryptographic endpoints to use. Before the CA forwards this public key to anybody, it signs it. To do this, the CA hashes the public key with a one-way hash algorithm, such as SHA-1 or MD-5. The message digest of that hash is then encrypted with the CA's private key. Only those endpoints that have authenticated the CA (and, as a result, also have the CA public key) can decrypt the message digest and verify it. Note Cisco cryptographic endpoints support the RSA-signatures method of authentication in ISAKMP. The DSS-1 standard for signature formatting and creation is followed in this process. As you may recognize, this is the same process of creating a digital signature, which we explored in Chapter 2, "IPsec Fundamentals." The digital signature that the CA places on stored public keys is the very cornerstone of trust in a PKI. Obtaining and Using Public Key CertificatesOnce a cryptographic endpoint has enrolled with the CA, it can now verify the public key certificates of cryptographic endpoints that are enrolled with the CA. Because the cryptographic endpoint has already obtained the CA's certificate and public key, it can verify the CA's signature on the public key certificates of other cryptographic endpoints that it wants to encrypt data towards. Note During the whole process of creating and obtaining public key certificates, the cryptographic endpoints' private keys are never shared with anybody else, including the CA. This process ensures that only the cryptographic endpoint that originated the public/private keypair can decrypt data that was encrypted with its public key. |