IKEv2 with RSA Signatures

Currently my studies have taken me on an adventure into the wonderful world of Cisco Security. I am studying for the 300-209 (SIMOS) certification exam which is VPN technologies including DMVPN, FlexVPN, and a few other flavors of VPN.I find it interesting that so many try very hard to avoid having to implement security because its hard, or because that’s not how they did it at their old job. In this post I am going to go over the simple process of adding RSA Signatures into a DMVPN phase 3 deployment.

 

Below is the high level topology I’ve been  using for my DMVPN labs:

DMVPNTopologyAs can been seen, its a single hub deployment with two spokes (one with two routers and the other with a single router). I am utilizing two separate tunnel types to allow for the addition of another hub (Datacenter) later on down the road. For this post, addressing doesn’t matter too much as I am only going over the parts that are required for RSA Signatures to work.

Lets start with the basics of what’s already in place:

  • NTP (Time) – All routers are already configured with NTP to have synchronized time. This is important for certificates as they have Valid From and Valid To fields that are enforced.
  • DMVPN Phase 3 with Pre-Shared Keys (PSKs)
    • This includes all parts from IKEv2 Policies, all the way to tunnel protection being configured. Maybe another time I’ll go over my lab but there’s a good amount of posts about DMVPN already so not sure it’s really worth while.
  • Routing
    • Both on the FVRF (Front Door VRF) and Internal VRF
  • PKI Infrastructure
    • I setup a single Signing CA for my lab environment with auto enrollment to allow for easy certificate signing on my routers.

Now that what’s in place has been gone over, lets see if things actually working.

dmvpn1

As can be seen, from DMVPNR2 (which is the DMVPN hub for the second tunnel), both remote locations are currently using PSKs and sessions are in a healthy state.

And now the fun part,  actually authenticating the CA, getting a signed RSA signature, and utilizing it with the current DMVPN configuration! As note, any configurations done on a device will be in italics, and any variable that can be changed will be in red like the following: hostname Branch2-R1

1.Generate a RSA keypair for your router:
crypto key generate rsa modulus 2048 label Branch2-R1.dmpvn.com

2.Configure the CA trustpoint:
crypto pki trustpoint TrustedCA
    enrollment url http://10.0.0.6
    rsakeypair Branch2-R1.dmpvn.com
    fqdn Branch2-R1.dmpvn.com
    subject-name CN=Branch2-R1,O=dmpvn.com
    revocation-check crl none

3. Authenticate CA
crypto pki authenticate TrustedCACA Authenticate.jpg

4.Enroll with the CA
crypto pki enroll TrustedCA

CA Enroll

The following fields will need to be filled out:

  • Password – This is needed to revoke the certificate
  • The option to include the Serial number in the subject name (Yes or No)
  • The option to include IP address in the subject name (Yes or No)
    • If yes – it must be configured
  • Accept the request to a certificate from CA (Yes or No)

The certificate request process runs in the background and syslogs are shown when the certificate is received from the CA. The command show crypto pki certificate verbose TrustedCA can be utilized to view the certificate fingerprints for the configured CA.

5. Create a certificate map
crypto pki certificate map CMAP 10
    issuer-name co CA
For my lab environment, I simply created a certificate map that looks for the word “CA” in the issure-name field of the certificate. This can be a very specific variable to allow for strict control over what exactly is allowed for authentication.

6. Create / Modify IKEv2 profile for RSA Signature based authentication
crypto ikev2 profile FVRF-IKEv2
    identity local dn
    match certificate CMAP
    authentication local rsa-sig
    authentication remote rsa-sig
    pki trustpoint TrustedCA

It’s important to make sure you add the authentication local and remote commands for rsa-sig, without them PSKs will still be used! In addition, if the profile is being reused and had the configuration for PSKs, the command for PSKs is NOT overwritten when the rsa-sig command is issued and need to be removed with the “no authentication remote pre-share” if it is no longer desired to utilize PSKs for IKEv2 SAs.

 

And that’s it! Any new SA for DMVPN IPSEC tunnels will be created utilizing RSA. Now, the way Cisco IOS maintains security SAs, they will be active with their negotiated security settings until the SA is renegotiated (if supported) or torn down. This means the old sessions (if RSA was added to an already configured deployment) will have been setup with PSKs. The easiest way to “refresh” these SA’s is to flap the tunnel. Extreme caution should be used when pushing changes to production environments, and as always test in your lab first!

Advertisements

2 thoughts on “IKEv2 with RSA Signatures

  1. If your using certificates and a Front door VRF, how will the certificate validate before hand if the tunnel is not up yet? Will they not need to be validated? Will the routers need to be placed on the network and be able to reach the CA to install the cert before being placed in the final position. What about renewal of the CA, can you source the cert validation on another interface other then the WAN interface? Small labs are easy, rolling into an enterprise with hundreds of nodes is more interesting.

    • The FVRF has a default route that leads back to the CA in the Datacenter, so the validation process works pretty flawlessly. If there’s a build process for the routers then the certificates could be done prior to deployment “on network” but not really necessary. Another option would be to allow for PSKs at the hub along with RSA signatures. A new site is stood up with a known PSK for building the site, then the site pulls the certificate over the tunnel created with PSKs. Then the tunnel is flapped with the RSA-sig configuration and the SAs are built with RSA instead of PSK at the hub. For CRL checking, the router will just use its routing table to get to the URL for CRL doesn’t matter if its going out its WAN interfaces or if the site has another router that router.

      There’s a function within the router called auto-enroll (its been around since at least the 2600 and 7200 days) which is basically a timer before the certificate is going to expired to have a new certificate generated and rolled over onto. So if you have a 1 year certificate you could be overcautious and have auto-enroll run every 6 months to allow for enough time to identify and fix any issues seen. There is also a regenerate command to manually force the certificate creation and rollover as well.

      Scalability is the solution to any size issue, just can’t be afraid to take on a challenge. I was curious if my PKI server would survive a multiple enrollment scenario so I spun up 30 CSR1000Vs to test it but the 800 series router I was using for a hub got mad… oops.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s