The following content is
provided under a Creative Commons license. Your support will help
MIT OpenCourseWare continue to offer high quality
educational resources for free. To make a donation or to
view additional materials from hundreds of MIT courses,
visit MIT OpenCourseWare at ocw.mit.edu. PROFESSOR: So today, we're going
to talk about Kerberos, which is a cryptographically
secure, in some ways, protocol for
authenticating computers and applications to one
another over the network. So this is now finally
going to use cryptography whereas last lecture,
we looked at just using these TCP sequence
numbers to provide security. So before we dive
into the details, I want to mention there's
two bits of administrivia that you might want to know. There's a quiz review today
7 to 9 o'clock in some room, I think 32 or 23. It's on schedule page and
the quiz is next Wednesday. And also, we want
you guys to post some idea for your
final project on Piazza by tomorrow just so
that your classmates can know what you're thinking
and help you form groups. All right, so let's talk
about Kerberos, all right? So what is the
setting that Kerberos is trying to support, here? So the model for
Kerberos, what these guys had in mind when
they were designing Athena guess 25 or
30 years ago now, is that they were
imagining they were going to have a network
with many server machines and many client machines
interacting with one another. So you could imagine, well, you
have a file server somewhere out there. You probably have a mail server
connected to the network, maybe other services-- printer. And all these are just connected
to some sort of a network rather than being processes
on a single machine. So the prelude to
Athena and Kerberos is that you just have a
time sharing machine where everything was a single
process and everyone would just log into the same system
and store their files there. So these guys wanted a
more distributed system. So this meant that you'd have
these servers on one side and you'd also have a
bunch of workstations that users would
use themselves which would run applications
and potentially connect to these servers
and store the user's files, get their mail et cetera. And the problem that
they wanted to solve was how to authenticate
the users that are using these workstations
to all these different servers in the back end without
having to trust the network to be correct, which seems
like a sensible design requirement in many ways. And I should
mention that I guess the alternative to
Kerberos at the time was these R login
commands that we're looking at in last lecture,
which seems like a bad plan. They just use IP addresses
to authenticate the users. And Kerberos was
reasonably successful. It actually still
is used at MIT. And actually, it's the basis
of Microsoft's Active Directory server. So pretty much every Microsoft
based sort of Windows Server uses Kerberos in
some form or another. But of course,
because this protocol was designed 25 or 30 years
ago, requirements change. What people assume change. People now understand
much more about security. So their version of
Kerberos that's in use today is noticeably
different in many ways from the version in the paper. And we'll look at exactly what
assumptions aren't good enough anymore today and what
did they get wrong. It's sort of inevitable
for any protocol that was the first protocol to
really use cryptography to authenticate parties over
the network in this sort of full system scale. Anyway, so that's the sort
of setting for Kerberos. And it might be
interesting to figure out what's the trust model, right? So Kerberos is going to
introduce this extra Kerberos server sitting on the side. So our third model
at some level is that the network is
untrusted like we were thinking about in last lecture. But who do we have to trust
in this Kerberos setting? So of course, one thing is
everyone-- all parties have to trust the Kerberos server. So that's an assumption
these guys were willing to make at the time
that this Kerberos server would be in charge of all
network authentication in some form or another. Do we have anyone else
that has to trust anything in the setting? For example, yeah. STUDENT: Well users should
trust their own machines. PROFESSOR: Yes, so that's
a good point, right? There's the users that
I didn't draw here. But these guys are
using some workstation. And it's actually pretty
important in Kerberos that the user trusts
their workstation. So what goes wrong if you
don't trust your workstation? Or presumably, it can
just sniff your password and do whatever you type-- you
know, LS, it tries-- runs RMX. That seems kind of unfortunate. Yeah. STUDENT: But it's
more than that though, because they could even, like,
sniff your Kerberos ticket. PROFESSOR: Yeah, exactly. Or when you log in, you
type in your password, which is even worse than the ticket. Yeah, absolutely, yeah. So this is actually a bit
of a problem with Kerberos in the sense that if you don't
trust the workstation, then you're in a bit of trouble. So if you have your
own laptop, this seems like a sensible
assumption to make. If you're using a
public computer, this is a bit more questionable. And we'll see exactly
what could go wrong. Yeah. STUDENT: You have to trust the
people administrating aren't doing anything bad with
[INAUDIBLE] servers and giving them privilege
access to one another. STUDENT: So what do you mean? So of course,
like, ISNT is going to run these machines down here. But I think the machines
themselves don't necessarily have to trust one another. So the mail server doesn't trust
the print server or the file server necessarily. STUDENT: Not to
trust, but he might be able to access
a server you're not supposed to have access to by
going through another server. PROFESSOR: Yeah,
that's true, I guess. Yeah, so if you set up
any trust relationship between these guys-- like,
if you give the mail server some back end to go access your
files just for convenience, then this could be abused, yeah. So you have to be careful
about not introducing additional sort of levels of
trust or trust relations here. All right, anything
else that matters here? Do the servers have
to trust the users in any way or the workstations? No, I guess presumably not. So this was the whole
goal that the server doesn't have to a priori
even know necessarily what all these users or
how to authenticate them or what this workstation
is doing until it can cryptographically prove that
this is a legitimate user and they should have access
to their data or whatnot. All right, so let's look
at how does Kerberos work or what's the overall
architecture, at least. So the plan that
these guys had in mind is that there would be
this Kerberos server. We have drawn it up
there but let's draw it in a slightly bigger scale. So this is the Kerberos server. And today, it's typically called
KDC-- Key Distribution Center. And there's all these users
out here somewhere and also services that you might
want to connect to. And the plan is that
the Kerberos server is going to be responsible
for storing a shared key between the Kerberos server
and every entity in the world, or in this realm at least. So if the user has some
sort of a key KC for client, than the Kerberos
server is going to remember this
key somewhere here. And similarly for the
server, the key KS is going to be known
to the service itself and to the Kerberos server
but hopefully no one else. So you can think of it as like
a generalization of passwords, right? So you know a password
and the Kerberos server knows your password
but no one else. And this is how you guys are
going to prove to each other, yeah, I'm the right guy. I know this password
and no one else does. Makes sense? And the other thing the Kerberos
server is going to have to do is, of course, keep
track of who is it that owns this key, right? So it's going to have this table
mapping some sort of a name. So this is some sort of a user. This is maybe service maybe
AFS or something like this. And the KDC is responsible for
storing the gigantic table-- well, not very large in
terms of the number of bytes, necessarily, but
one entry per entity at MIT that the Kerberos
server knows about. Makes sense? All right, and then we're
going to have sort of provide two interfaces, right? The paper is a little
fuzzy above this or it pretends like there's
really two services. But really, what's going on
is that there's two interfaces to the same machine. One of them is called Kerberos
in the paper and one of them is called TGS for
Ticket Granting Service. And really, these
are just two ways of talking to the same
thing in the back end. And the protocol is a little
different for these things. So initially, when
the user logs in, they're going to talk
to this guy over here. And they're going to
send their client name, C. So this might be
your Athena username. And the server is
going to respond to back with a ticket,
a TGS or-- well, some sort of a ticket. We'll look at the
details in a bit. And then when you want to
talk to some server down here, KS, then you're going to
talk to this TGS first and say, oh, hey,
I already logged in through the Kerberos interface. Now, I want to talk
to the server S. So you'd tell the TGS about
the server you want to talk to. And then it returns you
back some sort of a ticket for talking to the server
S. And then you can finally start talking to
the server over here by initially passing
it this ticket for S. Does this all make sense? This is the sort
of high level plan. So why do these guys
have two interfaces? Well, I guess I
wanted to actually ask a bunch of questions. Like, in the case of a
service, this service is probably going to
be stored on disk. What's going on with
this KC on the user side? Where does KC come
from in Kerberos? Yeah. STUDENT: KDMS
[INAUDIBLE] the database. PROFESSOR: Yeah, well,
the key C sits here. And that's absolutely true. It's sits on this
giant database. But it also has to
be known to the user because the user has to
prove that they are the user. Yeah. STUDENT: Is that a one way
function and then the password? PROFESSOR: Yeah,
so they actually have this sort of cute plan
where the KC is actually going to be derived by
hashing the user's password or really some sort of
key duration function. And there's several different
ones of perverse uses. But you're basically
going to take a password, transform it in some
way, and get this key KC. All right, so that seems good. Why do we need two
protocols, right? You could imagine that you just
always ask the Kerberos server for tickets directly this way. You say, well, hey,
I want a ticket for this particular
principle name. And it'll send you back a
ticket and you can decrypt it with your KC afterwards. Yeah. STUDENT: Can you
[INAUDIBLE] or ask the user to reenter their
password each time they want to [INAUDIBLE] service? PROFESSOR: Right, so the
reason for the difference between these two interfaces
is that on this interface, all the responses come back
encrypted with your key KC. And the Kerberos designers
are a little worried about keeping this KC
around for a long time. Because either you have to
ask the user to enter it, which is just
annoying for the user, or it sits around in memory. And this is basically as
good as the user's password. So if this gets disclosed,
then someone with access to KC can keep accessing the user's
files until the user maybe changes their password and
potentially even longer. We'll see about that. So this KC is a really
dangerous thing to leak. So the whole point of using
this interface first and using this interface later for
all subsequent requests is that you can
actually forget KC as soon as you decrypt this
TGS response from the Kerberos interface. And from that point on,
even if you leak it, there is a lifetime
associated with this ticket. So worst case,
someone gets access to your account for
a couple of hours, not for an unbounded
amount of time. So that's the sort
of main difference why you guys have this slightly
more complicated picture with two ways of
accessing the same thing. All right, so before we dive
into the mechanics of how these protocols actually
look like on the wire, let's talk a little bit about
this naming aspect in Kerberos, right? So at some level, you
could think of Kerberos as being a name registry, right? So it's really
responsible for mapping these cryptographic
keys onto string names. And this is the fundamental
sort of operation that Kerberos needs to provide. In fact, you'll see in the
next lecture even on the web, we need some function like this. It's implemented
differently from Kerberos but this is a fundamentally
very important thing to have in almost any
distributed system for security. So let's look at how Kerberos
actually deals with names. So in Kerberos,
the sort of system calls every entity in
this database a principal And a principal in Kerberos is
actually just a string, right? So you can actually have some
principal like, I don't know, nickolei. So that's a string. And that could be a principal
in some Kerberos realm. So it would literally
be the thing that sits in this left
column of the KDC's table. And there's also
some extra instances that the protocl supports. I could say, you know,
nikolai.extra secure or something. And I might use this
as a different entity for machines I
really care about. So maybe I will have
a different password for really secure things
and a different password for my regular account. So this is just sort
of how Kerberos-- this is what the paper
talks about with instances. So one might actually
wonder-- where do you actually see instances? Where do influences come from? So the Kerberos service
maps names to keys for you, but how do you know
which name to ask for or which name to expect when
you are talking to some machine? So I guess what I'm asking is,
what are names appear outside of the Kerberos machine. So I guess we could ask, OK,
where do user names appear? Any ideas? Yeah. STUDENT: You can ask the
MIT server for usernames presumably. PROFESSOR: Right, yeah. So you could enumerate
these things. Also, the users just
type them in when they log into a machine. So that's where it
initially comes from. Do usernames appear
anywhere else? Should they appear
anywhere else? Yeah. STUDENT: Possibly
access the [INAUDIBLE] lists on the various services. PROFESSOR: Yes, that's actually
an important point, right? The goal of Kerberos is
just to map keys to names. But it doesn't tell you what
that name should have access to. In fact, the way the
applications typically use Kerberos is that
one of these servers uses Kerberos to figure out,
OK, what string name am I talking to? So when the mail server
gets a connection from some workstation and it
get the Kerberos ticket that prove that maybe this
user is called Nikolai, then the mail server
internally now has to figure out,
OK, well, what should that guy have access to? And same for a file server. So inside of all
these servers, there's probably things like access
control lists, maybe groups, maybe other things that actually
do the authorization step. So Kerberos provides
authentication which tells you who is
this person I'm talking to. And the service itself is
responsible for implementing the authorization part where
they decide what access you should have based
on your username here. Makes sense? All right, so that's where
the user names appear. There's also other
principal names the Kerberos supports
for services, right? So services, I guess
the paper suggests, look something like this. That's rcmd.hostname. And the reason that you need a
name for one of these services is that you want to
know, for example, when I connect to a file
server, I actually want mutual authentication. It's not just the final
server learns who I am, but I, the user or
the workstation, want to be convinced that
I'm talking to the right file server and not some
fake file server that's impersonating my files. Because maybe I'll
look at the grades file and submit it
to the registrar. It would be too bad
if some file server can impersonate the response and
give me the wrong grades file all of a sudden. So this is why the
service principles also need their own name and the
workstations need to figure out what name should I expect to see
when I connect to the service. And typically, this comes
from the user at some level. So for example, if I type
SSH some machine foo, then this means that
I should be expecting a Kerberos principal
called rcmd.foo on the other end
of this connection. And if it turns out
to be someone else, this SSH client
should abort and not let me connect because then
I will be misled into talking to some other machine. That make sense? So here's one
interesting question. When can we reuse
names in Kerberos? It's like, all of you
guys have Athena accounts. And when you
graduate, could MIT, like, wipe out
your database entry and allow someone else to
register that same username? Would that be a good idea? Well, aside from the fact
that you guys want accounts. Yeah. STUDENT: Updated services
as well so that they would, like map that username
to [INAUDIBLE] permission theoretically? PROFESSOR: Yeah, because
these guys are actually just string entries somewhere
in some ACL on a file server on a mail server. And just because you wipe out
this entry in the Kerberos database doesn't mean
that this entry is gone. And they're not versioning
in any way, right? This entry could
literally say, you know, Alice has access to
some Athena locker. And if this Alice graduates
and her entry gets removed, then some new Alice
comes along, registers, in the Kerberos database. But she gets a
principal that looks identical to the old Alice. It's the same string. So all of a sudden,
the file server will give access to the new
Alice to old Alice's data. So there's a bit of
a complicated process for reclaiming principal
names in Kerberos because there's
no real connection or versioning
between these guys. So as a result, it's
actually kind of hard to reuse principal names. Once you register a
principal, you probably don't want to reuse
it very often. And same for, in some
sense, these principal names for service as well. As long as this hostname
remain some well-known service that people expect to
function in a certain way, you probably don't want
to get rid of its key even if the service goes on. Because maybe a year later,
some guy tries to connect to it and expects certain things. And if it's been reused
for a different service, that guy can impersonate things. Probably not as dramatic
or as bad, but still, you have to be careful with
reusing principal names in this kind of protocol. Makes sense? Any questions? All right, so let's look at how
the protocol itself now works. So we'll look first and
this step of the protocol where you initially get your
ticket with your password. And then we'll look at how
this TGS interface works and how it differs
then a little bit. All right, so I guess
there's this main data structure that Kerberos
uses called a ticket. And this ticket looks like this. So there's a ticket to
between a client and a server. And this guy is
basically the names of the server and
the client that we're talking about-- the IP
address of the client, some kind of timestamp, and an
expiration time for how long the stick is valid. And there's also
a key, KCS, that's going to be shared between
the client and the server. So that's what's in a ticket. And there's also this
other weird data structure that Kerberos introduces
called an authenticator. And an authenticator goes
with a particular client C. And this thing is just
the client's name, the IP address of the
client, and the time stamp when the client generated
this authenticator. And typically, both of
these things are encrypted. And authenticator is
typically scripted with the key between the
client on the server. So the authenticator
sort of has to do with a particular connection
between a client and a server. And the Kerberos
ticket itself here is typically encrypted with
the key for the service KS. So the subscript
notation denotes here encryption with
a particular key. All right, so what does this--
so using this sort of notation here, let's try to figure
out what is the protocol. By which the user initially
logs into this Kerberos and gets their TGS ticket. So as we saw here
before, right, the plan is the client is going to
send their username over to the Kerberos server
or that interface. And the response is
going to be a ticket. And what precisely
the client actually sends over-- both the username
C of the client that's issuing the request as well
as the principal name-- well, the client is also
a principal name. But the client also
sends the principal name of the service for which it
would like to get a ticket. And typically, the service name
is actually the service name of this TGS guy over here. So you get a ticket for them. But you could get a ticket
for almost any service you want in this way. And their response
is going to be this sort of interesting tuple. It's going to be your
ticket between the client and the server encrypted
just with that key KS as shown above. I guess we should
write that down with KS And also, you get to
this shared key-- key CS. And this whole thing
is encrypted with KC. So that's the wire protocol. So I guess let's try to
figure out a couple things. So first of all, how
does the Kerberos server authenticate the client here? How does it know that this
is the right user making this request? Yeah. STUDENT: It can make
sure that the ticket that it sent because it has KC. PROFESSOR: Yes, I think
that's what's going on is that the Kerberos server
again on some level actually doesn't know whether this
is the right client or not. But it thinks oh, well,
sure, it doesn't matter who is making this request. I'll just send this blob
out and the only person who should be able to
make any use of this blob is the person that knows
this key KC over here. So that's actually kind
of cool because the client doesn't have to
send their password over the network at all. So in some ways, this is
actually better than the client sending a password to
the Kerberos server because even if the
Kerberos server here was listening for
these passwords and trying to record them, it
would never get your password. Or maybe if someone was
impersonating the Kerberos server, they wouldn't get
a copy of your password. All right, yeah. STUDENT: [INAUDIBLE]
adversary wants to [INAUDIBLE] your password offline without-- PROFESSOR: Yeah, so this is
actually not a great aspect of Kerberos, in fact, right? So does everyone see
what the problem is? The problem is that the
way the client could tell if they got the
right password or not or the workstation tells
if the client supplied the right password is they
try to decrypt this ticket and they see if it works or not. And decryption is fairly cheap. This is symmetric
encryption and you can do probably
millions of decryptions a second if you try
hard on modern machines. And this means that
you can try millions of potential
passwords per second to guess what the
person's password is. And you could do this
for any person at all. You could just send
their principal to the Kerberos server. It'll very happily give you
back this response encrypted with the user's password. Then you can just try different
passwords and just see what works or what doesn't. Yeah. STUDENT: But won't the
content [INAUDIBLE] decrypted [INAUDIBLE] advantage? How can we be sure
that you directly-- PROFESSOR: Yes, this is actually
another interesting aspect where the Kerberos 4
developers didn't quite realize that the time they were
building this that they really should have been very careful
about separating encryption from authentication. So in the paper, there's
this implicit assumption that-- hopefully, that's not us. All right, sorry. So in the paper, there's
this implicit assumption that whenever you
encrypt a piece of data and you send it to someone
else, if that person can decrypt the data and it
sort of looks OK, then no, they must have
gotten the right key and the data wasn't
tampered with in flight. But it seems like a
totally bad plan now that we think of
it 30 years later. But at the time,
it wasn't so clear. So in order to do
Kerberos right, and in fact, what
Kerberos 5 does now, is they both encrypt
all the pieces of data and they also
authenticate the message by basically computing
a hash with a key. And then the result
actually tells you that, oh, that piece of data
just wasn't tampered with. It was correctly signed
with this key, et cetera. And what actually
happens in Kerberos version 4 is there
are some extra bits in this thing that was
encrypted that should all be some pattern like zeros. And typically, if you
get the key wrong, that pattern will not look
like all zeros just by chance. It's not cryptographically
guaranteed to be that. But most times, it will
not look like zeros and you will be able to decide
whether you got the correct key or not. All right, so that's
sort of the plan for how the clients
tells, I guess, whether the ticket is valid. They just try to decrypt
it and see how it works. So another interesting
question is why is this key
KCS included twice in the ticket in
some form, right? So it's included once here
and another time actually sort of implicitly in
this ticket T. Why do we have two copies
of the same key KCS? Yeah. STUDENT: The client
can't decrypt that ticket because it's encrypted
with a service key. PROFESSOR: Yeah, so it's
actually kind of cute, right? Like, there's this key
that the client can get to. But then there's another
copy of it in here. It's encrypted with KS. And the reason for this is that
the Kerberos server is actually trying to set up the
client and this other guy to talk to each other securely. So the Kerberos generates
this hopefully random key KCS and wants to give one copy
to the client and one copy to the write other server
that you want to talk to. And one thing you could
imagine doing naively is maybe the Kerberos will
just go and say, hey service, this guy wants to talk to you. Here's the key for it. But that would be
kind of unfortunate. You'd have to have the Kerberos
server call back to the service and so on. So instead, these guys have
this nice trick where they just to give the client does
blob that the client can't actually do
anything with other than give to the right service. And if the service
has the right key KS, they'll decrypt it and say, aha. Well, here's the key I should be
using to speak to this client. And that's how these two guys,
the client and the service, are going to establish a
shared key for protecting their communication. Yeah. STUDENT: So what exactly is TGS? PROFESSOR: So TGS
is-- OK, so there's sort of two sides to it. From the client's point of
view, it's just another service that you can get a ticket for. And the kinds of
operations it supports is getting more tickets. It's a Ticket Granting Service. STUDENT: Sorry, I meant what
is the ticket called TGS. PROFESSOR: Oh, yeah, sorry. This TGS is just shorthand
for this whole blob except where S is actually
the principal name of this TGS service. So you can think of it as
like, well, there's a Kerberos server, there's this
TGS service out there, and then there's the real
thing I want to get to. So you first ask
this guy to give me a ticket for some service. You could ask it to give you
directly a ticket for the file server. And this would work. But you'd need your
KC to decrypt it and then you'd need your
KC around all the time. So instead, what
you do is you get a ticket for this special
service over here. It looks just like a service
except that it happens to be provided by the same box. And then this guy will
happily give you more tickets later without having to
present your initial KC again. Makes sense? All right, other questions? Yeah. STUDENT: So [INAUDIBLE] the idea
is once you get the TGS ticket, you can just get rid of your KC? PROFESSOR: Yes,
so that's actually the cool thing about
it is that once you get this ticket-- well, this
ticket with the S being TGS, then you're going to get
rid of the password and KC. So you log into Athena
workstation and a couple of seconds into
the boot process, you already get
your ticket here. It scrubs the
password from memory. So even if someone, like,
grabs you and grab the machine and runs off, all they
got was your ticket. And OK, well, maybe they can
access your stuff for 10 hours or whatever the
ticket lifetime was, but not for longer than that. The password is gone. Yeah. So if the password's
gone, then on that picture there when Kerberos
sends a reply encrypted with KC,
how does the client-- Oh yeah, so this is the one
place you need your password. So you send this message,
you get this reply, you decrypt this, and then
you forget the password. So you can't forget
about the password before you use it for
decryption of course. STUDENT: [INAUDIBLE] PROFESSOR: Ah, no, so this is
just this interface, right? So this is the thing
you do initially. And we'll talk in a second
about how you basically also can get any ticket you want
from the second interface without needing
the initial key KC. Right, make sense? All right, so I guess
we already talked about two particular problems
that the Kerberos protocol had sort of baked into it, which
is a little unfortunate. One is that they assumed
that encryption also provides authentication
or integrity of messages. So don't do that. And Kerberos
version 5 fixes this by explicitly
authenticating messages. Another thing they sort
of had a problem with is the ability for
arbitrary clients to guess people's passwords. So any suggestions of
how we could fix this? How do you prevent
guessing attacks in a protocol like this? What could we try? Yeah. STUDENT: Some sort of salting? I'm not sure. PROFESSOR: Well, so
salting would just means that the client
has to hash the password in different ways, maybe. But it still
doesn't prevent them from trying lots of things. So maybe it'll be more
expensive to build a dictionary. Yeah. STUDENT: You could [INAUDIBLE]
derivation function? PROFESSOR: Yeah, so
another good idea is to make this hashing
process super expensive. So that might be
kind of nice, right? So if this hash function took
a second to compute like you guys did in lab two,
then OK, wow, this would be actually
really expensive to try different passwords. So that seems like
a reasonable plan. So in combination
with salting, those would be make it pretty
expensive to do password guessing attacks. Anything else? So another thing is,
yeah, challenge respond. So you could actually hear
in the initial protocol, the Kerberos server
doesn't have any idea if this was the
right client or not. But in fact, what
you could do is maybe give a little bit of a
proof that, well, you're probably the right client. So maybe you could encrypt
the current time stamp with your hash
password or something like this-- has them together. And then the Kerberos
server could just check if that's the right-- if
that matches, and if so, return you back a ticket. You probably don't want to
necessarily add more rounds but this could work. So just to precise about
what I'm sort of suggesting. OK, well, maybe you take
the current time stamp and maybe you hash the current
time stamp and the KC together. And maybe you include
the timestamp as well. And then the server could
see, well, it has your KC. It could hash the current
timestamp as well. If it gets the same
value, then yeah, it's probably the right
user requesting it. And I can send back the ticket. If not, then it wasn't
the right password at all. Question? STUDENT: [INAUDIBLE] you just do
[INAUDIBLE] if the servers see too many requests [INAUDIBLE] PROFESSOR: That's right. So the problem is that
we could write limit. But there's no
reason for the hacker to request this more than once. That hacker requests a
particular user more than once and then it gets
this encrypted blob. And then it can try decrypting
it offline as many times as it wants with
different passwords without having to re request it. So I think the whole
point of including some sort of a
challenge response thing like this in the particle
is so that the server will-- you'll have to actually
ask the server again and again to try to log in
with different passwords. And then you could rate
limit of the server and get a much better defense. Yeah. STUDENT: [INAUDIBLE] Kerberos? PROFESSOR: So I think you could
certainly replay this message so if I sent this message
now, you could probably look at that message
and send it as well and get a response back
from the Kerberos server. I guess if you're
watching the network, you could observe this
thing on the wire as well. So I think this is sort of a bit
of a stopgap measure-- improves security a bit. But certainly if you're
watching someone else's network, then you're going to see this
packet coming back regardless of what happened in this step. So coming back,
you'll see this guy and you can then
try to attack it. There's probably some
more elaborate schemes you could design
but I didn't think Kerberos 5 even
implements anything more elaborate than roughly this
plan, which seems good enough to prevent arbitrary
people from trying to break anyone's or brute
force anyone's password. Make sense? Yeah. STUDENT: So presume
that you could do authenticated [INAUDIBLE]
or something here to establish the shared key. And then you could
encrypt this thing with KC and the shared key. PROFESSOR: That's right, yeah. So if you're really
doing this right, there's all these nice
particles out there that are basically called
password authenticated key exchange particles, which is
exactly what's going on here. So if you're actually
building a system, you should basically
Google for SRP or PAKE. And these protocols
and related particles will actually do this in
a much better way where you can prove to both
parties that you established a new key and both parties
are convinced that it's the right other party
and there's no way to mount these offline
password guessing attacks on the set of network packets
that you observe and so on. So these are the
sort of protocols. And they're much more
elaborate in terms of crypto they rely on. So it's hard to explain on a
board exactly why they work. Yeah. STUDENT: [INAUDIBLE]
part of the reason they did it this
way is because they wanted to maintain the ability
of just sending the password. And protocols just allow
you to send a single thing as your authentication
[INAUDIBLE]. PROFESSOR: Well,
yeah, there's lots of sort of weird requirements
that these guys had in mind. I think they-- well,
certainly in practice, these servers could accept
both Kerberos and non Kerberos connections. And for non Kerberos
connections, you get-- like someone
connects to the mail server but they're not using
an Athena workstation. They just want to
send their password. And then the mail
client here, let's say, is going to take
your password and is going to get a ticket on
your behalf just to check it. And then it's going to
allow you to use it. So you certainly want conversion
from Kerberos from passwords into checking against Kerberos. I don't think this precludes
it because certainly Kerberos 5 deploys although
this hashes of timestamps, et cetera. STUDENT: Yeah but it's
because they wouldn't want multiple [INAUDIBLE]. PROFESSOR: Yeah, well,
I think that probably doesn't matter quite as much. You could certainly have
multiple rounds in the back end behind your library. But there's some downsides
to these particles-- probably not significant enough
to stop you from using them. Other questions? All right, I guess
the other thing I want to mention that
you should watch out for in the paper is that these
guys, in designing Kerberos 4, they picked a single
encryption scheme. And at the time,
they basically picked DES, which was a popular
encryption scheme of the time. It's a symmetric block cypher. It goes pretty fast. It was reasonably secure,
not necessarily the best, but certainly good
enough at the time. And they just baked
it into the protocol. Everything in Kerberos has
to use single DES or at least everything in
Kerberos version 4. And this was a bit problematic
because 25 years later, 30 years later
now, it's actually very cheap to brute
force DES encryption because the keys are
actually very small. They're 56 bits. So you could just search build
some custom hardware that iterates over all the possible
2 to the 56 combinations and tries them all and figures
out what someone's password is. So this is something
also you want to avoid in any protocol you design now. Kerberos version 5
actually supports multiple different
encryption schemes including AES and other things as well. So that seems like a
much better way to do it. On the other hand, MIT
actually kept supporting DES up until two years ago, which
is a little unfortunate. But now they don't. So that's good. Your principal is secure at
least from this kind of attack. All right, so does
that make sense? This is the initial
way you'd get any ticket at all in Kerberos. And typically, you'd get this
ticket from this TGS service. So now let's look at what's
going on in this TGS service. So here, the interaction
with the TGS service is going to be a
little different. On one hand, you're
going to-- as a client, you're going to have
to speak to it as if you're speaking to any
other Kerberos enabled service. So we'll see how you
authenticate yourself with a ticket to some machine. But then the response
you're going to get back is just a ticket for
some other principle that you're going to want to
communicate with like your file server. So the protocol level messages
that show up here kind of look like this. So here's your TGS service. And here's a client. The client already
got a ticket for TGS using this protocol above. So what the client is
actually going to send over is some combination
of messages that prove that this is
the right client and they're issuing a request
for some particular principle through TGS. So what the client is going
to send to TGS is this tuple. So first, it's
going to say, well, here's the service that
I want to talk to next. So this might be your mail
server or your file server. Then is going to
include the ticket. It already got 4TGS. So this is going to be TC
of TGS encrypted with KTGS. So this is just this
thing where S is TGS. And then you're going to have
to include this authenticator blob. This is this AC
thing from up there. And this thing is
going to be encrypted with a shared key between the
client and the TGS service. So this is the message that
you're going to send to TGS. It's going to look
at this message, do something with it that
we'll talk about in a second, and respond back with a
ticket for this new service S. So the response here looks
almost exactly like here. In fact, it is exactly
the same thing. It's going to be a
ticket between the client and this new service
S encrypted with KS and the shared key between the
client and this new service S encrypted-- well, now,
here's a little bit different. Instead of encrypting with KC,
which the client has probably forgotten since
then, now we're going to encrypt it with this
shared key between the client and the TGS service. Makes sense? All right, so in this-- how does
the server actually figure out what the client wants to do? Or, how does server
authenticate the client? Well, in this case, it's
going to-- TGS server actually knows its own key, KTGS. So it's going to first
decrypt this blob and look inside the ticket and
figure out what's going on. And there's all those
nice fields in the ticket. So let's just double check. Why do we need all those
fields in the ticket? So is it important to have the
server name S in the ticket? What would go wrong if you
didn't have S in there? Anything? Yeah. STUDENT: They could
potentially get authorized to use any server. PROFESSOR: Yeah, so it's
in general a good idea to be very explicit
in network protocols and to say exactly
what a message means. So in this case,
if you omit an S, you might be relying
on the fact that, well, if it's the wrong S that you're
trying to use the ticket for, then maybe you'll have a
different key over here and then it wouldn't decrypt
or something like this. But it seems like a good idea
to include it to make sure that the server that
receives this tickets decrypts and checks. Is that a ticket for
me or for someone else? Yeah. STUDENT: What does the
client get KTGS on? PROFESSOR: Ah, good question. The client has no
idea what this is. Because this is like
a super secret key. If you knew this,
you'd probably be able to break all of Kerberos. So the client has no
idea what KTGS is. STUDENT: [INAUDIBLE] PROFESSOR: Ah, yeah, yeah. And then the where
you get it from is actually-- it's the
Kerberos server itself that generates this whole blob
for you where this is actually TGS and this is KTGS over here. So you don't construct
this yourself. You just copy it over. OK So what is the client
name there important for? That should be
fairly easy, right? If you don't put the
client name in the ticket, then the server
gets this nice blob but it has no idea who
it's trying to talk to. So it has no idea
whether it should issue a ticket for my
principal or for someone else's principle, et cetera. So what's the deal
with the other fields? Why do these guys stick
an address in the ticket? This is the client's IP address. Does it matter? Yeah. STUDENT: Can they
use that address with the ticket to verify
against the [INAUDIBLE]? PROFESSOR: Sort of. Well, so I think
the general plan for why there's
addresses appearing everywhere here,
these IP addresses, is that these guys at the
time were still slightly confused and--
well, in some ways-- they were still
thinking, OK, well, we're going to rely
on IP addresses for a little bit of security. So they wanted to make sure
that if the client logged in from some IP address, then
everything else going on with that ticket happen
from that same IP address. So if you logged in
from some IP address on 18.26.4.9 or something,
then every connection you make to a file server
or to a mail server has to be from the
same IP address. Otherwise, the server should
reject your connection as being stolen by-- or
someone stole your ticket. So we're thinking,
OK, well, maybe we'll defend against ticket
theft this way. If you still a ticket,
well, but you're not using the same IP address. So it won't work. It's probably a little bit
misguided at this point but-- that sort of gets in the
way And Kerberos 5 still has it but it's largely optional. Really, you should just rely on
cryptography instead of any IP address security. So what's the point of the
time stamp and lifetime things in the ticket up there? One are those guys good for? Are they useful? Yeah. STUDENT: Preventing
replay attacks. PROFESSOR: Well,
so the syndicator is the thing that's
going to help us prevent replay attacks in a second. Because that thing gets
generated every time you do a new request. On the other hand, the
ticket just stays the same. So it's certainly not
preventing replay attacks there. Yeah. STUDENT: It prevents somebody
from stealing your ticket then using it [INAUDIBLE] PROFESSOR: Oh, sorry, yes. This just bounds the time
for which a ticket is valid, meaning that the damage
from disclosing it is hopefully reduced. So the plan is the timestamp
is roughly the time when you initially got the ticket. And a lifetime in
the ticket represents how many hours,
let's say, it's valid from that initial timestamp. So if you try to use it
too early or too late, then every server should
reject such a ticket in the Kerberos protocol. So this kind of means
that every server has to have a loosely
synchronized, clock which is a bit of a-- well,
maybe you've run into this. Like, your laptop clock is off
and you can't log into Kerberos anymore. Question? Yeah. STUDENT: You said before
that the client discards KC but they're still
keeping KCS [INAUDIBLE] the TGS. [INAUDIBLE] PROFESSOR: That's right, yeah. So the client discards
KC after logging in. But it still keeps KCS. You're exactly right. STUDENT: So if someone
steals the KCS, then they have access
to [INAUDIBLE]. PROFESSOR: Yeah, OK. So how bad is that? Like, why is it better
to disclose this KCS fof-- actually, well,
this is TGS, right? Why is it better to
disclose KCTGS than KC? Yeah. STUDENT: Someone [INAUDIBLE]
somewhere [INAUDIBLE]. PROFESSOR: It's
the kind of thing that they're both keys, though. So neither of them are
really hashed, yeah. STUDENT: You would take
KCS and you'd just steal that session between those two. But if you steal KC, you
can impersonate the client. PROFESSOR: That's right. Yeah. So I guess one
way to answer this is that KCTGS, this is actually
a new key generated every time you log in initially. And this thing is only good
because you have this ticket that goes along with it. If you lose this ticket or if
this ticket is no longer valid, then yeah, you have these
56 bits in this key. But no one is going to assume
anything from those bits. The only reason these
bits are interesting is because this ticket talks
about this KCS being valid right now. And there's a bound on it. STUDENT: Yeah, so if
they stole both of those [INAUDIBLE] be bounded. PROFESSOR: Yeah, if someone
steals both of these blogs, than they can impersonate you
or, like, log into your file server, mail server for the
lifetime of that ticket, which is a couple of
hours or 10 hours. Stealing this, there's no time
bound on that until you change your password and maybe worse. Make sense? All right, so it
seems like, yeah, all those fields are
kind of important, IP address maybe less so. And now in response, right, we
can get this ticket finally. And because we know KCTGS,
we can decrypt the response from this TGS server. And now we have a
ticket for any server we want-- a file server,
mail server, whatever it is that we finally
care about connecting to. Make sense? All right, so let's look at
how you might sort of finally use this in some
application level protocol. So suppose that maybe I'm
talking to a mail server to fetch my messages. So presumably, what my client
workstation is going to do is going to send a tickets
requesting for, I don't know, mail.po12. And it'll get back a ticket
for the principal mail.po12 or something like this. And then inside of this ticket
or inside of this response, now I have a shared
key between me and the mail server-- S is
the male server over here-- and this ticket a blob
that I can to the mail server to convince it
that I'm the right guy or anyone with this key
is the right principle. And then we can actually have
an encrypted conversation with the mail server
using this new key KCS. So what I might do as
a client is-- well, initially, I send some
message to the mail server that includes this
ticket TC mail encrypted with the key of the mail server. And then I can actually
send some message along with this request that maybe
says something like, well, delete some message-- delete 5. And I can encrypt
this with KC mail. Does that make sense? OK, so what happens in this
protocol on the mail server side? The mail server is going to
use its secret key K mail to decrypt this ticket first. And then it looks
inside there and finds two important things-- the
principal name C of who is it that's talking to it in
the first place and the key KCS that it should be
using to decrypt all the subsequent traffic
and authenticate it ideally in Kerberos 5, at least. And then you can decrypt this
message and say oh, well, yeah. User C is trying to
delete message five. So I'll run this command. Make sense? You had a question? STUDENT: Yeah, so
Kerberos initially sends the TGS ticket in KCTGS. Where's [INAUDIBLE]? PROFESSOR: So AC, those
authenticators are actually generated by the client. Note that the client
only needs KCS to generate an authenticator. So the client can make
these up any time it wants. So the general plan for
indicators or the reason to use authenticators is roughly
to prevent replay attack. So the client, or at least in
the way that the Kerberos 4 developers were
intending it, the client, every time it sends
a new request , it would generate a new
authenticator to say OK, well, this is a new request. I'm issuing it now. It's different from all
the previous requests. Go do it. And the general plan
was that the server would keep a cache of
these authenticators that were sent within the
last five minutes or so. So if it ever sees a
duplicate authenticator, it says oh, that's
a replay request. I'm going to reject it. And if it sees an
authenticator that's outside of a five
minute boundary, it doesn't have it in the cache. But it will look at the time
stamp in the authenticator and say, well, this is a
very old authenticator. I'll just reject your
request because it's too old. Send it again if
you really care. So that's the general
plan for indicators. As with many things
in Kerberos, they were slightly broken--
in Kerberos 4, at least. Because this
authenticator actually says nothing about the
message you're sending, right? It's some blob. So the way you would
use it, for example, in this mail server protocol
is-- or at least in Kerberos 4-- well, you would
generate some authenticator and you would be to
take the authenticator and you would encrypt
it with also KC mail. And the mail server would
keep track of, well, yeah, you've sent this [INAUDIBLE]
indicator before. No, you haven't. But there's nothing here that
connects the authenticator to the message you are sending. So for the first
message, this was great. But when you send
a second message, you're going to generate
a second authenticator. And someone on the
network can say, oh, yeah, I got your new authenticator. I can take your
new authenticator and splice in the
old delete message. So I'll force you to delete
the fifth message twice, even though the
second command meant to send some other operation. So Kerberos 5 gets this
right where you actually stick something in the
authenticator that relates to the command you're issuing. You could do this, of course,
but sort of took a while for people to realize
that, well, here's how you should design
a protocol correctly. Make sense? Yeah, other question. STUDENT: [INAUDIBLE] PROFESSOR: Ah, so the
client gets case email from this response. So the client, when it wants
to talk to the mail server, it's going to ask the TGS for
a ticket for the mail server. And here, S is basically this
mail server's principal name. So when it comes back,
this says S equals mail and this server key
S is equal to mail. And this KCS is
actually KC mail. So this is how the client
learns of the shared key that it has between it and the
files and the mail server here. And there's a copy of
it inside the ticket. Question back there? STUDENT: How does the
mail server get KC mail? PROFESSOR: Ah, yes. So how does the mail
server get this shared key? Like, the mail server
might have never heard of your connection before,
never heard of you. Where does KC mail come from
on the mail server side? Yeah. STUDENT: Isn't it
part of the ticket? PROFESSOR: Yeah, yeah, so
this is the cool thing. You send this ticket over to the
mail server and the mail server knows its own secret key K mail. And it uses that to decrypt the
ticket TC mail and the shared key is in there along
with the name of whoever it is that you're
sharing this key with. That's how it finds out,
oh, I'm talking to the guy and that's the shared
key we should use. Makes sense? All right, so that's
the sort of basic plan for how you use this protocol
in some actual application. There's-- well, there's a
bunch of problems with this. So Kerberos is-- it's
a nice paper to read but then there's all these
problems these guys didn't know about 30 years ago. So it's sort of inevitable
that there's problems you have to go through. So one interesting
problem in the way Kerberos 4 encrypted and
authenticated messages for applications is that
they use the same key for encrypting messages from
the client to the server as well as messages from the
server back to the client. So suppose that the client
issues, I don't know, a request to fetch a
particular message. So then I say, you know,
fetch the message 7. And I encrypt this
thing with KC mail. That seems all great. The mail server has
the shared key that's going to decrypt this message. And it's going to send me back
the body of this email message also encrypted with KC mail. Does anyone see a
problem with this? Why is this is potentially
a bad thing to do? Anyone else? Sure. STUDENT: So there's
a chapter [INAUDIBLE] they can make [INAUDIBLE] look
like some other things they want [INAUDIBLE] PROFESSOR: Yes, so
those are actually worrisome because I could send
you any email message I want. So suppose I really want
to delete some message that is sitting here in
your inbox and I don't want you to read it. I know it's maybe
message, I don't know, 23. So I'm going to send you an
email that says, delete 23. You're going to read it. You're going to fetch
it and a response is going to come from
the mail server saying, delete 23 encrypted
with this key. And so far, it's not being
sent to the mail server. But if I look at the
network at the right time and capture this packet,
I can send the packet back to the mail server. It would look like a message
saying delete 23 encrypted with the right key. And the mail server
will say, oh yeah, sure. You're trying to
delete this message. I'll do it. So this is a bit of
a problem because we are allowing an adversary
to confuse the mail server into whether our
message was generated by it or was sent to it
in the first place. So this is quite troublesome. So these are what's
typically called in cryptography and
protocol literature as reflection attacks. So you have any suggestions for
how we can avoid this problem? Yeah. STUDENT: Can't you just include
a header saying its origins? PROFESSOR: Yeah,
so typically, you want to have some very
unambiguous way to state what's going on. One way is to have a header
in every message that says, this is going from the client
to the server or from server to the client. And even better plan
in practice turns out to be just use
two separate keys. Because you might want to
have a long stream of data where you don't really have
space for this header bit. So instead, what Kerberos 5
does is every time you establish a connection with some service ,
you actually negotiate two keys instead of just one key. And the first key is going to
be used for encrypting stuff from client to server and other
from server back to the client. So that seems like a much
better way to do it in practice. Make sense? All right, so I guess
let's now talk a little bit about what happens with KDC. So the Kerberos server is
pretty important to the system. But what happens if
this KDC goes down? So how bad is it to our system. Like, in Athena,
suppose if KDC crashes, does this affect your life? Well, if you use Athena. STUDENT: Is that why
you can't log in? PROFESSOR: Yeah, so
you can't log in. I guess the other thing is
you also can't get tickets to new things as well. But kind of the cool thing
is that the KDC is largely off the critical path
for existing connection. So no data passes
through the KDC. And if you already have
a ticket for something, you can keep using
it and keep logging into some service
over the network. So in that way, it's actually
quite nicely cacheable. I guess the other
nice thing these guys do is they actually have
a way of replicating the KDC potentially. So they have one
master Kerberos server that stores the sort of primary
copy of this whole database. And then they can have
read only replicas that hold a copy of this database. They don't allow
any updates to this like registering users
or updating keys. But they do allow responding
to login and TJS requests. So this way, these backup
clones of this Kerberos database allow you to keep logging in
and keep talking to services even if the master
crashed and hopefully make it possible to upgrade
to master without breaking everything at the same time. Makes sense? Any questions? Yeah. STUDENT: How hard
is it to compromise the KDC server and [INAUDIBLE]? PROFESSOR: Well, yes,
this is a huge sort of target for any system
that runs Kerberos. Because if you
compromise this guy, you're in complete
control of the system. You can mint tickets for
any service you want, pretending to be
client you want. So this is pretty bad. So you really want to
keep this guy secure. Now, how hard is
it to compromise? Well, ideally, it's hard. And I don't know
of any instances where the MIT KDC has actually
been compromised in, I guess, 20 years or so. So it's , I think, possible to
run this reasonably security. But presumably, the things
you would worry about are just software
implementation security of the things that's listening
on these two services, right? So if there's buffer
overflows on this guys or some other vulnerability
like that, that's really bad. Or if there's an SSH server
running on the Kerberos KDC and someone guesses the root
password on that SSH server, they'll just log in and
copy the database over. So I think you really want
to be careful in minimizing the attack surface there. Maybe be very careful
writing the KDC code. Don't allow you to
log into it directly. Maybe you even worry about
physical security, et cetera. Absolutely. Luckily, this is actually
one of the few places where you have to be
super paranoid, though. Right, so the servers,
unlike in some other systems that do trust all the
machines, the servers are actually not that important. They of course store some data. But if someone compromises a
mail server or a print server, you can probably
recover reasonably well. So actually, here's an
interesting question. Like, suppose someone
compromised the mail server. What should you do to
recover from this attack? Like, if someone
stole your mail, I guess that's kind
of unfortunate. But what do you do so that the
attacker doesn't keep accessing your mail in the future? Yeah. STUDENT: [INAUDIBLE] PROFESSOR: Yeah, so
in Kerberos, there's no sort of revoke operation. But what you could
do is you could change generate a new
key for the mail server and stick it in this
database over here. And then you install a new mail
server, give it the new key, and then some attacker that
has the mail server's old key has no way of-- like, no
influence at all on this mail server now, right? On the other hand, suppose you
didn't change the mail server's key, K mail. How that is that? STUDENT: [INAUDIBLE] fine. PROFESSOR: OK, so suppose
you didn't change the mail. You, like, install
the new mail server. You patch whatever bug
that hacker exploited. But it still has
the same key K mail. And maybe it's taken a day so
all the tickets are expired. Can that hacker do anything
interesting in the system anymore? Yeah. STUDENT: [INAUDIBLE] PROFESSOR: Yeah, OK, so you give
the new mail server the old K mail. Is that bad? Yeah. STUDENT: This is-- PROFESSOR: Sure. STUDENT: [INAUDIBLE]
mail server. And [INAUDIBLE] mail
server because you can encrypt that initial ticket. PROFESSOR: Right. So K mail is actually
super important. And, OK, so you're saying you
can decrypt all the things going on to the mail server. So suppose the client now
connects to the mail server after it's been fixed up. But the attacker
still knows K mail from the last time they
compromised the system. They can now decrypt
this ticket k mail and they can now look inside the
ticket to get the session key and they can use that to
decrypt all the messages you send, all the responses
you get back, and so on. So it's pretty important
to change this key K mail. And in many ways, it's
actually even worse than just looking
at the traffic. Because if the attacker
know this key K mail, they can synthesize new
tickets for the mail server without talking to the key DC. So suppose that I
know K mail and I want to read your mail
from the mail server. I'll just make up this ticket. I'll plop down all those five
fields in the right order. I'll generate a new key. I'll encrypt it with K mail. It'll look like the real
thing generated by the KDC. And I'll just connect
to the mail server. And it'll decrypt it. It'll decrypt correctly and
then it'll think, oh, yeah, this is some particular user. And you can read all their mail
and you know the shared key and so on. So it's critically important
too that no one knows the secret key of a service. Because otherwise, not
only is the traffic to the service decryptable
and observable, but also you could impersonate
anyone to that service. So this is actually all
pretty important in Kerberos. Makes sense? Any questions? Yeah. STUDENT: So if the attacker
has to [INAUDIBLE], what's stopping him from
changing the [INAUDIBLE] key [INAUDIBLE]? PROFESSOR: Yeah, so presumably,
how you'd recover-- like, ISNT would, like, call up
the guy that runs this KDC and say, oh man, our mail
server got compromised. Why don't you go and, like,
delete this key from there and put in this new key instead? So you'd probably want to
have some out of bounds mechanism for proving that
you're really the mail server. Because we'll look
at a second on how do you change keys-- like a
password changing protocol, for example. And you can in general
change passwords in Kerberos. So if you know the
old password, you can change the user's password
to a new password here. So in order to recover, you
probably-- like the attacker, might get your key mail,
change it to something else. Someone with ISNT basically has
to go to the Accounts office and say, hey,
we're hear at ISNT. Could you please change the
password of the mail server for us? And they're going to
generate some new password the attacker doesn't know. So yeah, otherwise, if the
attacker knows this key K mail, there's nothing differentiating
the attacker from you, from the real mail
server operator. In fact, the attacker probably
changed the key so now they know the new thing
and you don't. It's like you're not on
the mail server anymore. So absolutely, you need
some out of band protocol for initially registering
principles in the database and for changing keys if you
forget your password or someone changes for you and
you lose it as well. So there's someone
at MIT or there's a group of people at
MIT that help users register for accounts and
change their passwords by, you know, you present your
MIT ID and say, oh, well, OK. Well, whatever
happened, we'll be able to change your
key for you then. Make sense? So it's pretty
important, of course, to do that right so
if the person that is allowing password resets does
the wrong thing when checking your MIT ID, you'll be able to
compromise the system as well, right? So they are sort of part
of the trusted computing base in Kerberos, right? Like, anyone that can go
and muck with the database is pretty important
for security here. All right, so let's look at
another sort of interesting use of Kerberos, right? So you could use Kerberos to try
to log into some remote machine over SSH. And the way this would work
is, of course, very similar to a mail server. You'd get a ticket
for the SSH server and you'd send the ticket
along with your SSH connection. But what if you're SSHing
into Athena dot dial-up and you don't have a Kerberos
client on your machine? You just want to log
into Athena dot dial-up with your regular password. So how would Athena dial-up
authenticate you, then, if you're just plugging into
this machine with a password? But you have no password
for Athena dot dial-up. It's on a Kerberos server. So which should
the dial-up machine do when you log into
it with a password? Yeah. STUDENT: You can
access the [INAUDIBLE]. PROFESSOR: Yeah, so
the dial-up is then going to basically play the
same protocol logging you in. So it's going to send a request. This thing, right? It's going to send a request
to the Kerberos service asking, give me a ticket for, I
don't know, this user Alice. And in response, it's going to
get back this reply encrypted with Alice's password. And then it's going to try
the password you just applied and see if it
decrypts correctly. And if it decrypts
correctly, it's going to let you log in, right? Yeah. STUDENT: You don't
even really have to send your key
to the SSH server. Because it could
relay this back-- the dot encrypted thing with KC. It could relay that back to the
user over the SSH connection. PROFESSOR: Potentially, yeah. Right, so this requires
some fancy SSH client that you might not have. But-- so yeah, absolutely right. If you want to do
this right, you probably want to have a
Kerberos client on your machine and get a ticket
yourself or maybe proxy it somehow
through the SSH server but not allow the SSH
server to have your key. That's probably a good plan. STUDENT: [INAUDIBLE]
just, the server could get through this wall [INAUDIBLE] PROFESSOR: That's right. Then you might decrypt
it and send back. OK, but in either case,
right, all we're doing here is someone is going to try
to decrypt this blob with KC. And then the server is
going to get this resolved and see if it looks right. It's going to allow you in. Seem like a good plan? So, turns out this is actually
a fairly dangerous thing to do and allows you to potentially
log into the SSH server as anyone. And the reason is
that previously, when we were talking about
a client trying to log in, the client basically
knew that it was trying to supply
a legitimate password, it was getting a reply from
the right Kerberos server, and if it can decrypt it, then
probably the password works out correctly. However, there's nothing
here in this protocol that authenticates the fact
that this reply is coming from the right Kerberos server. So if I try to log into a
machine by typing in a password and the machine sends
out this request and some response
comes back that seems to be encrypted with
the password I typed in, this response might not be
from the Kerberos server. So suppose I have some
machine I want to log into. I type a password X into it. And then the machine
sends out this response. And before the Kerberos
server can respond back with the real reply, I'll
send my own reply that looks like this real response
encrypted with my password X. And the workstation to which I
try to log in or the SSH server is going to decrypt it
with my fake password. It's going to look OK
because this response was generated by me rather than
the real Kerberos server. And you'll be able to
log in This make sense? Why does this happen? Yeah. STUDENT: [INAUDIBLE]
there's no authentication from the Kerberos
server [INAUDIBLE] PROFESSOR: Right,
yeah, so there's nothing really here that's
tying this to the real Kerberos server. So the way that
Kerberos fixes this for remotely accessible
machines like Athena dot dial-up is that
the dial-ups themselves have some sort of a secret key
that they share with the KDC. So in order to log
you in into a dial-up or to any workstation that
really cares about checking whether you are
really the right user, it's actually going
to do two things. It's going to first log you
into Kerberos like this. But then just because this
reply decrypts correctly, it's not going to trust that. It's going to try
to get a service ticket for itself using TGS. So the dial-up machine here
has its own secret key. And it logs you in
with this round one. Then it talks to TGS
saying, oh, please give me a service ticket for
my own principle, from the dial-up
principle, for this client. Then it gets the response back. And then it checks if it can
decrypt the response correctly. Because it knows the
dial-up key for this KS. And if this decrpyts,
that it knows, oh yeah, I must have talked to the
right Kerberos server. Because only the
right Kerberos server would have sent me this
second round ticket encrypted with my secret key K dial-up. So this is actually
pretty important. And typically,
Athena workstations don't do this extra step because
Athena workstations don't have any secret
key stored on them that's shared with the KDC. Why is this OK for Athena
workstations to let you log in in this one round
trip and not for dial-ups? Yeah. STUDENT: If you don't have
access to any services because the attacker
couldn't forge the ticket. PROFESSOR: That's right, yeah. So there's nothing interesting
on the dial-up machine itself-- sorry, on the
workstation itself. So workstation, whenever-- you
have root access on it anyway. So if you log into it with
a fake password, who cares? It's not like you'll be
able to do anything else outside of your workstation. Whereas on a dial-up, things
are much more interesting. It might be that you have
other processes running on the dial-up from
other login sessions. And there, the fact that you log
in with a particular Unix UID is actually pretty important. And there, they really
want to authenticate that you are the right entity. So that's why they do this sort
of 2-step process for logging into some shared
time-sharing machine. Make sense? All right, so the last
thing I want to talk about is how do we change keys. So we sort of talked about
it briefly here with the idea that the mail server's
key might get compromised. But as a user, you
probably also want to change passwords as well. Like, maybe you're thinking, oh,
that password is not so great anymore. Maybe I accidentally wrote it
on a piece of paper and someone looked at it. So you probably
want to change it. So the way this
works is actually at some level fairly
straightforward. So there's an extra interface
to this Kerberos server. In addition to Kerberos
and TGS, there's this extra service
called kpassword. And the service lets you
change your password. And the way it works is you
get a ticket for this service very much like you'd get
a ticket for the mail server or any other service. And then you send
your new password to this kpassword service
encrypted with your session key. And then if everything checks
out, your key in the database is going to be updated
to the new key. Question. STUDENT: [INAUDIBLE]
if there was, like, no [INAUDIBLE] they wanted to
have them use a [INAUDIBLE] had to go through this. PROFESSOR: That's right. OK, yeah, OK. So this is a good point. So for changing your
password, remember that we have this whole
goal that if someone steals your ticket, it shouldn't be
good enough to completely take over your account. So for this reason, the key
password service actually doesn't accept just any ticket. It accepts a ticket that you
initially get from the Kerberos service with your KC. So the way this actually works
is that inside of every ticket, in addition to all the stuff
I showed you there, there's an extra bit that tells you
which of these two things gave you the ticket. So if you get the ticket
from this Kerberos server, the bit has one. If you get the ticket from the
TGS server, the bit is zero, let's say. And then the kpassword service,
in addition to everything that any mail server or
file server would do, it also looks at the
bit on the ticket and says, well, if you got it
from Kerberos, that's good. If you got it from
TGS, that means that maybe you stole
someone's ticket and you didn't know their
password right away. So I'm not going to accept this. So this is how a key password
ensures that you can only change the password if you just
knew the password immediately prior to this. So you never actually supply
the old password to kpassword. You supply that to-- well,
you supply that in order to decrypt the response
from the Kerberos server for the kpassword
password principal. Makes sense? All right, so let's
just actually spell out the interactions with
the key password service because there'll be something
a little bit interesting there. So when you're going to
change your password, what the client is going
to do is, of course, obtain this initial
ticket from Kerberos. So it sends a message to the
Kerberos service saying here is my client ID and I want to
talk to the kpassword service. And the Kerberos server is
going to send a response back including the ticket
between the client and the kpassword service
encrypted with a key of kpass and the shared key
between KC and kpass. Makes sense? This is exactly this thing
up here encrypted with KC. Makes sense? Everyone's runs on board? And then very much like you talk
to a mail server, you take this and you send it to kpassword. You say, well, here's my
ticket-- tckpass encrypted with kpass. And in addition, you
send your new password and you encrypt this
with the key kcpass with shared key for
your interaction. I just separated these
two things out here. Make sense? So this is the thing you
send to the kpassword service with a new password encrypted
with the session key. Yeah. STUDENT: But in the [INAUDIBLE] PROFESSOR: So if the
attacker knows your password, they can change your
password-- absolutely. So it seems reasonable, right? Like, there's no other way to
tell whether it's you or not. If someone walks up to an
Athena workstation, types in your username and
password, runs password, change my password to this new
thing, they know your password? They're going to be
able to change it. So that's totally the
same in almost any system you could imagine. This is true for Gmail probably. This is true for any system
that uses passwords in general. The reason that we had to talk
to the Kerberos server instead of the TGS server here is that
if someone steals your ticket, then we don't want them to be
able to change your password. So if someone corrupts an Athena
workstation after you log in, your password is gone from
memory, the ticket remains. You could, in principle,
use the ticket to obtain more tickets for
the password changing service. But the password
changing service says that's not going
to be good enough. It's going to look
at this ticket here-- ticket between the
client and the password service. And if that was
updated through TGS, it's going to
reject your request. It's only going to accept it
if it was obtained directly from the Kerberos
service using KC. Makes sense? Question. STUDENT: So if you [INAUDIBLE]
password with the [INAUDIBLE] Athena, right? PROFESSOR: Yeah. STUDENT: So if I would
steal your private key-- PROFESSOR: Yeah,
so actually, KC is basically equivalent
to your password here. As far as the Kerberos
protocol is concerned, that don't even think
that you have a password. It thinks you have
a private key KC. If someone knows KC, that's
basically your password. So you can change
your key from KC to something else so you
don't lose this thing, yeah. Uh, yeah, question? STUDENT: [INAUDIBLE]
initial message [INAUDIBLE] from changing the [INAUDIBLE] PROFESSOR: Oh, you
can certainly get a ticket for some other
service or an attacker could drop this message
altogether or corrupt this exchange. And then you're not going
to successfully change your password. STUDENT: [INAUDIBLE] PROFESSOR: Yeah, so
the client actually knows exactly what service
it wants to talk to. So if it-- it's going
to make sure, well, there are some messages, some
parts of this protocol I'm not showing that allow the
client to make sure they actually got the
ticket for the right thing. But yeah, so the-- sorry. Question? STUDENT: [INAUDIBLE] very easy
to denial of service attack when an attacker [INAUDIBLE]
modifying the encrypted version of the new password. PROFESSOR: Yeah, so there's
actually lot of things. Because, for example, Kerberos
doesn't do authentication properly of messages--
it just does encryption-- you could
totally corrupt this blob. And-- STUDENT: [INAUDIBLE] PROFESSOR: Yeah, you
could flip it around and it'll decrypt
to something else. The service was like, oh
yeah, that's the new password, and set it. And then you're
sort of locked out. So it seems really unfortunate. And this is yet
another reason why you want separate encryption and
authentication in the protocol. There's actually an even
bigger problem here. But actually, yeah, question? STUDENT: What's the
point of having a one way function to [INAUDIBLE] your
password in KC if they're essentially [INAUDIBLE]? PROFESSOR: Basically because
KC is a 56-bit ds key and your password might
be of different lengths. And even if it's longer
than 56 bits, which is seven bites or
seven characters, you want to use all
those extra bytes too. So it's mostly just to condense
it down to a fixed width blob, yeah. But there's actually a much
more interesting problem here, which is that suppose
that I change my password and then I decide, OK,
well, I change my password. A day goes by and I'm
thinking, oh yeah, sure. I'll tell everyone what my
stupid old password was. Is this a good idea in Kerberos? Yeah. STUDENT: [INAUDIBLE]
immediately expire until the-- PROFESSOR: Yeah, OK. But someone's got to wait
for all my tickets to expire. I wait for, like, a week. And then no tickets
are good anymore. Can I give out my
old password now? Yeah. STUDENT: It might take
a while to replicate. PROFESSOR: Yeah,
suppose the replicas are all updated,
yeah, all the stuff. Yeah. STUDENT: [INAUDIBLE] if someone
saves the initial transaction [INAUDIBLE] to get,
like, your old password now that they have
your new password. PROFESSOR: Yeah,
so this is actually super worrisome
in Kerberos, which is that-- suppose
some attacker was watching all of my
previous password changes. They didn't know what my
password was or is or anything. But they're just saving these
packets very diligently. And then a month later, I
go and say, oh, my password was poodle or something
silly like this. And then they go say ah, ha, ha. I can now decrypt
this initial thing because it was encrypted
with your old KC. And I can get this KC
with pass that you shared. Then I can use this to
decrypt the new password you sent to the KDC. And even if you change
the password again, I can decrypt the
next round as well. And you can just keep going
and get the newest password. So in this particular password,
changing protocol, if you ever disclose an old
password, then someone could sort of unzip this whole
chain of encrypted messages and get your newest
password as well. This is actually very
troublesome in the design. Yeah. STUDENT: Doesn't the later
version of Kerberos [INAUDIBLE] PROFESSOR: Absolutely, yes. So there's actually
a solution to this that's not sort of fundamental. And this is
something they didn't realize in Kerberos version 4. There's actually this nice
mechanism called Diffie-Hellman that I'll just sketch
out in like one minute just so that you guys know
when to use it or et cetera. But it's basically a solution
for this kind of a problem where you want to stop this
unzipping from happening. So what happens in
the Kerberos version 5 password changing protocol
is that actually you want to establish a new secret
that will not be apparent if you happen to decrypt all
the messages on the wire. And the way this works
is-- this is like some math that you don't have
to fully understand. But the client some random value
X. And the kpassword server is going to pick some
other random value Y. And what they send to each
other are exponentiations of these values. So the client sends
G to the power X to the server and the server
sends G to the power Y back to the client. And it turns out
that mathematically, what we can do now is the
client can take G to the Y, raise it to X, and get
this value G to the XY. The server can take G to the
X, raise it to the power Y, and get G to the XY as well. They can now use this
secret value G to the XY to encrypt their
subsequent messages, including the new password. So you send the new password
encrypted with this value G to the XY, roughly speaking. But for some
mathematical reasons that we're not going
to cover right now, it turns out to be super
difficult for someone that just gets G to the X and G to the Y
by examining your packets later from figuring out
what was G to the XY. So this is something called
the discrete log problem. Yeah, question? STUDENT: But they have to
[INAUDIBLE] G at some point. PROFESSOR: Yeah, yeah. So G is some parameter
you could sort of send at the beginning of a protocol
or it could be just cooked into Kerberos. It turns out to be
relatively less important. All right, so anyway, use
Diffie-Hellman because this is called-- well, what you
should Google for if you're building a protocol like this
is this Diffie-Hellman key exchange protocol. And Kerberos 5 actually
does this correctly. But this is something
to really watch out for if you're designing any
kind of new protocol yourself. All right, so that's
it for Kerberos. Let's talk about SSL on Monday.
