daemon@ATHENA.MIT.EDU (Robert Cole) Mon Dec 11 05:15:22 1989 To: NESSETT@CCC.NMFECC.GOV Cc: ISO@NIC.DDN.MIL, kerberos@ATHENA.MIT.EDU In-Reply-To: Your message of Fri, 08 Dec 89 12:36:37 -0800. From: Robert Cole <rhc@HPLB.HPL.HP.COM> > There has been a fair number of messages on the kerberos mailing-list that > suggest using kerberos with ISO standards. The following is an example. > Would anyone on the ISO discussion list care to comment on this concept? > Please also copy your comments to kerberos@athena.mit.edu. > Dan Nessett Dan, Work in SC21/WG1 on security is attempting to put into place a framework for security in OSI applications which can be used by all applications (FTAM, MHS, Directory, etc). This is intended to avoid each application doing their own ad-hoc solutions based (usually) on a password. One part of this framework is a document on authentication, and another on access control. The access control framework contains a concept very similar to the Kerberos ticket, but is a generalised. The Frameworks are no where near complete, and of course they do not contain any key management. In ECMA TC32/TG9 (Security in Open Systems) a standard authentication and security attribute service is being developed. This standard is intended to meet all of the functionality of kerberos, as far as possible. Where possible the architecture is similar to Kerberos. This group has just completed a standard called "Security in Open Systems - Data Elements and Services" which describes a whole set of security services needed in an open system, and the security data that is required to communicate between these services. The model in this standard is not very different from that used for Kerberos. Several things happen when a function is standardised: 1. The various processes have to be separated, key management, security data management, authentication exchanges, ticket support, etc. 2. General cases are considered and attempts made to incorporate them. 3. Implementation separated from design. 4. many others. 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. Robert (Member of ECMA TC32/TG9)
daemon@ATHENA.MIT.EDU (Karl Auerbach) Wed Dec 13 13:45:54 1989 To: rhc@HPLB.HPL.HP.COM Cc: NESSETT@CCC.NMFECC.GOV, ISO@NIC.DDN.MIL, kerberos@ATHENA.MIT.EDU In-Reply-To: Robert Cole's message of Mon, 11 Dec 89 09:31:11 GMT <8912110931.AA04275@rcole.hpl.hp.com> From: karl@ASYLUM.SF.CA.US (Karl Auerbach) > 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? --karl--
daemon@ATHENA.MIT.EDU (NESSETT@CCC.NMFECC.GOV) Wed Dec 13 16:00:15 1989 From: NESSETT@CCC.NMFECC.GOV To: KERBEROS@ATHENA.MIT.EDU 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
From: jon@MIT.EDU (Jon A. Rochlis) To: NESSETT@CCC.NMFECC.GOV Cc: kerberos@MIT.EDU In-Reply-To: Your message of Wed, 13 Dec 89 12:32:33 -0800. From: NESSETT@CCC.NMFECC.GOV Message-Id: < 891213123233.5280012c@CCC.NMFECC.GOV> Subject: Re: kerberos and the ISO protocol standards To: KERBEROS@ATHENA.MIT.EDU 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. Certificates have major advantages, it is true. However the choice of an asymetric encryption algorithm (i.e. RSA) creates tremendous legal/financial problems, while the use of DES trumps those. So far the only arangements public arrangments with RSADI (who controls the RSA patent) are for the Internet e-mail keys (at $25 a user / per 2 years). Nobody knows what arrangments can be had for any other use. While I believe the RSA problems only apply within the US (and exclude the government and MIT), that still leaves a lot of people with serious exposure if they elect to go the X.509 route ... whereas they can go with Kerberos now and not pay anybody any money. -- Jon
daemon@ATHENA.MIT.EDU (NESSETT@CCC.NMFECC.GOV) Fri Dec 15 11:46:40 1989 From: NESSETT@CCC.NMFECC.GOV To: KERBEROS@MIT.EDU Jon Rochlis writes : > Certificates have major advantages, it is true. However the choice of > an asymetric encryption algorithm (i.e. RSA) creates tremendous > legal/financial problems, while the use of DES trumps those. So far > the only arangements public arrangments with RSADI (who controls the > RSA patent) are for the Internet e-mail keys (at $25 a user / per 2 > years). Nobody knows what arrangments can be had for any other use. > While I believe the RSA problems only apply within the US (and exclude > the government and MIT), that still leaves a lot of people with > serious exposure if they elect to go the X.509 route ... whereas they > can go with Kerberos now and not pay anybody any money. Those concerned with the cost per user of $25 / 2 years for a certificate may wish to calculate the costs of maintaining a centralized KDC (including, of course, administration costs associated with installing users in the password database, such as deciding whether a user is allowed in the database at all). It also may interest those concerned with using RSA that NIST (nee' NBS) is currently working on standardizing an asymmetric encryption algorithm. There are several candidates for this standard, one of which is RSA. It seems that the government is willing to standardize patented "processes" (technically, you can't patent algorithms) as long as the cost of using those "processes" is reasonable. Dan Nessett
daemon@ATHENA.MIT.EDU (Jeffrey I. Schiller) Fri Dec 15 18:44:50 1989 From: jis@ATHENA.MIT.EDU (Jeffrey I. Schiller) To: Saltzer@SRC.DEC.COM, NESSETT@CCC.NMFECC.GOV Cc: jon@ATHENA.MIT.EDU, kerberos@ATHENA.MIT.EDU > Those concerned with the cost per user of $25 / 2 years for a certificate may > wish to calculate the costs of maintaining a centralized KDC (including, of > course, administration costs associated with installing users in the password > database, such as deciding whether a user is allowed in the database at all). To add my two bits... The $25 / 2 years doesn't include the cost associated with the administrative overhead of allocating certificates through the methods proposed in the t-mail RFCs. This has got to be a lot higher then using Kerberos, for with Kerberos a site can do all its administration electronically (through the admin tools) whereas with RSA, there is paperwork involved in dealing with RSADSI. Revocation is also an important cost. For all practical purposes all one needs to do with Kerberos if one's password is compromised, is to change it. After the longest ticket lifetime, credentials are effectively revoked. With certificates another paperwork process must be initiated to sign a new certificate (I don't know whether or not more $$$ are also needed) and a revocation list must be updated (and delivered to the services that accept certificates). MIT's Project Athena effectively gives credentials to all undergraduate students who request them. Furthermore in this environment there is a reasonable number of password change requests per day (where someone has forgotten their password and has to have it administratively changed). With Kerberos authentication we use a special application that allows new users to be automatically added to the authentication database given the knowledge of their name and MIT ID number. A separate database of names and ID numbers is consulted to verify if in fact the requester is a student, and they don't already have a credential (thus their name and ID number are in effect a "weak" credential). If they forget their password they need to contact the "Accounts Consultant" to have it changed. Needless to say the cost per user (about 10,000 users are registered) is quite small. If we used certificates we would have to scrap our automated account creation software (or teach it how to write checks and mail them :-) ) and replace it with a manually, and therefore costly in staff time, system. Our revocation list would also be quite large. In this environment the cost differential between Kerberos, a "free" system, and RSA based certificates is quite large. -Jeff