LDAPv3 Replication Access Control Design Team Report

["Chris Apple" <capple@xxxxxxxxxxxxxxxxxx>]

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:capple@xxxxxxxxxxxxxxxxxx

http://www.dsi-consulting.com