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