Kerberized authorization service

[g.w@hurderos.org]

On Feb 11,  9:48am, Ken Hornstein wrote:
} Subject: Re: Kerberized authorization service

Good evening, I hope the week has started well for everyone.

My apologies for the somewhat high latency on responses.  I'm
answering e-mails at night since I'm spending the days skiing the back
bowls at Vail.

> >I presented a paper at the Kerberos/AFS workshop a couple of years ago
> >on an open-architecture authorization model and API.  The conceptual
> >approach is extremely simple, very powerful and architecturally similar
> >to what you propose.

> Well, I'm sorry ... I remember that paper, and ... well, I cannot
> agree with your statements (and to be fair, I just went and re-read
> that presentation again; it's available from the 2006 AFS Workshop
> archives).

I'm pleased you took time to look at the slides.  The paper which
accompanied those slides goes into some detail on these issues as
well.  In this spirit of fairness lets examine a few of your issues
within the context of that paper.

> Here are my beefs with your proposal:
>
> - "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.

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

On slide 9 the generic model (as recommended by cryptographic review)
was presented as:

	SIii = Hm(Uii, Sii)

On slide 10 the Kerberos specific implementation is presented in
equation form as follows:

	SIii = HmKn(Uii, Sii)

I would certainly be interested in a discussion on a more simplistic
model which covers the spectrum from generic yes/no to user
individualized roles or service authorization assignments.

All of this reminds me a bit of the movie Amadeus where the Austrian
Emperor asks Mozart, "Do you not think there are too many notes in
this piece?"  To which Mozart replies, "There are precisely enough
notes to accomplish the purpose, not too few nor too many."

The complete scope of our work revolves around the notion of how to
securely create and manage user identities and the services they have
assigned to them.  Doing this correctly starts at the organizational
ERP level and descends all the way to the application layer.

The diagram on slide 18 simply summarizes all the pieces which need to
be integrated to accomplish this.  Authorization is the box in the
lower left hand corner, which is represented by the third equation
above.  No XML, just a single function call.

>   I consider myself reasonably intelligent and I've spent a fair
>   amount of time thinking about authorization, and I can barely
>   follow your proposal.  Off-line discussions I have had with others
>   in the Kerberos community have seen similar reactions to mine.
>   So, in short: your proposal is really complicated.  If this
>   complexity was necessary, I could forgive that ...  but we have
>   real-world experience that shows that it is not.

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.

This stuff isn't theoretical. Its concepts are borne out of analysis
of practical deployment problems involving service delivery to 60,000+
users at highly granular modulation levels.

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.

> - Your proposal did not include an API (there was not one shown in
>   your slides).  Well, you included KDC and library plug-ins, but not
>   how this API would look on an application server.  I am gathering
>   that it would involve LDAP queries (although perhaps you hid that
>   inside of a wrapper library).
>
>   During our authz server prototype work, we developed an API.  It was
>   one function - it returned a "yes/no" answer, and a text string which
>   included a string you could display/log for the "no" reason.  Would have
>   been a few lines of code to add to all of the application servers that
>   we use.

char ** is_authorized(char *Uii_filter, char *Sii_filter, char *SIii);

Null return means the service has not been extended to the user.

Non-null implies the service has been extended to the user.  Return
value points to a null-terminated list of key-value pairs defining
current service status plus optional refinement parameters.

Or if an applications is content with yes/no and understands PAM, add
the following to the PAM stack for the service:

	account	requisite pam_idfusion service=SVCNAME

Where SVCNAME is the name assigned to the service/role.

> - History has shown us that adding authorization data to the
>   Kerberos protocol isn't the best idea.  DCE did it, Microsoft does
>   it, and there are a host of problems with this approach; from an
>   architectural perspective (operational experience has shown us
>   repeatedly that having the ability to change authorization
>   information more quickly than Kerberos ticket lifetimes is very
>   important) to the practical (authz data in Kerberos tickets brings
>   larger tickets which present problems for some applications, it
>   locks you to a particular KDC, and those are only a few).

Once again I believe its a problem with not being done right.

In IDfusion with Hm=SHA1 total authorization payload size is 20
bytes.

As noted previously our design has come from practical experience as
well.  In IDfusion the LDAP directory is the canonical source for the
current status of the service authorization.  The application is free
to verify authorization status at whatever timing granularity is
appropriate or feasible.

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.

Pick your poison.

> - Your model is simply not extensible enough.  For example, it is not
>   possible to easily extend it to make the authorization decisions that
>   our site needs to make.  Why?  Well, we make authorization decisions
>   on the application server based on information that is not available
>   at service ticket creation time.  Maybe I am mis-understanding your
>   model and perhaps it is possible ... but that just gets back to the
>   whole "complexity" issue. 

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 superset to that of an authorization server
model.

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

I'd love to dive into all that but will refrain due to the obvious
length of this note unless people are interested.  Its a fascinating
problem.

> Let's take two real world counter-examples: the AFS PTS server, and
> John Hascall's double-secret authz server (Stanford's wallet might
> be another example, but I don't know enough about it to say so
> let's not bring that into the mix right now).
> 
> Both services work in roughly the same way: you send them an identity
> which you have derived from your authentication service (Kerberos in
> both cases) and the service responds with what you are allowed to
> do.  In the AFS PTS server's case you get a set of groups that the
> identity belongs to which are used by the AFS fileserver to determine
> permissions based on ACLs stored on directories.  In the Hascall
> double-secret authz server you get a "yes/no" answer regarding access
> to a particular service (John, if I've got this wrong, please correct me).
> 
> Note that both of these services are pretty simple, and don't involve
> adding bits to the Kerberos protocol.  They both predate LDAP, so it's
> hard to say whether or not they would have used them.  Personally, I
> think LDAP is a crappy protocol to use for authorization queries ...
> it is fine for _managing_ authorization data, but I want something with
> fewer round-trips in the authorization path (I would probably do a custom
> protocol).

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

The application simply asks the API library to determine whether or
not the authorization should succeed based on the repository of
managed data.  If we restrict ourselves to single dimensional
authorization its one LDAP lookup.

> DCE tried to put authz data into Kerberos, and I think everyone would
> agree that DCE has been a failure.  Now obviously putting authz data
> into Kerberos is not the reason that they failed, but it just shows
> one of the fundamental problems with DCE - over-engineering.  You could
> bring up Microsoft as a counter-example.  That would be true, but Microsoft
> has the advantage of having tons of paid programmers to implement their
> designs and they control all aspects of their software at all levels.
> In the open-source world we do not have those luxuries ... we need to
> be able to have designs that are simple to implement and understand, and
> we need to be able to play nicely in heterogenous environments.

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.

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.

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.

With respect to overall complexity I will be interested in the
responses to the gedanken challenge I outlined above.

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

> --Ken

Best wishes for a productive remainder of the week.

}-- End of excerpt from Ken Hornstein

As always,
Greg Wettstein

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

"The real question is not whether machines think but whether men do."
                                -- B. F. Skinner
                                   _Contingencies of Reinforcement_