Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!agate!ucbvax!hplb.hpl.hp.com!rhc
From: rhc@hplb.hpl.hp.com (Robert Cole)
Newsgroups: comp.protocols.iso
Subject: Re: kerberos and the ISO protocol standards
Message-ID: <8912141730.AA06149@rcole.hpl.hp.com>
Date: 14 Dec 89 17:30:54 GMT
References: <891213123229.5280012c@CCC.NMFECC.GOV>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 47

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