When dealing with another device over a virtual private network
at tunnel between two devices, it's really important
before we start negotiating Diffie-Hellman and sharing
secret information, encrypting and decrypting,
it'd be handy to make sure that that device that we're peering
with over the VPN is an authenticated device
that we think it is.
It's not some hacker who's tricked us
into building a tunnel to that device.
So we have two major options for authenticating a peer
in the world of IPsec over VPN tunnels,
and those include pre-shared keys and also WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and those include pre-shared keys and also
digital certificates.
Let's take a closer look.
So let's use this topology and imagine
that we want to have a VPN between R1 and R2
so they can protect the traffic over this leg of the journey
right here.
Now, there's a little bit of variance
if we're going to use IKE version 1 or IKE version 2.
With IKE version 1, we're going to have
something called a phase 1 tunnel and a phase 2 tunnel.
And in IKE version 2, we're going
to have the IKE version 2 security association, the IKE
version 2 tunnel and then child tunnels including WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
version 2 tunnel and then child tunnels including
the IPsec tunnel.
But regardless of which IPsec flavor
and which variant we're using right here,
the authentication methods are going
to include a pre-shared key.
And let's talk about how that would work first.
Now, that pre-shared key is just to have
R1 and R2 be able to prove who each other is.
Now the pre-shared key is just for the benefit
of getting the ball rolling.
So R1 when it first starts to negotiate the tunnels,
it would say to R2, "hey, how do you want to authenticate?"
And hopefully R2 would say, "let's use pre-shared keys."
And if R1 agrees to that at some point WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if R1 agrees to that at some point
they would actually use those pre-shared keys to verify.
So over here is Cisco 1 2 3 and over here at Cisco 3 4 or 5,
they're going to fail the authentication
and it's not going to go on any further.
So a pre-shared key just think of that
for getting the ball rolling.
So let's imagine the passwords match and they authenticate
and they get the ball rolling and they
start building the tunnels between them.
This password of Cisco 1 2 3 is called a pre-shared key.
It's only used for the initial, hey, should I be talking to you
kind of a conversation.
After the fact, if we want to have data integrity WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
After the fact, if we want to have data integrity
and encryption, we'll have specific protocols
just for that including hashing for data integrity
or hashed message authentication code
for hashing along with secret keying material.
And to keep the data private, we'll be using some encryption.
And very likely these days we're going
to be using AES 128 through 256 depending
on which flavors and the key links
supported by both of our peers.
With key links, the bigger, the more
secure but also the bigger the key, a little bit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
secure but also the bigger the key, a little bit
more processing power is required to make it all work.
So again the authentication with pre-shared keys
is just to get the ball rolling.
Now, the other option--
let me go ahead and clear some of this off--
so the other option would be RSA signatures.
And with RSA signature that implies digital certificates.
So if you see a RSA signatures for authentication
that implies that we're using digital certificates.
So we'd have R2 with an identity certificate talking
about itself, R1 would have an identity certificate talking
about itself and they would both have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
about itself and they would both have
been configured for the authentication for IPsec
to use RSA signatures.
And that means R1 is going to present its certificate which
R2 needs to trust.
So whoever issued R1 certificate that
needs to be a trusted CA from the perspective of R2
so that R2 can validate that certificate.
The same thing for R2.
When R2 sends over its identity certificate to R1,
it needs be signed by a CA that R1 trusts and that way R1
can verify the signature on that certificate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
can verify the signature on that certificate
and then proceed to trust the information in that certificate
including validity dates and very importantly,
the public key of R2 that's contained in R2's identity
certificate.
And so if they can both trust each other's certificates,
they can use the public keys involved with that
and that would allow these two devices
to authenticate, "yeah, I'm really talking to that device."
and they could proceed on with their building of the tunnels
for IPsec traffic.
And in organizations a lot of times instead of going to PKI,
the Public Key Infrastructure for these routers,
if it's just internal, they might WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if it's just internal, they might
have an internal certificate authority
that R1 and R2 currently trust or have been configured
to trust and then that internal CA can issue the identity
certificates for R1 and R2 and that would still function.
So not everything has to be out on the PKI, the Public Key
Infrastructure.
We can have internal certificate authorities
that can be trusted and also issue identity certificates
in our organization.
And that can apply not just to the routers
but also to computers and other devices that
need digital certificates issued by a CA WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
need digital certificates issued by a CA
that every device in the organization already trusts.
In this video, we've looked at two methods for authenticating
peers in an IPsec VPN tunnel, and they
include pre-shared keys, manually configuring
the password, the same on both sides
and then telling them to use it for the authentication of IPsec
or we could use RSA signatures.
But it also implies that we have digital certificates installed
on each device and as they share those certificates with each,
the other device can validate the signature on those certs.
So they can trust it and then continue on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So they can trust it and then continue on
with the building of the IPsec tunnels.
So thanks for joining me in this video.
I'll see you in the next one.
Meanwhile, I hope this has been informative for you
and I'd like to thank you for viewing.