Subject: A Filter Based Approach to ACIs

From: "Brian Jarvis" <[email-masked]>
Date: Tue, 21 Dec 1999 15:11:09 -0700

I recently had a conversation with some marketing types who lamented the fact that they had difficulty selling to the military because we could not grant rights based on login-location (IOW subnet)  *AND* userID.  It seems that it is desirable to give rights to a user, but only allow him to exercise them from privileged locations (with secure wiring).

In most highly secure systems this would be handled by giving the userID discretionary rights (ACIs) and then limiting access to the same resources by using mandatory access controls (labels) based on login location.  This works because the combining of mandatory and discretionary access controls is an AND (minimizing) operation.

In the current ACL draft-04, there is support for login location support but no ANDing operation:

    "The subjectDN may be a DN or another string such as IPAddress (dotted-decimal string representation) on which access control is get/set." (section 8)

<Waxing Philosophical>

But what is an ACI really?

An ACI is a set of privileges granted (or denied) for a set of subject objects to act upon a set of target objects.
How we define the "set of subjects" and "set of targets" is interesting.  Right now we are defining them as a single object, as a subtree, as members of a group, as occupants of a role, or as an ip-address.

Generalizing, we really want to define these sets by using filters (as used by search).  Thus the set of subject objects is defined by a "subject filter" and the set or target objects is defined by a "target filter".

<UnWaxed Reality Restored>

Access control needs to be fast.  Generalized filters are too slow.  So lets limit the generalized filters to limited filters that we can perform quickly.  Filters are arbitrary nested expressions of ANDs and ORs of AVAs (attribute value assertions).  They can all be simplified to a "sum of products" or a "product or sums".  The product of sums seems more useful to me.  I fact lets limit it futher to a "product of terms" and limit the terms to what we can evaluate quickly.

The current draft is more limiting.  The filters are a single term out of small set of choices.  

Subject Terms
   single DN (currently supported)
   subtree (currently supported)
   member of a group (currently supported)
   occupant of a role (currently supported)
   any (currently supported, "public")
   subject and target are same object (currently supported, "this")
   ip-address (currently supported)
   ip-subnet (new)
   NOT <any of the above terms> (new)

Target Terms
   single DN (currently supported)
   subtree (currently supported)
   any (currently supported, on root of tree)
   subject and target are same object (currently supported, "this")
   object class (new)
   NOT <any of the above terms> (new)

<Blue Sky mode>
If we get ambitious, we can also do

Subject Terms
   arbitrary AVA on subject object
   special kind or level of authentication
   secure connection

Target Terms
   arbitrary AVA on target object
   time of day

<Back to gray sky reality--it looks like snow, here>

If each ACI has a list of subject terms and list of target terms (from the above lists) and ALL of the terms must evaluate true for the ACI to apply we have a very powerful system that is still quick to compute.  We will be able to do all of the following (actual requests from customers):

subjects = subtree - particular user = subtree and not dn
subjects = subtree - group = subtree and not group
subjects = subtree - (smaller) subtree = subtree and not subtree
subjects = groupA and groupB (intersection of groups) = group and group
targets = printer objects only = object class printer
subjects = admin logged in on special terminal = dn and ip-address
subjects = admin logged in on subnet (such as a military base) = dn and ip-subnet

Although I have thought about it, I have intentionally not discussed how to implement this in our ACI format or how vendors may extend the available filters.  The collective must be at least interested in this approach first.

I believe this "product of limited terms" approach will be similar in computational difficulty to what we currently have while the power of the ACI will go up dramatically.

I look forward to your comments.

--the walrus

---

From: Erik Skovgaard <[email-masked]>
Date: Tue, 21 Dec 1999 16:29:50 -0800

Brian,

I like this idea.  I have several times had the need to distinguish
anonymous access based on whether a user was on the intranet, the extranet
or the Internet.

Some PKI products require anonymous access to the PKI certs, so it is not
always possible to provide proper authentication.  Access based on IP
Address could go a long way to fixing that problem.

Cheers and Seasons Greetings,             ....Erik.

---------------------------------
Erik Skovgaard
GeoTrain/Global Knowledge
Enterprise Directory Planning Services
LDAP & X.500 Training
http://www.geotrain.com

At 15:11 99/12/21 -0700, Brian Jarvis wrote:
>I recently had a conversation with some marketing types who lamented the
fact that they had difficulty selling to the military because we could not
grant rights based on login-location (IOW subnet)  *AND* userID.  It seems
that it is desirable to give rights to a user, but only allow him to
exercise them from privileged locations (with secure wiring).
>
>In most highly secure systems this would be handled by giving the userID
discretionary rights (ACIs) and then limiting access to the same resources
by using mandatory access controls (labels) based on login location.  This
works because the combining of mandatory and discretionary access controls
is an AND (minimizing) operation.
>    "The subjectDN may be a DN or another string such as IPAddress
(dotted-decimal string representation) on which access control is get/set."
(section 8)
>An ACI is a set of privileges granted (or denied) for a set of subject
objects to act upon a set of target objects.
>How we define the "set of subjects" and "set of targets" is interesting.
Right now we are defining them as a single object, as a subtree, as members
of a group, as occupants of a role, or as an ip-address.
>
>Generalizing, we really want to define these sets by using filters (as
used by search).  Thus the set of subject objects is defined by a "subject
filter" and the set or target objects is defined by a "target filter".
>Access control needs to be fast.  Generalized filters are too slow.  So
lets limit the generalized filters to limited filters that we can perform
quickly.  Filters are arbitrary nested expressions of ANDs and ORs of AVAs
(attribute value assertions).  They can all be simplified to a "sum of
products" or a "product or sums".  The product of sums seems more useful to
me.  I fact lets limit it futher to a "product of terms" and limit the
terms to what we can evaluate quickly.
>If each ACI has a list of subject terms and list of target terms (from the
above lists) and ALL of the terms must evaluate true for the ACI to apply
we have a very powerful system that is still quick to compute.  We will be
able to do all of the following (actual requests from customers):
>Although I have thought about it, I have intentionally not discussed how
to implement this in our ACI format or how vendors may extend the available
filters.  The collective must be at least interested in this approach first.
>
>I believe this "product of limited terms" approach will be similar in
computational difficulty to what we currently have while the power of the
ACI will go up dramatically.
>Attachment Converted: "d:\Program Files\Eudora\Attach\Brian Jarvis3.vcf"
>