|
The Kerberos Authentication Protocol
In any network environment, you have to implement network security. If you have valuable data in a file server, you not only have to protect this data from outside networks, but also inside the network. Kerberos is an authentication protocol used on an internal network. Kerberos was developed in the late 1980’s by MIT to create a networking environment to support 10,000 workstations. This article is going to describe how this protocol works, the purpose of each step and illustrate the complete process.
Let’s say a packet labeled “c” is sent from station “x”, to station “y” using the encryption method described by “e”. The notation for this transaction will look something like this: Kx{c}Ky[e] A packet consists of or a combination of the following: 1.) Authenticator 2.) Ticket Authenticator consists of the following, encrypted what is called the “session key”: (username|workstation IP address)[session key] A ticket usually consists of the following, encrypted with a service or username password: 1.) Lifespan 2.) Timestamp 3.) Username 4.) Workstation IP address 5.) Session key A lifespan is basically the time when the ticket is no longer valid. The timestamp is the time when the ticket was created.
The most basic mode of authentication is to type a username and password to a server. If the username and password of the server are correct, the client is able to access the server’s resources. If it is incorrect, access is denied. There are some problems with this. First, someone could easily obtain somebody else’s username or password, and pose as that person. Second, there is a username and password for each server. In a network with multiple servers, this becomes troublesome. So Kerberos is designed like this. The “Kerberos server” consists of three services that can be implemented on the same machine, or multiple machines. The services are the Authentication Service (AS), the Ticket-Granting Service (TGS), and the Remote Ticket-Granting Service (RTGS). For now, we will focus on the AS and TGS. The AS has a central database of usernames with their corresponding passwords, as well as services and their passwords. In order for a client to access a service, the client has to go to the TGS. When a client sends a request to the TGS, the packet consists of only the client’s username. Then the TGS constructs a reply packet that looks like this: KTGS{TGT}KClient[username password]. TGT stands for Ticket-Granting Ticket. As this name implies, this ticket is used to get other tickets to use with the corresponding service. Also, this provides security for the session key.
If the client were to receive service specific keys then two things occur. First, the user would have to type their password each time they use that service. Also, the copy of the username specific ticket would be stored on the computer. If someone were to somehow gain access to that workstation, they could conceivably pose as the person who uses that workstation if he or she contains the correct password. This is the purpose of lifespan and timestamp. After a certain amount of time, the ticket expires, and the workstation has to reauthenticate with the AS to receive a corresponding service ticket. But ideally, a user should only have to type in their password once per work session. This is the reason for the TGT (Ticket-Granting Ticket). The best way to explain the purpose of the session key is to look what happens. Let’s say the client has a ticket (I will explain later how the client receives this ticket using the TGT) and wants to use that resource. The client sends a packet that looks like this: KClient{Authenticator[session key]|Ticket}KService[Service password].
Now remember, the authenticator is encrypted with this session key. The service decrypts the packet using its password. If the timestamp is within the lifespan, the process proceeds; if the timestamp is after the lifespan, the ticket is denied. This protects against stolen tickets being used indefinitely. After the decryption the service receives this session key. It uses this key to decrypt the authenticator. If the workstation’s IP address and username match the IP address and username in the ticket, authentication is complete.
Let’s really dissect what this accomplishes, to see how beautiful this system works. First, only the AS knows the service’s password. This means that the service knows that the AS is not a fake. If a bad guy were to steal the initial packet, he still doesn’t know the session key provided by the TGT. So when this bad guy makes up a session key to encrypt his authenticator, the session key doesn’t match the session key in the ticket. Therefore the authenticator can’t be decrypted, and the request is rejected. And finally, if he were to intercept the TGT itself, and was able to have the service decrypt his authenticator, his username could be the same, but it would be impossible for his workstation to have the same IP address. The IP address is not the IP address in the ticket, and therefore the request is denied. This also provides a level of mutual authentication. Ideally, only the true service knows the service password. So if someone were to create a fake service, the fake service would not be able to decrypt the initial packet. The beauty of Kerberos is there are multiple levels of authentication, making it extremely difficult to pose as a “fake”.
Now, all aspects of the Kerberos authentication protocol have been covered. I will start from the beginning, assuming that the client is the true client.
Mike sits at his computer to start his usual work day. He is prompted for a username and password. Once he presses enter, a packet with clear text is sent to the TGS containing the username only. The TGS constructs a TGT. This TGT contains the session key to share with the TGS. The packet looks like this: KTGS{TGT}KClient[Client password] The password entered at the beginning of the session, decrypts this packet. Mike goes into his word processor, and creates some reports. When he is done, he wants to print. The client doesn’t have a print service ticket, so the client uses its TGT to get the print service ticket. The packet looks like this: KClient{Authenticator[session key]|TGT}KTGS[Session Key].
Remember the session key the client got after decrypting the TGT packet? Well that session key is used to encrypt its authenticator as well as the packet as a whole. The TGS decrypts this packet, authenticates, and then constructs a print service ticket and sends it to the client. The print service ticket contains the session key that the client needs to share with the print service. The packet looks like this: KTGS{Print Service Ticket}KClient[Session Key] The same session key as used as before.
In the PST, the session key that the client uses with the print service is listed. With this ticket, the client sends a request to the print service. The packet looks like this: KClient{Authenticator[PST session key]|PST}KPrint service[Service password] The service decrypts this packet with its password. In the ticket the service receives the session key. It uses this session key to decrypt the authenticator. When the username and workstation IP address match, authentication is complete. The documents are printed. When the TGT ticket expires, Mike will be asked for his username and password again, and the procedure continues as before.
With an understanding of the Kerberos Authentication Protocol, you will learn to appreciate what it does and implement it on your network. MIT did an impressive job designing this authentication protocol. It is very wise that network administrators implement Kerberos on their network.
Jon Brengle
Senior Technology Analyst
Certified A+, N+ Technician
Bibliography
“Kerberos (Protocol)”.
Wikipedia The Free Encyclopedia.
October 19, 2007.
“Project Athena”.
Wikipedia The Free Encyclopedia.
October 18, 2007.
Tung, Brian. The Moron’s Guide to Kerberos. MIT. January 2, 2007. http://www.isi.edu/~brian/security/kerberos.html.
October 21, 2007.
|
PCTechBytes Computer Repair Help Tutorials 
Knowledge Base Home | 
Glossary 
The Kerberos Authentication Protocol
File Attachments
Related Questions 
Language Translation
Search Knowledge Base