The Kerberos protocol

T

The Kerberos protocol was designed at the MIT (Massachusetts Institute of Technology) at the Athena project around 1984. The purpose of the Kerberos protocol is to allow a client to demonstrate the identity of a remote server, somewhere beyond a completely insecure network. Unlike many of the current security solutions – such as password generators or biometric devices that read fingerprints or iris – Kerberos resolves network security with no additional hardware, but just relies on encryption mechanisms.

The protocol also guarantees that the client can not converse with a computer that acts as a server; authentication is done in both directions. The protocol itself consists of a messaging between a client and a series of servers, each with another mission. The basic idea belongs to Needham and Schroeder who published their original idea in 1978 in Communications of the ACM.

The protocol seems rather complicated, but if you have the patience you will understand everything that is going on. The initial premise is that there is a central server, called the authentication server (AS), which knows the identities of all possible customers. Also, each client has set a secret password that this server knows. The password securely reaches the server, for example by mail or through a secure messenger at least from a software point of view. This password is not known to anyone else even by the other servers from which the client will get the services that are of interest to him.

All other administrative servers are also clients of the AS. They have a unique password known only by AS and that server. Never password will not circulate clearly on the network. Then anyone can read it and use it instead of the right client. In order to protect against anyone who will record or delete messages, messages will have the information and time at which they were sent and a serial number to detect omissions. Another interesting rule is that the keys used in client-server communication change frequently. Standard implementation expires a key after 25 hours.
In this way, a cryptanalytic attack will not have much success. If it takes more than 25 hours, then the uncovered key is already useless, of course, any messages already intercepted and stored will be readable, but the damage is limited. The key that a client and server use in common is called a session key and is generated randomly.

Implementing Kerberos:
Between a paper authentication protocol and a real implementation on a computer is a considerable distance. The first thorny question that comes up is: where the password of each client KC, KS, etc. is stored). AS needs to be a very safe car, somewhere in a basement, but customer cars will probably be all over the place. If a customer’s password is stored on disk, it is even more user-friendly for client attacks. As such, Kerberos does not memorize your password anywhere!

The user is required to type each time he wants to be authenticated. Note that KC is used only to decrypt a message. The rest is useless.

So the procedure is the following: The client’s Kerberos program will contact the AS, and when the response arrives, the user must type the KC password. The password is immediately used to decrypt the message from the AS, after which it is completely deleted from the memory. In this way, the vulnerability window is reduced to the maximum. On the other hand, this can be very unpleasant, because then the user will have to type the password for each new S server he wants to use, that is, for each new session. And as some users are a little lazy, they think this is harder.

Kerberos then introduced a second central server named Ticket Server: Ticket Granting Server, TGS. The idea is that TGS actually has all KS passwords.
Client C logs in to TGS exactly the same way as any S server: getting a ticket from the AS. Once authenticated to TGS and using the KC session key, the TGS client can request any keys for other S, S1 servers, etc. Kerberos is implemented as server processes (AS, TGS) and libraries that can be linked to client and server programs. It works under a wide variety of operating systems: Unix and Windows NT being the most notable. Computer security is a matter of great economic importance, especially when more and more transactions are done through the Internet. Designing a security protocol is a very complicated task and implementation is not at all easy. The domain is in full research. Difficulties are amplified by the fact that the chain is just as weak as the weakest link, and there are many links.

Recent Posts

Archives

Categories