NESSETT@CCC.MFECC.LLNL.GOV (05/10/89)
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.
jhs%computer-lab.cambridge.ac.uk@NSFNET-RELAY.AC.UK (Jerome H Saltzer) (05/10/89)
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
jtkohl@ATHENA.MIT.EDU (John T Kohl) (05/10/89)
... 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 <n> minutes (where <n> 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
boomer@athena.mit.edu (Don Alvarez) (05/12/89)
In article <8905101146.AA05099@uk.ac.cam.cl.dovey>, jhs%computer-lab.cambridge.ac.uk@NSFNET-RELAY.AC.UK (Jerome H Saltzer) writes (in reference to posting by Nessett) >> 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.) Keys can not be convincingly hidden with current generation hardware. If you have no dedicated security hardware, then all your local key protection must be done in software, with the obvious risks. Smartcards have received lots of attention, but they exhibit the same weakness. There still needs to be some call by which "application process space" can ask the smartcard to generate tickets for new services. It is conceptually no more difficult to massage the kernel into allowing a fraudulent call than it is to massage the kernel into divulging a secret key. Even if you do give yourself a full dedicated security supervisor module which watches the main host processor and validates its actions, then all you are doing is passing the buck to the guy who has to make sure that the supervisor code doesn't get modified. Any secrets by which a user validates his actions must pass through the host (or transceiver, or whatever). Once he hands his secrets over to the host, he has no way to force it to use them honorably, because it knows all the secrets he knows. The best you can do with secrets is make it very hard for someone to rewrite the software which protects them. You can't make them absolutely safe. In the limiting case where you are willing to give me a soldering iron and EPROM programmer, the only way you can protect your secrets is by never logging in. (for an interesting example, note that all retina recognition does is prove that you are sitting at your terminal...it can't prove that you were the one who stuffed 'rm *.*' into the keyboard buffer) -- + -------------------------------------------------------------------------- + | Don Alvarez M.I.T. Center For Space Research (617) 253-7457 | | boomer@SPACE.MIT.EDU coming soon: Princeton University Dept. of Physics | + -------------------------------------------------------------------------- +
bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman) (05/17/89)
I found your comments interesting. I will attempt to answer a few of them here. Some of my comments duplicate those of others, and for that I apologize. Anyway, o Kerberos keeps its encryption keys in application process space. If you don't trust the workstation, application space is no less secure than kernel space. The only solution requires that the user's key never leave a trusted system, and this can only be accomplished using an approach such as having a smartcard do all the encryption and decryption, as well as having it maintain the list of session keys associated with each ticket. The smartcard is the trusted system in this case, and it is trusted because it is always in the user's possession. Don Alvarez points out that even with a smartcard, there is still the vulnerability of a system making unsolicited requests on behalf of a logged in user. The smartcard would happily provide the authenticators. As you can see, there is no absolute solution. One can simply get closer and closer to absolute security with greater and greater effort. 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. The IP address is included to make it slightly more difficult to use credentials stolen from a workstation. It is recognized that it only makes it difficult, not impossible. It is only when credentials are stolen through some mechanisms external to Kerberos that an attacker would have such credentials anyway. Replays are prevented through separate mechanism. As was already pointed out, the Kerberos protocol requires that the end service keep a list of the timestamps from those authenticators accepted within the acceptable timeframe. Unfortunately, this did not seem to get implemented. 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. Clocks must be synchronized using a mechanism that is itself authenticated. Although such a timeservice has not been implemented, it can be authenticated using Kerberos since it is the timeservice that must be authenticated, and not the user. The timseserver can ignore time skew on requests for the time. The client must specify that mutual authentication is requested. This results in a response coming back authenticated by including of the workstation's (old) timestamp + 1 encrypted in the session key. The actual response itself should also be encrypted in that key. 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). We specifically decided that this was not a requirement for Kerberos. In order to make the revoking of access have an immediate effect would require that the authentication server (AS) be involved with every service access. This would either be accomplished by having the end service check with AS each time, or by making the ticket obtained by the user valid for only a very short period of time. 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. This is a very interesting comment. Your point that Kerberos favors an access control list approach to authorization is quite accurate. The transitivity problem you mention is part of the proxy problem (which is being considered in the protocol revision). The way you phrased the problem got me to thinking, and I came up with an interesting way to solve it. I will discuss that in my next message (as a new proposal). Anyway, I hope that these comments sufficiently answered those comments that I chose to address. ~ Cliff
Mills@UDEL.EDU (05/17/89)
Cliff, Your statement that an authenticated time service has not been implemented may be in error. Version 2 of the Network Time Protocol (NTP) does in fact include an authentication feature based on DES crypto-checksums. This version is now in beta test and is expected soon to become the official version and obsolete the Version 1 specification of the protocol. Now, you folks can tell me how to manage the key distribution... Dave
bcn@JUNE.CS.WASHINGTON.EDU (Clifford Neuman) (05/18/89)
The comment by Dan Nessett is quite accurate. You do need a mechanism to prevent replays. Looking through your paper, I see a way to accomplish this, but it requires me to make a few assumptions which were not specified. From you paper, I get the impression that the authentication provided is intended for internal authentication between a group of timeservers. Extending it to the end user results in the key distribution problem you were asking about. First, for the techique to prevent replays within your protocol. It requires that the party receiving each authenticated message keep track of the last message received under that key. Further, it must make sure that the time in such messages is always increasing. This will prevent replays, but you must still provide some mechanisms to prevent deliberately delayed packets from causing problems. This might not be a problem for your protocol, but I would have to look at your entire protocol to determine that (and, unfortunately, I don't have the time right now). If you are not going to require that servers maintain the time from the last message received under each key, you will have to use a challenge response mechanism using a nonce of some kind. When requesting the time, the client sends a nonce which is included encrypted with the response along with the encrypted timestamp (or checksum of the timestamp). You would have to make sure that the encrypted timestamp can not be modified without causing the nonce to change, but this can be accomplished with an appropriate ordering of fields and the use of a suitable encryption chaining method. This approach would require a different format (and probably length) for your message authentication field. I actually think you would be much better off if you left the contents and length of the authentication field open, and include a field indicating type of authentication used. This would allow you to push both problems off to a separate authentication protocol. You might then want to suggest the use of two such protocols. The first being one of the low overhead ones just described for use between timeservers. The second would be one incorporating key distribution. It would be used by the end user. Kerberos could be used for the second protocol. The timeservice would be interesting in the sense that it is more important to authenticate the service than the user. In fact, the timeserver itself probably doesn't care who the user is. Anyway, to use Kerberos, the request to the timeserver would include the client's ticket and authenticator. By decoding these credentials, the timserver would obtain the session key and the client's timestamp (which for mutual authentication purposes is equivilant to a nonce). The response would then be the same as in the challenge response protocol described above except that the key would be the session key, and the nonce would be the client's old timestamp. ~ Cliff
Mills@UDEL.EDU (05/18/89)
Cliff, Thanks for your comments. Here are a few comments in response. My model for users/servers in NTP is that the users ARE the servers - there is no intended distinction, other than keying compartments and subnet hierarchy. You might want to declare the servers at the leaves of the tree to be users and the rest to be servers, but that is dangerous, since a failure can reorganize the tree and change leaves into nonterminal nodes and vice versa. NTP peers do keep the last message, more precisely, the last originate and the last transmit timestamp. This is sufficient to (a) authenticate the original sender and (b) detect and discard replays. It is hard to distinguish normal network delay dispersions from deliberate hostile delays. The various filtering and selection algorithms have been developed to deal with this issue, but the peformance must be evaluated statistically. Our experience is that they do a pretty good job in the existing Internet, but we have no way to know if somebody out there is tinkering with delays just to force us to develop better algorithms or similar nasty agenda. In any case, the local-clock mechanism described in the document and in use at all servers I know about prevents the clock being set backwards or even forwards beyond a selectable sanity interval (currently 1000 seconds). Your suggestion on using selectable algorithms, as well as keys, is intriguing. I argued against that on the basis that clock synchronization should be a ubiquitous service, since it relies so heavily on redundancy and diversity to detect falsetickers, prevent timewarps and improve accuracy. Having pockets of less robust time in order to reduce vulnerability strikes me as less of a time synchronization protocol than an event ordering protocol. Perhaps NTP in its present form represents a compromise between these two objectives. There are some technical issues about the authentication mechanism I am hoping the Privacy Task Force will comment upon. The use of a default key in order to initialize the association and also to provide a debuggning aid for new implementations (we found that feature absolutely wonderful) may represent a vulnerability, as may the scheme where the key selection is determined by association mode, as well as key identifier. These gizmos were incorporated to simplify key management and network monitoring. We still need to explore how to align NTP with the Kerberos paradigm and how to manage key distribution, perhaps along the lines suggested for private mail. Heck, we are still sloshing Steve Deering's multicast issues. NTP seems to have the right characteristics to become a litmus test for many of these distributed protocol issues now coming up in Internet research. Dave