Kerberized authorization service

[g.w@hurderos.org]

On Feb 12,  2:02pm, Ken Hornstein wrote:
} Subject: Re: Kerberized authorization service

Good morning to everyone.  Back from the mountains to the northern
plains so a bit more time for e-mail.

> First off, let me explain my perspective.
>
> My background has always been from a engineering perspective.  I
> look at a concept and I immediately think, "How would I implement
> that?"  "How would I use that?"  If I can't answer those questions,
> then I have a problem with the concept, because I've seen plenty of
> things that seem great on paper but fail to gain traction when the
> rubber meets the road.

That is certainly understandable and the mark of any good engineer.  I
respect your opinions and concerns on all these issues.

I also believe though a certain sense of introspection is required.
There is always a danger of looking at new ideas from only the context
of ones own experiences.  Some ideas may seem 'off-beat' until they
are considered in the full light of all the issues which went into the
engineering decisions.

As I indicated earlier, IDfusion actually comes out of a larger body
of work which was undertaken in response to issues surrounding secured
identity management.  I hate to use the term 'identity management'
since it carries a lot of political baggage, but thats what the
problem is all about.  It is a deeply complex issue since it involves
the intersection of technology, legal issues and organizational
business processes.

> >> - "Simple?"  Uh, you ARE kidding, right?  Right off the bat you
> >>    start talking about n-bit vectors and cryptographic hashes.  And the
> >>    diagram on slide 18 ... ouch.  And you use XML?  What exactly is
> >>    SIMPLE about this idea?
> >
> >The authorization model.  Something which no one in the thread has
> >addressed.
> 
> Well, hm.  Maybe this is a termology problem.  (Just to be fair, I went
> back and read the original paper that is also linked to the web site).

Good, then we have a starting point for a conversation.

With respect to my comments above there is an additional paper which
discusses the entire hierarchical identity generation model.  That
paper provides context on some of the larger issues which IDfusion
tries to address.

> >Since we are referring to page numbers; the authorization model was
> >conceptually presented via an animated graphic on slide 8.

> So, I looked at that slide (which wasn't animated on the PDF, but I
> think I got the gist).
>
> From what I have seen, this is basically similar to all other
> "models" for other authorization servers, with the exception that
> SIii is a concept unique to your scheme.  But from what I can tell,
> the whole reason the SIii exists is due to your desire to place that
> in a public directory.
>
> Other authorization systems do not choose to do this, so they don't
> need an SIii-equivalent concept.  So I'm not sure I would consider
> this part of the "model", as I would use the word.  I'd almost call
> it an artifact of the implementation (well, I don't know exactly
> what came first, the SIii or the desire to use LDAP).  Maybe other
> authorization servers we've talked about don't mention a "model"
> because they're self-evident.

SIii's are not an artifact but a principal outcome of the model.  The
general power of IDfusion is that it represents an inheritance scheme
for modeling identity.  This results in at least two important
advantages.

The first is the notion of cryptographic authentication of the
authorization decision.  Only the KDC and the management engine know
how to generate an SIii from a user and service object.

I think we all agree the authorization server and its database
immediately become components of the TCB.  A complete security
implementation for an authorization server would require encryption of
the database which entails another server or servers requiring an
encryption key typed into them at startup.

The inheritance model is also important from a management perspective.
The IDfusion API by default merges the attributes associated with the
Sii and Uii objects and overrides these default attributes with any
attributes specific to the SIii identity.

This allows a global change in how a service is authorized or
delivered by simply changing attributes on one directory object.
Conversely it provides the ability to customize the service
authorization at the user level without disturbing the global
configuration of the service.

> >I've generally found non-technical types understand the model/concept
> >far more quickly than most technical people.  I believe that tends to
> >be a hallmark of disruptive technology.

> Well, here's the problem with that: I would be one of the people you
> would have to convince of your project's value before it would be
> deployed here.  So convincing people who think like me is likely
> important if you want it to be used out in the wild (if you care
> about that).

I certainly respect that issue.

Unfortunately as IT becomes more critical to core business processes
there are political and legal issues which complicate technology
decisions.  Right or wrong, technology deployments have to sometimes
satisfy requirements which do not necessarily make sense from a
technical perspective.

As I noted earlier IDfusion was designed to address issues secondary
to the protection of identity and privacy concerns.  Whether we agree
with it or not these are important issues which drive technology
decisions and deployments.

