ISAKMP/IKE Phase 1 Management Connection

ISAKMP IKE Phase 1 Management Connection

In this first part of the chapter, I'll focus on the components necessary to allow IPsec traffic into the PIX/ASA and to build a management connection to a remote peer. Much of what I discuss here is applicable to both L2L and remote access sessions.

Allowing IPsec Traffic

Your first task is to allow IPsec session traffic into your PIX/ASA. Unlike Cisco routers, PIX/ASA devices behave differently when traffic is flowing through them. With these security appliances, interfaces are assigned security levels, and based on security level configurations, traffic is not allowed to flow from a lower to a higher level, by default. In most cases, your IPsec session traffic will be terminated on the device's outside interface, which is, from the FOS's perspective, the least secure.

You can use two methods to allow VPN traffic into or through the PIX from a less- to more- secure interface:

• Access control lists (ACLs)
• ACL bypassing

The following two sections will discuss both options. After this, I'll discuss one issue with moving traffic between interfaces that have the same security level.

Using ACLs to Allow IPsec Traffic

If you decide you'll use ACLs to allow IPsec traffic into your PIX/ASA, your ACL configuration will look something like the following:

appliance(config)# access-list ACL_name_or_# permit udp
 remote_peer_IP_address subnet_mask
 local_IP_address subnet_mask eq 500
appliance(config)# access-list ACL_name_or_# permit esp
 remote_peer_IP_address subnet_mask
 local_IP_address subnet_mask
appliance(config)# access-list ACL_name_or_# permit udp
 remote_peer_IP_address subnet_mask
 local_IP_address subnet_mask eq 4500
appliance(config)# access-list ACL_name_or_# permit tcp
 remote_peer_IP_address subnet_mask
 local_IP_address subnet_mask eq port_#
appliance(config)# access-list ACL_name_or_# permit protocol
 remote_protected traffic subnet_mask
 local_protected traffic subnet_mask
 [protocol_information]

The first ACL statement allows the management connection to be built. The second, third, and fourth statements are for the data connections. The second statement assumes that ESP traffic can reach the PIX/ASA without having to go through a PAT device. The third statement is for ESP traffic that is being encapsulated using NAT-T. New in FOS 7.0 is the ability of encapsulating ESP traffic in TCP, which statement four would allow. You can list up to ten TCP ports for IPsec over TCP, but the default is port 10,000; you'll need to list all ports you've configured the PIX/ASA to use, if any, in separate ACL statements.

The last ACL statement in the preceding syntax allows the tunneled packets to pass the ACL check. As mentioned in Chapter 17, "Router Site-to-Site Connections," routers process IPsec packets twice on the ACL (depending on the IOS version): once when they're protected and again after the router has verified the protection and decrypted them (in their clear-text form). PIX/ASA devices do the same thing. You'll need to list, probably in multiple ACL statements, the traffic that is allowed through the tunnel.

One other thing to point out about the ACL configuration is that in FOS 6.3, both AH and ESP are supported; however, in the initial release of FOS 7.0, only ESP is supported. If you are running 6.3 or earlier, and need to use AH, use protocol number 51 in the protocol field of the ACL statement.

Tip

Whenever possible, be specific about the remote and local addressing information in the PIX/ASA's ACL, because you want only certain types of IPsec traffic to enter your security appliance.

You'll then need to activate the ACL on the PIX/ASA's interface where the traffic will be entering:

appliance(config)# access-group ACL_name_or_# in
 interface logical_interface_name

 

Using ACL Bypassing to Allow IPsec Traffic

The second and less configuration-intensive solution (than configuring ACLs) is to use the ACL bypass feature for IPsec, which is configured with this command:

appliance(config)# sysopt connection permit-ipsec

This command performs the same function as manual configuration of the ACL statements, in the preceding section.

Note

Many administrators like to use this command because it's simple to configure; however, I don't like it for two reasons. First, any and all IPsec traffic is allowed into the PIX/ASA, which might not be legitimate IPsec traffic. Second, sometimes I don't have control of the remote peer and the traffic allowed to traverse the tunnel. To simplify things, the remote administrator and I agree on protecting traffic between two networks; however, I might need to exclude some of that traffic. In this instance, I would prefer to use an ACL to perform this function. Remember that in FOS 6.3 and earlier, an ACL could be applied only inbound on an interface. In 7.0, however, you can have an ACL applied inbound or outbound on the same interface. With 7.0, you might want to use the ACL bypassing option to allow the traffic into the router, but then use an ACL applied outbound on the other interfaces of the PIX/ASA to restrict where the tunneled packets can go.

 

