ISAKMP associations using RSA keys

By stretch | Wednesday, January 14, 2009 at 12:15 a.m. UTC

Most of the IPsec tunnels I see configured, both in labs and in the real world, rely on relatively weak preshared keys to establish the initial secure ISAKMP channel for key exchange between the IPsec peers (see my IPsec quick and dirty article for an example configuration). A much stronger solution is to use public/private key pairs distributed by a secure Public Key Infrastructure (PKI) Certificate Authority (CA). Unfortunately, deploying an enterprise PKI is no small undertaking, and many engineers are understandably hesitant about tying any aspect of network connectivity to the functionality of unrelated servers or services.

Fortunately, IOS allows for a comfortable middle ground, using manually distributed RSA encryption keys on routers. The 12.4T documentation has a pretty clear run-down of the steps required for such a setup. The example in this post will create an IPsec tunnel between R1 and R3 in the following topology.

topology.png

First, we need to generate an RSA public/private key pair on both of the endpoint routers.

R1(config)# crypto key generate rsa general-keys label R1
The name for the keys will be: R1
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]: 
% Generating 512 bit RSA keys, keys will be non-exportable...[OK]
R3(config)# crypto key generate rsa general-keys label R3
The name for the keys will be: R3
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]: 
% Generating 512 bit RSA keys, keys will be non-exportable...[OK]

If this is your first time creating an RSA keypair on the router, you may see a log message indicating that SSH has been enabled. RSA keys are also used for securing SSH connections.

%SSH-5-ENABLED: SSH 1.99 has been enabled

We can view the public key in our new keypair with the show crypto key mypubkey rsa command:

R1# show crypto key mypubkey rsa R1
% Key pair was generated at: 00:20:40 UTC Mar 1 2002
Key name: R1
 Storage Device: not specified
 Usage: General Purpose Key
 Key is not exportable.
 Key Data:
  305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00B000A8 22C680DC 
  AC788B8D 536BFF8A 999F7905 8F6D6878 73C07ECC 2BB2478A ACF270DB 08FF854F 
  99827407 294C63C4 1B5E9EBB CD3277E3 88A48EFD 033F3806 C9020301 0001
R3# show crypto key mypubkey rsa R3
% Key pair was generated at: 00:21:56 UTC Mar 1 2002
Key name: R3
 Storage Device: not specified
 Usage: General Purpose Key
 Key is not exportable.
 Key Data:
  305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00B6CAA3 400F6DA9 
  1D1D6553 3A272A70 A713D69B CA790F74 7D067215 4E2DEDC8 4A59F8A6 F849C422 
  8D7FCEBE 0D1E4D73 6541A85D 899D4208 EB176BB6 3125C290 63020301 0001

Note that I've neglected to properly configure the clock on the routers in my lab; when creating crypto keys in the real world, you want to first ensure the router's clock is accurate.

Both routers now have unique public and private keys. For these to be useful, we need to exchange the public keys between the routers so that R1 has a copy of R3's public key and vice versa. To do that, we create a public key chain on each router and manually copy the keys over.

R1(config)# crypto key pubkey-chain rsa
R1(config-pubkey-chain)# addressed-key 10.0.23.3 encryption
R1(config-pubkey-key)# key-string
Enter a public key as a hexidecimal number ....

At this prompt you can simply copy the key from the output of R3's terminal into R1's terminal. End by entering quit.

R1(config-pubkey)# 305C300D 06092A86 4886F70D 01010105
R1(config-pubkey)# 00034B00 30480241 00B6CAA3 400F6DA9
R1(config-pubkey)# 1D1D6553 3A272A70 A713D69B CA790F74
R1(config-pubkey)# 7D067215 4E2DEDC8 4A59F8A6 F849C422
R1(config-pubkey)# 8D7FCEBE 0D1E4D73 6541A85D 899D4208
R1(config-pubkey)# EB176BB6 3125C290 63020301 0001
R1(config-pubkey)# quit

We can confirm that the key was successfully entered on R1 by inspecting its public key chain:

R1# show crypto key pubkey-chain rsa address 10.0.23.3
Key address:        10.0.23.3             
 Usage: Encryption Key
 Source: Manually entered
 Data:
  305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00B6CAA3 400F6DA9 
  1D1D6553 3A272A70 A713D69B CA790F74 7D067215 4E2DEDC8 4A59F8A6 F849C422 
  8D7FCEBE 0D1E4D73 6541A85D 899D4208 EB176BB6 3125C290 63020301 0001

Note that the hex string above exactly matches that in the output of show crypto key mypubkey rsa R3 on R3. This verifies that we have correctly copied its public key.

Repeat this configuration for R3, copying R1's public key to R3, to complete the key exchange.

With the RSA keys settled, we can move on to the ISAKMP and IPsec configurations. Creating an ISAKMP profile to use the RSA keys is almost indentical to one which uses a preshared key, except we specify RSA encryption as the authentication type instead of pre-shared.

R1(config)# crypto isakmp policy 10
R1(config-isakmp)# encryption aes
R1(config-isakmp)# hash sha
R1(config-isakmp)# authentication rsa-encr

At this point, you might encounter the following system message, especially if performing this configuration on a Dynamips lab:

%CRYPTO-4-IKMP_INVALID_POLICY: ISAKMP policy rsa-encr not supported by crypto
 HW accelerator

This message warns that hardware RSA encryption is unavailable on the platform, and can be safely ignored in our case.

We can verify the creation of our ISAKMP policy with show crypto isakmp policy:

R1# show crypto isakmp policy

