Re: LDAP Access Control - comments

[Alan Lloyd <alan.lloyd@opendirectory.com.au>]

AL: re this response - may I comment

From:
          Ellen Stokes [SMTP:stokes@austin.ibm.com]

  >
  >
  > QUESTION 1: Do you believe LDAPEXT should be trying to define
  > requirements, framework, and/or a model for access control in
  > LDAP directories?


  Yes.  It is needed for interoperability and
  the replication work.

AL: as said - the Access control issue has to be dealt with for
DISTRIBUTED operations. I keep seeing this "replication" push. As one
cannot authenticate mobile users on a cloud of directories without
distribution and mutual authentication and the use of X.509 or simple
authentication. One cannot - with this non distributed LDAP server mode
of operation - replicate everything to every where using the LDAP
configuration army. Authentication AND access controls MUST be defined
for distributed directories - otherwise the trust and protection
mechanisms do NOT SCALE. See X.500 for scaleable trust and protection
mechanisms.


  >
  > QUESTION 2: Do you basically support the access control
  > requirements draft (draft-ietf-ldapext-acl-reqts-00.txt)?


  Yes.

AL: that is an issue see below.







  >
  >
  >
  > QUESTION 3: Do you basically support the access control model
  > draft (draft-ietf-ldapext-acl-model-00.txt)?


  Yes, plus the additions that were requested at the last IETF
  meeting.

AL: Well perhaps the changes have improved it. But if it does not deal
with the strong tie between Authentication and AC and works consistently
for distributed directories - and deals with the 5 dimensional issues of
Auth/ACI then it will be weaker than X.500 ACI. And if so - why bother.






  >
  > QUESTION 4: Do you think we should adopt the X.500(1993)
  > basic access control model as the starting point for the LDAP
  > access control model?


  No.  The X.500 access control model does not meet requirements
  as the acl model authors will show shortly.

AL: I hope they do show this - in DETAIL with engineering
specification.

AL: I note that IBM are authoring this document. I find it curiuos that
IBM are deploying Electronic Commerce X.500 systems and responding to
large commercial organisations with major X.500/509 solutions.
As a customer or as a potential  customer of IBM - who is trying to
standardise on  trusted directory infrastructure for core business
purposes - I would be seriously concerned that a supplier did not
support totally and without question the internationally defined
standardised trust and protection mechanisms provided in the directory
technologies being commecially offered.

I personally would not make such a public statement without the consent
of the CEO or company marketing manager - as this could destabilse any
major tenders and business potential for directory technology sales and
change my future.
eg. The allied and NATO forces and the carriers have standardised on
X.500 for their directory infrastucture - Is IBM not interested in this
business.

Opendirectory have implemented the X.500/509 Authentication and ACI
mechanisms for distributed and industry strength trusted directory
systems and absolutely stand behind the quality of this implementation.






  >
  > QUESTION 5: Do you think we should specify only a framework
  > for identifying access control models, and not define a
  > single standards-track model for LDAP at this time?


  No, a framework does not provide for interoperability - it
  will only profilerate more acl models.  There must be a
  single standard-track model for ldap.



AL: This is a curious statement - because as said - Authentication and
Access Control systems must be bound together - and as X.509 is titled
as an Authentication Framework for directory access - and that ACI must
have some notion of an administrative framework (see X.501) so it can be
applied in a distributed manner - then what is the substance and fabric
for the design of LDAP ACI.

In closing - this LDAP ACI work can be developed in any which way and
with any engineering principles for any perceived market strategy - If
the result turns out to be just a pile of untrusted lines of ASN.1 in an
RFC, I think most of those dealing with X.500 and ACI will just ignore
it - and market the fact that it has less capability than the
International standard - so why bother.

regards alan