RE: LDAPv3 Replication Access Control Design Team Report

["Liben, Michael (GTS)" <mliben@xxxxxxxxxxxxxxx>]

Once the directory data is replicated to another administrative authority, that authority owns access control, including its definition. If both replicas are governed by a common authority, then the
ACM data can travel as an attribute of the object.



-----Original Message-----
From: Richard Huber [mailto:rvh@xxxxxxx] 
Sent: Tuesday, September 10, 2002 7:35 PM
To: ietf-ldup@xxxxxxx
Subject: Re: LDAPv3 Replication Access Control Design Team Report


I agree with Tim.

If access controls are being used in a directory, the directory administrator has decided that it is important to
control access to all or part of the data in the tree.  So if replication is used in a directory that has access
controls, there needs to be a way to make sure that those access controls are not lost because of replication.

A standard access control mechanism for all LDAP directories is one way to do this.  But it can also be done by
making sure that the ACM in effect for any given part of the DIT is well defined, and that the definition can be
carried as part of the data being replicated.

So as Kurt noted, the design team did not propose a plan to design the one true access control mechanism.  But we do
need a replicatable way to express what ACM is in effect at any point in the DIT.  Otherwise, administrators will
have to choose between reliability (multiple copies via replication) and data security (access controls).

If, as discussed by John McMeeking and Kurt, this leads to a general framework for replicating policy information, so
much the better.  This makes it possible to replicate policy information if the situation so demands.

Requiring that LDUP make this possible is not the same as requiring that LDUP make this happen automatically.  I
agree with Kurt that LDUP should not automatically negotiate what policy data to transfer.  But LDUP should make it
possible to transfer policy data where needed, and we need the administrative structure to make this doable.

I believe that is where the design team proposal is heading.

Rick Huber

Timothy Hahn wrote:

> Kurt,
>
> My opinions below.
>
> Regards,
> Tim Hahn
>
> Internet: hahnt@xxxxxxxxxx
> Internal: Timothy Hahn/Durham/IBM@IBMUS
> phone: 919.224.1565     tie-line: 8/687.1565
> fax: 919.224.2540
>
>
>                       "Kurt D.
>                       Zeilenga"                To:       <capple@xxxxxxxxxxxxxxxxxx>
>                       <Kurt@xxxxxxxxxxx        cc:       <ietf-ldup@xxxxxxx>
>                       g>                       Subject:  RE: LDAPv3 Replication Access Control Design Team Report
>                       Sent by:
>                       owner-ietf-ldup@m
>                       ail.imc.org
>
>
>                       09/10/2002 08:42
>                       AM
>
>
>
> Let's cut to the key question:
>
>   Does LDAP replication REQUIRE a standard LDAP ACM?
>
> (REQUIRE here in the RFC 2119 sense).
> TJH> I believe that LDAP replication MUST ensure that the security
> TJH> (i.e. authorization to access - add/modify/search/delete)
> TJH> is NOT compromised by the LDAP replication mechanism defined.
> TJH>
> TJH> Thus, I believe that LDAP replication REQUIRES that access
> TJH> control issues be "attended to" (in the RFC 2119 sense).
> TJH>
> TJH> But I DO NOT feel that LDAP replication needs define a specific
> TJH> Access Control Model (ACM).  LDAP replication need only ensure
> TJH> that SOME ACM can be applied across the servers involved in the
> TJH> data replicated amongst them and that LDAP replication doesn't
> TJH> "mess that up".
>
> 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.
>
> TJH> Unfortunately, I don't believe the answer is as "binary"
> TJH> as this.  LDAP replication REQUIRES that things be done
> TJH> "securely" but it does NOT REQUIRE a specific ACM.
>
> I see little point is discussing the details of the plan
> until we've actually agreed upon requirements...
>
> Kurt