[4949] in Kerberos
Re: more k5 complaints
daemon@ATHENA.MIT.EDU (Joe Kovara)
Sat Apr 8 23:21:16 1995
To: kerberos@MIT.EDU
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...]
Please don't blame the K5 protocol for problems specific to an
implementation. Others in this thread have pointed out some of
the benefits K5 has over K4. I'll simply say that CyberSAFE
(previously Open Computing Security Group), started out offering a
commercial K4 product. We moved to offer a K5 product as quickly as
possible because of problems with K4. We've put a great deal of
work into making K4-K5 coexistence and migration as painless as
possible because we feel it is important that K4 sites move to
K5 as quickly as possible.
As for implementation specifics:
1. The Byzantine structure of the cred cache, keytab and replay code
can be overwhelming. But the concept is good. The ability to
handle variants is especially useful when, e.g., implementing
a cred cache or keytab file which is maintained by external
hardware (such as a crypto-capable smart card).
2. The "GSSAPI support" in K5 is not really part of K5, but--I
believe--an artifact of the imlpementation. The "raw" DES
support (which is what I believe is being referred to)
appears to have been added because it was near impossible to
extract the necessary underlying crypto code from K5. (Hey,
what's another few lines of code? Welcome to the cut-and-paste
method of software development. Sorry, couldn't resist that one.)
Please note that this is conjecture on my part.
3. CyberSAFE's new K5 implementation is more complete (reentrant,
thread-safe, transport-independent, full ticketing options
support, and yes, even multiple types of cred/keytab/replay).
And it's still _much_ smaller, faster, more robust, more
portable, and easier to use (did I leave anything out?) than
any other implementation that I am aware of.
I think that K4 fans would be pleasantly surprised.
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!
Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
