...making Linux just a little more fun!
By Raj Shekhar
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.
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.
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.
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.
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.
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,
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".
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:
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.The authentication process proceeds as follows:
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.
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.
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.
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.
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.