Subject: LDAPv3 Replication Access Control Design Team Report

From: "Chris Apple" <[email-masked]>
Date: Mon, 9 Sep 2002 22:00:48 -0400

This represents the progress of the Design Team to date and meets
its obligation to report on activities up to and including work item
5 of the Design Team Work Program posted to the WG mailing list:

http://www.imc.org/ietf-ldup/mail-archive/msg01491.html

LDAPv3 Design Team Report to the LDUP WG

Date: 9/9/2002

Terms and Definitions:

access control decision function - algorithm used to perform access
control
checks to establish if an identified and authenticated entity is allowed
to
add, access, update, or delete information stored in the directory.

access control information - the data used in applying the access
control
decision function

access control model - format of the access control information

access control scheme - from X.500, identifies the access control model
and

access control decision function

examples of access control schemes: 

	X.500 Basic Access Control + role-based
	X.500 Simple Access Control + role-based

Direction & Minimal Requirements

A.  For an given object being replicated, the same access control scheme
must apply to that object in all replicas.

B. This can be accomplished in either of two ways: 1) LDUP can define
and
all interoperable implementations agree to use a single identified and
defined access control scheme; or 2) LDUP can define a way to identify
the
access control scheme used.

C.  In an area of replication there is a single access control scheme
that
applies to all data elements in the area of replication.

D. We need an administrative model which can be used to indicate the
access
control scheme that is applied to each data element in the area of
replication. It is important in this context to make a distinction
between
ACI "external to the directory" (i.e., ACI outside of the DIT) and ACI
"outside of the area of replication" (i.e., possibly ACI inherited from
part
of the DIT that is not replicated). The first, seems forbidden by
RFC2820
requirement G3 (quoted later in this report) and so this Design Team
proposes
a distinction to G3 that one deliverable of this WG must be a
specification
for a common set of over-the-wire ACI semantics and that a part of this
specification must include a requirement that Implementors of ACI
outside
of the DIT shall publish a specification of the mapping between their
internal ACI scheme and the over-the-wire scheme (and that the internal
schemes shall have an OID associated with them). The subject of whether
or not these OIDs and internal ACI schemes should be standards track or
of some other status once published as RFCs should be discussed on the
WG mailing list. 

If an access control scheme relies on information external to the
directory
(i.e. access control information is held outside of the area of
replication), the access control scheme MUST provide for consistent
access
to the information by cooperating replicas in support of the access
control
decision function employed by those replicas.

The access control scheme MUST define how the access control decision
function uses/accesses the same access control information.  If access
control information is held in the directory and in the area of
replication
then this information will be replicated by LDUP.

RFC 2820 Minimal Requirements:

U6.  Management of access to resources in an entire subtree SHOULD
   require only one ACL (at the subtree root).  Note that this makes
   access control based explicitly on attribute types very hard, unless
   you constrain the types of entries in subtrees.  For example, another
   attribute is added to an entry. That attribute may fall outside the
   grouping covered by the ACL and hence require additional
   administration where the desired affect is indeed a different ACL.
   Access control information specified in one administrative area MUST
   NOT have jurisdiction in another area.  You SHOULD NOT be able to
   control access to the aliased entry in the alias.  You SHOULD be able
   to control access to the alias name.

U17.  Administrator MUST be able to determine where inherited policy
   information comes from, that is, where ACLs are located and which
   ACLs were applied. Where inheritance of ACLs is applied, it must be
   able to be shown how/where that new ACL is derived from.

U6 and U17 either deal with implying that an administrative model
is required or deal with determining where inherited policy comes from. 
With "partitions" and "sparse/fractional" replicas, the Design Team felt
this could become relevant to LDUP.

G3.  ACL administration SHOULD be part of the LDAP protocol.  Access
   control information MUST be an LDAP attribute.

G3 seems "related" to LDUP because ACL information MUST be (viewable as)
LDAP attributes, replication MUST ensure that the "view" of this
information
is IDENTICAL between any replicas that have the same entry(ies).

G4.  Object reuse protection SHOULD be provided and MUST NOT inhibit
   implementation of object reuse. The directory SHOULD support policy
   controlling the re-creation of deleted DNs, particularly in cases
   where they are re-created for the purpose of assigning them to a
   subject other than the owner of the deleted DN.

