performs authentication as a trusted third-party authentication
service by using conventional (shared secret key) cryptography.
Kerberos provides a means of verifying the identities of principals,
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.
When you integrate Kerberos into an application, it is important
to review how and when Kerberos routines ensure that the application
design does not compromise the authentication. For instance, an
application is not secure if it uses Kerberos routines only on initiation
of a stream-based network connection and assumes the absence of
any active attackers who might hijack the stream connection.
The Kerberos protocol code libraries, whose API is described
in Chapters 5 and 6, can be used to provide encryption to any application.
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 two methods for obtaining credentials—the initial
ticket exchange and the TGT exchange—use slightly different
protocols and require different API routines. The basic difference
an API programmer will see is that the initial request does not
require a TGT. It does require the client's secret key, because
the reply is sent back encrypted in the client's secret key. Usually
this request is for a TGT, and TGT-based exchanges are used from
then on. In a TGT exchange, the TGT is sent as part of the request
for tickets and the reply is encrypted in the session key from the
TGT. For example, once a user's password is used to obtain a TGT,
it is not required for subsequent TGT exchanges.
The reply consists of a ticket and a session key, encrypted
either in the user's secret key (password) or the TGT session key.
The combination of a ticket and a session key is known as a credentials
cache. (In Kerberos V4, a credentials cache was called a ticket
file.) An application client can use these credentials to authenticate to
the application server by sending the ticket and an authenticator
to the server. The authenticator is encrypted in the session key
of the ticket and contains the name of the client, the name of the
server, and the time the authenticator was created.
In order to verify the authentication, the application server
decrypts the ticket using its service key, which is known only by
the application server and the Kerberos server. Inside the ticket,
the Kerberos server had placed the name of the client, the name
of the server, a key associated with this ticket, and some additional information.
The application server then uses the ticket session key to decrypt
the authenticator, and verifies that the information in the authenticator
matches the information in the ticket and that the timestamp in
the authenticator is recent (to prevent reply attacks). Because
the session key was generated randomly by the Kerberos server and
delivered encrypted only in the service key and in a key known only
by the user, the application server can be confident that user is
really who he or she claims to be, because the user was able to encrypt
the authenticator using the correct key.
To provide detection of both replay attacks and message stream
modification attacks, the integrity of all the messages exchanged
between principals can also be guaranteed by generating and transmitting
a collision-proof checksum 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.
The Kerberos protocol operates across organizational boundaries.
Each organization that runs 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 end service
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 credentials remotely. The exchange of inter-realm keys (a separate
key may be used for each direction) 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 remote realm's
ticket-granting service from its local realm. When that ticket-granting
ticket is used, the remote ticket-granting service uses the inter-realm
key (which usually differs from its own normal TGS key) to decrypt
the ticket-granting ticket and to assure 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.
This method can be repeated to authenticate across multiple
realms. To build a valid authentication path to a distant realm,
the local realm must share an inter-realm key with an intermediate
realm that communicates with either the distant realm or yet another
Realms are typically organized hierarchically. Each realm
shares a key with its parent and a different key with each child.
If two realms do not directly share an inter-realm key, the hierarchical
organization allows an authentication path to be easily constructed.
If a hierarchical organization is not used, it may be necessary
to consult some database to construct an authentication path between
Although realms are typically hierarchical, intermediate realms
may be bypassed to achieve cross-realm authentication through alternate
authentication paths. It is important for the end service to know
which realms were traversed when deciding how much faith to place
in the authentication process. To make this easier, a field in
each ticket contains the names of the realms that were involved
in authenticating the client.
Limitations in Kerberos
When you are designing a secure application, be aware of the
following limitations of Kerberos:
not address denial of service attacks. There are places in the
Kerberos protocol where an intruder can prevent an application from
participating in the proper authentication steps. Detection and solution
of such attacks (some of which can appear to be normal failure modes
for the system) is usually best left to the human administrators
Principals must keep their
secret keys secret. If an intruder somehow steals a principal's
key, they can use it to masquerade as that principal or impersonate
a server to legitimate principals.
are not solved by Kerberos. If a user chooses a poor password,
it is possible for an attacker to successfully mount an offline
dictionary attack by repeatedly attempting to decrypt, with successive
entries from a dictionary, messages obtained that are encrypted
under a key derived from the user's password.