Subject: Re: Replicating policy information (RE: LDAPv3 Replication Access Control Design Team Report)

From: John McMeeking <[email-masked]>
Date: Tue, 10 Sep 2002 10:45:24 -0500

Kurt,

I have no problem with a more general solution/framework for replication of
policy information. That certainly beats defining a new set of schema and
behavior to handle each policy that is affected by replication.

I did not intend to suggest that LDUP should negotiate replication of
access control information, only that armed with information about what
access control schemes were used, LDUP (likely under control of an
administrator) could behave differently.  I would certainly want an
administrator to determine that access control information would not be
replicated.  But LDUP could adopt a default behavior that went the other
way, and refuse to replicate with a server that does not support the proper
access control scheme.

Again, I only wanted to point out kinds of behavior related to access
control (or other policies) that LDUP should address, and that LDUP
required only a means to identify, possibly select, the access control
scheme used, and not a specific access control scheme.

John  McMeeking

                      "Kurt D.                                                                                               
                      Zeilenga"                To:       John McMeeking/Rochester/IBM@IBMUS                                  
                      <Kurt@OpenLDAP.          cc:       Timothy Hahn/Durham/IBM@IBMUS, [email-masked], owner-ietf-       
                      org>                      [email-masked]                                                            
                                               Subject:  Replicating policy information (RE: LDAPv3 Replication Access       
                      09/10/2002 09:52          Control Design Team Report)                                                  
                      AM                                                                                                     

John hits on a interesting point, but he limits it to just
access control information.  I also disagree with his
conclusion he draws from the point.

When replicating between heterogeneous servers, each server
will have different operational attributes (as well as entries
which only hold operational information).  Some of these
operational attributes are maintained by the server and provide
information to the directory users.  Some are maintained by
directory users and are used by the directory server in its
processing.  Those of the latter can be viewed as policy
attributes.

In some cases, it may be desirable to share values of policy
information.  In other cases, no.  What LDUP needs to ensure
is that replications agreements can express the POLICY for
which policy attributes are to be replicated and which ones are
not to be replicated.  Then the authority (or authorities)
establishing the replication agreement will have the means
for ensuring only information appropriate to be replicated
is replicated.

Hence, LDUP MUST support fractional and partial replication
and LDUP replication agreements must be capable of expressing
the fraction and/or part to be replicated.

However, I believe it unwise (and insecure) for LDUP to
support negotiate (select) what policy information should be
exchanged between replicas.  What to replicate should be
explicit in the replication agreement.

Kurt

At 07:05 AM 2002-09-10, John McMeeking wrote:

>
>
>I agree with Tim.
>
>I see this as similar to how X.501 separates the general security model
>from a specific access control model.  The X.501 security model defines a
>mechanism for identifying the access control schema and its scope of
>control, while its Basic Access Control defines one (of possibly many)
>access control schemes.
>
>I think we need the security model portion.  At a minimum it provides a
>basis for determining whether all the servers support a given access
>control scheme.  Beyond that, if a server supported multiple access
control
>schemes, it provides a framework for specifying which access control
scheme
>is used for some area of the DIT, or how servers should behave in the
>presence of differing or identical acces control schemes.
>
>We do not need to specify a specific access control scheme.  We need to
>ensure that LDUP makes consistent access control across servers possible,
>possibly specifying that ACI is replicated (if the specific scheme
>represents ACI as operational attributes and/or LDAP objects).  I'm sure
>some folks would love it if they could manage access control across a
>hetergenous directory network, but that is a much tougher nut to crack --
>both from the perspective of agreeing on such a beast, and then getting
>vendors to implement it.
>
>Given the security model pieces, we can then define how LDUP should handle
>ACI information.  For example:
>- If the same access control scheme is used on two servers that replicate
>to one another, the attributes and / or LDAP objects that define ACI are
>replicated.
>- If different access control schemes are used -- writeable server(s) use
>same model to control updates, read only servers might allow anonymous
>searches to all data -- LDUP could use this knowledge to not replicate the
>same attributes and / or objects.
>
>The above does not require that we define a specific scheme, only that we
>have a means to identify -- possibly select -- the access control model
>used by various servers for a given area of the DIT, and that a server
that
>implements an access control model know how to behave with respect to
>replication of access control information.
>
>
>John  McMeeking
>[email-masked]
>
>
>
>

>                      Timothy

>                      Hahn/Durham/IBM@I        To:       [email-masked]

>                      BMUS                     cc:

>                      Sent by: owner-          Subject:  RE: LDAPv3
Replication Access Control Design Team Report
>                      ietf-ldup@mail.

>                      imc.org

>                      09/10/2002 08:04

>                      AM

>
>
>
>
>
>Kurt,
>
>My opinions below.
>
>Regards,
>Tim Hahn
>
>Internet: [email-masked]
>Internal: Timothy Hahn/Durham/IBM@IBMUS
>phone: 919.224.1565     tie-line: 8/687.1565
>fax: 919.224.2540
>
>
>
>
>                      "Kurt D.
>
>                      Zeilenga"                To:       <capple@dsi-
>consulting.net>
>                      <[email-masked]        cc:       <ietf-ldup@imc.
>org>
>                      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