rights management

[Dr. Greg Wettstein]

On Mar 3,  3:04pm, "Michael Fair" wrote:
} Subject: Re: rights management

I'm usually pretty much just a lurker but I thought that I would drop
in and offer a few comments since my applied research group and I have
been working on this problem for the last 4-5 years.  I've had a
series of conversations in the last few days with a company that I am
a component of about the possibility of open-sourcing a hunk of what
has been developed.  Those conversations have been fairly positive so
I thought some of my refletions may be relevant at this time.

Starting in 1997 I did the system design and build out for a state
network which serves K-12, Higher Education and interacts with State
Government.  A central design tenant of this work was to develop a
single-signon system for INTERNET style services which heavily
leveraged Linux and the open-source service delivery applications that
we have all come to love.  Those people who have been around the Linux
movement since the early days probably remember my name.  Most of my
Linux contributions ended up getting subordinated to this project.

It was pretty clear to me from early on that most people don't (and
still don't for matter) really understand authorization and the
implications of it.  Based on some of the conversations that I have
been seeing go by on this list I think that is beginning to change.
By and large the issue of differentiating authorization from
authentication has been overlooked and underserved by the
open-source/INTERNET application community.

I tend to be in violent agreement with the original author that what
is needed is a single and comprehensive solution to the problem.  I
also am in agreement with Mark that the answer is not to stick all
this in Kerberos itself.  The vision that drove my development efforts
was to leverage Kerberos for what it was good at while using the right
tool for the job, ie. LDAP, for what it was good at - authorization.

The important component in all this that cannot be overlooked is that
the process of authorization requires as much attention to security as
is required of authentication.  A great deal of respect tends to get
paid to deploying secured KDC's but in my view I see a lot less
attention being paid to the directory servers.  I believe that this
needs to be addressed if the directory servers are to become central
players in the authorization process.

The next major tidal wave of security concerns are going to revolve
around attacks on directory services, especially if the trend toward
'directory enabled' applications continue.  As an architect I tend to
cringe at the PAM stacks that do provisioning as a component of the
pam_sm_acct_mgmt module.  This strategy certainly has advantages with
respect to ease of administration at the expense of producing the
potential for widespread security penetration with the compromise of
the directory server.

The approach that we took to solving this problem was to base the
generation of directory based authorization tokens on a heirarchical
concantentation of the identities involved in the service delivery
chain.  In the case of a service based authorization the final token
was based on the identities of the organization, the service and the
user.  This final token was sealed by the symmetric key associated
with a service specific principal created in the KDC.  Presence of
this token in the directory heirarchy conveys authorization for a
specific instance of a service and provides a handy container for
encapsulating quality of delivery parameters for the service.

We have been pleasantly surprised by the overall utility of this
scheme as we have brought it into early production.  It seems to
provide a straight forward approach to the authorization problem which
leverages the advantages of LDAP and Kerberos without excessively
polluting the functionality of either system.

I've actually got a paper submitted to one of the upcoming conferences
which lays out the design of the system but don't know if it will be
excepted.  I had submitted it to the USENIX Systems Administration
conference but unfortunately the paper seemed to have gotten reviewed
by a cryptographer rather than a systems architect or design person.
Based on the review comments it would seem that the major focus and
intent of the paper got lost.  This whole area of applied research
tends to be at the intersection of pragmatism and theory which makes
it difficult to find people who have the scope of vision to appreciate
all the issues involved.

The whole IAA area is one that is going to be critically important to
the ability of OSS to penetrate the enterprise.  Anyone who has done
enterprise level work understands what it takes to get unified
directory and authentication services working.  If proprietary
interests end up controlling this space it won't be very long before
we find applications getting intimately tied to the middleware
infrastructure.  When that happens it will be much more problematic
for OSS work-alike solutions to compete.

Lots of work and attention needs to get paid to this by the OSS
community.  As I mentioned before my work focused on SSO for INTERNET
style applications, FTP, IMAP, SSH, SMB etc, etc.  While PAM supports
the notion of separating a 'remote' identity from an internal working
identity it is rare to find applications that understand this concept
and properly use the support that PAM provides for this
differentiation.  Beyond that there is little if any notion of
fine-grained or selective authorization for open-protocol style
services let alone the connection of this to individualized quality of
delivery parameters, ie. what IP addresses can I access this service
from.

> -- Michael --

It will be interesting to see how all this plays out.  It will
ultimately be the place where the battle of proprietary vs open
solutions in the enterprise gets fought.

>From someone who has been there.... :-)

}-- End of excerpt from "Michael Fair"

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
------------------------------------------------------------------------------
"Fools ignore complexity.  Pragmatists suffer it.  Some can avoid it.
Geniuses remove it.
                                -- Perliss' Programming Proverb #58
                                   SIGPLAN National, Sept. 1982