Subject: Access control framework ID

From: Mike Swift <[email-masked]>
Date: Tue, 1 Dec 1998 13:41:24 -0800

Cliff -

I'm not able to attend next weeks IETF meeting, but I was able to read
your draft on access control and think it is really interesting. There
are a couple of points that I think would be useful to add or consider.

1. The DCE & NT access control models include a reference monitor that
implements the AVR - it might be worthwhile to talk about this, as this
framework distributes the AVR.

2. Some discussion of a provider model, where a single piece of code is
the provider for all the access control decisions under a certain
authority, would be useful. It seems that we don't want to have to have
monolithic providers that have to understand every variant of access
control decisions. It might also be useful to define some kind of
generic access control entry that does not depend on a specific provider
- it just has to compare the input arguments.

3. Some discussion of inheritance is useful. The Netware security model
propagates inheritance rights down the directory tree, so that there is
not a single ACL to evaluate. In NT you can get access to an file either
through the directory or through the file itself, so again there are two
ACLs. At least specifying how this could be done would be useful, or
maybe taking a stance saying it can't be done.

4. In section 2 you list the goals of the framework. I think two
necessary goals are to (a) integrate with existing OS or toolkit
provided access control mechanisms, and (b) be able to provide high
speed implementations for operations that are supported natively by the
underlying system. An application writer shouldn't have to give anything
up by using this framework, so existing tools and ACLs stored by the
underlying system should be usable in some sense - perhaps through a
converter, or a special provider.

5. In section 6.3 you list access identites. I would add a sixth kind of
identity: connection. An application may want to distinguish based on
bandwidth, particular network (SAN vs. LAN for a cluster), dialup, level
of securty of the connection (encrypted / integrity protected / lead
pipes).

6. In section 10.1,  the gaa_get_object_policy_info function. I know
that in NT people often request a way to get a particular user's rights
on an object. This is used for UI purposes, so the application knows
what fields to display for input, what to highlight, etc. It might be
useful to have some notion of "maximum allowed" - the list of rights the
user has, and the appropriate conditions on those rights.

7. It isn't clear to me how boolean formulas of access control entries
can be used. One thing I've always thought would be useful is something
that allows you to express "group a and user b or group c and group d."
It sounds like this can be done by the application by parsing the
detailed answers, but I wasn't clear if this was possible to specify
boolean relations in the ACL itself.

8. The framework seems very general. Unlike the GSS-API, I don't see
clearly how an application writer can write code that is portable across
multiple providers - so much of the information is specific to
particular applications and providers that I'm not sure how much benefit
there is to providing this framework. I guess some examples of being
able to use this framework to write portable code would be useful to
clarify the benefit it provides.

- Mike Swift
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]