Thoughts on a Kerberos based open-authorization architecture.

[greg@enjellic.com]

Good day, I hope everyone's week has gone well.

I'm writing this as a 'put up or shut up' response for those of you
who remember the SASL/GSSAPI/LDAP thread.  I received a number of
interesting personal replies in response to my comments.

A surprising number of them indicated the opportunity had been missed
and we would have to learn to live with proprietary control over how
authorization will be carried out.  A number of other replies,
characteristically, informed me it was easer to bitch rather than
write code.

In defiance of the former and in response to the latter I decided to
compose this note.

Anyone who feels the battle has been lost or that IT doesn't need an
open playing field in authorization can hit delete.  It won't offend
either myself or my golden retriever Iggy who is laying on my feet
under the desk.

A small group of us have devoted a great deal of time to thinking
about an open-architecture 'mechanism' for implementing authorization.
Mechanism is a subtle but important point.  We believe there needs to
be isolation between the mechanism for implementing authorization and
the actual authorization policy which is executed.

Beyond this basic premise our goals were as follows:

        1.) Simple and flexible.

        2.) Synergistic combination of the strengths of Kerberos and
            LDAP.

        3.) Inherent security from the directory perspective.

We believe the latter concept to be particularly important.  As
authorization becomes increasingly important directory integrity
becomes more and more integral to security.  Subterfuge of a directory
controlling authorization offers an opportunity for attackers to grant
themselves escalated privileges or access rights.

In formulating our mechanism we went back to the basics of thinking
about what authorization actually is.  We concluded the authorization
process involves the interaction of two basic components:

        1.) User

        2.) Service

Before proceeding further, a necessary aside on the concept of a
'Service'.  For the purposes of this discussion a 'Service' is a
generic label for anything an organization wishes to authorize access
to.  It could be as granular as a single application or as
organizationally global as a role.

If you are comfortable with role based authorization think about the
model in that respect.  The authorization mechanism would be used by
an application to decide whether or not the user should be granted
access to a role.

Using these two basic components our strategy was to develop a model
where authorization involves the interaction or combination of these
two elements.  Authorization is the progeny, if you will, of the
genetic combination of the user and service.

Creating a model for this process requires a definition for the user
and service.  This definition is best thought of as the 'identity' of
the user and service.  The identity is a unique N-bit vector granted
by an organization to each user and service it manages.

Moving forward we will refer to this N-bit vector as the 'intrinsic
identity (ii)' of the user or service.  We thus have the following
labels:

        Uii = User intrinsic identity (N-bit vector)

        Sii = Service intrinsic identity (N-bit vector)

Our model combines a user and service to produce a third element which
represents the user's ability to access a service.  We will refer to
this element as follows:

        SIii = Service instance intrinsic identity (N-bit vector)

A cryptographic hash with a message size of m=N provides a convenient
mechanism for implementing the genetic combination of the user and
service identity.  We thus implement our authorization model as
follows:

        Hm(Uii,Sii) = SIii

The model is brought to practicality by thinking about what it means
with respect to an LDAP directory.  The hexadecimal representations of
the Uii, Sii and SIii are used to formulate the distinguished names
(DN's) of the identities in the directory.  The following regex
shorthand will be used to represent the actual value of the identity:

        [0-9a-f]{Lm}

        Where Lm is the length of the ASCII representation of the
        intrinsic identity hash values.  For m=160, Lm=40.

Now lets consider a hypothetical organization with one user being
granted one role.  The LDAP directory would contain the following
three objects (neglecting attributes):

        Uii=[0-9a-f]{Lm},dc=something,dc=com

        Sii=[0-9a-f]{Lm},dc=something,dc=com

        SIii=[0-9a-f]{Lm},dc=something,dc=com

The presence (or absence) of the SIii object in the directory conveys
the willingness of the organization to grant (or not grant)
authorization to whatever Sii represents.

Since the SIii object can contain attributes it serves as a very
convenient mechanism for storing policy information which the
application can use for making a more extended authorization decision.

As an example of this and to demonstrate the importance of the
fundamental underpinnings of the model lets consider a very simple
extension to the above directory objects:

        Uii=[0-9a-f]{Lm},dc=something,dc=com
        state: enabled|disabled

        Sii=[0-9a-f]{Lm},dc=something,dc=com
        state: enabled|disabled

        SIii=[0-9a-f]{Lm},dc=something,dc=com
        state: enabled|disabled

An attribute called state has been added which has the two basic
values of enabled or disabled.  An application can query the attribute
in any one of the objects to determine whether or not the
authorization policy decision should be made.

The organization can turn off authorization for our single user in any
one of three ways.

        1.) Set the Uii object to disabled.
        2.) Set the Sii object to disabled.
        3.) Set the SIii object to disabled.

This flexibility is certainly not useful in our hypothetical
organization but clearly useful in a larger organization with
thousands of users and multiple services/roles.  Authorization can be
revoked organizationally for an entire service by simply disabling the
Sii identity object.

