Win2000 PAC-Credentials Implementation

[Dr. Greg Wettstein]

On Sep 3,  7:42am, Tobias Heide wrote:
} Subject: Win2000 PAC-Credentials Implementation

> Hi there!

Good morning, hope that your day is going well.

> I wanted to have Windows 2000 Clients authenticate against a MIT Kerberos
> 1.3.1 KDC. But during implementation I came across some questions:
>
> 1. Is there an implementation for the Windows 2000 additional authorization
> information, which they keep in their tickets? There is an internet draft
> (which is expired), but is there an implementation as well?
>
> 2. Does any one know, why MS messes up DNS with certain _mscd, _tcp (etc.)
> Domains? What is the sense behind this?
>
> 3. Is there a backend for LDAP in MIT Kerberos? Could as well be beta,
> because this is only a case study until now.
>
> 4. Did anyone get it to run? (both, LDAP and/or Win2000 Clients)
>
> Overall goal would be, to have some kind of active directory, but based on
> Open Source Software.

I'm actually working on trying to hit an October 1st go live date for
a site to host a source release of systems and code which I have
called the Hurderos Project.  The focus of the project is to implement
an identity and service management system which would serve as a
work-alike for Active Directory but built on a superior identity and
service authorization model.

Some people may have run into the www.hurderos.com web-site.  That was
an ill-fated attempt to find a commercial venue for the technology
which the project is based on.  Huge amounts of experience with VC's
and large technology companies re-convinced me that the only hope for
solid infra-structural software is in an Open-Source model... :-()

The architecture looks something like this (excuse the ASCII art):

			  +-------------+
			  |     RDB    	|
 			  +-------------+
                                 |
 				 | JDBC
     GUI -----|		      	 |     		 |---->	 Service
              |   XML     +-------------+	 |
     HR/ERP --|---------> |    ISME    	| -------|---->	 Management
 	      |	     	  +-------------+	 |
     Other ---|	     	       	 | 		 |---->	 Plugins
 	      	       	 	 | XML
                                 |
 	     	       	  +-------------+
             		  |     SPL    	|
 			  +-------------+
 		       	   /   	 |    \
		     	 /	 |     	\   --------  Service
		       /	 |    	  \	      Implementation
                 +----+	      +----+    +-------+     Plugins
		 |KRB5|	      |LDAP|	|CONDUIT|
		 +----+	      +----+	+-------+


ISME standards for the Identity and Service Management Engine.  It is
currently a Java based application which oversees creation and
management of four fundamental identity types:

	1.) Users/consumers of information.
	2.) Services to be delivered to the consumers of information.
	3.) Consumer specific instances of the services.
	4.) Devices which implement the delivery of information.

There is actually a fifth fundamental object managed which I refer to
as an identity domain.  It has nothing actually to do with domains in
the sense of DNS but one runs out of unique names to call things after
awhile... :-)

Instead it is basically a container object for grouping identities in
some logical fashion within an organization.  It was expressly
designed not to have any correspondence to field implementation of the
service delivery infra-structure.  I wanted to avoid one of the perils
of Novell where you have to manage identities in a fashion somewhat
consistent with how the IT architecture is field deployed.

When developed in this manner an identity structure for an
organization begins to resemble a filesystem pretty quickly.  ISME
persists this logical structure via very, very generic SQL and JDBC
into a relational database of your choice.  I'm doing all my
development with Postgres but it has been tested with Oracle.  I never
had the cycles to test DB2 but by design the SQL is so generic I
suspect that it would just plop in.

The Service Implementation Plugins are designed to make it very easy
for an application vendor to plug into this architecture.  The whole
strategy of this system was to create a platform neutral and vendor
agnostic system for managing users and the services delivered to them.
Since the model logically encapsulates services as a unique identity
object the plugin for a service essentially implements the 'identity'
of the service including information needed to manage and deploy that
service.

	At this point the architecture is probably beginning to show
	its true colors.  I believe that for Linux to grow and thrive
	there needs to be something which makes Linux very attractive
	to software VAR's.

	Open-Source allows a lot of the problems that have plagued
	enterprise management software to go away.  Tivoli, CA and the
	like have been fighting this in the proprietary space forever
	and haven't made much headway.  Unless of course selling very
	expensive and hard to deploy management systems is
	headway... :-)

	I figured that if Linux could come walking into the enterprise
	with an open-architecture and protocol solution to these
	problems it would make porting to the platform very
	attractive.  Additionally, from the perspective of IT
	management, it would reduce barriers to selection of Linux as
	a service and application delivery platform.

	But I digress.

