Configuring Cisco Encryption Technology

20 Mar

Immediate Solutions
Configuring Cisco Encryption Technology

Configuring CET involves prior coordination between the local security administrator and the remote encryption peer’s security administrator. After that is accomplished, perform the following configuration tasks:

1.Use the following command to generate DSS keys for each crypto engine you will use:

crypto key generate dss key−name

The DSS key pair that is generated is used by peer routers to authenticate each other before each encrypted session. The same DSS key pair is used by a crypto engine with all its encrypted sessions.

2.Use this command to save the DSS keys that are generated to private NVRAM on the router (this command is only needed if the router is using a software−based crypto engine):

copy running−config startup−config

Next, the exchange of DSS public keys with all participating peer routers must be configured, which allows peer routers to authenticate each other at the start of encrypted
communication sessions. Use this command to enable a DSS key exchange on the passive peer router:

crypto key exchange dss passive <tcp−port>

The passive router will wait to exchange keys until after the active router has exchanged
keys with the passive router.

4.Use this command to define the active peer, which initiates a connection to the passive peer and exchanges keys:

crypto key exchange dss <ip−address> <key−name> <tcp−port>

Tasks 3 and 4 need a little further explanation. Prior to configuring a peer router for DSS key exchange in Step 3, “voice authentication” must take place between the security administrator of the local peer router and the security administrator of the remote peer router. You and the other administrator decide which of you will be what is referred to as the “passive” peer and which of you will be what is referred to as the “active” peer. The passive router enables a DSS exchange connection using the command listed in Step 3. The active router then initiates a DSS exchange connection with the passive peer router and sends a DSS public key to it. The serial number and
fingerprint of the active router’s DSS public key will then be displayed on screen of each security administrator’s machine. The serial number and fingerprint that are displayed are numeric values that are generated from the active router’s DSS public key. Each security administrator should verbally verify that the serial number and fingerprint are the same on both screens. If the displayed serial numbers and fingerprints match and the security administrators are in agreement that the serial numbers and fingerprints are valid, the administrator of the passive router should agree to accept the active router’s DSS key by typing “yes” at the prompt. The passive router’s security administrator then sends the active router’s security administrator its DSS public key by pressing Return at the screen prompt and selecting a crypto engine at the next prompt. The passive router’s DSS serial number and fingerprint are then displayed on each of the security administrators’ screens. Each security administrator should verbally verify that the serial number and fingerprint are the same on both screens. If the displayed serial numbers and fingerprints match, and the security administrators are in agreement that the serial numbers and fingerprints are valid, the administrator of the active router should agree to accept the passive router’s DSS key by typing “yes” at the prompt. At this point, both routers have been “verbally authenticated.” This process can be seen in Figure 5.4.

Figure 5.4: Verbal authentication process.

5.Use the following command to enable 56−bit DES with 8−bit or 64−bit cipher feedback:

crypto cisco algorithm des <cfb−8 | cfb−64>

Or use this command to enable 40−bit DES with 8−bit or 64−bit cipher feedback to configure the global encryption policy of the router:

crypto cisco algorithm 40−bit−des <cfb−8 | cfb−64>

The 56−bit DES option is the default.

Use one of the following commands to define an extended access list that will signify which IP packets will be encrypted and which IP packets will not be encrypted:

access−list <access−list−number> <deny | permit><protocol>
<source—source−wildcard><destination destination−
wildcard><precedence − precedence>

When defined for encryption of traffic, access lists function differently than when they function when they’re used as a packet filter. Using a permit keyword will cause the selected traffic that is passed between the specified source and destination addresses to be encrypted/decrypted by peer routers. Using a deny keyword prevents that traffic from being encrypted/decrypted by peer routers. The encryption access list you define at the local router must have a “mirror−image” encryption access list defined at the remote router so that traffic that is encrypted locally is decrypted at the remote peer.

7.Use this command to define a crypto map name:

crypto map <map−name> <seq−num> {cisco}

Use of this command moves you into the crypto map configuration mode.

8.Under crypto map configuration mode, use this command to define the remote peer with which an encrypted session will take place:

set peer <key−name>

9. Under crypto map configuration mode, use the following command to assign the previously configured access list to the crypto map:

match address <access−list−id | name>

