Case Studies and Sample Configurations

The following case studies represent a scaled-down version of an enterprise network. In real topologies, much more redundancy would be built into the network topology. However, for clarity and conciseness, the topology has been reduced to the critical network elements themselves. The network core consists of Catalyst 6500s, which branch off distribution switches at the company's east and west campuses. The distribution layer switches in this case are represented by the Catalyst 4507Rs at each campus. A 7200VXR router serves as the headend for the company's branch locations. Frame relay circuits extend the network to each branch, represented with a 3745 router. The topology described above is illustrated in Figure 11-6.

Figure 11-6. Case Study PKI Topology

Critical resources are located at the company's east campus. Transmissions from these resources across the WAN to the branch offices must be kept confidential. Security administrators have selected asymmetric encryption as the method used to authenticate the IKE channels. As such, a PKI-based implementation has been chosen to encrypt data from the company's east campus to resources at the branch locations. This series of case studies will demonstrate various PKI deployments in the company's west campus that are used to deliver these services.

Case Study 1: PKI Integration of Cryptographic Endpoints

In the first case study, we will illustrate the basic enrollment and authentication processes of the cryptographic endpoints within the PKI. In this case, the cryptographic endpoints are represented by the frame-relay head-end (7206VXR) and its spokes (3745s). The CA for this case study is running on Cisco IOS 12.3.8T4 and is configured as displayed in Example 11-1.

Example 11-1. Cisco IOS CA base configuration

crypto pki server IOS_CA1 grant auto ! crypto pki trustpoint IOS_CA1 revocation-check crl rsakeypair IOS_CA1 ! crypto pki certificate chain IOS_CA1 certificate ca 01 308201FD 30820166 A0030201 02020101 300D0609 2A864886 F70D0101 04050030 12311030 0E060355 04031407 494F535F 43413130 1E170D30 34313230 36313234 3532305A 170D3037 31323036 31323435 32305A30 12311030 0E060355 04031407 494F535F 43413130 819F300D 06092A86 4886F70D 01010105 0003818D 00308189 02818100 C3AB99C2 CE7E000D CB59AA96 CD5815EF 60ADAB83 DE6B67B5 356BC735 7F518745 EF92AC71 BBCA8CB5 DFCD8B63 DB05BDC9 194D1665 181283E5 631C9875 F7821CCA 2717900D EF73BD7A 0D86C2B7 73170DB4 41C66C66 BBD25C19 2801D22E 2AC7E22E 710B6BC9 184803BE 9D5D3238 FC704842 E4728A05 943B7AEB AF76F4B1 7E638CBD 02030100 01A36330 61300F06 03551D13 0101FF04 05300301 01FF300E 0603551D 0F0101FF 04040302 0186301D 0603551D 0E041604 14177FC9 2F8DE64D F61B730D 873B67BF 13A7E05B 70301F06 03551D23 04183016 8014177F C92F8DE6 4DF61B73 0D873B67 BF13A7E0 5B70300D 06092A86 4886F70D 01010405 00038181 004940A8 5E4ED5BB 3DF84643 AB77E505 A8A96E9B 1D621471 56ADC25B 7FBA3CEB EB755322 BB3A50A1 8B3B567D 4F4B667D B84D9860 F7519B70 EF2529E7 8B3F1EC7 90880D87 84394162 B31DD74F 0F2E4532 8E4EF645 15766A62 546CD102 BD670F6B 034FDCC6 040F90EF C68DDF1B 8A86354B 48289102 01700B77 CDB416A7 58605FDE CF

Once the CA has been configured, the crypto endpoints must generate RSA keys for creating digital signatures, as shown when the Frame Relay headend 7206VXR enrolls with the PKI. These public RSA keys will be used to encrypt communications through the IKE channel, and the private keys will be used for decrypting communications through the IKE channel. Note that stronger keys are selected for stronger security than the default key modulus (512). Example 11-2 illustrates the process of generating an RSA keypair with Cisco IOS.

Example 11-2. Generating RSA Keys for Use with RSA Signatures

