IKEv2 between IOS routers with certificate authentication

ios-ikev2-ike-pki

We are about to switch from pre-shared keys IKEv2 authentication to an authentication with digital certificates. Our topology remains the same, but router named SERVER has two more functions. It’s a time server and a CA server:

ikev2 SVTI 2

Let’s change our previous configurations, so that routers ROUTER-A and ROUTER-B use digital certificates, instead of pre-shared keys. Let’s make basic configurations on all routers in order to establish CA server and retrieve digital certificates. CA server:

!
hostname SERVER
!
interface f0/0
ip address 10.2.2.2 255.255.255.0
no shutdown
!
ip route 0.0.0.0 0.0.0.0 10.2.2.1
!
ntp master
!

In a production environment we would make sure that the time is accurate, but for our lab, this will do. It’s important that routers agree on a correct time, it does not matter what time it is. Now basic connectivity tasks for ROUTER-A:

!
hostname ROUTER-A
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
no shutdown
!
interface Serial5/0
ip address 1.1.1.1 255.255.255.0
no shutdown
!
ip route 0.0.0.0 0.0.0.0 1.1.1.2
!
ntp server 10.2.2.2
!

And ROUTER-B:

!
hostname ROUTER-B
!
interface FastEthernet0/0
ip address 10.2.2.1 255.255.255.0
no shutdown
!
interface Serial5/0
ip address 1.1.1.2 255.255.255.0
no shutdown
!
ip route 0.0.0.0 0.0.0.0 1.1.1.1
!
ntp server 10.2.2.2
!

PC router has the simplest configuration:

!
hostname PC
!
interface FastEthernet0/0
ip address 10.1.1.2 255.255.255.0
no shutdown
!
ip route 0.0.0.0 0.0.0.0 10.1.1.1
!

Now would be perfect time to verify our connectivity. We could verify time sync on ROUTER-A and ROUTER-B. If that’s ok, we can proceed. For example, ROUTER-A:

ROUTER_A#
ROUTER_A#show ntp ass

address         ref clock       st   when   poll reach  delay  offset   disp
*~10.2.2.2        127.127.7.1      8    118   1024   377 12.103 -59951.  0.070
* sys.peer, # selected, + candidate, – outlyer, x falseticker, ~ configured
ROUTER_A#

We can see that we are in-sync, so we may carry on.

Now let’s focus on SERVER again and generate a RSA key pair used for digital certificate that this CA will use:

cry key gen rsa gen lab CA_SERVER mod 2048

We gave this key pair a name of CA_SERVER and we want keys to be 2048 bits in length Next, we create CA authority with minimum settings:

crypto pki server CA_SERVER
issuer-name CN=Popravak Root CA
grant auto
no shutdown

We gave this CA a name and made sure it issues certificates without any intervention. Finally, we activate this CA. Before we move on, we need to make sure that the HTTP server on CA is activated, because clients will use the HTTP protocol when communicating with the CA:

!
ip http server
!

That’s very basic settings of our CA server. Now, let’s visit our friend ROUTER-A. We also need a RSA key pair on this router for the certificate that will be issued by our CA server:

cry key gen rsa gen lab ROUTER_A_CA mod 2048

Now we create the trust point. It’s a structure that describes our communication with the certificate authority. In our case:

crypto pki trustpoint ROUTER_A_CA
enrollment url http://10.2.2.2:80
subject-name CN=ROUTER_A.popravak.local, O=Popravak Inc
revocation-check none
rsakeypair ROUTER_A_CA

We gave this trust point a name, specified the URL which will be used for certificate requests and retrievals. We also stated which information we want to encode in our certificate. This is given in x509 form, and we only want the FQDN of the router (the CN, or Common Name, field) and organization name (O field). We don’t want to check if the certificate is marked as revoked by the CA, because this is a lab environment. Finally, we specify generated RSA key pair.

Now, two things need to be done. First, we must authenticate to the CA. This basically means that we connect to the CA and retrieve its certificate.

cry pki authenticate ROUTER_A_CA

We expect:

Trustpoint CA certificate accepted.

Once we obtained the CA certificate and public key, we may enroll to this CA. This is fancy way of saying that we want this CA to issue us a certificate:

cry pki enroll ROUTER_A_CA

This is what we want to see:

%PKI-6-CERTRET: Certificate received from Certificate Authority

We now have all we need to switch from pre-shared keys authentication to an authentication based on certificates. For router ROUTER-A, of course. These exact steps need to be performed on ROUTER-B as well. In addition to what we typed so far in on ROUTER-B, let’s make a summary of steps needed for obtaining a certificate:

!
cry key gen rsa gen lab ROUTER_B_CA mod 2048
!
crypto pki trustpoint ROUTER_B_CA
enrollment url http://10.2.2.2:80
subject-name CN=ROUTER_B.popravak.local, O=Popravak Inc
revocation-check none
rsakeypair ROUTER_B_CA
!
cry pki authenticate ROUTER_B_CA
!
cry pki enroll ROUTER_B_CA
!

We have reached VPN settings section. Finally 🙂

