Kerberos provides a means of verifying the identities of principals,
(e.g., a workstation user or a network server) on an open
(unprotected) network. This is accomplished without relying on
authentication by the host operating system, without basing trust on
host addresses, without requiring physical security of all the hosts
on the network, and under the assumption that packets traveling along
the network can be read, modified, and inserted at will. (Note,
however, that many applications use Kerberos' functions only upon the
initiation of a stream-based network connection, and assume the
absence of any "hijackers" who might subvert such a connection. Such
use implicitly trusts the host addresses involved.) Kerberos
performs authentication under these conditions as a trusted third-
party authentication service by using conventional cryptography,
i.e., shared secret key. (shared secret key - Secret and private are
often used interchangeably in the literature. In our usage, it takes
two (or more) to share a secret, thus a shared DES key is a secret
key. Something is only private when no one but its owner knows it.
Thus, in public key cryptosystems, one has a public and a private
key.)
The authentication process proceeds as follows: A client sends a
request to the authentication server (AS) requesting "credentials"
for a given server. The AS responds with these credentials,
encrypted in the client's key. The credentials consist of 1) a
"ticket" for the server and 2) a temporary encryption key (often
called a "session key"). The client transmits the ticket (which
contains the client's identity and a copy of the session key, all
encrypted in the server's key) to the server. The session key (now
shared by the client and 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 implementation consists of one or more authentication servers
running on physically secure hosts. The authentication servers
maintain a database of principals (i.e., users and servers) and their
secret keys. Code libraries provide encryption and implement the
Kerberos protocol. In order to add authentication to its
transactions, a typical network application adds one or two calls to
the Kerberos library, which results in the transmission of the
necessary messages to achieve authentication.
The Kerberos protocol consists of several sub-protocols (or
exchanges). There are two methods by which a client can ask a
Kerberos server for credentials. In the first approach, the client
sends a cleartext request for a ticket for the desired server to the
AS. The reply is sent encrypted in the client's secret key. Usually
this request is for a ticket-granting ticket (TGT) which can later be
used with the ticket-granting server (TGS). In the second method,
the client sends a request to the TGS. The client sends the TGT to
the TGS in the same manner as if it were contacting any other
application server which requires Kerberos credentials. The reply is
encrypted in the session key from the TGT.
Once obtained, credentials may be used to verify the identity of the
principals in a transaction, to ensure the integrity of messages
exchanged between them, or to preserve privacy of the messages. The
application is free to choose whatever protection may be necessary.
To verify the identities of the principals in a transaction, the
client transmits the ticket to the server. Since the ticket is sent
"in the clear" (parts of it are encrypted, but this encryption
doesn't thwart replay) and might be intercepted and reused by an
attacker, additional information is sent to prove that the message
was originated by the principal to whom the ticket was issued. This
information (called the authenticator) is encrypted in the session
key, and includes a timestamp. The timestamp proves that the message
was recently generated and is not a replay. Encrypting the
authenticator in the session key proves that it was generated by a
party possessing the session key. Since no one except the requesting
principal and the server know the session key (it is never sent over
the network in the clear) this guarantees the identity of the client.
The integrity of the messages exchanged between principals can also
be guaranteed using the session key (passed in the ticket and
contained in the credentials). This approach provides detection of
both replay attacks and message stream modification attacks. It is
accomplished by generating and transmitting a collision-proof
checksum (elsewhere called a hash or digest function) of the client's
message, keyed with the session key. Privacy and integrity of the
messages exchanged between principals can be secured by encrypting
the data to be passed using the session key passed in the ticket, and
contained in the credentials.
The authentication exchanges mentioned above require read-only access
to the Kerberos database. Sometimes, however, the entries in the
database must be modified, such as when adding new principals or
changing a principal's key. This is done using a protocol between a
client and a third Kerberos server, the Kerberos Administration
Server (KADM). The administration protocol is not described in this
document. There is also a protocol for maintaining multiple copies of
the Kerberos database, but this can be considered an implementation
detail and may vary to support different database technologies.