Transmitting IPsec Traffic Between Multiple Interfaces with the Same Security Level

In FOS 6.x and earlier, one restriction the PIX had was that if traffic entered an interface, it could not exit an interface with the same security level; in other words, traffic could not traverse interfaces of the same security level. This, for most purposes, prevented you from setting up a PIX as a hub device in a hub-and-spoke design, or, for remote access sessions, required you to enable split tunneling to allow a user to access both the corporate site and the Internet. As an example, for hub devices in L2L sessions, or when split tunneling was disabled for remote access sessions, traffic would have to enter the outside interface of the PIX and then would have to exit the same interface (entering and leaving interfaces with the same security level). The PIX would not allow this process to occur.

In 7.0, the PIX/ASA allows you to enable this process by configuring the following command:

appliance(config)# same-security-traffic permit
 {intra-interface | inter-interface)

The intra-interface parameter allows traffic to enter and leave the same interface while the inter-interface parameter allows traffic to enter and leave two different interfaces with the same security level. With VPNs, the first parameter is the one used for hub devices in an L2L session, and as an Easy VPN Server or VPN gateway for remote access sessions where split tunneling is disabled.

Setting Up ISAKMP

ISAKMP/IKE typically is used to build IPsec sessions; however, you can do this manually, but then you would have to make the following concessions:

• You cannot use certificates for device authentication
• Anti-replay services are not used
• The encryption and hashing keys must be configured manually
• The IPsec SAs will never time out
• All SA configurations must be configured manually in all crypto map entries on all peers

Because of these concessions, most administrators opt to use ISAKMP/IKE to build and maintain IPsec sessions. However, you must enable ISAKMP/IKE on your PIX/ASA with the following command:

appliance(config)# crypto isakmp enable logical_interface_name

For each interface that will have IPsec sessions terminated on it, you'll need to repeat the command with the correct logical interface name. This is all that is necessary to enable ISAKMP/IKE; however, there are other options you can configure, as the next few sections will explain.

Address Translation Issues

As mentioned in Chapter 3, "IPsec," ESP packets typically cannot be forwarded through an address translation device performing PAT. To solve this problem, an IPsec device can encapsulate the ESP packet either in a UDP or TCP segment. Of the three approaches I discussed in Chapter 3, the PIX/ASA support two solutions: NAT-T and IPsec over TCP.

NAT-T was added in FOS 6.3, using a detection method to discover if UDP encapsulation is necessary. By default NAT-T is disabled, but can be enabled with this command:

appliance(config)# isakmp nat-traversal [keepalive_seconds]

By default, a keepalive is generated every 20 seconds to ensure that the associated address translation entry stays in the translation table of the address translation device the packets will be traversing. You can change this by specifying a value from 103,600 seconds. You'll probably want to set this to a small value, like 1020 seconds, to ensure that an idle data connection isn't timed out of any address translation device's translation table inadvertently.

IPsec over TCP support was added in FOS 7.0. This feature typically is used when the protected traffic has to move through a stateful firewall, and the firewall doesn't support UDP (which NAT-T uses). To enable IPsec over TCP, use the following command:

appliance(config)# isakmp ipsec-over-tcp [port port1...port10]

If you don't specify a port number for the connection, it defaults to port 10,000. However, you can specify a different port number and up to a total of 10 ports. In many instances, some ISP firewalls will block UDP port 4,500 and TCP port 10,000. You can get around this by specifying a TCP port that you don't use, but that the ISP will allow through, such as 8080 (some ISPs do this to residential customers, wanting more money for what they refer to as a "business-class" service).

Note

IPsec over TCP will not work with proxy-based firewalls; also, if you've enabled both NAT-T and IPsec over TCP, IPsec over TCP takes precedence over NAT-T.

 

Disconnect Notifications

By default, if you reset a PIX/ASA's interface, reboot the PIX/ASA, or clear the IPsec sessions, the PIX/ASA will not notify the remote IPsec peer(s) that the SA(s) are no longer available, which could cause connectivity issues. In FOS 7.0, Cisco added the disconnect notification feature, which has the local PIX/ASA send an ISAKMP disconnect message to all IPsec peers connected to it. To enable this feature, use the following command:

appliance(config)# isakmp disconnect-notify