Moving clockwise one runs into the Service Provisioning Layer or SPL
for short.  The SPL serves as the abstraction layer for converting
information on how to instantiate a service into the physical
implementation or actions needed to do so.

This has the concept of plug-ins as well.  The actual mapping of a
service name to a provisioning plug-in is done by a configuration file
read by the SPLagent binary.  So the designation of an implementation
of a service creation request is handled at that level.

The CONDUIT plug-in currently needs a bunch of work but is designed to
use a GSSAPI authenticated connection to a targer server or device to
transmit the XML provisioning instructions to that device.  I've
currently designed the remote agent to be the SPLagent binary itself.
That makes things pretty convenient since a different configuration
file on the target simply provides instructions on which service
plug-in to be used at that 'hop'.

	I omitted details in the ASCII art but one of the plug-ins is
	actually an out-call to a binary on the target.  This supports
	proprietary application vendors who may want to keep their own
	'local' userdatabase.  The advantage is that all the
	'services' are tracked centrally.  Hurderos is thus very much
	about providing management and transport of service and
	identity information.

The one thing that is working pretty well are the MITKRB5 and LDAP
plugins.  I currently have loadable modules which handle the
management of principals in a KDC and the publication of directory
objects in OpenLDAP using GSSAPI authenticated transactions to the
target directory servers.

The goal in all this was again flexibility.  I wanted to be able to
support multiple directory servers which may not enjoy the freedom and
flexibility afforded by OpenLDAP.  Having a Novell plug-in would, I
suspect, be very attractive to a number of organizations.

One more turn clockwise takes you to how ISME gets managed.  In order
to maintain flexibility the engine gets directed to manage objects in
the 'identity filesystem' through XML-encoded instructions.  The GUI
is the most important initial target but the real power of such an
approach is potential integration with things like HR or ERP systems.
I'm leveraging the GSSAPI infra-structure in the 1.4.x libraries for
connection authentication and encryption.

So that pretty much summarizes the mechanics of the system.  The real
interesting thing, IMHO, is the identity and authorization model that
all this is constructed on.  At the peril of boring people more than I
have already I will take a little more time and discuss it in
generality.

I've been active in following a lot of the identity work being done in
the I2 Middleware groups, Liberty Alliance and such.  All of the work
and tools for federated identity systems all fail a common viability
test.  Most organizations don't have the infra-structure to define
what identities are (in a strict sense) or to manage them effectively
if they did define them.

	In my opinion the complicating issues for federated identity
	systems is the Reciprocal Identity Managment (RIM) problem.
	Participating in these things with multiple partners means
	that you get to not only manage identities in your
	organization but the identities of everyone in your partner
	organizations as well.  Not having a solution for RIM results
	in failure of the 'bullshit test" which I would be happy to
	explain over a fine snifter of single-malt scotch to anyone
	who is interested.... :-)

So we actually spent a lot of time trying to define an identity
generation model which was consistent with the needs of modern
identity management.  I always use the term SUPAC to describe this
which is an acronym for:

	Secure
	Unique
	Perpetual
	Anonymous
	Credentialled

I also tend to include Revocable in that list as well but the acronym
becomes less nice...

As I noted early on the identity generation framework focuses on the
fact that conceptually there are three important entities in the
delivery of information in an organization.  I considered these to be:

	Consumers (users)
	Services
	Devices

A federated identity structure means that organizations are going to
take responsibility for managing their own user identities.  These
three fundamental identities thus exist within the context of an
enterprise or something that I refer generically to as an 'identity
holder'.

It thus seemed logical that intrinsic identities could be formed by
the following 'fusions':

	Org. Identity + User Identity Precursor -> User identity

	Org. Identity + Service Identity Precursor -> Service identity

	Org. Identity + Device Identity Precursor -> Device Identity

The Identity Precursors that I refer to above is a token of
information generated from a piece of user credentialling information
and an identity which represents the source of credentialling
information.  All of this evolves from the need to handle multiple
credentialling sources.  This actually pays dividends when the
applicability of this model to the RIM problem is considered.

As I had noted before one of the things that I was interested in was
the problem of developing a secure and highly granular authorization
system.  When considered conceptually there are two broad classes of
authorizations to worry about.  I classify these as service and device
authorizations.

Service authorizations are useful, for example, in a clustered
environment or WEB environment where a generic service is vended to
consumers of information without regard to the device (or host)
delivering the service.  A device or host based authorization is
required when there is a need to differentially convey authorization
based on the host or device making the authorization decision.  The
best example of the latter type would be sudo or root access.

Following the above model the service and device authorizations
logically become the 'fusion' of the following identities:

	User + Service -> Service Authorization Instance ID

	User + Service + Device -> Device Authorization Instance ID

