[722] in Kerberos
RE: comments on my comments
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.
