Re: documentation vs specification

Greg Hudson <[email protected]> writes:

> The MIT krb5 team is quite aware that Heimdal and Shishi share its
> credential cache file format.

Java Kerberos as well.

> The last time MIT krb5's format changed was in 1995(*), and we are
> unlikely to change it again without serious consideration for
> compatibility on the part of all implementations.  Part of the reason we
> haven't formally documented it is that Simon did it for us in the Shishi
> documentation.  (It would certainly be better if it were specified as
> part of our own documentation, or in some kind of neutral implementation
> standard document; that's just a matter of resources and priorities.)

> (*) Support for "configuration values" was added a couple of years ago.
> This is technically layered on top of the file format, but does affect
> code which lists a ccache.  Heimdal implemented this first and MIT krb5
> followed its lead.

Also breaks Java, to mention.  :)  If one obtains a Kerberos ticket cache
with a version of Kerberos that puts that configuration information into
the cache, Java 1.5 will explode (with a DER decoding error) when
attempting to read the ticket cache.  At least in the first round of that
implementation in MIT as released with Ubuntu; I'm not sure if there have
been later tweaks.  (Java 1.6 is fine with it, IIRC, and I think this was
always a bug in Java, not actually a problem with the concept.)

> MIT krb5 does have Linux kernel keyring support, but of course that
> would be restricted to a single kernel.

KCM is nicer and easier to use than the keyring support from an
application perspective since it can take care of credential acquisition
and renewal as well.  The keyring stuff is arguably more secure.

Both I think miss the PAG concept that AFS has.  While the additional
granularity between processes with the same UID is not a security measure,
it is very convenient when one wants to take on multiple identities while
doing different things and be sure that one doesn't accidentally get the
wrong one.

-- 
Russ Allbery ([email protected])             <http://www.eyrie.org/~eagle/>