Explanation: Kerberos is a trusted, credential-based, third-party authentication protocol that uses symmetric (secret) key cryptography to provide robust authentication to clients accessing services on a network.
Because a client's password is used in the initiation of the Kerberos request for the service protocol, password guessing can be used to impersonate a client.
Here is a nice overview of HOW Kerberos is implement as described in RFC 4556:
1. Introduction
The Kerberos V5 protocol [RFC4120] involves use of a trusted third
party known as the Key Distribution Center (KDC) to negotiate shared
session keys between clients and services and provide mutual
authentication between them.
The corner-stones of Kerberos V5 are the Ticket and the
Authenticator. A Ticket encapsulates a symmetric key (the ticket
session key) in an envelope (a public message) intended for a
specific service. The contents of the Ticket are encrypted with a
symmetric key shared between the service principal and the issuing
KDC. The encrypted part of the Ticket contains the client principal
name, among other items. An Authenticator is a record that can be
shown to have been recently generated using the ticket session key in
the associated Ticket. The ticket session key is known by the client
who requested the ticket. The contents of the Authenticator are
encrypted with the associated ticket session key. The encrypted part
of an Authenticator contains a timestamp and the client principal
name, among other items.
As shown in Figure 1, below, the Kerberos V5 protocol consists of the
following message exchanges between the client and the KDC, and the
client and the application service:
The Authentication Service (AS) Exchange
The client obtains an "initial" ticket from the Kerberos
authentication server (AS), typically a Ticket Granting Ticket
(TGT). The AS-REQ message and the AS-REP message are the request
and the reply message, respectively, between the client and the
AS.
The Ticket Granting Service (TGS) Exchange
The client subsequently uses the TGT to authenticate and request a
service ticket for a particular service, from the Kerberos
ticket-granting server (TGS). The TGS-REQ message and the TGS-REP
message are the request and the reply message respectively between
the client and the TGS.
The Client/Server Authentication Protocol (AP) Exchange
The client then makes a request with an AP-REQ message, consisting
of a service ticket and an authenticator that certifies the
client's possession of the ticket session key. The server may
optionally reply with an AP-REP message. AP exchanges typically
negotiate session-specific symmetric keys.
Usually, the AS and TGS are integrated in a single device also known
as the KDC.
+--------------+
+--------->| KDC |
AS-REQ / +-------| |
/ / +--------------+
/ / ^ |
/ |AS-REP / |
| | / TGS-REQ + TGS-REP
| | / /
| | / /
| | / +---------+
| | / /
| | / /
| | / /
| v / v
++-------+------+ +-----------------+
| Client +------------>| Application |
| | AP-REQ | Server |
| |<------------| |
+---------------+ AP-REP +-----------------+
Figure 1: The Message Exchanges in the Kerberos V5 Protocol
In the AS exchange, the KDC reply contains the ticket session key,
among other items, that is encrypted using a key (the AS reply key)
shared between the client and the KDC. The AS reply key is typically
derived from the client's password for human users. Therefore, for
human users, the attack resistance strength of the Kerberos protocol
is no stronger than the strength of their passwords.
Source: KRUTZ, Ronald L. & VINES, Russel D., The CISSP Prep Guide: Mastering the Ten Domains of Computer Security, John Wiley & Sons, 2001, Chapter 2: Access control systems (page 40).
And
HARRIS, Shon, All-In-One CISSP Certification Exam Guide, McGraw-Hill/Osborne, 2002, chapter 4: Access Control (pages 147-151).
and
http://www.ietf.org/rfc/rfc4556.txt