[717] in Kerberos
some comments on Kerberos
daemon@TELECOM.MIT.EDU (NESSETT%CCC.MFECC.LLNL.GOV@.MIT.EDU)
Tue May 9 21:18:33 1989
From: NESSETT%CCC.MFECC.LLNL.GOV@.MIT.EDU
To: KERBEROS@ATHENA.MIT.EDU
On the 3rd of May at the Symposium on Security and Privacy in
Oakland, I pointed out several problems with Kerberos that, I
believe, require attention. I was somewhat surprised at the level of
interest these comments received. So that my criticisms can be
scrutinized by those directly involved with the ongoing Kerberos
design, I summarize them below. Included are two other points,
which I did not make at Oakland, related to the "realms" concept of
Kerberos.
Several of the comments made below are applications of work
described in a technical report written several years ago by Dick
Watson, Art Sorkin and me entitled, "Connection Management and
Key Distribution Protocols." This report examines the design issues
associated with the management of secure connections and critiques
several key distribution protocols, such as Needham and Schroeder
as well as Denning and Sacco according to how well they address
these issues. I would be happy to send a copy of this report to
anyone interested.
As a final preliminary remark, let me point out that I have only been
on the Kerberos mailing list since 9 May, 1989. If any of the
criticisms given below are "old hat", I apologize.
I believe Kerberos to be deficient in the following ways :
o Kerberos keeps its encryption keys in application process space.
While several Kerberos defenders have attempted to deflect this
criticism with the observation that only short-term keys are so kept,
in fact the long-term key derived by transforming the user's
password also appears, however briefly, in application process space
as well. That it is used quickly and then obliterated is of little
comfort after one realizes that : a) computer programs installed on a
host by an intruder with the specific intention of capturing the user's
password need little time to do so, and b) copies of the password
may exits in disk swapping space and terminal input buffers far
longer than one might expect. The environment for which Kerberos
was engineered (i.e., an "open" environment with little physical
security) admits a rich assortment of intruder attacks that can take
advantage of these properties.
o Kerberos (as described in the Winter '88 USENIX paper) seals the
client's IP address within ticket's and authenticators, yet these
addresses cannot be guaranteed correct. I am told that the current
version of the Kerberos protocol does not seal IP addresses in tickets
and authenticators, since the Kerberos designers now understand
that this affords no protection against message replay. Regrettably,
the removal of these addresses does not fix the problem, since
ticket/authenticator pairs captured by an intruder by observing the
traffic passing over an Ethernet or through an intermediate node can
be replayed. The window of opportunity for replay is on the order of
minutes, well within the capacity of programs written by an intruder
to capture such information and replay it.
o The security properties of Kerberos rest to a large extent on the
timestamp and lifetime information carried by tickets and
authenticators. Since this information must be compared by servers
against the value of some clock, its security properties also rests on
the mechanism by which clocks are kept synchronized. Attacks
against servers are possible by attacking the clock synchronization
protocol/mechanism. This threat is not adequately met by the
Kerberos architecture described in the public literature.
o One major advantage of central authentication (which is the basic
service that Kerberos offers) is the ability to revoke someone's access
to distributed system resources quickly and atomically (i.e., by
means of a single operation). At first sight, one might believe this
possible with Kerberos by invalidating a user's long-term key in the
Kerberos database. However, there is an attack against this strategy.
If an intruder can isolate one of the slave Kerberos servers (perhaps
by congesting an appropriate part of the network), thereby
preventing the arrival of update messages, he can continue to
operate even when his key has been invalidated in the master
database.
o While it is strenuously asserted that Kerberos only supports an
authentication service, the mechanisms by which this service is
provided strongly favors one type of authorization, namely, the use
of access control lists. Authenticating a user's identity or
identity.instance to individual servers for the purpose of access
control (as distinct from accountability purposes) is of little value
unless authorization is also based on identity. This introduces a
transitivity problem (acknowledged in the USENIX paper) whereby
servers accessing the resources of other servers on behalf of clients
must pose as those clients. But this action violates the principle of
least privilege, since servers posing as clients gain potential access to
all of the client's resources, not just to those necessary to carry out
their function.
o There are occasions when it is desirable for administrators to shut
down remote access to servers of given class (e.g., remote logon),
while allowing remote access to other servers (e.g., E-mail). For
example, if a worm is loose in a distributed system and you
determine it is attacking the remote logon and file transfer services,
you would like to shut down access to these services from outside
your administrative domain (for the purposes of this discussion,
administrative domain is used synonymously with realm) without
affecting the inter-administrative-domain E-mail service. The realm
mechanism supported by Kerberos is not well-suited to this
requirement. First of all, to quickly revoke the privileges of a user
from one realm to resources in another requires contacting the ticket
granting server in the latter realm and "black-listing" that user. I
have seen no mechanism described for doing this. Secondly, in the
short-term (since tickets issued by the ticket granting server may be
good for several hours), all servers of the target classes must be
contacted and directed not to accept service requests from user's of
other realms. Simply locating all servers of a given class is an
arduous task, not helped by the fact that Kerberos keeps no record of
the type of service offered by a particular server. In addition, a
secure administration protocol is necessary to direct the involved
servers to take the appropriate action. I have seen no description of
such a protocol in the Kerberos literature.
o Kerberos is designed to work in an environment in which all
administrative domains use the same communications protocol (e.g.,
TCP/IP). In addition, all servers of all realms must support the
Kerberos protocol in order to interoperate. These requirements are
impractical. If there is one characteristic of large distributed
systems it is that they are heterogeneous. Administrative domains
in practical distributed systems will support different
communications protocols and will not, in general support common
mechanisms such as those of Kerberos. Schemes that require the
existence of common mechanisms throughout the distributed system
will have only limited applicability in the distributed systems of the
future.
