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.