If you've worked in a number
of enterprise environments, then you're probably familiar
with the term Kerberos. Kerberos is a network
authentication protocol. It's one where you
can authenticate one with the system, and
then you're trusted by everything that's in
that entire infrastructure. The idea is that you're
being able to authenticate with a central
server, and then also authenticate with
everything else. But not only are you
authenticating yourself to the server, you
can also be assured that you are talking
directly to the server. So there's mutual
authentication here. And what that does
is help anybody who might be in the middle
of this conversation who wants to inject particular
pieces of information. Or maybe they'd like to replay
this information later on; they would not be
able to do that. This is a standard that was
created back in the 1980s, so it's been around
for quite some time. It was created at MIT. And there's an RFC for this. RFC 4120 gives a lot of details
about the Kerberos standard. Microsoft started using
Kerberos with Windows 2000, and they use Kerberos 5.0
which is an open standard. This makes it very easy, also,
for other operating systems to be able to authenticate
into the same Kerberos-based environments. So even if you have a
Linux or you have Mac OSX, it doesn't matter. Everybody ideally can talk back
to the central Kerberos system and be able to authenticate
onto the network. Kerberos or Cerberus is
a mythological creature. This is the three-headed
dog of the underworld. Its job was to keep people from
escaping across the River Styx. And a three-headed dog would
certainly do that for me. But it had three
heads for a reason. There's a reason we
call this Kerberos. That's because there are
three components to this. One, is that you have a
key distribution center. You'll often see this
referred to as a KDC. This is something
that is vouching for the user's identity. We're providing
user name, password, and other authentication
information, and we're getting tickets
that we can use later on. We're going to go
through that process. This runs either on
tcp/port88 most commonly. You could see it on
udp/port88, as well. The second head of
the three-headed dog is the authentication service,
which does exactly that. It authenticates us and provides
us access to the network. And the last head is the
ticket-granting service that provides us with tickets. In Kerberos, tickets is
a pretty important thing. You're given tickets
that will gain you access to resources
on the network. Before you can gain
access to resources, you first have to
authenticate yourself with the key
distribution center. This is the
authentication service that's going to provide
us with everything we need to gain access
to other resources. And this is a 2-step process. We'll start down here with
our device, our client, our principle we call it. And it's going to talk directly
to the key distribution center up here. There's an application
server down here that we would like to
access, but we're not able to do that yet until we
complete this authentication process. So we're going to send a
login request from our device to the key distribution center. And we're going to send
this encrypted with the date and time on the local computer. And we're going to use our
password hash as the key. Now we don't send the hash to
the key distribution center. This authentication service
that's up here already has our password. So it knows what it should be
expecting to use as that key, and the next process is going
to take advantage of that. But it's important to know
that this entire process is encrypted and it's
very, very secure. When the key distribution center
receives this encrypted package that's the
authentication request, it decrypts it
with what it knows to be the client's password
hash, has a look at it, and it makes sure that
the time frame that was encrypted in
there is somewhere within a five-minute period. So this is very time sensitive. Inside of that, it
checks and makes sure. And if that's all
legitimate, it sends back what is called a Ticket Granting
Ticket-- sort of an odd name. It's a ticket that's going to
allow you to get other tickets. It's a pretty important ticket. In that ticket, it's going
to have a client name, an IP address, some timestamp
information, and a validity period. So that this is only going to
be good for a certain amount of time. After that, you'll have to
re-authenticate to the network. This is also encrypted. You can see there's a
key associated with this. It is encrypted with a secret
key for the key distribution center, which means
the client here is not going to be able
to decrypt this. This is pretty
important because we want to be sure, if we're
going to authenticate to a third party, that
our authentication is going to be trusted. And if we know the key
distribution center is the thing that has
the private key, and that's the only thing
that has that private key, we can be assured that that
particular piece of information is going to be well-protected
when we present it to our application server. Another piece of
information that we get when we authenticate to
the key distribution center, is a Ticket Granting
service session key. And this is used to
encrypt the communication between our ticket granting
service that's up here, and our client. And we're going to use that
session service key again. That will be very useful. Again, every part of this
process is encrypted, and in this way,
we can be assured that nobody is able to
look into what's going on. Nobody's able to break
open some packets and see information that
we may be authenticating-- user names, password,
or anything else that might be in here. It's interesting to note
that that particular session key is encrypted with
the user's password hash, so we will be able to decrypt
that, and look inside of it and see all of the details
inside of that piece. So notice that we're getting
private keys from one place, private keys
from another place. There's a lot of
distribution here. It's a very complex process
to make this happen. Fortunately when
you're authenticating on to the network, you just put
in a user name and password. You've no idea this complex
encryption process is going on behind the scenes. Now that I have
been authenticated, I would like to be able
to communicate and use some resources on the network. Specifically, it would be great
if I could use this application server down here. But I've never spoken to
the application server. The application
server itself has not communicated to the
Ticket Granting Service. It has no idea that
I'm on the network. What I have to do is get a
ticket from the Ticket Granting Service that's
going to provide me with access to that
application server. The first step we'll do is
from our client workstation. I've got that encrypted
Ticket Granting ticket, and I'm going to
attach to that the name of the service that I'd like. And I'm going to send that to
the Ticket Granting Service. And I'm going to also send
a time stamp client ID that I've encrypted
with my session key. Again, we've got all this
encryption that's taking place, and the Ticket Granting
Service can certainly decrypt its own ticket. And since it knows the hash
that I'm using as my password, it can also decrypt the
TGS session key, as well. If this set of information
that we provided to our Ticket Granting Service
looks good, then we're going to get a couple of things
back from the Ticket Granting Service. The first one is a
service session key that we'll be able to use
with the application server. This is a key and
information that is encrypted with the session
key that we know about. So we'll be able to
look at that information once we receive it
off of the network. We're also going
to get a ticket. And this particular
ticket is one that is going to have user
information and session information key, and it's
going to being encrypted with a private key from
the application server's secret key. So this is a secret key that
only the key distribution server and the application
server know about. I don't have any access
to that private key, so therefore, I'm
not going to be able to decrypt that information
and see what's inside of it. It's going to be protected. And in our next
step, we're going to provide that to our
application server. That's why it's so important
that that information stay absolutely private. And that's exactly what we're
going to do in our next step. We're finally going to talk
to our application server, and we're going to send
along that private package that we received from
our key granting service. This is our encrypted
service ticket, and it's going to be encrypted
with that private key that we know nothing about. So we want to be sure we're
providing exactly the same key to the application server. We're also going to
provide an authenticator. It's going to have
a timestamp in it, and it's going to be encrypted
with our service session key that we got. That way we're able to send all
of this encrypted information, and on the other side,
our application server should be able to
see all of this. Our application server is
going to look at this service ticket that was provided
to us that was encrypted and we couldn't
look inside of it. So it's now finally
going to decrypt it with this private key, and
make sure the information in there looks OK. It's also going to look at
the authenticator we sent it and make sure that the
session key that we have with our passwords on it
matches what the application server would be
expecting with that. There's also an
optional process-- the application server may
send the timestamp back to the client encrypted with
that service session key. And because we're sending
that information back now, we are really checking to see
if there's a man in the middle. We want to prevent anybody
from sitting in the middle and looking at this information. We also want to be
sure that nobody can replay this
information later, to try to gain access
to these resources. After exchanging all this
encrypted information with our key
granting service, we are now talking directly
to the application server. The application server says
that information checks out, then you now have access
to those resources. This Kerberos
process takes place any time we need to gain access
to the network and authenticate for the first time, and every
time that we need access to yet another resource. So if you go into, for instance
your Microsoft Windows Active Directory infrastructure, you
look in the security logs, you'll see a lot of
session information where people are authenticating
into the Kerberos system. And you'll see every
time someone gains access to any of those resources. This Kerberos
technology allows us to be able to authenticate
and provide access, regardless of where you might
be on the network, or really even any type
of operating system that you might be using.