Using this command definitely is useful when you have two PIX/ASA devices at a site and the remote peers know about both devices. In this situation, when the PIX/ASA must drop an SA(s) associated with an IPsec interface, it will notify the remote peers, which then can proceed to rebuild their sessions to the other PIX/ASA device at the same site.

Main Mode Restriction

The PIX/ASA support both main and aggressive modes in setting up the management connection, where main mode is the default. Aggressive mode is faster in setting up the connection; however, it transmits the identity information of the two peers in clear text, making it less secure. If you always want the PIX to use main mode, you can disable aggressive mode with the following command:

appliance(config)# isakmp am-disable

Please note that this command was introduced in FOS 7.0.

Configuring Management Connection Policies

Once you've taken care of the ISAKMP preliminary configurations, you're ready to define your ISAKMP policies. ISAKMP policies define how the management connection is to be protected and built. On Cisco routers, you would use the crypto isakmp policy command and define the policies in a subcommand mode, where each policy is given a unique number. The number denotes the priority of the policy, with lower numbers having higher priorities. When peers exchange policies, they process them based on the order in which they're sent (for example, lower-numbered ones are sent first).

Configuring Phase 1 policies on a PIX/ASA is similar to doing them on a router, except that all of the policy configuration components of a policy are done from global configuration mode:

appliance(config)# isakmp policy priority encryption {aes | aes-192 |
 aes-256 | des | 3des }
appliance(config)# isakmp policy priority hash {md5 | sha}
appliance(config)# isakmp policy priority authentication
 {pre-share| rsa-sig| dsa-sig}
appliance(config)# isakmp policy priority group {1 | 2 | 5 | 7}
appliance(config)# isakmp policy priority lifetime seconds

If you don't configure any policies, there is a default policy that the PIX, in FOS 6.3, will use: DES, SHA, RSA-SIG, DH group 1, and a lifetime of 86,400 seconds; however, once you configure a policy, the default never is used. For 7.0 there is no default ISAKMP policy.

For a specific policy, if you want to use a default value for a parameter, it is not necessary to configure it. For example, to use SHA-1 for a hash function, you don't need to configure this manually for a policy; this is the default value for every policy.

To perform AES encryption, you need FOS 6.3 or later; and to perform it in hardware, you need the VAC+ card. And, unlike Cisco routers, RSA encrypted nonces are not supported for device authentication; however, in FOS 7.0, DSA certificates are now supported. Plus, to use DH group 5 keys, you need FOS 6.3, and for group 7 keys (PDA devices) you need FOS 7.0. For the management connection lifetime, you can specify a value from 1202,147,483,647 seconds.

Note

You can create up to 20 ISAKMP policies on your PIX/ASA; different policies are required if you have different peers with different capabilities, and you want to take advantage of the strongest security measures whenever the remote peer supports them.

To view your configured ISAKMP policies in 6.3, use the show isakmp policy command. The output of this command is very similar to the IOS router's show crypto isakmp policy command, discussed in Chapter 16, "Router ISAKMP/IKE Phase 1 Connectivity." In 7.0, use the show running-config isakmp command.

Configuring Device Authentication

The PIX/ASA devices support two types of device authentication:

• Pre-shared keys: symmetric
• Certificates: RSA and DSA (DSA is new in FOS 7.0)

The next section will discuss identity types used for device authentication, and the following two sections will discuss the configuration of the authentication methods in the preceding list.

Device Identity Type

During the ISAKMP/IKE negotiations, the IPsec peers identify themselves to each other. To configure which identity type should be used, use the following command:

appliance(config)# isakmp identity {address | hostname |
 key-id ID_string | auto}

The address parameter specifies that the IP address of the PIX/ASA should be used for the identity; the hostname parameter specifies that the FQDN (hostname plus domain name) should be used; and the key-id parameter specifies that the configured ID value should be used. The auto parameter is new in 7.0. It specifies that the IP address should be used if pre-shared keys are used for device authentication; otherwise, the DN (distinguished name) fields in the certificate should be used. In 6.3, the identity type defaults to address, whereas in 7.0, it defaults to auto.

Note

The identity type must match on the two peers for authentication to proceed. And because the isakmp identity command is a global configuration command, all devices connected to your PIX/ASA also must use the same identity type.

 

Pre-Shared Key Authentication

The most common method of setting up device authentication on a PIX/ASA, at least with a small number of IPsec devices, is to use pre-shared keys.