Global IKE policy
Protection suite of priority 10
    encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
    hash algorithm:     Secure Hash Standard
    authentication method:  Rivest-Shamir-Adleman Encryption
    Diffie-Hellman group:   #1 (768 bit)
    lifetime:       86400 seconds, no volume limit

I'll resist diving into the remainder of the IPsec configuration here, but the following is an example configuration for R1 (you can also reference the complete R1 and R3 configs attached at the end of this article):

crypto ipsec transform-set MyTransformSet ah-sha-hmac esp-aes 
!
crypto ipsec profile MyProfile
 set transform-set MyTransformSet 
!
interface Tunnel0
 ip address 172.16.0.1 255.255.255.252
 tunnel source 10.0.12.1
 tunnel destination 10.0.23.3
 tunnel protection ipsec profile MyProfile

Once the configurations have been completed, you can inpsect the ISAKMP and IPsec security associations with show crypto isakmp sa and show crypto ipsec sa, respectively:

R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
10.0.23.3       10.0.12.1       QM_IDLE           1001    0 ACTIVE

IPv6 Crypto ISAKMP SA

R1# show crypto ipsec sa

interface: Tunnel0
 Crypto map tag: Tunnel0-head-0, local addr 10.0.12.1

protected vrf: (none)
   local  ident (addr/mask/prot/port): (10.0.12.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (10.0.23.3/255.255.255.255/47/0)
   current_peer 10.0.23.3 port 500
 PERMIT, flags={origin_is_acl,}
#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 10.0.12.1, remote crypto endpt.: 10.0.23.3
 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
 current outbound spi: 0x8FF969E(150967966)
...

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Security

Comments


Paul Stewart (guest)
January 14, 2009 at 12:46 a.m. UTC

You are dead on and this is a good middleground approach. Unfortunately it is not supported on the Pix and ASA. I wish Cisco would add support across the board.


Phuc (guest)
January 14, 2009 at 2:23 a.m. UTC

It's an interesting, I always love the way to present technology topics in your blog.
Just small idea for the CA, I went with Windows 2K server for this function and even on the cisco router ( I did not test CA on a router yet).
Good luck on the CCIE certificate :)


Sean (guest)
January 14, 2009 at 3:38 a.m. UTC

The IOS CA works well, and is fairly easy to manage. At a previous job I had set up a 14 site DMVPN network using the IOS CA.

The only catch is the CA has to be accessible to issue the keys (and distribute the CRL, which you can disable), which means it has to be on the Internet or you need a back door to it.

Sean


Karsten (guest)
January 14, 2009 at 8:43 a.m. UTC

But be aware that some older encyption-cards (I don't remember which, was in the 36xx-era) are not compatible at all with RSA Encryption. The VPNs just stopped working.


Cisco (guest)
January 14, 2009 at 5:40 p.m. UTC

Also...don't think about using IPsec on your ASA if you're also using multiple security contexts (Multimode)...its not supported as of yet! You can only use IPsec on your ASA when it's in single mode.


MGK (guest)
January 15, 2009 at 12:59 p.m. UTC

why do you use rsa-enc? it is not widly supported (no asa etc.) and some newer accelerator cards do not support it (there is even a warning in IOS)
What i always recommend is using the keys you configured with RSA-signatures (YES, a CA is NOT required... it also works fine with locally configured keys like in your example...)


Kenny Kant (guest)
January 18, 2009 at 4:58 p.m. UTC

Can you help me understand why pre-shared keys are not a preferred way of configuring L2L tunnels? I ask because it seems this is how everyone in the world does it. I understand that by using this method you are almost always allowing the entire world to try and associate with you at phase 1 . Is it just because it opens you up to Brute Force? Cant you just mitigate this risk and only allow ISAKMP and Ipsec traffic from your peers via access lists and achieve the same thing here? I know this not practical for things like multi-site DMVPN ..etc


Ryan Finneran (guest)
January 19, 2009 at 7:51 a.m. UTC

In response to Kenny, not really. The important thing to note is that pre-shared keys (PSK's) are tied directly with a peer address. So, in order for an attacker to even attempt a brute-force attack on the PSK, they must be spoofing the remote VPN endpoint, and thus has already jumped the ACL/FW hurdle.


Kenny Kant (guest)
January 30, 2009 at 6:15 a.m. UTC

Ryan can you explain more on this? Are you saying that a PSK that I define for ISAKMP also sends some type of hash that is tied to my peer address?


Afroz (guest)
December 18, 2009 at 2:05 p.m. UTC

Hi, How would the config change if this were vrf -aware ipsec ??


Andy_V (guest)
February 10, 2011 at 9:06 a.m. UTC

Hey Jeremy,

For hub and spoke IPsec configurations using DMVPN where the spoke IP address is not known as it's allocated dynamically (assuming a PPP type connection), so it's not easy to configure public keys like this and get it working.

I was wondering, is it possible to create an exportable public / private RSA key pair and import this key pair into all routers in the DMVPN topology.
Using the same method of ISAKMP authentication "rsa-encr".

Under the Crypto key pub-keychain rsa

can we specify "addressed-key 0.0.0.0"

(As with Pre-shared keys that can specify a wild card address range for any host.)

If this is possible, I could still use public keys to complete authentication without having to know the host IP address. Also, all routers will have the same key pairs (simplifying the config) but should be secure as the private key is not recoverable from the configuration (assuming it was not made exportable).

I may be way off the mark here, just trying to think of a way to use RSA keys when using a DMVPN configuration, without having to use PKI.


David Surya Wijaya (guest)
January 14, 2014 at 8:29 p.m. UTC

I already try it, but why when i verify with "#sh cry isa sa" the status said "deleted", can you explain it?

Comments have closed for this article due to its age.