In a similar manner a single user can be denied access to all services
or just a single service.  The former case is achieved by disabling
the Uii object, the latter by disabling the SIii object.

We can pause for a moment and see where things are at.  We have a
generic model for authorization based on the interaction of a user
with a service.  We implemented the model by using a cryptographic
hash and publishing the outputs in a directory.

In doing this we have achieved a subset of our goals.  Its a
comparatively simple mechanism for implementing authorization policy.
Implementation is achieved by effectively leveraging the strengths of
LDAP.

Unfortunately it hasn't achieved the goals of leveraging Kerberos nor
of being very secure.  A compromise of the directory provides
everything needed to create 'false' authorizations.  One simply runs a
cryptographic hash on a Uii and Sii, inserts the result in the
directory and accesses whatever service or role the identity
represents.

So the challenge becomes in how to use Kerberos to fix the security
deficiency.  The one thing Kerberos is very good at is managing secret
keys.  We will leverage this strength and change our model a bit to
impart a higher level of security.

We extend the notion of a 'Service' having its own identity a bit
further by granting each service its own authentication identity
(principal) in the KDC.  The following naming scheme will be used for
these principals:

        svc/NAME at REALM

        Where NAME is whatever label is applied to the service or role
        the organization is conveying authorization for.

The important side effect of creating this principal is the generation
of one or more symmetric keys which are associated with the principal.
We choose one of the keys which we will label as Kn where n is the bit
length of the key.  For example lets consider des3-hmac-sha1 where
Kn=192.

The des3-hmac-sha1 key is typically used in derived form.  For
purposes of discussion we will assume an appropriate key derivation
constant has been allocated and used.  So Kn actually represents the
derived value of the primitive key.

We can now return to our basic model for describing the interaction of
a user and service which is as follows:

        Hm(Uii,Sii) = SIii

Conveniently, cryptographic hashes are typically available in a keyed
variant as well.  We will replace our hash function with its keyed
variant to yield the following:

        HmKn(Uii,Sii) = SIii

The same directory publication schema is followed using the keyed
variant value of SIii.

Using this procedure advances us more completely to our goals.  We
have enhanced publication security of authorization identities using
the symmetric key management capabilities of Kerberos.  By imparting a
cryptographic impediment to the formulation of the SIii identity the
directory itself no longer contains sufficient information to generate
bogus authorization identities.

        Unless of course one insists on stuffing both identity and
        authentication information into the directory....... :-)

The model inter-operates well with the authorization payload field of
Kerberos tickets.  The payload field contains the SIii of the service
or services the user has access to.  The application extracts the
SIii's and references the appropriate object(s) in the directory to
implement the authorization policy decision(s).

The model also supports applications which are not strictly
'kerberized'.  In a simplistic implementation the
authentication/authorization (AA) system needs access to a keytab on
the host containing the svc/SERVICE keys.  The AA system would
implement the HmKn(Uii,Sii) = SIii calculation and base its policy
decision on lookup and processing of the three intrinsic identities.

We've implemented a PAM module which does this for proof of concept
purposes.  We are also contemplating a superior strategy based on the
use of a service ticket.  Current thinking centers on how to
communicate the service(s) labels in a service ticket request for a
particular host.

As I stated at the outset our goal was to have a flexible mechanism
for implementing authorization.  This system supports (and enhances)
strategies such as PAC where the authorization policy information is
encapsulated in a PKI protected certificate.

In a PAC model the SIii object in the directory provides the container
for holding the certificate.  The model provides the added advantage
of a system where execution of the certificate encapsulated policy can
be turned on or off without modification of the certificate itself.

Our thinking on this authorization model is actually part of a much
larger body of work.  There is of course a management framework needed
on top of all this to make 'binding' of a service or role to a user
tractable and intuitive from an administrative point of view.  The
creation of the intrinsic identities for the users and services are
part of another large body of thinking on how to securely generate and
manage electronic identities.

Talk is cheap of course.  To the pundits who said 'write code' we
actually have a full implementation of the entire framework in proof
of concept form.  This includes a set of extensions to MIT Kerberos to
support injection of SIii's into Kerberos tickets in addition to other
functionality.  Its GPL and is free for the taking if anyone is
interested.

To cover our bases a bit we have also spent some time doing collision
modeling.  The work isn't complete but we have successfully modeled
organizational management systems containing 1 billion users with
multiple services.  With that said I will certainly become infamous as
the person who stated a billion users is more than enough for anyone.

I personally enjoy working on all this so acceptance isn't something
I'm seeking.  I do believe, as a community, we are short-sided on
giving up on establishing a generic mechanism for implementing
authorization.  By focusing on mechanism rather than policy everyone
benefits, most specifically application developers and system
architects.

To conclude Iggy and I thank everyone who has bothered to read this
far and who are provoked into thinking a bit more deeply about the
importance of an open authorization architecture.

Best wishes 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
------------------------------------------------------------------------------
"Whenever you find that you are on the side of the majority, it is time to
reform."
                                -- Mark Twin