Under crypto map configuration mode, use the command to define the encryption algorithms that the router can negotiate for the session:

set algorithm des <cfb−8 | cfb−64> command or −
the set algorithm − 40−bit−des <cfb−8 | cfb−64>

Any encryption algorithms that have been previously defined at the global level can be defined in the crypto map. If an encryption algorithm has not been defined at the global level, it cannot be defined in the crypto map.

11.Use this command to move into interface configuration mode:

interface <interface type> <interface number>

12.In interface configuration mode, use this command to apply the previously configured crypto map to an interface:

crypto map <map−name>

Only one crypto map set can be applied to each interface that will encrypt outbound data and decrypt inbound data. This interface provides the encrypted connection to a peer encrypting router.

Figure 5.5 illustrates the network topology and components of the fictitious company that will be used throughout the configuration example of CET. This network displays two routers; Router A is defined as the active router and Router B is defined as the passive router.

Figure 5.5: CET network topology.

One key step that should always be performed prior to the configuration of encryption on any network device is to ensure that the network functions properly; this means that basic connectivity between peer routers has been tested and is functioning before encryption is configured on the routers. The ping command can be used to test basic connectivity between encrypting peer routers. Also, although a successful ping will verify basic connectivity between peers, you should ensure that the network operates with other protocols or ports you want to encrypt before beginning the CET configuration. After CET is configured and activated, basic troubleshooting can become difficult to perform because the security configuration could mask a more fundamental network problem.

Note This configuration example in this chapter will not follow the same structure as examples in other chapters have followed. In this example, I will present the beginning configuration of the routers involved, then walk you through each step of configuring Cisco Encryption Technology, and finally, present to you the final completed configuration.

To verify that Router A and Router B in Figure 5.5 function properly prior to configuring CET on the routers, Listing 5.1 and Listing 5.2 display the basic configurations of the routers. Listing 5.3 and Listing 5.4 verify that basic connectivity between each peer functions properly without encryption configured. This will allow the routers to be baselined prior to the CET configuration.

Listing 5.1: Initial configuration of Router A.

version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password−encryption
!
hostname Router−A
!
username routera privilege 15 password 0 routera
!
memory−size iomem 10
ip subnet−zero
no ip finger
ip tcp synwait−time 10
no ip domain−lookup
!
interface Ethernet1/1
ip address 192.168.10.1 255.255.255.0
no ip directed−broadcast
duplex auto
speed auto
!
interface Serial0/0
ip address 192.168.12.1 255.255.255.0
no ip directed−broadcast
no fair−queue
!
ip classless
no ip http server
!
ip route 0.0.0.0 0.0.0.0 serial0/0
!
line con 0
session−timeout 30
exec−timeout 30 0
login local
transport input none
line aux 0
line vty 0 4
session−timeout 30
exec−timeout 30 0
login local
!
end

Listing 5.2: Initial configuration of Router B.

version 12.1
service timestamps debug uptime

service timestamps log uptime
no service password−encryption
!
hostname Router−B
!
username routerb privilege 15 password 0 routerb
!
memory−size iomem 10
ip subnet−zero
no ip finger
ip tcp synwait−time 10
no ip domain−lookup
!
interface Ethernet0/1
ip address 192.168.11.1 255.255.255.0
no ip directed−broadcast
duplex auto
>speed auto
!
interface Serial0/0
ip address 192.168.12.2 255.255.255.0
no ip directed−broadcast
no fair−queue!
ip classless
no ip http server
!
ip route 0.0.0.0 0.0.0.0 serial0/0
!
line con
0
session−timeout 30
exec−timeout 30 0
login local
transport input none
line aux 0
line vty 0 4
session−timeout 30
exec−timeout 30 0
login local
!
end

Both routers in Listing 5.1 and Listing 5.2 provide access to the Internet and act as the single entry and exit point from the local network to the outside world, which is why they each have a static default route pointing out their serial interface. Prior to configuring CET on your routers, you must ensure that each router that needs to perform encryption can communicate with each peer. For CET to function properly and for encryption to take place, Layer 3 communication must be established between each peer. In Listing 5.3 and Listing 5.4, the ping command will be used to verify Layer 3 connectivity between Router A and Router B.

Listing 5.3: Layer 3 connectivity verified on Router A.