> >Since we are talking pragmatic experiences; a gedanken challenge for
> >everyone with real world authorization experience:
> >
> >	An organization conveys two roles over a base of 50,000
> >	users.  Implement an architecture which allows the two generic
> >	roles to be custom managed at the individual user
> >	level.  Overall model complexity cannot exceed the expression
> >	on page 8.

> You know, I never liked the term "roles".  It's a "hot" term in the
> theoretical world, but I guess I never see a practical use of it
> when we get down to actually assigning rights to people.  To me the
> easier concept is ACL - that's something that just naturally fits
> into the sort of access control decisions we want to make.  The
> examples I've seen where they show "role" assignment always seem
> contrived, and somehow we never end up doing things like that.

I'm not a fan of roles either.  In fact the IDfusion inheritance and
object model was designed to overcome what I consider basic and
fundamental problems with roles.

The notion of 'roles' however have traction in IT management circles
since they are sold as a solution which simplifies system management
and administration.

Regardless of whether they are called roles, ACL's or permissions I
believe the open-source community needs a story in this venue.  We are
offering a set of strong individual tools and components, while the
industry is looking for an integrated solution.

> But, to answer your challenge - I think the Hascall double-secret
> authz server would work just fine for this task.  How we organize
> the data on the backend might need to be shuffled around a bit, but
> I don't see any reason why it couldn't work.

I will go back to the notion of inheritance.  The issue is whether or
not there is the ability to quickly change overall characteristics of
how a service is authorized and delivered while maintaining the option
of per user customizations.

Organizations want to do this by clicking on an icon, entering some
information and immediately having it propagate to all service
delivery components.  It is this usage scenario which IDfusion was
designed to provide a generic solution for.

> >I will certainly grant the need to have a KDC which understands
> >payload injection.  An authorization server model requires another
> >platform to be deployed which by definition enters into the TCB of the
> >organization with all consequent security constraints and issues.

> One thing I've learned is that having a custom KDC makes your life
> hard.  I am personally loath to do it (we do it, but really, I hate
> it).  I'd much rather add a new service to the TCB than have a KDC
> with Yet Another Custom extension.

That is certainly an understandable reaction.  My own experience has
taught me most organizations are loath to deploy additional servers or
services if they can avoid it.  Particularly when they are components
which have security implications.

Organizations tend to be big on integrated services.   That's one of
the main selling points of Active Directory.  This issue was once
again integral to the design decisions which were made.

> >If there is a belief IDfusion is not extensible enough its not being
> >understood.  The authorization decision context and flexibility model
> >is identical if not a super-set to that of an authorization server
> >model.

> "Meh".  You have not yet convinced me of that.  I might grant you
> identical (although I cannot see how you can do what I want) but a
> superset?  I don't see it.

I'm confident the model and architecture can replace an authorization
server.  The overall architecture was designed to be able to support
an authorization server if there was a need to deploy one.  The best
example of such a need would be a situation where communications with
a secondary device is needed to fully implement the authorization.

One example of this would be the centralization of things such as
802.1x based port activations.

> >>  Also, I cannot see how to make use of your scheme with cross-realm
> >>  authentication ... and we use that a lot.
> >
> >Ah yes, the Reciprocal Identity Management (RIM) problem.  I can point
> >people at a paper that discusses this issue in some depth.  I would
> >hazard a guess we understand the issue pretty completely.

> Maybe this is part of the problem we're having ... you're coming up
> with these new strange terms.  "Reciprocal" Identity Management?
> I've never heard of that before, and that term doesn't even make any
> sense to me!

Not having heard of something certainly doesn't preclude its
existence, see my comments at the outset of this note. The Austrian
emperor thought there were too many notes in one of Mozart's most
important works, history has spoken on that one... :-)

RIM is the problem area describing the collision of federated identity
models with practical IT deployment issues.  It focuses on the issue
that in a federated identity environment (cross-realm is an example of
federation) both organizations need to manage the identity of a user.

An example.  Organization A is responsible for validating and
authenticating the identity of User U.  Organization B offers a
service to User U based on Organization A's authentication.  For a
variety of practical and legal reasons both organizations need to
unilaterally control authorization of User U to Organization B's
services.

Its not an easy problem.  Particularly when privacy and auditability
are factored into the equation.

I can put a paper up on the web-site which discusses all this in more
detail.  Reading that will require an understanding of the
hierarchical identity model which IDfusion is based on though.

> But, you haven't really explained how this could work.  _Can_ it
> work?  You're using the authz field placed in the ticket during a
> AS_REQ, which the "local" KDC doesn't participate in.  Does this
> mean the foreign realm would have to have a KDC which placed authz
> data into the ticket?