Hashing is used to generate these identities which results in
directory objects of the following form being published:

	dn: hurvice=ddbf98271dba503ad37598d4e99b4e070b840dac,RDN

The 'hurvice' attribute is the name I invented to describe a
'hurderized' service authorization instance object in the directory.
The presence of the above object in the directory conveys
authorization for the service.  The object provides a convenient
container for attributes which classify or describe the conditions
under which the service instance will be vended.

I didn't mention this before but one of my concerns about directory
based authorization is the need to infer robustness in the face of
directory compromise.  The processes to yield the final authorization
instance identity uses HMAC keyed by a symmetric key attached to a
Kerberos principal which serves to authenticate the identity of the
service.

The end result, again IMHO, is an 'inherently' secure system for
conveying authorization through a directory.  Stealing the contents of
the directory doesn't yield information which can be used to covertly
create authorization instance identity objects.  Devices/servers
delivering the service, OTOH, can reproduce the authorization instance
identity since they have access to the fundamental user and service
identity objects through the directory in addition to the
authentication key from the local keytable.

The model is also consistent with the notion of 'packing' the
authorization identity token into a Kerberos ticket itself.  The
advantage is that since the authorization is very granular the ticket
size only gets expanded by 20 bytes.  The end result is a system where
Kerberos does what it does best and an LDAP directory does what it
does best.

There is a bunch more to all this including a process of creating
'transient' versions of the identity for publication in the directory
(revocability guarantee).  All of the above has probably been enough
to understand why ISME is needed to make the process transparent to
the user/administrator... :-)

I'm sure thats way more than what Tobi was expecting and I apologize
for using his message as a forum to dump this stuff.  I've mentioned
the Hurderos Project on the list a couple of times and I couldn't in
good conscience do so again for fear of having it labelled as a come
on only.

I probably want to state for the record that the code is far from
ready for prime time.  It basically represents a project to
demonstrate to VC's (and other industry types) that all this had
substance and actually would work.  Unfortunately it never got the
chance to even do that.  I was left though with an indelible
impression about how little most people in the technology industry
know and understand about issues surrounding identity management and
issues surrounding authorization.

Getting all this right ultimately requires a really big picture view
about the development and deployment of information delivery
architectures.  The need for this viewpoint makes conveying the
importance and meaning of all these issues more complicated.

I think what I do have is sort of the perfect candidate for an
Open-Source project.  The general architecture and a platform to build
on are all present.  There are also lots and lots of bits and pieces
of well isolated stuff that need building and refinement to support a
complete solution.  Hopefully an environment where people can bite off
bits and pieces that they are interested in.

In addition, all this is standing on very, very big shoulders.  The
fact that Kerberos and OpenLDAP are available and well supported
provide an tremendous vantage point to work from.

I'm probably not stating the obvious and that is my politics with
respect to Active Directory.  I consider the beast really dangerous to
efforts to maintain an open information delivery architecture.  That
supposition is based on what I refer to as the 'transcendency of
of identity management':

When the water gets boiled down at the end of the day the only
important thing in information delivery is:

	Who are the consumers of information and what can they
	consume?

The above statement translates functionally to user identities and how
they get authorized for access to information. Controlling that makes
alternate operating system platforms irrelevant and provides ultimate
lock-in for the application.

>From an enterprise perspective getting identity generation and
management infra-structure deployed is a huge undertaking.  Been
there, done that.  Up-rooting something that is deployed and
functional just doesn't happen very easily, if at all.  Once an
organization steps over the edge and implements an architecture things
don't go backwards very easily.

So the answer to Tobi's question is that, yes, there is at least one
project that hopes to address the problem of an Active Directory
work-alike with an open-architecture design and Open-Source
components.  We will hopefully see if there is sufficient interest in
the community and industry for a project like this to succeed.

One last piece of humor to end on.

I had the opportunity to participate in a pitch of all the above to a
high-profile VC outfit.  A four hour session with their 'enterprise
software specialist'.  After going through all the above plus tons of
other stuff this person looked at me and said:

	What is this Kerberos stuff and why is it so important?

I figured it was best to pretty much let him go and tend to their
investments in the security space... :-)

> Thanks in advance,
> tobi
> --
> System Administrator DAASI International GmbH

If there is interest in any of the above I will let the list know when
I get a web site up and running with more details and information on
the project.

Again my apologies for the length of the note.  Hopefully it was worth
the read to someone.

Best wishes to everyone for a pleasant weekend.

Greg

---------------------------------------------------------------------------
As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at enjellic.com
------------------------------------------------------------------------------
"Don't worry about people stealing your ideas.  If your ideas are any
good, you'll have to ram them down people's throats."
                                -- Howard Aiken