The challenge of trundling forward with Kerberos integration.

classic Classic list List threaded Threaded
4 messages Options
g.w
Reply | Threaded
Open this post in threaded view
|

The challenge of trundling forward with Kerberos integration.

g.w
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
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The challenge of trundling forward with Kerberos integration.

Andrew Bartlett
On Sat, 2005-06-11 at 16:45 -0500, [hidden email] wrote:
> Good day to everyone, I hope the weekend is going well or the week is
> starting well depending on when you read your mail.

> 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.

Just responding to this point first, because we need to be rather clear
on the point.  We are not trying to 'clone' AD (in particular, there is
no aim at duplicating the internal structure), and while a goal of
Samba4 is to implement management and logon protocols used in AD, the
server-side design is quite different.

The closely integrated KDC is not that way 'because Microsoft did it
that way' (their KDC is different again), but for other reasons:

 - A more global design decision was taken describing how Samba4 would
operate as a unix service (as a single binary, providing all integrated
services)
 - Because of the pain in doing portable dlopen() based plugins
 - Because of the close integration between the protocols we support
forced a common backend, and above two points clearly suggested a direct
linking.
 - Because it must 'just work', without the admin every knowing what
kerberos is.  

In the long term, I see optional integration with other kerberos
projects as a viable and valuable option, but I'm keen to finish the
current KDC, and gain some real world experiences before I send
developers on wild goose chases for features we may find we actually
can't use.  

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment
g.w
Reply | Threaded
Open this post in threaded view
|

Re: The challenge of trundling forward with Kerberos integration.

g.w
In reply to this post by g.w
On Jun 12,  5:23pm, Andrew Bartlett wrote:
} Subject: Re: The challenge of trundling forward with Kerberos integration.

Good morning to everyone, I hope the day is starting out well.

> On Sat, 2005-06-11 at 16:45 -0500, [hidden email] wrote:
> > Good day to everyone, I hope the weekend is going well or the week is
> > starting well depending on when you read your mail.
>
> > 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.

> Just responding to this point first, because we need to be rather
> clear on the point.  We are not trying to 'clone' AD (in particular,
> there is no aim at duplicating the internal structure), and while a
> goal of Samba4 is to implement management and logon protocols used
> in AD, the server-side design is quite different.=20

Stated another way the desired goal is to produce an application which
implements the complete functionality of another application in a
manner which is transparent to any client wishing to interact with it.
Including the faithful reproduction of all security authorization
tokens (potentially proprietary) needed for the client to participate
in controlled service delivery.

Sounds a bit like a clone to me.... :-)

But there be the dungeons and dragons of semantic interpretation which
all good intellectual property issues are borne of.

Our intent, however, isn't to argue with the goals of Samba4.  We
actually support the work and believe rather fundamentally that our
identity models could play favorably with Samba.

But I think we can be realistic as a community and concede that Samba4
needs to be a complete functional clone of AD.  If not it will be
trivial for applications to be coded to differentiate between Samba4
and an AD implementation.

Tridge commented earlier in the Samba4 thread that one of the reasons
everything needed to be tightly integrated was to allow simple SOHO
type deployments of Samba4 in order to support applications which
require AD services.  The utility of Samba4 could be rather simply
defeated if the applications could be taught to differentiate what was
delivering the login and management services.

> The closely integrated KDC is not that way 'because Microsoft did it
> that way' (their KDC is different again), but for other reasons:
>
>  - A more global design decision was taken describing how Samba4 would
> operate as a unix service (as a single binary, providing all integrated
> services)
>  - Because of the pain in doing portable dlopen() based plugins
>  - Because of the close integration between the protocols we support
> forced a common backend, and above two points clearly suggested a direct
> linking.
>  - Because it must 'just work', without the admin every knowing what
> kerberos is. =20

All valid and understandable reasons for your group choosing the
architeture that it did.  Once again to be realistic one needs to
assess globally why all this is happening.

Microsoft chooses to amalgamate functionality into an amomrphous
implementations for a variety of reasons.  In this case it may well be
due to the fact that the 'easiest' architectural approach, considering
the level of desired protocol integration, was to tightly integrate
all functionality into one glop.