For 6.3 L2L sessions, configuring pre-shared keys is done with the following command:

appliance(config)# isakmp key keystring address peer_IP_address
 [netmask subnet_mask] [no-xauth]
 [no-config-mode]

The pre-shared key can be an alphanumeric key up to 128 characters in length. You can wildcard the peer's address with a subnet mask, allowing multiple peers to share the same key, but Cisco doesn't recommend this practice unless the peers are acquiring their addressing information dynamically. The no-xauth and no-config-mode parameters were added in FOS 6.3. The no-xauth parameter specifies that user authentication should not be performed when this key is used (L2L connections) and the no-config-mode parameter specifies that IKE Mode config should not be performed (non-Cisco remote access clients).

For 7.0 L2L sessions, each L2L peer is associated with a tunnel group and the pre-shared key is configured in a subcommand mode:

appliance(config)# tunnel-group peer_IP_address type ipsec-l2l
appliance(config)# tunnel-group peer_IP_adress ipsec-attributes
appliance(config-ipsec)# pre-shared-key key_value

I'll save a more in-depth discussion of tunnel groups for the next chapter, "PIX and ASA Remote Access Connections," where it is more appropriate.

Certificate Authentication (CA)

Your second choice for device authentication is certificates. Cisco supports the following CA products on their PIX/ASA devices:

• Verisign
• Entrust
• Baltimore Technologies
• Microsoft Windows 2000/2003 Certificate Services (only a central design)
• Cisco IOS CS (7.0)
• Netscape (7.0)
• RSA (7.0)

The configuration of the PIX/ASA to obtain and use certificates is not very similar in 6.3 versus 7.0. In 7.0, the configuration is by and large the same that is performed on a Cisco IOS router. In both cases, though, you'll need to perform the following steps:

Step 1.	Define a name and a domain name.
Step 2.	Generate a public/private key pair.
Step 3.	Specify a trustpoint.
Step 4.	Obtain the root certificate.
Step 5.	Create the PIX/ASA's PKCS #10 information and obtain an identity certificate.
Step 6.	Verify and save your certificates and configuration information.

The following sections will discuss how to obtain, verify, and save certificate information if you are using a PIX running FOS 6.3 or earlier or a PIX/ASA running FOS 7.0 or later.

CA Configuration for 6.3

FOS 6.3 and earlier only supports SCEP to obtain certificates. The following commands outline what you need to do to obtain certificates for your 6.3 and earlier PIX:

pix(config)# hostname name
pix(config)# domain-name domain_name
pix(config)# ca generate rsa key {512 | 768 | 1024 | 2048}
pix(config)# show ca mypubkey rsa
pix(config)# ca identity CA_name [CA_ipaddress | hostname
 [:ca_script_location]
 [ldap_ip address | hostname]]
pix(config)# show ca identity
pix(config)# ca configure CA_name {ca |ra}
 retry_period retry_count [crloptional]
pix(config)# show ca configure
pix(config)# ca authenticate CA_name [fingerprint]
pix(config)# ca subject-name CA_name X.500_string
pix(config)# ca enroll CA_name challenge_password [serial]
 [ipaddress]
pix(config)# show ca certificate
pix(config)# ca crl request
pix(config)# show ca crl
pix(config)# ca save all
pix(config)# write memory

The hostname and domain-name commands are necessary to generate an RSA public/ private key pair. The ca generate rsa key command generates the public/private keys that will be used to sign and authenticate the PKCS #10 information sent to the CA via SCEP. The show ca mypubkey rsa command displays the PIX's public keys that have been configured.

The ca identity command specifies how the PIX should interact with the CA; you need to specify at least a name for the CA (typically a FQDN). If the name is not the same as the FQDN of the CA, you either need to specify one that is, or the IP address of the CA. In many instances, the CA product will require you to use a specific name for the CA. Also, you typically need to specify the script location that contains the SCEP software on the CA. The default location is "/cgi-bin/pkiclient.exe," which will not work with most CA products. For example, a Microsoft CA would require that you specify "/certsrv/mscep/mscep.dll."

The show ca identity command displays the configuration of the ca identity command. You can specify an LDAP IP address or hostname if the CA is publishing its CRL to an LDAP server. The ca configure command, which is optional, allows you to specify parameters that affect the interaction with the CA or RA. The retry period specifies the amount of seconds that need to expire before recontacting a CA to obtain certificate information; the retry count specifies the maximum number of times to retry obtaining certificate information (this defaults to 0, meaning an infinite number of times); and crloptional indicates that using a CRL to validate a certificate is optional. The show ca configure command displays the configuration of the ca configure command.

