|
0:00:13
|
In our next section we are going to talk about the digital signatures
|
|
0:00:17
|
and how certificates can be used for ISAKMP authentication
|
|
0:00:21
|
for our IPSec VPNs
|
|
0:00:23
|
we are going to look at the IOS PKI server
|
|
0:00:27
|
to run as a certificate authority server
|
|
0:00:29
|
we will look at the IOS and ASA PKI client
|
|
0:00:33
|
for enrolling
|
|
0:00:35
|
with this certificate authority and then using that
|
|
0:00:39
|
for the phase I authentication
|
|
0:00:41
|
of the ISAKMP SA
|
|
0:00:43
|
Now a digital signature is a essentially an authentication mechanism
|
|
0:00:48
|
that uses a standardised x.509 certificate
|
|
0:00:52
|
where the certificate is made up of a bunch of different fields
|
|
0:00:55
|
the important ones are
|
|
0:00:57
|
the device names
|
|
0:00:59
|
which is also known as the
|
|
0:01:00
|
the common name or the CN
|
|
0:01:02
|
which is going to be things like the
|
|
0:01:04
|
the certificate authorities name
|
|
0:01:07
|
the organizational unit
|
|
0:01:09
|
the organisation, the country
|
|
0:01:11
|
type of things that you would see like as
|
|
0:01:13
|
the SNMP information
|
|
0:01:16
|
when the
|
|
0:01:18
|
the device as the SNMP identifier, that is sent to the
|
|
0:01:22
|
the SNMP management station
|
|
0:01:24
|
and also the
|
|
0:01:25
|
the alternate name which would be things like the host name
|
|
0:01:29
|
and two other fields we will see out there are important
|
|
0:01:31
|
which are the devices public key
|
|
0:01:34
|
and then the certificate authorities signature
|
|
0:01:38
|
Now these three fields inside the signature
|
|
0:01:41
|
are what we are going to use in order to perform the authentication
|
|
0:01:44
|
and then ultimately use this
|
|
0:01:46
|
for our phase I ISAKMP SA authentication
|
|
0:01:49
|
as opposed to doing the
|
|
0:01:51
|
pre shared keys which we previously looked at
|
|
0:01:53
|
Now in order to do this authentication
|
|
0:01:56
|
it would imply that our first step is that we need to get our certificate
|
|
0:02:00
|
Now the way that we do this
|
|
0:02:02
|
is by having the certificate issued by a trusted third party
|
|
0:02:06
|
that is known as the certificate authority that is the CA
|
|
0:02:10
|
where in, a real implementation typically to CA would be some sort of public
|
|
0:02:15
|
CA like may verisigned or entrust
|
|
0:02:18
|
or could be some sort of internal CA server that were running
|
|
0:02:21
|
could be like Microsoft's
|
|
0:02:23
|
Certificate Authority that runs on Windows Server
|
|
0:02:25
|
or could even be
|
|
0:02:26
|
an IOS PKI
|
|
0:02:28
|
server that we were using internally
|
|
0:02:31
|
Now the actually process of getting the certificate from the Certificate Authority
|
|
0:02:35
|
is called the enrollment process
|
|
0:02:38
|
and in order to enroll
|
|
0:02:39
|
the first thing that we need to do is generate a public and a
|
|
0:02:43
|
private key pair
|
|
0:02:45
|
so this is the same type of procedure that we use when we are generating
|
|
0:02:49
|
keys for SSH
|
|
0:02:51
|
where we would
|
|
0:02:52
|
configure a hostname
|
|
0:02:53
|
configure a domain name
|
|
0:02:55
|
and then generate the RSA key pair
|
|
0:02:58
|
Now once we done that
|
|
0:03:00
|
we send our own public key
|
|
0:03:03
|
to the certificate authority server
|
|
0:03:05
|
this is what we call the enrollment process
|
|
0:03:08
|
and the result to that coming back
|
|
0:03:10
|
is that we receive our own public key back in the certificate authority
|
|
0:03:15
|
but it is now been signed with there private key
|
|
0:03:19
|
and as we know, how the PKI infrastructure works
|
|
0:03:22
|
is that if I sign something with my private key
|
|
0:03:26
|
to encrypt it
|
|
0:03:27
|
you are able to decrypt it with my public key
|
|
0:03:31
|
or likewise if you encrypt something with my public key
|
|
0:03:33
|
I am then able to decrypt it with my private key
|
|
0:03:37
|
So the idea behind this is that the certificate authority's private key
|
|
0:03:41
|
is going to be held
|
|
0:03:42
|
privately, so no one is going to be able to see that
|
|
0:03:44
|
but the CA is going to be advertising it
|
|
0:03:47
|
itself out to everyone
|
|
0:03:49
|
using its public key
|
|
0:03:52
|
so when I send my public key to the CA, they are going to sign with their private key
|
|
0:03:56
|
the result of that coming back in
|
|
0:03:58
|
from my perspective is the certificate
|
|
0:04:01
|
Now additionally I am going to receive the Certificate Authority's public key
|
|
0:04:05
|
which is considered the CA certificate
|
|
0:04:09
|
Now since my public key
|
|
0:04:11
|
was signed with their private key
|
|
0:04:14
|
but additionally I have their public key
|
|
0:04:18
|
If I were then to decrypt my
|
|
0:04:20
|
own certificate with their public key
|
|
0:04:23
|
then the result of that is going to be the same as what the pre encrypted version
|
|
0:04:26
|
was on the Certificate Authority
|
|
0:04:29
|
So again the idea behind this is that the private key is going to be
|
|
0:04:33
|
held separately
|
|
0:04:34
|
on the Certificate Authority, no one is going to see that
|
|
0:04:36
|
the only thing is being exchanged in the clear
|
|
0:04:39
|
is the public keys
|
|
0:04:42
|
Now the ways that this is used for the ISAKMP authentication
|
|
0:04:45
|
is that first off
|
|
0:04:46
|
the IPSec peers are going to enroll with this Certificate Authority
|
|
0:04:50
|
and they are going to be granted certificates
|
|
0:04:53
|
which again means that they are going to have two pieces of information
|
|
0:04:56
|
they are going to have their own certificates
|
|
0:04:58
|
and they are going to have the CAs certificate
|
|
0:05:01
|
Now once we actually start the ISAKMP phase I authentication
|
|
0:05:05
|
first thing we are going to do is to exchange our
|
|
0:05:07
|
own certificates with each other
|
|
0:05:10
|
So if we were to have two routers, router1 and router2
|
|
0:05:13
|
router1 is going to take its own certificates, send it to router2
|
|
0:05:16
|
router2 likewise is going to send its own certificates back to router1
|
|
0:05:21
|
Now, once router2 receives router1's certificates
|
|
0:05:25
|
it is going to decrypt it
|
|
0:05:27
|
by using the Certificate Authorities certificate
|
|
0:05:31
|
in order to result in an md5 hash value
|
|
0:05:36
|
because remember when I do my enrollment with the certificate authority
|
|
0:05:40
|
I am setting them my public key
|
|
0:05:42
|
they are encrypting my public key with their private key
|
|
0:05:46
|
the result to that is the certificate
|
|
0:05:49
|
so the if the remote peer already has the Certificate Authority's
|
|
0:05:52
|
public key
|
|
0:05:54
|
they should be able to decrypt my certificate
|
|
0:05:57
|
and then come up with this hash value
|
|
0:06:00
|
Now once they do
|
|
0:06:01
|
the router is then going to generate
|
|
0:06:04
|
own hash value of the certificate
|
|
0:06:06
|
and compare it with what was decrypted
|
|
0:06:08
|
based on the certificate Authorities Public key
|
|
0:06:12
|
Now if these two values match up
|
|
0:06:14
|
the ISAKMP SA authentication is successful
|
|
0:06:17
|
because it means that we are both trusting the same Certificate Authority
|
|
0:06:21
|
and that the certificate was actually generated by them
|
|
0:06:24
|
is not some random value that I am trying to spoof locally
|
|
0:06:29
|
now the key point about this, the PKI
|
|
0:06:32
|
is that we need to make sure that the IPSec peers
|
|
0:06:35
|
agree on who the Certificate Authority is to begin with
|
|
0:06:39
|
so if I am trusting one server
|
|
0:06:41
|
and the IPSec peer is trusting different server
|
|
0:06:44
|
unless they are exchanging information on the backend
|
|
0:06:47
|
like one is a sub ordinate server of another
|
|
0:06:50
|
then ultimately the authentication is not going to be successful
|
|
0:06:54
|
so for a real deployment of this, if we wanted to get
|
|
0:06:57
|
public certificates
|
|
0:06:58
|
we could buy
|
|
0:06:59
|
from verisign, we could say for each of my end host that are running VPN client
|
|
0:07:03
|
I want to generate
|
|
0:07:04
|
a certificate
|
|
0:07:06
|
or I should say have verisigned generated certificate for them
|
|
0:07:09
|
or I could say for my internal server
|
|
0:07:12
|
I am going to host one that all my VPN clients are going to use
|
|
0:07:15
|
or all my end points of the VPN tunnels are going to use
|
|
0:07:19
|
Now we will see the configurations of both the
|
|
0:07:21
|
PKI server and the PKI client is fairly straight forward
|
|
0:07:25
|
as you long as you try this out couple of times
|
|
0:07:27
|
go to through the debugs and see what are some of the common possible problems
|
|
0:07:32
|
most of these, you can piece together by the using the documentation
|
|
0:07:36
|
Now you will see above and beyond this
|
|
0:07:38
|
configuring the server
|
|
0:07:39
|
configuring the basic enrollment on the client
|
|
0:07:42
|
everything else from an IPSec point of view is going to be identical
|
|
0:07:46
|
with the exception that under our ISAKMP policies
|
|
0:07:49
|
we are going to specify that our authentication is using our signatures
|
|
0:07:53
|
as opposed to using the pre shared keys that we saw upto this point
|
|
0:07:58
|
So similar considerations we would need to take into account
|
|
0:08:01
|
first is that if we are doing automatic enrollment
|
|
0:08:05
|
with the certificate authority
|
|
0:08:06
|
which means that client asks the ca for the certificate
|
|
0:08:10
|
the CA is going to automatically generate this and grant it
|
|
0:08:14
|
without someone having to manually go in there and say
|
|
0:08:17
|
router1 has requested the certificate
|
|
0:08:19
|
and the copy and paste it in the router1's config
|
|
0:08:22
|
So if we are not go through the manual enrollment
|
|
0:08:24
|
it means that we need to use the Simple
|
|
0:08:26
|
Certificate Enrollment Protocol or SCEP
|
|
0:08:30
|
Now SCEP runs over http
|
|
0:08:33
|
So it implies that the
|
|
0:08:35
|
peers, the IPSec peers
|
|
0:08:37
|
or the PKI clients more specifically
|
|
0:08:40
|
will have to have TCP port 80 transport
|
|
0:08:43
|
to the certificate authority
|
|
0:08:46
|
so for example, if I were configuring one of the routers on the network
|
|
0:08:50
|
lets say I were to configure
|
|
0:08:52
|
router2 as the
|
|
0:08:54
|
the PKI server
|
|
0:08:59
|
and I want it, lets say the test PC
|
|
0:09:02
|
with its VPN client
|
|
0:09:05
|
if I wanted to enroll with the PKI server
|
|
0:09:09
|
it implies that I would need TCP port 80 reachability
|
|
0:09:13
|
from the client to the server and then back
|
|
0:09:16
|
So if there is any other type of complex filtering going out in the network
|
|
0:09:19
|
we would need to make sure that we
|
|
0:09:22
|
meet this basic requirement, that the underlying transport is there
|
|
0:09:26
|
The next thing that is a common problem for this
|
|
0:09:29
|
is that the Certificates themselves
|
|
0:09:32
|
have a finite valid life time
|
|
0:09:34
|
which means there is going to be some
|
|
0:09:36
|
time index where the certificates starts being valid
|
|
0:09:39
|
and then some time index that the certificates stops being valid
|
|
0:09:43
|
So kind of similar to like how a key chain authentication works for our routing protocols
|
|
0:09:48
|
where I say from January 1st 2000
|
|
0:09:51
|
to December 31st 2000
|
|
0:09:54
|
this is going to be the valid time for the key chain, or in this case the certificate
|
|
0:09:59
|
Now since this is essentially going to be time based
|
|
0:10:02
|
then it implies that the PKI client
|
|
0:10:05
|
and the PKI server must have clocks that agree with each other
|
|
0:10:09
|
and the easiest way to do it is just to run network time protocol in the network
|
|
0:10:14
|
So again if we were to configure router2 as the PKI server
|
|
0:10:18
|
would also be a good idea to configured as NTP server
|
|
0:10:22
|
then for the any of the PKI clients
|
|
0:10:24
|
lets say router3 is trying to involve
|
|
0:10:27
|
we would configure router3 as in
|
|
0:10:29
|
NTP client, as well as a PKI client of router2
|
|
0:10:34
|
So this ensures that when we actually generate the certificates
|
|
0:10:37
|
and then we go to use them
|
|
0:10:39
|
that they should be within there valid life times
|
|
0:10:44
|
Now additionally we will see for the configuration on ASA
|
|
0:10:48
|
that we have the flexibility to use different certificate authorities
|
|
0:10:51
|
for different tunnels
|
|
0:10:53
|
by applying a trust point
|
|
0:10:56
|
on to the particular tunnel group
|
|
0:10:59
|
So with the IOS configuration, if we have only one trust point configured globally
|
|
0:11:04
|
then this is automatically going to be inherited by all tunnels
|
|
0:11:07
|
but in the case of the ASA, it will not do that by default
|
|
0:11:11
|
So this implies that the trust point
|
|
0:11:13
|
must be manually called from the tunnel group
|
|
0:11:16
|
even if we are only defining one of them
|
|
0:11:22
|
So for this examples what we are going to do
|
|
0:11:25
|
is configure router2 as their PKI server
|
|
0:11:28
|
and we have two separate IPSec tunnel that are configured
|
|
0:11:33
|
one tunnel is pre configured between router1 and router3
|
|
0:11:37
|
to protect the traffic from the 192.168 network
|
|
0:11:41
|
upto the 172.16 network
|
|
0:11:44
|
and we have a second tunnel that is going from router3
|
|
0:11:46
|
to ASA2
|
|
0:11:48
|
that is protecting traffic from the 10 network upto the 172.16 network
|
|
0:11:54
|
Now at this point, just like we saw with our previous examples
|
|
0:11:57
|
I have this configured with
|
|
0:11:58
|
pre shared key authentication
|
|
0:12:01
|
So if you are implementing
|
|
0:12:02
|
the PKI and the certificate authority
|
|
0:12:05
|
with IPSec
|
|
0:12:06
|
it would be a good idea just to make sure that the basic
|
|
0:12:09
|
IPSec tunnel works with pre shared keys
|
|
0:12:13
|
then once we are verified, that the tunnel is working
|
|
0:12:16
|
then we can change over to the certificate authority support
|
|
0:12:20
|
because again when we are doing the troubleshooting with this
|
|
0:12:23
|
under the so many possible variables that can come into account with the IPSec configurations
|
|
0:12:27
|
and if I am having a problem getting the tunnel up
|
|
0:12:30
|
I want to be sure that its related
|
|
0:12:32
|
to either my certificate authority configuration
|
|
0:12:34
|
or something else unrelated
|
|
0:12:37
|
before I try to piece all of the configuration together all at once
|
|
0:12:41
|
So if I know that the tunnel works with pre shared keys
|
|
0:12:43
|
then I configure CA support and the tunnel is broken
|
|
0:12:47
|
then I know 100% for sure that there is something wrong with the CA configuration
|
|
0:12:51
|
not the underlying IPSec tunnel
|
|
0:12:56
|
So again router2 is going to be the PKI server
|
|
0:12:59
|
which means that the first thing we need to do is configure as the server
|
|
0:13:03
|
configure router1
|
|
0:13:05
|
3 and the ASA
|
|
0:13:07
|
as both NTP clients
|
|
0:13:10
|
and as PKI clients
|
|
0:13:12
|
because again we want to make sure that all of the devices are in the network
|
|
0:13:16
|
agree on what the time is
|
|
0:13:20
|
Now for both of these configurations, both the PKI servers and the PKI client
|
|
0:13:25
|
you want to make sure that you know
|
|
0:13:27
|
where this is located in the documentation
|
|
0:13:30
|
So if we take a look at the
|
|
0:13:33
|
the main documentation page
|
|
0:13:36
|
this is going to be for the routers, this going to be under products
|
|
0:13:39
|
and IOS
|
|
0:13:42
|
regular IOS
|
|
0:13:45
|
12.4, 12.4T
|
|
0:13:47
|
configuration guides
|
|
0:13:51
|
then similar to our other IPSec documentation its under security
|
|
0:13:55
|
for secure connectivity
|
|
0:14:00
|
then this is under the Public Key Infrastructure for PKI
|
|
0:14:05
|
this is going to show us both of the configurations
|
|
0:14:08
|
the PKI server
|
|
0:14:11
|
and the PKI client
|
|
0:14:14
|
where the PKI client is going to be
|
|
0:14:19
|
configuring certificate enrollment
|
|
0:14:22
|
so this is the client configuration here
|
|
0:14:25
|
and this the server configuration here
|
|
0:14:30
|
for the ASA, under the 8.0 configs
|
|
0:14:34
|
under configuring VPN
|
|
0:14:38
|
we have configuring certificates
|
|
0:14:41
|
Now we will see if you understand the syntax for the
|
|
0:14:43
|
client configuration on the IOS
|
|
0:14:45
|
or the ASA
|
|
0:14:47
|
you are going to understand
|
|
0:14:48
|
the other one vice-versa, so if you understand how IOS works
|
|
0:14:52
|
you pretty much inherently going to understand how the ASA works
|
|
0:14:55
|
So there is not that many differences in the syntax
|
|
0:15:00
|
Now for the server configuration
|
|
0:15:02
|
it is essentially functional PKI server
|
|
0:15:06
|
where we can get really detailed in here to say
|
|
0:15:09
|
I have some sort of offline
|
|
0:15:11
|
file storage that I am going to do for the certificates
|
|
0:15:14
|
we could have multiple servers that are showing the same database
|
|
0:15:18
|
we could have subordinate servers, to configure a hierarchy between them
|
|
0:15:23
|
but for the
|
|
0:15:24
|
the most basic configuration
|
|
0:15:27
|
essentially the only thing that we need to do
|
|
0:15:30
|
is to generate the keys
|
|
0:15:33
|
and to tell the server, are we going to automatically grant
|
|
0:15:37
|
the certificates
|
|
0:15:38
|
or are we manually going to grant them
|
|
0:15:41
|
Now if we are going to automatically grant them
|
|
0:15:43
|
with the Simple Certificate Enrollment Protocol or the SCEP
|
|
0:15:48
|
again this uses
|
|
0:15:50
|
http for the enrollment
|
|
0:15:53
|
so it implies that if we are using SCEP
|
|
0:15:56
|
that we have to configure the http server
|
