Path: utzoo!attcan!uunet!lll-winken!ames!eos!shelby!NSFNET-RELAY.AC.UK!jhs%computer-lab.cambridge.ac.uk From: jhs%computer-lab.cambridge.ac.uk@NSFNET-RELAY.AC.UK (Jerome H Saltzer) Newsgroups: comp.protocols.kerberos Subject: some comments on Kerberos Message-ID: <8905101146.AA05099@uk.ac.cam.cl.dovey> Date: 10 May 89 11:46:13 GMT References: <890509181345.2660012a@CCC.MFECC.LLNL.GOV> Sender: daemon@shelby.Stanford.EDU Organization: The Internet Lines: 146 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