The ca authentication command downloads the root certificate from the CA. If you don't know the fingerprint (signature) of the CA, you'll be prompted to verify this before accepting the root certificate; otherwise, if you've already obtained this from the CA, you can configure this command and have the PIX verify the root's signature automatically.

The ca subject-name command, which is optional, allows you to specify the X.500 information that should appear on the PIX's identity certificate, such as the OU (department), O (company), ST (state), C (country), and EA (e-mail address). Here's an example of the format of an X.500 string: "OU=mydept, O=dealgroup, ST=FL, C=USA, EA=[e-mail]," without the quotes. This command is new in FOS 6.3.

The ca enroll command obtains an identity certificate for the PIX via SCEP. The challenge password you enter is required. You should remember this because the CA administrator will require it if you need to revoke your certificate; also, this password can be used to automate the identity certificate enrollment process. You can optionally put the PIX's serial number or IP address on the identity certificate.

Once you have obtained the root and identity certificates, you can view them with the show ca certificate command. By default, the PIX will download the CRL periodically; however, if you suspect that your PIX doesn't have the most recent CRL, you can download it with the ca crl request command. You can view the CRL with the show ca crl command.

Upon completion, you need to save your configuration and certificate information. The ca save all command saves the public/private keys and certificate information to Flash memory. The write memory command saves the configuration commands necessary to interoperate with the CA, like ca identity and ca configure.

Example 21-1 illustrates how to prepare your PIX for certificates using FOS 6.3.

Example 21-1. Using FOS 6.3 to Obtain Certificates

pixfirewall(config)# hostname pix63
pix63(config)# domain-name thedealgroup.com
pix63(config)# ca generate rsa key 512
Keypair generation process begin.
Success.
pix63(config)# ca identity caserver
 192.1.1.77:/certsrv/mscep/mscep.dll
pix63(config)# ca authenticate caserver
Certificate has the following attributes:
Fingerprint: ce9956aa c02d15df a2309a9c e059bd47
pix63(config)# ca subject-name caserver OU=mydept,
 O=dealgroup, ST=FL, C=USA
pix63(config)# ca enroll caserver itsasecret
% Start certificate enrollment ..
% The subject name in the certificate will be: pix63.thedealgroup.com
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
 Fingerprint: 33c1af83 7c8a2665 2c74e153 8cbd1a96
The certificate has been granted by CA!
pix63(config)# ca save all
pix63(config)# write memory

If you no longer want to use certificates, or need to change the modulus of your public/ private keys and create new certificates, first you'll need to delete the old certificate and then the associated RSA public/private keys. To remove certificates and keys, use the following commands in the specified order:

pix(config)# clear ca identity CA_name
pix(config)# ca zeroize rsa

Note

Because certificates have a beginning and ending validation date, it is important that your PIX/ASA device has the correct time on it. This can be set manually with the clock set configuration command, but it is preferred to set it using NTP. The configuration of NTP on the PIX/ASA is beyond the scope of this book.

 

CA Configuration for 7.0

FOS 7.0 for the PIX and ASA supports both manual and SCEP enrollment. The configuration process is very similar to that of an IOS router, and doesn't look anything like what I described in the previous section for a PIX running FOS 6.3 or earlier. Because it is so similar to a Cisco router, I'll illustrate only two examples of the enrollment process: SCEP and manual (with cut-and-paste). You can refer to Chapter 16, "Router ISAKMP/IKE Phase 1 Connectivity," for a more detailed explanation of the commands.

Note

The commands used to configure a trustpoint and obtain certificates in FOS 6.3 also work with 7.0; but Cisco is moving toward a more IOS-style command convention in 7.0 and eventually will phase out the 6.3 ca commands.

Example 21-2 illustrates how to obtain the root and identity certificates via SCEP on a PIX/ASA running FOS 7.0. As you can see from the example, this is almost the same as doing it on a router. When generating a public/private key pair, you can specify either rsa or dsa, depending on your CA and its use of keys. Also, unlike on a router, if you don't specify the modulus in the command, it defaults to 512 (an IOS router will prompt you for the modulus). In this example, I created the key pair with a label, which I'll reference in the trustpoint configuration. The trustpoint configuration is very similar to a router's, using the crypto ca trustpoint command. Obtaining the root and identity certificates is mostly the same as a router with the crypto ca authenticate and crypto ca enroll commands. To view your certificates, use the show crypto ca certificate command. And as with a router, to save the certificate, keys, and configuration information, use the write memory or the copy running-config startup-config command; the ca save all command is no longer supported in FOS 7.0.

