Configuring IKE with RSA Signatures and Digital Certificates
IKE authentication with digital certificates uses RSA digital signatures and provides scalability for larger networks. As mentioned previously, digital certificates provide nonrepudiation through the service of a CA.
NOTE
Your organization might administer a CA server and act as the CA for all of the devices and people that belong to your organization. Also, you might be the CA for third parties (suppliers, partners, customers) that do business with your organization.
With digital certificate support, a router does not need to be configured with the public keys of each of its peers; instead, a router only needs to obtain its digital certificate from the CA. The digital certificate contains the router's public key (and other identity information) and the CA's signature for the certificate. When building an IKE SA with a peer, the router offers its digital certificate to the peer. The peer can then validate the authenticity of the certificate (by checking the CA's signature) and extract the public key contained within the certificate. See "Digital Signatures" and "Digital Certificates," earlier in this chapter.
CAs and supporting systems that provide digital certificates and public key management arc collectively called the public key infrastructure (PKI). PKI standards come from the IETF, International Telecommunication Union (ITU), RSA Data Security, and other organizations. IOS supports standards for PKI elements such as certificates, keys, and CAs. Consult Cisco for a current list of supported PKI systems and standards.
NOTE A particularly relevant PKI document is RFC 2510.
The example configurations presented in this section on certificates are based on the network depicted in Figure 7-8. This figure describes two routers peering over an untrusted network with IKE and digital certificates with RSA signatures.
Figure 7-8 Two Routers Peering with IKE and Digital Certificates with RSA Signatures ca server 10.1.1.1
RTA's certif.
s1:192.168.1.1
s1:192.168.1.2
RTA's certif.
s1:192.168.1.1
s1:192.168.1.2
In the preceding figure, both Router A and Router B store their own certificates locally in their IOS configurations. Both have already obtained their certificates at a prior time by following the certificate request, verification, and retrieval process with the CA server called ca_server. When Router A and Router B need to build an IKE S A, they exchange certificates as part of the IKE authentication process. Refer to "Tying All of the Pieces Together: A Comprehensive Example with IPsec and IKE" for a sequence including IKli and digital certificates.
Configure the IKE Transform Set for RSA Signature
As with prc-shared keys and RSA encryption, you must configure matching IKE transform sets in the routers to support RSA signanirc. The following IOS commands configure Router A so it can establish an IKE SA with Router B using RSA signature (for clarity, these commands include the context of the IOS prompt):
RTA#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RTA(config)#crypto isakmp policy 7
RTA(config-isakmp)#authentication rsa•sig
RTA(config-isakmp)#hash sha
RTA(config-isakmp)#encryption des
RTA(config-isakmp)#lifetime 43200
RTA(config-isakmp)#exit
The preceding commands create an IKE transform set with the following characteristics:
• Authentication method is RSA signature (rsa-sig).
• Encryption algorithm is 56-bit DES (des).
• Lifetime is 43,200 seconds (12 hours).
You must configure Router B with the same IKE transform set; otherwise, IKE negotiation will fail.
Configure CA Information
Both Router A and Router B need to be configured with the identity of the CA server so that they can communicate with it. The following commands configure the CA server information in Router A (Router B's configuration is similar):
RTB(config)#ip host ca_server 10.1.1.1 RTB(config)#crypto ca identity myca RTB(ca-identity)#enrollment url http://ca server RTB(ca-identity)#enrollment mode ra RTB(ca-identity)#query url ldap://ca_server RTB(ca-identity)#crl optional RTB(ca- identity)#exit
The command ip host ca server 10.1.1.1 adds an entry in the router's host table so that it can resolve the name ca__server to 10.1.1.1. This command can be skipped if the router is configured with the ip name-server command and can resolve the name with DNS.
The command crypto ca identity myca adds an entry for the CA, names the CA myca (this can be any string), and begins CA identity config mode as indicated when the prompt changes to ca-identity in the next line.
The command enrollment url http://ca_server configures the router with the Uniform Resource Locator (URL) of theCA. This is required and should match the hostname configured by the preceding ip host command. The URL in this example assumes the script directory of the CA server is in a default location. This should apply to most cases; however, if the script directory is in a nonstandard location, include the full path to the script directory in the URL (for example, enrollment url http://ca_server/cgi-bin/subdirl/subdir2). Consult your CA for assistance in determining the correct URL.
The command enrollment mode ra is necessary only if the router is communicating with a Registration Authority (RA). Some PKI systems split administration tasks across two servers: a CA that signs certificates and an RA that handles the certificate enrollment transactions. Consult your CA. If your CA does not use an RA, you should skip this command.
The command query url ldap://ca_server configures the router to use the Lightweight Directory Access Protocol (LDAP) for retrieving certificates from this server. This is usually configured in conjunction with an RA that supports the LDAP protocol. If your CA does not use LDAP, you should skip this step.
NOTE At the time of this writing, IOS intcroperates with CA servers from Entrust Technologies and Verisign, using the Certificate Enrollment Protocol (CEP). The Entrust CA server requires the commands enrollment mode ra and query url; the Verisign CA server does not. See a bulletin at http://www.cisco.com/warp/public/778/security/821_pp.htm or search for "certificate authority support" on Cisco's Web site. Consult Cisco for a current list of supported PKI systems.
The command crl optional allows the router to accept a peer's certificate even if the certi^cate revocation list (CRL) is not available. Routers and other devices use the CRL to chcck for cerfifica1e^atTiavel)een revoked. Certificates expire over time and can be retracted by the owner of the certificate or the CA. To ensure that a certificate is still valid, a device downloads a CRL from its CA and rejects certificates that are on the CRL. If the CRL is not available (if the CA server is down and the CRL is not stored on the router), crl optional enables the router to accept a peer's certificate and continue.
Without the crl optional command, the security policy is more strict: The router must possess and check the CRL before accepting a peer's certificate. This might be desirable for enhanced security, but it adds an additional step that might require troubleshooting.
Finally, exit ends CA identity mode and returns to global configure mode.
Retrieve the Certificate of the CA
Each device participating in authentication with digital certificates needs to retrieve the CA's certificate. This provides the device with the CA's public key that is used to verity certificates the CA has signed.
The following command instructs Router A to contact the CA and retrieve the CA's certificate (Router B also requires this command). The administrator commands are highlighted in boldface. Refer to Figure 7-8 for the topology.
RTA(config)#crypto ca authenticate myca
Certificate has the following attributes: Fingerprint: B60065B9 63EC9373 D33B4548 CAEF52B9
% Do you accept this certificate? lyes/no]: y RTA(config)#
The command crypto ca authenticate myca is a global config command and tells a router to get the certificate of the server mvca.
In the next lines, the router retrieves the fingerprint of the CA's certificate and asks you to verify it. The fingerprint is a cryptographic number calculated by the CA and is used to verify the integrity of the certificate. Check the fingerprint your router receives against the fingerprint provided by your CA. Matching fingerprints validates the CA's certificate and ensures that the certificate was not altered in transit.
After accepting the certificate, you can view it with the show crypto ca certificates command:
RTA#sh cry ca certificates
CA Certificate Status: Available
Certificate Serial Number: 3654B2FF Key Usage: Not Set
Generate Public and Private Keys
After configuring the CA information, you need to generate the router's public and private keys. This is performed with the command crypto key generate rsa introduced in the section "Configuring IKE with RSA Encryption" earlier in this chapter.
Some PKI servers (CA or RA) require each device to have two public/private key pairs—a total of four keys. One key pair is used for encryption and the other key pair is used for digital signatures. The following command generates two such key pairs. Before you issue this command, ensure that your router has a hostname and a domain name (configured with the hostname and ip domain-name global config commands):
RTA(config)#crypto key generate rsa usage-keys
The name for the keys will be: RTA.cisco.com
Choose the size of the key modulus in the range of 360 to 2048 for your Signature Keys. Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus [512]: 1536 Generating RSA keys ...
%SYS 3 CPUHOG: Task ran for 2812 msec (109/109), process = Key Proc, PC = 72B1EE. [OK]
Choose the size of the key modulus in the range of 360 to 2048 for your Encryption Keys. Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus [512]: 1536 Generating RSA keys ...
%SYS-3-CPUHOG: Task ran for 2048 msec (17/9), process = Key Proc, PC = 72A3A8. [OK]
The command crypto key generate rsa usage-keys runs a small program within global configure mode that creates two RSA key pairs. These key pairs are submitted to the PKI server (CA or RA) with a request for a certificate. See "Send Public Keys to the CA and Get Your Certificate," later in this chapter.
If your PKI server (CA or RA) requires only one public/private key pair, use the command crypto key generate rsa instead of crypto key generate rsa usage-key.
NOTE The system message %SYS-3-CPUHOG in the preceding output indicates that the router is experiencing high CPU utilization. This is expected because key generation is CPU-intensive. As mentioned in an earlier note, generate keys before putting the router into service.
Send Public Keys to the CA and Get Your Certificate
To submit the router's public key (or keys) to the PKI server and request a certificate, issue the crypto ca enroll command:
RTA(config)tfcrypto ca enroll rayca Start certificate enrollment .. 96 Create a challenge password. You will need to verbally provide this password to the CA Administrator in order to revoke your certificate. For security reasons your password will not be saved in the configuration.
Please make a note of it.
Password: <type a password here> Re-enter password: <re-enter password>
% The subject name in the certificate will be: RTA.cisco.com % Include the router serial number in the subject name? [yes/no]: yes % Include an IP address in the subject name? (yes/no): no Request certificate from DA? [yes/no]: yes % Certificate request sent to Certificate Authority % The certificate request fingerprint will be displayed. % The 'show crypto ca certificate' command will also show the fingerprint.
RTA(config)#
Signing Certificate Request Fingerprint: AABB1FD9 594B3209 39D9058C 2A19205C Encryption Certificate Request Fingerprint: 6289344E AEFDC0AE BCB86E1B ECD62171
The command crypto ca enroll myca initiates a request for a certificate and prompts you for the following (indicated by boldface in the preceding output):
• Password—You need to supply a password to the CA with your request. If you ever have to revoke a certificate, the CA will ask for this password to prevent fraudulent revocation requests.
• Include router serial number—You may include your router's serial number in the certificate. This is not required by IPsec or IKE, but might be required by your CA.
• Include IP address—You may include your router's IP address in the certificate. Generally, you will not include this because IP addresses can change and such a change would require a new certificate.
• Request certificate from CA—When you are ready to submit the request, answer yes to this prompt to send the request.
Next, the router displays the fingerprints associated with the certificate requests and periodically queries the PKI server until the CA fulfills the request. By default, the router queries the server every minute until the certificate is ready for retrieval. The query interval can be adjusted by the enrollment retry-period command (CA identity config mode).
The following output of show crypto ca certificates indicates that a certificate request is still pending:
RTA#sh cr ca certificates Certificate Subject Name
Name: RTA.cisco.com IP Address: 192.160.1.1 Status: Pending Key Usage: Signature
Fingerprint: AABB1FD9 594B3209 39D9058C 2A19205C
A status of Fending means the CA server has not yet completed the processing of the certificate request\j*tfmentioncd in the earlier section, "Digital Certificates and Certification Authorities," the CA should manually verity that the public key and the owner are legitimate before issuing a certificate.
When the router queries the server, discovers that the certificate is ready, and downloads the certificate, the following system message is displayed:
RTA(config)#
%CRYPTO-6 CERTRET: Certificate received from Certificate Authority RTA(config)#
The router now has its certificate. You can verify this by issuing the show crypto ca certificates command:
RTA#show crypto ca certificates Certificate Subject Name
Name: RTA.cisco.com IP Address: 192.168.1.1 Status: Available
Certificate Serial Number: 3654B3B6 Key Usage: Signature
A status of Available confirms that the router has its certificate and is ready to distribute it to peers.
When both routers, Router A and Router B in Figure 7-8, have their certificates, IKE configuration for this example is complete.
Continue reading here: Configuring Crypto Access Lists
Was this article helpful?