7206VXR-MAIN(config)#crypto key generate rsa The name for the keys will be: 7206VXR-MAIN.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]: 1024 % Generating 1024 bit RSA keys ...[OK] 7206VXR-MAIN(config)#exit 7206VXR-MAIN#sh crypto key mypubkey rsa % Key pair was generated at: 11:08:26 PST Dec 6 2004 Key name: 7206VXR-MAIN.cisco.com Usage: General Purpose Key Key is not exportable. Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00F4F069 29F731C7 3A6A78AC FC28201F 4B278BEB 348C6450 C9B88510 1AC5948B 36C2DB4A 6C85C1E8 C689B5CD 841F60FA 53264AB2 AFBD8E3E 62235BD0 F48208E9 042B43E6 60F01AD0 B7F870C2 224FF2E5 7288E6CA 47BFDF36 E0D882B1 6B8FAA28 775CBE4B 13B83E11 090F731D D5640280 4EBEF7EE C5EF1ED7 B56A5E09 603377E2 DD020301 0001 % Key pair was generated at: 11:08:26 PST Dec 6 2004 Key name: 7206VXR-MAIN.cisco.com.server Usage: Encryption Key Key is exportable. Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00D6CD85 1A603369 F8598785 E0F3003C 81874E3A F10BC0FB 5401D977 CA445C6B C9EA191D C08AEFED 9A511972 7BD4B303 C748A7EC 3A6DB4BD 8B6193A9 6FA80D2F CC32E35D E7E4CE1C 74F4493F 6C9DF20F B26B1FFB A52BAD30 5D88B725 6EFF4CE1 71020301 0001

Once RSA keys have been created, the CA must be specified and authenticated. Example 11-3 shows the specification of a CA trustpoint on the 7206VXR. When authenticating a CA, the CA will provide the administrator with a unique fingerprint. The administrator must manually accept this fingerprint for the CA to be authenticated on the router.

Example 11-3. Authenticating the CA with Cisco IOS

7206VXR-MAIN#conf t Enter configuration commands, one per line.  End with CNTL/Z. 7206VXR-MAIN(config)#crypto ca trustpoint IOS_CA1 7206VXR-MAIN(ca-trustpoint)#enrollment url http://200.2.1.2 7206VXR-MAIN(ca-trustpoint)#exit 7206VXR-MAIN(config)#crypto ca authenticate IOS_CA1 Certificate has the following attributes: Fingerprint: 99282341 BE16A9D0 DE8614E4 A3557E48 % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. 7206VXR-MAIN(config)#

The 7206VXR has now authenticated the CA. Next, the 7206VXR must be enrolled with the CA for other endpoints to verify its validity in the PKI. Example 11-4 shows this enrollment process. The router prompts the administrator for a password that is used for revoking certificates if needed.

Example 11-4. Enrolling a Cryptographic Endpoint in a PKI

7206VXR-MAIN(config)#crypto ca enroll IOS_CA1 % % 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: Re-enter password: % The fully-qualified domain name in the certificate will be: 7206VXR-MAIN.cisco.com % The subject name in the certificate will be: 7206VXR-MAIN.cisco.com % Include the router serial number in the subject name? [yes/no]: no % Include an IP address in the subject name? [no]: 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. CRYPTO_PKI:    Fingerprint: 56FB7367 20C98A75 82B96CE9 46C4D1F6 Dec  6 16:22:56.486: Dec  6 16:23:07.717: %CRYPTO-6-CERTRET: Certificate received from Certificate Authority

As a result of the enrollment process, the 7206VXR receives its own certificate signed by the CA. When 3745-A, B, and C enroll with the PKI through this same process, they will also receive their own CA-signed certificates. The spokes will then be able to exchange their certificates successfully with the 7206VXR to authenticate the IKE channel. Over this channel, an IPSec SA will be built and encrypted communications will be enabled between the spokes and the West Campus LAN.

Case Study 2: PKI with CA and RA

In this scenario, another Cisco IOS-based CA has been addedIOS_CA2. However, IOS_CA2 is acting strictly as a registration authority; it is not actually signing certificates for the crypto endpoints. Instead, IOS_CA2 offloads registration responsibility for IOS_CA1, which retains sole responsibility for enrolling and signing router certificates. In order to ensure that the CA is only granting certificates to those cryptographic endpoints which have already been processed by the registration authority, the configuration of IOS_CA1 is changed, as shown in Example 11-5, to automatically grant requests only if a trusted registration authority has previously processed them.

Example 11-5. CA Configuration for RA Interoperability

IOS_CA1#configure terminal IOS_CA1(config)# IOS_CA1(cs-server)#crypto pki server IOS_CA1 IOS_CA1(cs-server)#grant ra-auto IOS_CA1(cs-server)#end

The RA configuration looks similar to the configuration of a CA in Cisco IOS. The main difference is that RA mode must be selected under the CA server configuration. Additionally, the RA must be configured with a CA as its trustpoint, which is IOS_CA1 in this case. As such, IOS_CA2 will authenticate IOS_CA1 and enroll with IOS_CA1 in the same manner that a normal cryptographic endpoint would. IOS_CA2 must also be configured with its certificate name, along with other parameters for enrolling with the CA. Configuration of IOS_CA2 is displayed in Example 11-6.

Example 11-6. RA Configuration for CA Interoperability

