[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LDAPv3 Replication Access Control Design Team Report
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.
Chris Apple - Principal Architect
DSI Consulting, Inc.
mailto:capple@xxxxxxxxxxxxxxxxxx
http://www.dsi-consulting.com
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@xxxxxxxxxxxx]
Sent: Tuesday, September 10, 2002 12:25 AM
To: capple@xxxxxxxxxxxxxxxxxx
Cc: ietf-ldup@xxxxxxx
Subject: Re: LDAPv3 Replication Access Control Design Team Report
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
At 07:00 PM 2002-09-09, Chris Apple wrote:
>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