from mike's house to you direct
this is very strange
um welcome to remote computer file um
what are we looking at today all right
well steve did a great video on vpns and
how to work remotely right and now we're
all doing this so i thought i'd talk
also a little bit about networking or
you know a cryptographic protocol um
that we often use over networks in one
of my previous videos i talked about
quantum computing and what kind of
effect if any that would have on
encryption and the answer really is that
it has quite a big effect on public key
cryptography but not that big an effect
on on symmetric photography you know
that's assuming we can build bigger
quantum computers sometime now
what i wanted to talk about today is a
really cool protocol that actually sees
a lot of use particularly i mean
everywhere right on lots of different
operating systems but particularly on
active directory as its main
authentication mechanism and that's
kerberos right you remember kerberos a
three-headed dog but guards i think
hades is it so it has a cool name we're
off to a good start kerberos is a really
interesting protocol because it's a way
of managing
authentication and communication over a
network like a giant enterprise level
network but it does it without really
requiring any kind of public key at all
so it does it all with symmetric
encryption so it is inherently very
robust to any kind of quantum computer
so kerberos was invented um in the 70s
at mit um and it's still maintained by
mit
but obviously in recent years you know
variants of it have appeared in things
like windows active directory i'm just
going to talk sort of in general about
kerberos i'll try and draw attention to
the differences between you know the
active directory version but mostly it's
naming differences really is what we're
concerned with one of the issues if
we're going to use um
only symmetric encryption is we have to
work out how to share keys right we
can't do key exchange because that's
public key we can't verify people using
something like certificates because
that's rsa that's public key
so what do we do well one of the ways we
can share keys is using passwords
so we could derive a key i could take my
password i could hash it in some known
way
and then we could you could do the same
thing if you were a server but knew my
password or knew the hash
and we could have a shared secret that
way
so
okay let's say we want to do this right
well now let's think about the number of
machines on a standard corporate network
right maybe there's 2 000 laptops on any
given day connect to the network and 10
000 desktops and 200 servers how many of
these passwords are we using are they
all shared are you what different
passwords different keys i mean let's
use a very simple example let's imagine
we have a network with 10 machines so
i'm just going to draw
10 machines i should have drawn fewer
machines let's you know what i can undo
this i can say five machines now if i
want to have a shared key that's let's
say different for security reasons
between all of these machines it's going
to look something like
i think that's all of them right and
then if i had another machine a 6
machine here i've got to do this and the
seventh machine this is an absolute mess
right because we can't do key exchange
so normally what you would do on the
internet is you would just talk to a
machine do a quick key exchange and then
you've got yourself
a session key for the rest of that
conversation we can't do that because
that's a public key protocol which is
vulnerable to things like quantum right
and also actually at the time i don't
think diffie-hellman existed when this
was first developed right or at least
the protocol is underpinning this
so we're not going to use public key as
a solution we're going to come up with
something different what we're going to
try and do is use the fact that we have
this server which i'm going to draw sort
of nice and big here server right a big
s on it like for superman this server we
all trust and because we all trust that
server we can use that to give us
temporary keys so in orange i'm going to
draw let's imagine that these machines
now have long term keys
with this server right so there's now
one two three four five seven keys
there's seven permanent keys probably
based off passwords right with this
server we will trust the server for now
so that's good now let's imagine that
this machine wants to talk to this
machine what we do is we ask the server
to send us a key that we can use for
that conversation and it just generates
one at random and protects it using
these encrypted channels and then we can
temporarily use this green key for our
session so the key exchange is now using
this trusted third party so this is kind
of what kerbos is about it has the
benefit but it doesn't rely on public
key but also there's an inherently
there's a really elegant way that it
authenticates you because basically you
can't talk between these two machines
unless this has given you a key to do it
which is in some sense giving you
permission to do it if this is a file
server and you want to access a file
server it's only going to work if you've
got a key from here
and if it doesn't give you one because
you're not allowed good luck getting
onto the file server right that's the
idea so it's quite a neat trick but gets
around just using symmetric and has this
authentication built in now kerbos is
obviously a little bit more complicated
than this so that's what we're going to
delve into now we're going to be on a
fictitious network now and this is me
over here now you know as you know from
my previous videos i'm very good at
drawing computers and they always look
realistic so this is my little desktop
so this is me i'm going to be a
a for alice or you know and here we have
our authentication and our ticket
granting servers now these are part of
kerberos we're going to have a big
machine over here and this is going to
have two servers in it or two services
now in the original kerberos this would
be called a key distribution center or
kdc often this role is performed by
something called a domain controller on
active directory now in here
we have two kinds of servers we have our
authentication server which i'm going to
call s and our ticket granting server
which i'm going to call t and everything
to do with authentication and connecting
to like an active directory or any other
kind of curveball setup is going to be
using these two services so the
authentication server is going to be
responsible for checking your password
essentially and making sure you actually
do have an account on that directory or
that network and this ticket granting
server is going to be responsible for
issuing you tickets which you can use to
go and access things like file servers
or printers or whatever else it is on
the network the first thing to do is to
approach the authentication server
assuming we've already had an account
created and send them a message so we're
going to send them a message which says
my name is a i would like to talk to the
ticket granting server and here is a
random number that i'm going to use to
prevent replay attacks right we're not
going to worry too much about them we're
just going to pass them back and forth
but the point is i'm sending a message
not really necessarily encrypted to this
authentication server the ima and i'd
like to talk to a ticket granting server
now
the important thing here is assuming
that a has an account it has an
established key between a and s i have a
key a s
which i can use to talk to that server
for the long term because it's based on
my password maybe i only change my
password every 12 months or whatever
right
my password's very good i don't have to
change it i should i should know this
now so i'm going to send this message
across to s now s is going to reply s is
going to send a message which is
encrypted assuming it allows me to talk
to t
it's going to send me some messages that
mean i can then talk to t right so the
first one is going to be here's a key k
a t that you can use to talk between
these two here's your nonce back again
to prevent replay attacks this is the
current time
this is the lifetime of this ticket and
you're okay to talk to the ticket
granting server so it just has a lot of
different parts to this message the
things to bear in mind are so the time
stamp and the lifetime are so that you
can't like hold on to a ticket for sort
of two years and play it again right and
you know we have the names of things in
there to make sure everyone knows who it
is they're supposed to be talking to so
the important thing in this message is
this key k a t well i'm using a t to
symbolize this as a session key between
a and t right now i don't have a long
term key with t my computer doesn't have
that this is generated on the fly by
this server now this has encrypted this
message because we can't be sending keys
over the internet if it are not
encrypted so this is going to be
encrypted
with my very well drawn curly brackets
and this is going to be encrypted using
k
a s which is of course our long term key
between a
and the authentication server what i can
do now is i can decrypt this message
using kas because that's derived off my
password and i can read this session key
and then i can use it to talk to t
the problem is that t doesn't have this
session key right this is new this is
brand new this key so it's going to send
s is going to send me some more
information
it's going to send me the same
k 80 it's going to say this is to talk
to a
and this is the lifetime of that ticket
and this is going to be encrypted with
kst so this the authentication server s
is going to use a long-term key st to
encrypt this message which i can't read
right because i don't have st
i'm a right so this is a ticket that i
can pass to t for it to use and only it
can understand so this is called a
wonderfully named ticket granting ticket
it's a ticket that's going to let me get
more tickets in the future
so i take this first message i decrypt
it and i have the session key that i
need i forward this message on to the
ticket granting server it decrypts it
and assuming it's okay
it now has the message that it needs
that's kind of cool
um
this is all the other really nice thing
about this
is but it's fire and forget so this
authentication server can very quickly
look me up in a database fire back these
two new session keys encrypted and then
it's done its work is done right it's
authenticated me that's the end of the
discussion right it doesn't need to talk
to me anymore until i log on another
time so the next thing i have to do i
want to talk to some kind of server file
server let's say called b
now we can't do that yet because we
haven't got a ticket
and in that ticket is going to be a new
session key that we can use to encrypt
that conversation so i'm going to send a
message i'm going to use my purple again
i kind of i've kind of messed up the
colors we'll do our best right um so i'm
going to send a message now to t and
that's going to be first of all this
ticket all right that ticket says i'm a
and this is my
new session key that we can use and this
has kind of been stamped as it were it's
been authenticated by the fact that it's
encrypted by kst which is the
authentication server's private key with
this t here so i'm going to send my name
is a this is a timestamp to make sure
everything is taking place at the right
time
i'd like to talk to b please and this is
some new random number that we're going
to use to prevent replay attacks and
this is all going to be encrypted using
the k-a-t session key we've just
obtained so k-a-t
so only me and t can read that right i
have to take this and i also forward on
the ticket
it decrypts a ticket and now it has
access to kat and can read my message
right and no one else can this is why
kerbos is so clever and so this ticket
grinding server is going to look at me
and it's going to look at my account and
it's going to look at what b is and work
out whether it is okay that i actually
talked to b right now assuming that's
the case
it's going to respond right it's going
to send me back let's let's go with
green for this one well i don't know
it's going to do exactly the same as the
authentication services so it's going to
produce me a new random key to be used
to talk to b right which we're going to
call k a b so we're not don't get super
confused right so k
a b and we're going to reply with the
random number as well to prevent replay
attacks this is the time stamp of the
server this is the lifetime of this
ticket and finally i would like you to
talk to b and of course this is going to
be encrypted using our key between a and
t right k a t that makes sense
everyone's in messages are encrypted
with their own session key or their own
long-term key depending on which one
you're talking to
and of course what else does it need to
send well we need b to be able to have
this kab in order to have a conversation
so it's going to have to send another
ticket to let us access b so this is
going to have k
a b right so that's our shared secret
this is i would like you to talk to a
this is the lifetime this is going to be
encrypted with a key that only t and b
have
right which is k
b t
right so that will be some password or
other other sort of um
long term key between this file server b
and our ticket granting server our key
distribution center now we need to talk
to b right so i'm going to uh i don't
know let's let's uh let's draw b over
here so this is our file server b
this is b
that's a rack server it's the worst rack
server i've ever seen b is just sitting
on the network waiting for people to
talk to it right
and um i come along it gets very excited
i'm going to forward on the ticket right
because that's the one that it can
decrypt it uses its long term key bt to
decrypt this and now it has access to
this session key it also in some sense
has a proof that i'm allowed to talk to
b because otherwise i wouldn't have been
able to produce this ticket because this
was encrypted by the ticket granting
server a bit like how a digital
signature on the internet might provide
some sort of proof of authenticity this
kind of has that role right i wouldn't
have been able to produce this ticket if
the ticket granting server hadn't
encrypted it for me to pass on so i pass
on a ticket and i also pass on a message
that says very simply my name is
a this is a current time
and i'm going to encrypt this
using k
a b which is the new key i just got
given by the ticket granting server so i
send it that i also send it the ticket
it decrypts the ticket looks at kab and
it can now understand this message and
finally it responds with my timestamp
plus one as a challenge to prove that it
can actually understand the message and
it's not an imposter and that's going to
be also encrypted with k a b so i've
used the ticket from a ticket granting
server to talk to b and now i can then
continue using that ticket for a while
and continue encryption with b right and
then we can start to send files back and
forth and things like that so let's sort
of look one more time at what what's
gone on here all right i wanted to talk
to b and i also wanted to authenticate
to this network right because this
network is let's say my university
network and i wanted to log in and all i
have at the moment is a password
so what i do is i send a message to the
authentication server that says i'm a
and i'd like to talk to the ticket
granting server it sends me back an
encrypted message
that i would not be able to read if i
didn't have my password so that's how it
authenticates me
and it also crucially sends me a ticket
that i can use to pass on to the ticket
granting server these two things both
contain a new session key that i can use
for encryption so then i talk to the
ticket granting server and the exact
same process happens again i say i'm a
i'd like to talk to b
uh b is a file server the ticket
granting server will look at this it
will look at what b is and decide okay
he is allowed to access this server so
it will send me back a message with a
new key and it will also send me back a
ticket to pass on to b so it's the exact
same process so every time i want to
talk to anything on this network i can
just go to the ticket granting server
with my ticket and say please now i have
another one for this and it will give me
new tickets so i can just go and get
tickets it's like like at a fair ground
and you know you've got a ferris wheel
and other stuff and you just go to one
desk to buy all the tickets and then you
can go to the actual rides later or
something like that it's that kind of
idea so i then can talk to b
and we have this little exchange that
makes sure that you know there's no
replay attacks and you know we're not
doing anything untoward so it's a really
neat way of just using symmetric
encryption to gain actually some pretty
good security
these tickets how long do they how long
does a ticket last so it depends on a
ticket but an authentication ticket like
the one you get sort of a ticket
granting ticket right from from s that
could last 24 hours or something like
that now tell it
where it's going where it's come from
and then these days the local network
will almost certainly