Many organizations prefer using a centralized and secure authentication protocol. In this video, you’ll learn how Kerberos uses many different encryption points to maintain the security of the authentication process.
<< Previous Video: RADIUS and TACACSNext: LDAP and Secure LDAP >>
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.