Tech Insider					     Technology and Trends


		      Kerberos Mailing List Archives

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.

daemon@TELECOM.MIT.EDU (John T Kohl)
Wed May 10 09:29:08 1989

From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: NESSETT%CCC.MFECC.LLNL.GOV@.mit.edu
Cc: kerberos@ATHENA.MIT.EDU
In-Reply-To: [0717]

	...
	ticket/authenticator pairs captured by an intruder by observing the 
	traffic passing over an Ethernet or through an intermediate node can 
	be replayed.
	...

This is a bug in the current implementations.  The authenticator
contains a sealed request_id which the server is supposed to check
against the request_id's produced in the last  minutes (where  is
the max allowed clock skew).  Any duplication should be treated as
a replay attack.

	o  Kerberos is designed to work in an environment in which all 
	administrative domains use the same communications protocol (e.g., 
	TCP/IP).

We recognize this undesirability, and we plan to allow/support multiple
protocols (e.g. ISO, IP, ...) in the next version of Kerberos.

		In addition, all servers of all realms must support the 
	Kerberos protocol in order to interoperate.
	...

Not strictly true.  As long as a service provider has access to a secret
shared with its KDC, it can `play the game' as a passive recipient of
authentication information.  If the service provider wants to initiate
authentication to some other entity, it needs to speak the Kerberos
protocol to the appropriate KDC's, and it needs to know what
communications protocol to speak with those KDC's.

John Kohl <jtkohl@ATHENA.MIT.EDU>
Digital Equipment Corporation/Project Athena

daemon@TELECOM.MIT.EDU (Jerome H Saltzer)
Wed May 10 10:12:36 1989

From: Jerome H Saltzer <jhs%computer-lab.cambridge.ac.uk@NSFNET-RELAY.AC.UK>
To: NESSETT%ccc.mfecc.llnl.gov@NSFNET-RELAY.AC.UK
Cc: KERBEROS@ATHENA.MIT.EDU,
In-Reply-To: NESSETT@gov.llnl.mfecc.ccc's message of Tue, 9 May 89 18:13:45 PDT 
<890509181345.2660012a@CCC.MFECC.LLNL.GOV>


On the whole, the comments made by Nessett are quite interesting,
especially to deciding to what range of problems Kerberos might be
applicable.

There are a few things in Nessett's analysis and critique that should
be discussed before accepting the criticisms as valid, though.

> o  Kerberos keeps its encryption keys in application process space.  

I don't think that is a criticism of Kerberos itself as much as a
criticism of the way in which Kerberos is implemented in UNIX systems.
The protocol does not specify where keys should be kept, and in a
system specially designed for security one might well provide hardware
or software-in-the-supervisor storage mechanisms for the keys and for
temporary storage to hold the password.  Addition of such mechanisms
to UNIX would not require changes in the basic design of Kerberos.  (But
the changes to UNIX would be extensive enough as to risk considerable
debate, which is why the current Kerberos implementation didn't try.)

> 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.  . . . this affords no
> protection against message replay. . . .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.  

I think this criticism arises from a misunderstanding of the Kerberos
design that may in turn arise from the somewhat simplified description
that appeared in the USENIX paper.  The inclusion of the IP address in
a ticket is not intended to have any bearing on replay protection,
even though it does have the effect of increasing slightly the work
factor in creating a replay attack against a service that chooses not
to protect itself against replay.  The fundamental protection against
replay resides in the expiration of authenticators.  Any service
concerned about replay should keep a list of authenticators it has
accepted until they expire.  The expiration times are very short
exactly so that that list can be short.  When a service keeps such a
list, there is no window of replay vulnerability.

> 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.

This concern is definitely true, and it causes me to be somewhat
worried about recent moves from the traditional eyeball-and-timex
method of setting system clocks to the fancier network
time-synchronization protocols.  The eyeball-and-timex method at least
provides a known level of security on which Kerberos can build.

However, I think that the securing of the time-synchronization
protocol is a matter best thought of as orthogonal to the
authentication protocol; the Kerberos system should specify that a
secure time-synchronization method be used rather than specify the
method itself.

> 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.

Quick invalidation of user authentication was not one of the design
criteria of Kerberos, and its lack is a valid criticism in some
application situations.  Since tickets can have a fairly long lifetime
(8 hours is the default in the current implementation) there is a much
simpler attack than isolating a slave Kerberos server--just acquire a
set of tickets for interesting services, and then continue to operate
for up to eight hours after the administrator pulls you from the
database.

> . . . 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.

This concern seems to be based on some assumptions about the range of
transitive authorization mechanisms that can be based on identity.  A
service A when working for client B can present its credentials to
service C in at least the following several ways--

     -  this is service A asking for service C
     -  this is service A operating on behalf of client B asking for service C
     -  this is client B asking for service C

The present design of Kerberos does not provide for any form of
transitive credentials-passing (that lack is the transitivity problem
mentioned in the paper) so the proper criticism is probably about that
lack, rather than on speculation on how it might be filled wrongly.

> 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). . . .
> The realm mechanism supported by Kerberos is not well-suited to this 
> requirement. . . .   I have seen no mechanism described for doing this.
> ;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.

The requirement you describe here is not an authentication
requirement, but an authorization requirement.  Since Kerberos
does not claim to provide authorization control, it is not surprising
that it does not meet this requirement.

> o  Kerberos is designed to work in an environment in which all 
> administrative domains use the same communications protocol (e.g., 
> TCP/IP). 

Actually, there is nothing about the Kerberos design that requires it
use TCP or that requires that all interoperating realms use the same
protocol.  The current implementation happens to be TCP, but there is
no design barrier to producing a DECNET, SNA, or ISO version, and
there is nothing to keep a realm from accepting connections via any
protocol that it implements.  One might be concerned that perhaps
noone may ever get around to implementing other versions, but that is
not a design problem.

> In addition, all servers of all realms must support the Kerberos
> protocol in order to interoperate.

Perhaps you could more carefully specify this concern, because as it
is currently stated, it appears to be dramatically overdrawn.
Interoperation of any client with a server requires that the
particular pair agree on the protocol to be used, and if the server
demands Kerberos mediation, then the client had better be prepared to
provide Kerberos credentials.  If the server doesn't, then the client
need not provide them.  Both arrangements can coexist simultaneously,
and a client can use Kerberos mediation with a server that itself
obtains further services without Kerberos mediation.  There are a lot
of interoperability concerns in the world, but I can't figure out
which one you think is made especially difficult to deal with by the
use of Kerberos.

					Jerry Saltzer

daemon@TELECOM.MIT.EDU (NESSETT%CCC.MFECC.LLNL.GOV@.MIT.EDU)
Thu May 11 12:10:53 1989

From: NESSETT%CCC.MFECC.LLNL.GOV@.MIT.EDU
To: KERBEROS@ATHENA.MIT.EDU

I would like to briefly explore several points made by John Kohl 
and Jerry Saltzer in response to my comments on Kerberos.
Kohl proposes a counter-measure to thwart the replay threat that 
relies on servers retaining the request_ids produced by a client 
during an authenticator's replay window.  This in fact works, but in 
the interest of simplifying the counter-measure model, observe that 
the technique sets up a de facto secure connection between the client 
and server (the request_ids acting as sequence numbers).  
Connection management for this secure connection is based on a 
timer mechanism, much as timers are used for the Delta-t and VMTP 
transport protocols to manage their connection records.  One of the 
main contributions of the technical report cited in my previous 
comments is just this observation, i.e., protecting against 
communication threats is directly analogous to dealing with 
communication errors.  The main difference between the two is that 
the statistical properties of intruder-created security "errors" are 
distinctly non-random.  Thus, dealing with them can be achieved 
through the use of mechanisms, such as encryption, that randomize 
deliberate "errors."

Saltzer suggests that any mechanism used to keep clocks 
synchronized is orthoginal to the Kerberos authentication protocol.  
From a system modularity viewpoint, this is correct.  However, 
from a security viewpoint, the two are inseparable.  That is, the 
security of the authentication protocol is directly related to the 
maintenance of synchronized clocks.  In order to analyze the 
security properties of Kerberos in a given threat environment, the 
security characteristics of the clock synchronization mechanism must 
be established.

Several points of rebuttal are made that appeal to the fact that 
Kerberos only supplies an authentication service, not an 
authorization service.  However, authentication alone is almost 
useless.  It must be integrated into a system of security services, 
such as access control and accountability, that provides statistical 
assurances that resources are being used properly.  Thus, a 
legitimate question to ask is : what type of authorization mechanism 
does Kerberos naturally support and what is its security properties?  
I observed that Kerberos seems most naturally suited to work with 
access list authorization based on user identity, which has the 
undesirable transitive properties I suggest.  That is, servers 
providing a value-added service to clients by operating on client 
resources are given access to more resources than they need to carry 
out their function.  Examples are compilers, distributed database 
systems and distributed directory services, to mention a few.
That the ability to quickly revoke a user's access to distributed 
system resources is not an authentication requirement and therefore 
not a Kerberos requirement, while technically correct, also ignores 
how Kerberos will fit into the overall security apparatus of a 
distributed system.  One can imagine an authorization mechanism 
that works with Kerberos and also allows quick revocation, but it 
would very likely duplicate much of the Kerberos mechanism (e.g., 
a database under the control of a single administration, a protocol 
between servers and this database).  Duplication of this mechanism 
would increase costs unnecessarily and introduce a higher 
probability of failure of the access control system.

Both Kohl and Saltzer point out that the Kerberos protocols work 
properly regardless of the underlying transport services they use.  In 
rereading by comments on this topic I see that I fail to make the 
point I intended.  Let me try again.

Large distributed systems are composed of parts, which I shall 
call administrative domains, managed by administratively 
independent organizations.  These organizations retain control over 
the resources available within administrative domains and over the 
protocols that manage inter-resource interactions.  It is futile to 
engineer a scheme for large distributed systems that relies on the 
existence of common mechanism across all administrative domains.  
In practice interoperability must rely on the translation of services at 
administrative domain boundaries.  The reliance on a common 
authentication protocol to achieve inter-realm authentication limits 
the applicability of Kerberos to those distributed systems for which 
administrative domains support this common mechanism.  It is not 
likely that a large proportion of future distributed systems will 
satisfy this property, although portions of them may.  Thus, my 
point is that the realm concept of Kerberos is insufficiently general 
to solve many of the distributed system heterogeneity problems that 
will arise in the future.

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/