Before we change IKEv2 settings let’s take a look at our old IKEv2 profile:

crypto ikev2 profile IKEv2_PROFILE
match identity remote address 1.1.1.2 255.255.255.255
identity local address 1.1.1.1
authentication remote pre-share
authentication local pre-share
keyring local IKEv2_KEYRING

This IKEv2 profile will be triggered if remote peer identify itself with the IP address of 1.1.1.2, we will use our IP address of 1.1.1.1, both sides use pre-shared keys for authentication, and those keys are stored in specified key ring. Before we change this profile, let’s first create IKEv2 proposal. We are back on ROUTER-A.

crypto ikev2 proposal IKEv2_PROPOSAL
encryption aes-cbc-256 aes-cbc-192 3des
integrity sha512 sha256 md5
group 14 5 2

Then policy:

crypto ikev2 policy IKEv2_POLICY
proposal IKEv2_PROPOSAL

And certificate map:

crypto pki certificate map IDENTITY_MAP 10
subject-name co o = popravak inc

Finally, the IKEv2 profile:

crypto ikev2 profile IKEv2_PROFILE
match certificate IDENTITY_MAP
identity local dn
authentication remote rsa-sig
authentication local rsa-sig
pki trustpoint ROUTER_A_CA

Now this profile will be used if we receive certificate that matches whatever is specified in the certificate map. We identify our self with the certificate and both sides now uses rsa-sig type of authentication, which is authentication with digital certs. We also listed what trust point we want to use. Our certificate map is now used to trigger a profile. So, our profile will trigger if certificate map requirements are met, and we only expect the certificate to contain the name of our organization. Basically, if we receive the certificate in which the organization name is “Popravak Inc“, then we will use this certificate.

The IPsec settings on ROUTER-A remain the same:

!
crypto ipsec transform-set IPSEC_TRANSFORM1 esp-aes 256 esp-sha512-hmac
mode tunnel
!
crypto ipsec profile IPSEC_PROFILE
set transform-set IPSEC_TRANSFORM1
set ikev2-profile IKEv2_PROFILE
!

We are now ready to complete ROUTER-A configuration by configuring the tunnel interface and take care of routing:

interface Tunnel0
description === SVTI INTERFACE ===
ip address 192.168.12.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Serial5/0
tunnel mode ipsec ipv4
tunnel destination 1.1.1.2
tunnel protection ipsec profile IPSEC_PROFILE
!
ip route 10.2.2.0 255.255.255.0 Tunnel0

Up till now, we have been preparing ROUTER-A. Similar configuration is on ROUTER-B:

crypto ikev2 proposal IKEv2_PROPOSAL
encryption aes-cbc-256 aes-cbc-192 3des
integrity sha512 sha256 md5
group 14 5 2
!
crypto ikev2 policy IKEv2_POLICY
proposal IKEv2_PROPOSAL
!
crypto pki certificate map IDENTITY_MAP 10
subject-name co o = popravak inc
!
crypto ikev2 profile IKEv2_PROFILE
match certificate IDENTITY_MAP
identity local dn
authentication remote rsa-sig
authentication local rsa-sig
pki trustpoint ROUTER_B_CA
!
crypto ipsec transform-set IPSEC_TRANSFORM1 esp-aes 256 esp-sha512-hmac
mode tunnel
!
crypto ipsec profile IPSEC_PROFILE
set transform-set IPSEC_TRANSFORM1
set ikev2-profile IKEv2_PROFILE
!
interface Tunnel0
description === SVTI INTERFACE ===
ip address 192.168.12.2 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source Serial5/0
tunnel mode ipsec ipv4
tunnel destination 1.1.1.1
tunnel protection ipsec profile IPSEC_PROFILE
!
ip route 10.1.1.0 255.255.255.0 Tunnel0

When tunnels are up, we can verify that our peers indeed authenticated with digital certificates:

ROUTER_A#
ROUTER_A#show cry ikev2 sa
IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         1.1.1.1/500           1.1.1.2/500           none/none            READY
Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:14, Auth sign: RSA, Auth verify: RSA
Life/Active Time: 86400/27741 sec

IPv6 Crypto IKEv2  SA

ROUTER_A#

And we are all set! We may now test if everything is as it should be, and verification steps can be found in previous blog.

One final thought that perhaps does not have anything to do with IPSec. It is the command “no ip route-cache” under routers’ interfaces. Without this command, no traffic gets forwarded through the tunnel. This may have something to do with my IOS image on dynamips platform. I could not try this with physical boxes, but I’m pretty sure this wouldn’t be an issue there.

Thanks for reading!

 

 

Advertisements
This entry was posted in Certificates, Cisco, IOS, PKI, VPN and tagged , , , , , , , . Bookmark the permalink.

2 Responses to IKEv2 between IOS routers with certificate authentication

  1. lukeze says:

    Hello poprovak!
    Thanks for your explanation. It’s very clear.
    Do you have a configuration where one side of ikev2 tunnel perform certificate authentication and the other side authenticate the peer by preshared key?

    Kind regards

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