Network Computingwww.networkcomputing.com

The Kerberos protocol and its use of encryption are best illustrated by examining the login process:

1. User requests initial authentication (kinit)
2. Client contacts Kerberos server with user's requested principal name
3. Kerberos server returns TGT (Ticket-Granting-Ticket) encrypted in the user's key
4. Client attempts to decrypt TGT with user's key (derived from password). If successful, client saves user's TGT and enclosed session key in client's credential cache.
User is now "logged into Kerberos service."

When logging into a Kerberos realm, which also is known as requesting credentials, the user invokes kinit . This is sometimes integrated into system login utilities. This either prompts the user for a user ID, or obtains a known user ID from the workstation, finds the local realm name and Kerberos server in its configuration files, and requests a ticket-granting ticket.

Surprisingly, the Kerberos server freely transmits a TGT to any unauthorized request. However, every TGT is encrypted in a key derived from the user's password. Therefore, the user's password is then used to decrypt the TGT from the Kerberos server. If the decryption process results in a valid ticket with a valid time stamp, the user has valid Kerberos credentials. These credentials include a session key for establishing secure communications with the Kerberos server in the future, as well as the actual ticket-granting ticket, which is actually encrypted in the Kerberos server's own key. This second layer of encryption is unknown to the user, but it's what allows the Kerberos server to verify the authenticity of each TGT.

However, this TGT is only a license; it doesn't actually authenticate the user. When actually logging a Kerberized service, such as a klogin, or Kerberized rlogin service on a Unix machine, the klogin client presents the user's credentials to the Kerberos server and requests a service ticket. The KDC verifies the user's credentials by decrypting the TGT, which is encoded in the KDC's own key, and securely transmits the service key to the user's workstation. The service key is then added to the user's credential cache, and in turn, presented to the remote service, which in this case is the klogind.

1. User requests telnet connection to server. Telnet client c hecks for existing server credentials in client's credential cache.
2. Client requests service credentials from Kerberos KDC -- uses TGT and Session Key to authenticate to Kerberos KDC. [username@REALM]
3. Kerberos KDC verifies user's credentials and assembles service ticket for server.
4. Kerberos KDC transmits service ticket to client with new session key for service [host/server@REALM] (service ticket is encrypted using server's secret key).
5. Client stores service ticket for server in credential cache. Client transmits service ticket to server.
6. Server decrypts service ticket with its secret key. If successful, the user is valid and the session key is extracted.
Server and client then begin telnet session -- optionally encrypted using session key.

Recall that each server has a host principal (host/hostname.domain.com@REALM.COM), which is an entry in the Kerberos database with an associated encryption key. This key is known only to the host and the Kerberos KDC. In order to access the service, the user must present the host with a ticket encrypted in its own key. When the server accepts the user's service ticket and successfully decrypts the ticket using its own key, the user is authenticated and allowed in. As the service trusts the KDC, the user is considered valid. In the case of klogin on a Unix host, the user is logged into a Unix shell as specified in the /etc/passwd file. Note that Unix will not allow the user to start a shell if that user ID doesn't have an entry in /etc/passwd: a rudimentary form of access control useful in Unix-based Kerberos realms.

Print This Page

E-mail this URL