An additional philosophy of Microsoft is to make all their technology
as easily deployable as possible.  Regardless of the technical merits
of doing so one of their strategic goals is to minimize the amount of
competency needed to deploy their architectures.

So from a realistic perspective Samba4's technical architecture is
being driven by AD's architectural and role choices.

> In the long term, I see optional integration with other kerberos
> projects as a viable and valuable option, but I'm keen to finish the
> current KDC, and gain some real world experiences before I send
> developers on wild goose chases for features we may find we actually
> can't use.

Unfortunately there doesn't seem to be any type of ongoing discussion
about how to properly implement extensibility architectures, at least
for MIT Kerberos.  The primary purpose of my note was to try and
stimulate some discussion on how that should be done.  I don't see
such a discussion as a wild goose chase.

Hopefully such conversations will be forthcoming.  If not the Samba
group would seem to be justified in their architectural decisions
since there was little in the way of alternative choices available.

> Andrew Bartlett

Best wishes for a productive week for your project.

}-- End of excerpt from Andrew Bartlett

As always,
Dr. Greg 'GW' Wettstein
------------------------------------------------------------------------------
                         The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: The challenge of trundling forward with Kerberos integration.

Andrew Bartlett
On Tue, 2005-06-14 at 10:10 -0500, [hidden email] wrote:

> On Jun 12,  5:23pm, Andrew Bartlett wrote:
> } Subject: Re: The challenge of trundling forward with Kerberos integration.
>
> Good morning to everyone, I hope the day is starting out well.
>
> > On Sat, 2005-06-11 at 16:45 -0500, [hidden email] wrote:
> > > Good day to everyone, I hope the weekend is going well or the week is
> > > starting well depending on when you read your mail.
> >
> > > 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.
>
> > Just responding to this point first, because we need to be rather
> > clear on the point.  We are not trying to 'clone' AD (in particular,
> > there is no aim at duplicating the internal structure), and while a
> > goal of Samba4 is to implement management and logon protocols used
> > in AD, the server-side design is quite different.=20
>
> Stated another way the desired goal is to produce an application which
> implements the complete functionality of another application in a
> manner which is transparent to any client wishing to interact with it.
> Including the faithful reproduction of all security authorization
> tokens (potentially proprietary) needed for the client to participate
> in controlled service delivery.
>
> Sounds a bit like a clone to me.... :-)
Sorry to have to keep taking you to task on this, but this is *not* an
accurate description of what we do.  Our goal is to provide a network
implementation that is transparent to the client, however the means and
ways we provide that implementation are clearly different.  We do not in
any way wish to clone the MS internal design, nor their implementation.
A clone, which is originally a medial term with specific meaning implies
an identical DNA, but different external features.  We do not aim for
this at all.

If we are going to make a useful forward progress on this discussion,
then we will need to agree on this, as a clone of AD would indeed have
no useful role for your work (you would not be able to extend it).

> > In the long term, I see optional integration with other kerberos
> > projects as a viable and valuable option, but I'm keen to finish the
> > current KDC, and gain some real world experiences before I send
> > developers on wild goose chases for features we may find we actually
> > can't use.
>
> Unfortunately there doesn't seem to be any type of ongoing discussion
> about how to properly implement extensibility architectures, at least
> for MIT Kerberos.  The primary purpose of my note was to try and
> stimulate some discussion on how that should be done.  I don't see
> such a discussion as a wild goose chase.
>
> Hopefully such conversations will be forthcoming.  If not the Samba
> group would seem to be justified in their architectural decisions
> since there was little in the way of alternative choices available.
From Samba4's perspective, I am interested in seeing a pluggable
architecture as an optional way for specialist administrators to modify
the behaviour of their KDCs.  Be aware that we can't (due to portability
and manageability constraints) use a such plugin system by default, but
I see great value in allowing the option.

Samba has to be all over the KDC side of any such implementation, so the
plugins will indeed be large, but I hope it will allow interesting
experiments (such as alternate PKinit schemes) to be plugged into the
same KDC.  I don't know the exact interfaces we will need until I've
built the trial in Heimdal, but I'm happy to look at proposed designs
(and associated patches).

Thanks,

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment