WEBVTT

1
00:00.000 --> 00:00.960 align:middle line:84%


2
00:00.960 --> 00:04.200 align:middle line:90%
When dealing with another device
over a virtual private network

3
00:04.200 --> 00:06.670 align:middle line:90%
at tunnel between two
devices, it's really important

4
00:06.670 --> 00:09.450 align:middle line:90%
before we start negotiating
Diffie-Hellman and sharing

5
00:09.450 --> 00:12.000 align:middle line:90%
secret information,
encrypting and decrypting,

6
00:12.000 --> 00:14.730 align:middle line:90%
it'd be handy to make sure that
that device that we're peering

7
00:14.730 --> 00:18.030 align:middle line:90%
with over the VPN is
an authenticated device

8
00:18.030 --> 00:19.000 align:middle line:84%
that we think it is.

9
00:19.000 --> 00:20.790 align:middle line:90%
It's not some hacker
who's tricked us

10
00:20.790 --> 00:23.210 align:middle line:90%
into building a
tunnel to that device.

11
00:23.210 --> 00:25.860 align:middle line:90%
So we have two major options
for authenticating a peer

12
00:25.860 --> 00:28.440 align:middle line:90%
in the world of IPsec
over VPN tunnels,

13
00:28.440 --> 00:31.470 align:middle line:90%
and those include
pre-shared keys and also
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:28.440 --> 00:31.470 align:middle line:90%
and those include
pre-shared keys and also

14
00:31.470 --> 00:32.970 align:middle line:84%
digital certificates.

15
00:32.970 --> 00:34.390 align:middle line:84%
Let's take a closer look.

16
00:34.390 --> 00:36.150 align:middle line:90%
So let's use this
topology and imagine

17
00:36.150 --> 00:39.720 align:middle line:90%
that we want to have a
VPN between R1 and R2

18
00:39.720 --> 00:42.330 align:middle line:90%
so they can protect the traffic
over this leg of the journey

19
00:42.330 --> 00:43.150 align:middle line:84%
right here.

20
00:43.150 --> 00:45.060 align:middle line:90%
Now, there's a little
bit of variance

21
00:45.060 --> 00:49.530 align:middle line:90%
if we're going to use IKE
version 1 or IKE version 2.

22
00:49.530 --> 00:51.320 align:middle line:90%
With IKE version 1,
we're going to have

23
00:51.320 --> 00:54.175 align:middle line:90%
something called a phase 1
tunnel and a phase 2 tunnel.

24
00:54.175 --> 00:55.550 align:middle line:90%
And in IKE version
2, we're going

25
00:55.550 --> 00:58.110 align:middle line:90%
to have the IKE version 2
security association, the IKE

26
00:58.110 --> 01:00.870 align:middle line:90%
version 2 tunnel and then
child tunnels including
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
00:58.110 --> 01:00.870 align:middle line:90%
version 2 tunnel and then
child tunnels including

27
01:00.870 --> 01:02.250 align:middle line:84%
the IPsec tunnel.

28
01:02.250 --> 01:04.110 align:middle line:90%
But regardless of
which IPsec flavor

29
01:04.110 --> 01:05.820 align:middle line:90%
and which variant
we're using right here,

30
01:05.820 --> 01:07.320 align:middle line:90%
the authentication
methods are going

31
01:07.320 --> 01:09.112 align:middle line:84%
to include a pre-shared key.

32
01:09.112 --> 01:11.070 align:middle line:90%
And let's talk about how
that would work first.

33
01:11.070 --> 01:12.810 align:middle line:90%
Now, that pre-shared
key is just to have

34
01:12.810 --> 01:16.773 align:middle line:90%
R1 and R2 be able to
prove who each other is.

35
01:16.773 --> 01:18.690 align:middle line:90%
Now the pre-shared key
is just for the benefit

36
01:18.690 --> 01:20.280 align:middle line:84%
of getting the ball rolling.

37
01:20.280 --> 01:23.580 align:middle line:90%
So R1 when it first starts
to negotiate the tunnels,

38
01:23.580 --> 01:27.090 align:middle line:90%
it would say to R2, "hey, how
do you want to authenticate?"

39
01:27.090 --> 01:29.620 align:middle line:90%
And hopefully R2 would say,
"let's use pre-shared keys."

40
01:29.620 --> 01:31.237 align:middle line:90%
And if R1 agrees to
that at some point
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
01:29.620 --> 01:31.237 align:middle line:90%
And if R1 agrees to
that at some point

41
01:31.237 --> 01:33.570 align:middle line:90%
they would actually use those
pre-shared keys to verify.

42
01:33.570 --> 01:39.703 align:middle line:90%
So over here is Cisco 1 2 3 and
over here at Cisco 3 4 or 5,

