ISAKMP/IKE Phase 1 Device Authentication

ISAKMP IKE Phase 1 Device Authentication

Because the configuration of device authentication can be complex, at least when it comes to RSA encrypted nonces and especially digital certificates, I've separated the configuration process for authentication from the ISAKMP/IKE Phase 1 policy configuration and will cover it in its own section.

Note that Cisco routers support three methods of authenticating IPsec devices (peers): Pre-shared keys, RSA encrypted nonces, and RSA signatures (digital certificates). The following sections will discuss the configuration of these authentication methods.

ISAKMP/IKE Identity Type

Before I discuss the three ways of configuring device authentication, I first need to discuss the use of a router's identity type. The ISAKMP/IKE identity type specifies how each peer sends its identity to the remote peer; it will send either its IP address or its host name. This is used only when pre-shared (symmetric) keys or RSA encrypted nonces (asymmetric pre-shared keys) are used. This information is used by the remote peer to determine what pre-shared key information should be used to perform the device authentication.

The default is to have the router send its IP address. This works well if the local device has only one IP address that it will always use to initiate or terminate IPsec sessions. However, in certain cases this will cause problems if the local device can use more than one IP address (thus, more than one interface) to communicate to the remote device. In this case, I recommend that you use the router's host name for the identity type.

To specify the identity type, use the following command:

Router(config)# crypto isakmp identity {address | hostname}

address is the default type; so if your router will always use the same IP address to reach the remote peer, you don't need to configure this command. I recommend that if you use the hostname parameter, you should configure a static resolution table on your router for the name to the multiple IP addresses associated with the peer; if you don't do this, and DNS resolution fails, authentication also will fail and no IPsec tunnel will be built. To build a static DNS table, use the following command:

Router(config)# ip host hostname address1 [address2...address8]

You can list up to eight IP addresses per host name.

Note

Please note that the crypto isakmp identity command is a global command; you can't change the identity type on a peer-by-peer basis. Therefore, if you set it to hostname on one device, all of the other IPsec peer devices must be configured the same.

Pre-Shared Keys

Of the three methods of device authentication, configuring what Cisco calls "pre-shared keys" is the easiest. With pre-shared keys, the same key (symmetric) is used on both peers to perform the device authentication. Pre-shared keys, symmetric or asymmetric, commonly are used when you have a small number of devices with which you need to establish IPsec tunnels. When you add more and more IPsec devices to the network, however, pre-shared keys scale poorly and thus digital certificates are used to solve the device authentication scalability issues. The one advantage that pre-shared keys have over certificates, especially symmetric pre-shared keys, is that they are simple to set up on the two IPsec peers.

Configuring Pre-shared Keys

To configure a symmetric pre-shared key for device authentication on a router, use one of the following two commands, based on the identity type used on the router:

Router(config)# crypto isakmp {0 | 6} key keystring address peer_address [subnet_mask] [no-xauth] Router(config)# crypto isakmp {0 | 6} key keystring hostname peer_hostname [no-xauth]

