IKE Phase 1 Peer Authentication

In your IKE Phase 1 policy configuration, one of the policies that you can configure is the authentication method with the authentication command. IPSec supports three authentication methods:

• Preshared keys

• RSA encrypted nonces

• Digital certificates (RSA signatures)

The configuration of all three of these methods is covered later in this section after the coverage of the peer identity type.

Identity Type

Before I discuss how to configure the three different authentication methods, I need to discuss a peer's identity type. You use an identity type to identify a peer on your router. Three identity types exist: the IP address of the peer, the peer's name, and the peer's distinguished name (DN). You first must determine which of these three types you will use in identifying your IPSec peers. Here is the command to specify the identity type:

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

As you can notice from this command, it is a global configuration mode command, so it applies to all IPSec configurations. If you do not configure this command, the default is to specify a peer by its IP address. This command affects how you configure the identity of the peer in other IPSec commands.

If you specify the hostname parameter, you can specify a FQDN for the remote peer or statically configure the name resolution with the ip host command. I recommend using dynamic DNS resolution only if the remote peer is acquiring its IP address dynamically, which then is updated automatically in a DNS server's resolution table. I prefer not to use DNS because it is susceptible to session hijacking. If the peer has more than one IP address, I recommend using the hostname parameter and then statically configuring name resolution with the ip host command, with which you can specify more than one IP address for a device. This provides a method of redundancy if the first IP address of the peer is not reachable.

The dn parameter specifies the use of the distinguished name of the device from the router certificate. Either dn or hostname is necessary if you will be deploying DN-based crypto maps.

Authentication with Preshared Keys

When creating your IKE Phase 1 policies, if you configured authentication to be pre-share in the authentication command, authentication is accomplished by assigning the same key to both peers. Depending on the identity type defined on your router, you use one of these two commands:

Router(config)#  crypto isakmp key the_key address IP_address_of_peer

or:

Router(config)#  crypto isakmp key the_key hostname hostname_of_peer

The key can be an alphanumeric value up to 128 characters in length. If you specify an IP address of 0.0.0.0 for the address parameter, this is treated as a wildcard; all remote peers must use this key when authenticating. I highly recommend that you not use this trick because, if one peer becomes compromised, all your peers are compromised. Instead, I recommend that you configure a different authentication key for each remote peer.

To view your preshared keys, use the show crypto isakmp key command.

Authentication with RSA Encrypted Nonces

As you saw in the last section, configuring preshared key authentication is a simple process. However, because it uses a single symmetric key value for authentication, it is less secure than RSA encrypted nonces, which uses asymmetric keys (public and private).

If you specified your IKE Phase 1 authentication method with authentication rsa-encr in your ISAKMP policy configuration, you need to perform four steps to set up your RSA public/private key authentication:

Step 1. Create your router's personal RSA public/private keys.

Step 2. Share your router's public key with your peer.

Step 3. Get your peer's public key and configure it on your router.

Step 4. Verify the key that you configured for your peer.

RSA Manual Key Generation

To create a public/private key combination on your router, you first must give your router a unique FQDN with the hostname and ip domain-name commands. After this, you can generate your public/private keys with the following command:

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

If you use the optional usage-key parameter, two sets of public/private key combinations are created: one for the signature and one for encryption. However, only one set of public/private keys is needed for IPSec authentication purposes, so you can omit this parameter.

Example 19-2 shows a simple example of generating your RSA public/private keys for encrypted nonces.

Example 19-2. Creating RSA Keys for RSA Encrypted Nonces

Router(config)# hostname richard

richard(config)# ip domain-name quizware.com

richard(config)# crypto key generate rsa

The name for the keys will be: richard.quizware.com

Choose the size of the key modulus in the range of 360 to 2048

for your Signature Keys. Choosing a key modulus greater than 512

may take a few minutes.

How many bits in the modulus[512]?

Generating RSA keys.... [OK].

richard(config)#