43
01:39.703 --> 01:41.370 align:middle line:90%
they're going to fail
the authentication

44
01:41.370 --> 01:43.267 align:middle line:90%
and it's not going
to go on any further.

45
01:43.267 --> 01:44.850 align:middle line:90%
So a pre-shared key
just think of that

46
01:44.850 --> 01:46.270 align:middle line:84%
for getting the ball rolling.

47
01:46.270 --> 01:47.985 align:middle line:90%
So let's imagine the passwords
match and they authenticate

48
01:47.985 --> 01:49.568 align:middle line:90%
and they get the
ball rolling and they

49
01:49.568 --> 01:51.610 align:middle line:90%
start building the
tunnels between them.

50
01:51.610 --> 01:54.920 align:middle line:90%
This password of Cisco 1 2 3
is called a pre-shared key.

51
01:54.920 --> 01:58.380 align:middle line:90%
It's only used for the initial,
hey, should I be talking to you

52
01:58.380 --> 01:59.370 align:middle line:84%
kind of a conversation.

53
01:59.370 --> 02:02.280 align:middle line:90%
After the fact, if we want
to have data integrity
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
01:59.370 --> 02:02.280 align:middle line:90%
After the fact, if we want
to have data integrity

54
02:02.280 --> 02:04.860 align:middle line:90%
and encryption, we'll
have specific protocols

55
02:04.860 --> 02:08.100 align:middle line:90%
just for that including
hashing for data integrity

56
02:08.100 --> 02:10.350 align:middle line:90%
or hashed message
authentication code

57
02:10.350 --> 02:13.748 align:middle line:90%
for hashing along with
secret keying material.

58
02:13.748 --> 02:16.290 align:middle line:90%
And to keep the data private,
we'll be using some encryption.

59
02:16.290 --> 02:17.873 align:middle line:90%
And very likely these
days we're going

60
02:17.873 --> 02:22.380 align:middle line:90%
to be using AES 128
through 256 depending

61
02:22.380 --> 02:24.110 align:middle line:90%
on which flavors
and the key links

62
02:24.110 --> 02:26.160 align:middle line:84%
supported by both of our peers.

63
02:26.160 --> 02:28.650 align:middle line:90%
With key links, the
bigger, the more

64
02:28.650 --> 02:31.620 align:middle line:90%
secure but also the bigger
the key, a little bit
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

64
02:28.650 --> 02:31.620 align:middle line:90%
secure but also the bigger
the key, a little bit

65
02:31.620 --> 02:34.660 align:middle line:90%
more processing power is
required to make it all work.

66
02:34.660 --> 02:36.660 align:middle line:90%
So again the authentication
with pre-shared keys

67
02:36.660 --> 02:38.010 align:middle line:84%
is just to get the ball rolling.

68
02:38.010 --> 02:39.350 align:middle line:84%
Now, the other option--

69
02:39.350 --> 02:41.310 align:middle line:90%
let me go ahead and
clear some of this off--

70
02:41.310 --> 02:44.890 align:middle line:90%
so the other option
would be RSA signatures.

71
02:44.890 --> 02:47.615 align:middle line:90%
And with RSA signature that
implies digital certificates.

72
02:47.615 --> 02:50.640 align:middle line:90%
So if you see a RSA
signatures for authentication

73
02:50.640 --> 02:52.770 align:middle line:90%
that implies that we're
using digital certificates.

74
02:52.770 --> 02:56.130 align:middle line:90%
So we'd have R2 with an
identity certificate talking

75
02:56.130 --> 02:59.100 align:middle line:90%
about itself, R1 would have an
identity certificate talking

76
02:59.100 --> 03:00.750 align:middle line:90%
about itself and
they would both have
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

76
02:59.100 --> 03:00.750 align:middle line:90%
about itself and
they would both have

77
03:00.750 --> 03:04.500 align:middle line:90%
been configured for the
authentication for IPsec

78
03:04.500 --> 03:06.715 align:middle line:84%
to use RSA signatures.

79
03:06.715 --> 03:10.320 align:middle line:90%
And that means R1 is going to
present its certificate which

80
03:10.320 --> 03:11.640 align:middle line:84%
R2 needs to trust.

81
03:11.640 --> 03:14.520 align:middle line:90%
So whoever issued
R1 certificate that

82
03:14.520 --> 03:17.520 align:middle line:90%
needs to be a trusted CA
from the perspective of R2

83
03:17.520 --> 03:20.020 align:middle line:90%
so that R2 can validate
that certificate.

84
03:20.020 --> 03:20.940 align:middle line:84%
The same thing for R2.

85
03:20.940 --> 03:24.340 align:middle line:90%
When R2 sends over its
identity certificate to R1,

86
03:24.340 --> 03:28.080 align:middle line:90%
it needs be signed by a CA
that R1 trusts and that way R1

