Life of a Public Key Certificate


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 Certificates

RSA 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:

1.

James and Charlie request the CA's certificate. They optionally confirm the authenticity of the CA by verifying its fingerprint (manually) and install the CA's certificate, including its public (decryption) key.

2.

James and Charlie enroll with the CA upon completion of Step 2. During this process, they forward their public RSA key to the CA.

3.

When James and Charlie enroll with the CA, their public keys are received by the CA, then digitally signed with the CA's private key, as shown in Figure 11-4, resulting in a public key certificate for both James and Charlie.

Figure 11-3. Certificate Enrollment Procedure Using RSA Signatures and X.509 Certificates


Figure 11-4. CA Signs the X.509 Certificate


4.

The CA forwards the James and Charlie their CA-signed public key certificates, which are stored locally on both James and Charlie for future ISAKMP Phase I exchanges with other endpoints in the PKI that use the RSA-signatures method of authentication.

5.

When James and Charlie want to initiate ISAKMP Phase I negotiation with one another, they forward their CA-signed RSA public key certificates to one another.

6.

James and Charlie then use the CA Public Key (obtained in Step 1), to verify the CA's digital signature (computed in Step 2) on the public key certificates they receive from one another in Step 5. This is displayed in Figure 11-5. If the CA's certificate is verified successfully, then James and Charlie can be assured that the public keys were obtained from authentic sources and that their integrity has been preserved.

Figure 11-5. Verification of the CA-Signed Certificate


7.

James and Charlie can now use each other's public keys to encrypt communications between each other. Note that James and Charlie's private keys have been kept private throughout this exchange, ensuring confidentiality between the parties.

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 Endpoints

The 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 Authentication

The 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 Certificate

Once 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 Keys

Once 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 Certificates

Once 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.





IPsec Virtual Private Network Fundamentals
IPSec Virtual Private Network Fundamentals
ISBN: 1587052075
EAN: 2147483647
Year: N/A
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net