Re: documentation vs specification

Thanks Jeffrey,

Your comments give an important insight.

On Mon, Oct 03, 2011 at 10:11:46AM -0400, Jeffrey Altman wrote:
> On 10/3/2011 9:29 AM, <[email protected]> wrote:
> > It is plain unwise that part of the protocols remain undefined
> > (and are being reverse-engineered) even today. This is not a matter of
> > documentation, this is a matter of a missing specification.
> 
> Credential cache and keytab file formats are not protocols.  They are
> implementation specific data formats in exactly the same fashion as the
> krb5 api is an implementation specific api.  These are outside the
> bounds of what the IETF standardizes.

Right. But they _are_ being used like protocols. It is apparently a
"reverse-engineering miracle" that my applications work properly despite
ccache with tgt coming from MIT or Heimdal-libraries (which changes from
day to day) and with different applications running in parallel being
linked to different libraries too.

So if IETF can not standardize this, Kerberos team might use at least
some specification to move it from "miracle" to "quite reliable".
Of course it makes sense only if interoperability between implementations
is valued, including applications run by a user in the same session.

> The problem is that there is no standardization process for
> implementation specific data stores.  The credential cache file format
> of MIT's is really no different then their KDC database format.  Its a
> proprietary internal that uses an api with behaviors that are their own.

Which Heimdal and Shishi apparently thoroughly imitated.

> are other credential cache implementations.  Personally, I believe that
> credential caches and key tables should have platform specific
> implementations which the Kerberos implementations simply call into.

This implies a constraint of being compatible with _the_actual_host_
plugin architecture and software setup. A dependency on the actual host
custom setup is nothing which Kerberos functionality (authentication
with the help of a trusted third party) needs by design. You seem to
propose to introduce such dependency.

Some of my applications are linked against Heimdal and uClibc statically
and work just fine on virtually arbitrary Linux host. What you propose
would very efficiently disallow this kind of use. So "host-provided
plugins" is no adequate "replacement" for file caches.

> This is in fact how credentials caches are being used in the Heimdal
> port for Windows.  Credential cache implementations are plug-ins.

I guess it is Windows which forces you to use their API to cooperate
with their implementation of Kerberos or just to be able to share the
credentials between processes. Then this is a pityful platform constraint.

This does not look like a solution which would be good for other situations:

As a user I need to be able to run Kerberos applications even on hosts
where the administrator can not be bothered and/or where he or she has
no knowledge of Kerberos.

It works fine for me today as my applications use file ccache
for communication of the credentials - but would not work if it is
"the platform" (== "the host"?) who would be to provide a "proper and
compatible ccache communication plugin". No way.

> Choose one of the existing implementations or write one that meets your
> needs.  Then plug it in.

Plugin or not plugin does not help interoperability per se.

> You can't solve the problems of this thread using file caches.

My problems _are_ being solved using ccaches. I am in fact reasonably
happy with the result. I am unhappy with the state of the affairs when
my happiness (and happiness of my users) depends on teams of developers
(Heimdal and Shishi) having to reverse engineer and track what a third
team (MIT) chooses, apparently without any cooperation with the others'
efforts.

I am surprised (also that it took years for me to discover this fact).
Thanks for opening my eyes.

>  Use KCM

Is there KCM for MIT? Are MIT and Heimdal KCM compatible on the wire? Can
KCM be usable without being root on a multiuser machine? May the source
be with me...

KCM may also be a wrong tool for me if its main purposes are
(http://mailman.mit.edu/pipermail/krbdev/2005-November/003864.html)
> KCM is a credential caching daemon that provides these features,
>- Acquiring the tickets for the system (workstation) principal during
>the start-up
>- Changing the system principal password
>- Automatically renewing the tickets

This is not what I need for running user applications on an arbitrary host.

Ccache feels also more convenient than checking whether there is a KCM server
running and starting one, then taking care of shutting it down at logout
and things like that.

> There is not one MIT FILE ccache format.  The format has changed
> numerous times over the years.

Then I have had enormous luck that Kerberos worked for me, as it almost
never was "pure MIT" or "pure Heimdal".

>>>2. assume that all
>>> applications sharing kerberos-related data use One True Implementation.
...
>>> The second assumptions is not true, and it is actually Heimdal who first
>>> broke it.

>> Heimdal did not break anything.

May be I was misunderstood? It is with Heimdal's arrival the assumption
of a single "One True Implementation" of Kerberos could not hold any longer.
Or would it?

Regards,
Rune