RE: X.500 vs. LDAP ACL MODEL PROPOSAL comparison

["Miklos, Sue A." <samiklo@missi.ncsc.mil>]

(SM) I am attempting to catch up with discussions on this topic and have
the following comments:

>> SUBJECT TYPES
>> 
>>  X.500: 5 types
>> 
>>   User DN
>> 
>>    DN of a user entry
>> 
>>   THIS
>> 
>>    DN of the entry itself (used only with
>>    prescriptive ACI)
>> 
>>   Group
>> 
>>    entry DN of a "group of names" type entry

(SM)This group of names must be known by the local DSA - And, if I wish
to ensure that any given element of information (value) within a type is
only modified by a particular name, I must ensure that the local DSA has
that name correctly.  I am particularly interested in ensuring that mail
lists and certificate information can be managed by assigned roles in a
very granular fashion.  In most cases, the operational environment is
willing to accept the administrative burden associated with an ACI that
has type/value capability.

>> 
>>  LDAP ACL MODEL DRAFT: 1 type + 2 additional proposed types
>> 
>>   DN
>> 
>>    DN of:
>>     user with entry in this directory
>>     foreign user
>>     group
>
>To be fair, group should be classified as a separate type as in the X.500
>case
(SM)Agree, and the creation of groups needs to be clearly stated
(constraints, how 'membership' is determined, etc.
>
>> PERMISSIONS
>> 
>>  X.500: 12 permissions in 3 categories
>> 
>>   usable at any granularity:
>> 
>>    Add
>>    Disclose on error
>>    Read
>>    Remove
>> 
>>   not usable at Entry granularity:
>> 
>>    Compare
>>    Filter Match
>> 
>>   usable ONLY at Entry granularity:
>> 
>>    Browse
>>    Export
>>    Import
>>    Modify

(SM)Very useful to manage specific attribute types and values within an
entry, without allowing the ability to completely remove or add new
entries.  Good information management tool.
>>    Rename
>>    Return DN
>> 
>>  LDAP ACL MODEL DRAFT: 8 permissions in 1 category
>> 
>>    Add
>>    Delete
>>    Manage
(SM)Is this equivalent to modify ?
>> 
>> PRECEDENCE
>> 
>>  X.500: Many levels, ACI entry granularity
>> 
>>   Each ACI entry has a numeric precedence.
>>   Different ACI entries in the same directory
>>   entry or subentry may have different precedences.
>>   The standard does not define a range for
>>   precedences, so the number of levels is in principle
>>   infinite.
>>
>
>The standard does define that precedence lies in the range 0-255. Here is the
>ASN.1
>Precedence		::= 	INTEGER (0..255)

(SM)Our current implementation guidance documents recommend that the
first 10 levels be reserved for the global ACIs, and the lowest levels
be used in the inner-most nested areas, to preclude setting ACIs that
lead to inadvertent denial of service.
> 
>>  LDAP ACL MODEL DRAFT: none

(SM)Would most corporate environments have servers that would 'nest'
areas?  Isn't this a useful function?
>> 
>> AUTHENTICATION STRENGTH
>> 
>>  X.500: 3 levels
>> 
>>   Strong
>>   Simple
>>   None
>> 
>>    (note that these are the X.500 authentication
>>    mechanism names, NOT the LDAP mechanism
>>    names).
>> 
(SM)We have several policy statements / operating procedures that
require a minimum of strong authentication on binds (requiring
pre-placed CRLs, for the two-way case) and, digitally signed modify
requests, as we require audit on who is managing the information in the
server.  This would be extremely beneficial in the LDAP model, and, I
had thought was consistent with the PKIX requirements

>>  LDAP ACL MODEL DRAFT: none
>> 
>>   Proposers are considering proposals to add
>>   this function based on the LDAP authentication
>>   mecahnism names.
>> 
>> DENIAL
>> 
>>  X.500: per permission, subject to precedence
>> 
>>   each permission may be explicitly granted or denied
>> 
>>   denials only override grants at same or lower precedence
>> 
>>  LDAP ACL MODEL DRAFT: none
>> 
>>   Proposers have agreed to add this function
>>   based on expressed IETF ldapext working group consensus
>>   (but still think it's a bad idea!).

(SM)In some cases, it makes it much harder to manage, but the risks need
to be evaluated.  There are definitely those environments where 'safer
is better' even if it means I have to pay for smarter administrators and
manage my information more closely.

>
>>  U6: "Management of access to resources in an entire subtree
>>   SHOULD require only one ACL"

(SM) I'm not sure I understand this.. Is the intent to have one list of
all the names that map to ACIs used within the subtree? But that all the
members of this list do not have access to manage all the information
within that entire subtree?

Thanks for your patience while I catch up.
>Sandi