[4968] in Kerberos

home help back first fref pref prev next nref lref last post

Re: more k5 complaints

daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Apr 13 13:49:19 1995

Date: Thu, 13 Apr 1995 11:39:25 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Joe Kovara <joek@kerby.ocsg.com>
Cc: kerberos@MIT.EDU
In-Reply-To: Joe Kovara's message of Sat, 8 Apr 1995 19:24:51 -0700,
	<Pine.SUN.3.91.950408181740.3071A-100000@kerby.ocsg.com>

   Date: Sat, 8 Apr 1995 19:24:51 -0700
   From: Joe Kovara <joek@kerby.ocsg.com>

   On 14 Mar 1995, Daniel G. Pouzzner wrote:

   > I agree whole-heartedly with your estimation that k5's flab has not
   > been justified with a concomitant qualitative increase in
   > functionality.  My impression is that the usual version inflation,
   > combined with support for isode and gssapi, plus the inevitable krb524
   > compatibility, plus some minor increases in functionality, have
   > rendered Kerberos 5 as bulky and obscure as everything else out there
   > (AFS and X come to mind). This is unfortunate. [...deleted...]

Let me add a couple of points to Joe's response.

First of all, the MIT implementation of Krb5 is still under development,
and if you look at more recent versions, I think you'll will a dramatic
improvement.  For one thing, ISODE is no longer used.  For another, we
are working on trying to tighten up the "flab" and the memory leaks in
our existing version.  But that's one of the reasons why we are still
labeling our release as "beta".  It's still being worked on.

   2.  The "GSSAPI support" in K5 is not really part of K5, but--I
       believe--an artifact of the imlpementation.  

It's not even an artifiact of the implementation.  The "GSSAPI support"
is one extra library; one extra directory; which applications can either
use or not use.  If applications don't want to use the GSSAPI
specification, they can code to the Kerberos V5 native API.  

   Building an efficient and robust K5 doesn't take rocket science
   (although all here at CyberSAFE like to think we're pretty good).
   Nor is there anything in RFC1510 which prevents it (although ASN.1
   can be a real challenge).  What it takes is work and commitment.
   Whew!

Agreed, 100%.  And there are people who are working on making good,
efficient Krb5 implementation available, both commercial and free
implementations.  We're getting there.... perhaps more slowly than we
would have liked, but we're getting there.

							- Ted

home help back first fref pref prev next nref lref last post