G4 is basically the justification for the LDUP entry UUID, and while
it's not strictly an LDUP feature (it's really a change to the
underlying
information model of the directory, in my opinion), LDUP has identified
it as a requirement and specified it in the LDUP specifications. This
requirement makes implications about use of UUIDs associated with
entries
and the need to "keep track of" deleted entries - which are two things
that LDUP happens to provide already.  So it is "fortuitous" that LDUP
happens to be "in line" with what G4 would require.

U13.  A single administrator SHOULD be able to define policy for the
   entire directory tree.  An administrator MUST be able to delegate
   policy administration for specific subtrees to other users.  This
   allows for the partitioning of the entire directory tree for policy
   administration, but still allows a single policy to be defined for
   the entire tree independent of partitioning.  (Partition in this
   context means scope of administration). An administrator MUST be
   able to create new partitions at any point in the directory tree, and
   MUST be able to merge a superior and subordinate partition.  An
   administrator MUST be able to configure whether delegated access
   control information from superior partitions is to be accepted or
   not.

U13 is basically a statement that there must be an administrative
model for ACM, that such a model must take into account LDUP logical
operations like splitting and joining areas of replication (partitions)
in the namespace, by insuring that each area of replication winds up,
after the split/join operation, with an unambiguous ACM governing all
the entries that need to be addressed to enable access control in that
area of replication. In LDUP we go further, below, and say that
there must be a single unambiguous ACM governing each entry and that
it must be the same ACM in all replicas that hold the entry, but that
is a refinement proposed by this Design Team.

Approaches arriving at work programs for addressing these requirements:

1) The LDUP WG can define a new administrative model
2) The LDUP WG can LDUP can look for an administrative model that
already exists.
3) The LDUP WG can seek to establish a working liaison with an external
group to
   solve the problems required and adopt their solution.

Prod/Con Analysis of Each Approach:

Approach	Pros			Cons

    1		None			Essentially the same set
					of contributors have tried
					and failed to achieve consensus
					on such a model within the IETF

    2		Some existing models	Most models are vendor-specific
and
		already have broad	proprietary; thus there will be 
		deployment		impedance towards adoption
because
					the intellectual property is not
		One adaptation of a	freely available for creation of
		complimentary (x.500)	derivative works
		model exists as I-Ds
		already		

    3		The work could proceed	No such work has materialized to
		in parallel with that	date.
		in the IETF and would
		not significantly	Efforts that might produce
useful	
		impact the WG from a	documents in this subject area
		resource perspective	are not expected to do so in a
					timeframe generally thought to
be
					useful to LDUP.			

Because the second approach seems like the most reasonable balance
between
defining a new model or looking elsewhere for a new model, the Design
Team
has elected to make that recommendation to the WG at this time. So we
present
this list of existing administrative models for consideration:

 - various proprietary models from existing implementations
 - subentry draft (withdrawn) from Ed Reed
 - subentry + (first part of) ACM draft from Kurt Zeilenga and Steven
Legg

The last model, Kurt Zeilenga's subentry draft in combination with the
first part of Steven Legg's ACM draft (the part of the draft that
discusses
the X.500 administrative model) appears to offer everything that is
needed
by LDUP to describe the access control scheme employed in an area of
replication. These drafts are available at these locations:

http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-07.txt

http://www.ietf.org/internet-drafts/draft-legg-ldap-acm-admin-00.txt	

We believe that this identifies the minimal set of things that LDUP
needs
to do in the area of access control in order to ensure consistent and
secure access to information replicated between two replicas.

Rather than expend time and energy in producing multiple work programs
as the Design Team charter suggests, the Design Team felt that it's
energies were best directed to produce a single work program for the
Working Group to consider related to the recommended approach towards
solving the Access Control problems associated with LDUP.

Proposed LDUP Access Control Work Program:

1. Definition of the administrative model to be used.

2. Definition of how access control schemes are identified using the
model
(depends on 1.)

3. Guidelines for documenting access control schemes to promote
interoperability (depends on 2.)

4. Definition of access control schemes that can be employed in an area
of
replication or with respect to a replicated entry (depends on 3.)

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email-masked]

http://www.dsi-consulting.com

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 09 Sep 2002 21:25:27 -0700

I don't have much time to waste on this rat hole, so I'm not
going to waste my time (or the WGs) debating the technical
points made in this report.  Except to say that the minimal
amount of work the LDUP WG needs to do in specifying an
LDAP ACM (or ACM framework) is none.

