[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Comments on aci-model-04
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J
***************************************************
Comments on acl-model-4
1) There is ambiguity over whether aCIMechanism is single valued or multi-valued.
The text says "the value (an OID)" whereas the definition says "list of access
control mechanism (sic)". If it is single valued then the definition should include
SINGLE-VALUE
2) Like Jim, I am also confused over the precise definitions of role and group. If
group refers to a group of names, which I suspect it does, please state this clearly.
It seems to me in 6.4.1. that the two examples with group have different
semantics, one refers to a group of names and the other to a subtree. It is not good
in my opinion to attach two different semantics to one DN type. If role refers to a
non-leaf object (container or subtree) then can you please rename it so that it is
clearer. If it does not, then I think that this type (subtree) is missing from dnType
and should be added.
3) I think you need to add Delete rights to attributes (6.2.1.1). This will be needed for
the Modify operation (i.e. you have to have permission to both add and delete
attribute values).
4) You gave an example of a printer as a pointed to object, but said that Use was not
applicable to it. I should have thought that it was applicable, and that Use could
mean that the subject was allowed to send a document to the printer.
5) Midway down p15, you said:
.is the equivalent of
aci: 1.2.3.4#subtree#grant;r,w;[all];
r,attribute1#group#cn=Dept XYZ
This should be
aci: 1.2.3.4#subtree#grant;r,w;[all];$grant;
r,attribute1#group#cn=Dept XYZ
6) Immediately below this, with the example for an empty permission, could you
also add a note to say that "Alternatively this could be achieved by having a
permission of deny;r,s;attribute1" so that usage of deny is also shown.
7) In 7.2, there is a possible security weakness, by implying that an access denied
exception report is returned. The attacker then knows that the information exists.
By contrast, X.500 can reply "information not present", so that an attacker cannot
differentiate between information that is not present and information that is
present but that he does not have access to.
8) Section 8 and 9. When asking for effective rights, do you think that there is value
in allowing an administrator to set the subjectDN to "all", meaning return the
rights for everyone who has access to this object. This would necessitate definition
of a third well known value.
9) A major omission from the document is that nowhere could I find the mapping
from required rights to LDAP operations. This should be included for each LDAP
operation (even if in some cases it is simply that one right is needed for a
particular operation e.g. delete an entry). The complex one is obviously the search
operation. I suggest you need read rights for every attribute returned and search
rights for every attribute in the filter.
10) A possible missing right is readDN for an entry. This cannot be fully covered by
read attribute rights, as the latter will only give rights to the RDN, not the DN.
11) Section 9.1.2. There is no sense in setting the criticality on the response. This text
should be removed. Ditto 9.2.2