RE: ACL Draft

> ----------
> From: 	hep@netscape.com[SMTP:hep@netscape.com]
> Sent: 	Wednesday, October 22, 1997 5:58 PM
> 
> Paul,
> 
> > To stop a possibly long debate -- yes, we need to agree on what
> > principal names are. I didn't mean to imply differently.  I just said
> > that we shouldn't do so in the ACL draft, but rather in an
> > authentication draft. It is an issue of separation of concerns. The form
> > of principal names and how a user or server proves that they are
> > identified by a particular principal name is just totally orthogonal to
> > the question of the ACL draft (as long as principal  name can be encoded
> > as a string).
> 
> I'm trying to make a distinction between the credentials exchanged during
> an
> authentication process, and how the specification of a principal within an
> ACE on the wire references a user identity.  I don't believe these need to
> be the same, or even the same form.
> 
Yes they do. Any information that isn't exhchanged in an authentication
process isn't authenticated, and isn't secure.

> In my view, a principal specification in an ACE on the wire should be an
> extensible description of a set of principals.  The form of the
> description
> ought to be included in the access control protocol specification, and it
> should allow expressions such as:
> 
>   user=<principal identifier for Ringo> AND dns=*.old-drummers.org
> or
>   group=<principal identifier for Beatles> OR dns!=*.foo.com
> 
> (modulo the group consensus on a reasonable syntax).  The mechanism can be
> arbitrarily extended by defining more attributes (e.g. "user", "group",
> "dns", "ip") that can be used in the expressions.  I'd hope that the
> access
> control protocol specification would require that a set of the most common
> attributes be supported.
> 
I completely disagree. Users without degrees in computer science have to use
ACLs. They don't understand boolean predicates. We get zillions of
complaints that what we have is already too complicated. The only way I
convince myself to swallow all this dynamic inheritence stuff is because I
believe it means users have to understand less (more stuff is inherited and
managed for them) -- and some days I'm not even sure about that.

> The form of <principal identifier for Ringo> may actually be opaque, but
> it
> should be canonical, i.e. anywhere that Ringo is identified in the access
> control protocol (ACEs, resource owner, lock owner), the exact same
> <principal identifier for Ringo> must be used.  And it would be good if
> there were operations to:
> 
>   fetch a principal identifier for the currently authenticated user
>   fetch other properties (to be defined) of an entity referenced by a
> given
> principal identifier, including at least a descriptive name to display in
> the client UI
> 
> The terminology is part of the confusion, I think.  I'd suggest that
> "principal identifier" be used to mean a canonical reference to a user or
> group object that is accessible to the server at least, but also possibly
> to
> the client as well.
> 
Why can't you accept the traditional definition that the principal
identifier is everything about request to access an object that determines
what rights the request has to that object?   I.e., the security reference
monitor contains a function
	bool CheckAccess(principal-ID, method, object)
that returns "true" if access is allowed, and "false" otherwise. The
"principal-ID" is whatever combination of information that we decide is
needed to make that decision -- it doesn't have to be just the user ID.
(Whatever you do use, however, needs to be authenticated...)

We gain nothing by inventing new terminology when there is already well
established terminology.

>   Conceptually, any authentication mechanism maps
> authentication credentials to a user (or perhaps group) object, and once
> that is done, the corresponding principal identifier can be retrieved from
> the object, or constructed by using information in the object.  (In the
> case
> of certificate-based authentication, the client certificate might actually
> be the user object.)
> 
You could equally well say that an authentication mechanism maps
authentication credentials to a set of principal identifiers -- the
intermediate step just limits the possible implementations of the
authentication mechanism.

> The descriptive form which I called "a principal specification in an ACE
> on
> the wire" and gave examples of above, needs a term to describe it that
> does
> not use "principal". Generally speaking, it is a conditional expression
> that determines under what conditions the ACE which contains it applies,
> that is, under what conditions the policy of granting or denying rights as
> specified in the ACE will be effective.  (Subject to the mechanism for
> resolving conflicting policies in different ACEs.)  I'd suggest that
> something like "ACE conditions" or "ACE conditional" be used to refer to
> this concept.
> 
This is much more sensical. (I disagree with it completely on the complexity
grounds I mentioned above, but that's different.) In terms of the
CheckAccess function above, we might write it something like this
(simplifying a lot):

CheckAccess(pid, method, object) {
	acl = GetACL(object);		// get the acl for this object
	rts = GetRights(method);	// get rights needed to allow this
method
	ace = FindACE(pid, acl);		// find the ACE that applies
to this pid
	return ((rts & ace.rights) == rts);		// return true if
rights needed included in ace's rights
};

In these terms, as I understand it, you want FindACE to include a boolean
predicate over the principal ID (or components of it), and that you want
lots of stuff in the principal ID other than just the user ID. However, this
doesn't require a change of the definition of what "principal ID" means.

I think I understand you now -- am I making myself clearer?

Paul

Received on Wednesday, 22 October 1997 21:54:27 UTC