Example 19-2 shows how to configure your router to generate a single public/private RSA key combination. Notice that you are prompted for a modulus value, which affects the strength of the keys: The bigger the modulus is, the stronger the security of the keys will be. However, the longer the modulus is, the longer it takes to create a key pair. For example, on a 2500 router, using a 512-bit modulus takes about 20 seconds to generate the key-pair; however, if you changed the modulus to 2048 bits, it would take about an hour for the 2500 to generate the public/private key pair.

After you have generated your public/private key-pair combination, you can view your router's public key with the show crypto key mypubkey rsa command. If you used the usage-keys parameter when creating your keys, you will see two public keys. You need to give these key to your remote IPSec peer out of band. In other words, do not e-mail this to the peer because it will be traversing a public network and is susceptible to eavesdropping. Example 19-3 shows an example of this command.

Example 19-3. Viewing Your Router's RSA Public Keys

richard# show crytpo key mypubkey rsa

% Key pair was generated at: 07:06:28 UTC Oct 21 2001

Key name: richard.quizware.com

 Usage: Signature Key

 Key Data:

  105C311D 06039B86 1898F70D 01010105 00789B00 3048CBA1 0123E23B

  55D6AB22 11AEF1B0 ADCE18A6 432101C5 129D99E4 64987820 847EABC9

  D3214E4C 55179DD2 991AA8A9 FA603DD2 1234A6F8 FED76E28 D5DEF221

  B583D7A4 71020301 0201

Peer Key Configuration

After your peer has generated his public/private keys, you need to obtain his public key out of band and then configure this on your router. To configure the peer's public key on your router, use the following configuration:

Router(config)#  crypto key pubkey-chain rsa

Router(config-pubkey-chain)# {addressed-key | named-key}

  {IP_address | host_name} [encryption | signature]

Router(config-pubkey-key)# key-string the_key

Router(config-pubkey-key)# quit

First, you need to enter the public key configuration mode by entering the crypto key pubkey-chain rsa command; notice that the prompt changed to (config-pubkey-chain). Here, based on the identity type configured on the router, you use either the addressed-key or named-key commands. With the addressed-key command, you need to configure the IP address of the remote peer; with the named-key command, enter the peer device's name (typically a FQDN). Following this, you optionally can specify which type of key it is. If you generated two sets of keys with the usage-keys parameter with the crypto key generate rsa command, you need to configure both. If you do not specify the type of key, it defaults to signature. This takes you into a sub-subconfiguration mode, where you need to enter the peer's public key with the key-string command. With this command, the peer's key can be entered on multiple lines. When you are finished entering the peer's key, on a blank line, enter the quit command. Example 19-4 shows how to configure your peer's RSA public key.

Example 19-4. Entering a Peer's RSA Public Key

Router(config)#  crypto key pubkey-chain rsa

Router(config-pubkey-chain)# addressed-key 200.1.1.1 signature

Router(config-pubkey-key)# key-string

Router(config-pubkey-key)# 105C311D 06039B86 1898F70D 01010105

Router(config-pubkey-key)# 00789B00 3048CBA1 0123E23B 55D6AB22

Router(config-pubkey-key)# 11AEF1B0 ADCE18A6 432101C5 129D99E4

Router(config-pubkey-key)# 64987820 847EABC9 D3214E4C 55179DD2

Router(config-pubkey-key)# 991AA8A9 FA603DD2 1234A6F8 FED76E28

Router(config-pubkey-key)# D5DEF221 B583D7A4 71020301 0201

Router(config-pubkey-key)# quit

As you can see from Example 19-4, I entered the peer's public key on multiple command lines.

To view any peer's public key that you have configured on your router, use the following command:

Router#  show crypto key pubkey-chain rsa

  [name host_name | address IP_address]

Authentication with Certificates

Of the three types of IKE Phase 1 authentication, certificates provides the most security and scalability; however, they are also the most difficult to implement and troubleshoot. This section provides a brief overview of certificates and certificate authorities (CAs), as well as how to configure IPSec certificate authentication on your router.

