Example 4-13, line 5, confirms that ISAKMP SA negotiation is initiated with RSA Encryption for authentication. Output from Example 4-13, line 8, indicates that IKE messages cannot be decrypted, because Router_B is mistakenly using Router_A's decryption key for encrypting IKE messages to Router_A, rather than using Router_A's proper encryption key to do so. Example 4-13, lines 19-40, illustrate that the same key misconfiguration on Router_A is causing IKE SA authentication to fail on Router_B for the same reasons it failed earlier on Router_A.
Example 4-13 Troubleshooting IKE Authentication Failures with RSA Encryption
1 Router_A#debug crypto isakmp 2 Crypto ISAKMP debugging is on 3 ! 4 ! 5 *Feb 17 10:58:20.066: ISAKMP (0:1): SA is doing RSA encryption authentication using id type ID_IPV4_ADDR 6 ! 7 ! 8 *Feb 17 10:58:20.554: %CRYPTO-6-IKMP_CRYPT_FAILURE: IKE (connection id 1) unable to decrypt (w/RSA private key) packet 9 ! 10 ! 11 *Feb 17 10:58:41.706: ISAKMP (0:1): retransmitting phase 1 MM_SA_SETUP... 12 *Feb 17 10:58:41.706: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1 13 ! 14 ! 15 *Feb 17 10:59:19.918: ISAKMP (0:1): deleting SA reason "gen_IPsec_isakmp_delete but doi isakmp" state (I) MM_SA_SETUP (peer 200.0.0.2) input queue 0 16 *Feb 17 10:59:19.918: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL 17 *Feb 17 10:59:19.918: ISAKMP (0:1): Old State = IKE_I_MM3 New State = IKE_DEST_SA 18 19 Router_B#debug crypto isakmp 20 Crypto ISAKMP debugging is on 21 ! 22 ! 23 *Feb 17 10:01:10.930: ISAKMP:(0:1:SW:1):SA is doing RSA encryption authentication using id type ID_IPV4_ADDR 24 ! 25 ! 26 *Feb 17 10:01:21.658: ISAKMP:(0:1:SW:1): retransmitting phase 1 MM_KEY_EXCH 27 *Feb 17 10:01:21.658: ISAKMP:(0:1:SW:1): sending packet to 200.1.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH 28 ! 29 ! 30 *Feb 17 10:01:55.466: ISAKMP: quick mode timer expired. 31 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):src 200.0.0.1 dst 200.0.0.2, SA is not authenticated 32 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):peer does not do paranoid keepalives. 33 ! 34 ! 35 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):deleting SA reason "QM_TIMER expired" state (R) MM_KEY_EXCH (peer 200.0.0.1) 36 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):deleting SA reason "QM_TIMER expired" state (R) MM_KEY_EXCH (peer 200.1.1.1) 37 *Feb 17 10:01:55.466: ISAKMP: Unlocking IKE struct 0x65C405A8 for isadb_mark_sa_deleted(), count 0 38 *Feb 17 10:01:55.466: ISAKMP: Deleting peer node by peer_reap for 200.1.1.1: 65C405A8 39 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL 40 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM4 New State = IKE_DEST_SA
Cisco IOS VPN endpoints can be instructed to use certain RSA public keys with certain peers, a similar functionality to standard PSK authentication. As such, it is important that each VPN endpoint is using the correct key for the correct peer. Consider once again the situation in which the administrators of Router_A choose to source the VPN tunnel endpoint from their loopback1 (201.0.0.1) interface. The administrators of Router_B have fixed the mismatching key problem in Example 4-11 through Example 4-13, and have updated their IPsec configuration to peer with Router_A's loopback address. However, they have not updated the address that ISAKMP should use when authenticating the IKE channel with Router_B's public/encryption key (see configurations listed in Figure 4-4). Therefore, Router_B cannot select the appropriate public key to authenticate the IKE channel with Router_A. Once again, this leads to an IKE Authentication error, which eventually causes ISAKMP SA negotiation to time out.
RSA Encryption and ISAKMP Peer Mismatches
Example 4-14 provides the RSA key configuration for Router_A in Figure 4-4.
Example 4-14 Router_A RSA Encryption Key Peer Mismatch with Router_B in Figure 4-4 (Router_B Configuration Provided in Example 4-15)
1 Router_A#show crypto key mypubkey rsa 2 % Key pair was generated at: 10:56:03 UTC Feb 17 2005 3 Key name: Router_A.cisco.com 4 Usage: General Purpose Key 5 Key is not exportable. 6 Key Data: 7 305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2 8 415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B 9 4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001 10 % Key pair was generated at: 11:56:05 UTC Feb 17 2005 11 Key name: Router_A.cisco.com.server 12 Usage: Encryption Key 13 Key is not exportable. 14 Key Data: 15 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00A233B3 3A58DDB2 16 D578B1A4 0125E1CD 1594C9F2 24DACE5E 65A276C7 640E9A13 B8DC4EEC F332B8D8 17 80127FD6 07A579F6 A280DF7D 2ED2CA8B 3457F5DE 53DAB835 C2845EB6 42F89BB0 18 C7130F67 B10FD71E 30A1FB1E 812CA1A6 26F43DCA 7BDDA01D 65020301 0001 19 20 Router_A#show crypto key pubkey-chain rsa address 200.0.0.2 21 Key address: 200.0.0.2 22 Usage: General Purpose Key 23 Source: Manually entered 24 Data: 25 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF 26 64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE 27 28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162 28 C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4 29 5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001
Example 4-15 provides the RSA key configuration for Router_B in Figure 4-4. Note that, although the public and private keys have been correctly configured on Router_A and Router_B, Router_B is not configured with the correct peering information in its encryption key settings to be used with Router_A. This peer mismatch is illustrated in Example 4-15, lines 22-23.
Example 4-15 Router_B RSA Encryption Key Peer Mismatch with Router_A in Figure 4-4 (Router_A Configuration Provided in Example 4-14)
1 Router_B#show crypto key mypubkey rsa 2 % Key pair was generated at: 09:59:17 UTC Feb 17 2005 3 Key name: Router_B.cisco.com 4 Usage: General Purpose Key 5 Key is not exportable. 6 Key Data: 7 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF 8 64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE 9 28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162 10 C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4 11 5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001 12 % Key pair was generated at: 10:59:18 UTC Feb 17 2005 13 Key name: Router_B.cisco.com.server 14 Usage: Encryption Key 15 Key is not exportable. 16 Key Data: 17 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00CA138A 38268367 18 9FB2BDA8 A5C4677B 06A0FA1C 7811BAA6 C6FA48A7 E3DE55D0 B6967E71 DF076209 19 1F3CCA1E A7F40179 B4013CC8 ADCB15DD FFDAFAC3 9210BEA7 894DEEDA 1BF59C4B 20 B0143E21 80559A4D 4F8A512E DB739E8B 576E61FD 650BDA6B 87020301 0001 21 22 Router_B#show crypto key pubkey-chain rsa address 200.0.0.1 23 Key address: 200.0.0.1 24 Usage: General Purpose Key 25 Source: Manually entered 26 Data: 27 305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2 28 415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B 29 4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001
Once the configuration on Router_B (Example 4-15, lines 22-23) has been updated to use Router_A's public key with Router_A's new peering information (lo1=201.0.0.1), then the ISAKMP SA can be negotiated successfully using RSA Encryption as confirmed in Example 4-16.
Example 4-16 Updated Peer Configuration on Router_B, and ISAKMP SA Confirmation
1 Router_B#sh run 2 Building configuration... 3 crypto key pubkey-chain rsa 4 addressed-key 201.0.0.1 5 address 201.0.0.1 6 key-string 7 305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2 8 415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B 9 4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001 10 quit 11 12 Router_B#ping 13 ! 14 ! 15 Sending 5, 100-byte ICMP Echos to 202.1.1.1, timeout is 2 seconds: 16 Packet sent with a source address of 202.2.2.1 17 .!!!! 18 Success rate is 80 percent (4/5), round-trip min/avg/max = 40/43/44 ms 19 *Feb 17 11:21:41.570: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP . Peer 201.0.0.1:500 Id: 201.0.0.1 20 Router_B#show crypto isakmp sa 21 dst src state conn-id slot 22 201.0.0.1 200.1.1.2 QM_IDLE 1 0 23 Router_B#show crypto key pubkey-chain rsa 24 Codes: M - Manually configured, C - Extracted from certificate 25 26 Code Usage IP-Address/VRF Keyring Name 27 M General 201.0.0.1 default
Note - In the preceding examples pertaining to RSA encryption, Router_A (512 bit-mod) and Router_B (1024-bit mod) have been using mismatched key modulus. This will not cause IKE authentication errors, but does not provide the same strength in authentication as using 1024-bit keys on both sides.
Last, it is important to note that the configurations above use IP addresses (addressed-key) selecting public keys to use with their corresponding peer. Alternately, administrators can use hostnames to identify peers, instead of IP addresses. When using hostnames, administrators must verify that the hostname can be resolved to an IP address via DNS or manually using the ip host [ip-address] [hostname] command in the local router configuration. Additionally, each peer using a hostname for ISAKMP identification must be instructed to do so using the crypto isakmp identity [hostname] command, as the default is use of the IP address associated with the physical interface where the crypto map is applied.
IKE Authentication Errors with RSA Signatures
As we'll discuss later in Chapter 11, the dynamics of authentication change dramatically when RSA signatures are used. Until now, we've discussed IKE SA authentication methods that require direct key exchange between crypto endpoints, including both IKE PSK and RSA Encrypted Nonce methods of IKE authentication. Now we will discuss the RSA Signatures method of IKE SA authentication, in which both endpoints are authenticated indirectly using a centralized trusted resource, a Certificate Authority (CA), during Phase 1 negotiation. As such, our focus will not be on endpoint-endpoint authentication and peering, but instead will explore common IKE authentication issues attributable to endpoint-CA operation:
Authenticating the CA and Obtaining the CA Certificate
Enrolling with the CA and Obtaining Public Key Certificates
We will examine debugs and diagnostics for each of these processes using the topology in Figure 4-5, as Routers A and B obtain certificates from IOS_CAROOT needed for IKE authentication using RSA Signatures. It has been confirmed that Router_A and Router_B can reach the CA.
Troubleshooting IKE Authentication Errors with RSA Signatures
Example 4-17 provides the configuration for Router_A in Figure 4-5. We will use this configuration while troubleshooting and validating IKE SA authentication with RSA Signatures later in this chapter.
Example 4-17 RSA Signatures Configuration on Router_A (Figure 4-5)
Router_A#show crypto ca certificates
Certificate
Status: Available
Certificate Serial Number: 03
Certificate Usage: General Purpose
Issuer:
cn=IOS_CAROOT
Subject:
Name: Router_A.cisco.com
IP Address: 192.168.1.1
Serial Number: 01C2F27F
serialNumber=1C2F27F+ipaddress=192.168.1.1+hostname=Router_A.cisco.com
Validity Date:
start date: 10:12:45 UTC Feb 24 2005
end date: 10:12:45 UTC Feb 24 2006
renew date: 00:00:00 UTC Jan 1 1970
Associated Trustpoints: IOS_CAROOT
CA Certificate
Status: Available
Certificate Serial Number: 01
Certificate Usage: Signature
Issuer:
cn=IOS_CAROOT
Subject:
cn=IOS_CAROOT
Validity Date:
start date: 09:06:11 UTC Feb 24 2005
end date: 09:06:11 UTC Feb 24 2008
Associated Trustpoints: IOS_CAROOT
Router_A#show crypto key mypubkey rsa
% Key pair was generated at: 10:11:30 UTC Feb 24 2005
Key name: Router_A.cisco.com
Usage: General Purpose Key
Key is not exportable.
Key Data:
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00AF2FC9
1919ECF1 DE24C37D 796658E2 2B186600 98EB5CE3 AE0E53FE B1F736EA CE417989
F3029E25 594B9BCB 30DD0A2D 799814B1 555071FE BFB081E1 80548F91 3021F997
0FBC0B62 4A6284A4 22175B89 4D5C00B2 4DE6F657 F6CA00DA E8629294 413487F6
6AB72BAF 071F4C63 CD813C3A 8925B95D F3DE265C CCFA3AA5 C38386DA 25020301 0001
% Key pair was generated at: 10:11:31 UTC Feb 24 2005
Key name: Router_A.cisco.com.server
Usage: Encryption Key
Key is exportable.
Key Data:
307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00C7CE18 CD11DBAE
6FE6999B 15E81063 998CD039 91677AAD 9E310C38 9CF10010 EE3BBD5C 574837E8
08098084 D1F09C7D 9143F22C 6684AAA5 9B518676 AB205A9B 2681B77A 24E69ABA
734AB29C 28D4A672 4C93B3B4 DE27CB77 FF0DBBF0 2A5ABF1F AF020301 0001
Router_A#show crypto key pubkey-chain rsa
Codes: M - Manually configured, C - Extracted from certificate
Code Usage IP-Address/VRF Keyring Name
C Signing default X.500 DN name:
cn=IOS_CAROOT
C Signing 192.168.2.1/ default Router_B.cisco.com
Example 4-18 provides the configuration for Router_B in Figure 4-5. We will use this configuration while troubleshooting and validating IKE SA authentication with RSA Signatures later in this chapter.