RE: LDAP ACL model document

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Just scanned the document.

The following comments are provided:

a) Why on earth are we proposing something so different to X.500 ACI.
When that works......



Can any one on this list give me one good reason with some sound non
religious statements (not its too hard, etc) why!......................

THE WORLD IS TRYING TO STANDARDISE ON SECURITY RELATED PROCESSES FOR
GLOBAL ELECTRONIC COMMERCE AND DISTRIBUTED PROTECTED DIRECTORY SERVICES
WHICH INCLUDES AUTHENTICATION AND ACCESS CONTROL MECHANISMS - HAVE WE
OVERLOOKED THIS POINT......

THE TEXT BELOW


Eg. 
 Subject security attribute information is
 associated with subjects.  Each subject must have
 an LDAP directory entry, and a subject's security
 attribute information is stored as attributes of
 its directory entry.

HOW DOES THIS WORK IN A DISTRIBUTED LDAP SERVER ENVIRONMENT - WITH
REFERRALS TO  OTHER SERVERS WHICH DO NOT HAVE MY SECURITY REFERENCES IN
!!!!!!

X.500 does this with mutual authentication - in a distributed trust
model. And that works.

This draft ....DISTRIBUTION, Mutual Authentication, Commercial
Usefulness and practicality ?????

WHAT SEEMS TO BE TOTALLY MISSING IS THE aci FRAMEWORK BASED ON THE
DISTRIBUTED INFORMATION MODEL AS USED BY DIRECTORY SERVICES . aci MUST
BE ENFORCEABLE ACROSS MANY "SERVERS" WITH COMMON PROFILES with THE USE
OF STANDARDS. Not be open to local variations cause by the semantic and
trust interpretations of locally defined strings.



COMMENTS - 3.2 defining authority
having strings represent levels of clearances as a semantic without any
tie to a distributed trust model is a waste of time. eg a US "secret"
string could be interpreted as being dominated by a UK "unclassified"
string - who sets the rules here - a local issue???


Ditto with all the other text eg semantics of roles - is there a
standard for role trustworthyness conventions? - ie the security
attribute stuff is untrustworthy, unworkable and unscaleable.....


3.4.1 Credential versions - how is this enforceable - how does one
migrate versions - what are these ?? Are there trust differentiators
with versions ?? 


4.1.2 ACL Owner attributes - not sure why we have these when the X.500
model requires that a  User has Permissions - and no semantics are
applied re admin - they are just users with many privileges. This is
wasted definition and thus wasted user configuration effort.


4.1.3 Attribute Classes
Attributes are grouped in classes... this is also unscaleable,
unworkable, cannot be uniformally applied - different servers will do
this differently no doubt....

What about storage of ACI - is that subentries or entry level or both?


IF I AM BLUNT then its about time some one said that enough is enough.
This LDAP effort is not standards setting - it is causing a global
information mess. 

Access Control and trust in distributed directory systems is fundamental
- and we have a standard..


Whats the process for violent objection based on the fact that a good
working international standard already exists. And the one proposed is
unworkable....

Hopefully most will just ignore the text and let it die.










> -----Original Message-----
> From:	Ellen Stokes [SMTP:stokes@austin.ibm.com]
> Sent:	Saturday, March 28, 1998 3:15 PM
> To:	internet-drafts@ietf.org; ietf-ldapext@netscape.com
> Subject:	LDAP ACL model document
> 
> To the drafts editor:  please publish the attached draft.
> 
> To the ldapext group:  please find attached draft of the
> ldap ACL document.
> 
> Thanks.
> Ellen
>  << File: draft-ietf-ldapext-acl-model-00.txt >>