The challenge of trundling forward with Kerberos integration.

[g.w@hurderos.org]

Good day to everyone, I hope the weekend is going well or the week is
starting well depending on when you read your mail.

This note is a bit delayed from the discussion on the Kerberos
development list which inspired me to write it.  I spent some time
reflecting on the issues after reading all the material in the
previous thread.  Sending this note was prompted by the post Andrew
Bartlett sent this week describing progress with the Samba4 specific
KDC.

I'm sending this note with the hope it will inspire some dialogue on
how the general problem of integrating LDAP and Kerberos services can
be addressed in an architecturally sound fashion.  There is little
doubt, at least in the enterprise setting, that the future for
architecting information delivery systems is going to involve close
integration of technologies which deliver identification,
authentication and ultimately authorization services.

As some of you may know our Hurderos Project is working to develop an
open-architecture system for implementing identity.  The premise of
our project is that in the field of identity management the cart has
gotten ahead of the horse.  The majority of effort has gone into
solving the important but somewhat uninteresting problem of conveying
identity information or making assertions about identity.

Methods of conveying identity, ie. WS-security/InfoCards,
SAML/Shibboleth-LA, PKI/Globus-GRID have thus developed without a
clear understanding of how to securely implement identity.  Our belief
and findings is doing the latter makes the former much easier.

Like Samba4 and undoubtedly other initiatives to come, our project
requires tight integration between LDAP and Kerberos.  Unlike Samba4
we have deliberately chosen to develop on the predicate of a very
modular architecture.  Our goal was to have designated interfaces
between various sub-systems which allow these systems to be changed
out according to the architectural mandates of the organization.  An
architecture, if you well, for how identity information is
manipulated.

With that said I understand the reasoning on which Tridge and company
made their decision to move forward.  Our concerns with the direction
of Samba4 are more in its general goal of trying to clone AD with its
resultant architectural and potential IP problems.

Necessity is the mother of invention and the incentive for Samba to
implement an amorphous design is due to the long history of
identification and authentication technologies living in silos.  It
would seem to be in everyone's interests to 'break down the walls' if
you will and provide mechanisms for these technologies to interoperate
properly.

Hurderos provides a mechanism for ticket based authorizations like
Samba4/AD.  The primary difference being that our authorization
payloads are actually a service instance specific identity which is
genetically derived from the user's identity and the identity of the
service being requested.  Like Samba4 we need to have the KDC interact
tightly with an LDAP directory server in order to implement this
functionality.

When we started our reference implementation last September I
contacted Sam Hartman at MIT to find out their druthers for how they
would like to see this done.  Sam indicated they didn't like the idea
of 'patched' KDC's and instead had a vision for a 'plug-in'
architecture for making extensibility enhancements to the KDC.  Since
we needed to do a dive into the MIT sources in either case it seemed
wise to code up our extensions on top of some sort of extensibility
architecture.

After a couple of weeks of effort we came up with a very plain jane
architecture for bolting extensions onto the KDC and kadmind using
dynamically loaded shared libraries.  Our Kerberos enhancements which
include identity translation in the AS_REQ, loading of authorization
identities into service tickets and implementing authorization as a
pre-requisite to authentication were as fulfillment hooks on top of
this system.  Our experiences to date have affirmed this was the
correct decision.

In our next release we hope to have the extensions in place that allow
a Samba server to communicate with the KDC via a socket connection
implemented by our plug-in.  The goal of this work is to provide a
mechanism where Samba can send encrypted passwords to the KDC for
verification.  This made possible by an extension to kadmind which
saves a master-key encrypted version of the plaintext password on the
TLD chain of the principal.

So our efforts, albeit preliminary, seem to indicate a didactic
interaction between these three pieces of software is certainly
feasible.  What seems to be missing is an implementation or a
timeframe for a similar mechanism in the mainline KDC releases from
either Heimdal or MIT.

The first version of our attempt at a plug-in architecture was
incorporated in our 0.1.3 release.  I shipped a patch against 1.3.6 to
Sam and Ken but it ended up colliding with their work on getting 1.4
out the door.  My understanding is that some type of extension
mechanism may be in the works for 1.5.  I'm in the process of fitting
our patches into 1.4.x which is proving to be straight forward.

I don't mean to suggest that our implementation should be the basis
for a solution by MIT but I believe some plan for extensibility is
needed sooner rather than later.  A lot of big Kerberos sites already
have their 'hacks' and are probably happy with them.  We could do a
'hack' as well.  It seems life would be much easier for everyone
collectively if there were an extensibility architecture that our
'hacks' could live on top of.  Otherwise the hacks will surely
multiply.

Beside extensions to KDC/kadmind another ugly head will be reared
sooner or later.  The krb5_kuserok function is getting long in the
tooth as more sophisticated authorization technologies begin their
deployment, especially payload based schemes.  Some type of client or
application side plug-in is needed to provide a system for
implementing multiple authorization mechanisms in a portable fashion.

Until some alternate mechanism becomes available we will continue to
develop on top of what we came up with.  If anyone else can use it all
the better.  If it isn't useful I hope this note stirs interest in
helping the community conceptualize what is useful.

Wise or not the Samba team made a decision to fill a void due to lack
of available functionality.  It will be in everyone's best interests
to figure out a way to keep this problem space from becoming even more
divergent in the future.

Best wishes to everyone for a productive week

As always,
Dr. Greg 'GW' Wettstein
------------------------------------------------------------------------------
                         The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org