Path: utzoo!attcan!uunet!seismo!sundc!pitstop!male!sun-barr!ames!purdue!tut.cis.ohio-state.edu!ucbvax!agate!shelby!CCC.MFECC.LLNL.GOV!NESSETT
From: NESSETT@CCC.MFECC.LLNL.GOV
Newsgroups: comp.protocols.kerberos
Subject: some comments on Kerberos
Message-ID: <890509181345.2660012a@CCC.MFECC.LLNL.GOV>
Date: 10 May 89 01:13:45 GMT
Sender: daemon@shelby.Stanford.EDU
Organization: The Internet
Lines: 124

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.