NESSETT@CCC.NMFECC.GOV (12/14/89)
Quoting Robert Cole, Karl Auerbach writes: >> Thus it is not possible to 'standardise' kerberos, nor really possible >> to specify its use in a standard. > ???? Has the "standards" process reached the point where existing work > is not elegible? Rather a "standard" must be new? Is somebody > suffering from not-invented-here syndrome? I believe Karl quotes Robert Cole out of context. The full quotation reads : > Thus it is not possible to 'standardise' kerberos, nor really possible > to specify its use in a standard. But it is possible to contribute to > the standards activities in the area and to ensure that the resulting > standards meet the requirements which Kerberos was designed for. Standards are by nature agreed upon by a wide community. Participation in the standards process guarentees only that your views will be heard and that your requirements will be met (if they don't conflict with other requirements). In the case of security in distributed systems, there is already a standard that provides a foundation upon which can be built systems with the functionality of kerberos. This is the X.509 standard, which forms part of the X.500 directory service standard, and which uses public-key encryption to sign 'certificates' binding a user's name with a public-key. Implementations of X.509 are in approximately the same stage of development as kerberos, although slightly behind. While the developers of kerberos are to be congratulated for their industry and appreciation of the significance of the distributed systems security problem, the certificate approach is much more likely than kerberos to be used in ISO standards. Dan Nessett
rhc@hplb.hpl.hp.com (Robert Cole) (12/15/89)
Thanks for correcting that missquote, but I have comments on your additional notes. > Standards are by nature agreed upon by a wide community. Participation in th e > standards process guarentees only that your views will be heard and that your > requirements will be met (if they don't conflict with other requirements). > In the case of security in distributed systems, there is already a standard > that provides a foundation upon which can be built systems with the > functionality of kerberos. This is the X.509 standard, which forms part of > the X.500 directory service standard, and which uses public-key encryption to > sign 'certificates' binding a user's name with a public-key. Implementations > of X.509 are in approximately the same stage of development as kerberos, > although slightly behind. > While the developers of kerberos are to be congratulated for their industry a nd > appreciation of the significance of the distributed systems security problem, > the certificate approach is much more likely than kerberos to be used in ISO > standards. The certificate approach of X.500 is not a solution to many security problems. In fact it only provides a very crude key distribution mechanism. The security work in SC21 is looking for a uch more generic solution, in which security information is encoded in a general format. One part of that format might be an X.500 certificate, another format might look like a Kerberos ticket. X.500 doesn't address who generates the information, who consumes the information, how the information is protected in different ways, etc, etc. At the recent Florence meeting a people from the security and directory groups got together to convince the directory people that there is a larger security problem and to address the issue of securing the directory iteslf. I would like to stress that the Kerberos people have a lot of experience to offer the standards activities. I would also like to stress that NO ONE should be niave about submitting an existing system and expecting it to be accepted as a standard without change. Ask Xerox about their experience in standardising computer mail! What should not happen is that the designers of system can assume that the superiority of their system will, without any effort on their part, be adopted as a standard. This is not about NIH, it is about heads in the sand! Robert Robert
karl@asylum.sf.ca.us (Karl Auerbach) (12/16/89)
> I would like to stress that the Kerberos people have a lot of > experience to offer the standards activities. I would also like to > stress that NO ONE should be niave about submitting an existing system > and expecting it to be accepted as a standard without change. It is too bad that the "standards" efforts going on in the communications area are not codifying tried-and-true experience -- which I assert is the proper and correct role of "standards" activity. Instead it seems that the so-called standards groups insist on performing reasearch. What is wrong with "standardizing" Kerberos? A standard only provides a clear statement of the workings and interfaces of a mechanism -- it is not an endorsement that it is the best way to solve a problem. If two people then chose to use it, they then have a common frame of refererence. And they will be able to get on with whatever larger job they have at hand. Again, I believe that the "standards" groups are suffering from a very serious, and very expensive case of "not invented here". --karl--
rhc@HPLB.HPL.HP.COM (Robert Cole) (12/18/89)
> It is too bad that the "standards" efforts going on in the > communications area are not codifying tried-and-true experience -- > which I assert is the proper and correct role of "standards" activity. > Instead it seems that the so-called standards groups insist on > performing reasearch. > What is wrong with "standardizing" Kerberos? A standard only provides > a clear statement of the workings and interfaces of a mechanism -- it > is not an endorsement that it is the best way to solve a problem. If > two people then chose to use it, they then have a common frame of > refererence. And they will be able to get on with whatever larger job > they have at hand. > Again, I believe that the "standards" groups are suffering from a very > serious, and very expensive case of "not invented here". > --karl-- You seem to be fairly convinced that standards makers are all luddites, no doubt you have been attending too many standards meetings. However I will try to explain why input to standards gets changed, and why it is not as expensive as you would believe. First, you must realise that having more than one standard for anything is as bad as having no standard. A manufacturer will have to support all standards in a product. Lets imagine there are 3 standards for screw threads, one metric and two imperial. Then a nut manufacturer has to meet all three standards in all sizes of nuts, regardless of demand! The same would be true if there were several authentication standards. If you sold a product requiring the use of authentication you would have to asupport use of all the standards because you could not anticipate which authentication standard your customers authentication server would use at any time. Clearly this is expensive and you know who will pay. Given that only one standard will be acceptable, you then have to decide on it in a democratic manner. There are two pressures on a standard: 1. from those with existing activity in the area, I am fairly confident that Kerberos is not the only authentication system which has vested interests; 2. from those who want to see the standard somewhat future-proof by making the standard more general than any individual application would seem to warrant. Given that any input to a standard must be from a vested interest with a limited application, or from a theoretical standpoint looking for generality you can see that if democratic principles are to apply then there must be compromises. Consequently you cannot have back what you first thought of. I hope you agree that democracy and economics are best served by a single standard that meets the perceived needs of the widest community. Have a happy Christmas, Robert.
galvin@TIS.COM (James M Galvin) (12/18/89)
> I would like to stress that the Kerberos people have a lot of > experience to offer the standards activities. I would also like to > stress that NO ONE should be niave about submitting an existing system > and expecting it to be accepted as a standard without change. It is too bad that the "standards" efforts going on in the communications area are not codifying tried-and-true experience -- which I assert is the proper and correct role of "standards" activity. Instead it seems that the so-called standards groups insist on performing reasearch. I would offer a slightly different observation. If we are going to criticize "standards" activities, it is important to understand them. In fact, "standards" activities do try to ensure that no single commercial organization has an advantage over any other. If they did not, why would anyone participate. This is not to say I agree with them, but I would hardly call that research. Jim
hagens@CS.WISC.EDU (12/19/89)
> What is wrong with "standardizing" Kerberos? A standard only provides > a clear statement of the workings and interfaces of a mechanism -- it > is not an endorsement that it is the best way to solve a problem. The Internet has this distinction. ISO does not. Rob Hagens
karl@asylum.sf.ca.us (Karl Auerbach) (12/19/89)
> You seem to be fairly convinced that standards makers are all > luddites ... I am convinced of their sincerity, but not of their competence. I strongly subscribe to Marshall Rose's notion of "doers" and "goers". > First, you must realise that having more than one standard for > anything is as bad as having no standard. I disagree. It is good to have concise standards that do exactly the job at hand, not monstrosities that try to solve everything. That's why there are umpteen standards for screw gauges, strengths, etc. So I can buy exactly what I need. That's why there are so many different types of airliners, automobiles, screwdrivers, and medicines. We will need several authentication standards -- as there need to be several levels of trust/believability. Third party schemes will be necessary at times and two party schemes will be necessary at others. Simple handshakes at the front may be adequate for some, and continuous, repeated challanges necessary for others. Since tools tend to be built to do the job intended, the builders will select among the workable standards for the best for the job. There won't be the situation you describe where every tool will have to speak every authentication language. Rather, a tool will talk to its peers who have (perhaps informally) selected the same security standard. > Clearly this is expensive and you know who will pay. This OSI stuff is expensive -- it is damaging real networking, and GOSIP is going to cost the US and the UK and other nations a major bundle. The IBM-like "fear, uncertainty, and doubt" that you are trying to cast on Kerberos (because it is "non standard") is harming people who need added security TODAY. Give Don Parker at SRI or Jay Blumbecker (sp) in LA a call to get some numbers about the loss per day because of security problems in today's systems. The time to reach one, single, perfect standard is wasting big $$. > Given that only one standard will be acceptable... Wrong -- the OSI folks may reach one "standard" under their banner, but there will be other proposals, for instance Kerberos, and the market will chose. Take a look at the ANSI or ISO catalogues. You will see hundreds of standards that didn't make in the big world. > 2. from those who want to see the standard somewhat future-proof by > making the standard more general than any individual application would > seem to warrant. I spent nearly ten years the the business of network and operating system security. I have never seen any evidence that there can be any all-purpose solution. You are looking for the pot at the end of the rainbow. > then there must be compromises. and that is why there can not be one security standard. Many people will have needs which do not comport with the committee's choices. > I hope you agree that democracy and economics are best served by a > single standard that meets the perceived needs of the widest > community. No I don't. Particularly not for security. Indeed one the the best ways to get a secure system is to have multiple layers (or "firewalls") using different security techniques at each layer. --karl--
mrose@CHEETAH.NYSER.NET (Marshall Rose) (12/19/89)
Jim - there are three cases of standardization work: 1. Where there is exactly one de facto standard for a particular kind of technology. In this case, standardization is fairly straight-forward. 2. Where there is more than one way of doing it in use, e.g., CO- and CL- mode networking. In this case, the committees often take the bells and whistles of each, e.g., the OSI network layer. 3. There there is no de facto standard, e.g., the application layer framework. In this case, the committees often engage in what might be mistermed "research", e.g., the OSI appliation layer structure. Your analysis is correct in case 1. In cases 2 and 3, we usually get truly horrible stuff (e.g., the OSI network layer and the OSI appliation layer structure) for different reasons, which should both be obvious. /mtr
jtw@LCS.MIT.EDU (John Wroclawski) (12/19/89)
Date: Wed, 13 Dec 89 12:32:29 PST From: NESSETT@ccc.nmfecc.gov Comment: From NESSETT@CCC.MFENET on December 13, 1989 at 12:32 PST [Lots of quotes removed] In the case of security in distributed systems, there is already a standard that provides a foundation upon which can be built systems with the functionality of kerberos. This is the X.509 standard, which forms part of the X.500 directory service standard, and which uses public-key encryption to sign 'certificates' binding a user's name with a public-key. Implementations of X.509 are in approximately the same stage of development as kerberos, although slightly behind. While the developers of kerberos are to be congratulated for their industry and appreciation of the significance of the distributed systems security problem, the certificate approach is much more likely than kerberos to be used in ISO standards. It is somewhat interesting in the context of this ongoing attempt to justify protocol development in the guise of standardization to note that X.509 has recently been shown to have at least two "weaknesses" which were presumably not anticipated by the authors (See Burrows, Abadi, and Needham, "A Logic of Authentication", in Proceedings of the 12th ACM Symposium on Operating System Principles). This sort of thing seemed to happen less back in the days when standards were derived from existing widely accepted and well understood designs, rather than being created from scratch... John Wroclawski MIT Lab for Computer Science
barmar@Think.COM (12/19/89)
In article <8912180840.AA09995@asylum.sf.ca.us> karl@asylum.sf.ca.us (Karl Auerbach) writes: >> First, you must realise that having more than one standard for >> anything is as bad as having no standard. >I disagree. It is good to have concise standards that do exactly the >job at hand, not monstrosities that try to solve everything. That's >why there are umpteen standards for screw gauges, strengths, etc. So >I can buy exactly what I need. That's why there are so many different >types of airliners, automobiles, screwdrivers, and medicines. One must distinguish standards whose purpose is heterogeneous interoperability, such as those for communications. You're right that multiple standards permits you to specify more precisely just what you need. But in communications one often needs everything. If you anticipate trying to communicate with devices outside your jurisdiction then you must be prepared to use a protocol compatible with those other devices. If all you care about is communication within your environment then multiple standards aren't as big a problem, since you can make sure that all the devices are compatible. Consider character sets: there are only two standards (ASCII and EBCDIC), yet this can cause major hassles. >We will need several authentication standards -- as there need to be >several levels of trust/believability. Third party schemes will be >necessary at times and two party schemes will be necessary at others. >Simple handshakes at the front may be adequate for some, and >continuous, repeated challanges necessary for others. And what happens when a machine using two-party authentication tries to talk to one that requires a third party? Rather than having multiple standards, there should be one standard with several modes. A good example is TELNET, which is a single standard but has option negotiation that can vary the protocol. Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar