NESSETT@CCC.MFECC.LLNL.GOV (05/11/89)
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.