...making Linux just a little more fun!

Kerberos: The watchdog of the Ether By Raj Shekhar

Introduction

The first computer networks were used to send e-mails and share files and printers between researchers and corporate employees. In such a scenario security was not given much thought. Now the computer networks (especially the Internet) are used by millions for banking, shopping and filing their tax returns, and network security has become a major problem. Network security can be divided into four areas.

Secrecy

Secrecy has to do with keeping information out of the reach of nosy unauthorized people.

Authentication

Authentication deals with determining the identity of the communication partner, whether it/he/she is an impostor or the real thing.

Non repudiation

Non repudiation deals with signatures: it uniquely identifies the sender of a message or file. How can you prove that the order for "10 million left shoes only" came from your customer when he claims he ordered "10 right shoes only".

Integrity control

Integrity control assures that vital data has not been modified. Integrity is critical for conducting commerce over the Internet. Without assured integrity, purchase orders, contracts, specifications, or stock purchase orders could be modified with devastating effects.

Need for Authentication

Why do we need an authentication service? An authentication service verifies the identity of the communication partner. Authentication is a fundamental building block of a secure network environment. If a server knows for certain the identity of its client, it can decide whether to provide it a particular service (for example.. printing facility) or not, whether to give the user special privileges etc. As an aside authentication and authorization are different. If user Foo says "delete file bar", then the problem of verifying whether the command came from Foo is authentication. The problem of verifying whether Foo has permission to delete file bar is authorization.

Let's take an example of Alice, who wishes to deal with Bob, her banker. In real life Bob and Alice can authenticate each other by recognizing each others faces, voices or handwriting . However if they wish to transact over network none of these options are available. How can Bob be sure that the request to transfer all of Alice's money to a secret Swiss bank account came from Alice and not from Eve?

This is where an authentication service comes in. Alice starts by sending out a message to Bob. As these messages are being sent, we have Eve, an intruder, who may intercept, modify or replay the messages to trick Alice and Bob or just to throw a spanner in the works. Nevertheless when the authentication is complete, Alice is sure she is talking to Bob and Bob is sure that he is talking to Alice.

Enter Kerberos

Kerberos was created by MIT as a solution to network security problems. It has its roots in Project Athena, started in 1983. The aim of Project Athena was to create an educational computing environment built around high-performance graphic workstations, high speed networking, and servers of various types. Project Athena used Kerberos as its authentication system. The name Kerberos comes from Greek mythology; it is the three-headed dog that guarded the entrance to Hades. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice verse) across an insecure network connection. After a client and server have 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.

From http://web.mit.edu/Kerberos/www/

Many of the protocols used in the Internet do not provide any security. Tools to "sniff" passwords off the network are in common use by systems crackers. Thus, applications which send an unencrypted password over the network are extremely vulnerable. Worse yet, other client/server applications rely on the client program to be "honest" about the identity of the user who is using it .Other applications rely on the client to restrict its activities to those which it is allowed to do, with no other enforcement by the server.

The original design and implementation of Kerberos Versions 1 through 4 was the work of two former Project Athena staff members, Steve Miller of Digital Equipment Corporation and Clifford Neuman (now at the Information Sciences Institute of the University of Southern California), along with Jerome Saltzer, Technical Director of Project Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members of Project Athena have also contributed to the work on Kerberos. The latest version of Kerberos 4 from MIT is patch level 10.It is officially considered "dead" by MIT; all current development is concentrated on Kerberos 5. The latest version of Kerberos 5 is 1.2.1.

Some Keywords First

The art of devising ciphers is known as cryptography and breaking them is known as cryptanalysis; together they are known as cryptology . The message to be encrypted is known as plaintext or cleartext. The plaintext is encrypted by using a function, which takes as a parameter a key. The output of the encryption process is known as ciphertext .When ciphertext is put through a decryption function, we get back the plaintext. Going back to our story of Alice and Bob, they (Alice and Bob) are sometimes referred to as principals, the main characters of the story.

Traditionally, the encryption key is same as the decryption key. The key is known only to the principals. Such a key is known as shared secret key. However in a cypto system proposed by Diffie and Hellman (researchers at Stanford University) in 1976, the encryption and decryption keys are different. The key to be used for encryption is made public so that messages to be sent to that user can be encrypted using the publicly available key. This key is known as the public key. Each user also has a private key ,known only to the user, which is used for decrypting messages sent to the user. This system is known as public-key cryptography , to contrast with shared-key cryptography. The RSA algorithm is an example of public-key cryptography.

And Some More ...

Before describing the authentication process, it is important to remove ambiguities in the terms to be used.

Often network applications are made of two parts,

• the part which requests a service, called the client side of the application
• the part which provides the service, called the server side of the application

Kerberos is a trusted third party authentication system. It is trusted in the sense that each of its client believes the judgment of the Kerberos' as to the identity of each of its other client to be accurate. To prove to the application server that it (Kerberos client) is trusted by the Kerberos server, it uses a ticket .In order for the Kerberos client to use any application server, a ticket is required. The server examines the ticket to verify the identity of the user. If all checks out, then the client is accepted. Along with a ticket an authenticator is also used by a Kerberos client to prove its identity. The authenticator contains the additional information which, when compared against that in the ticket proves that the client presenting the ticket is the same one to which the ticket was issued.

Kerberos maintains a database of its clients and their private keys for authentication. Because Kerberos knows these private keys, it can create messages which convince one client that another is really who it claims to be. The designers did not expect the entire world to trust a single database, so they made provision for having different realms. The realm is an administrative entity that maintains authentication data. Each organization wishing to run a Kerberos server establishes its own "realm".

And Now the Details

Kerberos assumes that the Kerberos clients are not trustworthy and requires the client to identify itself every time a service is requested from some other Kerberos client. The technique used by Kerberos are unobtrusive. Kerberos follows the following guidelines:

• Passwords are never sent across the network in cleartext. They are always encrypted. Additionally, passwords are never stored on Kerberos clients or server in cleartext.
• Every client has a password i.e. every application server, user, Kerberos client has a password.
• The only entity that knows all the password is the Kerberos server and it operates under considerable physical security.

Both the client and the application server are required to have keys registered with the authentication server (AS). If the client is a user, his key is derived from a password that he chooses; the key for a service (for example. a printing daemon) is a randomly selected key. These keys are negotiated during the registration of the clients.

1. A client sends a request to the authentication server requesting "credentials" for a given application server. The credentials consist of a ticket for the server and a session key. The ticket contains, along with other fields, the name of the server, the name of the client, the Internet address of the client, a timestamp, a lifetime, and session key. This information (the ticket) is encrypted using the key of the server for which the ticket will be used. Once the ticket has been issued, it may be used multiple times by the named client to gain access to the named server, until the ticket expires.

   Why is a timestamp included? The timestamp is put to prevent someone else from copying the ticket and using it to impersonate the Kerberos client at a later time. This type of attack is known as a replay. Because clocks don't always work in perfect synchrony, a small amount of leeway (about five minutes is typical) is given between the timestamp and the current time.

2. The AS responds with these credentials (the ticket and the session key), encrypted in the client's key. The AS also includes its name in the credentials to convince the Kerberos client that the decryption by the server was successful and the message came from the server.

   The AS does not know whether the client is actually the principal which initiated the request for a the ticket. It simply sends a reply without knowing or caring whether they are the same. This is acceptable because nobody but the Kerberos client whose identity was given in the request will be able to use the reply. Its critical information is encrypted in that principal's key.

3. The Kerberos client decrypts the credentials using its key to extract the session key. Note that because the ticket is encrypted in the key of the application server, a Kerberos client cannot decrypt it.
4. In order to gain access to the application server, the Kerberos client builds an authenticator containing the client’s name and IP address, and the current time. The authenticator is then encrypted in the session key that was received with the ticket for the server. The client then sends the authenticator along with the ticket to the server.
5. The service decrypts the ticket with its own key, extracting the session key and the identity of the Kerberos client which the server sent it inside the ticket. It then opens the authenticator with the session key. The authenticator and the ticket demonstrate the identity of the client.
6. The session key (now shared by the client and application server) is used to authenticate the client, and may optionally be used to authenticate the server. It may also be used to encrypt further communication between the two parties or to exchange a separate sub-session key to be used to encrypt further communication.

The Ticket Granting Ticket

One of the goals of the Kerberos system is to remain as unobtrusive as possible. In the above exchange, the Kerberos client has to enter in a password every time it has to decrypt the credentials passed to it by the AS . If the Kerberos client is a user it becomes quite irritating to enter his password to have a file printed or whenever he wants modify a file on the network (remember that the key is derived from the user's password). The obvious way around this is to cache the key derived from the password. But caching the key is dangerous. With a copy of this key, an attacker could impersonate the user at any time (until the password is next changed).

Kerberos resolves this problem by introducing a new agent, called the ticket granting server (TGS). The TGS is logically distinct from the AS, although they may reside on the same physical machine. (They are often referred to collectively as the KDC--the Key Distribution Center). The function of the TGS is as follows. Before accessing any regular service, the user requests a ticket to contact the TGS, just as if it were any other service. This usually occurs when the user first logins into the system. This ticket is called the ticket granting ticket (TGT). After receiving the TGT, any time that the user wishes to contact a service, he requests a ticket not from the AS, but from the TGS. Furthermore, the reply is encrypted not with the user's secret key, but with the session key that the AS provided for use with the TGS. Inside that reply is the new session key for use with the regular service. The rest of the exchange now continues as described above. The TGT is good only for a fairly short period, typically eight hours.

Cross Realm Authentication

The Kerberos protocol is designed to operate across organizational boundaries. A client in one organization can be authenticated to a server in another. Each organization wishing to run a Kerberos server establishes its own "realm". The name of the realm in which a client is registered is part of the client's name, and can be used by the application server to decide whether to honor a request.

By establishing "inter-realm" keys, the administrators of two realms can allow a client authenticated in the local realm to use its authentication remotely The exchange of inter-realm keys registers the ticket-granting service of each realm as a principal in the other realm. A client is then able to obtain a ticket-granting ticket for the other realm's ticket-granting service from its local realm. When that ticket-granting ticket is used, the other ticket-granting service uses the inter-realm key (which usually differs from its own normal TGS key) to decrypt the ticket-granting ticket, and is thus certain that it was issued by the client's own TGS. Tickets issued by the remote ticket- granting service will indicate to the end-service that the client was authenticated from another realm.

Conclusion

Kerberos is not a one-shot solution to the network security problem.Trust is inherent throughout the system: the client trusts Kerberos, if it correctly provides the client's encryption key.The application trusts the client if the client successfully provides a ticket that is encrypted using the server's key.In this trust lies the weakness of the system.

Specifically speaking, secret keys should be kept just that, secret. If an intruder somehow steals a principal's key, it will be able to impersonate the principal. "Password guessing" attacks are not solved by Kerberos. If a user chooses a poor password, it is possible for an attacker to successfully mount an dictionary attack.Kerberos makes no provisions for client's security; it assumes that it is running on trusted clients with an untrusted network. If the client's security is compromised, then Kerberos is compromised as well. However, the degree to which Kerberos is compromised depends on the host that is compromised. If an attacker breaks into a multi-user machine and steals all of the tickets stored on that machine, he can impersonate the users who have tickets stored on that machine .... but only until those tickets expire.

Raj Shekha