Certificates and CAs

A certificate contains information to authenticate a device. Unlike preshared keys and RSA encrypted nonces, in which only two devices?the peers?are involved in the authentication process, a third device called the CA plays a role with certificates and IPSec. A CA is a trusted third-party device used to validate the identity of a peer. It typically is used with IPSec, but it also is used with e-commerce applications that use Secure Socket Layer (SSL). The CA's role in the authentication process is to act as the keeper of digital certificates.

The ITU-T X.509v3 standard defines the format and contents of a digital certificate. Digital certificates contain information about a device that can be used to authenticate it and contain three basic pieces of information:

• The CA's public key? The CA uses its private key to sign the digital certificate (including its contents). Another device then can use the public key of the CA to verify the authenticity and integrity of the certificate because only the public key of the CA can be used to validate the CA's signature (also on the certificate). Because this process uses the CA's public key to perform verification, you should obtain the CA's key out of band; if you obtain it in-band, verify with the administrator of the CA that the public key was not altered during transit across a public network.

• The identity of the IPSec device? This is some form of identification information that is used to uniquely identify the source of the public key. This can be a name, an address, a company name, a serial number, an IP address, or some other type of information. In most products, each certificate is assigned a unique serial number, which then is used to differentiate among different certificates.

• The public key of the IPSec device? This key, along with its private key (created by using the RSA algorithm), is used to create and validate the authentication information. The public key is used by any other device to validate the identity of the IPSec device associated with this certificate. Each IPSec device uses its personal private key to create a digital signature, which is placed on the device's personal certificate; only the public key of this device can validate the signature.

To provide redundancy when using certificates and CAs, a CA can implement one or more registration authorities (RAs). RAs act as proxies for CAs. RAs cannot generate certificates for devices, but they can pass out existing certificates for validation purposes, as well as Certificate Revocation Lists (CRLs), discussed later.

Cisco IOS routers support the following CA products, among others:

• Baltimore Technologies Unicert

• Entrust public-key infrastructure (PKI)

• Microsoft Windows 2000 and 2003 Certificate Services

• Verisign OnSite

I have used both Microsoft products with great success.

Simple Certificate Enrollment Protocol

The Simple Certificate Enrollment Protocol (SCEP) is one of two methods that you can use to obtain certificate information on your router. SCEP occurs in-band and provides a quick way of obtaining a certificate. The alternative method is manual: You generate certificate information and send this out of band to the administrator of the CA. The administrator generates a certificate for you and sends this back to you out of band. Then you manually put this into your IPSec device. Because the manual method is very work intensive and does not scale well, most network administrators prefer to use SCEP.

SCEP defines how an IPSec device and a CA interact when obtaining their initial certificate information. SCEP originally was developed by Cisco, Entrust, Microsoft, Netscape, Sun, and Verisign; it is currently in a draft state with Internet Engineering Task Force (IETF). It supports both the PKCS #7 and #10 standards (#7 defines how to encrypt, sign, and format certificate enrollment messages, and #10 defines how to handle multiple certificates in one request).

Certificate Revocation List

Basically, a CRL contains a list of revoked certificates, including their serial numbers. Here are some common reasons why a certificate might be revoked:

• A change was made in your security policy.

• Your device's private key was compromised.

• Your device is being taken permanently out of service.

A CRL is used to speed up the process of reauthenticating devices when their IKE Phase 1 management connection expires and needs to be rebuilt. When your router gets the peer's certificate initially and builds the management connection, your router caches the peer's certificate in memory. A CRL can be used to validate that the peer's certificate that you have cached is still current and valid. Without a CRL, when the management connection is about to expire and your router and peer need to rebuild the connection, the two devices must recontact the CA and request each other's personal certificate again. The problem with this process is that if the CA has a few million certificates, as would be the case in a public CA device, this could take a few seconds for the lookup to occur, adding delay in the rebuilding of the management connection. Instead, the two peers can ask the CA for a CRL; the CA can respond with this instantaneously because it does not require a special lookup. The two devices then can check to see if their peer is listed in the CRL: If it is not, the peer's certificate that they have cached is valid; otherwise, they need to request an updated certificate from the CA for the peer.