IOS-CA2#configure terminal IOS-CA2(config)#crypto pki server IOS_RA1 IOS-CA2(cs-server)#grant auto IOS-CA2(cs-server)#mode ra IOS-CA2(cs-server)#no shut % Once you start the server, you can no longer change some of % the configuration. Are you sure you want to do this? [yes/no]: yes Error: There is an enrollment transaction in progress. Please wait or abort the current enrollment before starting a new enrollment transaction. % Enrollment in progress... % You have to re-enable the certificate server after the enrollment succeeds. ! IOS-CA2(cs-server)#exit IOS-CA2(config)#crypto pki trustpoint IOS_RA1 IOS-CA2(ca-trustpoint)#enrollment url http://200.2.1.2:80 IOS-RA2(ca-trustpoint)#serial-number IOS-CA2(ca-trustpoint)#ip-address FastEthernet0/1 IOS-CA2(ca-trustpoint)#subject-name cn=IOS_RA1, ou=ioscs RA, o=cisco, c=us IOS-CA2(ca-trustpoint)#revocation-check crl IOS-CA2(ca-trustpoint)#rsakeypair IOS_RA1 IOS-CA2(ca-trustpoint)#end

Note

In Example 11-6, the enrollment URL points to an HTTP server enabled on the IOS-based CA Server, IOS-CA1.

The IOS CA will store information requests from the RA, which must be manually granted. Example 11-7 shows the process of displaying requests from RA's on IOS_CA1 and manually accepting them.

Example 11-7. Managing RA Information Requests on IOS CAs

IOS-CA1#crypto pki server IOS_CA1 info requests Enrollment Request Database: RA certificate requests: ReqID  State      Fingerprint                      SubjectName -------------------------------------------------------------- 14     pending    230B8A39AC85E0512A5D01EC1796D2C8 serialNumber=7F6AD0E2+ipaddress=200.2.2.2+hostname=IOS-RA1.cisco.com, cn=IOS_RA1,ou=ioscs RA,o=cisco,c=us Router certificates requests: ReqID  State      Fingerprint                      SubjectName IOS-CA1#crypto pki server IOS_CA1 ? grant     Grant enrollment requests info      Display info password  One Time Password for SCEP enrollment reject    Reject enrollment requests request   Retrieve an enrollment request revoke    Revoke certificate IOS-CA1#crypto pki server IOS_CA1 grant 14

Note that in Example 11-6, once the RA, IOS_CA2, has authenticated and enrolled with CA, IOS_CA1, the RA server on IOS_CA2 shuts down. It will remain disabled until it is manually enrolled by the administrator on IOS_CA1, as shown in Example 11-8.

Example 11-8. Re-Enabling the IOS Server on an RA

IOS-CA2#configure terminal IOS-CA2(config)#crypto pki server IOS_RA1 IOS-CA2(cs-server)#no shut % Once you start the server, you can no longer change some of % the configuration. Are you sure you want to do this? [yes/no]: yes % Certificate Server enabled. IOS-CA2(cs-server)#end

Now that the RA has been fully enrolled with the CA, cryptographic endpoints must be configured to subscribe to the PKI with the RA (IOS_CA2). The cryptographic endpoints will subscribe to the PKI using the same procedure outlined in Case Study 1, with the exception of using IOS_CA2 as their trustpoint instead of IOS_CA1. Additionally, the endpoints must be told that they are using an RA instead of a CA for subscribing to the PKI. Otherwise, the interaction between the RA and CA will be transparent to the cryptographic endpoints. Example 11-9 shows the configuration of the IOS CA server (IOS-CA2 in Figure 11-6) to act as an RA.

Example 11-9. Cryptographic Endpoint Enrollment with an RA

IOS-CA2# IOS-CA2(config)#crypto pki trustpoint IOS_RA1 IOS-CA2(ca-trustpoint)#enrollment url http://200.2.1.2:80 !#<--The following command informs the IOS PKI endpoint that it is enrolling with an RA as opposed to a CA--> IOS-CA2(ca-trustpoint)#enrollment mode ra

Case Study 3: PKI with Redundant CAs (CA Hierarchy)

A third CA running on Cisco IOS has now been added to the topology. This CA will serve as the root CA in the PKI CA hierarchy. IOS_CA2 is now configured as a full CA server that subscribes to the root CA. As such, there are now two CA servers running on Cisco IOS that are subscribed to the root CA.

Note

Traditionally, PKIs have only accommodated two tiers in their hierarchiesthe root CA comprises the first tier, and all other CAs in the second tier must subscribe to that tier-1 root CA. Cisco IOS supports multiple tier hierarchies for additional PKI scalability in later versions of 12.2T.

The two IOS-based CAs are configured to subscribe to the root CA as shown in Example 11-10 and Example 11-11.

Example 11-10. IOS_CA1 Configuration