No, that was one of the issues we were concerned about.

> This is where the "traditional" authz server works just fine.  All
> that gets communicated to the authz server is the principal
> identity.

A Uii doesn't need to be injected into a TGT in order for the system
to work.  The KDC can compute the SIii based on the foreign principal
name and the local Sii and inject it into the service ticket.  From
that point forward the service authorization process is identical to
what happens with 'local' principals.

All this is an example of the 'RIM' problem.  Both realms need to
coordinate management of the identity.  This is an issue regardless of
whether the authorization server or IDfusion model is used.

The goal of the overall hierarchical identity model implemented by
ISME (Identity and Service Management Engine) is to increase the
manageability of these foreign authorizations.

> >The only role LDAP has in IDfusion is to manage authorization data.

> But hold on a sec ... I mean, that's really just shifting things around
> slightly.  I mean, you have a choice between two alternatives:
> 
> - Present the identity information to an authz server, the authz server
>   says "yes/no".
> - Ask the LDAP server for some authz data that the app uses to decide "yes/no".
>
> (I'm ignoring ancillary attributes right now).
> 
> Those look pretty close to me.  Why is one better than the other?

The first issue is the number of moving parts.  As I've previously
noted IDfusion leverages existing KDC and LDAP servers to implement
authorization services.  That may not be a big issue for you but is a
significant concern to many organizations.

IDfusion supports the implementation of any number of services to be
authorized.  In an authorization server model you need to either
implement separate servers for each service type or codify which
authorization is being requested in the request protocol.

Most fundamentally IDfusion is predicated on the notion that
authorization should stay with the application.  Its designed to be a
model or architecture which supports answering the basic authorization
question along with providing qualifying information in case an
extended decision is needed.

> >IDfusion reduces the TCB of the IAA infra-structure of an organization
> >to two components; LDAP and Kerberos, two well understood and widely
> >implemented services.  An authorization server adds an additional
> >security sensitive component.
> 
> This is a bit of a red herring, and I think you know it.
> 
> - IDfusion TCB - Kerberos and LDAP
> - Traditional authz TCB - Kerberos and <insert your authz server here>
> 
> Again ... the difference is ...?

See above.

Odds are very, very long that organizations where all this matters are
going to have both a KDC and LDAP already running.

> >In its most simple implementation IDfusion has the authorization
> >question asked and answered by a single query using an IETF ratified
> >protocol with multiple heterogenous implementations.  An authorization
> >server uses a custom developed protocol which has no guarantee of
> >inter-operability beyond its implementation site and platform.

> "Meh".  I do not consider the blessing of the IETF of any particular
> worth when I decide to use a protocol (or write my own).  I pick the
> best tool for the job.  The number of implementations also is of
> little consequence ... competition is nice, but I only need one.
> And in this particular case, I have realized that I don't really
> _care_ about interoperability beyond my site.  Let me put it another
> way: if I had an account at Iowa State and I connected to it from
> NRL, would I care that they use the Hascall double-secret authz
> server?  No, because it would be the Iowa State servers who would be
> talking to that authz server.  Perhaps other sites feel differently,
> but I want to be in complete control of all aspects of authorization
> decisions at my site.  I don't expect anyone outside of my
> administrative boundary to be querying my authz server.

Your site may be different but in general organizations tend to want
to solve problems using generic solutions and standards where
possible.  Our goal in all this work was to propose a generic solution
architecture.

I believe the generic standards which organization will use to
implement integrated IAA solutions are LDAP and Kerberos.  Hence the
architectural choices in IDfusion.

In a larger context what is really needed is for everyone to agree on
how to ask and answer an authorization question.  If the open-source
community could promulgate and push that type of API everyone would
benefit.

And for the record I don't believe SAML is the solution for codifying
the question and answer process.

> >There are no extensions to the Kerberos protocol required.  In its
> >current implementation 20 bytes are added into a field which is
> >required to exist in an IETF ratified standard.

> Well ... that is true _in theory_, I can tell you from hard-learned
> experience that when you start using fields that have not
> traditionally been used in the Kerberos protocol, you may run into
> "exciting" new bugs.  But I think I used the wrong term ... perhaps
> I should have said "nontraditional" instead of "extension".

If applications can't cope with a properly formatted authorization
payload field it will be game over for them.  The impending dominance
of Active Directory is going to assure that.

> >> BTW, there is a "simple" way to prove that I am full of crap.  All
> >> you have to do is implement your design and get people to use it.
> >> Clearly there is a desire for a reasonable authorization service
> >> that ties into Kerberos, so if what you come up with is workable you
> >> should have plenty of users.

> >Unfortunately this simplistic assessment neglects the network
> >effect which may be at its strongest in the field of enterprise IAA
> >architectures.  As I stated before and will re-state somewhat
> >colloquially, it may be all over with except for the shouting.

> Well, hm .... okay, I don't follow you, at all.  "network effect"?

Its an architectural term used to describe situations where the cost
and complexity of replacing a solution is so significant that the
first implementation which gains dominance in the market controls the
market.

It was my way of saying all these argument's may be moot because for
all practical purposes Active Directory has won.

> Here's my bottom line, for what it's worth.  I have listened to the
> presentation, I've read the white paper and the slides, and I've
> tried to understand what you're doing.  So far as I can tell, it is
> roughly the same in function as a "traditional" authz server.  I
> can't see an advange to your scheme over the traditional authz
> server.  You might say that it's use of LDAP is an advantage - I
> would say that is just an implementation detail.  You have some
> hand-waving about controlling fine-grained user access with 50,000
> users, but again ... I don't see anything inherent in that scenario
> that makes a traditional authz server not be able to perform that
> job.

I believe the inheritance model with the management flexibility it
offers is more than hand waving, but thats certainly a biased opinion.

I believe the intrinsic security guarantee created by the
cryptographic model for identity generation is important with respect
to preventing overt or covert manipulation of authorization
entitlements.

We could argue the merits of LDAP all day along.  It has its warts but
its a standard which is widely understood and deployed

As evidence I offer as simple proof the support which was added in 1.6
for an LDAP backend to the KDC.  Standard security dictum has always
been to provide foolproof security for the KDC; no network access
except for port 88, single function server, dual-person security etc.

Now we are virtually condoning dumping all the authentication secrets
into a common data repository.  When I've raised this issue on the
list the reply was, 'thats what organizations want to use since they
know how to deploy and manage it'.

In fact I will wager a sizable sum on the following scenario:

Lets consider for a moment the community decides using an
authorization server is the solution in this problem space.  A
standardized access API gets established for applications to use and a
generic server implementation is written.

I can just about guarantee you the first request will be to add
support for LDAP as the backend database for the authz server.

> If IDfusion and a traditional authz server were the same, then the
> choice would probably go to the more mature codebase.  But from my
> perspective IDfusion has some significant practical disadvantages.
> It requires a custom KDC, and how you would deal with cross-realm
> users is simply not discussed (you say "we understand the issue
> completely".  I will notice you didn't say, "IDfusion can deal with
> it", or even, "We know how to solve this problem with IDfusion").

The plug-in architecture which MIT has implemented is a nod to the need
to customize KDC's in a manner which is supportable and extensible.
Either open-source solutions will use this to innovate or they will
become irrelevant.

With respect to the RIM issue (cross-realm support) I will officially
state we both understand it and can deal with it.  The trick is
managing it effectively which is the subject for another conversation.

> You have said that IDfusion is not being understood.  Well, I've
> done what I think is a fair job of trying to understand it.  I don't
> know what more I can do to understand it, so I have a hard time
> believing the problem is all on my end.

I certainly appreciate the time you took to go through the slides and
read the paper.  I believe the problem in understanding IDfusion is
secondary to the fact it approaches the authorization problem from a
different perspective than what most people are familiar with.  The
entire concept is more about identity than it is about authorization,
support for the latter basically falls out of the model.

The technology is arguably easier to understand when you see it in
action than when it is described.  So I will probably take you up on
your challenge.

Historically the problem with efforts in this space is the number of
technologies which need to be configured, deployed and interlocked.
I've spent a lot of time in the last year or so with User Mode Linux
(UML) and it brings a number of interesting possibilities to the
table.

Its now reasonably straight forward to package a completely configured
IAA solution in the form of a UML file-system image.  I'm going to
spend some time putting together an 'appliance' which people can
download and try the technology with.

Perhaps if experimentation with open-source IAA technology is made a
bit more tractable more people who are interested in the issue can
begin working with it a bit.

> --Ken

Thanks for the opportunity to discuss these issues.

Best wishes for a pleasant weekend.

}-- End of excerpt from Ken Hornstein

As always,
Greg Wettstein

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org

"If you don't like change, you're going to like irrelevance even
 less."
                                -- General Eric Shinseki