Certificate Enrollment and Configuration Process

Now that you have a basic overview of the components involved in using certificates for authentication in IKE Phase 1, you can go through the following steps to obtain certificate information on your router:

Step 1. Check your NVRAM usage. Your router's personal certificate and the CA and RA certificates are stored in NVRAM, and you might not have enough memory to hold them. (Use the crypto ca certificate query command.)

Step 2. Set the correct date and time on your router to interact with the CA. This is important for validating your certificate when the CA sends this to you. (Use the clock timezone and clock set commands or, preferably, Network Time Protocol (NTP).)

Step 3. Configure a unique FQDN on your router. (Use the hostname and ip domain-name commands.)

Step 4. Create your RSA public/private keys. (Use the crypto key generate rsa command.) The CA places your router's public key in the certificate, and the private key is used to sign authentication information during the IKE Phase 1 authentication process.

Step 5. Specify the location of the CA so that your router can reach it to obtain and validate certificates. (Use the crypto ca {identity | trustpoint} and enrollment url commands.)

Step 6. Obtain the CA's root certificate and verify the CA's signature on it. (Use the crypto ca authenticate command.)

Step 7. Obtain your router's own identity certificate from the CA. (Use the crypto ca enroll command.)

Step 8. Verify your certificate information. (Use the show crypto ca certificates command.)

Step 1: Check NVRAM Usage

The following certificate information is stored in NVRAM:

• The CA's certificate

• Your router's own certificate

• If the CA supports an RA, the RA's two certificates

• One CRL if there is no RA, or multiple CRLs if there is at least one RA

If you use the show crypto ca certificates command after obtaining certificate information, you quickly will see that each certificate is not small. Because certificate information is stored in NVRAM, this can be an issue. If your router does not have enough NVRAM to store this information, you need to execute the following command:

Router(config)#  crypto ca certificate query

This command causes the router not to store the certificate information in NVRAM; instead, every time the router boots up, it goes out to the CA and automatically obtains it.

Step 2: Specify Your Router's Name

Configuring your router's name information is straightforward. Use the following commands:

Router(config)#  hostname router's_name

Router(config)#  ip domain-name domain_name

Step 3: Configure the Correct Date and Time

To configure the correct date and time, use the following commands:

Router(config)#  clock timezone time_zone_name UTC_hour_offset

  [minute_offset]

Router# clock set HH:MM:SS day name_of_month year

Of course, you can use NTP. Both these commands and NTP were discussed in Chapter 18, "Logging Events."

Step 4: Generate Your Keys

When you have configured your router's identity and have set the correct date and time, you are ready to create your router's public/private key combination:

littledog(config)#  crypto key generate rsa

Use the show crypto key mypubkey rsa command to view your router's personal public key(s). These commands were discussed previously.

Step 5: Specify Your Certificate Authority

Now that you have created your public/private key combination, you can specify how to access the CA. Here are the commands to do this:

Router(config)#  ip host CA_name IP_address

Router(config)#  crypto ca identity | trustpoint CA_name

Router(config-ca-identity)#  enrollment url URL_and_CGI_bin_location

Router(config-ca-identity)#  enrollment retry-period #_of_minutes

Router(config-ca-identity)#  enrollment retry-count #_of_times

Router(config-ca-identity)#  enrollment mode ra

Router(config-ca-identity)#  crl optional

The first command is not necessary if you are using DNS to resolve the CA's name to an IP address. The crypto ca identity or trustpoint commands are used to take you into a subconfiguration mode where you can configure the access parameters for the CA. In older versions of the Cisco IOS, you need to use the identity parameter, but in 12.2 and later versions, you use trustpoint.

