Originally designed as a network authentication protocol, Kerberos is now finding extensive use in operating system security plans, including Microsoft's Windows XP operating system. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. Massachusetts Institute of Technology completed development and the first implementation of this protocol. From its academic background, Kerberos has grown in use as the basis of a commercially focused authentication technology.
Many of the protocols used on the Internet assume a high level of trust and security within organizations. Kerberos was created to handle the security risks posed by technologies that can listen for or "sniff" passwords off the network, which is a common approach that hackers take for gaining access to protected Web sites and resources. Applications that 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 that it is allowed to do, with no other enforcement by the server.
Some sites attempt to use firewalls to solve their network security problems. Unfortunately, firewalls assume that people who want to illegally gain access to the system are on the outside, which is often a very bad assumption. Insiders carry out most of the really damaging incidents of computer crime. Firewalls also have a significant disadvantage in that they restrict how your users can use the Internet. (After all, firewalls are simply a less-extreme example of the dictum that there is nothing more secure then a computer that is not connected to the network—and powered off!) In many places, these restrictions are simply unrealistic and unacceptable.
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 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.
Microsoft Implementation of Kerberos Starts in Windows 2000
Starting with the client/server architecture that Microsoft promoted and subsequently gained traction with in the Windows 2000 Server, the Kerberos authentication protocol is today being developed into and delivered with each version of the Windows XP operating system. The Kerberos protocol provides a mechanism for mutual authentication between a client and a server, or between one server and another, before a network connection is opened between them. The protocol assumes that initial transactions between clients and servers take place on an open network in which most computers are not physically secure, and packets traveling along the wire can be monitored and modified at will. The assumed environment, in other words, is very much like today's Internet, in which an attacker can easily pose as either a client or a server, and can readily eavesdrop on or tamper with communications between legitimate clients and servers.
Kerberos is a shared-secret authentication protocol because the user and the Key Distribution Center (KDC) both know the user's password or, in the case of the KDC, the one-way encrypted password. The Kerberos protocol defines a series of exchanges between clients, the KDC, and servers to obtain and use Kerberos tickets. When a user initiates a logon to Windows, the Kerberos SSP obtains an initial Kerberos ticket (TGT) based on an encrypted hash of the user's password. Both Windows 2000 and Windows XP store the TGT in a ticket cache on the workstation associated with the user's logon context. When a client program attempts to access a network service, the Kerberos runtime checks the ticket cache for a valid session ticket to the server. If a ticket is not available, the TGT is sent in a request to the KDC for a session ticket that allows access to the server.
The session ticket is added to the ticket cache, and may be reused for future connections to the same server until the ticket expires. The ticket expiration period is defined by domain security policy and is usually set for about eight hours. If the session ticket expires during the middle of an active session, the Kerberos security provider returns appropriate error values that allow the client and server to refresh the ticket, generate a new session key, and resume the connection.
The following diagram shows the relationship between the client, the KDC, and the application server using the Kerberos authentication protocol.
The Kerberos session ticket is presented to the remote service during the initial connection message. Portions of the session ticket are encrypted using a secret key shared between the service and the KDC. The server can quickly authenticate the client by verifying the session ticket without going to the authentication service because the Kerberos runtime for the server has a cached copy of the server's secret key. Session connection setup is much faster on the server side than NTLM authentication. With NTLM, the server would obtain the user credentials and then have to reauthenticate the user through the domain controller as part of establishing the connection.
Kerberos session tickets contain a unique session key created by the KDC to use for symmetric encryption of authentication information and data transferred between the client and server. In the Kerberos model, the KDC is used as an online trusted third party to generate the session key. Online authentication services are very efficient for distributed application services available in a campus-like network environment.