Re: LDAP ACL model document

["Ed Reed" <ED_REED@novell.com>]

Ellen - here is a written set of my comments on the draft.

First a few observations...

1) The operation Get Effective Rights would be much more valuable if it were able/required to provide some description of "why" the subject has the rights granted, by way of explaination.  Such a facility is a frequently required function of a security policy inspection tool, and we might as well include the ability now, even if it is only optionally supported.  The explaination should identify _at least one_ of the SSAI entries which contributed to why the subject has the given right, and should include entries sufficient that ALL the given rights are so explained.

2) I notice there's no provision for negative ACLs.  They're a real complicating thing, and we may well be able to get along without them, but there are certain cases...should we address them explicitly?

3) One of the most frequently asked ACL features we're asked to support is the ability for administrator A to block the ability of any other administrator B to grant _any_ privileges to user X (defined within the scope of administrative authority of administrator A).  Whether this is done by preventing administrator B from adding X to a group or list in B's domain (hard to imagine - it's the spam DL creation problem), or by preventing anyone from outside of A from seeing X, or by some other mechanism is hard to imagine in an untrusted, interoperating environment of LDAP servers, but if you have any suggestions on how we might approach it, I'd love to hear about it.

4) Support for a permission like "Use" (section 4.1.4) opens up a whole can of worms relating to use of the ACL model by non-LDAP resource managers, and how those resource managers integrate with LDAP.  It's a very interesting discussion, but I wonder if you meant to start the discussion now, by tempting us with "Use", or not.  I'd LIKE the ACL model to be useful for other applications, but folks like Bob Blakely have much more experience with such efforts as DCE's ACL Manager to know what's required.  Could you elaborate?

5) The whole subject of external references seems missing from the model.  How LDAP objects which are not defined locally should be treated, handled, maintained, and garbage collected when referenced in local SSAI or ACI needs discussion.  In particular, is it mandatory that LDAP servers verify the existence of a named object when it is used in a Distinguished Name syntax (I think it should be, via the LDAP server's own resolution of the name).  What happens if the object to whom the DN refers is (a) deleted, or (b) renamed, or (c) moved to another portion of the namespace?

Welcome to the world of distributed referential integrity.  It's a world which _can_ be tamed!

The security issue can be highlighted by another question:  if object XYZ is named by a DN syntax field of a SSAI, or of an ACI, and XYZ is deleted or renamed, and then another object is created with the very same name XYZ, does the new object get the rights an privileges that were granted in the SSAI to the original object XYZ?  I belive it must not.  That suggests that names, in and of themselves, are insufficient basis for knowing which XYZ object is granted a right in some ACI.  Some immutable name, perhaps a UUID or the concatenation of the creation timestamps of each RDN component of the XYZ object DN, is a much better thing, and can be cached on any external references that have to be created to deal with non-local objects (local objects should carry those immutable attributes around with them).  NDS uses the sequence of creation time stamps (we call the Tuned Names for obscure historical reasons), but UUIDs can be made to work, as well...in fact,  a Tuned Name is very similar in many ways to a sequence of UUIDs when you come to think about it...never mind.

Basically, this boils down to a question about the definition of "identity":  is an identity immutable (unchangeable) and non-reuseable?  Is it unique in time, or for all time? (it needs to be unique for all time).

6) When is the SSAI computed in your model:  at Login time, when a user first authenticates themselves and obtains access to their private keys or TGT in Kerberos terms, or at each BIND time when authenticated connections are established to each LDAP server the user talks to?  If a server wishes, may it decide NOT to provide an SSAI list to a (probably) untrusted client, and rely solely on server-side storage of the SSAI information for the connection?

7) in section 3.3 - Examples of Subject Security Attributes, in the discussion of Subjects, do you agree that it is a requirement that all subjects be defined objects in the directory, whether local or non-local, so long as they can be resolved and verified to "exist"?

8) in discussing credentials, in section 3.4.1, you note that no proivsion is made for identifying the authority, nor for signing the subjectCredential structure.  That's what causes me the concern with regard to the prospect of transfering the subjectCredential material outside of the TCB of the LDAP server, and delivering it to a probably un-trusted client.  If the list leaves the TCB of the server, what good is it?  Or does it ever do so in your thinking?

9) I oppose the notion that the standard model imposes a "by default, grant read and search access on all attributes to any unauthenticated boob who asks" policy on LDAP.  I seriously believe that a "by default, deny all" policy is the only thing that makes any sense at all from a security policy standpoint.  How would I express that in your model (don't think I can...and that's a real problem).

10) typo:  the BNF of <class> in section 4.3 should include <object> as one of it's 'or'ed values.

11) in the ASN description of the attributes, I'd very much like to see the abstract syntax described, in ASN, of the ACLEntry, for instance, and elsewhere that you say "see BNF for blah".

12) in the discussion of failure/error codes, shouldn't we give some care as to what information is divulged to someone "fishing" for information...for example, if a server can't remove a privilege because it doesn't exist in that object's subjectSecurityAttribute, how specific an error should be returned?  Since this is SSAI, it may not be a big deal, but something seems odd about it...

13) in section 7.1, there needs to be a way to support ACLs on extended LDAP operations, as well as the core LDAP operations, no?  How should the requestValue be so extended?

14) there should be some discussion of audit trails somewhere, perhaps in section 8.

Enough for now.

Ed
>>> Ellen Stokes <stokes@austin.ibm.com> 03/27/98 09:13PM >>>
To the drafts editor:  please publish the attached draft.

To the ldapext group:  please find attached draft of the
ldap ACL document.

Thanks.
Ellen


-------------------
Ed Reed, Technologist
Group Technology Office
Novell, Inc.
+1 801 861 3320