Example 21-2. Using 7.0 on a PIX/ASA to Obtain Certificates via SCEP

appliance(config)# hostname pix70
pix70(config)# domain-name thedealgroup.com
pix70(config)# crypto key generate rsa label certkeys modulus 512
INFO: The name for the keys will be: certkeys
Keypair generation process begin. Please wait...
pix70(config)# show crypto key mypubkey rsa
output omittedimages/U2192.jpg border=0>
pix70(config)# crypto ca trustpoint caserver
pix70(config-ca-trustpoint)# enrollment url
 http://192.1.1.77/certsrv/mscep/mscep.dll
pix70(config-ca-trustpoint)# crl optional
pix70(config-ca-trustpoint)# enrollment retry period 1
pix70(config-ca-trustpoint)# enrollment retry count 10
pix70(config-ca-trustpoint)# subject-name CN=pix70.thedealgroup.com
pix70(config-ca-trustpoint)# keypair certkeys
pix70(config-ca-trustpoint)# exit
pix70(config)# crypto ca authenticate caserver
INFO: Certificate has the following attributes:
Fingerprint: ce9956aa c02d15df a2309a9c e059bd47
Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
pix70(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: itsasecret
Re-enter password: itsasecret
% The subject name in the certificate will be:
 CN=pix70.thedealgroup.com
% The fully-qualified domain name in the certificate will be:
 pix70.thedealgroup.com
% Include the device serial number in the subject name? [yes/no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
The certificate has been granted by CA!
pix70(config)# show crypto ca certificate
output omittedimages/U2192.jpg border=0>
pix70(config)# write memory

Note

You don't have to use a label for the RSA key pair, just like with IOS routers; however, I prefer to do this so that I can have different key pairs for different certificates, if needed. If you generate keys without a label, you don't need the keypair command in the trustpoint configuration. Also, you can use the crypto key zeroize {rsa | dsa} command to remove a specific RSA/DSA key label or all RSA/DSA keys. To remove certificates and CA interoperability, use the no crypto ca trustpoint command.

Here is an explanation of the trustpoint configuration commands:

• enrollment {terminal | url URL} Specifies the enrollment mode (manual or SCEP).
• crl {required | optional | nocheck} Specifies whether or not CRLs are used.
• fqdn FQDN_of_appliance Specifies the fully qualified domain name to use for the enrollment certificate instead of the values from the hostname and domain-name commands.
• email email_address specifies the e-mail address to use for the enrollment certificate.
• subject-name X.500_values specifies the X.500 values, such as CN, OU, O, and others, to use for the enrollment certificate.
• serial-number Specifies that the serial number of the appliance should be used during the enrollment process.
• ip-address IP_address Specifies the IP address to use during the enrollment process.
• password passphrase Specifies the challenge password to use during SCEP registration or, once a certificate is obtained, to revoke it.
• keypair key_label_name Specifies the RSA/DSA key pair to use during the certificate enrollment process.
• id-cert-issuer Specifies whether the appliance will accept peer certificates issued by the CA associated with the configured trustpoint (by default, yes).
• accept-subordinates Specifies whether the appliance will accept certificates from subordinate CAs during ISAKMP/IKE Phase 1, when the subordinate CA certificates are not installed on the appliance (by default, yes).
• support-user-cert-validation Specifies whether the appliance will validate remote peer certificates with the currently configured CA (by default, yes).

Example 21-3 illustrates how to use the manual approach: generating the PKCS #10 information on your PIX/ASA and then importing the certificates the CA sends you. Up until the crypto ca trustpoint command, the configuration is the same as in Example 21-2. In the trustpoint configuration, the only main difference is the enrollment command, which specifies that the terminal (terminal parameter) will be used instead of SCEP (url parameter). At this point, you don't have to import the root certificate first, but can go ahead and start the enrollment process by generating your PIX/ASA's PKCS #10 information (crypto ca enroll command). In Example 21-3, however, I already had the root certificate, so I went and imported it here. Using the crypto ca authenticate command allows you to cut and paste the root certificate into your PIX/ASA; after cutting and pasting the root certificate into the terminal session to your PIX/ASA, on a blank line type in the quit command and then press the key to import the root certificate. The crypto ca enroll command creates your PKCS #10 information, which you need to send to the CA. The CA administrator will use this to create the PIX/ASA's X.509 identity certificate and send this back to you. The crypto ca import command allows you to import the identity certificate from the terminal (using cut-and-paste). The show crypto ca certificate command displays the certificates on the PIX/ASA. Last, I saved the PIX/ASA's configuration, keying, and certificate information.

Example 21-3. Using 7.0 on a PIX/ASA to Obtain Certificates via Cut-and-Paste

pixfirewall(config)# hostname pix70
pix70(config)# domain-name thedealgroup.com
pix70(config)# crypto key generate rsa label certkeys modulus 512
INFO: The name for the keys will be: certkeys
Keypair generation process begin. Please wait...
pix70(config)# crypto ca trustpoint caserver
pix70(config-ca-trustpoint)# enrollment terminal
pix70(config-ca-trustpoint)# crl optional
pix70(config-ca-trustpoint)# subject-name CN=pix70.thedealgroup.com
pix70(config-ca-trustpoint)# keypair certkeys
pix70(config-ca-trustpoint)# exit
pix70(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
images/U2192.jpg border=0>
BX3p1Wxz+tSEQwrChIzbHcFAUP1Gq0dpBQ==
-----END CERTIFICATE-----
quit
INFO: Certificate has the following attributes:
Fingerprint: ce9956aa c02d15df a2309a9c e059bd47
Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported
pix70(config)# crypto ca enroll caserver
% Start certificate enrollment ..
% The subject name in the certificate will be: CN=pix70.thedealgroup.com
% The fully-qualified domain name in the certificate will be:
 pix70.thedealgroup.com
% Include the device serial number in the subject name? [yes/no]: no
Display Certificate Request to terminal? [yes/no]: yes
Certificate Request follows:
MIIBQzCB7gIBADBIMR8wHQYDVQQDExZwaXg3MC50aGVkZWFsZ3JvdXAuY29tMSUw
IwYJKoZIhvcNAQkCFhZwaXg3MC50aGVkZWFsZ3JvdXAuY29tMFwwDQYJKoZIhvcN
AQEBBQADSwAwSAJBALKJho6w+fJtIG8Vok6lGaoGqwWPvsg0/p0TALlVzCPwkYBy
2vVN9m8T5XI4PQTvoAUv6cUtvvkGi/dxyspVm60CAwEAAaBBMD8GCSqGSIb3DQEJ
DjEyMDAwCwYDVR0PBAQDAgWgMCEGA1UdEQQaMBiCFnBpeDcwLnRoZWRlYWxncm91
cC5jb20wDQYJKoZIhvcNAQEEBQADQQCvTroxRLG3C2NU3gv/deUggTDnSj2IFz4q
NhlWinSioX1D05q66YXjueKz+iNSSeNoKtvU9vUo0eNY4xovjtS+
---End - This line not part of the certificate request---
Redisplay enrollment request? [yes/no]: no
pix70(config)# crypto ca import caserver certificate
% The fully-qualified domain name in the certificate will be:
 pix70.thedealgroup.com
Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself
-----BEGIN CERTIFICATE-----
MIIDRTCCAq6gAwIBAgIKYQoE8AABAAAAIzANBgkqhkiG9w0BAQUFADAgMQswCQYD
images/U2192.jpg border=0>
U9wt0p0NCoZhb6iAPTW37APBnUiihTiUTw==
-----END CERTIFICATE-----
quit
INFO: Certificate successfully imported
pix70(config)# show crypto ca certificate
output omittedimages/U2192.jpg border=0>
pix70(config)# copy running-config startup-config

Note

You can back up your identity certificate and keys with the crypto ca export command, which backs up the information in a PKCS #12 format. The information is password-protected and displayed on the terminal. You can then cut and paste this information into a file in a safe place. This can then be re-imported on the PIX/ASA later if you need to recover your PIX/ASA's certificate information.

 

Certificate Validation

In FOS 6.3 and later, you can specify which components have to be on a peer's certificate before the PIX/ASA will validate it. This feature adds an additional layer of security for preventing a man-in-the-middle attack. With certificate verification, you can specify the distinguished name (DN) value the certificate must contain (the various fields and their values on the peer's identity certificate).

The fields and values that you require are defined with the following command in FOS 6.3:

appliance(config)# ca verifycertdn X.500_string

In FOS 7.0, this command is preceded by "crypto": crypto ca verifycertdn.

If you wanted to accept only certificates that had a CN that contained "corp," an OU that is "engineering," an O that is "dealgroup," an ST that is "FL," and a C that is "US," you would use this command in 7.0:

appliance(config)# crypto ca verifycertdn cn*corp, ou=engineering,
 o=dealgroup, st=FL, c=US

The "*" between the field name and a parameter states that the field should contain the following value. For "*corp," this string could be included in words such as "incorporate," "engcorp," and "corporate," where all three values contain "corp." Normally this command is used with a public CA, where other companies also are using the same CA, but you want to restrict the PIX/ASA to accepting certificates only from devices within your organization or a trusted third-party company.

Note

Please note that you can enter the [crypto]ca verifycertdn command only once, which must encompass all certificates that your PIX/ASA will accept. Also, in 7.0, when you execute the ca verifycertdn command, you get a warning to use the crypto ca verifycertdn command; however, I found that in the initial release of 7.0, this command doesn't exist! On top of that, no matter what you enter for the ca verifycertdn command, in 7.0 it looks like it takes the command, gives the warning, but when you execute the show running-config command, it doesn't appear in the output! Based on this, apparently this feature isn't quite working in the initial release of FOS 7.0, which contradicts Cisco documentation.

 

7.0 and CRL Configuration Options

In FOS 7.0, Cisco added enhancements to the use of CRLs, similar to what the concentrators could do for quite some time. By default, a PIX/ASA will locate the CRL by using the URL on the CA's (root) certificate. Of course, this can present a problem if you're concerned about redundancy where you have a CA and multiple RAs, and the CA fails; no device will be able to obtain the CRL. Likewise, using the CA to download a CRL puts an additional processing burden on the CA. You can place the CRL in other locations, most commonly in an LDAP directory structure; but by default, the PIX/ASA doesn't know about the additional location. In 7.0, you have the flexibility to define when a CRL is used and where the CRL should be obtained. Here is the basic configuration to perform this task:

appliance(config)# crypto ca trustpoint CA_name
appliance(config-ca-trustpoint)# crl configure
appliance(config-ca-crl)# default
appliance(config-ca-crl)# policy {cdp | static | both}
appliance(config-ca-crl)# url {15} URL
appliance(config-ca-crl)# protocol {http | ldap | scep}
appliance(config-ca-crl)# ldap-defaults server_name_or_IP_address
 [port_#]
appliance(config-ca-crl)# ldap-dn admin_X.500_DN password
appliance(config-ca-crl)# cache-time minutes
appliance(config-ca-crl)# [no] enforcenextupdate
appliance(config-ca-crl)# exit
appliance(config-ca-trustpoint)# exit
appliance(config)# crypto ca crl request CA_name
appliance(config)# show crypto ca crls

The crypto ca trustpoint command takes you into the trustpoint subcommand mode. The crl configure command then takes you into the CRL subcommand mode. The default command resets the CRL configuration on the appliance back to the defaults. The policy command specifies where the PIX/ASA should obtain its CRL:

• cdp From the CRL distribution point (CDP) on the CA's certificate.
• static From URLs you define statically.
• both From the CDP, if it's reachable, otherwise the static definitions.

For static URL definitions, use the url command to define CRL locations. You can specify up to 5 CRL locations using a URL syntax, where each location must have a number associated with it (15). The number is used by the PIX/ASA to prioritize the entries, with 1 being the highest.

In the preceding code, the protocol command specifies the protocol to use to retrieve the CRL. For LDAP interactions, the ldap-defaults command specifies the name or IP address of the LDAP server and optionally the port number to use; the ldap-dn command specifies the X.500 DN settings and password to use, if the LDAP server requires authentication. The DN information is in this type of format: "CN=value,OU=value,O=value."

The cache-time command specifies, in minutes, how long a CRL is to be cached locally before the PIX/ASA downloads a new one. The default is 60 minutes, but the value can range from 11,440 minutes. However, if the "NextUpdate" field in the CRL is not specified, the PIX/ASA never will cache the CRL, but always will obtain it when needed. On the PIX/ASA, you can require this field in the CRL with the enforcenextupdate command, which is the default. Using the no parameter with this command disables this requirement.