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.