The only required command within this subconfiguration mode is enrollment url, which specifies the URL location of the CA. Example 19-5 shows an example when accessing Verity's CA product.

Example 19-5. Specifying the Access for the Verity CA Product

quizware(config)#  crypto ca identity ca.verity.com

quizware(config-ca-identity)#  enrollment url

  http://ca.verity.com/cgi-bin

Example 19-6 shows an example accessing a Microsoft CA.

Example 19-6. Specifying the Access for the Microsoft CA Product

quizware(config)#  crypto ca identity ca.quizware.com

quizware(config-ca-identity)#  enrollment url

  http://ca.quizware.com/certsrv/mscep/mscep.dll

The administrator of the CA will tell you the correct URL locator to use.

The rest of the commands are optional. For example, you can specify the retry period with the enrollment retry-period command. This specifies how often the router resends its request to the CA when it does not get a response; the default is 1 minute. You also can specify how many times the router resends a request to the CA when the CA is not responding. By default, the router continues to do so until it gets a response. You can set the number of times with the enrollment retry-count command. If your CA supports an RA for redundancy, you need to tell your router this with the enrollment mode ra command. Your router is also configured to request a CRL automatically whenever it has a peer's certificate information in memory and wants to build a new connection when an old one is expiring. You can override this behavior with the crl optional command, which, if the CRL is not available, causes the router to go ahead and set up the IKE Phase 1 management connection without verifying that the certificate has been revoked. The default behavior is for the router to not rebuild the connection unless it can get a CRL from the CA (or the RA).

CRL Problems I have experienced problems with CAs in which no CRL is created on the CA. In this situation, the management connection failed to be built. When examining output from the router's debug commands, it was not obvious that this was the problem. It took me a handful of days tinkering around to pinpoint this problem. When I fixed this problem, the management connection was established successfully. As I have found numerous other times when building IPSec connections, following a laid-out plan and performing things step by step helps simplify the troubleshooting process.

Step 6: Validate the CA's Identity

When you have established the identity of the CA, you need to obtain the CA's personal certificate and validate it. This is accomplished with the following command, assuming that you are using SCEP:

Router(config)#  crypto ca authenticate CA's_name

This command has the router retrieve the CA's certificate and then has you verify the CA's signature on the certificate. This process uses SCEP. Example 19-7 shows how to obtain the CA's certificate and validate it.

Example 19-7. Obtaining the CA's Certificate and Validating It

Router(config)# crypto ca authenticate ca.quizware.com

Certificate has the following attributes:

Fingerprint: 9871 A1E2 FF13 C1D0 0159

Do you accept this certificate? [yes/no] yes

Router#

You must answer yes or no to accept the certificate. Before you accept it, you should call the administrator of the CA and verify the signature, to ensure that it was not tampered with as it was sent from the CA to your router (a man-in-the-middle attack).

Step 7: Retrieve the Router's Personal Certificate

After you have retrieved the CA's certificate, you can go ahead and request that the CA send your router its own certificate. This process uses SCEP. Here is the command to request the router's personal certificate:

Router(config)#  crypto ca enroll CA's_name

You first are prompted for a password. This password is required and is used if you need to revoke the certificate, which reduces the likelihood of anybody calling the CA administrator and revoking a certificate. If you are using a public CA, write down this password and store it in a secure location. Without this password, you cannot revoke the router's certificate when needed.

Optionally, you can include the router's serial number or IP address as part of the certificate information. If you do this, it takes 5 to 45 seconds to get a certificate request, through SCEP, back from the CA (assuming that the CA is set up to grant certificates automatically).

If the result is successful, you should see this message:

%CRYPTO-6-CERTRET: Certificate received from Certificate Authority

If there is a problem, you will see this:

%CRYPTO-6-CERTREJ: Certificate enrollment request was rejected by

  Certificate Authority

This message indicates either that the CA rejected your request or that there is a configuration problem.