Per the recently completed LDUP requirements document
<draft-ietf-ldup-replica-req-12.txt> (approved for publication),
LDUP does not require a standard LDAP ACM.  This plan
doesn't attempt to provide a standard LDAP ACM.  So, it
seems, the proponents of this plan have already conceded
this point.

I believe all work suggested in the plan can be written
as an extension to LDUP and/or LDAP.

I see no reason to burden the LDUP WG with this work.  The
LDUP WG is already struggling to meet its deliverables and
the addition of this work item will significantly hinder
progress on those deliverables.

Hence, I suggest that the charter not be amended to include
any new work items and that the proponents of this work
be asked to continue it on an individual basis.

Kurt

---

From: "Chris Apple" <[email-masked]>
Date: Tue, 10 Sep 2002 01:32:18 -0400

Kurt,

This is not a rat hole. It's a report from the Design Team
that the WG agreed should form.

Various deliverables of the LDUP WG will have to reference
ACM/ACI-related specifications regardless of where they
are produced.

The Working Group has already agreed to discuss the technical
points contained in this report, per consensus established
around the Design Team work program posted to the mailing list
(and referenced below). I would also like to state the obvious:
the WG isn't prohibited from discussing the expansion of its
own charter based on input from the Design Team.

Your suggestion is noted and appreciated. However, John and I
would be creating the impression of prematurely judging consensus
if we were to simply agree with you and ask the WG members if
they do also. You are of course free to ignore any subsequent
discussion on this topic as is anyone else who deems it to be
a waste of their time. However, as a Co-chair, I would think
you'd be interested in whether or not the WG might adopt one
of your drafts as a deliverable.

John and I need to see some indications about whether or not
it would be a good or bad idea (and why) to add the work items
suggested. From other folks.

Now that there is at least a proposal on the table for the WG
to consider about how to proceed with our work, we can begin to
discuss what that means and where we collectively believe the
ACM/ACI/Administrative Model work ought to happen.

So, we need to discuss the report, its content, and figure
out the following as the Design Team's work program suggests:

1) Are the recommendations of the design team sufficient to
   address the ACM/ACI/Administrative Model requirements for
   LDAPv3 Replication?

2) Where should the recommended work items be completed?

Silence, in this case, is not likely to mean consent as
it sometimes does in the IETF...it is likely to mean that
John and I will have to evaluate whether or not to suggest
to the Applications Area Directors that the LDUP WG be
prematurely concluded.

Anyone who doesn't want to see us forced into that decision
point, should post your views on the above to the list.

DSI Consulting, Inc.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Tuesday, September 10, 2002 12:25 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: LDAPv3 Replication Access Control Design Team Report

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 10 Sep 2002 05:42:03 -0700

Let's cut to the key question:

  Does LDAP replication REQUIRE a standard LDAP ACM?

(REQUIRE here in the RFC 2119 sense).

If the consensus is yes, then we should determine how this
requirement is going to be fulfilled.  (I note that the
proposed plan doesn't produce a standard LDAP ACM.)

If the consensus is no, then we need not determine how an
LDAP ACM will or will not be produced.  It simply can remain
out of scope.

I see little point is discussing the details of the plan
until we've actually agreed upon requirements...

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 10 Sep 2002 06:40:07 -0700

>to the Applications Area Directors that the LDUP WG be

Regardless of consensus on this issue, you should evaluate
(with WG input) whether or not the WG can complete its
deliverables in a reasonable amount of time and, if not,
recommend the WG be shutdown.

While I think we can complete the LCUP work item in a
reasonable amount of time, I have serious doubts the WG
will ever complete LDUP work items.  The WG seems to be
floundering here, not able to focus on the critical issues
and hopelessly lost in requirement debates.

So, not only do I believe new WG items should not be added
to our charter, we should either 1) narrow the focus to
the basic replication protocol work or 2) concluded (after
completing LCUP work).

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Tue, 10 Sep 2002 09:48:31 -0400

> and hopelessly lost in requirement debates.

I don't think the group is hopeless lost in requirement debates, but I 
agree that not much progress has been made lately. I think this is 
mainly a "time and energy and focus" issue though. Therefore my question 
for the chairs and the group as a whole is: do we have enough volunteers 
with enough time and desire and expertise to complete the work? I don't 
know the answer.

-Mark Smith
  Netscape