Router−A#ping 192.168.12.2
Type escape sequence to abort.
Sending 5, 100−byte ICMP Echos to 192.168.12.2, timeout −
is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round−trip −
min/avg/max = 1/2/4 ms
Router−A#

Listing 5.4: Layer 3 communication verified on Router B.

Router−B#ping 192.168.12.1
Type escape sequence to abort.
Sending 5, 100−byte ICMP Echos to 192.168.12.1, timeout −
is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round−trip −
min/avg/max = 1/2/4 ms
Router−B#

The output in Listing 5.3 and Listing 5.4 confirms that communication between each peer is working properly because each peer can ping the serial interface of the other router.

The first task that must be performed to configure CET is to generate each peer router’s public and private key and save them to NVRAM.

Listing 5.5 displays an example of generating Router A’s public and private keys. Listing 5.6 displays an example of generating Router B’s public and private keys.

Listing 5.5: Generating Router A’s key.

Router−A(config)#crypto key generate dss routera
Generating DSS keys ….
[OK]

Listing 5.6: Generating Router B’s key.

Router−B(config)#crypto key generat dss routerb
Generating DSS keys ….
[OK]

After each router’s key pair is generated, the keys need to be saved into a private portion of NVRAM on the routers. To save the each router’s key to NVRAM on the routers, the copy running−config startup−config command is used. Listing 5.7, shows Router A saving its private key to NVRAM. Listing 5.8 shows Router B saving its private key to NVRAM.

Listing 5.7: Router A saving private key to NVRAM.

Router−A#copy running−config startup−config
Destination filename [startup−config]?
Building configuration…
[OK]
Router−A#

Listing 5.8: Router B saving private key to NVRAM.

Router−B#copy running−config startup−config
Destination filename [startup−config]?
Building configuration…
[OK]
Router−B#

As mentioned previously, the command used in Listing 5.5 and Listing 5.6 generate a public key and a private key. The private keys that generated on each router are saved into NVRAM and are inaccessible for viewing because if anyone were to gain access to the private key, she could masquerade as the owner of the private key and all data secured using the private key could be compromised. Cisco routers have been designed so that the private keys that are generated and saved to NVRAM cannot be accessed or tampered with. The public key can be viewed, however, because it is shared with its encryption peers. To view the public keys that were generated as a result of issuing the crypto key generate dss command, issue the show crypto key mypubkey dss command. Listing 5.9 shows an example of issuing the show crypto key mypubkey dss command on Router A. Listing 5.10 displays an example of issuing the show crypto key mypubkey dss command on Router B.

Listing 5.9: Viewing Router A’s public key.

Router−A#show crypto key mypubkey dss
Key name: routera
Serial number: 6B86ECF4
Usage: Signature Key
Key Data:
CC0438CE 125C2C5E DAE47A2C B47B44EE 4737C1D9 9FDF3164
69CAACA7 82D25416 8CA218AC 644BE782 36966277 BBF437DF
1347FFAA F2E3C04E 94CE60E5 5485C539
Router−A#

Listing 5.10: Viewing Router B’s public key.

Router−B#sh crypto key mypubkey dss
Key name: routerb
Serial number: 0615EC60
Usage: Signature Key
Key Data:
4B013A5D DB942F8F 556B6F67 13110723 A05F17F9 D7BA15BF
74B1C17B D2E5C4A5 ABC0A7DE D1188289 A54C80EC 5BB3B9AE
F4366FB1 D5DBB125 C44F904A 62209467
Router−B#

Now each router must exchange its public keys. According to Figure 5.5, Router B has been determined to be the passive router and Router A has been determined to be the active router. Router B must now be configured to initiate a key exchange connection; to do so, use the crypto key exchange dss passive command. Listing 5.11 displays an example of configuring Router B to be passive.

Listing 5.11: Router B enabling DSS key exchange.

Router−B(config)#crypto key exchange dss passive
Enter escape character to abort if connection does not complete.
Wait for connection from peer[confirm]
Waiting ….

Router B is now waiting for a connection from the active router, Router A. In order for the public keys to be exchanged, Router A must now be configured to initiate a key exchange connection; this is done by using the cypto key exchange dss command. Listing 5.12 displays an example of configuring Router A to be active and send its public DSS keys to Router B.


Random Posts

No comments yet

Leave a Reply

You must be logged in to post a comment.