After you successfully retrieve your certificate, save your configuration, including the CA and router's certificates to NVRAM, with the copy running-config startup-config command. Note that the crypto ca enroll command and your prompt responses are not stored in NVRAM. Therefore, if you forget to save your configuration to NVRAM before the router reboots, you must go through this process again after the router comes back up.

Example 19-8 displays an example of using this command.

Example 19-8. Obtaining Your Router's Identity Certificate

quizware(config)# crypto ca enroll ca.quizware.com

% 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: mysecretpass

Re-enter password: mysecretpass

% The subject name in the certificate will be: quizware.quizware.com

% Include the router serial number in the subject name? [yes/no]: yes

% The serial number in the certificate will be: 1234567890

% Include an IP address in the subject name [yes/no]? yes

Interface: ethernet0

Request certificate from CA [yes/no]? yes

% Certificate request sent to Certificate Authority

% The certificate request fingerprint will be displayed.

% The 'show crypto ca certificate' command will also show the fingerprint.

quizware(config)#   Fingerprint: 01234567 89ABCDEF 01234567 89ABCDEF

%CRYPTO-6-CERTRET: Certificate received from Certificate Authority

quizware(config)#

As you can see, the router successfully acquired a certificate.

Step 8: Verify Your Router's Certificate Configuration

After you have acquired the personal certificates for the CA and your router, you can view the certificates with the show crypto ca certificates command, displayed in Example 19-9.

Example 19-9. Viewing Certificates on Your Router

quizware# show crypto ca certificates

Certificate

  Subject Name

    Name: quizware.quizware.com

    IP Address: 192.1.1.1

    Serial Number: 123456789

  Status: Pending

  Key Usage: General Purpose

    Fingerprint: 12AE7BCD F98513D2 A34DECB1 557891A2 00000000

CA Certificate

  Status: Available

  Certificate Serial Number: 9815321EA5DCABEF1A23F76B891C92421

  Key Usage: Not Set

<--output omitted-->

Notice that the status in this example is pending. This means that the CA has received the request but has not generated a certificate for you. In this situation, the administrator of the CA probably has automatic certificate approval disabled and must manually approve your certificate request.

Removing Your Router's Certificate

If you need to remove a certificate on your router, first view the specific certificate that you want to remove with the show crypto ca certificates command. Typically, you do this if your certificate has expired and you need to get a new certificate, or if you are taking this router permanently out of service. You need to know the device's FQDN in the certificate, as well as the serial number of the certificate. Next, perform the following:

Router(config)# crypto ca certificate chain device's_FQDN

Router(config-cert-chain)# no certificate device's_serial_#

The crypto ca certificate chain command takes you into a certificate subconfiguration mode. The no certificate command deletes the specific certificate.

If you no longer will be using a CA for authentication and you want to remove this configuration from your router, you first must delete the certificates for the router and the CA. After this, you need to remove the CA's configuration with the following command:

Router(config)# no crypto ca {identity | trustpoint} CA's_name

Removing Your Router's RSA Keys

If you need to remove the RSA keys on your router, perhaps to generate new ones, use the following command:

Router(config)# crypto key zeroize rsa

If the public/private key combination is used with a certificate, you need to delete the certificate first and then delete the keys.

To remove your peers' public keys that you manually have configured, first display the peer's public key information and then delete it. Based on the identity type defined in the crypto isakmp identity command, you use either the no named-key or no addressed-key commands. Here are the actual commands:

Router# show crypto key pubkey-chain rsa

Router(config)# crypto key pubkey-chain rsa

Router(config-pubkey-chain)# no named-key fully_qualified_peer_name

  [encryption | signature]

or:

Router(config-pubkey-chain)# no addressed-key IP_address_of_peer

  [encryption | signature]

Typically, you must perform this process if your IPSec peer has regenerated its RSA encrypted nonces keys. In this situation, you need to delete the peer's old public key and enter the new one. You must choose the appropriate key command based on the identity type configured on your router when removing the peer's public key.

Copyright eTutorials.org 2008-2023. All rights reserved.