87
03:28.080 --> 03:30.960 align:middle line:90%
can verify the signature
on that certificate
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

87
03:28.080 --> 03:30.960 align:middle line:90%
can verify the signature
on that certificate

88
03:30.960 --> 03:33.840 align:middle line:90%
and then proceed to trust the
information in that certificate

89
03:33.840 --> 03:36.670 align:middle line:90%
including validity dates
and very importantly,

90
03:36.670 --> 03:40.320 align:middle line:90%
the public key of R2 that's
contained in R2's identity

91
03:40.320 --> 03:41.160 align:middle line:84%
certificate.

92
03:41.160 --> 03:43.792 align:middle line:90%
And so if they can both trust
each other's certificates,

93
03:43.792 --> 03:45.750 align:middle line:90%
they can use the public
keys involved with that

94
03:45.750 --> 03:47.160 align:middle line:90%
and that would allow
these two devices

95
03:47.160 --> 03:49.618 align:middle line:90%
to authenticate, "yeah, I'm
really talking to that device."

96
03:49.618 --> 03:52.260 align:middle line:90%
and they could proceed on with
their building of the tunnels

97
03:52.260 --> 03:54.020 align:middle line:84%
for IPsec traffic.

98
03:54.020 --> 03:57.300 align:middle line:90%
And in organizations a lot of
times instead of going to PKI,

99
03:57.300 --> 03:59.860 align:middle line:90%
the Public Key Infrastructure
for these routers,

100
03:59.860 --> 04:01.530 align:middle line:90%
if it's just
internal, they might
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

100
03:59.860 --> 04:01.530 align:middle line:90%
if it's just
internal, they might

101
04:01.530 --> 04:03.570 align:middle line:90%
have an internal
certificate authority

102
04:03.570 --> 04:07.410 align:middle line:90%
that R1 and R2 currently
trust or have been configured

103
04:07.410 --> 04:10.890 align:middle line:90%
to trust and then that internal
CA can issue the identity

104
04:10.890 --> 04:13.963 align:middle line:90%
certificates for R1 and R2
and that would still function.

105
04:13.963 --> 04:16.380 align:middle line:90%
So not everything has to be
out on the PKI, the Public Key

106
04:16.380 --> 04:17.310 align:middle line:84%
Infrastructure.

107
04:17.310 --> 04:19.829 align:middle line:90%
We can have internal
certificate authorities

108
04:19.829 --> 04:22.980 align:middle line:90%
that can be trusted and also
issue identity certificates

109
04:22.980 --> 04:23.850 align:middle line:84%
in our organization.

110
04:23.850 --> 04:25.600 align:middle line:90%
And that can apply not
just to the routers

111
04:25.600 --> 04:27.990 align:middle line:90%
but also to computers
and other devices that

112
04:27.990 --> 04:30.870 align:middle line:90%
need digital certificates
issued by a CA
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

112
04:27.990 --> 04:30.870 align:middle line:90%
need digital certificates
issued by a CA

113
04:30.870 --> 04:33.878 align:middle line:90%
that every device in the
organization already trusts.

114
04:33.878 --> 04:36.420 align:middle line:90%
In this video, we've looked at
two methods for authenticating

115
04:36.420 --> 04:39.000 align:middle line:90%
peers in an IPsec
VPN tunnel, and they

116
04:39.000 --> 04:41.610 align:middle line:90%
include pre-shared keys,
manually configuring

117
04:41.610 --> 04:43.710 align:middle line:90%
the password, the
same on both sides

118
04:43.710 --> 04:46.900 align:middle line:90%
and then telling them to use it
for the authentication of IPsec

119
04:46.900 --> 04:49.260 align:middle line:84%
or we could use RSA signatures.

120
04:49.260 --> 04:52.560 align:middle line:90%
But it also implies that we have
digital certificates installed

121
04:52.560 --> 04:55.980 align:middle line:90%
on each device and as they share
those certificates with each,

122
04:55.980 --> 04:59.960 align:middle line:90%
the other device can validate
the signature on those certs.

123
04:59.960 --> 05:01.850 align:middle line:90%
So they can trust it
and then continue on
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

123
04:59.960 --> 05:01.850 align:middle line:90%
So they can trust it
and then continue on

124
05:01.850 --> 05:03.985 align:middle line:90%
with the building of
the IPsec tunnels.

125
05:03.985 --> 05:05.610 align:middle line:90%
So thanks for joining
me in this video.

126
05:05.610 --> 05:06.900 align:middle line:84%
I'll see you in the next one.

127
05:06.900 --> 05:09.410 align:middle line:90%
Meanwhile, I hope this has
been informative for you

128
05:09.410 --> 05:12.670 align:middle line:90%
and I'd like to thank
you for viewing.