The 0 indicates that the key following the key parameter is unencrypted and a 6 indicates that it already is encrypted (in the router's configuration). If the identity type is address, use the first command. In this situation, the keystring value is the pre-shared key, and must match what is configured on the remote peer. If you don't specify a subnet mask, it defaults to a host mask: 255.255.255.255. With the ability to configure a subnet mask, you can wildcard a key to be used for multiple peers, like this:

Router(config)# crypto isakmp 0 key cisco123abc address 0.0.0.0 0.0.0.0

Caution

I highly recommend that you configure a different key for each peer; otherwise, if you wildcard keys and one device becomes compromised, the attacker now knows the authentication key for all of the devices covered by the masking process.

Remember that the crypto isakmp key command is used for non-remote access device authentication. As you'll see in Chapter 18, "Router Remote Access Connections," a different process is used for remote access users. However, this presents a problem if you have both L2L and remote access sessions terminated on your router. In this situation, the router will assume that XAUTH (user authentication) will be performed for both connection types. Of course, this will create problems for L2L sessions. Therefore, I always recommend that you add the no-xauth parameter to your pre-shared key configuration even if you don't currently have remote access sessions. If you add them later, you don't have to worry about your L2L sessions failing because they're trying to use XAUTH also.

Note

In older IOS versions, support for encrypting the pre-shared key on the router does not exist, and thus the 0 and 6 parameters in the crypto isakmp key command are omitted.

Protecting Pre-Shared Keys

By default, when you are entering your pre-shared symmetric or asymmetric (see the next section) keys, they are saved in clear text. In IOS 12.3(2)T, you have the option of encrypting these keys. One limitation, however, is that you must have an IOS image with AES encryption. Here are the commands you'll need to configure on your router to encrypt your unencrypted pre-shared keys:

Router(config)# key config-key password-encrypt New key: Confirm key: Router(config)# password encryption aes

The key config-key password-encrypt command will prompt you for the encryption key to use to encrypt the pre-shared keys; this key must be eight alphanumeric characters in length at a minimum. The password encryption aes command performs the actual encryption of your router's pre-shared keys.

Caution

If you want to remove the encryption option with the no key config-key password-encrypt command, the encrypted pre-shared are not automatically decrypted in your router's configuration; instead, all encrypted pre-shared keys become unusable, meaning that you'll have to re-enter them manually.

Viewing your Pre-Shared Keys

Once you have created your pre-shared keys, you can view them with the show crypto isakmp key command. An example of this command is shown in Example 16-4. In this example, the actual pre-shared keys have been encrypted using the process discussed in the previous section. If the pre-shared key wasn't encrypted, you would see it in clear text under the Preshared Key column.

Example 16-4. Phase 1 Keys

Router# show crypto isakmp key Keyring Hostname/Address Preshared Key default 192.1.1.1 (encrypted)

RSA Encrypted Nonces

One problem with symmetric pre-shared keys is that both sides need to use the same key to perform authentication, which means that either you should configure the pre-shared key out-of-band on both peers, like a console port, or use an encrypted CLI session, such as SSH. Plus, if someone can learn somehow what the symmetric key is, that person can pretend to be either peer when establishing a session to the other peer. RSA encrypted nonces limit the exposure in this situation to a single peer, because each peer has its own keying information using asymmetric keys (public and private).

With RSA encrypted nonces, you create a public/private key combination on each peer and encode your local peer's public key manually on the remote peer and the remote peer's public key on the local peer. One advantage of asymmetric keying for authentication, as I discussed in Chapter 2, "VPN Technologies," is that the private key creates the authentication information and only the related public key verifies it; the private key is never shared with anyone. In this situation, an attacker actually would have to break into your router, versus eavesdropping on a connection, to see the private key that creates the authentication information.

Using RSA encrypted nonces typically is a two step-process:

The following three sections will discuss these two steps. I'll also discuss how you can remove configured keys.

Generating RSA Encrypted Nonces (Key Pairs)

The first step you need to perform is to create your RSA encrypted nonces, commonly called key pairsa router's public and private key combination. To create encrypted nonces, first you need to configure a host name and domain name on your router with the following two commands:

Router(config)# hostname router_name Router(config)# ip domain-name domain_name

If you don't configure these commands at a minimum, the crypto key generate rsa command will give you an error message prompting you to configure both commands. The RSA algorithm needs these two components as input to the algorithm for generating the public/private keys, and also to name the key pair.

Note

Even though the router has a host name of "Router," the crypto key generate rsa command requires you to change it to something different.

Once you have configured the above commands, execute this command to generate your public/private keys:

Router(config)# crypto key generate rsa [general-keys | usage-keys]

The general-keys parameter generates a single public/private key combination used for signature purposes and usage-keys generates two key pairs: one for signatures and one for encryption. For authentication functions, you can use the general-keys parameter, which is the default if not specified. When you execute the command, you'll be prompted for a modulus value ranging from 3602,048 bits. You can't choose any value at random; it has to be a modulus factor.

Note

I've noticed in more recent IOS versions that the default is usage-keys instead of general-keys with the crypto key generate rsa command; this doesn't really matter in that for device authentication purposes, you're only interested in the public/private signature keys that are created.

Example 16-5 shows an example of using the crypto key generate rsa command. With this command, I chose the largest size modulus (the most secure) on a 3640 routerit took almost two minutes to generate the keys. With smaller routers, like the end-of-life 2500s, it takes longer than an hour. Therefore, I recommend that you use a smaller modulus for smaller routers.

Example 16-5. Generating RSA Keys

Router(config)# hostname r3640 Router(config)# ip domain-name cisco.com r3640(config)# crypto key generate rsa The name for the keys will be: r3640.cisco.com Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 2048 % Generating 2048 bit RSA keys ...[OK] r3640(config)#

Once you have created your keys, you can view your router's public keys with the show crypto key mypubkey rsa command, shown in Example 16-6. With this command you can only view the current router's keys, not a peer's keys.

Example 16-6. Viewing a Router's RSA Keys

r3640# show crypto key mypubkey rsa % Key pair was generated at: 06:13:07 UTC Mar 1 2002 Key name: r3640.cisco.com Usage: General Purpose Key Key is not exportable. Key Data: 30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A output omittedimages/U2192.jpg border=0> 23CA4ACE 63F1D296 1B020301 0001 % Key pair was generated at: 06:13:10 UTC Mar 1 2005 Key name: r3640.cisco.com.server Usage: Encryption Key Key is not exportable. Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00BFB7C0 output omittedimages/U2192.jpg border=0> BAE69169 713DCF99 B1020301 0001

Note

To save your public and private keys, execute the copy running-config startup-config command. Please note that if you back up your router's configuration to a remote device, such as a TFTP or SCP server, the router's private keying information is not backed up to the external server. I'll discuss how this can be done in the "Importing and Exporting RSA Keys and Certificates" section later in the chapter.

Multiple RSA Key Pairs

As of IOS 12.2(8)T, you can create multiple RSA key pairs on a single router; with this approach, you can use different keys for different peers with RSA encrypted nonces or for digital certificates discussed later in the "Digital Certificates and Router Enrollment" section. And because you can have multiple RSA key pairs, each key pair's policy can match that of the remote peer or certificate service.

Each RSA key pair on your router has a unique label. Without specifying any label for a key pair, as illustrated previously in Example 16-6, the label will default to the FQDN of the router (r3640.cisco.com). To create a different key pair on your router, use the following syntax:

Router(config)# crypto key generate rsa [general-keys | usage-keys] key_pair_label

Tip

When using different keys for different peers, I like to use a key pair label that describes the peer, like the name of the peer; when used for certificates, I like to use the name of the CA listed in the crypto ca trustpoint command discussed later in the chapter. Using this approach makes it easier to see where the keys are being used.

Configuring a Peer's Public Key

Once you have generated your public/private keys on both devices, you'll exchange public keys between the peers (use the show crypto key mypubkey rsa command to view your router's public key. You'll now need to configure the remote peer's public key on your router.

Based on the identity type you have defined with the crypto isakmp identity command, you'll configure it in one of two ways:

Router(config)# crypto key pubkey-chain rsa Router(config-pubkey-c)# named-key peer_name [encryption | signature] Router(config-pubkey-k)# key-string key_string Router(config-pubkey-k)# quit

or:

Router(config)# crypto key pubkey-chain rsa Router(config-pubkey-c)# addressed-key peer_IP_address [encryption | signature] Router(config-pubkey-k)# key-string key_string Router(config-pubkey-k)# quit

If the identity type is based on host names, use the named-key parameter followed by the name of the peer; otherwise, use the addressed-key parameter followed by the IP address of the peer. If you don't specify the key type, it defaults to signature.

The key-string subcommand allows you to enter the actual hexadecimal key for the remote peer. This can be entered on multiple lines. When finished entering the peer's key, on a blank command line enter the quit command, which tells the router you have finished entering the key with the key-string command.

Tip

When entering a peer's public key, I highly recommend that you don't type it in; instead, copy it on the peer and paste it into a file. Using a secure or out-of-band method, take the key to the PC you'll use to configure your router. Then use the key in this file and copy and paste it into your router. By doing this, you'll reduce the likelihood of mistyping the key; one wrong character when entering the key will invalidate the key when authentication is performed.

Once you have configured your peers' public keys on your router, you can view them with the following command:

Router# show crypto key pubkey-chain rsa {name peer_name | address peer_IP_address}

Without the name or address parameter, you won't see the peers' public keys, just the peers that you have set up on your router with public keys, like those shown in Example 16-7. If you enter the identity type followed by the peer's identity, like that shown in Example 16-8, you'll see that specific peer's public key.

Example 16-7. Viewing a List of Peers Configured for RSA Keying

r3640# show crypto key pubkey-chain rsa Codes: M - Manually configured, C - Extracted from certificate Code Usage IP-Address/VRF Keyring Name M General 192.1.1.1 default

Example 16-8. Viewing a Peer's Public Key

r3640# show crypto key pubkey-chain rsa address 192.1.1.1 Key address: 192.1.1.1 Usage: General Purpose Key Source: Manually entered Data: 30820122 300D0609 2A864886 F70D0101 01050003 82010F00 3082010A output omittedimages/U2192.jpg border=0> 23CA4ACE 63F1D296 1B020301 0001

Removing RSA Keys

If a peer generates new keys, you'll need to enter that peer's new public key on your routeryou'll need to remove the old key for the peer and then re-add it. To do this, first execute the crypto key pubkey-chain rsa command. Then use the no named-key or no addressed-key command to remove the peer (based on how you added the key), which will remove the peer and the key; then re-add the peer's key as I explained at the beginning of the section. Example 16-9 shows an example of this for the peer listed in Examples 16-7 and 16-8.

Example 16-9. Removing a Peer's Public Key

r3640(config)# crypto key pubkey-chain rsa r3640(config-pubkey-chain)# no addressed-key 192.1.1.1

Of course, you might need to generate and use new keys on your router. You might need to do this because your keys have been compromised, or because a change in security policy dictates a change in the modulus value used to generate the keys. To remove your router's own public/private keys, use this command:

Router(config)# crypto key zeroize rsa [key_pair_label]

Without specifying a key pair label for a specific key pair, all the router's personal public/private keys are deleted. If the router has more than one set of keys, you can specify which is deleted by examining the list of keys from the output of the show crypto key mypubkey rsa command and entering the name of the key.

Note

If the router's key is specified manually somewhere else in the router's configuration, you won't be able to delete it until you remove its reference. For example, certificates use public/private keys; therefore, if the router has a certificate, you'd first have to delete the router's certificate, and then the router's keys associated with the certificate.

Digital Certificates and Router Enrollment

Unlike symmetric or asymmetric (RSA encrypted nonces) pre-shared keys, digital certificate information is not pre-shared with other peers. Like RSA encrypted nonces, a private key is used to create authentication information (signature) and a public key is used to verify the signature; however, this information is located on a certificate and is not pre-shared with a peer. Thus, digital certificates scale better than either of the two pre-shared methods.

In this section I'll discuss the use of certificates on routers and how they're used for authentication. The first two sections will discuss how to obtain a certificate with SCEP (in-band) and manually (out-of-band). Following this, I'll discuss how to export and import certificate and keying information for backup and redundancy purposes.

Enrolling for a Certificate using SCEP

Between manual enrollment and the Simple Certificate Enrollment Protocol (SCEP), SCEP is used most often to set up certificate services on a router. To use SCEP, though, your router cannot use public keys greater than 2,048 bits and you must use ISAKMP/IKE and IPsec to set up the management and data connections dynamically.

No matter whether you're using SCEP or the manual approach, typically you'll go through the following steps to get certificates on a router:

The following subsections will discuss each of these tasks.

Step 1: Verify that Certificates Can Fit into NVRAM

When using certificates for device authentication, the following information is, by default, stored in NVRAM of the router: the router's identity certificate, the router's private and public keys used to create and validate the signature on the router's PKCS #10 information, the CA's certificate, root certificates obtained from the CA, if any, two Registration Authority (RA) certificates, if the CA supports an RA, and one or more CRLs.

Note

Use the show running-config command to determine how much NVRAM your router is currently using.

Because this can represent a large amount of information, NVRAM might be too small to store this information, which is possible on smaller, older router models. If this is the case, you have the option of having the router download this information from the CA with the exception of the following information: the router's public and private keys and the signature on the CA certificatethis information will be stored locally in NVRAM and all other certificate information will be downloaded to the router when it boots up and will be stored in RAM. This process is called query mode. To turn on the query mode of the router, use this command:

Router(config)# crypto ca certificate query

To turn off query mode later, use the no crypto ca certificate query after the router has downloaded all certificate information and then execute copy running-config startup-config to save the downloaded certificate information to NVRAM. If you currently are not using query mode and want to enable it, use the above command to remove all certificate information stored in NVRAM and then save the router's configuration (copy running config startup-config).

Note

Using the query method affects the performance of the router because it must download the certificate information before the router can establish IPsec tunnels. Also, this means that if the CA is not reachable, the router will not be able to download the certificate information and thus will not be able to build IPsec tunnels.

Steps 2 and 3: Names and RSA Key Pairs

A private key is needed on the router to generate the signature for the router's identity information (PKCS #10) and a public key is necessary to validate the signature for the PKCS #10 information. I've already discussed this configuration in the "Generating RSA Encrypted Nonces (Key Pairs)" section, where you use the hostname command to assign a name to the router, the ip domain-name command to assign a domain name, and the crypto key generate rsa command to create the router's public/private keys. Remember that if you want to create a separate RSA key pair for this certificate compared to other certificates your router has, you'll need to add a key pair label to the end of the command (see the "Multiple RSA Key Pairs" section earlier).

Step 4: Define a CA

Once you have generated your RSA key pair, you can then define the CA your router will be using for IPsec device authentication. This is done with the commands shown in the following code listing:

Router(config)# crypto {ca | pki} trustpoint CA_name Router(ca-trustpoint)# enrollment url CA_URL Router(ca-trustpoint)# enrollment http-proxy proxy_IP_address proxy_port_# Router(ca-trustpoint)# enrollment mode ra Router(ca-trustpoint)# enrollment retry period minutes Router(ca-trustpoint)# enrollment retry count number Router(ca-trustpoint)# crl {query URL | optional} Router(ca-trustpoint)# ocsp url OCSP_server_URL Router(ca-trustpoint)# revocation-check method1 [method2 [method3]] Router(ca-trustpoint)# query certificate Router(ca-trustpoint)# primary Router(ca-trustpoint)# source interface name_and_number_of_interface Router(ca-trustpoint)# default command Router(ca-trustpoint)# exit

The crypto ca trustpoint specifies CA properties to use to interact with the CA: you can use either the ca or pki parameter to signify the configuration type. The CA_name you specify is typically the FQDN of the CAyour CA administrator will give you this value. When executing this command, you are taken into a subcommand mode where you can enter the properties for interacting with the CA.

The enrollment url command specifies the URL to interact with the CA when requesting certificates; again, your CA administrator will give you this information. These are the only two required commands to interact with the CA; the remaining commands are optional. If your CA is behind a web proxy, you'll need to configure your router to interact with the proxy with the enrollment http-proxy command, specifying the IP address (or FQDN) of the proxy and the port number to use when contacting the proxy.

The enrollment mode ra command specifies whether or not the CA provides for an RA(s); you don't need to configure this command because IOS routers will determine automatically whether the CA is using an RA(s) or not. If the router determines that RAs are being used, this command will appear automatically in the router's configuration.

The enrollment retry period command specifies the length of time that the router will wait for a certificate from the CA before requesting it again. The default is one minute. The enrollment retry count command specifies how many times the router will continue contacting the CA for a certificate request before giving up; the default configuration specifies that the router will try continually without ever giving up.

Note

If your CA is an IOS router CA, the URL you specify in the enrollment url command needs to be as follows: enrollment url http://IP_address_or_FQDN_of_router_CA; no CGI-BIN script or additional information is necessary. For more information on using a router as a CA, see the "Routers as Certificate Authorities" section later in the chapter.

The crl command specifies configuration options for using CRLs. The query parameter specifies an LDAP or HTTP server where the CRL is located and is in the format of "{ldap|http}://IP_address/other_URL_info." The optional parameter specifies that CRLs might or might not be used by your CA and thus your router will accept a peer's certificate if a CRL cannot be located. If you know that your CA uses CRLs, don't configure this command; otherwise you inadvertently might use a revoked certificate, because CRL checking is optional with this command enabled.

The Online Certificate Status Protocol (OCSP) allows devices to use this process, instead of CRLs, to check the status of certificates. This feature is new in IOS 12.3(2)T. OCSP has a few advantages over CRLs. First, it runs across HTTP instead of the possibility of LDAP; second, it provides more frequent updates to the edge devices than CRLs provide (CRLs do this only periodically); and third, OCSP allows you to configure a central OCSP server to collect and update CRLs from multiple CAs, simplifying and speeding up the CRL checking process by an edge device.

The ocsp url command specifies the OCSP's location of revoked certificates; if the CA's certificate has this location already on it and you configure the ocsp url command, the configured command overrides the information on the CA's certificate. The revocation-check command specifies the method or order of methods to use to check the revocation status of a certificate. There are three defined method parameters: crl, ocsp, and none. crl specifies that certificate checking is performed by a CRLthis is the default option; oscp specifies that checking is performed by an OCSP server; and none specifies that no certificate checking is performed (this command replaces the crl optional command in the latest IOS releases).

The query certificate command specifies that any certificate information for this particular trustpoint is not stored in NVRAMthe advantage of this command over the crypto ca certificate query command is that the latter is global and affects all CAs defined on the router, whereas the former affects only the current trustpoint's configuration. The primary command specifies that this particular trustpoint is assigned the primary CA role on the router; this command is necessary only if you have more than one CA configured and you want one to be the primary one. The source interface command, new in IOS 12.2(15)T, specifies the source interface to use for traffic to be sent to the CA. This command typically is used when the exit interface of the router has a private (or IP address, but the router does have another interface with a public address and wants this address to be used. If you omit this command, the router uses the interface chosen based on its routing table selection.

The default command, followed by another trustpoint command, sets the specified trustpoint command back to the default value. This is useful if you want to undo a trustpoint configuration command. Other optional commands can be configured under the trustpoint (in the trustpoint subcommand mode), however, I'll discuss these in later sections.

Note

In IOS versions before 12.2(8)T, the command to specify the CA is crypto ca identity; this has be supplanted by the crypto ca trustpoint command. This is also true of the crypto ca trusted-root, which allows you to specify a root CA in a hierarchical CA setup.

Step 5: Download and Authenticate the CA's Certificate

Once you have defined the interaction between the router and the CA, you are ready to download and authenticate the CA's self-signed certificate by using this command:

Router(config)# crypto {ca | pki} authenticate CA_name

You need to configure the same CA name that you configured in the crypto ca trustpoint command in the last section. Example 16-10 illustrates this process. The name of the CA is "caserver." Upon downloading the CA certificate, you'll be prompted to accept it; before accepting it, first validate the CA's signature on the self-signed certificate. It's important that you do this, because this is the weakest link in the security process of using certificates. At this point, a man-in-the-middle attack could be occurring and you could be receiving a hostile or invalid CA certificate.

Example 16-10. Downloading and Authenticating the CA's Certificate

r3640(config)# crypto ca authenticate caserver Certificate has the following attributes: Fingerprint MD5: CE9956AA C02D15DF A2309A9C E059BD47 Fingerprint SHA1: 475A5DBA 0283DB43 305E9CF7 A208C8B8 E894C379 % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted.

Step 6: Request the Router's Identity Certificate

Before you can request the router's identity certificate, first you must have downloaded and verified the CA's certificate in Step 5. This is necessary so that the router can use the CA certificate to validate any certificate received (from the same CA's domain), including the router's own identity certificate. Likewise, you already must have generated an RSA key pair which is used to sign and verify the identity certificate request. When you have completed these steps, you are now ready to create the PKCS #10 information that will be sent to the CA, via SCEP, with this command:

Router(config)# crypto {ca | pki} enroll CA_name

The CA name you list must be the same name configured in the crypto ca authenticate and crypto ca trustpoint commands. First you'll be prompted for a challenge password. This password serves two purposes: it is used by the CA to control who can request a new certificate and by the CA administrator to revoke a valid certificate. You also have the option of including the router's serial number or IP address in the identity certificate. Once you answer yes to request a certificate, the router puts together the PKCS #10 information and sends this to the CA via HTTP. Once the request has been approved and the identity certificate generated, your router will download the identity certificate automatically. Example 16-11 illustrates how to use SCEP to request an identity certificate for your router.

Example 16-11. Obtaining the Router's Identity Certificate

r3640(config)# crypto ca enroll caserver % Start certificate enrollment .. % 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: cisco123abc Re-enter password: cisco123abc % The fully-qualified domain name in the certificate will be: r3640.cisco.com % The subject name in the certificate will be: r3640.cisco.com % Include the router serial number in the subject name? [yes/no]: no % Include an IP address in the subject name? [no]: no Request certificate from CA? [yes/no]: yes % Certificate request sent to Certificate Authority % The certificate request fingerprint will be displayed. % The 'show crypto pki certificate' command will also show the fingerprint. 05:32:29: CRYPTO_PKI: Certificate Request Fingerprint MD5: F9A3574C 09BAC68D 491D0FDA 1EBCE0BC 05:32:29: CRYPTO_PKI: Certificate Request Fingerprint SHA1: 898BDC0B 69F74320 8EECF1FF FD86503F 3DC366BB 05:32:34: %PKI-6-CERTRET: Certificate received from Certificate Authority

Step 7: Save the CA and Identity Certificates

Assuming you have enough NVRAM to store your router's certificate components, the last step is to save these components to NVRAM with the copy running-config startup-config command. If the router reboots before the requested identity certificate was installed and saved, you'll need to re-execute the crypto ca enroll command; the same is true for downloading and authenticating the CA certificate: crypto ca authenticate. Both of these commands are not saved in the router's NVRAM.

Step 8: Verify the Certificate Operation

Once you have an identity certificate on the router, the last step is to verify the certificate operation process. To view the CA or CAs you have configured on your router, use the show crypto {ca | pki} trustpoint. The output of this command, shown in Example 16-12, displays some of the information found on the CA certificate, in addition to how the trustpoint is configured on the router.

Example 16-12. The show cyrpto ca trustpoints Command

r3640# show crypto ca trustpoints Trustpoint caserver: Subject Name: cn=caserver c=US Serial Number: 6EBD53BA55C2D29841E0A0D48E40CF96 Certificate configured. SCEP URL: http://192.1.1.77:80/certsrv/mscep/mscep.dll

To view any certificates the router has, use the show crypto {ca | pki} certificates command, shown in Example 16-13. The first certificate is the router's identity certificate and the second one is the CA's.

Example 16-13. The show crypto ca certificates Command

r3640# show crypto ca certificates Certificate Status: Available Certificate Serial Number: 11320A3500010000001A Certificate Usage: General Purpose Issuer: cn=caserver c=US Subject: Name: r3640.cisco.com hostname=r3640.cisco.com CRL Distribution Points: http://i7500/CertEnroll/caserver(1).crl Validity Date: start date: 03:41:05 UTC Feb 26 2005 end date: 03:51:05 UTC Feb 26 2006 Associated Trustpoints: caserver CA Certificate Status: Available Certificate Serial Number: 6EBD53BA55C2D29841E0A0D48E40CF96 Certificate Usage: Signature Issuer: cn=caserver c=US Subject: cn=caserver c=US output omittedimages/U2192.jpg border=0>

To request the current CRL for the CA or configured LDAP server, execute the following command:

Router(config)# crypto ca crl request CA_name

Be sure to use the name of the CA configured in the crypto ca trustpoint command when requesting the current CRL. This command typically is used if certificates have been revoked on the CA, but you suspect your router doesn't have the most up-to-date CRL. To view the status of the CRL, use the show crypto {ca | pki} crls command; an example of this is shown in Example 16-14.

Example 16-14. The show crypto ca crls Command

r3640# show crypto ca crls CRL Issuer Name: cn=caserver,c=US LastUpdate: 01:18:27 UTC Feb 25 2005 NextUpdate: 13:38:27 UTC Mar 4 2005 Retrieved from CRL Distribution Point: http://i7500/CertEnroll/caserver(1).crl

Tip

You can use the debug crypto pki command to troubleshoot problems related to the request and use of certificates.

Deleting Certificates

There are many reasons you might want to delete a certificate, including the following:

• You need to generate an RSA key pair with a longer (or shorter) modulus.
• Your current certificate has expired.
• Your private key has been compromised.
• You no longer are using the certificate for authentication functions.

To delete a certificate, such as your router's identity certificate, first view the certificate with the show crypto ca certificates command and look for the serial number of the certificate to be revoked. Then execute the following two commands:

Router(config)# crypto ca certificate chain CA_name Router(config-cert-cha)# no certificate certificate-serial-number

With the first command, you must specify the name of the trustpoint configured in the crypto ca trustpoint command. This takes you into a subcommand mode where you remove the certificate by specifying the serial number of the certificate to be deleted with the no certificate command.

Once a certificate is deleted, you can remove its associated RSA key pair with the crypto key zeroize rsa command, discussed earlier in the "Removing RSA Keys" section. Also, if you no longer will be using certificates for authentication functions and wish to remove all certificate information on your router, use the following command:

Router(config)# no crypto ca trustpoint CA_name

This command allows you to remove not only the configuration of the trustpoint (the associated trustpoint commands), but the CA certificate, any RA certificates, any CRLs, and the router's identity certificate(s).

Enrolling for a Certificate Manually

If your CA doesn't support or use SCEP, you'll need to obtain certificates for your router using manual enrollment. Manual enrollment can be accomplished using TFTP or cut-and-paste if you're running IOS 12.2(13)T or later.

Note

Cisco doesn't recommend using SCEP to obtain one certificate and TFTP or cut-and-paste to obtain the other certificate when retrieving the CA and identity certificates; this might create problems when trying to retrieve the second certificate from the CA.

Configuring Manual Enrollment Using TFTP

Configuring manual enrollment using TFTP is very similar to configuring certificate enrollment using SCEP: you'll need to go through the same eight steps discussed in the "Enrolling for a Certificate using SCEP" section. However, there are obviously a few differences. Steps 13 are the same: verify NVRAM usage, configure the router's host and domain names, and generate the RSA keys.

Step 4, defining a CA, is slightly different. First, make sure the router can reach a TFTP server and has write access to the TFTP server's directory structure. Next, configure the trustpoint with the crypto ca trustpoint command. This command was discussed previously in the "Step 4: Define a CA" section. The main difference is the enrollment url command, which needs to specify a URL with a TFTP file type and the location of the TFTP server:

Router(config)# crypto ca trustpoint CA_name Router(ca-trustpoint)# enrollment url tftp://server_name_or_address/file_name

For example, you might enter something like enrollment url tftp://caserver/directory/cacert. In most cases, the TFTP server will be the same device that's the CA if you're setting up your own CA. Otherwise, you'll use a local TFTP server. The file specified is the CA's certificate and must be in a base-64 encoding scheme. Also, the router will append ".ca" as an extension to the file name; so in this example, the file on the tftp server is "cacert.ca." If you omit a file name, the name will default to the router's FQDN plus the ".ca" extension, like "r3640.cisco.com.ca." The other trustpoint commands discussed previously in the "Step 4: Define a CA" section also can be configured as necessary.

Next, perform Step 5 as discussed previously in the "Step 5: Download and Authenticate the CA's Certificate" section by executing the crypto ca authenticate command to download and authenticate the CA's certificate (from the TFTP server). You'll need to verify the CA's signature and accept it if valid.

Following this, request the router's certificate by executing the crypto ca enroll command, discussed previously in the "Step 6: Request the Router's Identity Certificate" section. In this case, the command creates the router's PKCS #10 information and sends it to the TFTP server, which Example 16-15 illustrates. The name of the file on the TFTP server will be the file name listed in the enrollment url command followed by ".req" as an extension, as you can see from Example 16-15. Give this file to the CA administrator, which then will be used by the CA to create an identity certificate for your router.

Example 16-15. Sending the Router's PKCS #10 Information to the TFTP Server

r3640(config)# crypto ca enroll caserver % Start certificate enrollment .. % The fully-qualified domain name in the certificate will be: r3640.cisco.com % The subject name in the certificate will be: r3640.cisco.com % Include the router serial number in the subject name? [yes/no]: no % Include an IP address in the subject name? [no]: no Send Certificate Request to file system? [yes/no]: yes % Certificate request sent to file system % The certificate request fingerprint will be displayed. % The 'show crypto pki certificate' command will also show the fingerprint. !Writing file to tftp://192.1.1.77/cacert.req! 09:20:42: CRYPTO_PKI: Certificate Request Fingerprint MD5: E5CC32D1 AB29F816 94BC76A8 ADC525EE 09:20:42: CRYPTO_PKI: Certificate Request Fingerprint SHA1: A5006A64 5E0BA531 97878ED0 A84AA3A8 8F6B9C82

Once the CA administrator has generated an identity certificate for your router, it needs to be saved with a ".crt" extension and with the same filename specified in the enrollment url command. This file must be stored in a base-64 encoding scheme (PKCS #10) as the CA certificate was previously, and placed in the same directory on the TFTP server as the CA's certificate. Then you can import the identity certificate with the crypto ca import command:

Router(config)# crypto ca import CA_name certificate

You must specify the name of the CA configured as a trustpoint with the crypto ca trustpoint command. Example 16-16 illustrates the use of this command. As you can see in this example, the router's identity certificate is named "cacert.crt" on the TFTP server.

Example 16-16. Importing the Router's Identity Certificate via TFTP

r3640(config)# crypto ca import caserver certificate % The fully-qualified domain name in the certificate will be: r3640.cisco.com Retrieve Certificate from file system? [yes/no]: yes % Request to retrieve Certificate queued Reading file from tftp://192.1.1.77/cacert.crt Loading cacert.crt from 192.1.1.77 (via Ethernet0/0): ! [OK - 1118 bytes] 09:31:07: %PKI-6-CERTRET: Certificate received from Certificate Authority

Tip

Because of naming complications on multiple routers, I recommend that you have a separate certificate directory on the TFTP server for each router. This reduces the likelihood of another router pulling in your certificate, since there is no authentication or access control with TFTP. Plus, the same file name is used for the CA and identity certificate, like "caserver"; what's unique is the extension: ".ca" for the CA certificate and ".crt" for the identity certificate.

Finally, save your router's certificate information with the copy running-config startup-config command, view the trustpoint with the show crypto ca trustpoint command, and view your router's certificate information with the show crypto ca certificates command (steps 7 and 8).

Configuring Manual Enrollment Using Cut-and-Paste

If using SCEP and a TFTP server is not an option, you can use the old-fashioned copy-and-paste process with manual enrollment. Steps 13 are the same as the other two processes for obtaining a certificate. Step 4, defining a CA, is slightly different than the other two, however. As with the other two, configure the trustpoint with the crypto ca trustpoint command. This command was discussed previously in the "Step 4: Define a CA" section. The main difference is the enrollment terminal command, which specifies that cut-and-paste will be used to obtain the CA's certificate.

Router(config)# crypto ca trustpoint CA_name Router(ca-trustpoint)# enrollment terminal

The other trustpoint commands discussed previously in the "Step 4: Define a CA" section can also be configured as necessary.

Once you have defined the CA, in Step 5 you'll execute the crypto ca authenticate command to obtain the CA's certificate. In the other two processes, this was achieved using SCEP or TFTP. With cut-and-paste, you'll need to open the file the CA administrator gave you containing the CA's certificate, copy the contents including the beginning and ending lines starting with the dashes ("-----"), and paste it into the router's configuration when prompted. Example 16-17 illustrates this process. Once you have pasted the CA certificate into the router, type in quit on a blank line to terminate the cut-and-paste process and to have the router import the CA's certificate.

Example 16-17. Importing the CA's Certificate with Cut-and-Paste

r3640(config)# crypto ca authenticate caserver Enter the base 64 encoded CA certificate. End with a blank line or the word "quit" on a line by itself -----BEGIN CERTIFICATE----- MIIChTCCAe6gAwIBAgIQbr1TulXC0phB4KDUjkDPljANBgkqhkiG9w0BAQUFADAg MQswCQYDVQQGEwJVUzERMA8GA1UEAxMIY2FzZXJ2ZXIwHhcNMDQwMTE2MDc0MjAw output omittedimages/U2192.jpg border=0> BX3p1Wxz+tSEQwrChIzbHcFAUP1Gq0dpBQ== -----END CERTIFICATE----- quit Certificate has the following attributes: Fingerprint MD5: CE9956AA C02D15DF A2309A9C E059BD47 Fingerprint SHA1: 475A5DBA 0283DB43 305E9CF7 A208C8B8 E894C379 % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. % Certificate successfully imported

Next, you need to create your PKCS #10 information for your router's identity certificate with the crypto ca enroll command, as shown in Example 16-18. The execution of this command is similar to the other two processes; however, you have the option of displaying the PKCS #10 information to the router's terminal screen, which you want to answer yes. At the line that states Certificate Request follows, select the information here, copy it, store it in a file, and send it to the administrator of the CA, who will use it to create an identity certificate for your router.

Example 16-18. Creating the Router's PKCS #10 Information for the Cut-and-Paste Process

r3640(config)# crypto ca enroll caserver % Start certificate enrollment .. % The fully-qualified domain name in the certificate will be: r3640.cisco.com % The subject name in the certificate will be: r3640.cisco.com % Include the router serial number in the subject name? [yes/no]: no % Include an IP address in the subject name? [no]: no Display Certificate Request to terminal? [yes/no]: yes Certificate Request follows: MIH7MIGmAgEAMCAxHjAcBgkqhkiG9w0BCQIWD3IzNjQwLmNpc2NvLmNvbTBcMA0G CSqGSIb3DQEBAQUAA0sAMEgCQQCobLU/S3ExRpMEJrkDLGMxHInlrwH33C7PpLli hehmSFlWgTx1GSTTAxVkQdpYJ09NQ76CFGQ6Bpi7BDCI8hZrAgMBAAGgITAfBgkq hkiG9w0BCQ4xEjAQMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQQFAANBACNW JHzO5brezlfI4db5RdLjgh7Wd5zmv84gfQwxtL0GPXJ0SRzK4/1L6le15jefrEu2 Tkag3YiQUZURfJB1smA= ---End - This line not part of the certificate request--- Redisplay enrollment request? [yes/no]: no r3640(config)#

Once the administrator has created a certificate for your router and sent this to you, you can then import the certificate into your router using the crypto ca import command discussed in the last section, which is shown in Example 16-19. After pasting in the certificate, on a blank line type in quit, signifying that this is the end of the cut-and-paste process. The router will validate the certificate and import it. And as with the other two certificate enrollment processes, be sure to save your router's certificate and configuration information to NVRAM and view your certificate information to validate it.

Example 16-19. Importing the Router's Identity Certificate Using Cut-and-Paste

r3640(config)# crypto ca import caserver certificate % The fully-qualified domain name in the certificate will be: r3640.cisco.com Enter the base 64 encoded certificate. End with a blank line or the word "quit" on a line by itself -----BEGIN CERTIFICATE----- MIIC/TCCAmagAwIBAgIKEgiafQABAAAAGzANBgkqhkiG9w0BAQUFADAgMQswCQYD VQQGEwJVUzERMA8GA1UEAxMIY2FzZXJ2ZXIwHhcNMDUwMzE3MDAzNTIyWhcNMDYw output omittedimages/U2192.jpg border=0> +vtDsziATo59EAjGmV8ofqr+oxpuOCM4cCN0BL3babe70dqtbMYLGyN+p6/K1jqA -----END CERTIFICATE----- quit % Router Certificate successfully imported

Autoenrollment for Certificates

In IOS 12.2(8)T, Cisco introduced the certificate autoenrollment feature, which allows you to set up your router so that it will request a certificate from a CA using the parameters in your configuration, eliminating any type of administrator intervention on the router when requesting a certificate from a CA. This process is triggered when a trustpoint CA has been configured, but a corresponding CA certificate doesn't exist on the router; plus, when the router's certificate expires, the router automatically will request a new certificate as needed. Of course, the administrator of the CA still might need to approve your router's certificate request via autoenrollment; however, you don't have to do anything to initiate the process from the router side.

Autoenrollment Trustpoint Configuration

The configuration of autoenrollment is very similar to the configuration of enrollment for certificates using SCEP. As with SCEP, you need to verify your NVRAM usage, configure a name and domain name on the router, and generate an RSA key pair. Once you've done this, you now need to configure your trustpoint. The commands discussed in the "Enrolling for a Certificate using SCEP" section earlier apply to this configuration, because SCEP is being used; however, there are some additional commands you need to configure, shown here:

Router(config)# crypto ca trustpoint CA_name Router(ca-trustpoint)# enrollment url CA_URL Router(ca-trustpoint)# subject-name [x.500_name] Router(ca-trustpoint)# ip-address {interface_name_or_IP_address | none} Router(ca-trustpoint)# serial-number [none] Router(ca-trustpoint)# password password_value Router(ca-trustpoint)# rsakeypair key_label [key_size [encryption_key_size]] Router(ca-trustpoint)# auto-enroll [regenerate]

The subject-name command specifies the X.500 field values that will appear on the certificate; if you omit this, it defaults to the FQDN of the router only for the Common Name. The ip-address command specifies the IP address or router interface name (which would include that interface's IP address) to be included on the certificate; specify the none parameter if you don't want an IP address on the identity certificate. The serial-number command specifies that the router's serial number should be included in the certificate request; use the none parameter to exclude this from the certificate request. The password command specifies the password to use for revoking passwords, called the challenge password.

The rsakeypair command specifies which RSA key pair to use for the certificate; the key_label parameter specifies the name of an existing key pair or of a new key pair, the key_size parameter specifies the modulus for the signature keys and the encryption_key_size specifies the modulus for the encryption keys. If you omit this command, the FQDN default key pair is used. If you specify the keying information, once autoenrollment starts, if the specified key label doesn't exist, autoenrollment will create the RSA key pair automatically; you can view the new key pair with the show crypto key mypubkey rsa command. For more information on multiple key pairs, see the "Multiple RSA Key Pairs" section earlier.

Note

One thing to note is that if you don't configure a specific value that typically is prompted for by the router, you'll still be prompted for these items; therefore, be sure that you configure all command values (even if you set it to none) so that autoenrollment occurs without any operator intervention.

The last step you need to perform in the trustpoint configuration is to enable autoenrollment with the auto-enroll command. The regenerate parameter specifies that a new RSA key pair should be created for the certificate even if a named key pair already exists. This ensures that when a router's certificate expires and it needs to request a new one, new keys are used instead of the ones from the old certificate.

Autoenrollment and the CA Certificate

When you're done with the trustpoint configuration with autoenrollment, within a few seconds the IOS will tell you that autoenrollment won't work until you obtain the CA's certificate and authenticate it. This can be done using one of the following two methods:

• Using SCEP to obtain the CA certificate
• Manually adding the CA certificate from the CLI

To use SCEP to obtain the CA's certificate, execute the crypto ca authenticate command with the name of the CA, discussed previously in the "Step 5: Download and Authenticate the CA's Certificate" section. The second option is to add the CA's certificate manually, using the crypto ca certificate chain and certificate ca commands. Because SCEP already is required to use autoenrollment, I won't discuss the latter approach.

Wait a few minutes for the autoenrollment process to start and obtain the router's identity certificate. If you're impatient, save your router's configuration and reboot it; upon rebooting, it will obtain its identity certificate.

Autoenrollment Example

Now that you understand the basic configuration for autoenrollment, I'll look at a simple configuration in Example 16-20 that illustrates how to set up autoenrollment. After the trustpoint configuration, the IOS warns you that you must next download and authenticate the CA certificate, which I did with the crypto ca authenticate command. Once this was done, about a minute later the autoenrollment process started with the information I configured under the trustpoint. At the end, the router automatically saved its certificates (and configuration) to NVRAM. Once done, you'll want to use the show crypto ca certificates and show crypto ca trustpoints command to verify that autoenroll did indeed acquire an identity certificate for your router.

Example 16-20. Sample Configuration Using Autoenrollment

r3640(config)# crypto ca trustpoint caserver r3640(ca-trustpoint)# enrollment url http://192.1.1.77/certsrv/mscep/mscep.dll r3640(ca-trustpoint)# ip-address none r3640(ca-trustpoint)# password dontrevokeme r3640(ca-trustpoint)# rsakeypair caserver 512 r3640(ca-trustpoint)# auto-enroll regenerate r3640(ca-trustpoint)# exit % You must authenticate the Certificate Authority before you can enroll with it. r3640(config)# crypto ca authenticate caserver Certificate has the following attributes: Fingerprint MD5: CE9956AA C02D15DF A2309A9C E059BD47 Fingerprint SHA1: 475A5DBA 0283DB43 305E9CF7 A208C8B8 E894C379 % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. % Start certificate enrollment .. % The subject name in the certificate will be: CN=r3640.cisco.com, OU=corporate, O=cisco % The fully-qualified domain name in the certificate will be: r3640.cisco.com % The subject name in the certificate will be: r3640.cisco.com % Certificate request sent to Certificate Authority % The certificate request fingerprint will be displayed. % The 'show crypto pki certificate' command will also show the fingerprint. 05:23:29: %CRYPTO-6-AUTOGEN: Generated new 512 bit key pair 05:23:30: CRYPTO_PKI: Certificate Request Fingerprint MD5: 85D91350 640EA994 0645C9C9 5D86563E 05:23:30: CRYPTO_PKI: Certificate Request Fingerprint SHA1: 677272CE B3E44144 AF143210 025C8AA3 36C155E1 05:23:33: %PKI-6-CERTRET: Certificate received from Certificate Authority 05:23:33: %PKI-6-AUTOSAVE: Running configuration saved to NVRAM

Certificate Attribute-Based Access Control

The certificate attribute-based access control (CABAC) feature, introduced in IOS 12.2(15)T, allows you to perform an additional step in authenticating a certificate. With CABAC, you can have the router look at specific certificate fields on a certificate and the values associated with them when determining whether or not you'll accept the certificate.

CABAC allows you to look at one or more fields on a certificate for an acceptable value(s). The kinds of tests you can perform are: equal to, not equal to, contains, doesn't contain, is less than, and is greater than or equal to, for the contents of a field. If you specify more than one test, all tests on all the specified fields must be true for a match to occur and an action to take place. Another nice feature is that you can specify a field multiple times within CABAC if you are looking for a number of permitted values.

For example, maybe you have a network with a router that handles site-to-site sessions with only a few remote access sessions for administrative functions, where the remote access authentication is handled by an AAA server such as Cisco Secure ACS (CSACS). You also have a VPN 3030 concentrator that handles user remote access IPsec sessions, where the 3030 also uses CSACS to authenticate the users. Both the router and 3030 use certificates for device authentication. However, you don't want the users to establish IPsec remote access sessions to the router, which they could, by default, because both the router and 3030 use certificates from the same CA for device authentication and the same source (CSACS) for user authentication (XAUTH). In this instance, you can use CABAC to match on the OU field that the network administrators belong to, in addition to the site-to-site connection devices, and thereby exclude all other remote access users.

Note

The memory and processing required to perform CABAC is minimal and adds very little overhead to the router and certificate verification process.

CABAC Configuration

Configuring CABAC is a two-step process:

To create your match rules, you need to create a certificate map with your rules embedded within the map:

Router(config)# crypto ca certificate map map_name sequence_# Router(ca-certificate-map)# field_name operator match_value

The crypto ca certificate map command is similar to configuring a crypto map for IPsec (discussed in the next chapter). The map can have multiple entries in it, where each entry has a unique sequence number. Sequence numbers can range from 165,535, where entries are processed in numerical order. The entries are grouped together into a single map by specifying the same map_name for each statement. Normally, I use the name of the CA that this will be applied against, but you can use whatever map name you choose (just so it is unique among all certificate map names on the router).

After executing the crypto ca certificate map command, you are taken into a subcommand mode where you can enter your matching criteria. The first value you enter on a command line is the name of the field on the certificate you're going to match against: subject-name, issuer-name, unstructured-subject-name, alt-subject-name, name, valid-start, and expires-on. The second value you enter is the operator, which can be one of the following:

• eq equal to (valid for the name and date fields only)
• ne not equal to (valid for the name and date fields only)
• co contains the specified value (valid only for the name fields)
• nc does not contain the specified value (valid only for the name fields)
• lt less than (valid only for the date fields)
• ge greater than or equal to (valid only for the date fields)

The last parameter, match_value, specifies what value you are matching against.

Once you have created your certificate mappings, you need to apply them to the trustpoint CA that handles the certificate functions in question:

Router(config)# crypto ca trustpoint CA_name Router(ca-trustpoint)# match certificate map_name

This is done by going into the trustpoint configuration with the crypto ca trustpoint command for the CA that you want to apply the map to. The match certificate command specifies the certificate map configuration you created with the crypto ca certificate map command. At this point, any new IPsec sessions brought up will first be validated using the certificate map.

Note

The entries in the certificate map are processed in numerical order. Matching on names (strings) is case-insensitive. As soon as a match is found for an entry, no further processing occurs. When a match occurs (all specific matchings in the entry must match), the peer's certificate will then be validated by checking the authenticity of it with the CA's signature, checking the validity date of the certificate, and checking the revocation status (the last is optional). If a match isn't found in the certificate map, the certificate is automatically considered invalid and device authentication fails.

CABAC Configuration Example

Now that you have a basic understanding of the commands used for CABAC, I'll look at an example that illustrates its use. I'll use the example I referred to earlier about limiting IPsec access to the router to just the site-to-site sessions and the remote access network administrators, all of which are using certificates for device authentication. Example 16-21 shows the configuration of the router. The first entry (10) allows only a certificate that was issued by "caserver" where the Common Name (CN) is "r3620a.cisco.com" and the Organizational Unit (OU) field is "corporate"; this matches on one of the two routers for L2L sessions. Entry 20 matches on the second L2L peer. Entry 30 only looks for matches on certificates issued by "caserver" where the OU field is "netadmins," which represents the group name of the network administrator group. As you can see in this example, if there is not a match on these three entries, the remote peer will fail device authentication with certificates.

Example 16-21. Sample CABAC Configuration

r3640(config)# crypto ca certificate map certsallowed 10 r3640(ca-certificate-map)# issuer-name co caserver r3640(ca-certificate-map)# subject-name co cn=r3620a.cisco.com r3640(ca-certificate-map)# subject-name co ou=corporate r3640(ca-certificate-map)# exit r3640(config)# crypto ca certificate map certsallowed 20 r3640(ca-certificate-map)# issuer-name co caserver r3640(ca-certificate-map)# subject-name co cn=r3620b.cisco.com r3640(ca-certificate-map)# subject-name co ou=corporate r3640(config)# crypto ca certificate map certsallowed 30 r3640(ca-certificate-map)# issuer-name co caserver r3640(ca-certificate-map)# subject-name co ou=netadmins r3640(ca-certificate-map)# exit r3640(config)# crypto ca trustpoint caserver r3640(ca-trustpoint)# match certificate certsallowed

CRL and Expired Certificate Access Control Lists

Another way of controlling authentication with certificates is to use the CRL and expired certificate Access Control List (ACL) feature, new in IOS 12.3(4)T. If you are using CRLs and a peer's serial number is listed in the CRL, by default, your router will invalidate the peer's certificate, causing authentication to fail. Likewise, if your router's date is beyond the expiration date on a peer's certificate, your router will invalidate the peer's certificate, causing authentication to fail.

With the certificate ACL feature, you can create exceptions to these cases. This is useful, for instance, if your router's battery for its clock dies and always comes up with an incorrect date such as 1993 or 2002. Even using NTP, the router's NTP process only allows incremental changes in the time, so it might take a long time for the router to synchronize its time with the NTP server. In this situation, if a peer's certificate says the validation dates are from November 30, 2004 to November 30, 2006 and the current day is November 19, 2005, the certificate is obviously valid; however, when your router, with the bad clock battery, boots up, it might have a date of March 1, 2003. Obviously the router would think the peer's certificate is invalid, when in reality it is valid. The real remedy to this problem is to replace the router's clock battery. In the interim, though, you can use the certificate ACL feature to allow the router to accept the certificate based on an "invalid" date.

Certificate ACL Configuration

Configuring the certificate ACL feature is a two-step process similar to CABAC:

To create your match rules, you need to create a certificate map with your rules embedded within the map using the crypto ca certificate map (discussed in the last section). Once you create your map and its corresponding entries, you must enable them, which is done under the corresponding trustpoint CA:

Router(config)# crypto ca trustpoint CA_name Router(ca-trustpoint)# match certificate map_name [allow expired-certificate | skip revocation-check | skip authorization-check]

The allow expired-certificate parameter causes the router to not invalidate a certificate match found in the certificate map based on its date. The skip revocation-check parameter causes the router to ignore a serial number found in a CRL for matching certificates found in the certificate map. The skip authorization-check parameter specifies that the AAA check of a certificate is skipped when certificates with an AAA server are configured.

Expired Certificate ACL Configuration

I'll now illustrate the usefulness of the certificate ACL feature. In this example, assume that the clock battery on a 3640 has died and you have ordered a replacement. In the meantime, every time you cold-boot your router, it comes up with the wrong time and you have to change the time of the router manually to something close to what the NTP server is advertising to speed up the time-synchronization process. This has become a hassle because this router (at a remote site) periodically loses power and reboots. Using an Uninterrupted Power Supply would help simplify the problem, but the budget at the remote office didn't allow for it. This whole process has created a headache for you, because to administer the router, typically you do it through an IPsec L2L session from the corporate office; but in this case, the remote office's 3640 is invalidating the corporate office's certificate because the 3640 router's time always states March 1, 2002 when it boots up.

As a temporary fix to this problem, you've decided to exempt the corporate office's 7200 router certificate from expiration (on the remote office's 3640 router). Example 16-22 shows an example of what the remote office's 3640 router configuration would look like. In this example, the 7200's certificate (r7200.cisco.com) will be exempted from the expiration check when the 3640 at the remote office validates the 7200's certificate. Of course, once you replace the clock battery on the 3640, I would remove this configuration on the router.

Example 16-22. Sample Expiry ACL Configuration

r3640(config)# crypto ca certificate map certsallowed 10 r3640(ca-certificate-map)# issuer-name co caserver r3640(ca-certificate-map)# subject-name co cn=r7200.cisco.com r3640(ca-certificate-map)# subject-name co ou=corporate r3640(ca-certificate-map)# exit r3640(config)# crypto ca trustpoint caserver r3640(ca-trustpoint)# match certificate exemptcorprouter allow expired-certificate

Importing and Exporting RSA Keys and Certificates

One of the issues with RSA keys, which are used to sign and validate certificates, is that, by default, they cannot be saved anywhere except for NVRAM. This can present problems if the router fails and must be replaced, or if you buy a newer model router to replace an old one: you can't use the same certificate because you can't copy the RSA private key to the new router. In this situation, you would have to generate a new RSA key pair on the new router and acquire a new certificate.

Cisco realizes that this can create problems in certain situations. For example, in a failover configuration, two routers should have the same certificate and keys, otherwise the failover won't be seamless. Likewise, if you accidentally remove the wrong RSA key pair on a router, you would have to revoke the router's current certificate and generate new keys and a certificate request to allow for certificate authentication to proceed. Therefore, Cisco has developed a way that allows you to export and import RSA keys in IOS 12.2(15)T, specifically the private keys. This process applies to authentication methods that use RSA encrypted nonces or RSA signatureanything that uses an RSA key pair.

Tip

SSH also uses RSA key pairs for encryption. You can use the method described in this section to place the same RSA key pair on all routers and then allow your management station(s) to use the same public key to encrypt traffic to the routers, simplifying the management of RSA key pairs. Generate an RSA key pair to one router and export it to all other routers; then take the public key and configure it on the SSH client.

Creating an Exportable RSA Key Pair

By default, when you use the crypto key generate rsa command, the RSA key pair(s) created are not exportable. Plus, once a key pair is created, you cannot change whether or not it can be exportable. The only way to make an RSA key pair exportable is to define this when you create the key pair with the exportable parameter:

Router(config)# crypto key generate rsa {general-keys | usage-keys} [label RSA_key_label] exportable

You can verify whether or not an RSA key pair is exportable by executing the show crypto key mypubkey rsa command on your router. Example 16-23 shows an example of two key pairs: one exportable and one not.

Example 16-23. Nonexportable and Exportable RSA Key Pairs

r3640# show crypto key mypubkey rsa % Key pair was generated at: 10:49:01 EDT Mar 15 2005 Key name: r3640.cisco.com Usage: General Purpose Key Key is not exportable. Key Data: 305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00A86CB5 3F4B7131 46930426 B9032C63 311C89E5 AF01F7DC 2ECFA4B9 6285E866 48595681 3C751924 D3031564 41DA5827 4F4D43BE 8214643A 0698BB04 3088F216 6B020301 0001 % Key pair was generated at: 14:24:54 EDT Mar 17 2005 Key name: caservercert Usage: General Purpose Key Key is exportable. Key Data: 305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00C158F6 72F69C0D D0A8064E EAA88CE8 38A852CA C3927EEA 00CC8C62 8D8C26C4 38634CBE 5DF98751 B6F1194F DE80D659 6D5D3ADA EF6A708D 2EC77F46 CBCDF7C1 35020301 0001

Using a Configured RSA Key Pair for a Certificate

To associate the key pair with a certificate you'll be creating for your router, you would configure the following, which I've discussed in various sections throughout this chapter:

Router(config)# crypto ca trustpoint CA_name Router(ca-trustpoint)# enrollment url CA_URL Router(ca-trustpoint)# rsakeypair RSA_key_label Router(ca-trustpoint)# exit Router(config)# crypto ca authenticate CA_name Router(config)# crypto ca enroll CA_name Router(config)# exit Router# copy running-config startup-config

The important thing about this code is that you specify the exportable key pair label name in the CA trustpoint configuration before requesting your router's identity certificate.

Exporting the RSA Key Pair and Certificates

To back up your RSA key pair, in addition to the CA and identity certificates, use the following command on the router that has the exportable keys:

Router(config)# crypto {ca | pki} export CA_name pkcs12 destination_URL passphrase

You must specify the name of the CA trustpoint where you obtained your identity certificate. The destination_URL parameter specifies to where you want the keys exported. This can include the following locations: Flash memory, FTP, NVRAM, RCP, SCP, TFTP, XMODEM, and YMODEM. The passphrase parameter is used to encrypt the PKCS #12 file that will have the exported keys. You must use the same passphrase value when importing the keys so as to decrypt them. This process protects the keys from unauthorized access. The passphrase can be any combination of characters, numbers, and special characters with the exception of "?" (the question mark).

Note

The passphrase you enter for exporting and importing is not saved on the routerif you forget the phrase, you will not be able to import an encrypted PKCS #12 with your router's key pair.

Caution

When setting up exportable keys and certificates, anyone who has level 15 access on the router can export this information, which might create a security issue. If you are concerned about this, configure AAA on your router with accounting enabled for command execution; then you can determine who exported any keying material and when they did it. I discuss the use of AAA in my Cisco Router Firewall Security book with Cisco Press.

Importing the RSA Key Pair and Certificates

To import an RSA key pair, CA certificate, and identity certificate into a router, use the following command:

Router(config)# crypto {ca | pki} import CA_name pkcs12 source_URL passphrase

You'll need to use the same passphrase to decrypt the RSA key pair in the PKCS #12 file. Once you do this, you will still need to configure the router with the correct commands to interact with the CA, if necessary. You could easily copy the configuration of the original router and select and paste the correct router CA commands into the new router.

Backing up RSA Information Example

To help illustrate this process, I'll use a simple example shown in Examples 16-24 and 16-25. The first example shows the creation of the exportable keys, the process of acquiring certificates, and the exporting of the RSA information. In this example, I gave the RSA key pair label the name of the CA I'll use for certificates. You can use whatever key label you want; however, I typically use the name of the CA that the key pair will be associated with. The second example shows the import process on a second router. Of course, you'll need to complete the configuration on the second router to match that of the first, to use the imported RSA keys and certificates.

Example 16-24. RSA Key Pair Export Example

r3640A(config)# crypto key generate rsa general-keys label caserver exportable The name for the keys will be: caserver Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: % Generating 512 bit RSA keys ...[OK] r3640A(config)# crypto ca trustpoint caserver r3640A(ca-trustpoint)# enrollment url http://192.1.1.77/certsrv/mscep/mscep.dll r3640A(ca-trustpoint)# rsakeypair caserver r3640A(ca-trustpoint)# exit r3640A(config)# crypto ca authenticate caserver output omittedimages/U2192.jpg border=0> r3640A(config)# crypto ca enroll caserver output omittedimages/U2192.jpg border=0> r3640A(config)# crypto ca export caserver pkcs12 tftp://192.1.1.77/r3640A.pkcs12 cisco123 output omittedimages/U2192.jpg border=0> !Writing pkcs12 file to tftp://192.1.1.77/r3640A.pkcs12 CRYPTO_PKI: Exported PKCS12 file successfully. 04:01:56: %PKI-6-PKCS12EXPORT_SUCCESS: PKCS #12 Successfully Exported.

Example 16-25. RSA Key Pair Import Example

r3620B(config)# crypto ca import caserver pkcs12 tftp://192.1.1.77/r3640A.pkcs12 cisco123 output omittedimages/U2192.jpg border=0> Loading r3640.pkcs12 from 192.1.1.77 (via Ethernet0/0): ! [OK - 2307 bytes] CRYPTO_PKI: Imported PKCS12 file successfully. .Mar 18 19:37:58.987: %CRYPTO-6-PKCS12IMPORT_SUCCESS: