Kerberos... providing strong cryptography

The Internet is an insecure place as we all know. Many of the protocols used in the Internet do not provide any security. Tools to identify passwords off of the network are in common use by malicious hackers. Thus, applications which send an unencrypted password over the network are extremely vulnerable. Some sites attempt to use firewalls to solve their network security problems. Unfortunately, firewalls assume that hackers are on the outside, which is often a very bad assumption. Most of the really damaging incidents of computer crime are carried out by insiders.Kerberos was created by MIT as a solution to these network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.Lets see how it works.

Auth - Authenticator , SK1 - Session Key , TGT - Ticket

The client asks the authentication server for a ticket to the ticket-granting server(TGS). The authentication server looks up the client in its database, then generates a session key (SK1) for use between the client and the TGS. Kerberos encrypts the SK1 using the client’s secret key. The authentication server also uses the TGS’s secret key (known only to the authentication server and the TGS) to create and send the user a ticket-granting ticket (TGT).

The client decrypts the message and recovers the session key, then uses it to create an authenticator containing the user’s name, IP address and a time stamp. The client sends this authenticator, along with the TGT, to the TGS, requesting access to the target server. The TGS decrypts the TGT, then uses the SK1 inside the TGT to decrypt the authenticator. It verifies information in the authenticator, the ticket, the client’s network address and the time stamp. If everything matches, it lets the request proceed. Then the TGS creates a new session key (SK2) for the client and target server to use, encrypts it using SK1 and sends it to the client. The TGS also sends a new ticket containing the client’s name, network address, a time stamp and an expiration time for the ticket — all encrypted with the target server’s secret key — and the name of the server.

The client decrypts the message and gets the SK2. Finally ready to approach the target server, the client creates a new authenticator encrypted with SK2. The client sends the session ticket (already encrypted with the target server’s secret key) and the encrypted authenticator. Because the authenticator contains plaintext encrypted with SK2, it proves that the client knows the key. The encrypted time stamp prevents an eavesdropper from recording both the ticket and authenticator and replaying them later. The target server decrypts and checks the ticket, authenticator, client address and time stamp. For applications that require two-way authentication, the target server returns a message consisting of the time stamp plus 1, encrypted with SK2. This proves to the client that the server actually knew its own secret key and thus could decrypt the ticket and the authenticator.

The target server knows that the client is who he claims to be, and the two now share an encryption key for secure communications. Because only the client and target server share this key, they can assume that a recent message encrypted in that key originated with the other party.