Porting Heimdal's libkafs to MIT Kerberos

[Sam Hartman]

>>>>> "Steven" == Steven Michaud <smichaud at pobox.com> writes:

    Steven> Thanks for the quick answer.
    >> I just don't see anything you gain from folding it into the
    >> main Kerberos distribution.

    Steven> Until I'd read Darren Tucker's note
    Steven> (http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=107363804131871&w=2),
    Steven> and also Ken Horenstein's, I'd have been inclined to
    Steven> agree.  Now I see that you gain the ability to use
    Steven> krb5-config in your configure script.

    Steven> The author of a libkafs port would (at the very least)
    Steven> have to detect and alter an existing MIT krb5-config
    Steven> script.  But maybe this could be done without actually
    Steven> patching the MIT distribution.  For example, you could
    Steven> capture the output of the existing krb5-config script,
    Steven> then rewrite it to add flags for your libkafs port (you
    Steven> could even "borrow" most of the code to do this from a
    Steven> recent MIT Kerberos distribution).  Is the kind of
    Steven> solution you would suggest?

No, absolutely not.  AFS support has no business in krb5-config at
all.  I believe the Heimdal folks made a bad design decisions by
putting it there.

MIT would be very upset with someone who replaced our krb5-config or
patched it.  If you are going to be a Kerberos implementation it is
reasonable to provide krb5-config.  But krb5-config is for the
Kerberos implementation to provide, not some third-party library..

Fundamentally we're in this mess because the OpenAFS project has
resisted adding Kerberos dependencies to AFS.  IT's a hard problem and
I respect that they don't have the resources to do it.  But putting
the problem off on the Kerberos vendors is also not OK.

Kerberos has one fundamental interaction with AFS.  The krb524d
supports a special protocol for AFS tickets because of the v4
transited realm attack; this is a very big hack but besides this,
there is no reason the MIT libraries or KDC needs to know about AFS.

MIt developers currently are AFS users and some of us are familiar
with AFS issues.  There is no guarantee this will remain true.

Why is AFS special besides historical reasons?  Other than historical
decisions, why should Kerberos implementations contain code to deal
with AFS rather than AFS implementations contain code to deal with
Kerberos?  If MIT chooses to integrate this code how will we avoid
opening the floodgates to vaguely related technologies?


So, what would I like to see happen?  I'd like to see AFS
implementations pick up libkafs or some similar functionality.  I'd
like to see them provide a tool for finding afs libraries including
libkafs.


I'm open to arguments about why the Heimdal design decision is
 correct.  I have already considered the historical argument.  

All the above not withstanding, MIT Kerberos is open source software.
 You can take it and modify it as you see fit.  We don't have to take
 your patches; you don't even have to offer them or allow us to take
 your patches even if we want them.  We'll cooperate more with people
 who are working in the same direction we are, but you can always go
 take our code and do whatever you want with it.



--Sam