IOS-CA1#configure terminal IOS-CA1(config)#crypto pki server IOS_CA1 IOS-CA1(cs-server)#grant auto IOS-CA1(cs-server)#exit IOS-CA1(config)#crypto pki trustpoint IOS_CA1 IOS-CA1(ca-trustpoint)#enrollment url http://10.1.12.100:80 IOS-CA1(ca-trustpoint)#revocation-check crl IOS-CA1(ca-trustpoint)#rsakeypair IOS_CA1 IOS-CA1(ca-trustpoint)#end

Example 11-11. IOS_CA2 Configuration

IOS-CA2#configure terminal IOS-CA2(config)#crypto pki server IOS_CA2 IOS-CA2(cs-server)#grant auto IOS-CA2(cs-server)#exit IOS-CA2(config)# IOS-CA2(ca-trustpoint)#crypto pki trustpoint IOS_CA2 IOS-CA2(ca-trustpoint)#enrollment url http://10.1.12.100:80 IOS-CA2(ca-trustpoint)#revocation-check crl IOS-CA2(ca-trustpoint)#rsakeypair IOS_CA2 IOS-CA2(ca-trustpoint)#end

Note

The CAs in Example 11-10 and Example 11-11 are subordinate to the root CA, IOS_CAROOT. Each subordinate CA must download the root CA certificate and authenticate the root CA. Likewise, each subordinate CA is configured to enroll with the root CA (shaded text in Example 11-10 and Example 11-11).

The root CA is configured to grant its certificate to the root CA, as shown in Example 11-12. The root CA can therefore use what is commonly referred to as a "self-signed certificate" when IOSCA1 and IOS-CA2 are unavailable, providing another layer of redundancy within the PKI hierarchy.

Example 11-12. Root CA Configuration

IOS-CAROOT#configure terminal IOS-CAROOT(config)#crypto pki server IOS_CAROOT IOS-CAROOT(cs-server)#grant auto IOS-CAROOT(cs-server)#exit IOS-CAROOT(config)#crypto pki trustpoint IOS_CAROOT IOS-CAROOT(ca-trustpoint)#revocation-check crl IOS-CAROOT(ca-trustpoint)#rsakeypair IOS_CAROOT IOS-CAROOT(ca-trustpoint)#end

Each cryptographic endpoint will authenticate the root CA and at least one of its subordinate CAs for redundancy. Likewise, each cryptographic endpoint will enroll with the root CA and one of its subordinates. Example 11-13 shows the configuration of redundant trustpoints on one of the Frame Relay spoke routers, 3745-A. Example 11-14 displays the configuration of the Frame Relay head-end 7206VXR. The Frame Relay hub router must authenticate and enroll with all of the CAs in the PKI, since not all of the Frame Relay spokes will have their certificates signed by the same CA. The process of enrollment for the cryptographic endpoints for each CA trustpoint configured is consistent with the procedures discussed in the previous case studies in this chapter.

Example 11-13. Frame Relay Spoke (3745) Configuration for PKI Redundancy.

3745-A#configure terminal 3745-A(config)#crypto pki trustpoint IOS_CAROOT 3745-A(ca-trustpoint)#enrollment url http://10.1.12.100:80 3745-A(ca-trustpoint)#serial-number 3745-A(ca-trustpoint)#ip-address Serial0/0 3745-A(ca-trustpoint)#revocation-check crl 3745-A(ca-trustpoint)#exit 3745-A(config)#crypto pki trustpoint IOS_CA1 3745-A(ca-trustpoint)#enrollment url http://200.2.1.2:80 3745-A(ca-trustpoint)#serial-number 3745-A(ca-trustpoint)#ip-address Serial0/0 3745-A(ca-trustpoint)#revocation-check crl 3745-A(ca-trustpoint)#end

Example 11-14. Frame Relay Hub (7206VXR) Configuration for PKI Redundancy

7206VXR#configure terminal 7206VXR(config)#crypto ca trustpoint IOS_CAROOT 7206VXR(ca-trustpoint)#enrollment url http://10.1.12.100:80 7206VXR(ca-trustpoint)#serial-number 7206VXR(ca-trustpoint)#ip-address FastEthernet0/1 7206VXR(ca-trustpoint)#exit 7206VXR(config)#crypto ca trustpoint IOS_CA1 7206VXR(ca-trustpoint)#enrollment url http://200.2.1.2:80 7206VXR(ca-trustpoint)#serial-number 7206VXR(ca-trustpoint)#ip-address FastEthernet0/1 7206VXR(ca-trustpoint)#exit 7206VXR(config)#crypto ca trustpoint IOS_CA2 7206VXR(ca-trustpoint)#enrollment url http://200.2.2.2:80 7206VXR(ca-trustpoint)#serial-number 7206VXR(ca-trustpoint)#ip-address FastEthernet0/1 7206VXR(ca-trustpoint)#end