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!