Kerberos

From Hill2dot0
Jump to: navigation, search
Kerberos

Kerberos is an authentication model developed by M.I.T.’s Project Athena and named for the three-headed dog who, according to Greek mythology, guards the entrance to Hades. This is the authentication model that is now the default for Windows 2000 and later versions of Windows. Kerberos is currently available in two versions, V4 and V5; while the details of their operation are different, they are conceptually similar.

Kerberos uses a client/server architecture for user-to-server authentication, rather than host-to-host authentication. In this model, security and authentication will be based on secret key technology where every host on the network has its own secret key. It would be unmanageable if every host had to know all of the keys. Instead, a secure, trusted host somewhere on the network, known as a Key Distribution Center (KDC), knows the keys for all of the hosts (or at least some of the hosts within a portion of the network, called a realm). In this way, when a new node is brought online, only the KDC and the new node need to be configured with the node’s key; keys can be distributed physically or by some other secure means. Kerberos uses the Data Encryption Standard (DES) to generate keys and encrypt messages.

The Kerberos KDC has two main functions, as shown on the visual, known as the authentication server (AS) and ticket granting server (TGS). The basic steps in establishing an authenticated session between an application client and the appropriate server are listed below.

  1. The Kerberos software on the client system must first establish a connection with the Kerberos server’s AS function. The AS ensures that this client is who they say they are. The AS provides the client with a secret key for this login session (called the session key) and a ticket granting ticket (TGT), which gives the client permission to talk to the TGS.
  2. The client now needs to communicate with the TGS because this is where the client obtains the application server’s key; without this, the client cannot establish a connection to the service. The client supplies the TGS with the session key and TGT; the TGS responds with a session key to be used with the application server and an encrypted form of the application server’s secret key. That secret key is never sent on the network in any other form.
  3. At this point, the client has authenticated itself and can prove itself to the intended application server. The client sends the TGT, session key, and encrypted application server key to the server. The server can respond with similarly encrypted information to authenticate itself to the client. At this point, the client can initiate the intended service requests (e.g., Telnet, FTP, or HTTP session establishment).